BigTable：一个大查询还是十几个小查询？

Question

我将一系列events 存储在 BigTable 中，格式如下：

rowKey                | col_1 | col_2

----------------------|-------|------

uuid1!uuid2!timestamp | val1  | val2

....

col_1保存 afloat64并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"

}

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

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

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

这让我想知道，鉴于 BigTable 的架构 - 执行小型的单独查询是否有意义？

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

Answer 1

很可能是的，但细节在这里很重要。如果每个用户请求只有几个操作，那么并行发出小查询实际上可能更好。这将为您带来每个请求的最佳延迟，但代价是集群会产生一些每个请求的 CPU 开销。您的应用程序代码也会更加复杂。如果每个用户请求有大量操作，您肯定会希望通过扫描获得更高的吞吐量效率。对于高级用例，您还可以在两者之间进行折衷，并将扫描分成并行运行的 N 个分片，其中 N << #operations。您绝对不应该做的一件事是一次发送一个小请求，因为您只会产生一堆不必要的往返！