数据库分片原则及技术选型总结

前言

在经历数据库主从复制，读写分离之后，我们将面临一个最大的问题，那就是数据库分片；
分片分为：垂直切分和水平切分。

• 垂直切分
  垂直切分好理解也好做，无非是根据业务需求将一张表里的数据拆分出来变成多张不同的表，质变而不是量变，比如：将订单和用户信息从一张表中独立成两种表。

• 水平切分
  这个就比较麻烦了，要根据你业务的需求将一张表的数据分散到多张同样结构的表中，量变质不变，这就会产生一些列的问题，比如：拆分原则的指定、查询逻辑难度变大、数据存储分步，事务问题都将出现，但为了读写速度和存储压力，还不得不拆分。

这其中还涉及到分表和分区的区别，分表就是上边所说的对数据拆分成不同的表、库，分区跟建平常的表没区别，并且对代码端透明；

分区主要是针对单表查询压力过大，且表数据具有分段性，但是数据量非常大的情况下还是得进行分表操作。

分库分表的前提

数据库分片会产生很多的问题，增大维护和开发成本，所以能不去分片就不去分片。
一般来说单表数据超过1000W再去考虑数据库分片，或者数据库被前人或者自己设计的一塌糊涂，完全不满足现有的业务。

分片中间件选择

之说常用免费的两个：sharding-jdbc（shardingsphere）、mycat.

• sharding-jdbc（shardingsphere）
  SQL语法支持较多，支持分库分表、读写分离、分布式id生成、柔性事务（最大努力送达型事务、TCC事务）。被大量公司使用,现在已经升级为Apache组织的项目。
  优点：不用部署，运维成本低，无需代理层的二次转发请求，性能很高
  但遇到升级啥的需要各个系统都重新升级版本再发布，各个系统都需要耦合sharding-jdbc的依赖。
• mycat
  需要部署，自己及运维一套中间件，运维成本高，但是好处在于对于各个项目是透明的，如果遇到升级之类的都是自己中间件那里搞就行了。

选型：
小型公司选用sharding-jdbc，client层方案轻便，而且维护成本低，不需要额外增派人手，而且中小型公司系统复杂度会低一些，项目也没那么多
中大型公司最好还是选用mycat这类proxy层方案，因为可能大公司系统和项目非常多，团队很大，人员充足，那么最好是专门弄个人来研究和维护mycat，然后大量项目直接透明使用即可。

分片算法

常用的两种：范围和hash

• 范围range
  可以按时间或者数值区间来进行划分，优点就是容易扩展，缺点就是如果是按时间来划分，容易产生热点数据，大量请求全部打在最新的数据上，视情况稳定。

数据迁移

mycat官网

• HASH算法（最常用）
  优点，可以平均分配没给库的数据量和请求压力，缺点，扩容起来比较麻烦，会有一个数据迁移的过程，因为你按照hash来区分，那么之前的数据必须要重新进行hash计算之后分布到各个表里才行。

总结

并非所有表都需要水平拆分，要看增长的类型和速度，水平拆分是大招，拆分后会增加开发的复杂度，不到万不得已不使用。
拆分维度的选择很重要，要尽可能在解决拆分前问题的基础上，便于开发。

参考文章：
大厂原来都这么对MySQL分库分表!
mysql数据库分表分库的策略