Google Bigtable vs BigQuery用于存储大量事件

背景

我们希望将不可变事件存储在(最好)托管服务中.一个事件的平均大小小于1 Kb,我们每秒有1-5个事件.存储这些事件的主要原因是,一旦我们创建可能对这些事件感兴趣的未来服务,就能够重放它们(可能使用表扫描).由于我们在谷歌云中,我们显然将谷歌的服务视为首选.

我怀疑Bigtable非常适合这个,但根据价格计算器,我们每月花费超过1400美元(这对我们来说是一个大问题):

看看像BigQuery这样的东西每月3美元的价格(如果我没有遗漏必要的东西):

即使无模式数据库更适合我们,我们也可以将事件存储为带有一些元数据的blob.

问题

我们可以使用BigQuery而不是Bigtable来降低成本吗？例如,BigQuery有一些称为流插入的东西,对我来说似乎是我们可以使用的东西.有什么东西会在短期或长期内咬我们,如果走这条路线我可能不会意识到这一点吗？

Bigtable非常适合大型(> = 1TB)可变数据集.它在负载下具有低延迟,由Google管理.在您的情况下,我认为您使用BigQuery正在走上正轨.

FYI

Cloud Bigtable不是关系数据库; 它不支持SQL查询或连接,也不支持多行事务.此外,它不适用于少量数据(<1 TB).

请考虑以下情况: - 如果您需要对联机事务处理(OLTP)系统提供完整的SQL支持,请考虑使用Google Cloud SQL.

如果您需要在线分析处理(OLAP)系统中进行交互式查询,请考虑使用Google BigQuery.

如果您需要存储大于10 MB的不可变blob,例如大图像或电影,请考虑使用Google Cloud Storage.

如果需要存储高度结构化的对象,或者需要支持ACID事务和类似SQL的查询,请考虑使用Cloud Datastore.

在整体成本归结为您将"查询"的数据多久.如果它是一个备份而你不经常重播事件,它将是便宜的.但是,如果您需要每天重播一次,则开始轻松触发5 $/TB扫描.我们也很惊讶插入和存储的价格是多么便宜,但这是因为谷歌希望你在某个时间点运行昂贵的查询.你必须围绕一些事情进行设计.例如,AFAIK流媒体插入没有写入表格的保证,你必须经常在列表的尾部轮询,看看它是否真的被写入.可以使用时间范围表装饰器有效地完成拖尾(不支付扫描整个数据集).

如果您不关心订单,您甚至可以免费列出一张桌子.然后不需要运行'查询'.