mycat与sharding-sphere对比

参考文档：

https://dbaplus.cn/news-11-1854-1.html

1.方案对比

mycat是db 代理的分库分表解决方案。

sharding-sphere中sharding-jdbc是对jdbc 代理的分库分表解决方案。

从解决方案/架构来看sharding-jdbc更符合分布式架构的设计，直连数据库，没有中间应用，理论性能是最高的（实际性能需要结合具体的代码实现，理论性能可以理解为上限，通过不断优化代码实现，逐渐接近理论性能）。同时缺点也很明显，由于作为组件存在，需要集成在应用内，意味着作为使用方，必须要集成到代码里，使得开发成本相对较高。

另一方面，由于需要集成在应用内，使得需要针对不同语言（java、C、PHP……）有不同的实现（事实上sharding-jdbc目前只支持java），这样组件本身的维护成本也会很高。最终将应用场景限定在由java开发的应用这一种场景下。

DBproxy 高度依赖网络组件，它需要诸如 LVS/F5 等 VIP 来实现流量的负载均衡，如果跨 IDC，还依赖诸如 DNS 进行IDC 分发。同时部分 DBproxy 对 Prepare 这类操作支持不友好，所以它的问题概括来说：

• 链路过长，每层都会增加响应时间
• 网络单点，并且往往是整个公司层面的单点
• 部分产品对Prepare 应用不友好，需要绑定 connection 信息

JDBC Proxy 最大的问题是违背了 DB 透明的原则，它需要对不同的语言编写 Driver，概括来说：

• 语言限制，总会遭到一批 RD 同学的吐槽 “世界上最好的语言竟然不支持！”
• 接入繁琐
• DB 不透明

2.项目归属及活跃度

sharding-sphere是apache的顶级项目。

mycat未找到拖管方。mycat源码在github上。https://github.com/MyCATApache，网上风评对mycat不友好。github上mycat的issue中bug还有71个open。

3.网上对比

sharding-jdbc:

优点：

1.可适用于任何基于java的ORM框架,如:JPA、Hibernate、Mybatis、Spring JDBC Template,或直接使用JDBC

2.可基于任何第三方的数据库连接池,如:DBCP、C3P0、Durid等

3.分片策略灵活,可支持等号、between、in等多维度分片,也可支持多分片键。

4.SQL解析功能完善,支持聚合、分组、排序、limit、or等查询,并支持Binding Table以及笛卡尔积表查询。

5.性能高,单库查询QPS为原生JDBC的99.8%,双库查询QPS比单库增加94%。

缺点：

1.理论上可支持任意实现JDBC规范的数据库。目前仅支持mysql

2.维护会比较麻烦，需要逐个项目的修改配置。不能进行跨库连接，代码需要进行改造。

3.在扩展数据库服务器时需要考虑一致性哈希问题，或者采用分片键局部取模方式，也难免要进行部分的数据迁移。

mycat:

优点：

1.支持Mysql集群，可以作为Proxy使用

2.支持JDBC连接ORACLE、DB2、SQL Server，将其模拟为MySQL Server使用

3.自动故障切换，高可用性

4.支持读写分离，支持Mysql双主多从，以及一主多从的模式 ，支持全局表，数据自动分片到多个节点，用于高效表关联查询

5.支持独有的基于E-R 关系的分片策略，实现了高效的表关联查询

6.多平台支持，部署和实施简单(主备切换、库迁移等友好)

缺点：

1.mycat不支持二维路由，仅支持单库多表或多库单表 由于自定义连接池，这样就会存在mycat自身维护一个连接池，MySQL也有一个连接池，任何一个连接池上限都会成为性能的瓶。

4.网上选择

网友A:

如果项目比较简单，需要使用的分片策略和算法不复杂，那么可以用Sharding-JDBC；如果项目比较复杂，分片规则比较复杂，而且具有一定的运维能力，那么选择Mycat。

网友B:

本着符合业务场景，可靠度高，接入成本低，具有良好的文档，活跃的社区的原则，打算采用shardingJdbc，涉及到分表策略选择使用城市的维度。