我正在使用BT表的集合来存储用于批处理和实时操作的数据，并且想要优化性能，尤其是在随机访问读取的等待时间附近。尽管我确实非常了解底层BT代码库，但是我不知道所有这些如何转化为Cloud Bigtable的最佳实践，而后者与底层代码完全不同。所以我对专家有一些疑问：
（1）在其他问题中，我发现Cloud BT将所有列族存储在一个位置组中。由于我经常必须从一行中读取多个列族的数据，因此这非常适合我的需求...但是我注意到在读取N CF而不是在操作中读取一个CF时，速度显着下降。在这种情况下，每个单元很小（〜1kB），并且正在读取的单元总数也不大，因此，我不希望这受网络延迟，瓶颈等因素的支配。而且单元不会因写入而受到影响，因此我不希望出现不受控制的紧凑日志。但是：
（2）读取API确实在读取请求中接受行的稀疏集合。这些在后台进行了多少优化？我是否在实例中找到一些正在使Tablet PC上的这些底层操作并行化的Cloud BT Server，或者Cloud BT API是否直接进入了Tablet Server？ （这是说，使用此API确实比进行循环更有效吗？）
（3）相关，我正在使用Python客户端库。关于操作的并行化或可并行性，是否有任何要了解的东西-例如，从多个线程使用它的任何陷阱？
（4）关于如何使随机读取声尖叫我应该知道的其他事情吗？
（为这个问题的未来读者提供的注脚，他们不了解BT的内在知识：您可以将整个表格垂直划分为位置组，将位置组划分为列族，将列族划分为列，并且每个地区组基本上都像一个独立的大表一样在幕后运作，但是在BT云中，您的所有家庭都在一个LG中，因此这种抽象水平意义不大。为了避免平板电脑出现热点，每隔一定时间动态地进行一次操作，因此单个平板电脑可以小到一行，也可以大到几百万个。在表格的每个（位置组）*（平板电脑）矩形内，数据存储在日志文件系统的样式：有一个最近写入的日志文件（基本上只是“行，列，值”元组）。每个较小的压缩间隔，都会启动一个新的日志文件，并将先前的日志文件转换为SSTable ，这是一个文件at存储从字符串到字符串的排序映射，以实现高效读取。在每个主要的压缩间隔中，所有SSTable都合并为一个SSTable。因此，对BT的一次写操作只是对日志的追加，而读操作必须检查当前存在的所有SSTables以及日志文件。因此，如果您要在平板电脑上写很多东西，那么在平板电脑上阅读的速度就会变慢。
SSTable实际上具有多种连线格式，这些格式针对各种访问模式进行了优化，例如来自旋转磁盘的随机访问，批处理访问等，因此根据这些详细信息，读取其中之一可能需要1-3 iops的底层操作。存储系统，通常是分布式磁盘。）
答案 0 :(得分：2)
您提出了很多问题：)我可以给（1）提示。 The documentation提到
存储您将在单个列系列的单个查询中访问的数据。
单个列族中的列限定符既具有物理属性又具有物理属性 逻辑关系。一般而言， 单列族一起存储，一起访问和缓存 一起。结果，访问单个列族的查询 可能比跨越列族的查询更有效地执行。
这似乎与您的体验一致。因此，如果您能够将数据分组到单个CF中，则可能会帮助您缩短读取时间。
答案 1 :(得分：1)
其中有很多子问题，因此将它们分解为单独的问题可能会有更好的结果。同时尝试回答其中的一些问题：
Cloud Bigtable的次要和主要压缩间隔未发布，因为它们可能会更改。根据当前的GC Documentation，一周之内将进行垃圾收集（重大压缩）。如Compactions Documentation中所述，这些设置不是用户可配置的。
在Cloud Bigtable端没有读取并行化。通过在客户端中并行化，您将获得更好的性能。
我对Python客户端不是很熟悉，所以我会让其他人对此感到满意。但是请注意，与其他GA客户端相比，它处于Beta版，后者将对其进行更多性能调整。
经过深思熟虑的Schema Design是确保表格持续表现的最佳选择。此外，使用Key Visualizer可有效地诊断出现的任何性能问题，例如热点。