A question that we commonly get asked is “how does Apache Cassandra compare to NoSQL technology X?”. While the easy answer is to say “It’s just better”, the truth of course isn’t that simple. NoSQL encompasses a much more diverse range of technologies than the relational database world with specific NoSQL products suited to particular use cases.
The definition I often use (OK, made up) for NoSQL is any database technology designed for a more specialised use case to in order to overcome the limitations of RDBMS technology in terms of:
reliability and manageability;
flexibility of data schema; and/or
cost of hardware.
One implication of this definition is that it doesn’t make sense to say that NoSQL generally is “better” than relational databases. If you want to compare NoSQL technology X with technology Y then you need to understand what you want to use it for.
Perhaps the better question to ask is which use cases are Cassandra and other popular NoSQL technologies such as MongoDB and Hadoop/HDFS best suited to? The table below provides a summary of the characteristics
In summary, Cassandra is a great choice where:
you need an operational database that can extend to supporting analytics;
you don’t want to be limited in ability to scale; and
you want the highest possible levels of availability.
Primary use cases
Large-scale operational database;
Structured data store for analytics engines
Big data analytics database
Flexible JSON database for rapid development
Apache Foundation community maintained
Proprietary development released under AGPL open source
Extreme reliability, masterless and replicated. No failover required.
Full bi-directional multi-datacenter support
High availability with automated master fail-over.
High availability with multiple replicas and automated failover.
Typically 5-15 milliseconds for standard operations. Consistent as dataset grows.
Engineered for batch throughput rather than latency.
Similar to Cassandra for simple operations. More complex querying capability can lead to greater variability.
No practical limits. Operational clusters in the multi-PB range (eg Apple).
No practical limits. Multi-PB scale not uncommon.
Can scale to TB and beyond but requires sharding and is therefore less manageable at very large scale.
CQL, an SQL-like language
Map-reduce API plus many add-ons available (inc SQL)
API and JSON based queries.
Structured tables but allows for sparse value and multi-value fields