分库分表的策略及实现

转载自：https://blog.csdn.net/why_2012_gogo/article/details/51492573

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

为什么要对数据库拆分？是因为随着数据量的增多，单个数据库存储全部的数据时，在对该库检索时的IO吞吐率较低，数据存储在单一的硬盘介子中，存在单点和单个介子存储数据过大的问题。那么这里主要介绍如何将单一数据库的数据拆分到多个数据库中，以及如何将大数据量的表拆分到多张小表的过程，对于前者的拆分我们称之为数据库的垂直拆分，而后者我们称之为水平分割（Sharding），本篇文章主要介绍切分原理。

·     垂直拆分

·     水平拆分

·     垂直水平

·     注意事项

一、垂直拆分

从上面的数据库拆分结构图，我们知道单一数据库Single DB被垂直拆分为5个单一的数据库，这些数据可以在一个数据库Server上部署，也可以在不同的数据库Server上部署，具体需要根据业务数据量来定，不过一般欲对数据库分库的话，说明数据量比较大，往往结合分布式数据库将不同数据库分别放到不同的数据库Server上，而被拆分的若干个DB数据库，其中都存放着业务关联紧密度高的数据表，比如：某个模块相关的数据表（比如：user,product,order数据表可以划分在一个数据库Shard）。

NOTE：

如果数据库中的数据量大是因为数据表比较多，那么可以考虑将业务关系紧密的表放到一个Shard中，并单独放在一个数据库服务器中，实现数据库均衡效果。

二、水平拆分

 

水平拆分针对的是数据量大的数据表而言，将数据拆分到若干张小的数据表，做到数据均衡分摊，精准定位到指定的分表检索，可以大大提高数据库的检索效率。上图中的表分割采用了取模分表，平均分摊数据到这4张数据表，因为我们可以通过分表的策略集合id值就可以定位到指定的分表中，所以其直接从中检索数据，检索速度十分的快速。

具体可以查看我的前面的博文《数据表分割策略和实现》，博客地址：

http://blog.csdn.net/why_2012_gogo/article/details/51483960

NOTE：

如果单张数据表比较大时，将以考虑将该表的数据均分到多张小数据表中，这些数据分表可放在单一数据库，也可以存放在不同的服务器数据库中去。

三、垂直水平

垂直水平指的是数据库的垂直和水平拆分相结合的一种数据均衡的方案，往往在实际项目中经常使用，此方案与单独的垂直分库略有不同，因为此时的数据表划分建议根据表的关系紧密和表内数据增长的速率来划分，具体如下：

当同时进行垂直和水平切分时，切分策略会发生一些微妙的变化。例如：在只考虑垂直切分的时候，被划分到一起的表之间可以保持任意关联关系，因此你可以按“功能模块”划分表，但是一旦引入水平切分之后，表间关联关系就会受到很大的制约，通常只能允许一个主表（以该表ID进行散列的表）和其多个次表之间保留关联关系，也就是说，当同时进行垂直和水平切分时，在垂直方向上的切分将不再以“功能模块”进行划分，而是需要更加细粒度的垂直切分，这样切分下来你会发现数据库分被切分地过于分散了（shard的数量会比较多，但是shard里的表却不多），为了避免管理过多的数据源，充分利用每一个数据库服务器的资源，可以考虑将业务上相近，并且具有相近数据增长速率的两个或多个shard放到同一个数据源里，每个shard依然是独立的，它们有各自的主表，并使用各自主表ID进行散列，不同的只是它们的散列取模（即节点数量）必需是一致的。

四、注意事项

1、跨节点关联查询

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

2、跨节点事物处理

解决事务问题目前有两种可行的方案：分布式事务和通过应用程序与数据库共同控制实现事务，下面对两套方案进行一个简单的对比。


方案一：分布式事务
   

优点：交由数据库管理，简单有效
   

缺点：性能代价高，特别是shard越来越多时

方案二：应用程序和数据库协同    

将一个跨多个数据库的分布式事务分拆成多个仅处于单个数据库上面的小事务，并通过应用程序来总控各个小事务。
    

优点：性能上有优势
    

缺点：需要应用程序在事务控制上做灵活设计。

3、跨节点聚合函数

与解决跨节点join问题的类似，分别在各个节点上得到结果后在应用程序端进行数据合并。和join不同的是每个结点的查询可以并行执行，因此很多时候它的速度要比单一大表快很多，但如果结果集很大，对应用程序内存的消耗有一定影响。

好了，到这里已经介绍完了分库分表的简单策略，接下来会继续介绍分库分表的策略和实施部分，谢谢。

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

一、分库策略

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表示需要打断的表间关联；

深色实体表为主表；

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