最近，我一直在从新项目的角度研究Cassandra，并从这个社区及其wiki中学到了很多东西。但是我没有找到任何关于如何在物理磁盘空间管理方面管理Cassandra更新的内容，尽管它似乎与使用压缩的记录删除管理非常类似。
假设有100个记录，每个记录有5个列值，所以当所有更改都被刷新时，所有记录都将被相邻写入，当删除操作完成后，它在Memory表中首先标记，物理记录在一段时间后被删除在配置或其充分。压实过程占据了空间。
现在的问题是，一方面是架构较少，一开始没有固定数量的列，但是当压缩过程发生时，另一方面就是..它是否像传统的RDBMS一样将记录相邻地放在磁盘上以加速RDBMS的读取过程很简单，因为它们必须按照column数据类型的声明分配固定数量的空间。
但是Cassandra如何在压缩过程中将记录放置在磁盘上（用于更新/删除）以加快读取速度？
与压缩相关的另一个问题是，当没有删除查询但是有更新查询用一些可变长度数据更新现有记录或完全插入新列时，那么压缩如何使其空间在磁盘之间可用现有的数据行？
答案 0 :(得分：3)
行和列按顺序存储在SSTable中。这允许压缩多个SSTable以输出新的（已排序的）SSTable，仅具有顺序磁盘IO。这个新的SSTable将被输出到磁盘上的新文件和自由空间。此过程不依赖于列的行数，而是依赖于它们按排序顺序存储。所以，是的，在所有SSTable中（即使是那些形成压缩的行），行和列将按照磁盘上的排序顺序排列。
更重要的是，正如您在问题中提示的那样，更新与插入没有什么不同 - 它们不会覆盖磁盘上的值，而是在Memtable中缓冲，然后刷新到新的SSTable中。当新的SSTable最终被包含原始值的SSTable压缩时，较新的值将消灭旧的值 - 即旧的值将不会从压缩中输出。时间戳用于确定哪些值是最新的。
删除以相同的方式处理，有效插入“反价值”或墓碑。该过程的局限性是可能需要大量的空间开销。删除实际上是'懒惰的，因此空间直到一段时间后才会被释放。此外，虽然压缩的输出可以与输入的大小相同，但是在新的SSTable完成之前不能删除旧的SSTable，因此这可以将磁盘利用率降低到50％。
在上述系统中，现有密钥的新值可以与现有密钥的大小不同，而不填充到某个预定长度，因为新值不会在更新时写入旧值，而是一个新的SSTable。