4 ms·

I'm not saying nosql dbs don't have their place, but... Articles like this are exactly why my current company moved to cassandra, and why I regret not having t

I'm not saying nosql dbs don't have their place, but... Articles like this are exactly why my current company moved to cassandra, and why I regret not having tried harder to stop them (but I was new, didn't knew cassandra and I'm digressing) Cassandra is (very probably) wrong for your use case. The only model that makes sense in cassandra is where you insert data, wait for minutes for the propagation, hope it was propagated, then read it, while knowing either the primary/clustering key or the time of the last read data (assuming everything has the timestamp in the key, and has been replicated) Anything else in cassandra feels like a hack. Deleting stuff is kinda bad, it will remain there (marked as tombstone) until the "grace period" has expired (default 10 days). It is really bad unless you put the timestamp in the keys, which you basically must do in cassandra. default 100k tombstones ad your query will be dropped. You want a big grace period for the data, 'cause if a node goes down that is exactly the maximum time you have to bring it up and hope all data has finished resyncing. Otherwise deleted data will come up again, and your node will have less data. If the grace period has passed or are not confident in the replication speed, absolutely delete that node and add a new one. Bigger grace period means more tombstones (unless you never, ever delete data). Even if all the data/tombstones have been replicated to all nodes, the tombstones remain. Running manual compaction once prevents the automatic compaction from running ever again. You need to pay attention to never scan tombstones, so no queries like select without where, always use a LIMIT or where that will ensure you will not scan deleted data. (but don't use 'where' on columns that are not keys... Unless X, unless Y on the unless X and so on for everything) They need kafka because the probably need a queue, and there is no way to implement those in semi-realtime in cassandra without the tombstone problem killing your queries. Features have been added and then deprecated (see material views), or very limited in their use (secondary indexes, which basically work only per-partition). Queries that are not plain select/insert (or update, which is the same as insert) have loads of special cases and special cases on the special cases. LWT are much slower, and are the only transaction/consensus you will find. for single-row only. COPY TO/FROM works with csv, but will not properly escape all kinds of data, giving you all kinds of fun. Hell, manual copy-pasting a timestamp from a select to an insert does not work, the format a tiny bit different. Backups/restore procedures seem complex and amateurish, especially when you have to restore in an other cluster. You can select how many nodes to query for an operation, but things like "Quorum" are not a transaction or consensus. BATCH is atomic, not isolated. read-after-write works only on exactly the same node (unless you write to ALL nodes, and I have not checked what happens if one is down). And a sh*tload of other stuff. I could go on, but even if this fits your use case, don't use cassandra. Try scylladb first. Same protocol, missing material views and LWT (until next year apparently), but 10x as fast, probably due to being C++ vs java

pixelmonkey 7y ago
I had a somewhat similar experience. This, especially, is what my team also found to be true: "The only model that makes sense in cassandra is where you insert data, wait for minutes for the propagation, hope it was propagated, then read it, while knowing either the primary/clustering key or the time of the last read data." We use Cassandra in production at my company, but only after much scope reduction to the use case. We needed a distributed data store for real-time writes and delayed reads for a 24x7 high-throughput shared-nothing highly-parallel distributed processing plant (implemented atop Apache Storm). Cassandra fit the bill because writes could come from any of 500+ parallel processes on 30+ physical nodes (and growing), potentially across AZs in AWS. And because the writes were a form of "distributed grouping" where we'd later look up data by row key. At first, we tried to also use Cassandra for counters, but that had loads of problems. So we cut that. We briefly looked at LWTs and determined they were a non-starter. Then we had some reasonable cost/storage constraints, and discovered that Cassandra's storage format with its "native" map/list types left a lot to be desired. We had some client performance requirements, and found the same thing that hosed storage also hosed client performance. So then we did a lot of performance hacks and whittled down our use case to just the "grouping" one described above, and even still, hit a thorny production issue around "effective wide row limits". I wrote up a number of these issues in this detailed blog post. https://blog.parse.ly/post/1928/cass/ https://blog.parse.ly/post/1928/cass/ The good news about Cassandra is that it has been a rock-solid production cluster for us, given the whittled-down use case and performance enhancements. That is, operationally, it really is nice to have a system that thoughtfully and correctly handles data sharding, node zombification, and node failure. That's really Cassandra's legacy, IMO: that it is possible to build a distributed, masterless cluster system that lets your engineers and ops team sleep at night. But I think the quirky/limited data model may hold the project back long-term, when it comes to multi-decade popularity.

pixelmonkey 7y ago

I had a somewhat similar experience. This, especially, is what my team also found to be true: "The only model that makes sense in cassandra is where you insert data, wait for minutes for the propagation, hope it was propagated, then read it, while knowing either the primary/clustering key or the time of the last read data." We use Cassandra in production at my company, but only after much scope reduction to the use case. We needed a distributed data store for real-time writes and delayed reads for a 24x7 high-throughput shared-nothing highly-parallel distributed processing plant (implemented atop Apache Storm). Cassandra fit the bill because writes could come from any of 500+ parallel processes on 30+ physical nodes (and growing), potentially across AZs in AWS. And because the writes were a form of "distributed grouping" where we'd later look up data by row key. At first, we tried to also use Cassandra for counters, but that had loads of problems. So we cut that. We briefly looked at LWTs and determined they were a non-starter. Then we had some reasonable cost/storage constraints, and discovered that Cassandra's storage format with its "native" map/list types left a lot to be desired. We had some client performance requirements, and found the same thing that hosed storage also hosed client performance. So then we did a lot of performance hacks and whittled down our use case to just the "grouping" one described above, and even still, hit a thorny production issue around "effective wide row limits". I wrote up a number of these issues in this detailed blog post. https://blog.parse.ly/post/1928/cass/ https://blog.parse.ly/post/1928/cass/ The good news about Cassandra is that it has been a rock-solid production cluster for us, given the whittled-down use case and performance enhancements. That is, operationally, it really is nice to have a system that thoughtfully and correctly handles data sharding, node zombification, and node failure. That's really Cassandra's legacy, IMO: that it is possible to build a distributed, masterless cluster system that lets your engineers and ops team sleep at night. But I think the quirky/limited data model may hold the project back long-term, when it comes to multi-decade popularity.