共计 23940 个字符，预计需要花费 60 分钟才能阅读完成。
ABSTRACT
混合事务和剖析解决（HTAP）数据库须要独自处理事务和剖析查问，以打消它们之间的烦扰。为此，须要保护为两种类型的查问指定的不同数据正本。然而，为存储系统中的分布式正本提供统一的视图是具备挑战性的，因为剖析申请能够无效地从大规模和高可用性的事务工作负载中高效读取统一和新的数据。
为了迎接这一挑战，咱们倡议扩大复制的基于状态机的统一统一算法，为 HTAP 工作负载提供统一的正本。基于这一新鲜的想法，咱们提出了一个基于漂流的 HTAP 数据库：TiDB。在数据库中，咱们设计了一个多层存储系统，该零碎由行存储和列存储组成。行存储基于 Raft 算法构建。它能够扩大，以实现高可用性的事务申请的更新。特地是，它异步地将 Raft 日志复制到学员中，学员将行格局转换为元组列格局，从而造成实时可上座的列存储。此列存储容许剖析查问，以便无效地读取陈腐且统一的数据，同时与行存储区中的事务强隔离。基于此存储系统，咱们构建一个 SQL 引擎来解决大型分布式事务和低廉的剖析查问。SQL 引擎以最佳形式拜访数据的行格局和列格局正本。咱们还包含一个弱小的剖析引擎 TiSpark，以帮忙 TiDB 连贯到 Hadoop 生态系统。综合试验表明，TiDB 实现了隔离的高性能非 der CH-benCHmark，这是一个专一于 HTAP 工作负载的基准。
- INTRODUCTION
关系数据库管理系统（RDBMS）受其关系模型、弱小的事务性保障和 SQL 接口的欢送。它们在传统利用中被宽泛采纳，如业务零碎。然而，旧的 RDBMS 不反对可伸缩性和高可用性。因而，在 2000 年初 [11]，互联网应用程序更喜爱 NoSQL 零碎，如谷歌大表[12] 和 DynamoDB[36]。NoSQL 零碎放宽了一致性要求，并提供高可扩展性和代替数据模型，如键值对、图形和文档。然而，许多应用程序还须要弱小的事务、数据一致性和 SQL 接口，因而呈现了 NewSQL 零碎。NewSQL 零碎（如 CockroachDB [38] 和 GoogleSpanner [14]）为在线事务处理（OLTP）读 / 写工作负载提供了 NoSQL 的高可扩展性，并且依然保护对交易的 ACID 保障 [32]。此外，基于 SQL 的在线剖析解决（OLAP）零碎正在疾速开发，就像许多 SQL on Hadoop 零碎 [16] 一样。
这些零碎遵循 ” 一刀切 ” 的范式[37]，应用不同的数据模型和技术，用于 OLAP 和 OLTP 的不同目标。然而，多个零碎开发、部署和保护的老本十分低廉。此外，实时剖析最新版本的数据也极具吸引力。这就在工业界和学术界引起了混合 OLTP 和 OLP（HTAP）零碎[30]。HTAP 零碎应实现可扩展性、高可用性和跨国一致性，如 NewSQL 零碎。此外，HTAP 零碎须要高效地读取最新数据，以确保 OLTP 和 OLAP 申请的吞吐量和提早，满足两项额定要求：新鲜度和隔离性。
新鲜度是指剖析查询处理最近数据的过程 [34]。实时剖析最新数据具备极大的业务价值。然而，在某些 HTAP 解决方案中，例如基于提取 - 转换加载（ETL）解决的解决方案，它不能保障。通过 ETL 流程，OLTP 零碎定期向 OLAP 零碎从新更新一批最新数据。ETL 须要几个小时或几天的工夫，因而无奈提供实时剖析。ETL 阶段能够通过将最新更新流式传输到 OLAP 零碎来替换，以缩小同步工夫。然而，因为这两种办法短少全局数据治理模型，因而思考一致性语义更为简单。与多个零碎连贯会引入额定的开销。
隔离是指保障独自的 OLTP 和 OLAP 查问的隔离性能。某些内存中数据库（如 HyPer [18]）容许剖析查问从同一服务器上的事务处理读取最新版本的数据。只管此办法提供了新的数据，但它无奈同时实现 OLTP 和 OLAP 的高性能。这是因为数据同步处罚和工作负载烦扰。通过运行 CH-benCHmark[13]（Hy-Per 和 SAP HANA 上的 HTAP 基准），在 [34] 中钻研了这种效应。钻研发现，当零碎独特运行剖析查问时，其最大可达到的 OLTP 吞吐量会显著升高。SAP HANA [22] 吞吐量至多缩小了三倍，HyPer 至多缩小了五倍。相似的后果在 MemSQL [24] 中失去证实。此外，如果内存中的数据库仅部署在单个服务器上，则无奈提供高可用性和可伸缩性。
为了保障隔离性能，有必要在不同的硬件资源上运行 OLTP and OLAP 申请。根本艰难在于在单个零碎中保护来自 OLTP 工作负载的 OLAP 申请的最新正本。此外，零碎须要放弃更多复制之间的数据一致性。请留神，可用性 [29] 还须要保护统一的正本。能够应用家喻户晓的协商一致算法（如 Paxos [20] 和 Raft [29]）实现高可用性。它们基于复制的状态计算机来同步正本。能够扩大这些共识算法，为 HTAP 工作负载提供统一的正本。据咱们所知，这个想法以前没有钻研过。
依照这个想法，咱们提出了一个基于漂流的 HTAP 数据库：TiDB。它将专用节点（称为学员）引入 Raft 共识算法。学员异步从领导节点复制事务日志，为 OLAP 查问结构新的正本。特地是，学员将日志中的行格局元数转换为列格局，以便正本更适宜剖析查问。这种日志复制在领导者节点上运行的事务查问上很少产生开销。此外，这种复制的提早十分短，能够保障 OLAP 的数据新鲜度。咱们应用不同的数据正本别离解决 OLAP 和 OLTP 申请，以防止它们之间的烦扰。咱们还能够基于行格局和列格局的数据正本优化 HTAP 申请。基于 Raft 协定，TiDB 提供高可用性、可扩展性和数据一致性。
TiDB 提供了一个翻新的解决方案，可帮忙基于共识算法的 NewSQL 零碎演变为 HTAP 零碎。New-SQL 零碎通过复制 Google Spanner 和 Cockroach DB 等数据库，确保 OLTP 申请的高可用性、可扩展性和数据持久性。它们通过通常来自共识算法的复制机制跨数据正本同步数据。基于日志复制，NewSQL 零碎能够提供专用于 OLAP 申请的列正本，以便它们能够像 TiDB 那样独自反对 HTAP 申请。
咱们的奉献如下。
•咱们倡议基于共识算法构建 HTAP 零碎，并实现了基于 Raft 的 HTAP 数据库 TiDB。这是一个开源我的项目 [7]，为 HTAP 工作负载提供高可用性、一致性、可扩展性、数据新鲜度和隔离性
•咱们将学员角色引入 Raft 算法，以生成用于实时 OLAP 查问的列存储。
•咱们施行多 Raft 存储系统并优化其读取和写入，以便零碎在扩大到更多节点时提供高性能。
•咱们为大型 HTAP 查问定制 SQL 引擎。引擎能够最佳地抉择应用基于行的存储和列存储。
•咱们应用 HTAP 基准 CH-benCHmark 进行综合试验，以评估 TiDB 在 OLTP、OLAP 和 HTAP 方面的体现。
本文的其余部分按如下形式组织。咱们在第 2 节中形容了次要思维，基于 Raft 的 HTAP，并在第 3 节中阐明了 TiDB 的体系结构。第 4 节第 5 节论述了 TiDB 的多负载存储和 HTAP 引擎。试验评估在第 6 节中介绍。咱们总结了第 7 节中的相干工作。最初，咱们在第 8 节中完结咱们的论文。
- RAFT-BASED HTAP
共识算法（如 Raft 和 Paxos）是构建统一、可扩大且高度可用的分布式系统的根底。其劣势在于应用复制的状态机在服务器之间实时牢靠地复制数据。咱们调整此性能，将数据复制到不同的服务器，用于不同的 HTAP 工作负载。这样，咱们保障 OLTP 和 OLAP 工作负载彼此隔离，但 OLAP 申请也会为数据提供全新且统一的视图。据咱们所知，以前没有应用这些共识算法来构建 HTAP 数据库的工作。
因为 Raft 算法设计为易于了解和实现，因而咱们专一于 Raft 扩大，实现生产就绪的 HTAP 数据库。如图 1 所示，在高级别上，咱们的想法如下：数据存储在多个 Raft 组中，应用行格局提供事务查问。每个小组由一名领导者和追随者组成。咱们增加每个组的学员角色，以异步地从领导者复制数据。这种办法是低开销，并保持数据一致性。复制到学员的数据将转换为基于列的格局。查问优化器被扩大，以摸索拜访基于行和基于列的正本的物理打算。
在规范 Raft 组中，每个关注者都能够成为提供读写申请的领导者。简略地增加更多的追随者，因而，不会隔离资源。此外，增加更多关注者将影响组的性能，因为领导者必须期待来自较大仲裁节点的响应，而后能力响应客户端。因而，咱们向 Raft 共识算法引入了一个学员角色。学员不参加领导者选举，也不参加日志复制的法定人数。从领导者到学员的日志复制是异步的; 领导者不须要期待胜利，而后再响应客户端。领导者和学员之间的强一致性在读取期间强制执行。依据设计，领导者和学员之间的日志复制提早较低，如评估局部所演示。
事务查问须要高效的数据更新，而剖析查问（如联接或聚合）须要读取列的子集，但须要读取大量行。基于行的格局能够利用索引无效地为事务查问服务。基于列的格局能够无效地利用数据压缩和矢量化解决。因而，在复制给 Raft 学员时，数据会从基于行的格局转换为基于列的格局。此外，学习者能够部署在独自的物理资源中。因而，事务查问和剖析查问在隔离资源中解决。
咱们的设计也提供了新的优化机会。因为数据在基于行的格局和基于列的格局之间保持一致，因而咱们的查问优化器能够生成拜访两个存储区的物理打算。
咱们提出了扩大 Raft 以满足 HTAP 数据库的新鲜度和隔离要求的想法。为使 HTAP 数据库生产准备就绪，咱们克服了许多工程挑战，次要包含：
（1）如何构建可扩大的 Raft 存储系统以反对高度并发读 / 写？如果数据量超过 Raft 算法治理的每个节点上的可用空间，咱们须要一个分区策略来在服务器上散发数据。此外，在根本 Raft 过程中，申请按程序解决，并且任何申请都必须在响应客户端之前由 Raft 节点的仲裁批准。此过程波及网络和磁盘操作，因而十分耗时。这种过头使领导者成为解决从新工作（尤其是在大型数据集上）的瓶颈
（2）如何以低提早将日志同步到学员中，以保持数据陈腐？正在执行的事务能够生成一些十分大的日志。这些日志须要在学员中疾速重播和实现，以便能够读取新的数据。将日志数据转换为列格局可能会因为架构不匹配而遇到谬误。这可能提早日志同步。
（3）如何无效地解决具备保障性能的事务和剖析查问？大型事务查问须要读取和写入散布在多台服务器中的大量数据。剖析查问也会耗费密集的从新源，不应影响联机事务。为了缩小执行开销，他们还须要在行格局存储和列格局存储上抉择最佳打算。
在以下各节中，咱们将具体论述 TiDB 的设计和实现，以应答这些挑战。
- ARCHITECTURE
在本节中，咱们将介绍 TiDB 的高级别构造，如图 2 所示。TiDB 反对 MySQL 协定，并且可由与 MySQL 兼容的客户端拜访。它有三个外围组件：分布式存储层、搁置驱动程序（PD）和计算引擎层。
分布式存储层由行存储（TiKV）和列存储（TiFlash）组成。从逻辑上讲，存储在 TiKV 中的数据是有序的键值映射。每个元组都映射到键值对。密钥由其表 ID 和行 ID 组成，值是理论行数据，其中表 ID 和行 ID 是惟一的整数，行 ID 未来自主键列。例如，蕴含四列的元组编码为：
Key:{table{tableID}record{rowID}}
Value:{col0, col1, col2, col3}
为了横向扩大，咱们采取范畴分区策略，将大键值映射拆分为许多间断范畴，每个区域称为区域。每个区域都有多个正本，用于高可用性。Raft 共识算法用于放弃每个区域正本之间的一致性，从而造成一个 Raft 组。不同 Raft 组的领导者异步将数据从 TiKV 复制到 TiFlash。TiKV 和 TiFlash 能够部署在独自的物理资源中，因而在处理事务和剖析查问时提供隔离。
搁置驱动程序（PD）负责管理区域，包含提供每个键的区域和物理地位，并主动挪动区域以均衡工作负载。PD 也是咱们的工夫戳预言家，提供严格减少和寰球惟一的工夫戳。这些工夫戳也用作咱们的交易 ID。PD 可能蕴含多个 PD 成员，用于鲁棒性和性能。PD 没有长久状态，在启动时，PD 成员从其余成员和 TiKV 节点收集所有必要的数据。
计算引擎层是无状态的，是可扩大的。咱们定制的 SQL 引擎具备基于老本的查问优化器和分布式查问执行器。TiDB 实现了基于浸透器 [33] 的两阶段提交（2PC）协定，以反对事务处理。查问优化器能够依据查问最佳抉择从 TiKV 和 TiFlash 读取。
TiDB 的体系结构满足 HTAP 数据库的要求。TiDB 的每个组件都设计为具备高可用性和可扩展性。存储层应用 Raft 算法实现数据正本之间的一致性。TiKV 和 TiFlash 之间的低提早复制使剖析查问可能应用新的数据。查问优化器以及 TiKV 和 TiFlash 之间的强一致性数据可提供疾速的剖析查询处理，对事务处理影响很小。
除了上述组件外，TiDB 还与 Spark 集成，这有助于集成存储在 TiDB 和 Hadoop 分布式文件系统（HDFS）中的数据。TiDB 具备一组丰盛的生态系统工具，用于将数据导入 TiDB 并导出数据，以及将数据从其余数据库迁徙到 TiDB。
在以下局部中，咱们将对分布式存储层、SQL 引擎和 TiSpark 进行深刻深入探讨，以演示 TiDB（一个生产就绪的 HTAP 数据库）的性能。
- MULTI-RAFT STORAGE
图 3 显示了 TiDB 中分布式存储层的体系结构，其中具备雷同形态的对象表演雷同的角色。存储层由基于行的存储、TiKV 和基于列的存储 TiFlash 组成。存储将一个大表映射到一个大键值映射，该映射被拆分为存储在 TiKV 中的多个区域。每个区域应用 Raft 共识算法来放弃正本之间的一致性，以实现高可用性。当数据复制到 TiFlash 时，多个区域能够合并到一个分区中，以便于表扫描。通过异步日志复制，TiKV 和 TiFlash 之间的数据保持一致。因为多个 Raft 组治理分布式存储层中的数据，因而咱们称之为多 Raft 存储。在以下各节中，咱们将具体介绍 TiKV 和 TiFlash，重点介绍优化，使 TiDB 成为生产就绪的 HTAP 数据库。
4.1 Row-based Storage (TiKV)
TiKV 部署由许多 TiKV 服务器组成。应用 Raft 在 TiKV 服务器之间复制区域。每个 TiKV 服务器都能够是不同区域的 Raft 领导者或跟随者。在每个 TiKV 服务器上，数据和元数据都保留到 RocksDB，这是一个可嵌入的、长久的、键值存储 [5]。每个区域都有可配置的最大大小，默认状况下为 96 MB。Raft 领导服务器的 TiKV 服务器解决相应区域的读 / 写申请
当 Raft 算法响应读写申请时，在领导者及其跟随者之间执行根本的 Raft 过程：
（1）区域领导接管来自 SQL 引擎层的申请。
（2）领导者将申请附加到其日志。
（3）领导者将新的日志条目发送给其关注者，而关注者又将条目附加到其日志中。
（4）领导者期待其追随者做出回应。如果节点的仲裁响应胜利，则领导者将 commit 申请并在本地利用它。
（5）领导者将后果发送给客户端，并持续解决传入的申请。
此过程可确保数据一致性和高可用性。然而，它不提供无效的性能，因为这些步骤按程序执行，并且可能会产生较大的 I/O 开销（磁盘和网络）。以下各节介绍咱们如何优化此过程以实现高读 / 写吞吐量，即解决第 2 节中形容的第一个挑战。
4.1.1 Optimization between Leaders and Followers
在上述过程中，第二步和第三步能够并行进行，因为它们之间没有依赖关系。因而，领导者在本地追加日志，并同时向关注者发送日志。如果在领导者追加日志失败，但关注者仲裁胜利追加日志，则依然能够提交日志。在第三步中，当向关注者发送日志时，领导者会缓冲日志条目，并分批将其发送给其关注者。发送日志后，领导者不用期待关注者响应。相同，它能够假如胜利，并发送更多日志与预测的日志索引。如果产生谬误，领导者将调整日志索引并从新发送复制申请。在第四步中，利用已提交日志条目标领导能够由不同的线程异步解决，因为在此阶段，一致性没有危险。根据上述优化，Raft 过程将更新如下：
（1）领导者接管来自 SQL 引擎层的申请。
（2）领导者将相应的日志发送给关注者，并并行地在本地追加日志。
（3）领导者持续收到客户的申请，并从新执行步骤（2）。
（4）领导者提交日志并将其发送到要利用的另一个线程。
（5）利用日志后，领导者将后果返回给客户端。
在此最佳流程中，来自客户端的任何申请仍运行所有 Raft 步骤，但来自多个客户端的申请并行运行，因而总体吞吐量会减少。
4.1.2 Accelerating Read Requests from Clients
从 TiKV 领导读取数据提供线性语义。这意味着，当值在工夫 t 从区域领导读取时读取时，领导者不得在 t 之后返回读取申请值的晚期版本。这能够通过应用如上所述的 Raft 实现：为每个读取申请收回日志条目，并期待该条目在返回前提交。然而，此过程十分低廉，因为日志必须在 Raft 组中的大多数节点上复制，这会造成网络 I/O 的开销。为了进步性能，咱们能够防止日志同步阶段。
Raft 保障领导者胜利写入数据后，领导者能够响应任何读取申请，而无需跨服务器同步日志。然而，在领导者选举后，领导者角色可能会在 Raft 组中的服务器之间挪动。为了实现来自领导者的读取，TiKV 实现了以下读取优化，如 [29] 中所述。
第一种办法称为读取索引。当领导者响应读取申请时，它会将以后提交索引记录为本地读取索引，而后向关注者发送检测信号音讯以确认其领导角色。如果它的确是领导，则一旦利用的索引大于或等于读取索引，它就能够返回该值。此办法可进步读取性能，但会导致很少的网络开销。
另一种办法是租约读取，它缩小了由读取索引引起的网络过头心跳。领导者和追随者批准租赁期，在此期间，追随者不收回选举申请，以便不会更改领导者。在租赁期间，领导者能够响应任何读取申请，而无需连贯到其关注者。如果每个节点上的 CPU 时钟差别并不很大，那么此办法成果良好。
除了领导者之外，关注者还能够响应来自客户的从新申请，这称为关注者浏览。跟随者收到读取申请后，它会向领导者询问最新的读取索引。如果本地利用的索引等于或大于读取索引，则跟随者能够将值返回给客户端; 如果本地利用的索引等于或大于读取索引，则跟随者能够将值返回给客户端。否则，它必须期待日志的利用。跟随者浏览能够加重热区领导者的压力，从而进步浏览性能。而后，通过增加更多关注者，能够进一步提高读取性能。
4.1.3 Managing Massive Regions
大量区域散布在服务器群集上。服务器和数据大小在动态变化，区域可能会群集在某些服务器中，尤其是领导者正本。这会导致某些服务器的磁盘适度应用，而其余服务器磁盘则是收费的。此外，服务器能够增加到群集或从群集中挪动。
若要在服务器之间均衡区域，打算驱动程序（PD）会安顿具备正本数量和地位限度的区域。一个要害的束缚是将一个区域的至多三个正本放在不同的 TiKV 实例上，以确保高可用性。PD 通过从服务器通过检测信号收集特定信息进行初始化。它还监督每台服务器的工作负载，并在不会影响应用程序的状况下将热区域迁徙到不同的服务器。
另一方面，保护海量区域波及发送检测信号和治理元数据，这可能会导致大量的网络工作和存储开销。然而，如果 Raft 组没有任何工作负荷，则不须要检测信号。依据区域工作负载的忙碌状况，咱们能够调整发送检测信号的频率。这升高了呈现网络提早或节点过载等问题的可能性。
4.1.4 Dynamic Region Split and Merge
一个大区域可能会变得太热，无奈在正当的工夫内浏览或书写。热区域或大区域应拆分为较小的区域，以便更好地调配工作负载。另一方面，许多地区可能很小，很少被拜访; 然而，零碎依然须要保护检测信号和元数据。在某些状况下，保护这些小区域会产生大量的网络和 CPU 开销。因而，有必要合并较小的区域。请留神，为了保护区域之间的程序，咱们仅在键空间中合并相邻区域。依据察看到的工作负荷，PD 动静地向 TiKV 发送拆分和合并命令。
拆分操作将区域划分为几个新的较小区域，每个区域涵盖原始区域中的间断键范畴。笼罩最右侧范畴的区域可重用原始区域的 Raft 组。其余区域应用新的 Raft 组。拆分过程相似于 Raft 过程中的失常更新申请：
（1）PD 向区域领导者收回拆分命令。
（2）收到拆分命令后，领导者将该命令转换为日志，并将日志复制到所有追随节点。日志仅包含拆分命令，而不是批改理论数据。
（3）一旦仲裁复制日志，领导者将提交拆分命令，该命令将利用于 Raft 组中的所有节点。利用过程包含更新原始区域的范畴和纪元元数据，以及创立新的区域以笼罩其余范畴。请留神，该命令以原子形式利用并同步到磁盘。
（4）对于拆分区域的每个正本，将创立一个 Raft 状态机并开始工作，从而造成一个新的 Raft 组。原始区域的领长将拆分后果报告给 PD。拆分过程实现。
请留神，当大多数节点提交拆分日志时，拆分过程将胜利。相似于提交其余 Raft 日志，而不是要求所有节点实现区域拆分。拆分后，如果对网络进行分区，则具备最近纪元的节点组将获胜。因为只须要元数据更改，因而区域分割的开销较低。拆分命令实现后，因为 PD 的惯例负载平衡，新拆分区域可能会跨服务器挪动。
合并两个相邻区域与拆分一个区域相同。PD 挪动两个区域的正本，以在独自的服务器上协调它们。而后，通过两阶段操作，将两个区域的合并正本合并到每台服务器上的本地区域; 也就是说，进行一个区域的服务，并将其与另一个区域合并。此办法与拆分区域不同，因为它不能应用两个 Raft 组之间的日志复制过程来约定合并它们。
4.2 Column-based Storage (TiFlash)
只管咱们优化了上述 TiKV 的读取数据，但 TiKV 中的行格局数据并不适宜疾速剖析。因而，咱们将列存储（TiFlash）合并到 TiDB 中。TiFlash 由学员节点组成，这些节点只从 Raft 组接管 Raft 日志，并将行格局的元组转换为列数据。他们不参加 Raft 协定来提交日志或选举领导者，因而它们很少在 TiKV 上产生开销。
用户能够应用 SQL 语句为表设置列格局正本：
ALTER TABLE x SET TiFLASH REPLICA n;
其中 x 是表的名称，n 是正本的数量。默认值为 1。增加列正本相似于向表增加异步列形索引。TiFlash 中的每个表被划分为多个分区，每个分区依据 TiKV 的几个间断区域笼罩一个间断的元组范畴。较大的分区便于范畴扫描。
4.2.1 Log Replayer
依据 Raft 算法，学员节点接管的日志是线性的。为了放弃已提交数据的线性语义，依据先出先出（FIFO）策略重播它们。日志重播有三个步骤：
（1）压缩日志：依据第 5.1 节中形容的事务模型，事务日志分为三种状态：预写、提交或回滚。回滚日志中的数据不须要写入磁盘，因而压缩过程会依据回滚日志删除有效的事后写入的日志，并将无效的日志放入缓冲区。
（2）解码元数：缓冲区中的日志被解码为行格局的元数，删除无关事务的冗余信息。而后，将解码的元数放入行缓冲区中。
（3）转换数据格式：如果行缓冲区中的数据大小超过大小限度或其工夫持续时间超过 val 间限度，则这些行格局的元数将转换为列数据并写入本地分区数据池。转换是指本地缓存架构，这些架构会定期与 TiKV 同步，如下文所述。
若要阐明日志重播过程的详细信息，请思考以下示例。咱们将每个 Raft 日志项形象为事务 ID 操作类型 transaction status[#committs]操作数据。依据典型的 DML，操作类型包含插入、更新和删除元组。事务状态可能事后写、提交或回滚。操作数据能够作为特定插入或更新的元组，也能够是已删除的密钥。
在表 1 所示的示例中，原始日志蕴含八个我的项目，它们尝试插入两个元组、更新一个元组和删除一个元组。然而插入 k1 会回滚，因而仅保留了八个原始日志项中的六个，其中三个元组被解码。最初，三个解码的元组被转换成五列：操作类型、提交工夫戳、键和两列数据。这些列将追加到增量树。
4.2.2 Schema Synchronization
要实时将元组转换为列格局，学员节点必须理解最新的架构。这种架构过程不同于 TiKV 上的无架构操作，它把元数编码为字节数组。最新的架构信息存储在 TiKV 中。为了缩小 TiFlash 向 TiKV 申请最新架构的数量，每个学员节点都保护一个架构缓存。
缓存通过架构同步器与 TiKV 的架构同步。如果缓存的架构已过期，则要解码的数据与本地架构之间存在不匹配，并且必须从新转换数据。架构同步的频率和架构不匹配的数量之间有一个衡量。咱们采取两阶段策略：
•定期同步：架构同步器定期从 TiKV 提取最新的架构，并利用更改到其本地缓存。在大多数状况下，这种长期同步会升高同步架构的频率。
•强制同步：如果架构同步器检测到不匹配的架构，它将被动从 TiKV 获取最新的架构。当元数和架构之间不同或列值溢出时，能够触发此状况。
4.2.3 Columnar Delta Tree
为了无效地写入和读取具备高直通投入的列数据，咱们设计了一个新的列存储引擎 Delta Tree，它立刻追加增量更新，而后将它们与每个分区的先前稳固版本合并。增量更新和稳固数据别离存储在增量树中，如图 4 所示。在稳固空间中，分区数据存储为块，每个区块都笼罩分区元组较小范畴。此外，这些行格局的元对按列存储。相同，增量间接追加到增量空间中，以 TiKV 生成它们的顺序排列。TiFlash 中柱数据的商店格局相似于 Parquet [4]。它还将行组存储到列块中。不同地，TiFlash 将行组的列数据及其元数据存储到不同的文件中以同时更新文件，而不是仅在 Parquet 中存储一个文件。TiFlash 只是应用常见的 LZ4 [2] 压缩数据文件来保留其磁盘大小。
新的传入增量是插入数据的原子批处理或删除的范畴。这些增量缓存到内存中并化为磁盘。它们按顺序存储，因而它们实现了提前写入日志（WAL）的性能。这些增量通常存储在许多小文件中，因而在读取时会导致较大的 IO 开销。为了降低成本，咱们定期将这些小增量压缩成一个更大的增量，而后将较大的增量刷新到磁盘中，并替换以前实现的小增量。传入增量的内存正本便于读取最新数据，如果旧增量达到无限大小，则删除它们。
读取某些特定元组的最新数据时，有必要将所有增量文件及其稳固的元组（即读取放大）合并，因为相干增量散布的地位并不当时晓得。因为读取大量文件，这样的过程十分低廉。此外，许多增量文件可能蕴含无用的数据（即空间放大），这些数据会节约存储空间并减慢将它们与稳固元组合并的速度。因而，咱们定期将增量合并到稳固空间中。每个增量文件及其相干区块都读取到内存中并合并。增量中插入的元组将增加到稳固中，批改后的元组将替换原始元组，并挪动已删除的元组。合并的区块以原子形式替换磁盘中的原始区块。
合并增量十分低廉，因为相要害在增量空间中是无序的。这种凌乱还减缓了将增量与稳固区块集成以返回读取申请的最新数据的速度。因而，咱们在增量空间的顶部构建一个 B+ 树索引。每个增量更新项都按其键和工夫戳排序插入 B+ 树中。此订单优先级有助于无效地查找一系列键的更新，或在响应读取申请时在增量空间中查找单个键。此外，B+ 树中的有序数据很容易与稳固区块合并。
咱们进行一项宏观试验，将 Delta Tree 的性能与 TiFlash 中的日志结构化合并（LSM）树 [28] 进行比拟，在该树依据 Raft 日志更新数据时读取数据。咱们设置了三个 TiKV 节点和一个 TiFlash 节点，在试验局部列出了硬件构造。咱们在 TiKV 上运行 Sysbench [6] 的惟一写入工作负载，并在 TiFlash 上运行 ” 从 sbtest1 中抉择计数（id）、count（k）”。为了防止数据压缩的大量写入放大，咱们应用通用压缩而不是程度款式压缩来实现 LSM 存储引擎。此实现在 ClickHouse [1] 中也采纳，这是一个面向列的 OLAP 数据库。
如表 2 所示，无论有 1 亿还是 2 亿个元组以及事务工作负载，从增量树读取的速度比 LSM 树快两倍。这是因为在增量树中，每个读取拜访最多在 B+ 树中索引的增量文件的一个级别，同时拜访 LSM 树中更多的适度映射文件。在不同的写入工作负载下，性能简直保持稳定，因为增量文件的比例简直雷同。尽管 Delta 树（16.11）的写入放大大于 LSM 树（4.74），但它也是能够承受的。
4.2.4 Read Process
与跟随者读取一样，学员节点提供快照隔离，因而咱们能够在特定工夫戳中从 TiFlash 读取数据。收到读取申请后，学员向其领导发送读取索引申请，以获取涵盖申请的工夫戳的最新数据。作为响应，领导者将援用的日志发送给学员，学员重播并存储日志。将日志写入 Delta 树后，将读取来自增量树的特定数据以响应读取申请。
- HTAP ENGINES
为了解决第 2 节中提到的第三个挑战，即解决大型事务和剖析查问，咱们提供了一个 SQL 引擎来评估事务和剖析查问。SQL 引擎调整 Percolator 模型，在分布式群集中实现乐观和乐观锁定。SQL 引擎通过应用基于规定和老本的优化器、索引和将计算推送到存储层来减速剖析查问。咱们还施行 TiSpark 与 Hadoop 生态系统连贯，并加强 OLAP 能力。HTAP 申请能够在隔离存储和引擎服务器中独自解决。特地是，SQL 引擎和 TiSpark 受害于同时应用行和列存储，以获得最佳后果。
5.1 Transactional Processing
TiDB 提供具备快照隔离（SI）或可反复读取（RR）语义的 ACID 事务。SI 容许事务中的每个申请读取数据的统一版本。RR 示意事务中的不同语句可能会读取同一键的不同值，但反复读取（即具备雷同工夫戳的两次读取）将始终读取雷同的值。咱们的实现基于多版本并发管制（MVCC），防止了读写锁定，并可避免写入抵触。在 TiDB 中，事务是 SQL 引擎、TiKV 和 PD 之间的合作事务。在跨口头期间，每个组件的责任如下：
•SQL 引擎：协调事务。它接管来自客户端的写入和读取申请，将数据转换为键值格局，并应用 two-phase commit（2PC）将事务写入 TiKV。
•PD：治理逻辑区域和物理地位; 提供全局、严格减少的工夫戳。
•TiKV：提供分布式事务接口，实现 MVCC，并将数据保留到磁盘。
TiDB 实现乐观和乐观锁定。它们依据 Percolator 模型改编，该模型抉择一个键作为主键，并应用它代表事务的状态，并基于 2PC 执行事务。乐观事务的过程图 5 的左侧阐明了这一过程。（为简略起见，图疏忽异样解决。
（1）从客户端收到 ” 开始 ” 命令后，SQL 引擎要求 PD 应用工夫戳作为事务的开始工夫戳（start_ts）。
（2）SQL 引擎通过从 TiKV 读取数据并写入本地内存来执行 SQL DML。TiKV 在跨操作的公布 commit_ts 之前提供最新的提交工夫戳（start_ts）。
（4）当 SQL 引擎从客户端收到提交命令时，它将启动 2PC 协定。它随机抉择主键，并行锁定所有密钥，并将预写入发送到 TiKV 节点。
（3）如果所有预写胜利，SQL 引擎会向 PD 申请为事务的提交提供工夫戳，并向 TiKV 发送提交命令。TiKV 提交主密钥并将胜利响应发送回 SQL 引擎。
（5）SQL 引擎将胜利返回给客户端。
（6）SQL 引擎提交辅助键，通过向 TiKV 发送进一步的提交命令，以异步和并行形式革除锁。
乐观事务和乐观事务的次要区别在于获取锁时。在乐观事务中，锁在预写入阶段（下面的步骤 3）以增量形式获取。在乐观事务中，锁是在预写前执行 DML 时获取的（步骤 2 的一部分）。这意味着，一旦预写开始，事务不会因为与另一个跨操作抵触而失败。（因为网络分区或其余问题，它仍可能失败。
在乐观事务中锁定键时，SQL 引擎将获取一个新的工夫戳，称为 for_update_ts。如果 SQL 引擎无奈获取锁，它能够从该锁开始重试事务，而不是回滚和重试整个跨操作。读取数据时，TiKV for_update_ts 而不是 start_ts 来决定能够读取键的哪些值。这样，乐观事务仍维持 RR 隔离级别，即便具备局部事务重应。
应用乐观事务，用户还能够抉择仅要求读取提交（RC）隔离级别。这会导致事务之间的抵触缩小，从而进步性能，而就义较少的孤立事务。实现区别在于，如果读取尝试拜访被另一个事务锁定的密钥，则 RR TiKV 必须报告抵触; 因而，如果读取内容尝试拜访被另一事务锁定的密钥，则必须报告抵触。对于 RC，能够疏忽锁以进行读取。
TiDB 实现分布式事务，无需集中式锁管理器。锁存储在 TiKV 中，具备很高的可扩展性和可用性。此外，SQL 引擎和 PD 服务器可扩大，可解决 OLTP 申请。跨服务器同时运行多个事务实现了高度并行性。
从 PD 申请工夫戳。每个工夫戳都蕴含物理工夫和逻辑工夫。物理工夫是指具备毫秒精度的以后工夫，逻辑工夫须要 18 位。因而，从实践上讲，PD 能够调配 218 次的每毫秒。实际上，它每天能够产生大概 100 万次的 tamps，因为调配工夫戳只需几个周期。客户端要求一次工夫戳，以摊销开销，尤其是网络提早。目前，获取工夫戳并不是咱们试验和许多生产环境中的性能瓶颈。
5.2 Analytical Processing
在本节中，咱们将介绍针对 OLAP 查问的优化，包含优化器、索引和推送咱们定制的 SQL 引擎和 TiSpark 中的计算。
5.2.1 Query Optimization in SQL Engine
TiDB 实现了一个查问优化器，具备两个阶段的查问优化：基于规定的查问优化（RBO），该优化生成逻辑打算，而后是基于老本的优化（CBO），将逻辑打算转换为物理打算）。咱们的 RBO 具备一组丰盛的转换规则，包含裁剪不必要的列、打消投影、向下推谓词、派生谓词、一直折叠、打消 ” 分组通过 ” 或内部联接，以及勾销勾销子联接。咱们的 CBO 依据执行老本从候选打算中抉择最便宜的打算。请留神，TiDB 反对应用两个数据存储库，TiKV 和 TiFlash，因而扫描表通常有三个选项：扫描 TiKV 中的行格局表、在 TiKV 中应用索引扫描表以及在 TiFlash 中扫描列。
索引对于进步数据库中的查问性能十分重要，这些查问通常用于点获取或范畴查问，为哈希联接和合并联接提供更便宜的数据扫描门路。TiDB 实现可扩大索引，以在分布式环境中工作。因为保护索引会耗费大量从新源，并且可能会影响联机事务和剖析，因而咱们在后盾异步生成或删除索引。索引按区域按数据以雷同的形式拆分，并存储于 TiKV 中的键值。惟一键索引上的索引项编码为：
Key:{table{tableID}index{indexID}indexedColValue}
Value:{rowID}
An index item on a nonunique index is decoded as:
Key:{table{tableID}index{indexID}indexedColValuerowID}
Value:{null}
应用索引须要二进制搜寻来查找蕴含索引相干局部的区域。为了进步索引抉择的稳定性，缩小物理优化的开销，咱们应用天际线修剪算法来打消无用的候选索引。如果有多个候选索引匹配不同的查问条件，咱们将合并局部后果（即一组合格的行 ID）以取得准确的后果集。
物理打算（CBO 的后果）由 SQL 引擎层应用拉拔器模型 [17] 执行。通过将一些计算向下推送到存储层，能够进一步优化执行。在存储层中，执行计算的组件称为协处理器。协处理器并行在不同的服务器上执行执行打算的子树。这将缩小必须从存储层发送到引擎层的元组数。例如，通过评估协处理器中的筛选器，在存储层中筛选出被回绝的元组，并且只须要将承受的元组发送到引擎层。协处理器能够计算逻辑操作、算术运算和其余常见函数。在某些状况下，它能够执行聚合和 TopN。协处理器能够通过矢量化操作进一步提高性能：而不是遍数整个行，对行进行批处理，按列组织数据，从而实现更高效的迭代。
5.2.2 TiSpark
为了帮忙 TiDB 连贯到 Hadoop 生态系统，TiDB 在多 Raft 存储上增加了 TiSpark。除了 SQL 之外，TiSpark 还反对弱小的计算，如机器学习库，并且能够解决来自 TiDB 内部的数据。
图 6 显示了 TiSpark 如何与 TiDB 集成。在 TiSpark 中，Spark 驱动程序从 TiKV 读取元数据以结构 Spark 目录，包含表架构和索引信息。Spark 驱动程序要求 PD 提供工夫戳，以读取来自 TiKV 的 MVCC 数据，以确保它取得数据库的统一快照。与 SQL 引擎一样，Spark 驱动程序能够将计算推送到存储层上的独特处理器并应用可用的索引。这是通过批改 Spark 优化器生成的打算实现的。咱们还自定义一些读取操作以从 TiKV 和 TiFlash 读取数据，并将它们组装成 Spark 工作人员的行。例如，TiSpark 能够同时从多个 TiDB 区域读取，它能够并行从存储层获取索引数据。为了缩小对 Spark 特定版本的依赖，大多数这些函数都是在附加包中实现的。
TiSpark 在两个方面不同于一般连接器。它不仅能够同时读取多个数据区域，还能够并行从存储层获取索引数据。读取索引有助于 Spark 中的优化器抉择最佳打算以从新升高执行老本。另一方面，TiSpark 批改了从 Spark 中的原始优化器生成的打算，将执行局部向下推送到存储层中的协处理器，从而进一步升高了执行开销。除了从存储层读取数据外，TiSpark 还反对在存储层中加载具备事务的大型数据。为此，TiSpark 采纳两阶段提交和锁定表。
5.3 Isolation and Coordination
资源隔离是保障事务查问性能的无效办法。剖析查问通常耗费大量资源，如 CPU、内存和 I/O 带宽。如果这些查问与事务查问一起运行，则后者可能会重大提早。这一个别准则在以前的工作中曾经失去验证[24，34]。为了防止在 TiDB 中呈现此问题，咱们在不同的引擎服务器上安顿剖析和事务查问，并在独自的服务器上部署 TiKV 和 TiFlash。事务查问次要拜访 TiKV，而剖析查问次要拜访 TiFlash。通过 Raft 放弃 TiKV 和 TiFlash 之间的数据一致性的开销较低，因而应用 TiFlash 运行剖析查问对事务处理的性能影响很小。
数据在 TiKV 和 TiFlash 之间是统一的，因而能够通过从 TiKV 或 TiFlash 读取来提供查问。因而，咱们的查问优化器能够从更大的物理打算空间进行抉择，并且最佳打算可能同时从 TiKV 和 Ti-Flash 中读取。当 TiKV 拜访表时，它提供行扫描和索引扫描，而 TiFlash 反对列扫描。
这三个拜访门路的执行老本和数据程序属性之间不同。行扫描和列扫描按主键提供程序; 索引扫描提供从键的编码中的多个排序。不同门路的老本取决于均匀元组 / 列 / 索引大小（Stuple/col/index）和预计元数 / 区域数（Ntuple/reg）。咱们示意数据扫描 asfscan 的 I/O 开销，以及寻求老本 asfseek 的文件。查问优化器依据方程（1）抉择最佳拜访门路。如公式（2）所示，行扫描的老本来自扫描间断行数据和寻找区域文件。列扫描的老本（公式（3）））是扫描 m 列的总和。如果索引列不能满足表扫描所需的列，则索引扫描（公式（4））应思考扫描索引文件的老本和扫描数据文件的老本（即双重读取）。请留神，双读通常随机扫描元组，这波及到在方程（5）中查找更多文件。
例如，当查问优化器将同时抉择行格局和列格局存储以拜访同一查问中的不同表时，请思考 ” 从 T.*，S.a 从 T.b_s.bwhere T.a 之间的 1 和 100″。这是一个典型的联接查问，其中 T 和 S 在行存储中的列 a 上具备索引，以及列正本。最好应用索引从行存储拜访 T，从列存储拜访 S。这是因为查问须要一系列来自 T 的残缺元组，并且通过元组拜访数据比列存储便宜。另一方面，应用列存储时获取两列残缺的 S 更便宜。
TiKV 和 TiFlash 的协调依然能够保障隔离性能。对于剖析查问，只有小范畴扫描或点获取扫描只能通过追随读取拜访 TiKV，这对领导者影响很小。咱们还将 TiKV 上的默认拜访表大小限度为最多 500 MB。事务查问可能会从 TiFlash 拜访列数据，以查看某些束缚，如唯一性。咱们为特定表设置了多个列正本，一个表正本专用于事务查问。在独自的服务器上解决事务性查问可防止影响剖析查问。
- EXPERIMENTS
在本节中，咱们首先别离评估 TiDB 的 OLTP 和 OLAP 能力。对于 OLAP，咱们考察 SQL 引擎抉择 TiKV 和 T8lash 的能力，并将 TiSpark 与其余 OLAP 零碎进行比拟。而后，咱们测量 TiDB 的 HTAP 性能，包含 TiKV 和 TiFlash 之间的日志复制提早。最初，咱们将 TiDB 与 MemSQL 进行比拟。在隔离方面。
6.1 Experimental Setup
集群。咱们在六台服务器集群上执行全面的试验; 每个处理器具备 188 GB 内存和两个 IntelR© XeonR©CPU E5-2630 v4 处理器，即两个 NUMA 节点。每个处理器有 10 个物理内核（20 个线程）和一个 25 MB 的共享 L3cache。服务器运行 Centos 版本 7.6.1810，并且通过 10 Gbps 以太网网络连接。
工作量。咱们的试验是在混合 OLTP 和 OLAP 工作负载下应用 CH-benCH 标记进行的。源代码在线公布 [7]。基准由规范 OLTP 和 OLAP 基准组成：TPC-C 和 TPC-H。它是依据 TPC-C 基准的未修改版本构建的。OLAP 局部蕴含 22 个剖析查问，这些查问受 TPC-H 的启发，其架构从 TPC-H 调整为 CH-benCH 标记架构，外加三个缺失的 TPC-H 关系。在运行时，两个工作负载同时由多个客户端进行治理; 在试验中，客户端的数量各不相同。吞吐量别离以查问 / 秒（QPS）或事务 / 秒（TPS）来掂量。CH-benCH 标记中的数据单位称为仓库，与 TPC-C 雷同。100 个仓库须要大概 70 GB 的内存。
6.2 OLTP Performance
咱们评估 TiDB 的独立 OLTP 性能，在 CH-benCH 标记的 OLTP 局部下乐观锁定或乐观锁定; 即 TPC-C 基准。咱们将 TiDB 的可见度与另一个分布式 NewSQL 数据库 ” Cockroach DB “CRDB 进行比拟。CRDB 部署在六台同质服务器上。对于 TiDB，SQL 引擎和 TiKV 部署在六台服务器上，它们的实例别离绑定到每台服务器上的两个 NUMA 节点。PD 部署在六台服务器中的三台。为了均衡申请，通过 HAProxy 负载均衡器能够拜访 TiDB 和 CRDB。咱们应用各种数量的客户端测量 50、100 和 200 个仓库的吞吐量和均匀提早。
图 7（b）和图 7（c）中的吞吐量图与图 7（a）不同。在图 7（a）中，对于少于 256 个客户端，TiDB 的吞吐量随乐观锁定和乐观锁定的客户端数而减少。对于超过 256 个客户端，具备乐观锁定的吞吐量保持稳定，而后开始降落，而乐观锁定的吞吐量达到其最大 512 个客户端，而后降落。图 7（b）和 7（c）中的 TiDB 吞吐量一直减少。因为资源争用最强烈且并发性和小数据大小，因而预期会呈现此后果。
通常，乐观锁定的性能优于乐观锁定，但较小的数据大小和高并发性（50 或 100 个仓库的 1024 个客户端），其中资源争用很重，导致重试许多乐观事务。因为资源争用较轻，有 200 个仓库，因而乐观锁定仍会产生更好的性能。
在大多数状况下，TiDB 的吞吐量高于 CRDB，尤其是在对大型仓库应用乐观锁定时。即便采纳乐观锁定进行偏心比拟（CRDB 始终应用乐观锁定），TiDB 的性能依然更高。咱们置信 TiBD 的性能劣势在于事务处理和 Raft 算法的优化。
图 7（d）显示，更多的客户端会导致更多的提早，尤其是在达到最大吞吐量之后，因为更多的申请必须期待更长的工夫。这也意味着提早越高，仓库越少。对于某些客户端，较高的通投入可缩小 TiDB 和 CRDB 的提早。50 个和 100 个仓库也存在相似的后果。
咱们评估从 PD 申请工夫戳的性能，因为这可能是一个潜在的瓶颈。咱们应用 1200 个客户端继续申请工夫戳。客户端位于群集中的不同服务器上。模仿 TiDB，每个客户端分批向 PD 发送工夫戳申请。如表 3 所示，六台服务器中每个服务器每台可接管 602594 次工夫戳 / 秒，这是运行 TPC-Cbench 标记时所需速率的 100 倍以上。运行 TPC-C 时，TiDB 申请每台服务器最多为 6000 次。减少服务器数量时，每台服务器上接管的工夫戳数将缩小，但工夫戳总数简直雷同。这个比率大大超过任何理论需要。对于提早，只有一小部分申请破费 1 ms 或 2 ms。咱们的论断是，从 PD 获取工夫戳目前不是 TiDB 的性能瓶颈。
6.3 OLAP Performance
咱们评估从 PD 申请工夫戳的性能，因为这可能是一个潜在的瓶颈。咱们应用 1200 个客户端继续申请工夫戳。客户端位于群集中的不同服务器上。模仿 TiDB，每个客户端分批向 PD 发送工夫戳申请。如表 3 所示，六台服务器中每个服务器每台可接管 602594 次工夫戳 / 秒，这是运行 TPC-Cbench 标记时所需速率的 100 倍以上。运行 TPC-C 时，TiDB 申请每台服务器最多为 6000 次。减少服务器数量时，每台服务器上接管的工夫戳数将缩小，但工夫戳总数简直雷同。这个比率大大超过任何理论需要。对于提早，只有一小部分申请破费 1 ms 或 2 ms。咱们的论断是，从 PD 获取工夫戳目前不是 TiDB 的性能瓶颈。
Q8, Q12, 和 Q22 会产生乏味的后果。与 Q8 和 Q22 中仅 TiFlash 案例的工夫老本要长，但 Q22 须要破费更多工夫。TiKV 和 TiFlash 案例的性能优于仅 TiKV 和仅 TiFlash 案例。
Q12 次要蕴含两个表联接，但在每个存储类型中须要不同的物理实现。在仅 TiKV 的状况下，它应用索引联接，该联接从表 ORDERLINE 扫描多个合格的元数，并应用索引查找表 OORDER。索引读取器的成本低得多，因而它优于在 TiFlash 只例例中应用哈希联接，该案例扫描两个表中所需的列。应用 TiKV 和 TiFlash 时的老本进一步升高，因为它应用从 TiFlash 扫描 ORDERLINE 的更便宜的索引联接，并应用 TiKV 中的索引搜寻 OORDER。在 TiKV 和 TiFlash 案例中，读取列存储可将仅 TiKV 案例的执行工夫缩小一半。
在 Q22 中，其存在（）子查问转换为反半联接。它在仅 TiKV 大小写例中应用索引联接，在仅 TiFlash 的状况下应用哈希联接。但与 Q12 中的执行不同，应用索引联接比哈希联接更低廉。从 TiFlash 获取外部表并应用 TiKV 的索引查找内部表时，索引联接的老本会升高。因而，TiKV 和 TiFlash 案例再次占用的工夫起码。
Q8 更为简单。它蕴含一个蕴含九个表的联接。在仅 TiKV 的状况下，须要两个索引合并联接和六个哈希联接，并应用索引查问两个表（CUSTOMER 和 OORDER）。此打算须要 1.13 秒，优于在 TiFlash 只例中采纳 8 个哈希联接，该案例须要 1.64 秒。在 TiKV 和 TiFlash 案例中，其过头性进一步缩小，其中物理打算简直放弃不变，除了在六个哈希联接中扫描来自 TiFlash 的数据。此改良将执行工夫缩短到 0.55 秒。在三个查问中，仅应用 TiKV 或 Ti-Flash 取得不同的性能，并组合它们可获得最佳后果。
对于 Q1, Q4, Q6, Q11, Q13, Q14, 和 Q19，仅 TiFlash 案例的性能优于仅 TiKV 案例，而 TiKV 和 TiFlash 案例的性能与仅 TiFlash 案例的性能雷同。这七个查问的起因不同。Q1 和 Q6 次要是单个表上的聚合组合，因而在 TiFlash 中的列存储上运行老本更低，是最佳抉择。这些后果突出了先前工作中形容的柱存储的长处。Q4 和 Q11 在每种状况下都应用雷同的物理打算独自执行。然而，从 TiFlash 扫描数据比 TiKV 便宜，因而仅 TiFlash 状况下的执行工夫更少，也是最佳抉择。Q13、Q14 和 Q19 都蕴含一个双表联接，该联接作为哈希联接实现。只管仅 TiKV 大小写在探测哈希表时采纳索引读取器，但它也比从 TiFlash 扫描数据更低廉。
Q9 是多联接查问。在仅 TiKV 的状况下，它应用索引对某些表采纳索引合并联接。它比在 TiFlash 上执行哈希联接便宜，因而它成为最佳抉择。Q7、Q20 和 Q21 会产生相似的后果，但因为空间无限，后果被打消。其余 8 个 22 个 TPC-H 查问在三个存储设置中具备可比的性能。
此外，咱们应用 500 个仓库的 CH-benCH 标记的 22 个剖析查问将 TiSpark 与 SparkSQL、PrestoDB 和 Greenplum 进行比拟。每个数据库都装置在六台服务器上。对于 SparkSQL 和 PrestoDB，数据存储为 Hive 中的柱形镶木地板文件。图 9 比拟了这些零碎的性能。TiSpark 的性能可与 SparkSQL 媲美，因为它们应用雷同的引擎。性能差距相当小，次要来自拜访不同的存储系统：扫描压缩镶木地板文件更便宜，因而 SparkSQL 通常优于 TiSpark。然而，在某些状况下，TiSpark 能够将更多计算推送到存储层，但这种劣势是对消的。将 TiSpark 与 PrestoDB 和 Greenplum 进行比拟是 SparkSQL（TiSpark 的根底引擎）与其余两个引擎的比拟。然而，这超出了本文的范畴，咱们不会具体探讨。
6.4 HTAP Performance
除了考察事务处理（TP）和剖析解决（AP）性能，咱们还依据整个 CH-benCHmark 以及独自的事务客户端（TC）和剖析客户端（AC）评估 TiDB 的混合工作负载。这些试验是在 100 个仓库进行的。数据加载到 TiKV 中，并同时复制到 TiFlash 中。TiKV 部署在三台服务器上，由 TiDB SQL 引擎实例拜访。TiFlash 部署在其余三台服务器上，并与其余 TiSpark 实例并合。此配置别离提供剖析和事务查问。每次跑步工夫为 10 分钟，热身工夫为 3 分钟。咱们测量了 TP 和 AP 工作负载的吞吐量和均匀提早。
图 10（a）和 10（b）显示了具备不同数量的 TP 客户端和 AP 客户端的事务的吞吐量和均匀提早（别离）。吞吐量随着 TP 客户端的减少而减少，但达到最大值时略低于 512 个客户端。对于雷同数量的 TP 客户端，与没有 AP 客户端相比，更多的剖析解决客户端最多会升高 TP 吞吐量 10%。这证实了 TiKV 和 TiFlash 之间的日志复制实现了高隔离，尤其是与第 6.6 节中的 MemSQL 性能相同。此后果与 [24] 中的后果相似。
事务的均匀提早在没有下限的状况下减少。这是因为即便更多的客户端收回更多的重工作，它们也不能立刻实现，必须期待。等待时间是提早减少的一部分。
图 10（c）和 10（d）所示的相似吞吐量和提早结果显示了 TP 对 AP 申请的影响。AP 吞吐量很快达到 16 个 AP 客户端以下的最大容量，起因 AP 查问老本昂扬，并且争用资源。此类争用会升高应用更多 AP 客户端的吞吐量。对于雷同数量的 AP 客户端，吞吐量简直放弃不变，最多只能缩小 5%。这表明 TP 不会显著影响 AP 执行。剖析查问的均匀提早减少会导致与更多客户端的等待时间减少。
6.5 Log Replication Delay
为了实现实时剖析解决，TiFlash 应立即看到事务更新。此类数据新鲜度由 TiKV 和 TiFlash 之间的日志复制提早决定。咱们应用不同数量的事务客户端和剖析客户端运行 CH-ben CHmark 时测量日志复制工夫。咱们记录运行 CH-benCHmark 10 分钟内每个复制的提早，并计算每 10 秒的均匀提早。咱们还计算日志复制提早在 10 分钟内的散布，如表 4 所示。
如图 11（a）所示，10 个仓库的日志复制提早始终小于 300 ms，并且大多数提早小于 100 毫秒。图 11（b）显示，提早减少与 100 个软件屋; 大多数小于 10ms。表 4 提供了更准确的细节。在 10 个仓库中，无论客户端设置如何，简直 99% 的查问老本都低于 500 ms。在 100 个仓库中，别离有 2 个和 32 个剖析客户端的查问量低于 99% 和 85%。这些指标强调 TiDB 能够保障 HTAP 工作负载的数据新鲜度约为 1 秒。
在比拟图 11（a）和图 11（b）时，咱们察看到延迟时间与数据大小无关。仓库越大，提早越大，因为更多的数据会引入更多的日志进行同步。此外，提早还取决于剖析申请的数量，但因为事务客户端的数量，因而损失较少。这能够在图 11（b）中分明地看到。32 个 AC 比两个 AC 导致更多的提早。然而，对于雷同数量的剖析客户端，提早没有很大差别。咱们在表 4 中显示更准确的后果。领有 100 个仓库和两个 AC，超过 80% 的查问须要小于 100 ms，但 32 个 AC 少于 50% 的查问须要不到 100 ms。这是因为更多的剖析查问会以更高的频率诱导日志复制。
6.6 Comparison to MemSQL
咱们应用 CH-benC -Hmark 将 TiDB 与 MemSQL 7.0 进行比拟。本试验旨在强调最先进的 HTAP 零碎的隔离问题，而不是 OLTP 和 OLAP 性能。MemSQL 是一个分布式关系数据库，可大规模处理事务和实时剖析。MemSQL 部署在六台服务器上：一台主服务器、一台聚合器和四台服务器。咱们将 100 个仓库加载到 MemSQL 中，并运行了各种数量的 AP 和 TP 客户端的基准。基准运行 10 分钟，5 分钟的热身期。
与图 10 相比，图 12 阐明了工作负载烦扰对 MemSQL 的性能有显著影响。特地是，随着 AP 客户端数量的减少，事务吞吐量显著减慢，降落五倍以上。AP 吞吐量也会随着 TP 客户端的减少而升高，但这种成果没有标记，因为事务查问不会从新询问剖析查问的大量资源。
- RELATED WORK
构建 HTAP 零碎的常见办法包含：从现有数据库演变、扩大开源剖析零碎或从头开始构建。TiDB 是从头开始构建的，在体系结构、数据发动、计算引擎和一致性保障方面与其余零碎不同。
从现有数据库演变。成熟的数据库能够基于现有产品反对 HTAP 解决方案，并且它们尤其侧重于减速剖析查问。他们采纳自定义办法，别离实现数据一致性和高可用性。相比之下，TiDB 天然会从 Raft 中的日志复制中取得益处，以实现数据一致性和高可用性。
Oracle [19] 于 2014 年推出了数据库内存选项，成为业界首款双格局内存 RDBMS。此选项旨在突破剖析查问工作负荷中的性能阻碍，同时不影响（甚至改善）惯例事务工作负载的性能。列存储是只读快照，在工夫点统一，并应用齐全联机的从新填充机制进行更新。Oracle 的前期工作 [27] 介绍了其分布式体系结构的高可用性方面，并提供容错剖析查问执行。
SQL Server [21] 将两个专用存储引擎集成到其外围中：用于剖析工作负载的阿波罗列存储引擎和用于事务性工作负载的 Hekaton 内存引擎。数据迁徙工作定期将数据从 Hekaton 表的尾部复制到压缩列存储区。SQL Server 应用列存储索引和批处理来高效地解决剖析查问，应用 SIMD [15] 进行数据扫描。
SAP HANA 反对高效评估独自的 OLAP 和 OLTP 查问，并为每个查问应用不同的数据组织。为了扩大 OLAP 性能，它异步地将行存储数据复制到散布在服务器群集上的列存储 [22]。此办法提供具备子秒可见性的 MVCC 数据。然而，处理错误和保持数据一致性须要付出大量致力。重要的是，事务引擎不足高可用性，因为它只部署在单个节点上。
转换开源零碎。Apache Spark 是用于数据分析的开源框架。它须要一个事务模块来实现 HTAP。上面列出的许多零碎都遵循此理念。TiDB 并不深深依赖于 Spark，因为 Tispark 是一种前缓和。TiDB 是一个独立的 HTAP 数据库，没有 TiSpark。
Wild-fire [10，9] 基于 Spark 构建 HTAP 引擎。它解决同一列数据组织（即 Parquet）上的剖析和事务申请。它采纳最初写入获胜语义进行并发更新，对读取采纳快照隔离。对于高可用性，分片日志将复制到多个节点，而无需共识算法的帮忙。剖析查问和事务查问能够在独自的节点上解决; 然而，在解决最新更新时存在显著的提早。对于大型 HTAP 工作负载，Wild-fire 应用对立的多版本和多区域索引办法 [23]。
SnappyData [25] 为 OLTP、OLAP 和流剖析提供了一个对立的平台。它集成了用于高吞吐量剖析（Spark）的计算引擎和扩大内存事务存储（GemFire）。最近的更新以行格局存储，而后老化为剖析查问的列格局。应用 GemFire 的 Paxos 实现遵循 2PC 协定，以确保在整个群集中达成共识和统一的观点。
从头开始构建。许多新的 HTAP 零碎曾经考察了混合工作负载的不同方面，包含利用内存计算来进步性能、优化数据存储和可用性。与 TiDB 不同，它们不能同时提供高可用性、数据一致性、可扩展性、数据新鲜度和隔离性。
MemSQL [3] 具备可扩大的内存 OLTP 和疾速剖析查问的引擎。MemSQL 能够以行或列格局存储数据库表。它能够以行格局保留局部数据，并将其转换为列格局，以在将数据写入磁盘时进行疾速剖析。它将反复查问编译为低级 ma-chine 代码以减速剖析查问，并应用许多无锁构造来帮忙事务处理。然而，在运行 HTAP 工作负载时，它不能为 OLAP 和 OLTP 提供隔离性能。
HyPer [18] 应用操作系统的分叉零碎调用来为剖析工作负载进行亲 vide 快照隔离。其较新版本采纳 MVCC 实现，提供可序列化、疾速的跨动作解决和疾速扫描。ScyPer [26] 扩大 HyPer，通过应用逻辑或物理重做日志流传更新，在近程正本上大规模评估剖析查问。
BatchDB [24] 是专为 HTAP 工作负载设计的内存数据库引擎。它依赖于具备专用正本的高级辅助复制，每个正本针对特定工作负载类型（即 OLTP 或 OLAP）进行了优化。它最大限度地缩小了事务引擎和剖析引擎之间的负载交互，从而在 HTAP 工作负载的严格 SLA 下，可能对全新数据进行实时剖析。请留神，它在行格局正本上执行剖析查问，并且不保障高可用性。
基于血统的数据存储（L-Store）[35] 通过引入基于更新的、基于血统的存储体系结构，将实时剖析和事务查询处理联合在一个对立引擎中。该存储在本机多版本列存储模型上启用无争用更新机制，以便从写入优化的列格局到读取优化的列式布局中，以安稳和独立地将稳固数据阶段为读取优化的列式布局。
Peloton [31] 是一个主动驾驶的 SQL 数据库管理系统。它尝试在运行时为 HTAP 工作负载调整数据发动 [8]。它应用无锁的多版本并发管制反对端口实时剖析。然而，它是由设计的单节点内存数据库。
Cockroach DB [38] 是一个分布式 SQL 数据库，提供高可用性、数据一致性、可扩展性和隔离性。与 TiDB 一样，它建设在 Raft 算法之上，反对分布式事务。它提供了更强的隔离属性：可序列化，而不是快照隔离。然而，它不反对专用 OLAP 或 HTAP 性能。
- CONCLUSION
咱们提出了一个生产就绪的 HTAP 数据库：TiDB。TiDB 构建在 TiKV 之上，TiKV 是一个分布式、基于行的存储，它应用 Raft 算法。咱们引入列学员进行实时剖析，这些剖析异步地从 TiKV 复制日志，并将行格局数据转换为列格局。TiKV 和 TiFlash 之间的此类日志正本提供实时数据一致性，且开销很小。TiKV 和 TiFlash 能够部署在 sepa 速率的物理资源上，以便高效处理事务和剖析查问。TiDB 能够最好地抉择它们，以在扫描事务查问和剖析查问的表时拜访它们。试验结果表明，TiDB 在 HTAP 基准 CH-benCHmark 下体现良好。TiDB 提供了一个通用解决方案，将 NewSQL 零碎倒退为 HTAP 零碎。