数据库Sharding

Sharding介绍

Sharding的基本思想就要把一个数据库切分成多个部分放到不同的数据库(server)上，从而缓解单一数据库的性能问题。Sharding分为垂直拆分和水平拆分两种。

垂直拆分

在业务的初期，不可避免会将多个系统的db放在同一台mysql instance上，伴随这业务的不断壮大，需要进行“垂直拆分”，将不同的业务拆分出去。

拆分原因：

• 防止其他db使用不当，比如说有问题的SQL（可能是未使用到索引，可能是一个复杂的统计SQL），导致服务器的IO、CPU消耗严重，影响了其他的db；
• db的账号设计不合理，导致不同db之间存在数据的交叉访问，这样存在数据泄露的风险，比如某个db因为SQL注入，其他db的数据也被拖库；
• 资源上的不足，比如说随着业务的不断扩大，单台的instance受到io、cpu、disk等硬件的限制，很难支撑起诸多的db；

分别针对这三个原因进行解释：

• 避免影响主要两种思路，第一种思路通过业务SQL的审核、限制SQL资源的消耗来实现，第二种思路就是拆分到不同的物理机或者不同的instance上，通过cgroup等来限制对于io、cpu等资源的使用；
• 可以使用更加细分的权限设置来避免这种跨库的访问；
• 这种情况下，只能进行拆分或者scale up的策略来进行；

拆分方法：

• 通过MySQL Replication，搭建Slave，在业务确定没有use db1;update db2.table的情况下可以使用replicate-do-db或者replicate-do-table避免copy以及复制大量的数据；
• 业务更改写入源，写入新的master；
• 通过binlog检查老的master中需要拆分出去的db是否还有写入；
• 在新的master的执行“stop slave”;
• 观察一段时间没有写入之后，将需要拆分出去的table全部rename，防止业务更改写入源的不彻底，早点发现问题；
• 老的master上的table备份之后删除；

水平拆分

水平拆分是将访问频繁的大数据量的表，按照某种规则拆分到多个表中，每个表只包含一部分数据。

拆分的规则常见的方式就是按照求余的方式进行；这个网上有很多的讨论，在这里不在细说。
存在问题：拆分之后的如果读取涉及到多张表的时候，需要多次请求进行merge；也可以使用MySQL的partition，MySQL server层会自动的进行merge。

拆分方法：

可以参照osc的实现原理：创建分表，使用trigger将增量数据迁移到分表中，使用lock in share mode对存量数据进行一点点的迁移（减少对服务器以及Slave的压力）。

过程：

• 创建分表；
• 创建trigger，将增量的变更根据分表规则应用到不同的新的分表上；
• 执行SELECT CHUNK lock in share mode，根据分表规则将历史数据导入到新的分表中；
• 业务更新写入源，将新的写入写入到分表中；