MyCAT和MySQL服务能力的对比梳理

开发语言

基于Java语言开发

基于C++，C开发

产品定位

数据库中间件（Proxy)

数据库基础服务

SQL支持

事务支持

支持度较差（目前业务不接入事务）

原生支持基于ACID事务模型

主键依赖

对于主键依赖度高，如果主键和分片字段不一致，查询代价较高

主键依赖以规范为主

表关联

数据无法实现表关联（跨分片规则的表关联），支持有限

支持较为丰富

SQL优化

支持基础的SQL，5.7以及8.0以上版本支持度不足

原生支持

聚合查询

的代价相对较高，目前采用只读集群绑定分片从库的模式

查询代价中等，会有瓶颈

支持存储过程

不支持

支持

自增列

全局ID较为复杂，分片自增ID会有重复

ID连续

高可用

高可用能力

数据分片故障时（写节点）基于MHA,可实现分钟级的数据故障切换（如数据复制节点出现宕机，对集群完全不影响， 如数据写入节点宕机，会直接影响业务）

数据分片故障时（写节点）基于MHA,可实现分钟级的数据故障切换

负载均衡

Proxy层支持负载均衡

不支持

性能

吞吐量

吞吐量高（比如支撑每秒5-10万的QPS）

单机性能难以扩展

数据延迟

分片配置自定义程度高，完全基于主键，性能表现相对更优

单机延迟难以优化

扩缩容

存储容量

1.2T~4T

标准化300G~500G

集群缩容

不支持

不支持

扩展能力

只能按照N*2的模式扩展

不支持

分片管理

分片管理

分片配置较为复杂，也是最核心，最复杂同时是难以自动化的环节

无

分片冗余

数据分片冗余2份（基于数据复制），空间占用略低

数据冗余2分（基于数据复制）

业务迁移

跨机房切换

可控度高，切换时间短

可控度高，切换时间较短

业务迁移代价

需要做一些前置的设计改造，代价略高

无

数据流转

数据导出

较为复杂

社区工具支持

数据导入

原生工具支持，基于load导入和SQL导入

社区工具支持

数据流转

数据T+1交付，从MyCAT流转至数仓体系，分片聚合较为复杂

流转实现相对简单

社区生态

社区活跃度

早期较为活跃，现在不够活跃，版本迭代度低

活跃度高

产品文档

相关文档较少

文档丰富

技术活动

几乎没有

活动较丰富

运维管理

管理模式

完全基于中间件模式管理，多个中间件的管理是独立的

点对点式管理

读写分离

可以实现读的隔离扩展，可以实现一主多从的扩展，而且不影响线上业务

原生支持

配置文件管理

基于xml的模式配置管理

无

参数优化

系统参数优化空间较小

参数和配置丰富

自动化运维

自动化运维代价中等

自动化运维代价低

备份配置

分片模式的备份配置较为简单，而且可以按照单实例MySQL的模式来备份处理

原生工具支持

监控&部署

硬件配置

数据库资源要求不高，标准配置PC即可，SSD更佳

配置要求低

跨机房部署

支持度高

支持度高

部署模式

部署代价中等，需要单独配置数据分片，在CentOS 6/7中均可以快速部署

部署简单

部署规模

10台虚拟机+

1台虚拟机+

监控

中间件管理和监控，MyCAT功能相对单一，目前没有部署

有社区的开源监控方案

定制开发

定制开发核心服务

门槛中等

门槛较高

定制开发运维服务

需要全新开发

行业的工具较为丰富