分库分表简析
我这里说的数据库主要指MySQL
一：出现的问题
数据库单库里面的数据量越来越大，查询数据出来的结果所花费的时间变得越来越长；
用户越来越多，写入的数据量也变得越来越多，有时会出现延迟，即使我们做了主从读写分离，这时候该怎么办？
毕竟单台服务器上的IO，CPU，硬盘等等都是有限的，单服务器上的资源是有限的。
单台服务器不行，我们可以用多台服务器，把请求分发到不同的服务器上，这时候就用到了“分”的思想了。
同理，数据库的库和表也是可以切分--分库分表。把大库大表变成多个库表， 同时数据的读写也相应的进行了切分。
二：怎么分库分表
按大的分类，一般我们有水平切分和垂直切分。
水平切分
数据表的数据量太巨大，可以进行水平切分表。我们按照某种规则(range, hash等)把数据切分到多张表中。
水平分表
把单张大数据的表按照一定的规则把数据分配到多张数据表中。所有表的结构字段是相同的。
这样不仅能控制表的大小，还能提升查询和写入的性能，分解请求的压力。
比如我们按照range切分表数据，1000W数据分一张表，如果有1500W数据，那么另外500W数据分到第二张表。
水平分库
当然我们也可以拆分到多个库中，比如一个库存1年的数据，每个库分12张表存数据等等方法。根据你的
实际情况进行选择。
比如我们有的系统中使用的冷热数据分离，将一些历史数据迁移到历史库中。
垂直切分
垂直切分我们一般按照表字段或业务进行切分。
在数据表上一般我们是按照字段进行切分，就是把一张表的字段拆分成多张表的字段。
或把业务分成不同的业务模块，建立不同的业务模块数据库。
比如电商，把用户，商品，订单独立建立数据库。分成多个库，我们也可以部署到多台服务器上，增强数据库
的处理能力。
垂直分表
按照表字段进行切分。
比如数据库表中的字段比较多，那么我们建立一张扩展表，将不经常使用或者长度较大的字段拆分到扩展表中。
当然还有其他的拆分方式。
垂直分库
在业务上，我们一般会把业务拆分成不同的业务模块，然后根据不同的业务模块创建不同的数据库，这个就是
垂直分库。
三：常用的切分规则
1、range
比如1-100000一张表， 100001-200000一张表，每10W数据一张表
2、hash取模
比如取用户id，然后hash取模，分配到不同数据库
3、按照时间
这种切割方式对于日志的切分一般用的比较多。
比如一张表存放一个月的数据，一年就是12张表了。
四：切分后出现的问题
1、数据迁移问题
2、数据扩容问题
3、跨库join，group by，order等问题
4、事务问题
这部分问题待解决
五：分库分表中间件
| Cobar | 阿里巴巴B2B团队开发的，很少更新https://github.com/alibaba/cobar |
|---|---|
| MyCat | 基于阿里开源的Cobar产品而研发，社区开发，现在社区比较活跃http://www.mycat.io/ |
| Oneproxy | 平民软件开发，不开源的商业中间件 http://www.onexsoft.com/ |
| Kingshard | 原360开发团队的人开发的 https://github.com/flike/kingshard |
| Vitess | Youtube开发的中间件 https://github.com/vitessio/vitess |
| Atlas | 360团队基于mysql proxy开发的 https://github.com/Qihoo360/Atlas |
| MaxScale | maridb研发出的中间件 https://github.com/mariadb-corporation/MaxScale |
| MySQL Route | MySQL官方推出的中间件 https://dev.mysql.com/doc/relnotes/mysql-router/en/ |
上面的数据库中间件MyCat，Kingshard都可以好好的研究下，看看他们是如何解决上面的问题的
六：其他的方案
其他方案就是我们经常所说的 NoSQL 和 NewSQL
比如：ElasticSearch，MongoDB，HBase 等等，这些也是可以好好考虑的方案。
