nosql - Cassandra SSTable 和压缩

Question

所以我正在研究 Cassandra 并试图了解其架构，并且我正在阅读 wiki 中的以下页面: http://wiki.apache.org/cassandra/MemtableSSTable

因此，为了遵循这里的工作流程，您发送一个更新表的请求，该请求被写入 CommitLog，然后写入称为 Memtable 的内存表(如果系统出现问题，可以从 Commitlog 重建该表)失败)。一旦 Memtable 达到一定大小，它会将整个 Memtable 刷新到磁盘上的 SSTable，该 SSTable 无法再修改，只能在压缩期间合并。当您达到可配置数量的 SSTable 时，您将进行压缩，这基本上会合并结果，释放磁盘空间并创建一个新的和改进的最新 SSTable。如果我理解有任何错误，请纠正我。

现在我有一些关于压缩的问题。首先，这个手术的费用是多少？如果每当光盘上有两个 SSTable 时我就要求进行压缩，这是否会令人望而却步，或者等到半夜使用量下降时我会得到更好的服务吗？如果我有多个(但很小)SSTable 与有几个但非常大的 SSTable 相比，压缩会更好吗？拥有大量未压缩的 SSTable 是否会影响读取性能？并发如何处理:如果我正在从这些 SSTable 中读取数据，然后有人执行插入操作，将新的 Memtable 刷新到磁盘，进而导致压缩，该怎么办？

您可以提供有关此的任何信息和经验，那就太好了!

Answer 1

尝试回答每个问题:

Firstly, how expensive is this operation?

压缩必须复制它正在压缩的 SSTable 中的所有内容(减去来自逻辑删除或覆盖的任何消灭)。然而，这比一开始看起来要便宜，因为压缩使用纯粹的顺序 IO，这在旋转磁盘上又好又快。

If I demanded a compaction whenever we have two SSTables on disc, would this be prohibitive, or would I be better served waiting until the middle of the night when usage is down?

这意味着您的写入成本将显着增加；假设每次写入都会导致一个新的 SSTable；因此，每次写入都必须压缩之前的所有写入。编写 N 个项目的成本将为 N^2。

一个更好的想法是采用类似于 Acunu 的倍增数组所使用的压缩策略:将每个 SSTable(又名数组)存储在一个“级别”中，并在一个级别中有两个数组时压缩它们，将输出数组提升为下一级。这可以证明每次写入分摊为 O((log N)/B) 顺序 IO，同时将数组数量限制为 O(log N)。

该方案在Cassandra 的(开源)存储引擎CaSTLe 中实现。欲了解更多信息，请参见此处:

• http://skillsmatter.com/podcast/nosql/castle-big-data
• http://www.acunu.com/blogs/tom-wilkie/castle-storage-engine-oscon/

注意，我为 Acunu 工作

Is compaction any better if I have multiple (but small) SSTables vs having a few but very large SSTables?

使用较小的 SSTable 进行压缩将花费更少的时间，但您必须执行更多操作。确实，这是以马换类(class)。然而，SSTable 的数量和大小确实会影响读取性能(请参阅下一个问题)

Does having a lot of non-compacted SSTables affect read performance?

对于点读取，不是很多:Cassandra(和 CaSTLe)具有布隆过滤器，以避免在知道键不存在时查找 SSTables，并且可以在找到正确的值时提前终止(通过使用时间戳)关于值和 SSTables)。

但是，使用 get_slice 查询时，您无法提前终止，因此您必须访问行中可能包含值的每个 SSTable - 因此，如果您有很多查询，您的 get_slices 将会变慢。

对于 get_range_slices 来说情况更糟，你不能使用布隆过滤器，并且每次调用都必须访问每个 SSTable。这些调用的性能将与您拥有的 SSTable 数量成反比。

更重要的是，对于数千个 SSTable，布隆过滤器误报率 (~1%) 将开始受到影响，因为每次查找时，您都必须在 10 个不包含该值的 SSTable 中查找!

How does concurrency work with this: what if I'm reading from these SSTables, then someone does an insert which flushes a new Memtable to disk, which in turn causes a compaction?

在 Cassandra 中，一旦内存中不再有对 SSTable 的引用(由垃圾收集器决定)，SSTable 就会从磁盘中删除。所以读取不需要担心，旧的 SSTable 会被懒惰地清除。

谢谢

汤姆