如何select一款适合自己的分库分表组件(修订版)

1,405 阅读8分钟

1 背景介绍

随着互联网金融场景的不断拓展,海量的数据访问和处理造成传统的集中式数据库开始表现出性能瓶颈,各种分布式数据解决方案的研究和场景使用应运而生,而数据的安全和合规也随着企业对数据使用的要求越来越高更加重视。因此在这种场景下,分布式数据解决方案应具备高性能、可扩展、高可用等特性,而传统的集中式数据库难以同时满足,本文重点分析分布式数据中间件的特性及相关产品的对比分析, 并根据分析结果对如何选择一款合适的分库分表中间件给出建议。

2 对比分析

从技术路线分析,分布式数据主要分三种模式,即嵌入式客户端模式、分布式数据库中间件模式和原生分布式数据库模式。

  • 切入式客户模式

功能聚集在jar中,应用通过依赖jar,不需要额外的依赖和部署,然后仅需要简单的配置即可,对业务零侵入,可灵活拆卸。

  • 中间件模式

分布式数据库中间件是架构在多个传统单点数据库系统上的中间层解决方案,通过将数据分拆到不同的数据库节点上,利用中间件来管理和访问各个数据库中的数据。互联网行业最初所使用的分布式数据库方案多是基于中间件的,在解决服务压力问题上也取得了较好的效果。

  • 分布式数据库模式 原生分布式数据库是指从架构设计、底层存储和查询处理均面向分布式数据管理需求,数据库集群作为一个整体对外提供服务,用户无需关注集群内部的实现细节。

2.1 主流中间件分析

2.1.1 Cobar

Cobar 是由 Alibaba 开源的 MySQL 分布式处理中间件,它可以在分布式的环境下看上去像传统数据库一样提供海量数据服务。

2.1.1.1 主要技术栈

采用Java语言开发,Cobar前端实现MySQL协议,即仅接受MySQL协议的请求,对接收到的SQL进行解析、路由、结果集处理等操作;内部实现Hash、枚举等常用的算法;

后端对MySQL是直接面向二进制协议访问。

2.1.1.2 社区活跃度

分析结果:

参数 说明 备注
关注度 3k左右,关注度仅是一个方面,和时间有关 仅参考,无法准确判断是否活跃
活跃度 从2014年 -- 2020年,项目活跃度明显降低,到目前基本处于停滞状态。 较准确判断是否活跃

2.1.1.3 功能约束

  • 仅支持MySQL数据库
  • SQL支持度有限

2.1.2 MyCat

MyCat是基于Cobar优化开源的分布式数据中间件,后端兼容JDBC协议,支持多数据库访问。MyCat目前存在两个版本,一个是1.xxx版本,另外一个是2.0版本。在未来2.0版本中提供客户端模式,支持不启动网络层的方式,以api方式操作mycat,实现执行sql。

2.1.2.1 主要技术栈

采用Java语言开发,MyCat前端实现MySQL协议,采用NIO或AIO接收应用请求,对接收到的SQL进行解析、路由、结果集处理等操作。

后端对MySQL数据库采用原生的二进制协议访问,同时兼容JDBC协议,支持访问多种类型数据库访问。

2.1.2.2 社区活跃度

分析结果:

参数 说明 备注
关注度 MyCat1 8.3k左右,MyCat2 624 仅参考,无法准确判断是否活跃
活跃度 从2020年5月左右开始活跃,处于持续建设中 较准确判断是否活跃

2.1.2.3 功能约束

  • 开启事务后的操作只能是同一个分片
  • 事务里使用全局表会出现非同一分片的全局表无法回滚的现象
  • 部分关联子查询暂时不支持(不可下推的子查询)
  • 对oracle支持有限

2.1.3 Dble

dble 是基于开源项目MyCat1.xxx开发的,仅支持MySQL数据库,取消了对其他数据库的支持, 对兼容性,复杂查询和分布式事务的行为进行了深入的改进/优化。

2.1.3.1 主要技术栈

采用Java语法开发,前端实现MySQL协议,采用NIO或AIO接收应用请求,内部实现SQL优化器对SQL进行优化改写,对接收到的SQL进行解析、路由、结果集处理等操作。

后端对MySQL数据库采用原生的二进制协议访问。

2.1.3.2 社区活跃度

分析结果:

参数 说明 备注
关注度 685 仅参考,无法准确判断是否活跃
活跃度 从2016年 -- 2020年,项目活跃度比较稳定,属于持续维护中 较准确判断是否活跃

2.1.3.3 功能约束

  • 仅支持MySQL数据库

2.1.4 ShardingSphere

ShardingSphere提供代理模式Sharding-Proxy,同时也提供客户端模式Sharding-JDBC;Sharding-Proxy定位为透明化的数据库代理端,提供封装了数据库二进制协议的服务端版本,用于完成对异构语言的支持。 目前先提供MySQL/PostgreSQL版本,它可以使用任何兼容MySQL/PostgreSQL协议的访问客户端(如:MySQL Command Client, MySQL Workbench, Navicat等)操作数据。

Sharding-JDBC为嵌入式客户端模式,以Jar形式嵌入在应用内

2.1.4.1 主要技术栈

采用Java语言开发,内部实现MySQL协议接收MySQL协议请求,自定义SQL语法解析模板,集成Antl4解析器对SQL进行解析,同时通过扩展spring namespace实现标签方式配置分库分表。兼容springboot。

2.1.4.2 社区活跃度

分析结果:

参数 说明 备注
关注度 12k 仅参考,无法准确判断是否活跃
活跃度 2019年发展最为活跃,后期处于稳定维护中 较准确判断是否活跃

2.1.4.3 功能约束

  • 仅支持MySQL/PostgreSQL数据库
  • SQL支持度有限

2.2 对比结论

功能对比

组件 数据库 异构语言 性能 静态入口 备注
Cobar 仅MySQL 任意 损耗略高 提供嵌入式客户端
MyCat 任意 任意 损耗略高 未来版本中会提供API支持嵌入式模式
Dble 仅MySQL 任意 损耗略高
Sharding-JDBC 任意 仅Java 损耗低

关注度对比

活跃度对比

  • 分析表中数据可知Cobar已经属于停滞状态,最近几年已经不在进行维护;

  • MyCat2.0 2019年开始发育,发展速度比较快,处于建设阶段,功能正在完善中,由于发展时间比较短,无法确定后期是否持续下去。

  • Dble发展比较稳定,属于持续维护中,对于github上用户提的Issues也定期进行解决,但仅支持MySQL数据库。

  • Sharding-JDBC 关注度为12k左右,活跃度比较稳定。

3 如何选择

一般根据以下几个原则去选择一款适合自己的分库分表中间件,没有最好,只有合适。

  • 简单原则

    如果最近3-5年内数据量根本没达到数据库瓶颈,最好不使用分库分表组件,尽可能的减少复杂性,保证业务的简单性,使用分库分表组件会增加其它复杂度,关键在此期间组件并未起到明显作用,还存在损耗。

  • 业务复杂度原则

对于SQL比较简单的业务系统推介优先考虑客户端嵌入式模式,因为客户端模式下,组件以jar包形式嵌入到应用内,组件生命周期与业务系统生命周期一致,无需额外考虑组件高可用等特性,性能明显优于代理模式的中间件。另外需要考虑物理资源是否充足,由于嵌入在应用内,所以会与业务系统共享物理资源CPU等。

对于SQL复杂,存在跨分片查询,已经无法通过业务去规避的业务系统,这种场景下需要考虑中间件代理模式,客户端模式与代理模式其中一个很大的区别就是SQL支持度方面 ;另外代理模式需要独立部署,需要使用者考虑负载,目前开源的中间件自身基本都未提供负载。复杂度相比客户端模式要高。

  • 基于现有组件选择

常见嵌入式客户端模式组件有淘宝的TDDL、美团Zebra、Sharding-JDBC等,推介使用Sharding-JDBC,从关注度和活跃度明显看出优势,TDDL和Zebra目前都以停止维护。也可以考虑自研嵌入式组件,成本相对代理模式较低。

关于中间件选取,由章节2中数据分析结论可以看出Cobar已经处于停滞状态,不推介使用;

MyCat2.0是基于1.xx开发,从2019年中开始建设,先阶段还处于建设中,功能还在完善中,如果使用的话需要做深度分析;

Dble处于稳定维护中,对于社区中提的问题也积极解决,可以考虑使用,但是仅支持MySQL数据库。

本文使用 mdnice 排版