51–60 of 76 posts
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 .
HBase looks bad in some of these benchmarks, because it is hard to setup and has many tuning knobs to be tuned correctly for the workload in question. Due to its strictly consistent nature you have to think about key design, hotspotting of servers, etc, etc. In return you get correct atomic operations, row transactions, range scans by default (Cassandra uses a random partitioner by default not allowing range scans),…
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...
[1] https://ccp.cloudera.com/display/CDH4DOC/Software+Configurat... [2] http://blog.cloudera.com/blog/2012/10/quorum-based-journalin...
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."
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.
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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
What do you mean by "from what I can tell" ? Have you actually experienced this issue or just making it up ?
I have looked through the code to conclude that Cassandra's consistency claims are overblown.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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…
> There's not really any way that nodes can disagree on this.
Atomic, dynamic updates to a ring are a difficult thing to do. If I'm missing some additional mechanism that ensures agreement on ring membership, please explain.
Earlier quoted context omitted.
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.
Please enlighten us with a cluster database that enables guaranteed consistency with dynamic node membership. They all have quirks handling membership (unless you're looking at a shared disk setup).