google-compute-engine - 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内部结构的这个问题的 future 读者的脚注:您可以将整个表垂直划分为locality group，将locality group划分为列族，将列族划分为列，水平划分为tablets , 其中包含行。每个位置组基本上都像引擎盖下的独立大表一样运行，但是在云 BT 中，您的所有家庭都在一个 LG 中，因此这种抽象级别没有多大意义。水平拆分为平板电脑是动态完成的有规律的间隔，为了避免tablets的热点，所以单个tablet可以小到一行，大到几百万。日志文件系统:有一个最近写入的日志文件(基本上就是“行，列，值”元组)。每一个小的压缩间隔，一个新的日志文件被启动，之前的日志文件被转换成一个 SSTable，它是一个文件存储从字符串到字符串的排序映射以进行高效读取。每一个主要的压缩间隔，所有的 SSTable 都被组合成一个 SSTable。因此，对 BT 的单次写入只是对日志的追加，而读取必须检查当前存在的所有 SSTable，以及日志文件。因此，如果您在平板电脑上写入大量内容，则读取速度会变慢。

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

Answer 1

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

Store data you will access in a single query in a single column family.
Column qualifiers in a single column family have a physical as well as a logical relationship. In general, all of the column qualifiers in a single column family are stored together, accessed together and cached together. As a result, a query that accesses a single column family might execute more efficiently than a query spanning column families.

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