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

作者: admin 分类: 公众号存档 4 次浏览发布时间: 2021-10-12 19:25

公众号：杨建荣的学习笔记 · 作者：杨建荣 · 发布：2021-10-12 19:25:58 · 原文链接

这是学习笔记的第 2382篇文章

今天下午对比了下MyCAT，MySQL和其他数据库的能力项对比情况，梳理了一个列表，因为篇幅原因，主要包含如下的一些能力项。

	能力项	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功能相对单一，目前没有部署	有社区的开源监控方案
定制开发	定制开发核心服务	门槛中等	门槛较高
定制开发	定制开发运维服务	需要全新开发	行业的工具较为丰富