Well it's a cassandra company so it's bound to exaggerate the throughput test that shows Cassandra winning but relegating its huge weakness in latency performance (Whoa!! 10ms average read latency from in-memory store...) to an "area for improvement" list at the bottom is a bit disingenuous. It's not a small issue. It's an order of magnitude difference from Voldemort, redis and even mysql at scale.
Cassandra Performance
71–76 of 76 posts
Re: Cassandra Performance
#72What is memory overhead? How much memory Java processes consume comparing to the amount of data a node could handle, assuming there must be no swap (otherwise we all know what happens to any Java process).
It seems that question has almost completely fallen off the radar today. I've experienced medium sized voldemort clusters eating up huge amounts of extra RAM (of the order of 100% overhead[1]) to avoid falling into pathological GC patterns over long runs. Actually I shouldn't really single out voldemort. The problem is java.
Java[2] is a terrible platform to write large in-memory caching servers on. The write and access patterns are a complete mismatch for the assumptions made in the generational GC algorithms that most current JVM's sport. Most caches will evict on an LRU basis, which means that almost all allocations will end up in the old generation heap before finally being evicted. Which is precisely the counter-optimal case for the basic assumptions that the generational GC model relies on (that most objects are short-lived and get swept while still in the "young" heap (which is ultra cheap).
Footnotes: [1] "overhead" here means precisely how the parent post defines it. [2] more precisely, the commonly used freely available JVM's that most shops use. There might be better GC implementations (e.g. as claimed by azul) but I don't have any direct experience with them.
Re: Cassandra Performance
#73Earlier quoted context omitted.
I have looked through the code to conclude that Cassandra's consistency claims are overblown.
I've looked at your user profile to suggest you're a troll account. Please elaborate on the observations you have that led to this conclusion.
Let's not revert to ad hominems so quickly. If you looked through my submissions, you'll see that I explained the problem elsewhere. Here it is again:
Imagine two nodes, both initiating updates to the same row. One has observed a number of node additions and deletions. The other has not. They will perform their updates on disjoint sets.
Additions to the ring are not atomic, therefore quorums aren't.
Re: Cassandra Performance
#74What is memory overhead? How much memory Java processes consume comparing to the amount of data a node could handle, assuming there must be no swap (otherwise we all know what happens to any Java process).
It seems that question has almost completely fallen off the radar today. I've experienced medium sized voldemort clusters eating up huge amounts of extra RAM (of the order of 100% overhead[1]) to avoid falling into pathological GC patterns over long runs. Actually I shouldn't really single out voldemort. The problem is java. Java[2] is a terrible platform to write large in-memory caching servers on. The write and acc…
We got bit by GC issues with our Cassandra cluster, and we had to completely re-design a column family to fix it.
It's pretty telling that the development community is moving as many memory structures as possible outside the java heap, each new major release has moved some piece or other.
The biggest threat I see to Cassandra is that java in the end won't cut it, that the JVM will limit its performance too much, allowing a competitor to surpass it. Stop-the-world GC pauses are not something you want in a high-performance database solution.
Re: Cassandra Performance
#75Earlier quoted context omitted.
It seems that question has almost completely fallen off the radar today. I've experienced medium sized voldemort clusters eating up huge amounts of extra RAM (of the order of 100% overhead[1]) to avoid falling into pathological GC patterns over long runs. Actually I shouldn't really single out voldemort. The problem is java. Java[2] is a terrible platform to write large in-memory caching servers on. The write and acc…
We got bit by GC issues with our Cassandra cluster, and we had to completely re-design a column family to fix it. It's pretty telling that the development community is moving as many memory structures as possible outside the java heap, each new major release has moved some piece or other. The biggest threat I see to Cassandra is that java in the end won't cut it, that the JVM will limit its performance too much, allo…
I was in a discussion with a member of the Go development team, bitterly complaining about their decision to go with a GC'd heap as the only way to access memory for something they intended as a "systems programming language". They suggested I link in C data structures for those heap-heavy caching applications :-( As I see it, C and C++ are the only practical options for writing high performance, memory efficient, cache heavy applications for production use in the current tech climate.
Re: Cassandra Performance
#76Earlier quoted context omitted.
And more usually, you'll use the tool the tool that your most familiar with or can become most familiar [quickest]. You say so yourself, HBase is relatively hard to quickly come to terms. We can observe the same when viewing the "SQL camp" with MySQL and PostgreSQL (and MSSQL). It is also true of the Facebook HBase install! Completely unnecessary jab; the use of HBase was politically driven -- what the architects wan…
Hmm... Where to start. First, kindly point at an Cassandra installation, which supports the size that HBase supports in this setting. Can I assume you have first hand information about this decision from someone at Facebook? I was stating a fact... not a jab. Re: Google. Nothing at Google is driven by an eventually consistent store. They got that part right from beginning. It's too hard to manage from the an applicat…
Re: Facebook, as jbellis mentions in this comment thread, Facebook shards HBase, so it's not able to support what they need without some major additional complexity.
Re: eventual consistency. It's tunable to the need of the user. It's a trade-off. Tunable consistency becomes nice when you want a system to be always available. See the Amazon Dynamo paper, on which Cassandra is partially based.
I think many underestimate how many are using Cassandra in production. Spotify, eBay, Walmart, Netflix, Ooyala, NASA and others - one list is found here: http://www.datastax.com/cassandrausers.