项目总是从小到大慢慢发展的，最开始我们的项目代码架构可能就是一台代码运行的server+mysql+redis,随着用户越来越多，访问量越来越多，数据量越来越多，都会经历些神马。
1.单台mysql连接数不够用了：
一台mysql服务器会遇到
1.服务器磁盘空间不够：sharding（分片）策略，也就是水平扩容(分布式)
2.单台服务器对外提供服务时连接数不够：读写分离，布置集群
3.单表数据太大(亿)等问题，分库，分表，分区,迁移，冷热分离。。。
分析过程：
一般一开始应该是服务器数据量少，用户也少，然后慢慢的用户多了起来，并发了起来，数据量嗖嗖的增长起来，这个时候应该是先发生单库对方提供并发服务的能力不够，应为毕竟并发对数据库的拜访，特别是业务中的事物修改等行为，容易锁表造成等待，单库对外吞吐量不够，这时候虽然数据还不是很多，但也会出现瓶颈，应选择读写分离的纵向扩容策略，这一波瓶颈解决后应该能稳定一段时间了，这段时间数据库就可以稳定对外提供服务，并且不断累积数据，终于有一天由于某个业务记录数据到某表很频繁，此表数据积累已达千万级别，关于此表的sql都现慢查询，这个时候你可能需要定睛一下业务慢查询sql列表，以及分析业务，找出(或优化出)共同点，为此表创建必要索引，ok这一波慢查询又被你成功解决掉了，于是又成功渡过了一阵子，此表数据由千万级别，到达了上亿级别，io次数也虽数据量增多而增加，索引好像不怎么管用了，于是你在想如果此表数据没这么大不就啥事没有啦，于是你继续想，现在总共有A,B,C,D 4个这么大的表，其中A表也就最近10天的数据会被业务使用，其他的历史数据其实没啥作用的(至少目前是的),这个表完全可以采用冷热分离只保留今一个月的，其他数据都给我暂时搬去安全处就行啦。至于B表这个表就不好整了，此表光大就算了，而且历史数据还时不时存在修改的行为和根据本身各个字段进行where的条件刷选的行为，不过好在此表性格孤僻，跟其他的表没啥关联关系，于是思前想后mysql分片太搞人了，如果我把它给迁移到mongodb，mongodb的sharding部署起来可比mysql容易多了，毕竟人家是非关系型数据库，天生就支持分片，这样不就解决啦，以后随它变得有多大，加服务器就是啦，业务代码不需要变动，很是友好；再一个C表了，这个表数据量有进一步增长的趋势，但此表跟其他表不怎么关联，数据增长很热，历史数据不存在修改的行为，像极了日志增长行为(随时间会不停的增),业务中会经常对其发生搜索的行为，所以不能像A那样冷热分离它，也不能像B那样放到mongodb里面去(因为mongodb搜索可不是它的强项)，突然想起来不是还有一个传说中的Elasticsearch么，太吻合了，果断把表C迁移至Es中。最后一个D表，此表目前数据量虽然挺大的，但是考虑到现在经费开始紧张起来啦(前面都部署了那么多了)，然后这个表数据也不是太核心，对它产生的select也都是针对其主键的发生的，再一想这台mysql服务器刚把一大部分数据迁移到ES，mongodb，和专门备份普通大容量磁盘服务器中去了，现在我们的mysql磁盘又富裕起来啦，不如考虑下单表分区策略，根据主键来个range，分个10个或30个分区，单表数据除以分区数就不那么吓人了。
总结：
以上情景先后经历了，读写分离-》索引优化-》单表过大之冷热分离-》单表过大之mongodb迁移-》单表过大之ES迁移-》单表过大之分区。没谈分表，只是觉得分表这一步要慎重，慎重。。。然后最好别分表。。。垂直拆还好点，变一次，跟后面策略不冲突，水平拆就比较尴尬了，一定要想好，后面别变分的规则，当然管用也hai是很管用的。。。
参考文章:
MySql分表、分库、分片和分区知识
分布式与集群区别
mysql分布式部署
mycat中间件作用原理分析
mysql索引之b+tree
elasticsearch之logstash
mongodb分片思路分析
搞懂MySQL分区
mysql几种分区方式原理介绍
hash分区介绍
网友评论