大表与大查询用于时间序列数据

Ros*_*ndo 4 bigtable google-bigquery google-cloud-bigtable

我希望最终确定Big table vs Big Query以获取我的时间序列数据.

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

这是用于存储Omniture数据,其中包含网站访问者密钥(一些Long密钥),他的cookie id(一些Long密钥),他的IP的时间戳系列数据web命中,cookie等信息

什么可以用作Big table的rowkey?我不能使用时间戳或CookieId作为前缀,因为我从最佳实践中学习.但是应该有一个标识符(最好是字母?),然后是时间序列后缀.数据量为5亿,今天在SQL表中存储了52列.我认为数据可能会根据OLTP处理进行更新.但是稍后会在时间序列数据上查询该表以进行类似的OLAP处理.

a)Big table在这里是最好的选择,还是我应该使用Big Query,因为稍后根据时间序列数据查询会对我有所帮助?b)如果使用Big table,那么最好的行键是什么,因为timeseries是我看到的唯一意义过滤器.我相信,使用表中的其他字段,如visitorkey,cookieid ID(Long ids)作为带时间戳的前缀仍然会导致整个数据填满Bigtable中的1个节点,而不是分发.

请告诉我.

Dou*_*ean 8

(我是Cloud Bigtable团队的工程师)

正如您从我们的文档中发现的那样,行键格式是您在使用Bigtable时做出的最大决定,因为它决定了哪些访问模式可以有效执行.在时间戳之前使用visitorKey + cookie作为前缀听起来像是可以避免热点问题,因为您的站点访问者几乎肯定会比群集中的节点多.Bigtable一直为这些时间序列用例提供服务!

但是,您也来自SQL体系结构,这并不总是适合Bigtable的模式/查询模型.所以这里有一些问题可以帮助您入门:

  • 您是否计划执行大量即席查询,例如"SELECT A FROM Bigtable WHERE B = x"?如果是这样,非常喜欢BigQuery.如果不执行全表扫描,Bigtable无法支持此查询.而在一般的Bigtable,比较适合流回数据的简单子集快速,比方说,以数据流的工作,而不是在查询本身嵌入复杂的处理.
  • 您需要多行OLTP交易吗?同样,使用BigQuery,因为Bigtable仅支持单行内的事务.
  • 您是否在高QPS的新活动中流媒体?对于这些高容量更新,Bigtable要好得多.请记住,Bigtable的最初目的是作为Google搜索索引中网络抓取工具更新的随机访问接收器!
  • 您想对数据执行任何类型的大规模复杂转换吗?同样,Bigtable在这里可能更好,因为您可以更快地流出数据并让数据流作业中的自定义业务逻辑执行您想要的任何操作.

如果您需要这些功能的某些组合,也可以组合这两种服务.例如,假设您一直在接收大量更新,但希望能够执行复杂的即席查询.如果你正好处理稍微延迟的数据版本,那么将更新写入Bigtable是有意义的,然后使用Dataflow定期扫描表格并将最新事件的后处理版本导出到BigQuery中.GCP也允许的BigQuery到在一些地区从Bigtable的发球直接查询:https://cloud.google.com/bigquery/external-data-bigtable

  • 由于即席查询和连接,BigQuery听起来像是适合您工作负载的工具.关于Bigtable中热点的未来参考,我们担心的是我们不希望所有传入的写入都达到相同的行范围,因为负载不能分散在服务器上.使用时间戳(尤其是细粒度时间戳)为行键添加前缀是此反模式的典型示例.以visitorKey + cookie +时间戳为键,有|| visitorKey + cookie || 单独的行范围在任何给定的时间戳接收更新,因此可以跨多个服务器拆分它们. (3认同)
  • 基于不同列的临时查询,没有多行OLTP事务,没有流式传输新事件。一天的某些部分可能会有更多插入内容。将基于时间戳数据-每天或某天到某天之间进行查询。将进行一些转换并加入。查看带有日期分区的Big查询。请确认。请进一步说明热点。与仅在BT中添加时间戳相比,visitorKey + Cookie +时间戳如何避免热点?我认为给定这种组合,我无法基于特定的行键进行过滤。 (2认同)