分库分表

常见的分库分表

       如果是因为表多而导致数据多，可以采用垂直方式，根据业务切分成不同的库；

       方式一： 把一个实例中的多个数据库拆分到不同的实例，电商系统， DB集群中有 订单、用户、促销 三个数据库

       

       订单节点的写入压力比较大，你这样拆也解决不了问题

      如果是因为单表数据量太大，就可以采用水平方式，即把表的数据按某种规则切分成多张表，甚至多个库上的多张表。

       方式二： 把一个库中的表分离到不同的数据库中 

       

         写的压力 都在 一个节点上，这样才到不同的数据库上，原来一个节点的写压力，就被分散到了3个节点上。订单的DB 写压力 又扛不住了呢？

         分表 ： 就是对一个库中的相关表 进行水平拆分到不同实例的数据库中。

         

 如何选择分区键 ，尽量避免跨分片查询

　　  博客系统 ：如果按照博客id hash进行分片，那么这个blog_id 会分配到各个节点上，那么查询某个用户的博客， 不得不去所有的数据库上去查询。 但如果按照user_id分呢？ 那只要查询一个数据库就可以了。就避免了跨分区的查询

　　 分区键要尽可能的使各个分配片中数据平均分片的目的，是为了降低数据库的写负载，如果分片不均匀，大部分数据都写到一个节点上了，这个节点压力大。

如何存储无需分片的表

　　一个库中，大部分的表是没有必要分片的，只有几个写入非常频繁的表，才需要分片。那不用分片的如何存储呢？每个分片中存储一份相同的数据

      方法通常用于： 表本身数据量不大，而且不怎么变更的表，比如字典表。 查询也经常关联这种表，每个分片都有的话，这样的话 就不用跨分片查询了，提高查询效率。

      缺点要维护多个分片的一致性，避免不一致导致查询出错。

使用额外的节点统一存储

      需要查询的话，由应用来分别查询，然后组合了。 效率不如第一种，但好在不用去维护数据一致性。

如何分配分片中的数据

　　数据如何分布，对查询的性能，影响很大。平均包括 : 数据分部平均，第二 并发访问也要平均

　　方式一： 按照分区键的hash值取模来分配分片数据，先hash再取模， 并不是所有的分区键都是数字，所以最好hash一下

　　方式二： 按照分区键的范围来分配数据，举个例子 10个分片 ，第一个分片存 1 - 100 ，第二个 101 -199 依次类推。常用于 分区键为 日期类型或者数值类型的场景。

　　优点： 很容易知道放哪里
　　缺点： 容易造成数据的分配不平均 ，从而导致访问也不平均。

　　比如一个 在线题库，以 课程id作为分区键来分区， 但是Java这个课，大家都爱选这个，导致运行一段时间后，java课程的那个分片，压力特别大，所以前期设计要充分考量。

　　方式三：利用分区键和分片的映射表来分配分片数据，需要建立一张 分区键和分片的映射表， 先通过查询映射表 来查询具体的分区。这个表的压力比较大， 记得做缓存。

 分库分表的顺序应该是先垂直分，后水平分。 

1.垂直分表： 大表拆小表，基于字段进行，将不常用、数据量大的字段拆分到“扩展表“，也可避免数据量查询时造成的“跨页”问题。
2.垂直分库： 按业务进行划分库，比如用户服务相关数据划分在用户库，商品服务相关数据划分到商品库等
3.水平分表： 对数据量巨大的表，可按照某种规则(如range,time,hash)切分到多张表里面去。但是这些表还是在同一个库中，所以库级别的数据库操作还是有IO瓶颈。不建议采用。
4.水平分库分表： 将单张表的数据切分到多个服务器上去，每个服务器具有相应的库与表，只是表中数据集合不同。 水平分库分表可解决单机单库性能瓶颈和压力，突破IO、连接数等问题。
水平分库分表规则：
4.1 range: 比如id在0-10000一个表，10000-2000一个表等
4.2 hash: 根据hash取模id，分配到不同的数据库上
4.3 地理区域: 根据数据产生的地理位置划分，比如华南地区、华北地区等
4.3 根据时间：比如一个月分一张表