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

　　这是学习笔记的第 2382篇文章
　　今天下午对比了下MyCAT，MySQL和其他数据库的能力项对比情况，梳理了一个列表，因为篇幅原因，主要包含如下的一些能力项。
　　能力项MyCATMySQL单机版
　　开发语言基于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功能相对单一，目前没有部署有社区的开源监控方案定制开发定制开发核心服务门槛中等门槛较高定制开发运维服务需要全新开发行业的工具较为丰富
　　各大平台都可以找到我
　　微信公众号：杨建荣的学习笔记
　　Github：@jeanron100
　　CSDN：@jeanron100
　　知乎：@jeanron100
　　头条号：@杨建荣的学习笔记
　　网易号：@杨建荣的数据库笔记
　　大鱼号：@杨建荣的数据库笔记
　　腾讯云+社区：@杨建荣的学习笔记
　　原创热文：
　　维护之夜，说点故事和经验
　　我们为什么在MySQL中几乎不使用分区表
　　新年大吉 总结了如下的感想
　　《大江大河2》最触动我的一段经典对话
　　MySQL 8.0给开发方向带来的一些困扰