你好，哈布罗维人。 传统上，我们会在新课程开始前夕继续分享有趣的材料。 今天，我们特别为您翻译了一篇有关 Google Cloud Spanner 的文章，时间与课程发布时间一致 .
最初发表于 .
作为一家为世界各地的零售商、餐馆和在线商家提供各种基于云的 POS 解决方案的公司，Lightspeed 使用多种不同类型的数据库平台来处理各种交易、分析和搜索用例。 这些数据库平台都有自己的优点和缺点，因此，当 Google 将 Cloud Spanner 推向市场时，它承诺提供关系数据库领域中未曾见过的功能，例如几乎无限的水平可扩展性和 99,999% 的服务级别协议 (SLA) ，我们不能错过将她掌握在我们手中的机会！
为了全面概述我们使用 Cloud Spanner 的经验以及我们使用的评估标准，我们将涵盖以下主题：
- 我们的评价标准
- 云扳手简而言之
- 我们的评估
- 我们的研究结果
1. 我们的评价标准
在深入了解 Cloud Spanner 的具体情况及其与市场上其他解决方案的异同之前，我们首先讨论一下在考虑在基础设施中部署 Cloud Spanner 时想到的主要用例：
- 作为（流行的）传统 SQL 数据库解决方案的替代品
- 作为支持 OLAP 的 OLTP 解决方案
注： 为了便于比较，本文将 Cloud Spanner 与 GCP Cloud SQL 和 Amazon AWS RDS 解决方案系列的 MySQL 变体进行了比较。
使用 Cloud Spanner 替代传统 SQL 数据库解决方案
在环境中 传统的 在数据库中，当数据库查询的响应时间接近甚至超过预定义的应用程序阈值（主要是由于用户和/或请求数量的增加）时，有多种方法可以将响应时间减少到可接受的水平。 然而，这些解决方案大多数都涉及手动干预。
例如，第一步是查看各种与性能相关的数据库设置，并将其调整为最匹配应用程序使用场景模式。 如果这还不够，您可以选择垂直或水平扩展数据库。
扩展应用程序需要更新服务器实例，通常通过添加更多处理器/内核、更多 RAM、更快的存储等。添加更多硬件资源会提高数据库性能，主要以每秒事务数和 OLTP 系统的事务延迟来衡量。 MySQL 等关系数据库系统（使用多线程方法）可以很好地垂直扩展。
这种方法有几个缺点，但最明显的是市场上最大的服务器尺寸。 一旦达到最大服务器实例限制，就只剩下一条路径：横向扩展。
横向扩展是一种向集群添加更多服务器的方法，以随着添加更多服务器而理想地线性提高性能。 多数 传统的 数据库系统不能很好地扩展或者根本不能扩展。 例如，MySQL可以通过添加从属读取器来扩展读操作，但不能扩展写操作。
另一方面，由于其性质，Cloud Spanner 可以以最少的干预轻松水平扩展。
功能齐全 DBMS 即服务 必须从不同的角度来评价。 作为基础，我们采用了云中最流行的 DBMS - 对于 Google，GCP Cloud SQL 和对于 Amazon，AWS RDS。 在我们的评估中，我们重点关注以下类别：
- 特征映射：SQL范围、DDL、DML； 连接库/连接器、事务支持等。
- 开发支持：易于开发和测试。
- 管理支持：实例管理，例如扩缩容和升级实例； SLA、备份和恢复； 安全/访问控制。
使用 Cloud Spanner 作为支持 OLAP 的 OLTP 解决方案
虽然 Google 没有明确声明 Cloud Spanner 用于分析，但它确实与其他引擎共享一些属性，例如专为 OLAP 工作负载设计的 Apache Impala & Kudu 和 YugaByte。
即使 Cloud Spanner 包含一致的横向扩展 HTAP（混合事务/分析处理）引擎以及（或多或少）可用的 OLAP 功能集的可能性很小，我们也认为它值得我们关注。
考虑到这一点，我们研究了以下类别：
- 数据加载、索引和分区支持
- 查询性能和 DML
2. Cloud Spanner 简而言之
Google Spanner 是一个集群关系数据库管理系统 (RDBMS)，Google 将其用于自己的多项服务。 谷歌于 2017 年初向谷歌云平台用户公开提供该服务。
以下是 Cloud Spanner 的一些属性：
- 高度一致、可扩展的RDBMS集群：使用硬件时间同步来保证数据的一致性。
- 跨表事务支持：事务可以跨越多个表 - 不一定限于单个表（与 Apache HBase 或 Apache Kudu 不同）。
- 基于主键的表：所有表都必须有一个声明的主键（PC），它可以由多个表列组成。 表格数据按照 PC 顺序存储，这使得 PC 搜索非常高效、快速。 与其他基于 PC 的系统一样，必须根据预先设想的用例对实施进行建模，才能实现 .
- 条带表：表之间可以具有物理依赖性。 子表的行可以与父表的行匹配。 这种方法加快了对可在数据建模阶段确定的关系的搜索速度，例如，将客户及其发票放在一起时。
- 索引：Cloud Spanner 支持二级索引。 索引由索引列和所有 PC 列组成。 或者，索引还可以包含其他非索引列。 索引可以与父表交错以加快查询速度。 索引有几个限制，例如索引中可以存储的附加列的最大数量。 此外，通过索引的查询可能不像其他 RDBMS 那样简单。
“Cloud Spanner 仅在极少数情况下自动选择索引。 特别是，如果查询请求的任何列未存储在 Cloud Spanner 中，则 Cloud Spanner 不会自动选择二级索引。 “。
- 服务水平协议（SLA）：单区域部署，SLA达99,99%； 具有 99,999% SLA 的多区域部署。 虽然SLA本身只是一个协议，并不是任何形式的保证，但我相信Google人确实有一些确凿的数据来做出如此强有力的主张。 （仅供参考，99,999% 表示每月服务停机时间为 26,3 秒。）
- 更多：
注： Apache Tephra 项目为 Apache HBase 添加了高级事务支持（现在也在 Apache Phoenix 中作为测试版实现）。
3. 我们的评价
因此，我们都读过 Google 关于 Cloud Spanner 优势的声明 - 几乎无限的水平扩展，同时保持高一致性和非常高的 SLA。 尽管这些主张无论如何都极难实现，但我们的目的并不是反驳它们。 相反，让我们关注大多数数据库用户关心的其他事情：奇偶性和可用性。
我们将 Cloud Spanner 评为 Sharded MySQL 的替代品
Google Cloud SQL 和 Amazon AWS RDS 是云市场中最受欢迎的两种 OLTP 数据库，拥有非常庞大的功能集。 但是，为了将这些数据库扩展到单个节点的大小之外，您需要执行应用程序拆分。 这种方法给应用程序和管理带来了额外的复杂性。 我们研究了 Spanner 如何适应将多个分片合并到一个实例中的场景，以及可能必须牺牲哪些功能（如果有）。
支持 SQL、DML 和 DDL，以及连接器和库？
首先，在开始使用任何数据库时，您需要创建一个数据模型。 如果您认为可以将 JDBC Spanner 连接到您最喜欢的 SQL 工具，您会发现您可以使用它查询数据，但不能使用它来创建表或更新 (DDL) 或任何插入/更新/删除操作（DML）。 Google 官方的 JDBC 也不支持。
“驱动程序当前不支持 DML 或 DDL 语句。”
扳手文档
GCP 控制台的情况也好不了多少 - 您只能发送 SELECT 查询。 幸运的是，社区有一个支持 DML 和 DDL 的 JDBC 驱动程序，包括事务 。 虽然这个驱动程序非常有用，但谷歌自己的 JDBC 驱动程序的缺失令人惊讶。 幸运的是，Google 提供了相当广泛的客户端库支持（基于 gRPC）：C#、Go、Java、node.js、PHP、Python 和 Ruby。
几乎强制使用 Cloud Spanner 的自定义 API（由于 JDBC 中缺乏 DDL 和 DML）导致相关代码领域（例如连接池或数据库绑定框架（如 Spring MVC））受到一些限制。 一般来说，在使用 JDBC 时，您可以自由选择您最喜欢的经过测试且运行良好的连接池（例如 HikariCP、DBCP、C3PO 等）。 对于自定义 Spanner API，我们必须依赖我们自己创建的框架/绑定/会话池。
面向主键（PC）的设计使得Cloud Spanner在通过PC访问数据时非常快，但也引入了一些查询问题。
- 您无法更新主键的值； 您必须首先删除原始 PC 条目，然后使用新值重新插入。 （这与其他面向 PC 的数据库/存储引擎类似。）
- 任何 UPDATE 和 DELETE 语句都必须在 WHERE 中指定 PC，因此，不能有空 DELETE all 语句 - 必须始终有一个子查询，例如： UPDATE xxx WHERE id IN (SELECT id FROM table1)
- 缺少自动增量选项或类似的设置 PC 字段序列的选项。 为此，必须在应用程序端创建相应的值。
二级指标？
Google Cloud Spanner 内置了对二级索引的支持。 这是一个非常好的功能，在其他技术中并不总是存在。 Apache Kudu 目前根本不支持二级索引，Apache HBase 也不直接支持索引，但可以通过 Apache Phoenix 添加索引。
Kudu 和 HBase 中的索引可以建模为具有不同主键组成的单独表，但对父表和相关索引表执行的操作的原子性必须在应用程序级别执行，并且正确实现并不简单。
正如 Cloud Spanner 评论中提到的，它的索引可能与 MySQL 索引不同。 因此，在构建查询和分析时必须特别小心，以确保在需要的地方使用正确的索引。
表示？
数据库中一个非常流行且有用的对象是视图。 它们对于大量用例很有用； 我最喜欢的两个是逻辑抽象层和安全层。 不幸的是，Cloud Spanner 不支持视图。 然而，这只是部分限制了我们，因为访问权限没有列级粒度，视图可以成为可接受的解决方案。
请参阅 Cloud Spanner 文档，了解详细说明配额和限制的部分 (），对于某些应用程序来说，有一个特别可能会出现问题：开箱即用的 Cloud Spanner 每个实例最多有 100 个数据库。 显然，对于旨在扩展到 100 多个数据库的数据库来说，这可能是一个主要障碍。 幸运的是，在与我们的 Google 技术代表交谈后，我们发现这个限制可以通过 Google 支持增加到几乎任何值。
开发支持？
Cloud Spanner 为其 API 的使用提供了相当不错的编程语言支持。 官方支持的库包括 C#、Go、Java、node.js、PHP、Python 和 Ruby。 该文档相当详细，但与其他尖端技术一样，与最流行的数据库技术相比，社区相当小，这可能会导致将更多时间花在不太常见的用例或问题上。
那么当地的发展支持呢？
我们尚未找到在本地创建 Cloud Spanner 实例的方法。 我们得到的最接近的是 Docker 镜像 这在原理上是相似的，但在实践中却有很大不同。 例如，CockroachDB 可以使用 PostgreSQL JDBC。 由于开发环境应尽可能接近生产环境，因此 Cloud Spanner 并不理想，因为您需要依赖完整的 Spanner 实例。 为了节省成本，您可以选择单个地域实例。
行政支持？
创建 Cloud Spanner 实例非常简单。 您只需选择创建多区域实例还是单区域实例，指定区域和节点数量。 不到一分钟，实例就会启动并运行。
Google 控制台的 Spanner 页面上可以直接使用几个基本指标。 通过 Stackdriver 可以获得更详细的视图，您还可以在其中设置指标阈值和警报策略。
获取资源？
MySQL 提供广泛且非常精细的用户权限/角色设置。 您可以轻松自定义对特定表甚至其列的子集的访问。 Cloud Spanner 使用 Google 身份和访问管理 (IAM) 工具，该工具仅允许您在非常高的级别设置策略和权限。 最细粒度的选项是数据库级权限，它不适合大多数生产情况。 此限制迫使您向代码、基础设施或两者添加额外的安全措施，以防止未经授权使用 Spanner 资源。
备份？
简而言之，Cloud Spanner 中没有备份。 虽然Google的高SLA要求可以确保您不会因硬件或数据库故障、人为错误、应用程序缺陷等而丢失任何数据。我们都知道规则：高可用性不能替代智能备份策略。 目前，备份数据的唯一方法是以编程方式将其从数据库流式传输到单独的存储环境。
查询性能？
我们使用 Yahoo! 加载数据并测试查询。 云服务基准。 下表显示了读取率为 95%、写入率为 5% 的 B YCSB 工作负载。
* 负载测试在 n1-standard-32 计算引擎 (CE)（32 个 vCPU、120 GB 内存）上运行，测试实例从来都不是测试中的瓶颈。
** 一个 YCSB 实例中的最大线程数为 400。总共必须运行 YCSB 测试的 2400 个并行实例才能获得总共 XNUMX 个线程。
查看基准测试结果，特别是 CPU 负载和 TPS 的组合，我们可以清楚地看到 Cloud Spanner 的扩展性相当好。 大量线程产生的巨大负载被 Cloud Spanner 集群中的大量节点抵消。 尽管延迟看起来相当高，尤其是在 2400 个线程下运行时，但可能需要使用 6 个较小的计算引擎实例重新测试才能获得更准确的数字。 每个实例将运行一个 YCSB 测试，而不是一个具有 6 个并行测试的大型 CE 实例。 这样可以更轻松地区分 Cloud Spanner 请求延迟和 Cloud Spanner 与运行测试的 CE 实例之间的网络连接所添加的延迟。
Cloud Spanner 作为 OLAP 的表现如何？
分区？
将数据划分为物理和/或逻辑上独立的段（称为分区）是大多数 OLAP 引擎中非常流行的概念。 分区可以极大地提高查询性能和数据库可维护性。 进一步深入研究分区将是一篇单独的文章，所以我们只提一下分区方案和子分区的重要性。 将数据拆分为分区甚至进一步拆分为子分区的能力是分析查询性能的关键。
Cloud Spanner 本身不支持分区。 它将数据内部分离成所谓的 分裂-s 基于主键范围。 分区是自动完成的，以平衡 Cloud Spanner 集群上的负载。 Cloud Spanner 的一个非常方便的功能是拆分父表（不与另一个表交错的表）的基本负载。 Spanner 自动检测是否包含 分裂 比其他数据中的数据更频繁地读取的数据 分裂-啊，可能会决定进一步分离。 这样，一个请求可以涉及更多的节点，这也有效地提高了吞吐量。
加载数据中？
批量数据的 Cloud Spanner 方法与常规上传相同。 为了获得最佳性能，您需要遵循一些准则，包括：
- 按主键对数据进行排序。
- 将它们除以 10*节点数 各个部分。
- 创建一组并行加载数据的工作任务。
此数据加载使用所有 Cloud Spanner 节点。
我们使用 A YCSB 工作负载生成 10M 行数据集。
* 负载测试在 n1-standard-32 计算引擎（32 个 vCPU、120 GB 内存）上运行，测试实例从来都不是测试中的瓶颈。
** 不建议对任何生产工作负载使用 1 节点设置。
如上所述，Cloud Spanner 根据负载自动处理拆分，因此在连续几次测试迭代后结果会有所改善。 这里给出的结果是我们收到的最好结果。 查看上面的数字，我们可以看到 Cloud Spanner 如何随着集群中节点数量的增加而扩展。 最引人注目的数字是极低的平均延迟，这与上一节所述的混合工作负载（95% 读取和 5% 写入）的结果形成对比。
缩放？
增加和减少 Cloud Spanner 节点数量是一项一键式任务。 如果您想快速加载数据，您可能需要考虑将实例提升到最大（在我们的示例中，美国东部地区为 25 个节点），然后在所有数据加载完毕后减少适合您正常加载的节点数量在数据库中，请记住 2 TB/节点限制。
即使数据库小得多，我们也会注意到这个限制。 经过几次负载测试运行后，我们的数据库大小约为 155 GB，当缩小到 1 节点实例时，我们收到以下错误：
我们能够将实例从 25 个缩减到 2 个，但我们被困在两个节点上。
可以使用 REST API 自动增加和减少 Cloud Spanner 集群中的节点数量。 这对于减少繁忙时段系统上增加的负载特别有用。
OLAP查询性能？
我们原本计划花大量的时间来评估 Spanner 的这一部分。 经过几次 SELECT COUNT 后，我们立即意识到测试会很短，并且 Spanner 不适合 OLAP 引擎。 无论集群中有多少个节点，仅选择 10M 行表中的行数就需要 55 到 60 秒。 此外，任何需要更多内存来存储中间结果的查询都会失败并出现 OOM 错误。
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
TPC-H 查询的一些数字可以在 Todd Lipcon 的文章中找到 ，幻灯片 42 和 43。这些数字与我们自己的结果一致（不幸的是）。
4. 我们的发现
鉴于 Cloud Spanner 功能的当前状态，很难将其视为现有 OLTP 解决方案的简单替代品，尤其是当您的需求超出它的范围时。 必须花费大量时间围绕 Cloud Spanner 的缺点构建解决方案。
当我们开始评估 Cloud Spanner 时，我们预计其管理功能与其他 Google SQL 解决方案相当，或者至少相差不远。 但我们对完全缺乏备份以及对资源的访问控制非常有限感到惊讶。 更不用说没有视图、没有本地开发环境、不支持的序列、不支持 DML 和 DDL 的 JDBC 等等。
那么，对于需要扩展事务数据库的人来说，该去哪里呢？ 市场上似乎还没有一个适合所有用例的解决方案。 有许多封闭和开源解决方案（本文中提到了其中一些），每个解决方案都有自己的优点和缺点，但它们都没有提供具有 99,999% SLA 和高度一致性的 SaaS。 如果高 SLA 是您的主要目标，并且您不倾向于为多个云构建自己的解决方案，那么 Cloud Spanner 可能就是您正在寻找的解决方案。 但您应该意识到它的所有局限性。
公平地说，Cloud Spanner 于 2017 年春季才向公众发布，因此有理由预期其当前的一些缺陷最终可能会消失（希望如此），而当它消失时，它可能会改变游戏规则。 毕竟，Cloud Spanner 不仅仅是 Google 的一个副业项目。 谷歌使用它作为其他谷歌产品的基础。 而且，当 Google 最近用 Cloud Spanner 替换 Google Cloud Storage 中的 Megastore 时，它使得 Google Cloud Storage 在全球范围内变得高度一致的对象列表（对于 Google Cloud Storage 来说，情况仍然不是这样） ).
所以，仍然有希望……我们希望。
就这样。 和文章作者一样，我们也继续希望，但是你对此怎么看呢？ 写在评论里
我们邀请大家参观我们的 我们将在其中详细告诉您有关课程的信息 来自奥图斯。
来源： habr.com