sql时间范围查询_Google Spanner：成为一个SQL系统

本周，我们将开始研究SIGMOD'17的一些论文。首先是有关Google Spanner的出色的“更新”论文，该故事使该故事自OSDI'12原始论文以来的五年内一直保持最新状态。

…在许多方面，今天的Spanner与此处所描述的完全不同。

如果必须用两个词来概括更改，则可能是：“ 更多SQL！”

当然，作为Google最重要的内部系统之一，Spanner现在也可以以“ Cloud Spanner ”的形式作为GCP的一部分供您使用。本文将使您对Spanner可以为您做的事情有更深入的了解。

Spanner为什么会发展？

谷歌开发人员试图建立在以前的“键值”存储系统上的经验推动了向更“类似于数据库”的系统发展的主要动机。[例如，Bigtable]。

Bigtable在Google上仍被广泛使用，但是对于OLTP风格的应用程序，开发人员在没有强大的架构系统，跨行事务，一致的复制和强大的查询语言的情况下苦苦挣扎。到目前为止，仅尝试在Bigtable上提供这些功能。

结果，我们决定将Spanner变成功能全面的SQL系统，并将查询执行与Spanner的其他体系结构功能（例如强一致性和全局复制）紧密集成在一起。

尽管Spanner接受了SQL，但这并不意味着它放弃了可扩展性目标：“ 在网络公司中，可扩展性从未受到妥协，因此包括Spanner在内的所有Google系统都从那里开始。” Spanner团队提到支持可伸缩性的两个主要挑战是可管理性和事务。

可扩展的数据管理系统必须尽早解决可管理性以保持可行性。对于Spanner而言，这意味着跨集群的透明故障转移以及在扩展系统时轻松重新分片数据的能力……跨越任意行/键的ACID事务是可伸缩数据管理系统面临的下一个难题。事务对于关键任务应用程序是必不可少的，在这种应用程序中，任何不一致的情况，甚至是暂时的都不可接受。如[ OSDI'12原始论文 ] 所述，要使 ACID大规模地工作非常困难，并且需要Spanner进行实质性的创新。

本文中有很多很棒的信息，其中包括第2部分中对Spanner总体架构的简洁概述。在本文中，我主要关注三个关键方面：

• Spanner如何有效地支持分布式查询执行
• Spanner如何确定哪些服务器应处理查询，以及如何使用范围提取来最大程度地减少对这些服务器的扫描和锁定
• 为什么Spanner会花很多精力来支持可重新启动的查询

分布式查询执行

Spanner SQL查询编译器使用查询代数树中的显式运算符表示分布（沿长长的线一直返回到Volcano）。基本的构建块是Distributed Union运算符，该运算符将子查询运送到每个相关的分片并连接结果。

分布式联合是扳手中的一项基本操作，特别是因为表的分片可能在查询执行期间以及查询重新启动后发生变化。

首先，在每个Spanner表的上方立即插入一个Distributed Union运算符，以便使用表分片的本地扫描将全局扫描替换为显式的分布式操作。然后，在可能的情况下，将分布式联盟拉到树上。这样的结果是将更多的计算留在分布式联合之下 -即，工作量被降低，从而由负责数据分片的服务器执行最大可能的工作量。

为了使这些运算符树转换等效，对于我们要下推的任何关系运算 F，必须满足我们称为 分区性的属性。

该条件规定执行施加的结果的有序工会˚F到表键顺序每个碎片给出了相同的结果为适用˚F到全局扫描的结果。

Spanner知道底层数据集的键或标识列，因此可以将更复杂的操作（如分组和排序）推向靠近数据执行的位置，其中分片列是分组或排序列的适当子集。这是可能的，因为Spanner使用范围分片。

除了范围分片外，Spanner还支持表交织，该表交织将多个共享主键前缀的表中的行并置在一起：所有“子表”行实际上存储在它们所连接的“父表”行的旁边。这意味着还可以将这些表之间的联接向下推到分布式联合的下方，以获取通用的分片键。

考虑SQL查询

它产生以下分布式执行计划，其中最初在Customer和Sales扫描正上方插入的分布式并集几乎在树的顶部被拉起并统一在一起：

在运行时，分布式联合通过使用Spanner协处理器框架将寻址到分片的子查询请求路由到可以为该请求提供服务的最近副本之一，从而最大程度地减少了延迟。分片修剪用于避免查询不相关的分片。分片修剪利用分片的范围键，并且取决于将表的分片键上的条件下推到基础扫描。

范围提取，如下所述，提取一组范围，保证可以完全覆盖子查询可能在其上产生结果的所有表行，并且是分枝修剪的核心。

子查询并行分配给每个相关的分片。

独立分布的表之间的联接可能是另一篇论文的主题。在这里，作者集中于一个示例，即批量应用联接，该联接联接通常用于联接二级索引及其独立分布的基表。

Spanner通过扩展Distributed Union并以批处理方式实现Apply样式联接来实现Distributed Apply运算符-作为两个联接，一个分布式联接将输入中的行行应用到远程子查询中，另一个将每个批处理中的行应用到原始行中在分片上本地连接子查询。

当客户端通过API进行查询时，Spanner将尝试将查询直接路由到拥有查询所引用数据的全部或部分的服务器。第一次提交查询时，它可以转到任何服务器。此时，将分析查询并确定位置提示，然后将其发送到客户端进行缓存。位置提示使客户端能够廉价地计算后续执行时将查询发送到的位置。

Spanner还对需要使用并行使用者 API 并行处理查询结果的情况提供明确支持。这分为两个阶段：

首先是将工作分配给所需数量的客户。API接收SQL查询和所需的并行度，并返回一组不透明的查询分区描述符。在第二阶段，通常使用从单独计算机并行发起的请求，在各个分区上执行查询。并行消费者API保证来自所有分区的结果串联产生的无序行集与通过单一消费者API提交的查询相同。

范围提取

范围提取是分析查询以确定它引用的表的哪些部分的过程。范围提取有以下三种方式：

• 分布式范围提取可确定查询引用了哪些表分片。
• 搜寻范围提取确定要从底层存储堆栈读取相关碎片的哪些片段。
• 锁定范围提取确定要锁定表的哪些片段（悲观的txns）或检查潜在的未决修改（快照的txns）。

我们在Spanner中执行范围提取的实现依赖于两种主要技术：在编译时，我们将过滤后的扫描表达式进行规范化并将其重写到相关的自联接树中，以提取连续键列的范围。在运行时，我们使用称为过滤器树的特殊数据结构，既可以通过自下而上的时间间隔算法来计算范围，又可以有效地评估后过滤条件。

通常，范围计算是一个保守的近似值，因为隔离谓词中的关键列可能是任意复杂的，并且收益递减。在最坏的情况下，对于分布范围提取，查询可能会发送到最终不返回任何行的分片。

…搜索与扫描的权衡以及锁定的粒度涉及优化决策，这可能非常棘手，超出了本文的范围。

可重启查询

Spanner支持在出现故障，重新分片和二进制部署时自动重启查询。这是在查询处理器内部实现的，方法是捕获使用重新启动令牌执行的查询计划的分布式状态。令牌必须对动态重新分片（正在进行的数据拆分，合并和移动）具有鲁棒性。此外，由于高性能可能以不可重复的顺序返回，因此不确定性会导致高性能查询执行机会，从而使重启变得复杂。最后，Spanner还支持跨新服务器版本的重新启动，这涉及确保重新启动令牌连线格式的向后兼容性，在每次查询重新启动时保留查询计划，以及操作员行为的向后兼容性。这是很多工作！

总体而言，对重启的支持需要付出可观的工程成本。除其他事项外，它需要开发重新启动令牌版本控制机制，在不兼容的更改时强制进行显式版本控制的过程，以及捕获不兼容性的框架。应对这些挑战很困难，但值得这样做，因为透明的重启可以提高用户感知的系统稳定性，并在Spanner设计的其他方面提供重要的灵活性。

查询重新启动机制提供的一些好处包括：

• 隐藏瞬态故障，包括网络断开连接，计算机重新启动，进程崩溃，分布式等待和数据移动。
• 一种简化的编程模型，不需要程序员对重试循环进行编码。（“数据库客户端代码中的重试循环很难解决错误，因为编写具有适当补偿的重试循环并不容易。”）
• 支持长时间运行的查询而不是分页查询（避免仅为了支持分页而进行排序）
• 通过重新启动查询时需要做的最少工作量，改进了在线请求的尾部等待时间
• 前向进度保证了长时间运行的查询，其中运行时间与发生（瞬时）故障的平均时间相当。
• 支持循环滚动升级。“在过去几年中，Spanner在Google内部广泛使用，很少有时间没有Spanner区域升级到新版本，主要是在短暂的假期休假期间。”

Spanner开发敏捷性的基石是能够在一周左右的时间内同时运行几个版本的同时将所有计算机逐步升级到新版本的能力。

本文中其他有趣的点点滴滴

Google迁移到了其所有系统（例如Spanner，F1，Dremel，BigQuery）共享的标准内部SQL方言（“ Standard SQL”）。要进行这项工作需要花费很多精力。几个共享组件确保了系统之间的一致性：编译器前端，标量函数库以及共享的测试框架和测试。

Spanner现在具有一种名为Ressi的新的低级存储格式，该格式是从头开始设计的，用于处理大型分布式数据库中的SQL查询，这些数据库混合了OLTP和OLAP工作负载。Ressi将数据库存储为LSM树，并将值分为仅包含最新值的活动文件和可能包含较旧版本的不活动文件。这有助于更有效地支持Spanner的时间版本语义。

尽管对万能的系统提出了批评，但将OLTP，OLAP和全文本搜索功能组合在一个系统中仍然是客户优先考虑的事情。对具有不同可用性保证，事务语义，推出周期以及语言和API怪癖的多个系统进行大规模部署和监视是客户的主要负担。我们的目标是随着时间的流逝，使Spanner在各种使用案例中表现良好并具有成本效益。