1

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

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

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

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

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

4

1 回答 1

2

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

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

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

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

于 2019-01-22T19:15:01.050 回答