spanner 区块链-Google Spanner详述 下

Google扳手号称全球分布式数据库存储。有必要了解其特点，更好地了解区块链企业解决方案的优缺点。这篇文章是第二篇

这是昨天“谷歌萨普纳细节”的后半部分:

5实验分析

我们测试了扳手性能，包括复制、事务和可用性。然后，我们提供了一些关于TrueTime的实验数据，并提供了我们的第一个用例——F1。

5.1微量测试基准

表3给出了扳手的微基准。这些测试是在分时机器上实现的:每个spanserver使用4GB内存和四核CPU。客户端运行在不同的机器上。每个区域都包含一个spanserver。客户端和区域放置在一个数据中心集中，它们之间的网络距离不会超过1毫秒。这种布局很常见，很多数据不需要分布存储在全世界。测试数据库有50个Paxos组和2500个目录。操作是独立的4KB读写。所有的读取都是在比较后从内存中取出的，所以我们只需要测量扳手调用堆栈的开销。此外，将执行读取操作来预热任何位置的缓存。

对于延迟的实验，客户端会发起足够多的操作来避免在服务器中排队。在一次复制的实验中，提交延迟约为5毫秒，Paxos延迟约为9毫秒。随着副本数量的增加，延迟保持不变，只有很小的标准差，因为Paxos会在一组副本内并行执行。随着副本数量的增加，获得指定票数的延迟对从副本的慢速不敏感。

对于吞吐量实验，客户端发起足够多的操作，使CPU处理能力达到饱和。快照读取操作可以在任何足够新的副本上执行，因此快照读取的吞吐量将随着副本数量的增加而线性增加。单次读取的只读事务将只在引导上执行，因为时间戳分配必须在引导上进行。只读事务的吞吐量会随着副本数量的增加而增加，因为有效Spanservers的数量会增加。在这个实验设置中，Spanservers的数量与副本的数量相同，并且领导者将被随机分配到不同的区域。写操作的吞吐量也将受益于该实验设置。但是，随着副本数量的增加，完成每个写操作所需的工作量也会线性增加，这将抵消以前的优势。

表4显示，两阶段提交可以扩展到合理数量的参与者:它是在三个区域运行的一系列实验的总结，每个区域有25个spanserver。扩大到50名参与者是合理的，无论是平均还是第99百分位。在100名参与者的情况下，延迟发展显著增加。

5.2可用性

图5显示了在多个数据中心运行扳手时可用性的优势。它显示了三个吞吐量实验的结果，并且存在一个数据中心故障。三个实验结果都是重叠的，放在一个时间轴上。用于测试的宇宙包含5个区域Zi，每个区域有25个spanserver。测试数据库分为1250个Paxos组，100个客户端连续发送非快照读操作，每秒读操作累计速率50K。所有领导都会明确的放在Z1。每次测试5秒后，一个区域内的所有服务器都会被“杀死”:非领导杀死Z2，领导-硬杀Z1，领导-软杀Z1，但会先通知所有服务器，他们会交出领导。

杀死Z2对读取吞吐量没有影响。干掉Z1，给领导一些时间把领导权交给另一个区，影响不大:吞吐量下降，不明显，大概3-4%。另一方面，毫无征兆的干掉Z1有明显的效果:完成率几乎降到零。重新选择前导后，系统的吞吐量将增加到每秒100K次左右的读取操作，这主要是由于我们的实验设置:系统中有额外的容量，找不到前导时操作会排队。因此，系统的吞吐量将增加，直到达到系统的恒定速率。

我们可以看到将Paxos leader租约设置为10ms的效果。当我们杀死这个区域时，这个组的领导者的租约到期时间将在接下来的10秒内均匀分布。一旦一个死去的领袖的租约到期，就会选出一个新的领袖。经过10秒左右的消磨时间，所有组都会有领袖，吞吐量恢复。租用时间短会减少服务器死亡对可用性的影响，但是需要更多的网络通信开销来更新租用。我们正在设计和实现一个机制，当首领失败时，让奴隶释放帕索斯首领租赁。

5.3 TrueTime

关于TrueTime，必须回答两个问题:ε是时钟不确定性的边界吗？ε能坏到什么程度？对于第一个问题，最严重的问题是，如果一个本地时钟漂移大于200us/sec，那么TrueTime的假设就会被破坏。我们的机器统计显示，坏CPU的发生概率是坏时钟的6倍。也就是说，相比更严重的硬件问题，时钟问题是比较少见的。所以我们也相信TrueTime的实现和扳手的其他软件组件一样可靠可信。

图6显示了TrueTime数据，这些数据是从数千个跨越多个数据中心、距离超过2200公里的spanserver收集的。图中描述了ε的第90百分位、第99百分位和第99.9百分位，在timemaster上投票后立即从timeslave守护程序中提取样本。这些采样数据没有考虑时钟不确定性导致的ε值锯齿，因此它测量timemaster不确定性加上通信延迟。

图6中的数据表明，在确定ε的基本值时，上述两个问题通常都不是问题。但可能存在明显的拖尾延迟问题，会导致较高的ε值。图中3月30日拖尾延迟的减少是由于网络的改善，减少了瞬时网络连接的拥塞。4月13日，ε的值增加了一个小时左右，主要是因为日常维护时关闭了两个计时器。我们会继续调查，排除导致TrueTime突变的因素。

5.4 F1

扳手于2011年初开始在线负载测试，这是谷歌广告后台F1重新实施的一部分。这个背景最初是基于MySQL数据库的，很多方面都采用了手工数据分区。未压缩的数据可以达到几十兆字节，这对于许多NoSQL实例来说是非常小的，但是对于带有数据分区的MySQL来说是非常大的。MySQL的数据分片机制会将每个客户和所有相关数据分配到一个固定的分区。这种布局可以支持单个客户的索引构建和复杂的查询处理，但是它需要了解一些业务知识来设计分区。随着客户数量的增加，对数据进行重新分区成本很高。最近一次重新分区花了两年时间。为了降低风险，多个团队之间进行了大量的合作和测试。这种操作太复杂，不能频繁执行。因此，团队必须通过在外部Bigtable中存储一些数据来限制MySQL数据库的增长，这将牺牲事务和查询所有数据的能力。

F1车队选择扳手有几个原因。第一，扳手不需要手动分区。其次，扳手提供同步复制和自动故障恢复。当采用MySQL的主从复制方式时，很难从故障中恢复，存在数据丢失和崩溃的风险。第三，F1需要强大的事务语义，这使得使用其他NoSQL系统不切实际。应用语义需要跨任意数据的事务和一致读取。F1团队还需要在他们的数据上建立一个二级索引，并且有能力使用扳手事务来实现他们自己的一致的全局索引。

默认情况下，所有应用程序写入现在都从F1发送到扳手。而不是将其发送到基于MySQL的应用程序堆栈。F1在美国西海岸有2份，东海岸有3份。选择该副本的位置是为了避免发生自然灾害时服务停止的问题，这也是由于前端应用程序的位置。扳手的故障其实是自动恢复的，几乎看不见。在过去的几个月里，虽然一些计划外集群失败了，但F1团队最重要的任务是更新他们的数据库模式，告诉扳手在哪里放置Paxos领导者，使他们尽可能靠近应用前端。

扳手时间戳语义使F1能够高效地维护从数据库状态计算并存储在内存中的数据结构。F1维护所有更改的逻辑历史日志，作为每个事务的一部分写入扳手。F1会获取某个时间戳下的数据的完整快照来初始化其数据结构，然后根据数据的增量变化来更新数据结构。

表5显示了F1中每个目录中切片数量的分布。每个目录通常对应于F1上应用程序堆栈中的一个用户。大多数目录将只包含一个切片，这意味着这些用户数据的读写将只发生在一台服务器上。切片数超过100个的目录就是F1次索引的表。编写这些表的多个切片是极其不寻常的。F1团队只有在以事务方式加载未优化的批处理数据时才会遇到这种情况。

表6显示了从F1服务器测量的扳手操作延迟。东海岸数据中心的副本将在选择Paxos领导者时获得更高的优先级。表6中的数据是从这些数据中心的F1服务器测量的。写操作的延迟分布存在较大的标准差，这是由于锁冲突导致的肥尾效应。读操作的延迟分布存在较大的标准差，部分原因是Paxos的领导们跨越了两个数据中心，其中只有一个是带固态硬盘的机器。此外，该测试还包括两个数据中心的系统中的每个读取操作:字节读取操作的平均值和标准偏差分别为1.6KB和119KB。

6相关工作

Megastore和DynamoDB提供了跨多个数据中心的一致复制。DynamoDB提供键值存储接口，只能在一个区域内复制。扳手和Megastore一样，提供了半关系数据模型，甚至采用了类似的模式语言。Megastore无法激活高性能。Megastore基于Bigtable，带来较高的通信成本。Megastore也不支持长寿命的领导者，多个副本可能会启动写操作。来自不同副本的写操作在Paxos协议下肯定会冲突，即使不会有逻辑冲突:会严重影响吞吐量，一个Paxos组每秒只能执行几个写操作。扳手提供了更高的性能，一般事务和外部一致性。

Pavlo等人比较了数据库和MapReduce的性能。他们指出了几种努力，可以充分利用分布式键值存储之上的数据库功能，实现两者的完全集成。我们将zan与这个结论进行比较，认为集成多层有优势:集成复制和并发控制可以降低扳手中的提交等待成本。

在复制存储上实现事务至少可以追溯到吉福德的论文。散点是最近出现的基于DHT的键值存储，可以在一致复制上实现事务。扳手提供了比分散更高级别的接口。格雷和兰波特描述了一个基于Paxos的非阻塞提交协议。它们的协议会带来比两阶段提交协议更大的代价，并且两阶段提交协议在大规模分布式组中的代价会进一步恶化。Walter提供了快照隔离的变体，但它不能跨越数据中心。相反，我们的只读事务提供了更自然的语义，因为我们支持所有操作的外部语义。

最近，已经有许多关于减少或消除锁开销的研究工作。卡尔文消除了并发控制:它重新分配时间戳，然后按照时间戳的顺序执行事务。HStore和Granola都支持自己的交易类型分类方法，有些交易类型可以避免锁定机制。然而，这些系统都不能提供外部一致性。扳手通过提供快照隔离解决了冲突问题。

VoltDB是一个分区内存数据库，可以支持大面积主从复制和容灾，但没有提供通用的复制配置方法。它是一个叫做NewSQL的实例，是实现可扩展SQL的强大市场驱动力。很多商业数据库都可以支持历史数据读取，比如Marklogic和Oracle的Total Recall。Lomet和李描述了这个时间数据库的实现策略。

Faresite给出了与可信时钟参考值相关的时钟不确定性的边界13:fare site中的服务器租用方式与扳手中的Paxos租用维护方式相同。在以前的工作中，松散的同步时钟被用于并发控制。我们已经表明，TrueTime可以从Paxos状态机集中导出全局时间。

7未来工作

在过去一年的大部分时间里，我们作为F1团队一起将谷歌的广告后台从MySQL迁移到扳手。我们正在积极改进其监控和支持工具，并优化其性能。此外，我们还做了大量工作来改进备份恢复系统的功能和性能。我们目前正在实现扳手模式语言，可以自动维护二级索引，并根据负载自动分区。在未来，我们将调查更多的特征。我们追求以优化的方式并行执行读取操作，这是一种有价值的策略。但是初期的实验表明，很难达到这个目的。此外，我们计划最终支持对Paxos配置的直接更改。

我们希望在数据中心之间复制许多应用程序，并且这些数据中心彼此靠近。TrueTime ε可能会显著影响性能。把ε降到1ms以下没有不可逾越的障碍。时间主查询间隔可以不断减少，时间主查询延迟应该随着网络的改善而减少，或者可以采用分时技术来避免延迟。

最后，还有很多方面需要改进。虽然扳手在节点数量上是可扩展的，但是节点相关的数据结构在复杂的SQL查询上的性能相对较差，因为它们是为简单的键值访问而设计的。数据库文献中的算法和数据结构可以极大地提高单个节点的性能。此外，根据客户端负载的变化，在数据中心之间自动传输数据已经成为我们的目标。然而，为了有效地实现这一目标，我们必须有能力在数据中心之间自动和谐地传输客户端应用程序流程。转移过程会带来更困难的问题——如何在数据中心之间管理和分配资源。

8摘要

一般来说，扳手结合并扩展了来自两个研究组的概念:一个是数据库研究组，包括熟悉且易于使用的半关系接口、事务和基于SQL的查询语言；另一个是系统研究社区，包括可扩展性、自动分区、容错、一致复制、外部一致性和大规模分发。自从扳手的概念形成以来，我们用了5年多的时间来完成当前版本的设计和实现。这么长时间的部分原因是我们已经意识到扳手不仅要解决全局复制的命名空问题，还要注意Bigtable中缺失的数据库特性。

TrueTime是我们设计中的亮点之一。我们已经表明，当时钟不确定性在时间API中明确给出时，分布式系统可以用更强的时间语义来构建。此外，因为底层系统对时钟不确定性采用了更严格的边界，所以实现更强时间语义的成本将会降低。作为一个课题组，在设计分布式算法时，不再依赖弱同步时钟和弱时间API。