一基本介绍

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 垂直分表

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

ShardingSphere JDBC （一）基本介绍

一 基本介绍