分库分表的策略及实施（二）（转）

分库分表的策略及实施（二）：

一、分库策略

 

1、准备阶段

对数据库进行分库分表前，需要开发人员充分了解业务逻辑和数据库中表间语法结构，建议绘制一张数据库ER图，以这类图为基础划分shard，可以确保开发人员始终保持明晰的思路。

 

2、分析阶段

A、垂直切分

垂直切分也就是对业务相关，速度增长速率类似的数据表划分在一个Shard中，而这些Shard可被分在一个或是不同的数据库服务器中，然后由应用程序来控制不同数据库的访问及操作即可。

 

B、水平切分

垂直切分后，需要对shard内表的数据的量和增速做进一步分析，以确定是否需要进行水平切分。

 

－> 若划分到一起的表数据增长缓慢，产品上线后可遇见的足够长的时期内均可以由单一数据库承载，则不需要进行水平切分，增加不必要的维护工作，所有表驻留在同一shard中，表间关联关系会得到最大限度的保留，同时保证了书写SQL的解耦合，不易受join、group by、orderby等聚合函数的限制。

 

－> 若划分到一起的表数据量大，数据增长速率高，那么需要进一步进行水平分割，必须结合业务逻辑和表间关系，将当前shard划分成多个更小的shard，一般情况下，这些更小的shard每一个都只包含一个主表（将以该表ID进行散列的表）和多个与其关联或间接关联的次表。一个shard一张主表多张次表的状况是水平切分的必然结果。这样切分下来，shard数量就会迅速增多。如果每一个shard代表一个独立的数据库，这样在管理和维护数据库会比较麻烦，而且这些小shard往往只有几张表，为此而建立一个新库，利用率并不高，所以，在水平切分完成后可再进行一次筛选过滤shard，也就是将业务相近，并且具有相近数据增长速率的两个或多个shard放到同一个数据库上，在逻辑上它们依然是独立的shard，有各自的主表，并依据各自主表的ID进行散列，不同的只是它们的散列取模（即节点数量）必需是一致的，以使每个数据库结点上的表格数量就相对均衡了。

 

－> 所有表均划分到合适的shard之后，所有跨越shard的表间关联都必须打断，在书写sql时，跨shard的join、group by、order by等聚合函数都被禁止，需要在应用程序层面协调解决这些问题，也就是在应用程序中合并数据集。

 

 

3、具体实施

项目在开发时就准备进行分库分表设计，那么严格按照分析设计方案推进即可；如果只是在过程架构重构中实施，除搭建实现shard逻辑的基础设施外，还需要对原有SQL过滤分析，修改那些因为shard而受到影响的sql语句。

 

二、实例验证

这里我们举个实际电商项目中涉及的用户、产品、订单以及相关联的数据表为例，下面我们以一个很简单的电商系统原型为例进行说明，具体如下：

 

我们从上面模型中看出，其主要由三个模块组成：用户，订单和产品，那么垂直切分的方案也就出来了。接下来看水平切分，如果我们从一个实际的花店项目考虑，可能出现数据激增的单表应该是account和order，因此这两张表需要进行水平切分。对于product模块来说， product和Item的数量都不会很大，因此只做垂直切分就足够了，也就是（product，category，item，iventory，supplier）五张表在一个数据库结点上（没有水平切分，不会存在两个以上的数据库结点）。我们假设产品模块也有大量的数据需要我们做水平切分，那么分析来看，这个模块要拆分出两个shard:一个是（product（主），category），另一个是（item（主），iventory，supplier），同时，这两个shard在数据增速上应该是相近的，且在业务上也很紧密，那么我们可以把这两个shard放在同一个数据库节点上，Item和product数据在散列时取相同的模。

 

NOTE：

X表示需要打断的表间关联；

深色实体表为主表；

 

 

好了，到这里已经介绍完了分库分表的实施策略以及例子说明，具体实现请执行设计，因为比较简单，只是对表的划分和存放，然后在应用程序中控制数据的检索分库和分表。