BigTable使用分层的还是水平的LSM-tree压缩？

Question

Google BigTable是一个使用LSM-tree作为其存储核心数据结构的系统。LSM-tree可以使用不同的合并策略。最常见的两种合并是(1)读优化程度更高的分层合并，以及(2)写优化程度更高的分层合并。可以通过调整相邻级别之间的大小比例来进一步配置这些合并策略。

我在任何地方都找不到BigTable在这些方面的默认行为，以及它是否可以调优。因此，很难理解它的默认性能属性以及如何使其适应不同的工作负载。

使用分层合并时，一定级别的LSM树收集会一直运行，直到达到容量为止。然后，它合并这些运行，并将结果运行刷新到下一个更大的级别。每个级别最多运行O(T * log_T(N))次，写成本为O(log_T(N) / B)，其中N是数据大小，B是块大小，T是级别之间的大小比率。

使用分层合并，在LSM树的每个级别上都有一次运行。一旦新的运行进入级别，合并就会发生，如果级别超过容量，则结果运行将刷新到下一个更大的级别。每级最多运行O(log_T(N))次，写开销为O((T * log_T(N)) / B)。

因此，这些方案具有不同的读/写性能属性。然而，我一直无法找到关于谷歌的BigTable使用分层合并还是分层合并的消息来源，以及默认大小比率T是多少？另外，系统的这些方面是固定的，还是可以调整的？

Answer 1

Google Cloud Bigtable使用的合并压缩行为和策略目前不能由最终用户通过Cloud Bigtable API进行调整，尽管支持Cloud Bigtable产品的底层系统是动态的，并且可以由我们的工程和运营团队进行调整。

这是最近一篇关于合并压缩算法的不同方法的论文，这些算法已经在Bigtable中进行了探索：

在线Bigtable合并压缩https://arxiv.org/pdf/1407.3008.pdf

我们采用了许多专有方法来动态调整和调优合并压缩行为。如果您确实有与系统使用相关的更具体的问题，或者遇到合并压缩行为的问题，您当然可以随时提交支持案例。