分库分表解决方案和数据库分片中常见的问题及其解决方案

1、分库分表形式

水平分库
建立结构一样的库，根据分库方案划分数据到不同库

水平分表
建立多个表，根据分表方案划分数据到不同表

垂直分库
根据业务模块，把一组表划分为一个库

垂直分表
根据字段的活跃性，把字段组拆分到不同的表中

2、分库分表解决方案

分库分表工具（轻量级）
1、sharding-sphere ：jar 包，前身是 sharding-jdbc （当当）
2、TSharding ： 蘑菇街的中间件

分库分表工具（重量级）
1、Mycat ： 中间件产品，基于开源的 cobar 开发
2、TDDL Smart Client ： jar 包，Taobao Distribute Data Layer
3、Atlas ： 奇虎 360
4、alibaba.cobar ： 阿里 B2B 部门开发
5、Oceanus ： 58 同城的数据库中间件
6、OneProxy ： 支付宝首席架构师楼方鑫开发
7、vitess ： 谷歌开发的数据库中间件

分表规则
1、Hash
2、Range

3、分库分表中存在的问题

1、事务问题
    方案一：使用分布式事务
        优点：交由数据库管理，简单有效
        缺点：性能代价高，特别是shard越来越多时
    方案二：由应用程序和数据库共同控制
        原理：将一个跨多个数据库的分布式事务分拆成多个仅处 于单个数据库上面的小事务，并通过应用程序来总控 各个小事务。
        优点：性能上有优势
        缺点：需要应用程序在事务控制上做灵活设计。如果使用 了spring的事务管理，改动起来会面临一定的困难。

2、跨节点的 Join 问题
    只要是进行切分，跨节点 Join 的问题是不可避免的。但是良好的设计和切分却可以减少此类情况的发生。解决这一问题的普遍做法是分两次查询实现。
    在第一次查询的结果集中找出关联数据的id,根据这些id发起第二次请求得到关联数据。

3、跨节点聚合问题
    比如 count、order by、group by 等聚合函数问题，方案是各节点完成计算后，交由业务层进行合并
    多节点的查询可以是并行的，因此大多数情况他比单一大表快很多，但是如果结果集很大，可能会导致内存消耗过高

4、数据迁移，容量规划，扩容等问题
    这些问题目前都没有特别好的解决方案，每个方案都或多或少的有一些问题存在，因此这个问题的解决难度其实挺高的

5、ID 问题
    数据被切分后，就不能依赖数据库的自增 ID 进行赋值，另外 ID 还需要承担携带路由信息的功能，以降低查询难度
    一种方案是使用 UUID ，但是 UUID 比较长会占用较多的存储空间，另外一方面，UUID 对索引不友好
    一种方案是通过维护一个 ID 签发表来对 ID 进行签发，但是这会导致插入需要增加一次查询，且该表容易成为性能瓶颈存在单点故障问题
    一种方案是使用雪花算法进行 ID 的下发

6、跨分片的排序问题
    如果排序字段是分片字段，则可以直接使用分片排序
    如果排序字段不是分片字段，则需要先在分片上进行排序，然后到业务系统进行合并，然后再排序

7、分库策略、分库数量
    这个需要根据实际的业务场景，进行合理的分配，否则容易给后期造成很大的问题




  

 

  
1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
  
9
  
10
  
11
  
12
  
13
  
14
  
15
  
16
  
17
  
18
  
19
  
20
  
21
  
22
  
23
  
24
  
25
  
26
  
27
  
28
  
29
  
30
  
31
  
32
  
33
  
34
  
35
 

4、总结

1、分库分表，首先要知道数据库的瓶颈在哪里，才能给出合理的方案
2、对于 Key 的选择很重要，要考虑数据拆分均匀，也要考虑非 partition key 的查询
3、满足要求的情况下，划分规则越简单越好

文章来源: wretchant.blog.csdn.net，作者：简简单单OnlineZuozuo，版权归原作者所有，如需转载，请联系作者。

原文链接：wretchant.blog.csdn.net/article/details/123783206