用于存储大量事件的 Google Bigtable 与 BigQuery答案

【问题标题】：Google Bigtable vs BigQuery for storing large number of events用于存储大量事件的 Google Bigtable 与 BigQuery
【发布时间】：2016-03-30 00:00:25
【问题描述】：

背景

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

我怀疑Bigtable 很适合这个，但根据price calculator，我们每月要花费超过 1400 美元（这对我们来说是一笔大交易）：

查看BigQuery 之类的内容会显示每月 3 美元的价格（如果我没有错过重要的东西的话）：

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

问题

我们是否可以为此使用 BigQuery 而不是 Bigtable 来降低成本？例如，BigQuery 有一个名为 streaming inserts 的东西，在我看来，我们可以使用它。如果沿着这条路线走下去，我可能不知道有什么会在短期或长期影响我们的事情吗？

【问题讨论】：

你没有错过必需品，BQ 非常“便宜”。
BigQuery 针对长期存储和分析进行了优化，BigTable 针对在线应用的大量使用进行了优化
不确定，但在操作方面可能会受到限制。例如，认为您每天只能将 1k 附加到一张表中（这是我不久前达到的一个 BQ api 限制）。虽然我认为流式 API 更宽容。只是可能是另一个需要考虑的维度。

标签： google-app-engine google-bigquery bigtable google-cloud-bigtable

【解决方案1】：

Bigtable 是一个分布式（在集群上运行）数据库，适用于管理海量数据的应用程序。它专为海量非结构化数据而设计，可水平扩展并由列族组成。它将数据存储在键值对中，而不是关系数据库或结构化数据库。

BigQuery 是一个数据仓库应用程序。这意味着它提供了与多个数据源或流的连接，以便可以将它们提取、转换并加载到 bigQuery 表中以进行进一步分析。与 Bigtable 不同的是，它确实将数据存储在结构化表中，并支持 SQL 查询。

用例；如果您想通过从您组织的不同来源（应用程序、研究、调查、反馈、日志等）收集的数据中获得洞察力来进行分析或商业智能，您可能希望将所有这些信息集中到一个位置。该位置很可能是 Bigquery 数据仓库。

如果您有一个收集大数据的应用程序，换句话说，每次以更高的速度（高速）收集海量信息（高数据量），并且以具有不同数据类型（如音频、文本、视频、图像）的非结构化不一致形式，等等...（多样性和准确性），那么您可能选择的此应用程序的数据库应用程序将是 Bigtable。

【讨论】：

【解决方案2】：

此流程图可能有助于在不同的 Google 云存储产品之间做出决定（免责声明！此图片来自 Google 云页面）

如果您的用例是一个实时数据库（比方说，一个网站的后端），BigTable 就是您所需要的（但它不是真的是一个 OLTP 系统虽然）。如果它更像是一种数据分析/数据仓库类型的用途，那么 BigQuery 就是您所需要的。

想想 OLTP 与 OLAP；或者如果你熟悉 Cassandra 和 Hadoop，BigTable 大致相当于 Cassandra，BigQuery 大致相当于 Hadoop（同意，不是一个公平的比较，但你明白了）

https://cloud.google.com/images/storage-options/flowchart.svg

请记住，Bigtable 不是关系数据库，它是没有任何 SQL 功能（如 JOIN 等）的 noSQL 解决方案。如果您想要 RDBMS OLTP，您可能需要查看 cloudSQL (mysql/ postgres) 或 spanner。

Cloud spanner相对年轻，但功能强大且前景广阔。至少，谷歌营销声称它的功能是两全其美（传统 RDBMS 和 noSQL）

成本方面

这里已经很好地涵盖了成本方面https://stackoverflow.com/a/34845073/6785908

我知道这是一个很晚的答案，但无论如何添加它以防将来可能对其他人有所帮助。

【讨论】：

【解决方案3】：

比already done by Google 更难概括。

我认为您需要弄清楚您将如何使用（重放）您的数据（事件），这可以帮助您做出最终决定。

到目前为止，BigQuery 似乎是您的最佳选择

【讨论】：

【解决方案4】：

仅供参考

Cloud Bigtable 不是关系型数据库；它不支持 SQL 查询或连接，也不支持多行事务。此外，对于少量数据（

考虑以下情况： - 如果您需要完整的 SQL 支持以进行在线事务处理 (OLTP) 系统，请考虑 Google Cloud SQL。

如果您需要在线分析处理中的交互式查询 (OLAP) 系统，请考虑 Google BigQuery。

如果您需要存储大于 10 MB 的不可变 blob，例如大图片或电影，请考虑 Google Cloud Storage。

如果您需要存储高度结构化的对象，或者如果您需要支持 ACID 事务和类似 SQL 的查询，考虑 Cloud 数据存储。

【讨论】：

【解决方案5】：

总成本归结为您“查询”数据的频率。如果它是备份并且您不经常重播事件，那么它将非常便宜。但是，如果您需要每天重播一次，您开始触发 5$/TB 扫描太容易了。我们也对插入和存储的便宜程度感到惊讶，但这是因为谷歌希望您在某个时间点对它们运行昂贵的查询。不过，您必须围绕一些事情进行设计。例如。 AFAIK 流插入没有被写入表的保证，您必须经常轮询列表尾部以查看它是否真的被写入。不过，使用时间范围表装饰器可以有效地完成拖尾（无需支付扫描整个数据集的费用）。

如果您不关心订单，您甚至可以免费列出一张桌子。那么就不需要运行“查询”了。

【讨论】：

【解决方案6】：

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

【讨论】：