的性能优化技巧

Question

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

(1)我在其他问题中发现，Cloud将所有列族存储在一个地区组中。由于我经常要在一行中读取来自多列家族的数据，这对我的需求来说是很好的.但我注意到，在一次操作中阅读N而不是一个CF时，会出现明显的减速。在这种情况下，每个单元格都很小(~1kB)，被读取的单元格总数也不多，所以我不认为这会被网络延迟、瓶颈等占据主导地位；而且这些单元格也不会受到写操作的影响，所以我不期望有一个不受控制的非压缩日志。但是：

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

(2) read确实接受读取请求中的稀疏行集。这些引擎盖下发生了多少优化？有什么云BT服务器是我在实例中碰到的，它正在跨tabletservers并行这些底层操作，还是云BT直接进入了tabletservers？(也就是说，使用这个API确实比循环更有效吗？)

(3)与此相关的是，我使用的是Python客户机库。对于其操作的并行化或可并行性，有什么需要了解的吗?例如，从多个线程中使用它有什么问题吗？

(4)关于如何随机读取尖叫声，我还有什么要知道的吗？

(对于不了解BT内部的未来读者来说，脚注:您可以将整个表看作是垂直划分为局部组，局部性组分为列族，列族分为列，以及水平划分为包含行的平板。每个本地组基本上像一个独立的bigtable在引擎盖下运行，但是在云BT中，所有的家庭都在一个LG中，所以这个抽象级别并不意味着什么。水平分割成药片是动态的间隔，以避免热点的片剂，因此单一的平板可能是小到一行或大到数百万。在表的每个(locality组)* (tablet)矩形中，数据以日志文件系统的形式存储:有一个最近写入的日志文件(基本上只有“行、列、值”元组)。每隔一段较小的压缩间隔，就会启动一个新的日志文件，并将前一个日志文件转换为一个SSTable，该文件存储从字符串到字符串的排序映射，以便高效读取。每个主要的压缩间隔，所有的SSTables组合成一个单一的SSTable。因此，对BT的一次写入只是对日志的附加，读取必须检查当前存在的所有SSTables，再加上日志文件。因此，如果你给平板电脑写了很多东西，它的读取速度就会变慢。

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

Answer 1

这里面有很多子问题，所以你可能会有更好的结果，把它们分解成不同的问题。同时，试图回答其中的一些问题：

1. Cloud的次要和主要压缩间隔未发布，因为它们可能会更改。基于当前的GC文档，垃圾收集(主要压缩)将在一周内完成。正如在压缩文档中所指出的，这些设置不是用户可配置的。
2. Cloud端没有读取并行化。通过在客户端中并行化，您将获得更好的性能。
3. 我不太熟悉Python客户端，所以我会让其他人参与进来。但是请注意，与其他GA客户端相比，它在Beta中进行了更多的性能优化。
4. 经过深思熟虑的图式设计是确保表的持续性能的最佳选择。此外，使用键可视化器可以有效地诊断出现的任何性能问题，例如热点。

Answer 2

你问了很多问题:)我可以给(1)个提示。文献资料提到

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

这似乎和你的经历是一致的。因此，如果您能够将数据分组到一个CF中，那么它可能会帮助您的读取时间。