Highlights
Passages saved from the original.
- Cassandra works really well if you want to write and store a large amount of data in a distributed system, don’t care much about ACID with good performance
- people joke that it’s more difficult to run it as a single node system than as a distributed one. Being distributed is kind of built into Cassandra and running it in a single node makes it seem like you are wasting its potential, kinda like you are using a Lamborghini in city traffic during rush hour
- Another popular feature of Cassandra is how it runs as a masterless system. Most traditional databases rely on master nodes and slave nodes. Slave nodes would generally be used for replication and master nodes for writing.
- When you ask for your row, the nodes gossip among one another to find out who holds that piece of data and return it to you. In fact, all nodes can serve requests for any piece of data, even if they don’t actually hold it.
- It offers partition-level atomicity but doesn’t offer rollbacks if the write operation succeeds in some nodes and fails in others. Also, depending on how you configure Cassandra, it is possible for your cluster to be in an inconsistent state. So nodes may disagree with each other on the data they hold.
-
Why should you not use Cassandra?
-
When you want a lot of different types of queries or you can’t predict your data usage
-
When a single node works
-
When you want strong ACID compliance
-
When you want many-to-many mappings or join tables
-
When you don’t want a rigid schema
Summary AI-generated
Summarised by an AI assistant when this source was saved. Double-check against the original.
In summary, Cassandra’s masterless, linearly scalable architecture trades strict ACID compliance for massive write throughput and high availability, making it a powerful but specialized tool best suited for specific large-scale workloads rather than a direct replacement for traditional relational databases.
- Cassandra uses a masterless, homogeneous node architecture with gossip protocols, eliminating single points of failure and simplifying distributed scaling compared to traditional master-slave databases.
- It prioritizes high write performance and linear scalability by embracing tunable consistency and weak ACID support, making it ideal for applications that can tolerate eventual consistency.
- Data modeling is query-driven and rigid; you must define your access patterns upfront since Cassandra lacks foreign keys, joins, and flexible schema enforcement.
- Avoid Cassandra if your application requires strong ACID transactions, complex relational queries, or if a single-node database already meets your performance needs, as the distributed overhead isn't worth the cost.
Notes this inspired
- Cassandra DatabaseGrowing
Cassandra is masterless. Cassandra has no Database ACID support. Bias towards Availability. Write heavy. Zero downtime needed (in traditional master/slave, there is a small downtime if master is down for the failover…