Google Cloud Bigtable 的性能调优技巧

Question

我正在使用 BT 表的集合来存储用于批处理和实时操作的数据，并且希望优化性能，尤其是在随机访问读取的延迟方面。虽然我确实非常了解底层 BT 代码库，但我不知道所有这些如何转化为 Cloud Bigtable 的最佳实践，这与底层代码完全相同。所以我有一些问题要问专家：

(1) 我在其他问题中发现 Cloud BT 将所有列族存储在一个位置组中。由于我经常需要在一行中读取多个列族的数据，这非常适合我的需求……但我注意到在读取 N CF 而不是操作中的一个 CF 时速度明显减慢。在这种情况下，每个单元都很小（~1kB）并且被读取的单元总数并不大，所以我不认为这会受到网络延迟、瓶颈等的支配；并且单元格没有被写入锤击，所以我不期待不受控制的未压缩日志。但是：

• 对于这种类型的读取模式是否有任何一般性能提示？
• 云 BT 中使用的主要和次要压缩间隔是什么？这些是可调的吗？

(2) 读取 API 确实接受读取请求中的稀疏行集。这些在幕后发生了多少优化？我在实例中是否有一些云 BT 服务器正在跨平板服务器并行这些底层操作，或者云 BT API 是否直接进入平板服务器？ （也就是说，使用这个 API 确实比使用 for 循环更高效吗？）

(3) 相关，我正在使用 Python 客户端库。关于它的操作并行化，或者它的可并行性，有什么需要了解的吗？例如，从多个线程中使用它的任何问题？

(4) 关于如何让随机读取尖叫，我还应该知道什么？

（对于不了解 BT 内部结构的未来读者的脚注：您可以将整个表视为垂直划分为位置组，将位置组划分为列族，将列族划分为列，以及水平分成包含行的平板电脑。每个地区组基本上就像一个独立的大表一样运作，但在云 BT 中，你所有的家庭都在一个 LG 中，所以这种抽象级别没有多大意义。平板电脑的水平拆分是定期动态完成，以避免平板电脑热点，因此单个平板电脑可能小至一行或大至数百万。在表格的每个 (locality group) * (tablet) 矩形内，数据存储在日志文件系统的风格：有一个最近写入的日志文件（基本上只是“行、列、值”元组）。每个小的压缩间隔，都会启动一个新的日志文件，并将之前的日志文件转换为 SSTable ，这是一个文件at 存储从字符串到字符串的排序映射，以实现高效读取。每个主要的压缩间隔，所有的 SSTable 都被组合成一个 SSTable。因此，对 BT 的单次写入只是对日志的附加，而读取必须检查当前存在的所有 SSTable 以及日志文件。因此，如果您在平板电脑上写入大量内容，则在平板电脑上读取会变慢。

SSTables 实际上有多种线路格式，这些格式针对各种访问模式进行了优化，例如从旋转磁盘随机访问、批量访问等，因此根据这些详细信息，读取其中一个可能需要 1-3 iops 对底层存储系统，一般是分布式磁盘。）

Answer 1

你问了很多问题 :) 我可以就 (1) 给出一个提示。 The documentation 提到

将您将在单个查询中访问的数据存储在单个列族中。
单个列族中的列限定符具有物理和 一种逻辑关系。通常，一个列中的所有限定符 单个列族存储在一起，一起访问和缓存 一起。因此，访问单个列族的查询 可能比跨列族的查询更有效地执行。

这似乎符合您的经验。因此，如果您能够将数据分组到单个 CF 中，它可能会帮助您缩短阅读时间。

Answer 2

这里有很多子问题，因此将它们分解为单独的问题可能会得到更好的结果。同时尝试回答其中的一些问题：

1. Cloud Bigtable 的次要和主要压缩间隔未发布，因为它们可能会发生变化。基于当前的GC Documentation，垃圾收集（主要压缩）将在一周内发生。如Compactions Documentation 中所述，这些设置不是用户可配置的。

2. Cloud Bigtable 端没有读取并行化。您将通过在客户端中进行并行化获得更好的性能。

3. 我对 Python 客户端并不太熟悉，所以我会让其他人参与进来。但请注意，与其他 GA 客户端相比，它处于 Beta 阶段，后者将对其进行更多的性能调整。

4. 经过深思熟虑的Schema Design 是确保牌桌持续性能的最佳选择。此外，使用Key Visualizer 可有效诊断出现的任何性能问题，例如热点。