数据库设计模式之-Sharding

Posted 2021-05-01 gangpao

单台数据库垂直扩容在面对日益增长的数据量解决能力非常有限，这个时候就需要考虑数据库的分库策略。通常我们从两个角度考虑分库，水平切分和垂直切分。

垂直切分

垂直切分如上图所示。原来在单台库上的数据可以被拆分到3台服务器，理想情况下每台服务器承担旧服务器的1/3的压力。这种拆分只适合表之间耦合度非常低的数据库，最好是能把不同的业务需求的表拆分到不同库中，拆分后的库与库之间没有关联查询，外键依赖等。垂直拆分的另外一个不足就是并没有通过拆分来降低表的量级，所以它更适合应对因大量小表而带来的单台库压力。

由于垂直切分逻辑简单，我们一般可以自己组织切分规则，然后自己实现一层查询代理，怎么拆分就怎么查询，实现对上层应用的透明封装。

水平切分

水平切分相对垂直切分要发杂很多，这种策略会将一张表的数据打撒到不同的服务器，每张表都会选择一个distribute-key（分布键可以是一列，也可以是组合列），水平打散时如果分布键选择不当，会导致数据分布倾斜，对于大表来说，数据分布倾斜就不能达到降维效果。

水平切后的多张表之间是支持关联查询的，前提是多张表的分布键选择一致，而且也只限于分布键的关联查询。虽然有些水平切分的架构也支持非分布键的关联查询、分组统计等功能，但是这些操作的代价是底层数据交换，开销非常大、一般也只有一些OLAP系统的数据仓库，才启用非分布键的复杂操作。

现在有大量的MPP库实现水平切分功能，在团队开发资源有限的情况下，可以直接套用开源项目的实现方法。

常用Sharding技巧

1. 实际情况我下，我们会选择水平切分和垂直切分结合使用，一般先垂直切分再水平切分的，形成一个切分矩阵。

2. 对于一些轻量级基础数据表，如果出现频繁全量关联查询或非分布键关联查询，可以讲这些基础表数据备到每个shard节点里。

3. 水平切分后，对于两张表的非分布键的join查询，一般的解决办法是把join查询转化成嵌套查询；或者是分两步查询，将驱动表中的查询结果去非驱动表中反查。

4. 水平分布后，对于非分布键上用到的分组函数，开窗函数，聚集函数等，在不允许数据交换的分布式系统中，需要应用端介入。并发的分别在各个节点上得到结果后在应用程序端进行合并。

5. 水平切分时，一般都会选择一个主表（将以该表ID进行散列的表）和多个与其关联或间接关联的从表