分库分表知识必备

亿级数据量性能优化必备之分库分表
https://zhuanlan.zhihu.com/p/93724977
1.什么时候分库分表
   当单表的数据量达到1000W或100G以后，由于查询维度较多，即使添加从库、优化索引，做很多操作时性能仍下降严重。此时就要考虑对其进行切分
2.分库分表，到底怎么分。 数据切分（Sharding）
   数据切分就是将数据分散存储到多个数据库中，使得单一数据库中的数据量变小，同时扩充主机数量来缓解单一数据库的性能问题
   数据切分根据其切分类型，可以分为两种方式：垂直（纵向）切分和水平（横向）切分  
   垂直切分常见有垂直分库和垂直分表两种。
      垂直切分— 垂直分库。根据业务耦合性，将关联度低的不同表存储在不同的数据库。(隐患：分布式事务处理复杂，依然存在单表数据量过大的问题)
         |__垂直分表。某个表字段较多，把字段拆开散到多个表中.（隐患：部分表无法join，只能通过接口聚合方式解决，提升了开发的复杂度）

      水平切分.将同一个表按不同的条件分散到多个数据库或多个表中，每个表中只包含一部分数据
              (隐患:跨分片的事务一致性难以保证,跨库的join关联查询性能较差)
      —库内分表。只解决了单一表数据量过大的问题。还是竞争同一个物理机的CPU、内存、网络IO
      |_分库分表。
     常用的切分规则：
          —根据数值范围。按照时间区间或ID区间来切分。按日期将不同月甚至是日的数据分散到不同的库中
             某些系统中使用的"冷热数据分离"，将一些使用较少的历史数据迁移到其他库中，业务功能上只提供热点数据的查询，也是类似的实践。
      |_根据数值取模。一般采用hash取模mod的切分方式
             例如：将 Customer 表根据 cusno 字段切分到4个库中，余数为0的放到第一个库，余数为1的放到第二个库，以此类推。
              这样同一个用户的数据会分散到同一个库中，如果查询条件带有cusno字段，则可明确定位到相应库去查询。
             优点：分布均匀，不容易出现热点和并发访问的瓶颈
             缺点：扩容时，需要迁移旧的数据。 还有跨分片查询时如果没有sharding key(上面例子的cusno字段)会更复杂。需要查多个库再合并。

3.分库分表导致复杂性增加，带来的问题与解决方案
   a.事务一致性问题.跨库和跨分片事务都是分布式事务，
      解决方法1:一般可使用"XA协议"和"两阶段提交"处理。
      复杂性增加的原因：分布式事务能最大限度保证了数据库操作的原子性。但在提交事务时需要协调多个节点，推后了提交事务的时间点，
        延长了事务的执行时间。导致事务在访问共享资源时发生冲突或死锁的概率增高。
        随着数据库节点的增多，这种趋势会越来越严重，从而成为系统在数据库层面上水平扩展的枷锁。
     解决方法2:最终一致性。适用场景：对于那些性能要求很高，但对一致性要求不高的系统，往往不苛求系统的实时一致性，
             只要在允许的时间段内达到最终一致性即可，可采用事务补偿的方式。
         常见的实现方法有：对数据进行对账检查，基于日志进行对比，定期同标准数据来源进行同步等等。事务补偿还要结合业务系统来考虑。
   b.跨节点关联查询join问题
     解决方法1:全局表，即数据字典表，是系统中所有模块都可能依赖的一些表。在每个数据库中都保存一份。内容很少变动，不用担心一致性
     解决方法2:字段冗余。一种典型的反范式设计，利用空间换时间，为了性能而避免join查询。
              买家修改了userName后，是否需要在历史订单中同步更新呢？这也要结合实际业务场景进行考虑。
     解决方法3:数据组装。系统分两次查询，第一次查询的结果集中找出关联数据id，然后根据id发起第二次请求得到关联数据。最后将获得到的数据进行字段拼装。
     解决方法4:ER分片，先确定表之间的关联关系，将有关联关系的表数据放在1个库里面。来避免跨分片join问题
   c.跨节点分页、排序、函数问题
      跨节点多库进行查询时，会出现limit分页、order by排序等问题。
      分页需要按照指定字段进行排序，当排序字段就是分片字段时，通过分片规则就比较容易定位到指定的分片；当排序字段非分片字段时，就变得比较复杂了。
      需要先在不同的分片节点中将数据进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序，最终返回给用户。
   d、全局主键避重问题
      问题的背景原因：由于表中数据同时存在不同数据库中，主键值平时使用的自增长将无用武之地，
           某个分区数据库自生成的ID无法保证全局唯一。因此需要单独设计全局主键，以避免跨库主键重复问题。
       有一些常见的主键生成策略：UUID  + 结合数据库维护主键ID表
   e.数据迁移、扩容问题.历史数据要按指定的分片规则再将数据写入到各个分片节点中。
      此外还需要根据当前的数据量和QPS，以及业务发展的速度，进行容量规划，推算出大概需要多少分片（一般建议单个分片上的单表数据量不超过1000W）

4. 支持分库分表的中间件
sharding-jdbc（当当）
TSharding（蘑菇街）
Atlas（奇虎360）
Cobar（阿里巴巴）
MyCAT（基于Cobar）
Oceanus（58同城）
Vitess（谷歌）
在数据量很大的情况下，还可以使用ES搜索引擎或Hive来满足后台复杂的查询方式。