One thing that Cassandra doesn't have a good story of, and what intro guides continue to gloss over is the ops situation. I've recently moved some our largest Cassandra tables to BigTable for this reason. The compaction / repair / garbage collection death cycle is probably the most difficult thing to manage, and in the past 3 years of using Cassandra, managing it has gotten worse. Tools have been deprecated (like OpsCenter) and new features can exacerbate the problem. There is still no reliable way to detect when repairs have finished, and if you have a large enough table, repairs can take a week to finish. Combine that with the fact that if a table is that large, then it probably has a high write volume - meaning it has a lot of compactions as well. So you have repairs and compactions going on which thrash the heap, and now you also have a GC tuning problem.<p>It took a lot of experimentation to get right, but once I did, scaling started to mean smaller drives and more nodes, which meant a more expensive cluster, for which I was largely paying for my CPUs to repair and garbage collect data.<p>Other than ops however, Cassandra is a great tool and does everything it says it does on the box.