2 ms·
These are all quite true: Frequent DELETE: True, unless your data is time-windowed. The extension to this is frequent updates to the same "cell" of data, which
by AtlasBarfed 5y ago
These are all quite true:
Frequent DELETE: True, unless your data is time-windowed. The extension to this is frequent updates to the same "cell" of data, which also overloads the compaction and read paths. DELETEs have a big toll on relational databases at scale as well though, although SSDs mitigated a large part of those. DELETEs are very hard on B+tree indices without LSM features, and I think I've read that compaction issues exist in Postgres under heavy deletes: all those empty cells need to be cleaned up eventually...
Complex Indexes: Well, you can just roll your own view table, although I don't know your exact use case. The original (heavily downvotes) comment about B+ trees is that SQL users are used to throwing a B+ tree index onto tables. You can't do that in cassandra, and I'm not aware of how you would do it in other distributed scenarios that aren't full-dataset-replication strategies. From what I've read, a B+ tree scaling and many other index scalings aren't Cassandra problems, they are fundamental CAP problems.
Operational Pain: You are mostly right (Cassandra is a cranky beast), but once you get to heavy distributed data, it's all a PITA. At least Cassandra has some node loss tolerance. In a lot of times I hear people complain about Cassandra I ask, "well, did the database go down"? And they generally admit it stayed up.
Scans suck: Yup. If you need scans, do a separate datacenter for the scans. On a sufficiently large distributed dataset, all scans / "big data queries" are approximations of current data state: there's no meaningful/practical way to tie to a transaction window. Is this a cassandra problem or a fundamental CAP problem?
Transactions: Compare and Swap is about as good as it gets, and it's hard, and there's no way to span tables. Does anyone have a solution mathematically for sharded distributed data that isn't? As in is this a Cassandra problem or a fundamental CAP problem?