cassandra的物理磁盘空间管理

Question

最近，我一直在从我们的新项目的角度来看待Cassandra，并从这个社区和它的wiki中学到了很多东西。但是在物理磁盘空间管理方面，我没有发现关于如何在Cassandra中管理更新的任何信息，尽管它似乎与使用压缩的记录删除管理非常相似。

假设有100条记录与5个值的每一个，所以当所有的改变将被刷新磁盘中的所有记录将被相邻的书面当删除操作完成那么它标志着存储表第一和物理记录一些时间后删除在配置中设置或完全设置。压实过程要求空间。

现在的问题是，在一侧是模式较少有列没有固定数量的开始，但在另一边时，压实过程中发生的话..它提出了相邻的记录在磁盘上像传统的RDBMS速度读取过程与RDBMS一样简单，因为它们必须根据列数据类型的声明分配固定的空间量。

但是，Cassandra如何在压缩过程中精确地将记录放置在磁盘上（用于更新/删除）以加快读取速度？

还有一个与压缩相关的问题是，如果没有删除查询，但有一个更新查询用一些可变长度数据更新一个存在的记录，或者全部插入一个新列，那么压缩如何使它在磁盘上的空间可用已经存在的数据行？

Answer 1

行和列按照排序顺序存储在SSTable中。这允许压缩多个SSTable以输出新的（排序的）SSTable，只有顺序磁盘IO。这个新的SSTable将被输出到磁盘上的新文件和可用空间中。这个过程不依赖于列的行数，只是按照排序顺序存储。所以是的，在所有的SSTables（即使是那些形成压缩的行）中，行和列将按照排序顺序排列在磁盘上。当你在你的问题中提示时，更新与插入没有什么不同 - 它们不会覆盖磁盘上的值，而是被缓存在Memtable中，然后刷新到新的SSTable中。当新的SSTable最终与包含原始值的SSTable进行压缩时，新值将湮灭旧值 - 即旧值不会从压缩中输出。时间戳用于确定哪些值是最新的。

删除以相同的方式处理，有效地插入了“反值”或逻辑删除。这个过程的局限性是需要大量的空间开销。删除实际上是“懒惰的”，所以空间在一段时间后才会被释放。另外，虽然压缩的输出可以与输入大小相同，但在完成新的SSTable之前，无法删除旧的SSTable，因此可以将磁盘利用率降低至50％。

在该系统中如上所述，新值现有的密钥可以是不同的尺寸与现有的键，但不填充到一些预先确定的长度，作为新的值不被写入在上更新的旧值，但到一个新的SSTable。