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

最新推荐文章于 2024-07-19 09:32:36 发布

置顶云水之路

最新推荐文章于 2024-07-19 09:32:36 发布

阅读量1.7k

点赞数 1

分类专栏：数据库设计文章标签：分库分表

本文链接：https://blog.csdn.net/why_2012_gogo/article/details/51507646

版权

数据库设计专栏收录该内容

15 篇文章 0 订阅

订阅专栏

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

为什么要对数据库拆分？是因为随着数据量的增多，单个数据库存储全部的数据时，在对该库检索时的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越来越多时

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

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

优点：性能上有优势 

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