Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cassandra Performance

datastax.com

Post reply on HN
Print view View original

41–50 of 76 posts

Re: Cassandra Performance

#41

Post by jamesaguilar »

otterley wrote: post #4

> A log-structured engine that avoids overwrites to turn updates into sequential i/o is essential both on hard disks (HDD) and solid-state disks (SSD). On HDD, because the seek penalty is so high; on SSD, to avoid write amplification and disk failure. This is why you see mongodb performance go through the floor as the dataset size exceeds RAM. The structure of MongoDB's on-disk data has nothing to do with why its per…

Even simpler hypothesis: Mongo's performance slows down once dataset size is greater than RAM because disk is slower than RAM.

Re: Cassandra Performance

#43

Post by rogerbinns »

otterley wrote: post #4

> A log-structured engine that avoids overwrites to turn updates into sequential i/o is essential both on hard disks (HDD) and solid-state disks (SSD). On HDD, because the seek penalty is so high; on SSD, to avoid write amplification and disk failure. This is why you see mongodb performance go through the floor as the dataset size exceeds RAM. The structure of MongoDB's on-disk data has nothing to do with why its per…

There is a secondary problem with using mmap. You don't know if an access will take a page fault. When thrashing starts happening MongoDB doesn't throttle new queries. New queries coming in then add fuel to the fire making existing queries take longer and longer. This causes a huge and rapid performance dropoff.

Of course not all new queries will cause paging so they could be left unthrottled. There is a system call mincore that will tell you if pages will take faults but it doesn't support scatter/gather and has race conditions especially when there is lots of paging!

I did report this at the beginning of 2010 - currently marked as major priority, planned but not scheduled: https://jira.mongodb.org/browse/SERVER-574

That said MongoDB is still my first database of choice. Nothing beats arbitrary JSON in, the same JSON back out.

Re: Cassandra Performance

#44

Post by linuxhansl »

justin_hancock wrote: post #37
jbellis wrote: post #32

Earlier quoted context omitted.

It's worth noting that the FB HBase install is also sharding across multiple sub-clusters because of the HDFS namenode SPOF problems [1]. Personally, if I'm going to shard manually I'll stick with postgresql. One of the primary reasons to use something like Cassandra is that it solves that for you. [1] http://www.slideshare.net/brizzzdotcom/facebook-messages-hba...

My understanding of facebooks Pod Architecture for HBase was not the name node but simply scaling HBase, HBase gets rather unpleasant at facebook scales. The facebook HBase fork has things like compactions disabled to improve performance. I ran a HBase cluster with 1PB storage, it became very unwieldy at this scale, thousands of regions and lots of tricks to keep it happy. As for SPOF, the name node now has HA and it…

Interesting. Do you remember what kind of problems you ran into and what version of HBase you used?

Re: Cassandra Performance

#45

Post by antman »

meh01 wrote: post #33
endymi0n wrote: post #9

Cassandra is ugly, hardcore and performant as hell. It's not meant for the casual user, it's really meant to be there for you at scales where MongoDB craps its pants. If you wrap your head around ColumnFamilies, tunable consistency and NetworkTopologySnitch strategies, you get rewarded by a database that can scale on a global level to millions of I/O operations per second. We at Trademob have chosen Cassy as the back…

I don't know how you can say it's "performant as hell" when it's actually slower than even MySQL for simple selects.

Selecting data is important, inserting is also important see: [1]A comparison of NoSQL dbs: Cassandra, HBase, MongoDB, Riak (includes MYSQL cluster)

[1] https://news.ycombinator.com/item?id=5076130

Re: Cassandra Performance

#46

Post by tylerhobbs »

meh01 wrote: post #31

Serious question: are people really still using Cassandra? I've only ever heard horror stories about big deployments, and the only posts about it come from DataStax.

Some of these are a bit dated, but it's still a reasonably accurate list of companies that have publicly disclosed their usage of Cassandra: http://www.datastax.com/cassandrausers.

Re: Cassandra Performance

#47

Post by tylerhobbs »

rescrv wrote: post #34
taligent wrote: post #29

Earlier quoted context omitted.

I am not disputing that Cassandra has a learning curve but I just disagree that it is any different to every other database available today. They ALL have issues and eventual consistency is a fundamental part of a distributed database so its something you have to learn either way.

Check out HyperDex, Hbase and BigTable for systems that provide better guarantees than "eventually."

You would need to define "consistency" in order to have a more reasonable discussion about what each system provides, but Cassandra certainly isn't only eventually consistent. You can choose the number of replicas that must respond in order to consider the read/write operation a success per operation, which allows you to have quorum-based strong consistency guarantees.

There are more details on the options here: http://www.datastax.com/docs/1.2/dml/data_consistency

Re: Cassandra Performance

#48

Post by meh01 »

antman wrote: post #45
meh01 wrote: post #33

Earlier quoted context omitted.

I don't know how you can say it's "performant as hell" when it's actually slower than even MySQL for simple selects.

Selecting data is important, inserting is also important see: [1]A comparison of NoSQL dbs: Cassandra, HBase, MongoDB, Riak (includes MYSQL cluster) [1] https://news.ycombinator.com/item?id=5076130

Yes, then you start thinking about the workload of the average webapp...

Re: Cassandra Performance

#49

Post by meh01 »

henrikschroder wrote: post #42
meh01 wrote: post #31

Serious question: are people really still using Cassandra? I've only ever heard horror stories about big deployments, and the only posts about it come from DataStax.

Netflix is probably the most well-known large user currently.

I don't know if this is heretical to say, but when I think about services that people should look up to in terms of architecture, I don't think of Netflix.

See all the downtime they have despite the 1000 posts on their blog about how wonderfully available their architecture is.

I can point to 10 other sites running on a boring LAMP stack with similar availability.

Re: Cassandra Performance

#50

Post by tylerhobbs »

jmix wrote: post #35
jbellis wrote: post #13

Earlier quoted context omitted.

Post author here. Your first paragraph is, bluntly, incorrect. Cassandra guarantees that data will always become consistent. This is automatic [1] for normal operation, including in the face of temporary failures. Permanent failures require running a "repair" process to rebuild the failed machine from other replicas [2]. I think you've also misunderstood how quorum works; it is a quorum of the replica count , which t…

False -- if there are nodes being added or deleted from the system, Cassandra provides no guarantee of consistency. Two nodes might disagree on quorum membership and thus quorum accesses may fail to overlap, leading to inconsistency. The consistency claims are overblown.

Cassandra uses a technique known as consistent hashing to allow each node to independently determine what nodes are replicas for a given row. The process really just involves hashing the row key and then comparing the result to the token of each node in the cluster. If the hash falls in between a node's token and the token of the previous node in the ring, then that node is a replica for that row. There's not really any way that nodes can disagree on this.

Given that nodes cannot disagree on the set of replicas for a row, quorums must (by definition, and the pigeon hole principal) overlap by at least one replica.

Post reply on HN