大表与大查询用例的时序数据

Question

我正在为我的时间序列数据用例确定Big Table vs Big Query。

我经历了https://cloud.google.com/bigtable/docs/schema-design-time-series

这是用于存储Omniture数据的信息，其中包含诸如网站访问者密钥（某些长键），他的cookie ID（某些长键），其IP，cookie的时间戳系列数据网络匹配之类的信息

什么可以用作Big table的行键？我不能从最佳实践中了解到时间戳或CookieId作为前缀。但是应该有一个标识符（最好是字母？），然后加上时间序列后缀。今天的数据量为5亿，其中52列存储在SQL表中。我认为数据可能会基于OLTP处理进行更新。但是稍后会在时间序列数据上查询该表，以进行OLAP处理。

a）在这里，大表会是最好的选择吗？还是我应该使用大查询，因为仅根据时间序列数据进行查询会为我提供更多帮助吗？ b）如果使用Big table，那么最好的行键是什么，因为时间序列是我看到的唯一筛选数据的含义。我相信，使用表中的其他字段（如visitorkey，cookieid id（长ID））作为带有时间戳的前缀仍会导致整个数据填充Bigtable中的1个节点，而不是进行分配。

请让我知道。

Answer 1

（我是Cloud Bigtable团队的工程师）

正如您从我们的文档中发现的那样，行键格式是您使用Bigtable时做出的最大决定，因为它决定了可以有效执行的访问模式。在时间戳记出现之前，先使用visitorKey + cookie作为前缀，这样可以避免出现热点问题，因为几乎可以肯定，与站点中的节点相比，您网站的访问者要多得多。 Bigtable始终为此类时间序列用例提供服务！

但是，您也来自SQL体系结构，它并不总是适合Bigtable的架构/查询模型。因此，这里有一些问题可以帮助您入门：

• 您是否打算执行很多临时查询，例如“从Bigtable WHERE B = x中选择SELECT”？如果是这样，强烈建议使用BigQuery。如果不执行全表扫描，Bigtable将无法支持此查询。通常，Bigtable的目标是更快速地将简单的数据子集流回数据流，例如流向Dataflow作业，而不是将复杂的处理嵌入查询本身中。
• 您将需要多行OLTP事务吗？再次使用BigQuery，因为Bigtable仅支持单行内的事务。
• 您是否正在以高QPS直播新事件？对于这类大批量更新，Bigtable更好。请记住，Bigtable的最初目的是作为Google搜索索引中网络抓取工具更新的随机访问接收器！
• 您要对数据执行任何形式的大规模复杂转换吗？同样，Bigtable在这里可能会更好，因为您可以更快地将数据流式传输和返回，并让Dataflow作业中的自定义业务逻辑执行您想要的任何操作。

如果需要这些功能的某种组合，也可以将两种服务组合在一起。例如，假设您一直在接收大量更新，但希望能够执行复杂的临时查询。如果您使用的是稍有延迟的数据版本，则可以将更新写入Bigtable，然后使用Dataflow定期扫描表，并将最新事件的后处理版本导出到BigQuery中。 GCP还允许BigQuery在某些区域直接从Bigtable服务查询：https://cloud.google.com/bigquery/external-data-bigtable