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:
- data size;
- transaction throughout;
- 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.
| Cassandra | Hadoop/HDFS | Mongo | |
| Primary use cases | Large-scale operational database; Structured data store for analytics engines | Big data analytics database | Flexible JSON database for rapid development |
| Development Model | Apache Foundation community maintained | Apache Foundation community maintained | Proprietary development released under AGPL open source |
| Reliability | 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. |
| Read/write latency | 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. |
| Scalability | 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. |
| Query Language | CQL, an SQL-like language | Map-reduce API plus many add-ons available (inc SQL) | API and JSON based queries. |
| Data Model | Structured tables but allows for sparse value and multi-value fields | Schema-less | Schema-less JSON |
