背景

用户有个普遍认识,分库分表配置繁琐,而且需要大量文档来描述配置，本文将介绍一下关系型数据库分布式解决方案Shardingsphere 与Mycat2。

Apache ShardingSphere

介绍

Apache ShardingSphere 是一套开源的分布式数据库解决方案组成的生态圈，Apache ShardingSphere 产品定位为 Database Plus，旨在构建异构数据库上层的标准和生态。 它关注如何充分合理地利用数据库的计算和存储能力，而并非实现一个全新的数据库。ShardingSphere 站在数据库的上层视角，关注他们之间的协作多于数据库自身。Apache ShardingSphere 由 JDBC、Proxy 和 Sidecar（规划中）这 3 款既能够独立部署，又支持混合部署配合使用的产品组成。 它们均提供标准化的基于数据库作为存储节点的增量功能，可适用于如 Java 同构、异构语言、云原生等各种多样化的应用场景。ShardingSphere 已于2020年4月16日成为 Apache 软件基金会的顶级项目

特点

• 连接：通过对数据库协议、SQL 方言以及数据库存储的灵活适配，快速的连接应用与多模式的异构数据库；
• 增量：获取数据库的访问流量，并提供流量重定向（数据分片、读写分离、影子库）、流量变形（数据加密、数据脱敏）、流量鉴权（安全、审计、权限）、流量治理（熔断、限流）以及流量分析（服务质量分析、可观察性）等透明化增量功能；
• 可插拔：项目采用微内核 + 三层可插拔模型，使内核、功能组件以及生态对接完全能够灵活的方式进行插拔式扩展，开发者能够像使用积木一样定制属于自己的独特系统。

架构

Apache ShardingSphere 由 JDBC、Proxy 和 Sidecar（规划中）这 3 款既能够独立部署，又支持混合部署配合使用的产品组成。 它们均提供标准化的基于数据库作为存储节点的增量功能，可适用于如 Java 同构、异构语言、云原生等各种多样化的应用场景。

独立部署

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 访问的数据库。

ShardingSphere-Proxy：定位为透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持。 目前提供 MySQL 和 PostgreSQL（兼容 openGauss 等基于 PostgreSQL 的数据库）版本，它可以使用任何兼容 MySQL/PostgreSQL 协议的访问客户端（如：MySQL Command Client, MySQL Workbench, Navicat 等）操作数据，对 DBA 更加友好。

• 向应用程序完全透明，可直接当做 MySQL/PostgreSQL 使用；
• 适用于任何兼容 MySQL/PostgreSQL 协议的客户端。

ShardingSphere-Sidecar（TODO）：定位为 Kubernetes 的云原生数据库代理，以 Sidecar 的形式代理所有对数据库的访问。 通过无中心、零侵入的方案提供与数据库交互的啮合层，即 Database Mesh，又可称数据库网格。

Database Mesh 的关注重点在于如何将分布式的数据访问应用与数据库有机串联起来，它更加关注的是交互，是将杂乱无章的应用与数据库之间的交互进行有效地梳理。 使用 Database Mesh，访问数据库的应用和数据库终将形成一个巨大的网格体系，应用和数据库只需在网格体系中对号入座即可，它们都是被啮合层所治理的对象。

混合架构

ShardingSphere-JDBC 采用无中心化架构，与应用程序共享资源，适用于 Java 开发的高性能的轻量级 OLTP 应用； ShardingSphere-Proxy 提供静态入口以及异构语言的支持，独立于应用程序部署，适用于 OLAP 应用以及对分片数据库进行管理和运维的场景。Apache ShardingSphere 是多接入端共同组成的生态圈。 通过混合使用 ShardingSphere-JDBC 和 ShardingSphere-Proxy，并采用同一注册中心统一配置分片策略，能够灵活的搭建适用于各种场景的应用系统，使得架构师更加自由地调整适合于当前业务的最佳系统架构。

MyCAT 2

介绍

Mycat2是Mycat社区开发的一款分布式关系型数据库(中间件)，是一个实现了MySQL协议的服务器，用于搭建 MySQL 数据库的分布式集群，实现分库分表功能，解决数据库中海量数据存储和查询性能的问题，前端用户可以把它看作是一个数据库代理，用MySQL客户端工具和命令行访问，而其后端可以用MySQL原生协议与多个MySQL服务器通信，也可以用JDBC协议与大多数主流数据库服务器通信，。它支持分布式SQL查询，以Java生态支持多种后端数据库，通过数据分片提高数据查询处理能力。

特点

• 代码开源：学习中间件技术,数据库技术，代码是必须有的。
• 兼容MySQL语法的分布式查询引擎：兼容MySQL语法，兼容MySQL值类型，使用基于规则优化与代价的优化器。独立的物理执行引擎。
• 自定义功能算法开发：分片算法,序列号算法,负载均衡算法等都可自定义加载。查询引擎可脱离网络框架运行。
• 自定义处理过程：自研DSL操纵物理查询计划。支持SQL转发,缓存结果集。
• 优化查询计划：定制Calcite分布式查询引擎、编译SQL到关系代数表达式、规则优化引擎和代价优化引擎、生成物理执行计划、支持逻辑视图
• SQL支持语法：任意跨库跨表join查询、支持跨库跨表非关联子查询、支持跨库跨表关联子查询、支持跨库跨表Window语法、支持全局二级索引、有限支持存储过程、支持可视化配置
• 高性能：支持并行拉取结果集、支持自动调动后端结果集、支持多种路由注释、优化器注释
• 支持定制任意多字段路由：提供分片算法接口、优化器简化过滤条件、分片信息与关系表达式结合生成执行sql
• 支持原生协议：前端协议MySQL网络通信协议、MySQL原生网络协议异步非阻塞、JDBC接口支持多种数据库、生成物理执行计划

应用场景

理论上Mycat2与单机数据库差别不大,但是由于其涉及多个存储节点以及定位是事务型数据库,并不是所有应用场景都会特显优势,以下是常见的用法。

• 任意数据源合拼的分布式查询
• 管理多数据库实例，比如管理全国城市数据库
• 点查/范围查询分片数据，业务访问呈现点查/范围规律而且可以根据分片键分散访问压力
• 二阶段聚合汇总，比如统计求和,MySQL计算一部分和值,Mycat再对结果汇总
• 二阶段数据源汇总，比如利用子查询查询物理库数据,而Mycat再对结果汇总
• 单表访问读写分离
• 多租户场景

不适合场景

• 无分片条件的SQL
• join多于3个表,不区分分片表,单表,全局表

Mycat2与1.6区别

架构

计算节点(Mycat)和存储节点(MySQL)组合架构，一般来说,Mycat2使用数据库（接收sql的服务器）作为存储节点进行读写,当然未来也支持直接以自定义接口读写数据。特别地，暂时Mycat2没有实现系统表，所以查询系统表的sql需要转发到特殊的节点处理后返回到客户端。

• 网络层:NIO Netty Vertx
• 数据库与其客户端:开源数据库通信协议MySQL,闭源数据库与其客户端JDBC
• 单机执行器与分布式执行器:火山模型,Push模型
• 查询优化器:Apache Calcite,
• 查询编译器: Apache Calcite,Mycat 1.6
• 执行器:Ling4j,RxJava

应用架构

总结