SolarDB：分布式日志结构存储的共享数据库

ACM Transactions on Storage，Vol.号152、第十一条。出版日期：2019年6月SolarDB：面向分布式日志结构存储的朱涛，华东师范大学ZHOOYUE ZHAO和FEIFEI LI，犹他大学钱伟宁，周傲英，华东师范大学DONG XIE和RYAN STUTSMAN，犹他大学李海宁和胡惠琪，交通银行大型数据库上的高效事务处理是许多关键任务应用程序的关键要求。虽然现代数据库通过水平分区实现了良好的性能，但当必须执行跨分区分布式事务时，它们的性能会恶化。本文介绍了SolarDB，一个分布式关系数据库系统，已成功地在一家大型商业银行进行了测试SolarDB的关键特性包括：（1）基于两层日志结构合并树的共享一切架构;（2）与日志结构存储一起工作的新并发控制算法，即使存储层在后台压缩节点之间的数据，也能确保高效和无阻塞的事务处理;（3）查找粒度的数据访问，以有效地最小化和平衡集群内的网络通信根据我们对TPC-C的经验评估小银行，和一个真实世界的工作负载，SolarDB优于现有的无共享系统高达11当分布式事务接近或超过5%时为50倍CCS概念：·信息系统→数据库事务处理;关系并行和分布式DBMS;其他关键词和短语：共享一切架构，日志结构存储，并发控制ACM参考格式：Tao Zhu， Zhuoyue Zhao， Feifei Li ， Weining Qian ， Aoying Zhou， Dong Xie ， Ryan Stutsman ，Haining Li，and Huiqi Hu.2019年。SolarDB：Toward a Shared-Everything Database on Distributed Log-Structured Storage（SolarDB：在分布式日志结构存储上实现共享数据库）ACMTrans. 存储15，2，第11条（2019年6月），26页。https://doi.org/10.1145/3318158本文是发表在USENIX ATCT. Zhu ， W. Qian ， 和 A. Zhou 博 士 获 得 了 863 计 划 （ 2015AA015307 ） ， 国 家 重 点 研 发 计 划 项 目（2018YFB1003303）和国家自然科学基金（61432006和61332006）的资助。F. Li，Z.Zhao和D.谢的研究部分得到了美国国家科学基金会的资助1619287和1443046。F. 李还得到了国家自然科学基金资助61729202的部分支持R. Stutsman的研究得到了NSF资助CNS-1750558的部分支持本材料中表达的任何观点、发现、结论或建议均为作者的观点，不一定反映国家科学基金会的观点作者地址：T. Zhu，W. Qian，和A.华东师范大学，中山北路3663号;电子邮件：zhutao@stu.ecnu.edu.cn，{wnqian，ayzhou}@sei.ecnu.edu.cn; Zhao，F. Li，D. Xie，和R. Stutsman，犹他大学，50 Central Campus Dr，SaltLake City，UT，USA，84112;电子邮件：{zyzhao，lifeifei，dongx，stutsman}@cs.utah.edu; H. Li和H.中国上海市银城中路188号交通银行胡先生;电子邮件：{lihn，hqhu}@ bankcomm.com。允许制作本作品的全部或部分数字或硬拷贝供个人或课堂使用，无需付费，前提是复制品不以营利或商业利益为目的制作或分发，并且复制品在第一页上带有此通知和完整的引用版权的组成部分，这项工作所拥有的其他人比ACM必须尊重。允许用信用进行提取复制，或重新发布，张贴在服务器上或重新分发到列表，需要事先特定的许可和/或费用。从permissions@acm.org请求权限。© 2019计算机协会。1553-3077/2019/06-ART11 $15.00https://doi.org/10.1145/3318158ACM Transactions on Storage，Vol.号152、第十一条。出版日期：2019年6月十一：2T. Zhu等人1介绍NoSQL系统的成功展示了横向扩展架构在实现接近线性可伸缩性方面的优势然而，由于数据存储的分布性，这些系统很难支持事务，这是大型数据库例如，Bigtable [5]只支持单行事务，而其他像Dynamo [6]这样的根本不支持事务为了响应对事务支持的需求，NewSQL系统被设计为在具有分布式数据存储的集群上进行高效的联机事务处理（OLTP）分布式事务处理是困难的，因为需要在节点之间进行有效的同步，以确保ACID属性并保持良好的性能。尽管最近提出的许多系统取得了重大进展和成功[8，9，12，19，23，27，29，34，38]，但它们仍然存在各种局限性。例如，依赖于无共享架构和两阶段提交（2PC）的系统严重遭受跨分区分布式事务，因此需要针对给定的工作负载进行仔细的数据分区然而，像Tell [19]这样的分布式共享数据系统需要特定的硬件支持，这些硬件支持通常还不能大规模使用。也就是说，当没有关于事务工作负载的先验假设时，并且没有特殊的硬件支持，在商品集群上实现高性能事务处理仍然是一个具有挑战性的问题。同时，先前的研究也表明，通过探索多核和多套接字（例如，NUMA）体系结构。Silo [30]和Hekaton [7]都使用单个服务器进行事务处理，并展示了高吞吐量。然而，这样的系统可能无法满足大数据应用的需求，其数据无法容纳在单个节点上，因此需要支持分布式数据存储。受这些观察的启发，我们的目标是设计一个事务数据库引擎，它结合了节点集群提供的可扩展数据存储的优点和在单个服务器节点上实现高效事务处理的简单性，而无需对事务工作负载进行任何先验假设，也无需任何特殊的硬件支持。作为中国最大的银行之一，交通银行也面临着这些挑战。一方面，来自其自身及其合作伙伴的移动和在线应用程序的新电子商务应用程序已经推动了对大数据上的临时事务的支持的需求，其中随着新应用程序的不断涌现，另一方面，银行对更好地利用其现有的硬件基础设施有着浓厚的兴趣，以避免昂贵的新硬件投资（如果可能的话）。考虑到这一点，SolarDB设计使用共享一切架构，其中服务器节点（称为T节点）保留用于内存中事务处理，许多存储节点（称为S节点）用于数据存储和读取访问。从本质上讲，SolarDB中的S节点形成了一个分布式存储引擎，T节点充当了主存事务引擎。分布式存储引擎利用节点集群来实现以下方面的可扩展性数据库容量和服务并发读取的能力。事务引擎提供高效的事务处理，并通过其内存中的已提交列表临时存储已提交的更新。T节点上最近提交的数据项定期通过后台运行的数据压缩过程合并回总的来说，SolarDB旨在实现高性能的事务处理和可扩展的数据存储。为了加快系统中的更新操作，T节点上的内存中提交列表和来自所有S节点的磁盘存储共同形成分布式双层日志结构合并树（LSM树）设计[22]。此外，还引入了一个称为P单元的处理层，SolarDB：面向分布式日志结构存储的共享数据库十一：3ACM Transactions on Storage，Vol.号152、第十一条。出版日期：2019年6月从S节点的数据访问和事务中所需的任何计算，使得T节点可以从协调数据访问和执行业务逻辑计算的负担中解放这种存储和计算的分离还使系统能够利用所有CPU资源进行事务调度和验证。为了实现上述设计原则，我们还设计并实现了一些优化和算法，以最大限度地减少系统开销我们的贡献概述如下：为了实现高性能的事务处理，提出了一种由一个T节点、一组S节点和P单元组成的分布式共享一切架构提出了一种混合型并发控制方案MVOCC，它结合了乐观并发控制（OCC）和多版本并发控制（MVCC）方案。作为MVOCC的一部分，数据压缩算法被设计为周期性地将T节点上的已提交列表有效地合并回S节点，而不中断T节点上的事务处理。研究了几种优化方法以提高整体性能，如通过P单元分离计算和存储，在一个事务中分组多个数据访问操作，以及维护位图以避免对分布式存储引擎的不必要数据访问在我们对TPC-C、Smallbank和实际工作负载的经验评估中，当需要分布式提交的事务接近或超过5%时，SolarDB比现有的无共享系统高出50倍2SOLARDB架构SolarDB是一个分布式共享关系数据库，在商品服务器集群上运行并发图1显示了它的体系结构。2.1设计考虑共享一切架构。无共享架构[12，27]将数据放置在不同节点上的非重叠分区中，希望当几乎所有事务都只需要接触一个分区上的数据时，它可以避免节点之间昂贵的2PC，从而可以独立运行对于分布式事务，涉及数据的多个分区需要被锁定，从而阻止所有其他需要接触这些分区的事务，这大大增加了系统延迟。更糟糕的是，只需要几个分布式事务就可以始终在所有分区上拥有锁，因此，系统吞吐量可以降低到几乎为零。相反，SolarDB采用了共享一切架构，事务处理单元可以访问任何数据。ACID可以在单个记录的更细粒度上而不是在分区上实施它还通过将更新存储在单个高端服务器上来避免昂贵的2PC，从而实现更高的事务吞吐量。内存中事务处理和可扩展存储。 传统的基于磁盘的数据库依赖于缓冲机制来减少频繁随机访问数据的延迟。然而，由于缓冲区的大小有限和恢复的复杂性，这比访问内存中的数据要慢几个数量级内存中的事务处理被证明比基于磁盘的设计更有效[7，12]。有限的内存始终是内存中事务处理的一个关键问题数据库必须具有将数据卸载到稳定存储的机制，以便为无限的事务流释放内存。一个关键的观察结果是，事务通常只触及非常小的子集····十一：4T. Zhu等人ACM Transactions on Storage，Vol.号152、第十一条。出版日期：2019年6月Fig. 1. SolarDB的架构整个数据库的一部分，在一个TB级数据的数据库中一次写入几条记录。因此，SolarDB通过完全写入内存来减少事务处理延迟，同时通过在基于磁盘的分布式存储上存储一致的快照来获得无限的容量，如果需要，可以扩展到更多节点细粒度数据访问控制。在SolarDB中，处理节点通过网络直接访问存储在远程节点中的数据，这可能导致开销。现有的研究表明，使用InfiniBand和Myrinet等网络是有利的[19]。然而，它们远未广泛提供。它们需要特殊的软件和硬件配置。目前还不清楚如何在数百台现成机器的集群上做到这一点SolarDB被设计为在商用服务器集群上工作，因此使用基于以太网/IP/TCP的标准网络基础设施但是网络延迟是很重要的，因为需要转换和数据复制到内核和从内核复制出来。它也比In-finiBand消耗更多的CPU，在In-finiBand中，数据传输被卸载到NIC上。为了解决这个问题，我们设计了细粒度的数据访问，以减少网络开销，包括缓存，避免不必要的读取，并通过事务编译优化节点间的通信细粒度数据访问使事务延迟与最先进的系统不相上下，并将吞吐量提高了3倍。2.2体系结构概述图1提供了SolarDBSolarDB使用多版本OCC协议将事务处理分为计算、验证和提交阶段。事务可以在任何一个P单元上启动，除了用于数据访问优化的几个小数据结构之外，P单元不存储任何数据（第4节）。P单元处理所有从T节点或S节点，以及事务处理。 写入在P单元处缓冲，直到事务提交或中止。当事务准备好提交时，P单元将写入集发送到T节点进行验证和提交。一旦T节点完成验证，它就会将更新写入其内存存储，并写入一个写前日志以确保持久性。最后，T节点通知P单元事务是否成功提交。 P单元可以在集群内部或外部的任何机器上实例化（通常在S节点或客户端）。它们将大部分计算负担从T节点卸载，T节点可以专用于事务管理。集群信息（例如，所有节点的状态，数据分布）由管理器节点维护并由其它节点高速缓存SolarDB采用模仿LSM树的两层分布式存储[22]。存储层由（1）一致的数据库快照和（2）自上次快照以来的所有已提交更新SolarDB：面向分布式日志结构存储的共享数据库十一：5ACM Transactions on Storage，Vol.号152、第十一条。出版日期：2019年6月快照的大小可以是任意大的，因此存储在跨S节点的磁盘的称为SSTable表中的记录根据其主键动态地划分为每个记录范围都存储在一个名为tablet的结构中（默认大小为256MB），它本质上是一个B树索引。提交的更新存储在T节点上的Memtable中，这些更新来自最近的事务，通常足够小，可以完全容纳在内存中。Memtable在主键上包含一个哈希索引和一个B树索引数据条目指向自上次快照以来的所有更新（仅更新的列），按其提交时间戳排序。要访问特定的记录，P-unit首先查询Memtable。如果Memtable中没有可见的版本，则它会从最后一个快照中查询SSTable的版本Memtable的大小随着事务的提交而增加。当它达到某个预定阈值或某个预定的非高峰时间（例如，12：00 am to 4：00 am for Bank of Communi-cations），SolarDB执行数据压缩操作，将Memtable中的更新合并到SSTable中，以释放T节点上的内存。在数据压缩结束时，在SSTable中创建一个新的一致快照，Memtable在数据压缩开始之前删除所有已提交的更新在数据压缩过程中，会创建一个新的Memtable来处理数据压缩开始然后，旧的Memtable以类似于LSM树的方式合并到SSTable我们不是用新的内容覆盖数据块，而是制作新的副本并在副本上应用更新。正如我们将在第3节中解释的那样，在数据压缩开始时已经开始的事务可能仍然需要访问旧的SST表。因此，这种方法最大限度地减少了对正在进行的事务的请注意，T节点的功能是双重的：它作为事务管理器执行时间戳分配，事务验证和提交更新;然而，它作为日志结构存储层的内存部分。 这种架构允许通过内存部分进行低延迟和高吞吐量的插入、删除和更新。日志结构存储还实现了快速数据压缩，这对系统性能的影响非常小，因为它主要消耗网络带宽而不是T节点最后，SolarDB使用数据复制来提供高可用性和对节点故障的抵抗能力。在SSTable中，每个tablet至少有三个副本，它们被分配到不同的S节点。复制还有助于在多个S节点之间实现更好的负载平衡：读请求可以访问任何一个副本。Memtable在两个备份T节点上复制。数据复制和节点故障的详细信息将在3.2节中讨论。3交易管理SolarDB利用OCC和MVCC来提供快照隔离[2]。快照隔离在现实世界的应用中被广泛采用，并且许多数据库系统（例如，PostgreSQL 9.1之前的版本，Tell [19]）主要支持快照隔离，尽管它承认通过可序列化隔离防止的写偏斜异常 本文主要关注SolarDB对快照隔离的支持，我们将可序列化隔离的讨论留到以后的工作中进行。为了确保持久性并支持系统恢复，重做日志条目在事务提交之前被持久化到T节点上的持久存储中（即，写前记录）。3.1支持快照隔离SolarDB 通过 结合OCC和 MVCC实现 快照隔 离[2 ，15] 。更 具体 地说，MVOCC 由Memtable上的T节点使用。回想一下，Memtable中的每条记录都维护多个版本。允许事务tx访问在其开始时间之前创建的版本，该开始时间称为读取时间戳，可以是其第一次读取之前的任何时间戳在十一：6T. Zhu等人ACM Transactions on Storage，Vol.号152、第十一条。出版日期：2019年6月∈在提交时间，事务获得提交时间戳，该提交时间戳应该大于其他事务的任何现有的 读取 时间 戳 或提 交时 间戳 事 务tx 还 应该 验证 在tx 的read-timestamp 和 commit-timestamp之间没有其他事务写入任何数据否则，tx应该被中止以避免丢失更新异常[2]。当一个事务被允许提交时，它通过创建一个标记有其提交时间戳的新版本来更新记录使用MVOCC，对于数据库中的所有记录，SSTable包含由具有提交时间戳的事务创建的最新版本，其小于上次数据压缩时间（压缩时间戳）。Memtable包含由commit-timestamps大于precision-timestamps的事务创建的较新版本T节点使用一个全局的，单调递增的计数器来分配transactions的时间戳SolarDB中的事务处理被分解为三个阶段：处理、验证和写入/提交。处理. 在处理阶段，P单元的工作线程在事务t x中执行用户定义的逻辑，并从T节点和S节点读取t x中涉及的记录。事务tx在第一次与T节点通信时获得其读时间戳（简称rtx用于处理tx的P单元读取tx中涉及的每个记录的最新版本，其时间戳小于rtx。特别是，它首先从Memtable检索最新版本。如果正确的版本（即，时间戳小于rtx）不被获取，它继续访问相应的SST可读取记录的tablet。在此过程中，tx将其写入缓冲在P单元上当tx完成了它所有的业务逻辑代码时，它就进入了第二阶段。P单元向T节点发送包含tx的写集合的tx的提交请求然后，T节点将验证并提交事务。确认中验证阶段在T节点上进行，其目的是识别t x和其他事务之间的潜在写-写冲突。在验证阶段期间，T节点尝试锁定Memtable上的t x的写集中的所有记录（表示为wx），并针对任何记录r w x检查Memtable中是否存在时间戳大于rt x的任何更新版本的r。当tx成功地持有所有锁并且wx 如果找到，则T节点保证tx没有写-写冲突并且可以继续提交。否则，T节点将由于丢失更新异常而中止tx因此，在验证之后，T节点确定是提交还是中止事务tx。如果T节点决定中止tx，则T节点将中止决定发送回在tx的提交请求中发送的P单元。P单元将简单地删除写集合wx。否则，事务tx继续到第三阶段。写作/承诺。在这个阶段，事务tx首先从Memtable中的写集wx为每条记录创建一个新版本，并临时将其事务IDx写入每条记录的头字段。接下来，T节点通过递增全局计数器来获得tx然后，T节点针对Memtable中具有事务ID x的每个记录用tx的来自WX的那些）。最后，T节点释放tx持有的所有锁。正确性。 给定一个具有read-timestamp（rtx）和commit-timestamp（ctx）的事务t x，So- larDB保证tx读取数据库的一致快照，并且没有丢失更新异常。一致的快照读取。首先，tx看到在rtx之前提交的所有事务所写的版本，因为那些事务已经完成了为它们的写集合创建新版本，并且在tx被分配rtx作为其读时间戳之前获得了它们的提交时间戳。其次，系统中的剩余事务总是使用大于rtx的提交时间戳来写入新的数据版本。因此，它们的更新不会被tx读取。因此，tx始终在一致的快照上操作SolarDB：面向分布式日志结构存储的共享数据库十一：7ACM Transactions on Storage，Vol.号152、第十一条。出版日期：2019年6月∈∈防止丢失更新。当另一个事务为r w x创建了记录r的新版本，并且该版本的时间戳在（rt x，ct x）的范围内时，发生丢失更新异常。假设版本是由ty创建的。有两种情况：(1) 在Tx尝试锁定R之前，TY获得了记录R上的锁定因此，tx只有在ty提交并创建了一个新版本的r之后才能得到锁。因此，tx将在验证期间看到r的新版本并被中止。(2) ty在tx已经保护锁之后获取r上的锁。在这种情况下，ty将无法获得提交时间戳，直到它获得了由tx释放的锁，这意味着cty>ctx。这与新版本r的时间戳在（rtx，ctx）内的假设相矛盾。回想一下，记录r wy的新版本的时间戳被分配了ty的提交时间戳。3.2系统恢复P单元故障 当P单元失败时，如果事务尚未发出提交请求，则该事务可能仍处于处理阶段。这样的事务被视为中止。对于处于验证或提交阶段的事务，它们可以由T节点终止，而无需与失败的P单元通信。T节点将正确验证此类别中的事务快照隔离和持久性都得到了保证，并且在P单元失败后，所有受影响的事务都会正确结束T节点失效T节点将其Memtable保存在主存中。为了避免数据丢失，它使用WAL并强制重做日志记录到其磁盘存储中的所有提交的事务。当T节点失败时，它能够通过重放重做日志来恢复提交的数据此外，为了避免成为单点故障，SolarDB还使用主备份方案将所有重做日志记录复制到T节点的两个副本每个副本通过重放日志来捕获T节点的内容当主T节点崩溃时，所有活跃运行的事务都被终止，并且进一步的事务提交请求被快速重定向到辅助T节点因此，SolarDB能够在几秒钟内从T节点故障中恢复并恢复服务S节点故障S节点故障不会导致数据丢失，因为S节点将所有平板电脑保存在磁盘上。单个S节点的故障不会对系统的可用性产生负面影响，因为所有tablet在不同的S节点上至少有三个副本。当一个S节点崩溃时，P单元仍然可以从另一个S节点上的副本访问平板电脑的记录。3.3数据压缩中的快照隔离数据压缩可节省Memtable使用的内存。它通过将T节点上的当前Memtable合并到S节点上的SSTable来生成一个新的SSTable数据压缩。 Le t m0和s0是当前的Memtable和SSTable，rees pectiv el y。 数据压缩通过合并m 0和s 0创建一个新的SS表s1。 Memtablem1在T节点上替换m0，以服务于四个事务写入。 注意，s1包含最初存储在m0或s0中的每个数据的最新版本，并且是数据库e的一致快照。 它指示存在用于压缩开始的时间戳tdc，使得在t dc之前提交的事务在s1中保持更新日期，并且在tdc之后提交的事务在m1中保持更新日期。当数据压缩开始时，T节点创建m1用于服务新的写入请求。当且仅当事务的验证阶段发生在数据压缩开始之前时，才允许事务将数据写入mT节点等待，直到所有这样的事务都已提交（即，不再有事务更新M0）。此时，S节点开始将m0与它们的本地tablet合并。S节点不会直接覆盖现有的tablet相反，它使用写时复制策略写入新的平板电脑。因此，正在进行的事务仍然可以照常读取s0。一个S-node十一：8T. Zhu等人ACM Transactions on Storage，Vol.号152、第十一条。出版日期：2019年6月图2. 数据压缩期间的数据访问当涉及m0中的一些记录的S节点上的tablet与来自m0的那些记录的新版本完全合并时，确认T节点。当所有新平板电脑都已创建时，数据压缩完成现在允许T节点丢弃m0并截断相关的日志记录。图2说明了如何在数据压缩期间提供读访问。对任何新提交的复制版本（在t_d_c之后）的读请求由m_l服务;或者，它由s_l服务。 在访问S1时存在两种情况：如果请求的重新编码在已经完成合并过程的tablet中，则只有S1中的新ablet才需要被访问（例如，例如， 如果所请求的记录在仍处于合并过程中的平板中（例如，图2中的Tablet 2），我们需要从b0和m0访问该tablet。并发控制。在数据压缩过程中需要支持快照隔离。执行以下并发控制方案首先，如果事务在数据压缩操作启动之前开始其验证阶段，则它将验证并写入m0，如第3.1节所述。第二，数据压缩操作可以仅当在数据压缩操作被发起之前开始验证的每个事务中止或获取提交时间戳时才获取时间戳tdc第三，一旦所有提交时间戳小于tdc的事务完成，就可以开始数据压缩第四，如果事务tx在数据压缩操作被发起之后开始其验证阶段，则它可以仅在数据压缩操作获得其时间戳tdc之后开始验证。事务tx对m0和m1都进行验证，但只对m1进行写入。在验证期间，tx为它的写集合wx中的每个记录获取m0和m1上的锁，并验证相对于tx的读时间戳没有创建更新的版本一旦通过验证，tx将其更新写入m1，之后tx被允许获取其提交时间戳。第五，如果一个事务获取了一个大于tdc的读时间戳，那么它只对m1正确性。通过为每个事务分配读取时间戳来保证一致的快照读取。它的正确性遵循与正常事务处理相同的分析上述过程还可以防止在数据压缩期间丢失更新考虑一个transsac- tiontx，其中read-timestamprtx和commit-timestampctx。假设存在另一个事务ty，其已经在rtx和ctx之间提交（即，rtxctyctx），并且ty已经写入了tx稍后在ty已经提交之后也将写入的一些记录<<我们只需要考虑ctytdcctx的情况，因为否则，丢失更新异常被保证不会发生，因为tx和ty都将针对相同的Memtables集合（m0和/或m1）进行验证<<这导致了rtxctytdcctx的情况。<<<因此，tx将针对m0和m1进行验证，并且它将保证看到ty所做的已提交更新。因此，tx将被中止，因为它将找到至少一个时间戳大于其读取时间戳rtx的记录。因此，即使数据压缩与其他事务并发运行，也不会发生丢失更新SolarDB：面向分布式日志结构存储的共享数据库十一：9ACM Transactions on Storage，Vol.号152、第十一条。出版日期：2019年6月复苏当节点在主动数据压缩期间发生故障时，需要恢复机制来正确地恢复m0和m1。数据压缩充当恢复的边界。transs-在最新数据压缩开始之前提交的操作（当 发生了碰撞）应该被重新播放到m0，而在那之后提交的那些应该被重新播放到m1。此外，我们不需要重放在最新完成的数据压缩完成之前提交的任何事务，因为它们已经通过该完成的数据压缩的合并操作成功地保持到SSTable。为了实现这一点，当数据压缩开始时，压缩开始日志条目（CSLE）被持久化到磁盘存储上的日志中，以记录其tdc。当数据压缩结束时，压缩结束日志条目（CELE）被持久化，其tdc用作标识该数据压缩的唯一标识符。也就是说，任何P单元的故障都不会导致数据丢失或影响数据压缩。当T节点发生故障，恢复过程将从CSLE中重播时间戳为tdc的日志，可以在最后的CELE中找到最初，它将日志重放到Memtablem0中。当遇到下一个CSLE时，它创建一个新的Memtablem1，并将后续的日志条目重放到m1中。m0到S节点的合并过程在m0从恢复恢复后继续如果S节点在数据压缩期间发生故障，则不会丢失数据，因为S节点使用磁盘存储。但是，当S节点β发生故障时，它可能仍然在创建新的平板电脑的过程因此，当β恢复并重新加入集群时，它包含合并过程中产生的旧SST可执行的如果系统已经完成了数据压缩（使用故障节点的其他副本），则新的SST表中的每个tablet至少有一个副本。恢复的节点β简单地从远程S节点复制必要的片剂。如果数据压缩尚未完成，则β将通过从T节点读取m0仓库管理员。 在数据压缩期间，m0和s0（当前压缩开始前的扩展表）保持只读，而s1和m1保持更新。 当压缩完成时，m0和s0将被截断。 但是，只有当不再需要任何读访问时，才能截断该数据。为此，即使压缩已经完成，m0也可以被一些读时间戳小于tdc的T节点记住任何事务最后一次使用m0的时间。超时机制用于避免任何transactions闲置太长时间。当所有这样的事务已经结束或超时时，T节点截断m 0。 然而，m0和s0也可以由其读取时间戳大于tdc的事务使用。您操作的快照可以由s0、m0和m1或s1和m1进行复制。 在压实完成之前，s1d oe不存在物理上的存在。 Henc e，事务需要从m0、s0和m1中获取最新的数据版本。 压实完成后，可供读取。因此，具有大于tdc的读取时间戳的那些事务可以在该点处立即将其访问切换到m1和s1，并且不再需要访问m0和s0。总之，当数据压缩已经完成并且没有事务具有小于tdc的读取时间戳时，可以截断m0和s0。4优化对于SolarDB来说，减少P单元、S节点和T节点之间的网络通信开销是很重要的为了实现更好的性能，我们设计了细粒度的数据访问方法之间的P-单元和存储节点。4.1优化数据访问事务需要读取的正确数据版本由事务的读取时间戳定义因此，SolarDB不知道应该从哪里读取记录（或记录的列），十一：T. Zhu等人ACM Transactions on Storage，Vol.号152、第十一条。出版日期：2019年6月P单元必须访问S节点上的SSTable和T节点上的Memtable，以确保读一致性（尽管其中一个将被证明是不正确的版本）。在这里，我们首先在P单元上提出了一个SST可缓存，以减少P单元和S节点之间的数据访问。然后，设计了一个异步位数组来帮助P单元识别对T节点的潜在无用数据访问。4.1.1SSTable Cache。P单元需要从SST表中提取记录。这些远程数据访问可以使用数据高速缓存来有效地服务SSTable的不变性使得在P-unit上构建缓存池变得容易缓存池保存从SSTable获取的记录，并提供对相同记录的数据缓存池是一个简单的键值存储。键存储主键，值保存相应的记录。所有条目都由哈希映射索引P单元上的读请求首先从其缓存池中查找记录只有当存在高速缓存未命中时，P单元才从S节点拉取记录并将其添加到其高速缓存池。缓存池使用标准的缓冲区替换算法来满足给定的内存预算约束。由于SSTable是不可变的，并且持久化在磁盘上，因此SolarDB不会持久化缓存池。当从缓存池中提取的SST表在数据压缩操作后过时时，缓存池中的缓存会过期当这种情况发生时，P单元构建一个新的缓存池。4.1.2异步位数组。 SSTable是整个数据库的一致快照。在COM中，Memtable只存储最后一次数据压缩后新创建的数据版本，这必须是数据库的一小部分。因此，发送到T节点的读请求很可能不会从T节点获取任何内容我们称这种现象为空读。这些要求是无用的，并产生负面影响。它们增加了延迟并消耗了T节点为了避免产生许多空读取，T节点使用一种称为memo结构的简洁结构来编码Memtable中项目的存在。该结构定期同步到所有P单位每个P单元检查其本地备忘录以识别潜在的空读段。memo结构是一个位数组。在位数组中，每个位用于表示图形输入板的列是否已被修改。换句话说，如果输入板T的任何记录的列C被修改，则对应于（T，C）的位被打开。否则，位被关闭。其他设计选择也是可能的，例如对记录级信息进行编码，但这将显著增加位阵列的大小SolarDB保留了两种类型的位数组。第一种类型是T节点上的实时位数组，表示为b。第二种类型是每个P单元上的异步位数组，它是b在某个时间戳t的副本，表示为bJ=bt，其中bt是b在时间t的版本。P单元查询bJ以在不接触T节点的情况下找到潜在的空读段。在T节点上，当第一次为记录的任何列创建新版本时，b会更新。请注意，当为Memtable中已经存在的数据项（列值）创建版本时，没有必要更新b，因为它已经在b中编码。每个P单元周期性地从T节点拉取b以刷新和同步其本地副本bJ。在对P单元p上的事务tx的查询处理期间，p检查其局部bJ以确定T节点是否包含Tx如果对于这样的列C，bJ中的（T，C）为0，则p将请求视为空读取并且不接触T节点;否则，p将发送请求以从T节点拉取数据显然，由于编码的粒度，查询bJ导致误报，并且这样的误报将导致对T节点的空读取。考虑在tabletT中，行r1更新了其列C，而行r2没有更新其列C。当读取r 2的列C时，P单元可能发现b j中的位（T，C）被设置，而r 2没有版本。C在T节点上。事实上，前SolarDB：面向分布式日志结构存储的共享数据库十一：ACM Transactions on Storage，Vol.号152、第十一条。出版日期：2019年6月表1.物理计划中的可能操作读可记忆读取SST可读取写更新P单元上的本地缓冲区（本地操作）过程表达式、项目、排序、联接。. .（本地操作）化合物循环，分支方法对于读取密集型或只读列最有效。它们很少在位数组中打开位。查询bJ也可能返回假阴性，因为它没有与最新版本同步。b在T节点上。一旦出现假阴性，P单元可能会错过最新版本的它需要读取一些值，并最终使用不一致的快照。为了解决这个问题，事务必须在其验证阶段检查所有潜在的空读取。如果一笔交易看到如果在处理期间用于（T，C）的位在bJ中为0，则需要在验证期间检查该位在b如果先前由bJ识别的任何空读段不能由b确认，则必须通过读取Memtable中的最新版本来重新处理事务。假阴性是罕见的，因为b没有看到频繁的更新：它只在tabletT中的任何行第一次更新时才被更新。修改了C列。4.2事务编译SolarDB支持JDBC/ODBC连接和存储过程。后者采用一次性执行模型[26]，避免了客户端-服务器交互。这对DBMS造成了更多的处理负担，但可以实现服务器端优化[34，40，41]。SolarDB利用服务器端优化机会，设计了一种编译技术，通过生成优化的物理计划来减少事务处理期间的节点间执行图和依赖约束。当提供不同的输入参数和数据库快照时，存储过程可以编译为物理计划的不同实例。存储过程的物理计划（由P单元执行）表示为表1中的操作序列（嵌套结构，例如，分支或循环，可以被看作是复合操作）。读是通过远程过程调用实现的，而写和处理/计算是P单元上的本地函数调用因此，读取是优化网络通信的关键如果满足以下条件之一，则必须按顺序执行两个操作(1) 过程约束：两个操作具有数据/控制依赖性[21]。 这可以确保读取或写入的变量值是正确的，并且任何控制流都可以正确执行。(2) 访问约束：两个操作访问同一个数据库记录，其中一个操作是写操作。这种情况可以解释为对数据库中记录的特殊数据依赖性，这不受过程约束的影响如果两个操作不满足这两个约束中的任何一个，它们可以被任意重新排序。在附录中，我们将证明，如果重新排序的物理计划不违反前面的约束，则它具有与原始计划相同的语义一对操作之间的约束由它们的变量和记录读/写集决定操作使用的变量可以在编译期间轻松找到然而，对于数据库记录，情况并非总是如此，因为记录id可能直到运行时才确定十一：T. Zhu等人ACM Transactions on Storage，Vol.号152、第十一条。出版日期：2019年6月图3. 操作顺序和执行图示例在实践中，如果两个操作访问同一个表，其中一个是写操作，我们将其视为潜在的访问约束。然后，我们可以将操作序列表示为执行图，其中节点是操作，边是约束并表示执行顺序（图3）。我们还支持分支和循环作为复合操作。如果复合操作包含多个读取，则它是复杂操作如果它只包含一个读操作，则复合操作被视为与该单个读操作相同类型的读操作（在表1中定义）否则，复合操作被视为局部操作。我们采用循环分布[14]将一个大循环分成多个小循环，以便更具体地分类对于分支块中的读操作，它可以被移出以进行推测性执行，因为读操作没有副作用，因此即使不采取相应的分支，也可以安全地执行Memtable reads。为了减少到T节点的RPC的数量，如果它们之间没有约束，我们可以将多个Memtable read分组在一个到T节点的RPC中。它节省了P单元和T节点之间的多次往返，从而减少了事务延迟。找到分组的Memtable读段可以在物理计划上的两次通过中完成（参见算法1）。第一遍通过在执行图上通过BFS将受某些Memtable读取约束的所有操作标记为块来找到所有未约束的Memtable读取未约束的Memtable读取被标记为组。复杂操作不分组，因为嵌套结构本身内的Memtable读取之间可能存在约束第二遍从无约束的Memtable读取开始，并将它们之前的所有本地操作标记为组。在执行事务逻辑之前，所有在第2次传递中标记的本地操作都会首先执行。然后，在传递1中标记的Memtable读取在单个RPC请求中发送到T节点。预执行SSTable读取。 甚至在事务从T节点获得其读时间戳之前，也可以发出SSTable读取，因为SSTable中一次只有一个有效快照。请注意，即使在数据压缩期间，此时我们已经拍摄了快照s0和s1，对于平板电脑上的重新读取请求，是读取s0和m0还是s1，都可以仅通过平板电脑是否已经完成合并来确定，这与读取时间戳无关。因此，我们可以在执行