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

【问题标题】：BigTable: One large query or a dozen small queries?BigTable：一个大查询还是十几个小查询？
【发布时间】：2019-12-27 23:09:59
【问题描述】：

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

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

col_1 包含一个 float64，col_2 包含一个 63 个字符长的字符串。

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

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

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

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

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

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

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

【问题讨论】：

【解决方案1】：

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

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

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

对于高级用例，您还可以在两者之间妥协，将扫描分成 N 个并行运行的分片，其中 N

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

【讨论】：

伟大而明确的答案，If there are lots of operations per user request 有什么大致数字吗？
这在一定程度上取决于您的延迟要求有多严格。我会先看看你是否对单次扫描获得的性能感到满意，因为这是最简单的方法。但一个不错的经验法则是，超过 10 个并行请求会出现收益递减，因为尾部延迟很快就会被最慢的请求所支配。