Google Cloud SQL vs Cloud DataStore vs BigTable vs BigQuery vs Spanner

Google Cloud SQL vs Cloud DataStore vs BigTable vs BigQuery vs Spanner

Google Cloud SQL vs Cloud DataStore vs BigTable vs BigQuery vs Spanner

很多人都熟悉亚马逊AWS云,但谷歌云平台(GCP)是另一个云供应商。对于GCP上的云数据库存储选项,谷歌提供的选项包括Cloud SQL, Cloud Datastore, Google BigTable, Google Cloud BigQuery, and Google Spanner。在这篇博客中,我将讨论所有这五个选项,但主要集中在后三个,因为我对处理大量数据的选项更感兴趣。

Cloud SQL
如果你想拥有完整的关系型数据库,支持自定义表视图、存储过程、大量索引和ACID兼容,那么云SQL可能是你的潜在选择。谷歌云SQL是支持两种类型数据库的数据库服务。MySQL和PostgreSQL。两者都支持高可用(HA)和按使用付费,没有锁定。它可以扩展到32个处理器核心和200GB以上的内存。虽然这个选项可能会使你在将数据迁移到云端时生活更轻松,但它确实有MySQL和PostgreSQL的所有限制,而且对于巨大的数据量来说,不能很好地扩展。关于MySQL和PostgreSQL的性能限制,有很多博客。我不打算在这里重复。

关于云计算SQL的更多信息,请访问https://cloud.google.com/sql/

云数据存储
Google Cloud DataStore是一个基于云的NoSQL数据库,用于网络和移动应用。它是可扩展的NoSQL数据库,可以自动处理分片和复制。它还支持ACID交易、类似SQL的查询和REST API。与BigTable不同,Datastore针对较小的数据集进行了优化。尽管云数据存储是一个NoSQL数据库,你不需要在存储行之前定义一个模式,但它实际上更多的是用于结构化数据的临时存储。云数据存储没有SQL,但有一个叫做GQL的API来执行某种查询。下面是一个查询的例子。
// 列出员工少于400人的谷歌公司。
var companies = query.filter(‘name =’, ‘Google’).filter(‘size <’, 400)。
有人提到,Cloud Datastore实际上起源于谷歌的内部使用的数据库Megastore。Megastore在谷歌内部被广泛使用。我没能找到谷歌关于这两个产品之间联系的官方声明。但从谷歌公布的关于Megastore的信息来看,它确实与Cloud Datastore相当相似。

关于Cloud Datastore的更多信息,请访问https://cloud.google.com/datastore/

Google BigTable
谷歌BigTable是谷歌的云存储解决方案,用于低延迟的数据访问。它最初是在2004年开发的,建立在谷歌文件系统(GFS)上。有一篇关于BigTable的论文。Bigtable一个结构化数据的分布式存储系统。现在,它被广泛用于许多谷歌的核心服务,如谷歌搜索、谷歌地图和Gmail。它是以NoSQL架构设计的,但仍然可以使用基于行的数据格式。它的数据读/写时间在10毫秒以下,适合于频繁摄入数据的应用。它可以扩展到数百PB,每秒处理数百万次操作。

BigTable通过扩展与HBase 1.0 API兼容。从HBase转移到BigTable将更加容易。BigTable没有SQL接口,你只能使用API去Put/Get/Delete单个行或运行扫描操作。BigTable可以很容易地与其他GCP工具集成,比如Cloud Dataflow和Dataproc。BigTable也是Cloud Datastore的基础。

与其他云不同,GCP的计算和存储是分开的。在计算成本时,你需要考虑以下三个部分。
1. 云实例的类型,以及实例中的节点数量。
2. 你的表使用的存储总量。
3. 使用的网络带宽的数量。请注意:网络流量的某些部分是免费的。

这有好有坏。好的部分是,如果你的系统是闲置的,你不需要支付计算成本,你只需要支付存储成本。坏的部分是,如果你有非常大的数据集,就不容易预测你的计算用量。

无论你选择SSD和HDD存储类型,计算成本都是一样的。这是有道理的,因为存储和计算在GCP中是分开的。
两种情况下的写入量都是一样的。与SSD相比,HDD的读取速度要慢20倍左右。但是HDD的扫描速度只下降了20%。如果你知道你的访问模式主要是扫描,那么HDD的选择似乎并不坏。虽然我不推荐使用HDD,但我觉得这个观察很有趣,而且令人费解。
使用HDD存储的成本只有使用SSD的15%。
欲了解更多信息,请访问http://cloud.google.com/bigtable/

BigQuery
BigQuery是谷歌基于云的数据仓库解决方案。与BigTable不同,它针对的是大图片中的数据,可以在短时间内查询大量的数据。由于数据是以柱状数据格式存储的,与BigTable相比,它在扫描大量数据时速度更快。BigQuery允许你扩展到PB级,是伟大的企业数据仓库,用于分析。BigQuery是无服务器的。无服务器计算意味着计算资源可以按需启动。它使用户从零服务器使用到全面使用,而不需要管理员和管理基础设施。据谷歌介绍,BigQuery可以在几秒钟内扫描Terabytes的数据,在几分钟内扫描Petabytes的数据。对于数据摄取,BigQuery允许你从谷歌云存储,或谷歌云数据存储,或流媒体加载数据到BigQuery存储。

然而,BigQuery确实适用于OLAP类型的查询和扫描大量数据,而不是为OLTP类型的查询而设计。对于小规模的读/写,它需要大约2秒,而BigTable对于相同数量的数据需要大约9毫秒。BigTable更适合于OLTP类型的查询。虽然BigQuery支持原子单行操作,但它缺乏跨行交易支持。

对于定价,有一些免费的操作。我不会讨论更多的免费操作,只是讨论BigQuery中最重要的组件的标准定价。在使用BigQuery的成本中,有两个主要部分。存储成本和查询成本

对于存储成本,它是每GB/月0.02美元。然而,谷歌有一个长期存储的定价,是每GB/月0.01美元的50%折扣。长期存储的定义是90天内没有被编辑(APPEND、OVERWRITE或STEAMING)的表。表中的每个分区被认为是独立的存储。因此,你可以对一些最近的分区进行标准定价,而对一些历史分区进行长期存储定价。即使数据在长期存储中,性能、耐久性和可用性也不会降低。

对于查询费用,一个月内处理的第一个1TB的数据是免费的,然后是每TB5美元。缓存查询不收费。由于BigQuery是以列式数据格式存储的,查询费用是基于所选择的列。对于拥有大量数据和大量应用程序的企业来说,虽然数据存储的账单是可预测的,但查询费用的账单却不是。好消息是,谷歌确实提供了一个统一的每月费用模式,而不是按需定价。例如,你可以为500个BigQuery插槽支付10,000美元,BigQuery自动管理这些插槽配额。

关于BigQuery的更多文件,请访问http://cloud.google.com/bigquery/docs。下面是BigQuery屏幕的一个例子。

Cloud Spanner
Cloud Spanner是一个全球分布式数据库,2017年5月正式发布。它是一个版本化的键值存储。从这个角度来看,它类似于BigTable。然而,它支持通用的交易,并提供基于SQL的查询语言。

Spanner开发于2011年,在内部用于谷歌的广告后台,它被称为F1。F1最初是基于MySQL数据库的。随着谷歌广告收入的快速增长,F1的MySQL数据库也在快速增长。未压缩的数据集有几十TB。这绝对超出了MySQL的舒适区。即使在分片方案上做了巨大的努力,数据库的管理也变得非常复杂和昂贵。上一次对这个MySQL数据库进行重新分片,花了两年的时间,付出了巨大的努力。请注意,即使是像谷歌这样的伟大公司,拥有如此多的人才,仍然花费了两年的努力。我无法想象其他公司是如何在这么大的MySQL数据库中生存的。这就是为什么我通常对使用大尺寸的MySQL数据库持谨慎态度。

我最喜欢Cloud Spanner的两个特点。
1. 复制配置
数据复制是自动和透明地处理的。但用户应用可以控制数据的存储方式。例如,如果用户数据要求只留在美国,你可以指定只将数据存储在美国的数据中心。如果你想提高读取性能和可用性,你可以增加使用的复制数量和复制的地理位置,使数据尽可能地靠近用户。如果你想拥有快速的写入吞吐量,你可以决定副本之间的距离。

2. 全球分布的数据库允许一致的读和写。
如果我想有一个一致的备份,或者在全球范围内有一致的读取,这个功能是至关重要的。这个功能的实现是使用谷歌的TrueTime。TrueTime基于GPS和原子钟的时间参考,而不是只使用一个来源的时间参考。谷歌表示,之所以使用两种不同的时间参考,是因为它们有不同的故障模型。原子钟可以在很长一段时间内发生故障,如漂移明显,而GPS在接收机故障或无线电干扰时可能发生故障。通常你不会看到两种时间基准同时失效,因为它们有不同的失效模型。

Spanner被组织成一组区域。每个区有一个区主和100到1000个跨度服务器。每个表都被分割成多个片区。一个表的状态被存储在一组类似B树的结构文件中,并在一个叫做Colossus的文件系统中存储Write-Ahead Log。Colossus是一个全球分布式文件系统,是谷歌文件系统(GFS)的继承者。Spanner的数据模型不是纯粹的关系型,而是半关系型。每个行都必须有名字,每个表都需要有一个或多个主键列的有序集合。谷歌发布了《Spanner模式设计的最佳实践》。关于Spanner架构的更多信息,请查看谷歌的研究论文。Spanner。谷歌的全球分布式数据库。

下面显示了创建一个有10个节点的Spanner实例的选项。

存储成本是每GB/月0.30美元,每个节点每小时9美元。每个Spanner节点可以提供高达10,000 QPS的读取或2000 QPS的写入(以每行1KB数据写入单行),以及2TB的磁盘存储。谷歌还建议提供更多的扳手节点,以保持CPU利用率低于75%。

在GCP的这五个数据库存储选项中,我最喜欢Cloud Spanner,因为我觉得它最能满足支持关系型数据库和强大的可扩展性和可用性的要求。但是,如果你想找到真正适合你的选项,谷歌有一个很好的决策树来帮助你确定最适合你的选项。

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注

Back To Top