摘自《Mycat权威指南》
首先,全面了解 Mycat 的能力、目前的限制、以及可能的解决办法,然后,在此基础上,考虑是否用Mycat的分表分片功能,根据目前业务的数据模型和数据访问模式,确定几个可能的分表方案,然后对方案进行针对性的性能测试,在性能数据的基础上,最终决定采用怎样的分片策略。
一、了解 Mycat
了解 Mycat 的能力,包括如下的方面:
- Mycat 的起源和解决的目标
- Mycat 在数据库中间件方面的独特功能和定位
- Mycat 的实际案例情况
- Mycat 的优点和不足
- Mycat 所提供的监控和测试工具
- Mycat 社区的动态
其中,关于分片规则的支持和扩展、多数据库支持、 SQL 拦截和注解、跨库 Join、读写分离、缓存功能、高可用性等方面需要比较深入的学习和理解,有助于正确的使用 Mycat 来解决当前的业务问题。
二、分析业务
接下来是分析当前业务,具体内容包括如下几个方面:
- 数据模型:重点关注数据的增长模式(实时大量增长还是缓慢增长)和规律、数据之间的关联关系
- 数据访问模式:通过抓取系统中实际执行的 SQL,分析其频率、响应时间、对系统性能和功能的影响程度
- 数据可靠性的要求:系统中不同数据表的可靠性要求,以及操作模式
- 事务的要求:系统中哪些业务操作是严格事务的,哪些是普通事务或可以无事务的
- 数据备份和恢复问题:目前的备份模式,对系统的压力等
数据的模型和访问模式在很大程度上决定了未来数据分片的模式,包括哪些表用全局表、哪些用 ER 分片、哪些用范围分片规则、哪些用一致性 Hash 或自定义方式。而数据可靠性的要求,则影响到 Mycat 后端是采用普通的 MySQL 主从还是用 Gluster 多写模式,事务性要求需要相关的表或者SQL尽量不会垮分片执行,对于以后制定本项目的编程约束有重要意义。
三、分表方案
分表方案则需要确定如下一些问题:
- 哪些表要分片、什么分片规则、依赖关联关系如何解决
- 数据迁移和扩容的手段
四、性能测试
建议根据业务分析的结果,确定两套比较合适分表方案,然后进行性能测试,选出最佳的分表方案,性能测试可以采用 Mycat自带的超级工具,此工具在前面提到过,可以模拟接近真实业务数据的数据,并随机制造大量的数据供测试,是目前开源的最佳数据库性能测试工具。
五、编程约束
在最终进入开发之前,架构师还需要给出一个编程约束,需要明确列出不能执行的 SQL 语句,这些约束可能包括如下几种:
- 跨越太多节点的查询语句
- 不能 Join 的表和相关的 Join SQL
- 很影响性能的复杂 SQL
- 对比较大的表的 SQL 操作提示
六、开发&部署
最后在开发阶段,还应该做到如下几点
- 一开始就按照最初的分片设计和数据规模,制造大量的随机数据,进行开发和测试,尽早发现性能问题
- 对所有的 SQL 进行统计分析,找出异常的 SQL,包括跨越太多分片的 SQL,以及执行缓慢的 SQL,对这些 SQL 进行分析和优化
- 时刻关注性能问题
当项目上线后,通过 Mycat Web 对系统进行监控,特别是服务的 IO 和网络指标,除此之外,对 Mycat 运行过程中的日志也要进行排查,告警信息可能是 SQL 错误,可能是 Mycat Bug,及时分析处理,并积极反馈给Mycat 社区,寻求帮助。