我将 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 是否更有意义？
最佳答案
很可能是的，但这里的细节很重要。
如果每个用户请求只有几个操作，那么并行发出小查询实际上可能更好。这将使您获得每个请求的最佳延迟，但会以集群的每个请求 CPU 开销为代价。您的应用程序代码也会更加复杂。
如果每个用户请求有很多操作，您肯定希望通过扫描获得更高的吞吐量效率。
对于高级用例，您还可以在两者之间做出折衷，并将扫描分成并行运行的 N 个分片，其中 N << #operations。
您绝对不应该做的一件事是一次发送一个小请求，因为您只会产生一堆不必要的往返!
关于go - BigTable:一个大查询还是一打小查询？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/57612508/