1       背景

互联网时代数据日益增长，单表已满足不了数据存储，当前涌现很多 nosql，newsql 数据存储，但目前系统设计概念基于关系数据库，nosql，newsql 不能很好适应，基于关系数据库的数据分片显然是目前比较好的解决方案

组件基于 sharding-jdbc 3.1.0，针对 sharding-jdbc 使用上痛点和缺失在源码级别解决和增强，附有使用指南设计

2       核心概念

2.1     逻辑表

水平拆分的数据库/表的相同逻辑和数据结构表的总称。例：订单数据根据主键尾数拆分为 10 张表，分别是 t_order_0 到 t_order_9，他们的逻辑表名为 t_order。

2.2     真实表

在分片的数据库中真实存在的物理表。即上个示例中的 t_order_0 到 t_order_9。

2.3     绑定表

指分片规则一致的主表和子表。例如：t_order 表和 t_order_item 表，均按照 order_id 分片，则此两张表互为绑定表关系。绑定表之间的多表关联查询不会出现笛卡尔积关联，关联查询效率将大大提升。

2.4     逻辑库/真实库

与逻辑表/真实表类似，同时真实库配置连接参数，也是连接数据源

3       架构设计

sharding-spring my-sharding 的 spring boot starter，接管 sharding-jdbc 启动，构建库表资源模型，初始化自有的分片策略框架，按 sharding-jdbc 要求初始化库表列表，即 data nodes；构建分片数据源

jdbc 代理sharding-jdbc 自身实现一套 jdbc 代理，嵌入分库分表的逻辑，无缝地接入持久层

sql 解释/sql 路由/sql 改写/sql 执行/结果归并sharding-jdbc 分片的核心功能模块

apm 埋点 手动埋探针，采集 ql 解释/sql 执行执行性能

my-sharding  sharding-jdbc 扩展和改造 

3.1     shardsphere

下图展现 shardingsphere 整体模块

sharding-jdbc/sharding-proxysharding-sphere 呈现的两个产品，sharding-jdbc 轻量级分片组件，内部实现一套 jdbc 标准组件，嵌入分库分表逻辑；sharding-proxy 数据库代理，实现数据库的交互协议

sharding-core sql 改写，解释，执行等数据分片的核心功能，sharding-jdbc/sharding-prox 代理壳不一样，共用分片的核心逻辑

sharding-orchetration分片治理，包括注册中心，配置中心，支持 zookeeper 分布式配置及配置变更

sharding-transaction 分片事务模块，支持 xa，v4.0 支持 base 事务，集成 seata

sharding-opentracing 原生支持 opentracing 0.30.0，my-sharding 重写代码，支持 0.31.0，至此新的链路跟踪平台，如 zipkin server 5.x

sharding-spring 包括分片的 starter，事务 starter，由于 my-sharding 自有的 spring boot starter，只使用事务 starter

*shardingsphere 规划还有一款产品，sharding-sidecar，称为数据库网格，规划中，还没实现

3.2     my-sharding

service 资源服务，库表资源管理 api，表的生成和扩充

resource 库表资源模型

strategy 分片策略/算法

function y=f(x), 投射函数，分片键值(x)投射到库/表(y)集合，包括预处理，如，取整，字符串截取，日期截取；投射，取模，=，表达式

springboot starter/springboot starter apm

3.2.1 问题                                                                                     

Ø  原生提供的 inline 表达式的分片算法，不支持日期，字符等复杂分片算法, 需要自行扩展

Ø  sql 不兼容，哪怕是肉眼看到是路由到一个库，主要是解释器问题

Ø  opentracing 版本 0.30，不兼容主流版本的链路服务，如 zipkin 5.x

3.2.2     解决方案

1.   库表资源建模， 从而掌握库表控制权，分库分表实质库表资源分配，是算法框架的核心，也是在 shardingsphere 解释不了 sql，绕过 sharding-jdbc 自行生成物理 sql 的关键

2.   集合映射分片算法框架

Ø  sharding-jdbc 自身只实现 inline 表达式的 hash 分片算法，不能满足实际需要，因此开发了基于集合分布分片算法框架，支持不同维度的分片算法

Ø数据分片抽象成数学概念，就是某个数值或者范围值(即)分片主键值)与特定集合(真实表名称)的映射 f(x)->y, x 为分片键值，y 真实表集合

这里要求真实表命名：逻辑表名称{后缀}，其中‘后缀‘是集合元素值

Ø  库表资源集合分布类型：

>整数集合，例如，userId 取模，年龄范围

>日期集合，年，月，周，日，时等

>字符集合，如，“a~z”,“A~Z”

>离散点集合，没有顺序数值集合

>并集合，不连续同类型的集合的并

示例：2 个数据库，存放 6 个月数据，采用分片算法，按月分库，按日分表

考虑到数据分布不均匀，按经验，146 月分到一个库，235 月分到另一个库

库资源集合，采用离散点集合，[1,4,6]， [2,3,5]；

表资源集合，采用日集合并集，{[1.1~1.31]&[4.1~4.30]&[6.1~6.30]}，{[2.1~1.28]&[3.1~3.31]&[5.1~5.31]}

3.2.2.1          库表资源模型

库表资源模型

3.2.2.1.1 库表集合模型

库表资源看成连续的集合，分库分表就是根据 sql 分片键值，映射到具体库和表元素，已实现整形，字符，日期等集合类型和映射

3.2.2.2          定位真实表时序

分片路由计算变成，数值定位到哪个集合里(使用并集的情况下)的哪个元素的计算

1). 分片算法调用资源管理器，传入逻辑表名称查找逻辑表

2). 资源管理器找出逻辑表并返回

3). 分片算法调用逻辑表 locate 方法，传入分片键值

4). 逻辑表调用资源集合 locate 方法定位真实表 (集)

5). 数值预处理和值定位计算，预处理:  取模，日期截取；计算:  =，in；range

3.2.2.3          性能监控 apm

apm 应用性能监控，发现性能瓶颈，持续改进

手动埋点，分别在 sql 解释，sql 执行埋点，监控其性能

apm 监控台示例

1.      执行概览

开始(rootInvoke)->分析(parsesql)->执行(executesql)，下面示例不带分片键条件的 select sql，全域扫描，sql 路由到所有的库/表执行

2.      分析阶段

执行时间，包括自定义标签，逻辑 sql

3.      执行阶段

实际执行 sql，实际路由到哪个库，哪个表

3.3     代码下载(收费)

mysharding 修改了 shardingsphere 分片策略源码，为了不混淆原生，修改 jar 包名字，包结构没变

https://download.csdn.net/download/szlhj/77817675

测试包括，整形/日/月/字符的数据分片场景，例如，按店铺 id 取模分库+按月分表等，并接入 opentracing，apm 监

3.4     开发指南

3.4.1     分片设计

分库分表成败 90%+在于分片设计，分片设计 99%的关键在于表分析，分析表之间的关系，sql，选择分片键，

分片键的选择，总会有利于一些 sql，而另一些 sql 因分片不能在单库执行，需要拆分，或使用搜索引擎

3.4.2     分片配置

分片配置使用 xml，配置分绑定表，逻辑库，真实库，逻辑表，每部分可以拆开，避免文件过大，编辑阅读困难, 以后扩展到 yml，继而支持 nacos，zookeeper，apollo 等常用的配置中心

示例：

  参考 sharding-sphere/my-sharding/my-sharding-resouce-xml 工程

3.4.3     创建分片库

分片框架没有提供 api 直接创建分片库，需手动创建

3.4.4     创建分片表

  组件提供工具自动创建分片表，如下图：

框架提供工具类,  my-sharding-tools-gentable.jar, 生成分片表

命令行 java -jar my-sharding-tools-gentable.jar gentable [ddl]

其中，ddl 是创建表(逻辑表)ddl

3.4.5     系统改造

数据分片后，系统需相应的改造，以适应分片要求

3.4.5.1     分离分片/非分片表

3.4.5.1.1 多数据源配置

分片后，非分片使用原有数据源；分片表使用分片框架创建的代理数据源

3.4.5.1.2 服务和 dao

服务和 dao 分离到不同的文件夹，方便扫描，事务切入

3.4.5.2          sql 拆分

分片后，分片键选择，导致除了绑定表外，其他 join 需要跨库，需要拆分 sql 分段执行，合并结果，或者使用搜索引擎，宽表查询

3.4.5.3          手动计算和执行真实 sql

sharding-sphere 有限度支持 sql，例如，3.1.0 不支持 distinct

但有些情况，sql 有分片健作为条件，肉眼可见 sql 路由到单库，s 是可以执行的

例如，

select distinct

t1.partno, t1.uoi

from #{shardingTable}  t1

where t1.parent_id = #{parentId}

假设 t1 以 parentId 分片，而 parentId 是查询条件，sql 最终路由到单库

my-sharding 管理着库表资源，分片算法和数据源，可以轻松地手动计算出实际 sql，

1)     ResourceCollection 的 locate 方法，传入分片键值，获得真实库真实表

2)     替换逻辑 sql 的逻辑表，活动实际 sql

3)     真实库获得真实数据源，执行实际 sql

3.4.6     分布式事务

xa/base

版本 3.x 只支持 xa，有 atomikos 实现

版本 4+，增加 base 支持，集成 seata 实现；xa 增加多种实现

分布式事务 3 个场景：

1.      非分表/分表的事务 不支持

2.      多分片表 支持

2.1    广播表

2.2    其他

对于 2.2 应尽量避免，相比分片前本地事务，xa/base 吞吐率/性能都会大幅下降；base 最终一直，业务需要识别是否合适

对于 2.1 广播比表，例如，数据字典，xa 是合适方案，时间容忍度高，需要严格保障一致性

3.4.7     搜索引擎

    数据分片后，一些数据跨库，需要拆分执行，也可以使用搜索引擎，完整的放到搜索引擎索引，数据查找在搜索引擎进行，同时数据变更使用数据同步，同步到搜索引擎

参考《搜索引擎 onesearch 设计与实现.docx》

规划

1)      支持 yml 分片配置，进而支持 nacos，apollo 等配置中心

2)      完善 function 模块

3)      升级到 shardingsphere 5