BigTable：一个复杂查询还是数个简单查询？

在 Bigtable 中存储时间范围事件时，选择单个复杂查询还是多个简单查询对于性能至关重要。复杂查询效率更高，但并行执行多个简单查询在用户请求操作较少时可能带来更好的延迟。权衡两种方法的关键在于每个请求中操作的数量，对于大量操作，扫描可以提高吞吐量效率。折衷方案包括将扫描分成并行运行的分片，以在延迟和吞吐量之间取得平衡。

我将一系列 events 存储在 bigtable 中，格式为：

rowkey                | col_1 | col_2
----------------------|-------|------
uuid1!uuid2!timestamp | val1  | val2
....

col_1 保存一个 float64，col_2 保存一个 63 个字符长的字符串。

这一系列 event 中的特定范围被分组并与我们称为 operation 的对象松散关联：

{
    "id": 123,
    "startDate": "2019-07-15T14:02:12.335+02:00",
    "endDate": "2019-07-15T14:02:16.335+02:00"
}

所以你可能会说，操作是events的时间窗口，并且可能与10-1000个events相关联。

当我想要向用户显示此数据时，我首先查询 operation 对象，然后对每个 operation 执行 bigtable 查询以查找它覆盖的 event。

通过监控，我发现每个 bigtable（请注意，一个开发实例）查询可能需要 20 毫秒到 300 毫秒。

这让我想知道，考虑到 bigtable 的架构 - 执行小型的单独查询是否有意义？

执行一个涵盖我的 operations 范围的大型查询，然后将事件划分到我的应用程序中各自的 operations 是否更有意义？

解决方案

很可能是的，但细节很重要。

如果每个用户请求只有几个操作，那么并行发出小查询实际上可能会更好。这将为您带来每个请求的最佳延迟，但代价是集群会产生一些每个请求的 CPU 开销。您的应用程序代码也会更加复杂。

如果每个用户请求有大量操作，您肯定会希望通过扫描获得更高的吞吐量效率。

对于高级用例，您还可以在两者之间进行折衷，并将扫描分成并行运行的 N 个分片，其中 N << #operations。

您绝对不应该做的一件事是一次发送一个小请求，因为您只会产生一堆不必要的往返！

本篇关于《BigTable：一个复杂查询还是数个简单查询？》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！