Google BigTable是一个使用LSM树作为其核心数据结构进行存储的系统。 LSM树可以使用不同的合并策略。最常见的两个是（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）。
结果，这些方案具有不同的读/写性能属性。但是，我无法找到有关Google BigTable是使用分层合并还是分层合并的信息，默认大小比率T是多少？另外，系统的这些方面是否固定，还是可调的？
答案 0 :(得分：2)
尽管支持Cloud Bigtable产品的基础系统是动态的，并且由我们的工程和运营团队调整，但最终用户目前无法通过Cloud Bigtable API调整Google Cloud Bigtable使用的合并压缩行为和策略。
这是有关Bigcomp中探索的合并压缩算法的不同方法的最新文章：
在线Bigtable合并压缩 https://arxiv.org/pdf/1407.3008.pdf
我们采用了许多专有方法来动态调整和调整合并压缩行为。如果您确实有与系统使用相关的更具体的问题，或者遇到合并压缩行为方面的问题，那么您当然可以随时提出支持案例。