一 基本介绍

1.1 概述

• 官网：shardingsphere.apache.org/
• Apache ShardingSphere 产品定位为 Database Plus，旨在构建异构数据库上层的标准和生态。
• 它重视如何充分合理地利用数据库的计算和存储才能，而并非完成一个全新的数据库。
• ShardingSphere 站在数据库的上层视角，重视他们之间的协作多于数据库自身。
• 衔接 、 增量 和 可插拔 是 Apache ShardingSphere 的中心概念。
• 衔接：经过对数据库协议、SQL 方言以及数据库存储的灵敏适配，快速的衔接运用与多方法的异构数据库；
• 增量：获取数据库的拜访流量，并供给流量重定向（数据分片、读写别离、影子库）、流量变形（数据加密、数据脱敏）、流量鉴权（安全、审计、权限）、流量治理（熔断、限流）以及流量剖析（服务质量剖析、可观察性）等通明化增量功用；
• 可插拔：项目选用微内核 + 三层可插拔模型，使内核、功用组件以及生态对接彻底能够灵敏的方法进行插拔式扩展，开发者能够像运用积木相同定制归于自己的共同系统。
• Apache ShardingSphere 由 JDBC、Proxy 和 Sidecar（规划中）这 3 款既能够独立布置，又支撑混合布置合作运用的产品组成。 它们均供给标准化的基于数据库作为存储节点的增量功用，可适用于如 Java 同构、异构语言、云原生等各种多样化的运用场景。
• 关系型数据库当今仍然占有巨大市场份额，是企业中心系统的柱石，未来也难于撼动，我们愈加注重在原有基础上供给增量，而非推翻。

1.2 ShardingSphere JDBC

• 定位为轻量级 Java 结构，在 Java 的 JDBC 层供给的额外服务。 它运用客户端直连数据库，以 jar 包方法供给服务，无需额外布置和依靠，可理解为增强版的 JDBC 驱动，彻底兼容 JDBC 和各种 ORM 结构。
• 适用于任何基于 JDBC 的 ORM 结构，如：JPA, Hibernate, Mybatis, Spring JDBC Template 或直接运用 JDBC；
• 支撑任何第三方的数据库衔接池，如：DBCP, C3P0, BoneCP, HikariCP 等；
• 支撑任意完成 JDBC 标准的数据库，目前支撑 MySQL，PostgreSQL，Oracle，SQLServer 以及任何可运用 JDBC 拜访的数据库。

1.3 ShardingSphere Proxy

• 定位为通明化的数据库署理端，供给封装了数据库二进制协议的服务端版本，用于完成对异构语言的支撑。 目前供给 MySQL 和 PostgreSQL（兼容 openGauss 等基于 PostgreSQL 的数据库）版本，它能够运用任何兼容 MySQL/PostgreSQL 协议的拜访客户端（如：MySQL Command Client, MySQL Workbench, Navicat 等）操作数据，对 DBA 愈加友好。
• 向运用程序彻底通明，可直接作为 MySQL/PostgreSQL 运用；
• 适用于任何兼容 MySQL/PostgreSQL 协议的的客户端。

1.4 ShardingSphere Sidecar

• 定位为 Kubernetes 的云原生数据库署理，以 Sidecar 的方法署理一切对数据库的拜访。 经过无中心、零侵入的方案供给与数据库交互的啮合层，即 Database Mesh，又可称数据库网格。
• Database Mesh 的重视要点在于如何将散布式的数据拜访运用与数据库有机串联起来，它愈加重视的是交互，是将杂乱无章的运用与数据库之间的交互进行有效地整理。 运用 Database Mesh，拜访数据库的运用和数据库终将形成一个巨大的网格系统，运用和数据库只需在网格系统中对号入座即可，它们都是被啮合层所治理的对象。

1.5 数据库的扩展

• 数据库的扩展能够简略分为两类：向上扩展和横向扩展（水平扩展） 。
• 向上扩展是进步硬件，横向扩展是经过副本（读写别离）、笔直切分和水平切分的方法，把不同的数据放在不同的节点（物理布置的MySQL实例）中。

1.5.1 向上扩展

向上扩展，买更好的服务器，这种方法比较简略，一般情况下向上扩展就能够解决问题，但是假如代价太大了（标准越高的硬件需求花费的钱越多），就不可取了。并且向上扩展总有极限的。

1.5.2 横向扩展

横向扩展是经过副本（读写别离）、笔直切分，水平切分的方法，把不同的数据放在不同的节点（物理布置的MySQL实例）中。

1.5.2.1 读写别离

读写别离：给数据库（主数据库）增加一个从数据库，主数据库担任文本的写操作（增，删，改），从数据库担任数据读的操作，如下图所示。也能够一主多从（一个主数据库，多个从数据库），不过需求进行负载均衡。

1.5.2.2 笔直切分

笔直切分：依照功用模块划分数据，举一个例子：一个电商网站，数据库中可能有库存办理的数据，用户办理的数据，订单办理的数据，他们归于不同的功用，能够将一个数据库分红三个数据库，库存办理的数据库，用户办理的数据库，订单办理的数据数据库。

1.5.2.3 水平切分

水平切分：将同一个表中的数据进行分片保存到不同的数据库中。例如：一个用户表，我们能够将用户分片保存的不同的数据库中，能够根据 用户的ID（userID），userID%3==0的用户放到一个库中，userID%3==1 放到一个库中，userID%3==2放到一个库中。

1.6 扩展带来的问题

• 事务共同性问题：因为分库分表把数据散布在不同库乃至不同服务器，不可避免会带来散布式事务问题。
• 跨节点查询问题：因为本来一张表的数据现在散布在不同数据库，不同表中，在涉及到多表关联，必定要设计好分片战略以及查询条件，否则很可能出现笛卡尔积现象，导致功能更低。
• 跨节点多库进行查询：limit分页、order by排序等问题，就变得比较复杂了。需求先在不同的分片节点中将数据进行排序并回来，然后将不同分片回来的成果集进行汇总和再次排序。
• 不能在选用数据库自增主键，应选用散布式id，保证全局唯一。
• 实践的运用场景中，参数表、数据字典表等都是数据量较小，变动少，并且归于高频联合查询的依靠表。例子中地理区域表也归于此类型。能够将这类表在每个数据库都保存一份，一切对公共表的更新操作都同时发送到一切分库执行。
• 当然ShardingSphere Jdbc来解决这个问题

1.7 分库与分表

1.7.1 水平分库

• 以字段为根据，依照必定战略（hash、range等），将一个库中的数据拆分到多个库中。
• 每个库的结构都相同。
• 每个库的数据都不相同，没有交集。
• 一切库的并集是全量数据。

1.7.2 水平分表

• 以字段为根据，依照必定战略（hash、range等），将一个表中的数据拆分到多个表中。
• 每个表的结构都相同。
• 每个表的数据都不相同，没有交集。
• 一切表的并集是全量数据。

1.7.3 笔直分库

• 以表为根据，依照业务归属不同，将不同的表拆分到不同的库中。
• 每个库的结构都不相同。
• 每个库的数据也不相同，没有交集。
• 一切库的并集是全量数据。

1.7.4 笔直分表

• 以字段为根据，依照字段的活跃性，将表中字段拆到不同的表（主表和扩展表）中。
• 每个表的结构都不一。
• 每个表的数据也不相同，一般来说，每个表的字段至少有一列交集，一般是主键，用于关联数据。
• 一切表的并集是全量数据。