共计 7970 个字符，预计需要花费 20 分钟才能阅读完成。
置信大家在网上抢购时遇到过网页无奈失常拜访的状况，一部分起因可能是数据库无奈很好地应答一直减少的并发拜访。如何无效地解决数据库现有的这些缺点呢？数据分片是一个可选的计划。本篇文章将 为大家解读由重庆大学和 SphereEx 实验室单干的、发表在 CCF A 类数据库顶级会议 ICDE 2022 上的论文《Apache ShardingSphere：A Holistic and Pluggable Platform for Data Sharding》。
01 问题背景
随着数据量的一直减少以及人们对数据需要的一直增长，须要数据库不仅可能治理大量数据，还可能反对高度并发的拜访。设计一种可能应答这两种要求的数据库可能进步用户体验，缩小相似网购时网页无法访问的状况呈现。
目前来看，关系型数据库依然是在线事务处理的主力，因为它们反对残缺的事务。然而关系型数据库设计初期是针对单台机器的，数据量过大时往往可扩展性欠佳，而且不能很好地解决高并发的问题。只管当初像 HBase 这种 NoSQL 数据库能够反对高并发申请，然而他们不太适宜在线事务的解决，还可能会呈现数据不统一的问题。所以很多人开始关注 NewSQL，New 就意味着是从零开始开发的数据库。尽管适宜当初的利用场景，但它们还没有很好地承受社会的测验，而且 NewSQL 的应用和保护人员还须要额定地学习相干新技术。
那么在已有的数据库和应用程序之间插入一个数据分片中间件，来连贯和治理泛滥已有的数据库，是不是可行呢？答案天然是必定的。如下图 1 所示，数据分片中间件将用户查问调配到不同机器内的多个数据库中，别离执行查问后再将多个后果合并，最初返回到应用程序中，这无效地解决了单台机器的限度。对于开发人员来说，数据分片中间件是通明的，应用更为不便。这么看数据分片中间件非常敌对且十分高效。
（图 1：数据分片示例）
设计一个好的数据分片中间件存在很大挑战。第一，在不同的场景下采纳的底层数据库不同，这些数据库采纳不同的数据库协定和 SQL 语句，在一个对立的框架下反对多种数据库并不简略。此外，有许多 SQL 语句类型（从简略的查问到聚合再到多表 join 等），对不同 SQL 语句的路由办法以及合并策略也不雷同。第二，多个数据库之间协调事务比拟艰难，有时候单个事务类型可能不反对所有的场景。第三，数据分片中间件可能会遇到效率问题，因为转发申请、合并后果影响须要耗费一些工夫。第四，数据管理员须要一一配置分片规定，这对他们不是很敌对。
Apache ShardingSphere 作为 Apache 第一个顶级开源的数据库分片我的项目，可能解决了下面提到的所有挑战。ShardingSphere 的次要指标就是要缩小数据分片的影响，让开发人员像应用单个数据库一样应用分片数据库。它领有以下几个显著的特点：
（1）性能齐备。ShardingSphere 反对多种支流的关系型数据库（实际上，任何满足 SQL-92 规范的数据库都反对）。它设计并实现了一个残缺的 SQL 引擎，因而任何类型的 SQL 都可能精确的被路由。此外，其提供了三种类型的分布式事务和其余丰盛的性能。据作者所知，ShardingSphere 是第一个将数据分片、强一致性事务和柔性事务联合在一起的零碎。
（2）高效。除了代理模式，ShardingSphere 还提供了 JDBC 的接入形式，这在大部分场景下可能大幅晋升效率。此外，ShardingSphere 提出了两种执行模式，并提出了一种智能的策略来抉择适合的执行模式和后果合并策略，这可能很好地均衡资源和效率。
（3）可插拔和可扩大。ShardingSphere 基于 SPI（Service Provider Interface, 一种 Java 语言中的服务发现机制）和多种设计模式设计的。因而，更多类型的数据库、性能、分片算法都可能十分不便地退出。此外，所有现有的性能都可能移除或者自由组合。
（4）用户敌对。ShardingSphere 反对简直所有的 SQL 语句，同时暗藏了分布式事务的细节。因而，利用开发人员可能在 ShardingSphere 的帮忙下像应用单机版数据库一样应用分布式事务和分片后的数据库集群。ShardingSphere 还提出了一种新的 DistSQL 和 AutoTable 策略，可能帮忙数据库管理员更不便地配置分片策略。
以后（截止到论文撰写期间）有 170 多个公司发表在应用 ShardingSphere。本文基于 2021 年 11 月 10 日公布的 ShardingSphere 5.0.0 版本。
02 零碎框架和数据流
如图 2 所示，ShardingSphere 一共分为五个模块，1）数据源模块，集成多种数据库来进行存储。以后反对的数据源有 MySQL，PostgreSQL，SQL Server，Oracle，MariaDB 和 openGauss。2）功能模块，用来提供许多开箱即用的性能，也能够自在地增加、组合、删除性能来满足需要。3）调控器，次要用于配置管理和衰弱监测。4）SQL 引擎，设计并实现了一个残缺的数据分片 SQL 引擎。所有性能都能够通过 SQL 引擎实现可插拔，并且任何性能都能够通过一条 SQL 语句实现。5）适配接口，能够反对不同的场景来应用。
（图 2：ShardingSphere 框架）
图 3 展现了 ShardingSphere 的数据流，次要分为两种。第一种是对 JDBC 进行加强扩大，ShardingSphere-JDBC 能够和 Java 应用程序在同一个过程中运行。第二种是在数据源和应用程序之间的过程 ShardingSphere-Proxy，能够反对应用任何编程语言的应用程序。此外，能够通过任何兼容 MySQL 或 PostgreSQL 协定的终端（如 MySQL 命令客户端、MySQL Workbench 等）间接连贯到 ShardingSphere-Proxy，对数据库管理员非常敌对。调控器作为一个独自的过程，用来监督数据源并且保护 ShardingSphere-JDBC 和 ShardingSphere-Proxy 配置。
（图 3：ShardingSphere 数据流）
接下来咱们从图 2 中的功能模块、调控器、SQL 引擎、适配接口进行细节解说。
03 功能模块
3.1 数据分区
数据分区是 ShardingSphere 中最重要的性能之一。它将数据拆分并依据肯定的条件将其存储在多个表或数据源（这里的数据源即为逻辑数据库，下同）中。ShardingSphere 提出表分片和数据源分片，每种分片有程度和垂直两种分片办法，下图 4 给出四种类型分片的例子。图 4（a）是原始数据库及其外部表的构造和数据。图 4（c）为垂直表分片、程度表分片、垂直数据源分片以及程度数据源分片四种分片形式。其中分片后的表格构造为 4（b）所示。垂直分片扭转了构造，在利用时须要不断调整架构设计，无奈很好地满足互联网业务疾速变动的需要。相比之下，程度数据分片能够冲破单台机器存储量的限度，并且能够更自在地扩大，本文次要对程度分片进行钻研。
（图 4：分片实例）
联合图 1 和图 4 咱们来解释数据分片中的一些概念：图 1 中的 uid 用来确定数据分片的字段，称其为分片键。ShardingSphere 反对多字段 分片键 。图 1 中“uid%2”用来将数据记录调配给不同的表，咱们称其为 分片算法 。ShardingSphere 中蕴含十余种内置分片算法，用户也能够通过接口进行自定义算法。ShardingSphere 还为不同的数据分片需要提供了不同类型的 表。例如上图的 t_user，咱们称其为 逻辑表 ，而 t_user_h0，t_user_h1 为 理论表 。真正存储在数据库中的表是理论表，然而应用程序开发人员所看到的表是未经分片的逻辑表。对于应用程序开发人员来说分片操作是通明的。如果在图 4（c）中，如果 t_user 和 t_order 采纳雷同的分片算法、雷同的数据源、雷同的分片键和雷同的分片算法，咱们称它们表为 绑定表 ，这在关联查问时非常有用。此外，咱们应用 数据节点 将逻辑表映射到理论表。它是分片的原子单位，由一个数据源名称和一个理论的表名组成，例如，DS0.t_user_h1。
3.2 分布式事务
ShardingSphere 为不同的应用场景提供了三种类型的分布式事务。
XA 事务。原生 XA 事务共有三个角色：AP、RM、TM，开发人员如果要应用 XA 事务，会有较大的学习老本。ShardingSphere 表演了 AP 和 TM 的角色，因而开发人员可能像应用单机版事务一样应用 XA 事务。如下图 5，当应用程序向 ShardingSphere 发送“提交”申请，ShardingSphere 将记录日志并启动 2PC（两阶段提交）过程：第一阶段，ShardingSphere 向所有数据源发送“筹备”音讯，以查看该事务是否能够提交。如果一个数据源确定能够提交它本人的事务，它会向 ShardingSphere 发送一个“ok”；否则，它会发送一个“no”，并回滚它所做的事件。若所有数据源都“ok”，ShardingSphere 则向所有数据源发送“commit”，否则发送“Rollback”告诉回滚。数据源依据命令进行操作。
（图 5：XA 事务）
XA 事务保障了数据的 ACID 个性，然而因为会锁定资源，不太适宜长时间事务，ShardingSphere 提供了本地事务和 BASE 事务来解决此问题。
本地事务。如图 6，当 ShardingSphere 接管来自用户应用程序的“COMMIT”或“ROLLBACK”命令时，它会间接把该命令传输到所有数据源。即便某些数据源提交失败，ShardingSphere 也会疏忽它。因为 Local 事务没有筹备阶段，故能够提高效率。
（图 6：本地事务）
BASE 事务。BASE 事务能够承受短时间内的数据不统一。满足根本可用、软状态和最终统一三个要求的事务称为 BASE 事务。通常，BASE 事务能够从性能上改良零碎，因为它们不须要很强的一致性，并且能够缩小对共享资源的争用。
（图 7：BASE 事务模型）
ShardingSphere 封装了 SEATA，因为 SEATA 提出了一种主动事务（AT）模式来主动生成弥补操作。如图 7 的灰色框所示，SEATA 中有三个角色：1）事务协调器（TC）保护全局和分支事务的状态，并驱动全局提交或回滚；2）事务管理器（TM）定义全局事务的范畴；以及 3）资源管理器（RM）治理资源并驱动分支事务提交或回滚。用户应用程序只须要以规范的数据库连贯形式与 ShardingSphere 交互。ShardingSphere 中的 BASE 事务是 2PC 过程，其中 ShardingSphere 表演 SEATA 中的 TM 和 RM 的角色，BASE 事务过程如图 8 所示。
（图 8：BASE 事务过程）
当然除了数据分片和分布式事务，ShardingSphere 还提供了许多其余有用的性能，包含但不限于：读写拆分、加密、影子（即创立影子数据库并将相应的测试 SQL 路由到它）、伸缩等等。所有这些性能对应用程序开发人员都是通明的，因为 ShardingSphere 能够智能地从规范 SQL 语句中辨认必要的信息。而且咱们能够依据应用场景自在增加、删除或合并其余性能。更多信息可在咱们的用户手册中找到。
04 调控器
4.1 配置管理
配置信息存储在 Apache ZooKeeper 中，这是一个成熟而弱小的分布式协调系统，提供高效的内存治理和分布式锁服务。当初开发者习惯于通过 SQL 操作数据。为此，咱们提出了一种新的 DistSQL（分布式 SQL），它容许用户以应用数据库的形式配置 ShardingSphere。DistSQL 分为资源和规定定义语言（RDL）、资源和规定查询语言（RQL）和资源和规定治理语言（RAL）：
（1）RDL：用来增加、更改或删除资源和规定。例如：
其中咱们提出了 AutoTable 的概念，咱们不须要手动设定分片规定，只须要通知 ShardingSphere 分片的数据源和应有多少分片，分片的细节就交给 ShardingSphere。
（2）RQL：用来查问和显示现有的资源和规定。例如：
（3）RAL：负责附加的管理员性能，如切换交易类型和扩大。例如：
可看出 DistSQL 和个别 SQL 十分相似，对开发人员很敌对。更多信息可参考用户手册。
4.2 衰弱检测
为了保障高可用性，咱们能够建设多个 ShardingSphere-Proxy 实例，并应用负载平衡工具保障负载平衡。调控器会启动一个线程来定期检查每个 ShardingSphere-Proxy 实例和底层数据库的状态，如果发现变动，调控器会主动更改配置，以确保零碎仍能失常工作。
05 SQL 引擎
ShardingSphere 设计并实现了一个残缺的 SQL 引擎，用于数据分片和其余性能。因而，ShardingSphere 中的所有性能都能够通过一条 SQL 语句实现。
当一条 SQL 语句到来时，通过 SQL 解析器 将其解析成形象语法树。之后 SQL 路由器 依据解析后果将逻辑 SQL 语句与数据节点进行匹配。然而上文咱们提到开发人员看到的是逻辑表而不是理论表，所以为了在理论的数据源中进行 SQL 操作，须要通过 SQL 重写器 将 SQL 语句重写，重写分为两步，首先进行正确性重写，将标识符重写为理论的标识符（例如将 t_user 重写为 t_user_h0）、派生后续合并所须要的列、批改来自不同数据源的分页、拆分含有批处理的插入语句。这样保障 SQL 语句执行的正确性、防止数据反复。其中能够进行优化重写，对于路由到单节点 SQL 能够只重写标识符不进行其余重写操作提高效率。SQL 执行器 将重写后的 SQL 语句发送到底层数据源执行相干操作。下文解说执行细节。从 SQL 执行器中失去的不同数据源的多个后果进行后果合并，并将后果返回给用户应用程序。
5.1 SQL 执行器
这部分不仅仅是简略向底层数据源转发 SQL 语句，还须要关注数据源连贯、内存耗费和最大并发之间的均衡。
SQL Executor 提出了两种连贯模式来自动平衡资源管制和执行效率：1) 严格内存模式，它思考了更多的内存应用，并且不限度一个操作的连接数。在这种模式下，咱们更偏向于为每个数据节点保护一个独立的连贯，并发执行 SQL，将后果通过数据游标来加载并进行流合并，以防止内存溢出或频繁的垃圾回收；2) 严格连贯模式，严格限度每次操作的连贯耗费。此模式只能应用将所有后果数据加载到内存中进行合并的内存合并。
然而，对于用户来说很难抉择适合的连贯形式。此外，即便在雷同的利用中，不同的查问可能适宜不同的模式。为了不便用户咱们设计了主动执行引擎，如下图 9，分为两个阶段。
（图 9：SQL 执行器）
筹备阶段。在此阶段，咱们首先按数据源对路由和重写后果进行分组。而后，咱们依据每个数据源的连贯状况确定它们的连贯形式。如果路由到数据源的 SQL 数量大于数据源用于查问的最大连接数，就只能采纳严格连贯模式，否则，咱们能够抉择严格内存模式。接下来，咱们取得所需的连贯并创立执行单元。为了避免出现死锁，咱们向数据源增加锁来主动获取查问所需的所有连贯。
执行阶段。在此阶段，将组中的执行单元一起发送到对应的底层数据源。数据源并行执行 SQL，并为分布式事务或监督发送事件音讯。
5.2 后果合并
后果合并将来自不同数据源的多个后果汇合并为一个，并将后果返回给用户应用程序。上文提到流合并和内存合并两种合并形式，对于不同的语句咱们采纳不同的合并形式。
对于迭代语句咱们采纳流合并的形式，只须要将后果依照数据库游标逐个合并。对于排序（Order by）语句而言，因为每个数据源返回的后果集是有序的，咱们采纳流合并来应用多路合并算法将这些后果汇合并为一个后果集。如果语句同时蕴含 GROUP BY 和 ORDER BY，并且 GROUP BY 和 ORDER BY 的属性雷同，则能够应用流合并。因为组中的数据记录都位于游标所指向的第一地位，如图 10，咱们从左到右扫描指向的数据记录（标记为橙色）并累积分数，直到名字不是“Jerry”，输入“Jerry，185”后，调整数据库游标并反复上述操作。其余状况咱们须要应用内存合并。
（图 10：GROUP BY 时流合并示例）
此外咱们还能够将流合并和内存合并用于聚合语句以及分页操作。
06 适配器和应用程序
ShardingSphere 蕴含两个适配器：ShardingSphere-JDBC 和 ShardingSphere-Proxy。前者能够被视为加强的 JDBC 驱动程序。它封装了整个 SQL 引擎和 ShardingSphere 提供的其余性能，能够在任何应用 JDBC 的中央应用。后者是一个代理服务器，它将来自应用程序的申请转发到数据源。它提供了一个连接池，因而不同的应用程序和不同的查问能够共享同一连贯。ShardingSphere-Proxy 将本人伪装成 MySQL 或 PostgreSQL 数据库。所以它对应用程序开发人员是通明的，并且反对任何编程语言。
当初全世界曾经有许多中央在应用 ShardingSphere 零碎比方京东白条、中国电信翼领取等。ShardingSphere 进步了服务质量，升高了开发成本。
07 试验
数据集：1）Sysbench，这是一个驰名的数据库基准测试工具，它提供了一个表格，容许用户调整其数据量。2）TPCC，一个宽泛应用的 OLTP 基准，它模仿了商店常常应用的几种交易类型。它的 10 个表按仓库组织（每个仓库约 600,000 个条目）。
比照办法：MySQL v5.7.26（MS）；PostgreSQL v10.17（PG）；Vitess v12.0.0；Citus v9.0.0；TiDB v5.2.0；CockroachDB v21.1.11（CRDB）；Aurora MySQL v2.07.2；Aurora PostgreSQL v4.2。
咱们在华为云中应用了一个由 12 台虚构服务器组成的集群，每台服务器都装备了 CentOS 7.1 64 位、32-VCORE CPU、64 GB 内存和 1TB 磁盘。
比照试验。应用 Sysbench 进行比拟，如下表所示，基于 ShardingSphere 的零碎在所有场景中总是体现最好的。
应用 TPCC 进行比拟，TPCC 提供了五个场景，每个场景的比例是固定的，所以咱们只给出整体体现。如图 11 可看出 SSJ 成果最好。
（图 11：不同分布式系统的比拟）
可伸缩性试验。接下来咱们只与 TiDB 进行比照，因为它相比于别的零碎性能最优。如图 12，基于 SSJ 的零碎总是执行得最好。
（图 12：不同数据量）
不同的并发数，如图 13 基于 SSJ 的零碎在 TPS 方面体现最好。
（图 13：不同并发数）
不同的数据服务器，如图 14，TPS 先略有减少，而后在数据服务器数量超过 3 台时保持稳定。起因可能有两个。首先，咱们只应用一个代理服务器，这可能是一个瓶颈。其次，随着数据服务器的增多，网络可能成为另一个瓶颈。
（图 14：不同数据服务器数量）
咱们验证的绑定表的有效性，图中 Common 是没有绑定关系的表查问的性能，可显著看出远远不如有绑定关系的绑定表的效率。
（图 15：绑定表的性能）
咱们测试了不同最大连接数 MaxCon 对效率的影响，如图 16。
（图 16：最大连接数的效率）
08 总结
本文介绍了开源数据分片零碎 Apache ShardingSphere，它容许用户像应用一个数据库一样应用分片数据库。在两个驰名的基准测试工具上进行了宽泛的试验，验证了在咱们的设置下，ShardingSphere 的性能在大多数状况下都优于其余分片零碎和新架构的数据库。越来越多的公司正在将 ShardingSphere 用于其要害的应用程序。在将来的工作中，咱们将提供基于 ShardingSphere 的“数据库 +”产品，并构建一个具备更多可插拔性能的生态系统。
⏰ 欢送点击下载论文。
欢送增加社区经理微信（ss_assistant_1）退出交换群，与泛滥 ShardingSphere 爱好者一起交换。
