Apache ShardingSphere 是一套开源的分布式数据库中间件解决方案组成的生态圈,它由 JDBC、Proxy 和 Sidecar(规划中)这 3 款相互独立,却又可以混合部署配合使用的产品组成。 它们均提供标准化的数据分片、分布式事务和数据库治理功能,可适用于如 Java 同构、异构语言、云原生等各类多样化的应用场景。算法
Apache ShardingSphere 定位为关系型数据库中间件,旨在充分合理地在分布式的场景下利用关系型数据库的计算和存储能力,而并不是实现一个全新的关系型数据库。 它经过关注不变,进而抓住事物本质。关系型数据库当今依然占有巨大市场,是各个公司核心业务的基石,将来也难于撼动,咱们目前阶段更加关注在原有基础上的增量,而非颠覆。sql
Apache ShardingSphere 5.x 版本开始致力于可插拔架构,项目的功能组件可以灵活的以可插拔的方式进行扩展。 目前,数据分片、读写分离、多数据副本、数据加密、影子库压测等功能,以及 MySQL、PostgreSQL、SQLServer、Oracle 等 SQL 与协议的支持,均经过插件的方式织入项目。 开发者可以像使用积木同样定制属于本身的独特系统。Apache ShardingSphere 目前已提供数十个 SPI 做为系统的扩展点,仍在不断增长中。数据库
ShardingSphere 已于2020年4月16日成为 Apache 软件基金会的顶级项目。数据结构
定位为轻量级Java框架,在Java的JDBC层提供的额外服务。 它使用客户端直连数据库,以jar包形式提供服务,无需额外部署和依赖,可理解为加强版的JDBC驱动,彻底兼容JDBC和各类ORM框架。架构
定位为透明化的数据库代理端,提供封装了数据库二进制协议的服务端版本,用于完成对异构语言的支持。 目前先提供MySQL/PostgreSQL版本,它可使用任何兼容MySQL/PostgreSQL协议的访问客户端(如:MySQL Command Client, MySQL Workbench, Navicat等)操做数据,对DBA更加友好。框架
定位为Kubernetes的云原生数据库代理,以Sidecar的形式代理全部对数据库的访问。 经过无中心、零侵入的方案提供与数据库交互的的啮合层,即Database Mesh,又可称数据网格。运维
Database Mesh的关注重点在于如何将分布式的数据访问应用与数据库有机串联起来,它更加关注的是交互,是将杂乱无章的应用与数据库之间的交互有效的梳理。使用Database Mesh,访问数据库的应用和数据库终将造成一个巨大的网格体系,应用和数据库只需在网格体系中对号入座便可,它们都是被啮合层所治理的对象。分布式
Sharding-JDBC采用无中心化架构,适用于Java开发的高性能的轻量级OLTP应用;Sharding-Proxy提供静态入口以及异构语言的支持,适用于OLAP应用以及对分片数据库进行管理和运维的场景。ide
ShardingSphere是多接入端共同组成的生态圈。 经过混合使用Sharding-JDBC和Sharding-Proxy,并采用同一注册中心统一配置分片策略,可以灵活的搭建适用于各类场景的应用系统,架构师能够更加自由的调整适合于当前业务的最佳系统架构。性能
水平拆分的数据库(表)的相同逻辑和数据结构表的总称。例:订单数据根据主键尾数拆分为10张表,分别是t_order_0
到t_order_9
,他们的逻辑表名为t_order
。
在分片的数据库中真实存在的物理表。即上个示例中的t_order_0
到t_order_9
。
数据分片的最小单元。由数据源名称和数据表组成,例:ds_0.t_order_0
。
指分片规则一致的主表和子表。例如:t_order
表和t_order_item
表,均按照order_id
分片,则此两张表互为绑定表关系。绑定表之间的多表关联查询不会出现笛卡尔积关联,关联查询效率将大大提高。举例说明,若是SQL为:
SELECT i.* FROM t_order o JOIN t_order_item i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
在不配置绑定表关系时,假设分片键order_id
将数值10路由至第0片,将数值11路由至第1片,那么路由后的SQL应该为4条,它们呈现为笛卡尔积:
SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11); SELECT i.* FROM t_order_0 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11); SELECT i.* FROM t_order_1 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11); SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
在配置绑定表关系后,路由的SQL应该为2条:
SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11); SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
其中t_order
在FROM的最左侧,ShardingSphere将会以它做为整个绑定表的主表。 全部路由计算将会只使用主表的策略,那么t_order_item
表的分片计算将会使用t_order
的条件。故绑定表之间的分区键要彻底相同。
指全部的分片数据源中都存在的表,表结构和表中的数据在每一个数据库中均彻底一致。适用于数据量不大且须要与海量数据的表进行关联查询的场景,例如:字典表。
用于分片的数据库字段,是将数据库(表)水平拆分的关键字段。例:将订单表中的订单主键的尾数取模分片,则订单主键为分片字段。 SQL中若是无分片字段,将执行全路由,性能较差。 除了对单分片字段的支持,ShardingSphere也支持根据多个字段进行分片。
经过分片算法将数据分片,支持经过=
、>=
、<=
、>
、<
、BETWEEN
和IN
分片。分片算法须要应用方开发者自行实现,可实现的灵活度很是高。
目前提供4种分片算法。因为分片算法和业务实现紧密相关,所以并未提供内置分片算法,而是经过分片策略将各类场景提炼出来,提供更高层级的抽象,并提供接口让应用开发者自行实现分片算法。
精确分片算法
对应PreciseShardingAlgorithm,用于处理使用单一键做为分片键的=与IN进行分片的场景。须要配合StandardShardingStrategy使用。
范围分片算法
对应RangeShardingAlgorithm,用于处理使用单一键做为分片键的BETWEEN AND、>、<、>=、<=进行分片的场景。须要配合StandardShardingStrategy使用。
复合分片算法
对应ComplexKeysShardingAlgorithm,用于处理使用多键做为分片键进行分片的场景,包含多个分片键的逻辑较复杂,须要应用开发者自行处理其中的复杂度。须要配合ComplexShardingStrategy使用。
Hint分片算法
对应HintShardingAlgorithm,用于处理使用Hint行分片的场景。须要配合HintShardingStrategy使用。
包含分片键和分片算法,因为分片算法的独立性,将其独立抽离。真正可用于分片操做的是分片键 + 分片算法,也就是分片策略。目前提供5种分片策略。
标准分片策略
对应StandardShardingStrategy。提供对SQL语句中的=, >, <, >=, <=, IN和BETWEEN AND的分片操做支持。StandardShardingStrategy只支持单分片键,提供PreciseShardingAlgorithm和RangeShardingAlgorithm两个分片算法。PreciseShardingAlgorithm是必选的,用于处理=和IN的分片。RangeShardingAlgorithm是可选的,用于处理BETWEEN AND, >, <, >=, <=分片,若是不配置RangeShardingAlgorithm,SQL中的BETWEEN AND将按照全库路由处理。
复合分片策略
对应ComplexShardingStrategy。复合分片策略。提供对SQL语句中的=, >, <, >=, <=, IN和BETWEEN AND的分片操做支持。ComplexShardingStrategy支持多分片键,因为多分片键之间的关系复杂,所以并未进行过多的封装,而是直接将分片键值组合以及分片操做符透传至分片算法,彻底由应用开发者实现,提供最大的灵活度。
行表达式分片策略
对应InlineShardingStrategy。使用Groovy的表达式,提供对SQL语句中的=和IN的分片操做支持,只支持单分片键。对于简单的分片算法,能够经过简单的配置使用,从而避免繁琐的Java代码开发,如: t_user_$->{u_id % 8}
表示t_user表根据u_id模8,而分红8张表,表名称为t_user_0
到t_user_7
。
Hint分片策略
对应HintShardingStrategy。经过Hint指定分片值而非从SQL中提取分片值的方式进行分片的策略。
不分片策略
对应NoneShardingStrategy。不分片的策略。