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