Inside Cassandra: The Internals That Make It Fast and Massively Scalable
Posted by Sushant098123@reddit | programming | View on Reddit | 6 comments
Posted by Sushant098123@reddit | programming | View on Reddit | 6 comments
A_modicum_of_cheese@reddit
I see gen AI. I downvote
Cidan@reddit
Many years ago, I managed several rather large Cassandra clusters that served millions of users daily.
There are no words to describe just how much work it is to manage and write against Cassandra and all of it's gotchas. Using Cassandra as a net new database in 2025 is something I would never do.
awj@reddit
At one place we ended up with both Cassandra and Elasticsearch. Replacing a single Cassandra node was roughly the same level of effort as rolling the entire ES cluster.
Can’t remember if it was a language client or plain Cassandra issue, but we also would have to restart all of our app servers if one of the seed nodes they were configured for went down.
It’s just infuriating how bad things are with that thing.
Cidan@reddit
We too also had Cassandra + ES. Total nightmare. Running Java based databases in general is pretty miserable.
sweetno@reddit
How Memtable is different from SSTable?
ChillFish8@reddit
Am I greatly forgetting how Cassandra and CQL work or is this just not true?
My memory of Cassandra is that you need to define a table, primary key, etc, and just like SQL your row can only have columns that are defined in the schema, and just like SQL those columns may be null, of all the differences Cassandra has, the schema side of things is virtually identical to SQL no? (Ignoring all the jazz about partition keys, sort/cluster keys, etc...)
Kind of? But the things that really hate random IO are mechanical devices like HDDs, not flash devices; you could be doing 4KB or 8KB IOPS on a modern NVME and still reach its peak throughput. It is just expensive on the CPU side of things when doing lots of small IOPS with the file system.
Overall, you touch on a lot of components of Cassandra, but never really go deep enough into them to really differentiate how it works differently to a traditional RDMS like Postgres.
For example, I could make the argument that your commit log explanation could equally be applied to Postgres' WAL.
Some bits like adding a node to the cluster, are really describing how the system does cluster membership, but you don't really explain or even mention how the nodes re-balance the data spread out across nodes as new shards are added. I.e. missing any explanation around the hash ring architecture.