go - BigTable:一个大查询还是一打小查询？

Question

我将 event 系列存储在 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"
}

所以你可以说一个operation是一个event的时间窗口，并且可能关联到10-1000个event。

当我想向用户显示此数据时，我首先查询 operation 对象，然后为每个 operation 执行 BigTable 查询以找到 >它涵盖的事件。

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

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

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

Answer 1

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

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

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

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

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