大表与大查询对timeseries数据的使用
我希望在大表和大查询上最后确定我对timeseries数据的使用。
我经历过https://cloud.google.com/bigtable/docs/schema-design-time-series
这是用于存储Omniture数据，其中包含网站访问者键(一些长键)、cookie id(一些长键)、时间戳系列数据( web点击)等信息，用于他的IP，cookie
什么可以作为大桌子的行键？我不能使用时间戳或CookieId作为前缀，因为我从最佳实践中学到了这一点。但是应该有一个标识符(最好是字母表？)然后是timeseries后缀。今天，SQL表中存储了52列，数据量为5亿。我认为数据可能是基于OLTP处理更新的。但该表稍后将被查询为诸如OLAP处理的timeseries数据。
( a)在这里，Big table是最好的选择吗?还是应该使用Big Query，因为稍后根据timeseries数据进行查询会对我更有帮助？( b)如果使用Big表，那么什么才是最好的行键，因为timeseries是我看到的数据的唯一意义筛选器。我相信，使用该表中的其他字段(如visitorkey )，作为带有时间戳的前缀的cookieid I(长I)仍然会导致整个数据填充Bigtable中的一个节点，而不是分发。
请让我知道。
回答 1
Stack Overflow用户
发布于 2018-09-19 14:12:07
(我是云大表团队的一名工程师)
正如您从我们的文档中发现的那样，行键格式是在使用Bigtable时做出的最大决定，因为它决定了哪些访问模式可以有效地执行。在时间戳听起来之前，使用visitorKey + cookie作为前缀可以避免热点问题，因为访问站点的访问者几乎肯定比集群中的节点多。Bigtable一直在为这些时间序列用例服务！
但是，您也来自SQL体系结构，它并不总是适合Bigtable的模式/查询模型。下面是一些让你开始的问题：
- 您是否计划执行许多特别的查询，如“从B=x的Bigtable中选择A”？如果是这样的话，那么非常喜欢BigQuery。如果不执行完整的表扫描，Bigtable无法支持此查询。一般来说，Bigtable更倾向于快速地将数据的一个简单子集流回数据流作业，而不是在查询本身中嵌入复杂的处理。
- 您需要多行OLTP事务吗？同样，请使用BigQuery，因为Bigtable只支持单行内的事务。
- 你是在高QPS播放新事件吗？Bigtable对于这些大容量的更新来说要好得多.记住，Bigtable最初的目的是作为Google搜索索引中web爬虫更新的随机访问池！
- 您想对数据执行任何大规模的复杂转换吗？同样，Bigtable在这里可能更好，因为您可以更快地将数据源源不断地流出来，并让Dataflow作业中的自定义业务逻辑做您想做的任何事情。
如果需要这些功能的某些组合，也可以将这两个服务组合在一起。例如，假设您一直在接收大量更新，但希望能够执行复杂的临时查询。如果您可以使用稍微延迟的数据版本，那么将更新写入Bigtable，然后使用Dataflow定期扫描表并将最新事件的后处理版本导出到BigQuery中可能是有意义的。GCP还允许BigQuery直接从某些区域的Bigtable中提供查询：https://cloud.google.com/bigquery/external-data-bigtable
https://stackoverflow.com/questions/52392904
复制相似问题
腾讯云开发者
