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.
Cassandra Performance
31–40 of 76 posts
Re: Cassandra Performance
#32HBase 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...
Re: Cassandra Performance
#33Cassandra 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.
Re: Cassandra Performance
#34Earlier quoted context omitted.
If you don't understand the implications of eventual consistency, you're heading for a fall. It's not a trivial topic and unfortunately "it appears to work as you'd expect" on a small dev cluster which can lead to statements like yours. Your parent's post is actually very very accurate.
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."
Re: Cassandra Performance
#35While Cassandra has some nice characteristics, there are a few things I've run into along the way. Don't expect to run a 3-node Cassandra cluster and get much out of it in terms of availability, in the way you might run a master/slave failover setup. It's somewhat obvious, but your Cassandra deployment can't just start with a couple of nodes and scale up as you run into bottlenecks. The number of nodes needed starts…
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.
Re: Cassandra Performance
#36While Cassandra has some nice characteristics, there are a few things I've run into along the way. Don't expect to run a 3-node Cassandra cluster and get much out of it in terms of availability, in the way you might run a master/slave failover setup. It's somewhat obvious, but your Cassandra deployment can't just start with a couple of nodes and scale up as you run into bottlenecks. The number of nodes needed starts…
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…
[deleted]
Re: Cassandra Performance
#37HBase 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...
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 works very well.
Re: Cassandra Performance
#38HBase 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),…
Also they used an old version of HBase, 90.4 in the benchmark, HBase 94.0 has been out since May 2012, and has a lot of work to improve performance especially remove lock contention on the region server.
Re: Cassandra Performance
#39While Cassandra has some nice characteristics, there are a few things I've run into along the way. Don't expect to run a 3-node Cassandra cluster and get much out of it in terms of availability, in the way you might run a master/slave failover setup. It's somewhat obvious, but your Cassandra deployment can't just start with a couple of nodes and scale up as you run into bottlenecks. The number of nodes needed starts…
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.
Re: Cassandra Performance
#40Cassandra 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…
Sorry but this is just nonsense. Cassandra with PlayORM/Astyanax has been the easiest database for me to install, use and manage out of the 10+ I've tried. Far simpler to install/manage than MySQL Cluster or Riak, far easier to use than PostgreSQL and infinitely better to scale than MongoDB. You don't have to understand ColumnFamilies, consistency or the different topology strategies. The defaults are fine and if you…
>You don't have to understand ... consistency
This is a recipe for disaster. Cassandra requires careful understanding of its claimed consistency guarantees to be used properly. Proper use of the ConsistencyLevel argument is pretty critical if you want to build a real site that actually works under load.