精华 利用一致性哈希水平拆分MySql单表 (求指教)
发布于 9 年前 作者 DoubleSpout 16381 次浏览 最后一次编辑是 8 年前 来自 分享

写在前面, 打算在公司试行这种方案,求大牛指点一二,看看有无错误和遗漏。

Sharding(切片) 不是一门新技术,而是一个相对简朴的软件理念,就是当我们的数据库单机无法承受高强度的i/o时,我们就考虑利用 sharding 来把这种读写压力分散到各个主机上去。

所以Sharding 不是一个某个特定数据库软件附属的功能,而是在具体技术细节之上的抽象处理,是Horizontal Partitioning 水平扩展(或横向扩展)的解决方案,其主要目的是为突破单节点数据库服务器的 I/O 能力限制,注意这里是突破单点数据库服务器的“I/O”能力。

在MySql 5.1 中增加了对单表的 PARTITION(分区)支持,可以把一张很大的单表通过 partition 分区成很多物理文件,避免每次操作一个大文件,可以对读写新能有所提升,下面是一个 partition 分区的例子。

一张游戏的日志表,有几千万行的数据,记录了接近一年的游戏物品获取日志,如果不对它进行 partition 分区存储,每次统计和分析日志都会消耗大量的时间。然后我们新建一张分区表,把老的日志数据导入到新的数据,统计分析的时间就会节约很多。

	CREATE TABLE `xxxxxxxx` (     
	`crttm` int(11) NOT NULL,     
	`srvid` int(11) NOT NULL,     
	`evtid` int(11) NOT NULL,     
	`aid` int(11) NOT NULL,     
	`rid` int(11) NOT NULL,     
	`itmid` int(11) NOT NULL,     
	`itmnum` int(11) NOT NULL,     
	`gdtype` int(11) NOT NULL,     
	`gdnum` int(11) NOT NULL,     
	`islmt` int(11) NOT NULL,  
	KEY `crttm` (`crttm`),  
	  KEY `itemid` (`itmid`),  
	  KEY `srvid` (`srvid`),  
	  KEY `gdtype` (`gdtype`)  
	) ENGINE=myisam DEFAULT CHARSET=utf8  
	PARTITION BY RANGE (crttm)   
	(  
	PARTITION p201303 VALUES LESS THAN (unix_timestamp('2014-04-01')),  
	PARTITION p201304 VALUES LESS THAN (unix_timestamp('2014-05-01')),  
	PARTITION p201305 VALUES LESS THAN (unix_timestamp('2014-06-01')),  
	PARTITION p201306 VALUES LESS THAN (unix_timestamp('2014-07-01')),  
	PARTITION p201307 VALUES LESS THAN (unix_timestamp('2014-08-01')),  
	PARTITION p201308 VALUES LESS THAN (unix_timestamp('2014-09-01')),  
	PARTITION p201309 VALUES LESS THAN (unix_timestamp('2014-10-01')),  
	PARTITION p201310 VALUES LESS THAN (unix_timestamp('2014-11-01')),  
	PARTITION p201311 VALUES LESS THAN (unix_timestamp('2014-12-01')),  
	PARTITION p201312 VALUES LESS THAN (unix_timestamp('2015-01-01')),  
	PARTITION p201401 VALUES LESS THAN (unix_timestamp('2015-02-01'))  
	); 

对于这种业务场景,使用 mysql 的 partition 就已经足够了,但是对于 i/o 非常频繁的大表,单机垂直升级也已经支撑不了,存储已经不是影响其性能的主要原因,这时候就要用到sharding了。

我们一般会将一张大表的唯一键作为 hash 的 key,比如我们想要水平拆分的是一张拥有3千万行数据的用户表,我们可以利用唯一的字段用户id作为拆分的依据,这样就可以依据如下的方式,将用户表水平拆分成3张,下面是伪代码,将老的用户数据导入到新的3个被水平拆分的数据库中。

if userId % 3 == 0:
	#insert data in user_table (user_table_0 databaseip: 127.0.0.1)
elif userId % 3 == 1:
	#insert data in user_table (user_table_1 databaseip: 127.0.0.2)
else:
	#insert data in user_table (user_table_2 databaseip: 127.0.0.3)

我们还会对每一个被拆分的数据库,做一个双主 master 的副本集备份,至于backup,我们则可以使用 percona的cluster来解决。它是比 mysql m/s 或者 m/m 更靠谱的方案。 http://www.percona.com/software/percona-xtradb-cluster

所以最后拆分的拓扑图大致如下: connhash.jpg

随着我们的业务增长,数据涨到5千万了,慢慢的发现3个sharding不能满足我们的需求了,因为服务器紧张,所以这时候BOSS打算再加2个sharding,以后会慢慢加到10个sharding。

所以我们得在之前的3台sharding服务器上分别执行导入数据代码,将数据根据新的hash规则导入到每台sharding服务器上。几乎5千万行数据每行都移动了一遍,如果服务器够牛逼,Mysql每秒的插入性能能高达 2000/s,即使这样整个操作,都要让服务暂停8个小时左右。这时候DBA的脸色已经不好看了,他应该是已经通宵在导数据了。

那有没有一种更好的办法,让添加或者删除 sharding 节点对整个分片系统的数据迁移量降低呢?

我们可以利用一致性哈希算法,把用户id散列到各个 sharding 节点,这样就可以保证添加和删除节点数据迁移影响较小。关于什么是一致性哈性算法,参考我的另一篇博客: http://snoopyxdy.blog.163.com/blog/static/601174402012722102446720/

这里介绍一个Node.js模块,hashring,github主页地址如下,上面有demo和api文档: https://github.com/3rd-Eden/node-hashring 这是一个使用的demo代码,我翻译了注释,供大家参考:

// 加载模块,返回HashRing的构造函数
var HashRing = require('hashring');

//实例化HashRing,这个例子中,我们把各个服务器均匀的添加了,没有设置权重
// 设置了最大的缓冲区 10000
var ring = new HashRing([
	'127.0.0.1',
	'127.0.0.2',
	'127.0.0.3', 
	'127.0.0.4'
  ], 'md5', {
	'max cache size': 10000
  });

//我们获取这个字符串的服务器ip
var server = ring.get('foo bar banana'); // returns 127.0.0.x
console.log(server)

// 如果你想把数据冗余的存储在多个服务器上
ring.range('foo bar banana', 2).forEach(function forEach(server) {
  console.log(server); // do stuff with your server
});

// 对环上移除或新增加一台服务器
ring.add('127.0.0.7').remove('127.0.0.1');

var server = ring.get('foo bar banana'); // returns 127.0.0.x
console.log(server)

接下来我们就要验证这种方式的可行性。 第一,假如我们有3万条数据,根据一致性哈希算法存储好了之后,这个算法是否能够较平均的将3万条数据分散到3台sharding服务器上。 第二,当数据量增加到5万,然后我们增加2台sharding服务器后,这个算法移动的数据量和最终每台服务器上的数据分布是如何的。

connHashStep1.js将3万用户数据通过一致性哈希算法存储在3台服务器上

var HashRing = require('hashring');
var ring = new HashRing([
	'127.0.0.1',
	'127.0.0.2',
	'127.0.0.3', 
  ], 'md5', {
	'max cache size': 10000
  });

var record = {
	  '127.0.0.1':0,
	'127.0.0.2':0,
	'127.0.0.3':0
};
var userMap = {}

for(var i=1; i<=30000; i++){
	var userIdStr = i.toString();
	var server = ring.get(userIdStr);
	userMap[userIdStr] = server;
	record[server]++;
}

console.log(record);

第一次利用一致性hash之后,每台服务器存储的用户数据。

{ '127.0.0.1': 9162, '127.0.0.2': 9824, '127.0.0.3': 11014 }

connHashStep2.js将5万用户数据通过一致性哈希算法存储在3台服务器上,然后用户数据5万不改变,新增加2台sharding,查看新的5台sharding的用户数据存储情况以及计算移动的数据条数。

var HashRing = require('hashring');
var ring = new HashRing([
	'127.0.0.1',
	'127.0.0.2',
	'127.0.0.3', 
  ], 'md5', {
	'max cache size': 10000
  });

var record = {
	  '127.0.0.1':0,
	'127.0.0.2':0,
	'127.0.0.3':0
};
var userMap = {}
  
for(var i=1; i<=50000; i++){
	var userIdStr = i.toString();
	var server = ring.get(userIdStr);
	userMap[userIdStr] = server;
	record[server]++;
}

console.log(record);

//新增加2个sharding节点
var record2 = {
	'127.0.0.1':0,
	  '127.0.0.2':0,
	  '127.0.0.3':0,
	'127.0.0.4':0,
	'127.0.0.5':0,
};
ring.add('127.0.0.4').add('127.0.0.5')

var moveStep = 0;
for(var i=1; i<=50000; i++){
	var userIdStr = i.toString();
	var server = ring.get(userIdStr);
	//当用户的存储server改变,则计算移动
	if(userMap[userIdStr] && userMap[userIdStr] != server){
		userMap[userIdStr] = server;
		moveStep++;
	}
	record2[server]++;
}
console.log(record2);
console.log('move step:'+moveStep);

5万用户数据,存储在3台服务器上的数目:

{ '127.0.0.1': 15238, '127.0.0.2': 16448, '127.0.0.3': 18314 }

当我们sharding增加到5台,存储在5台服务器上的数目:

{ '127.0.0.1': 8869,
  '127.0.0.2': 9972,
  '127.0.0.3': 10326,
  '127.0.0.4': 10064,
  '127.0.0.5': 10769 }

最终我们移动的用户数量:

move step:20833

其实你会发现

20833 = 10064 + 10769 

也就是说,我们只是将1-3节点的部分数据移动到了4,5节点,并没有多余的移动一行数据。根据上面的示例,如果是5千万数据,利用一致性哈希的算法,添加2个节点,仅需2-3小时就可以完成。

那么什么时候我们需要利用一致性哈希水平拆分数据库单表呢? 1、当我们拥有一个数据量非常大的单表,比如上亿条数据。 2、不仅数据量巨大,这个单表的访问读写也非常频繁,单机已经无法抗住 I/O 操作。 3、此表无事务性操作,如果涉及分布式事务是相当复杂的事情,在拆分此类表需要异常小心。 4、查询条件单一,对此表的查询更新条件常用的仅有1-2个字段,比如用户表中的用户id或用户名。 最后,这样的拆分也是会带来负面性的,当水平拆分了一个大表,不得不去修改应用程序或者开发db代理层中间件,这样会加大开发周期、难度和系统复杂性。

求大牛指点不足,指出错误~

参考链接:http://lobert.iteye.com/blog/1955841

14 回复

帮忙顶一下吧

@CocaCola183 感谢帮顶哦~

不明觉厉!

我测了测

var ring = new HashRing([
    // 重复 5 次
    '127.0.0.1', '127.0.0.2', '127.0.0.3',
    '127.0.0.1', '127.0.0.2', '127.0.0.3',
    '127.0.0.1', '127.0.0.2', '127.0.0.3',
    '127.0.0.1', '127.0.0.2', '127.0.0.3',
    '127.0.0.1', '127.0.0.2', '127.0.0.3',
  ], 'md5', {
    'max cache size': 10000
  });

这种情况。我也忘记我在测的叫什么,但最终 move step 的步数跟文章中是一样的。

@alsotang 你为什么要重复5次?这里存储的就是模拟数据库ip地址,是为了让用户记录找到存储的 ip 地址,重复的话有什么特别的意思吗?

1:对于数据库一般 sharding 都是根据容量进行预估,也就是说 sharding 到几台数据 node 节点要事先定好,如果以后要进行扩容就进行垂直的伸缩,通过mysql复制迁移。而水平伸缩,即使你使用一致性哈希也是会有一定的迁移代价存在
2:5千万数据量对于mysql还好,如果索引设计使用合理的话,还是高效的,优化下sql说不定比sharding效果好 3:mysql sharding 之后就需要中间件了,主要难点在于多表查询(涉及查询计划的生成与优化)与事务上,不过如果是针对特定业务的话,可以简化

赞,看懂了。 英文的解释更精炼些,但是没图。两个结合起来看更好。 http://en.wikipedia.org/wiki/Consistent_hashing

@fantasyni 感谢大牛回复 对于1表示赞同,但是有时候预估不准,或者从无到有,迈出第一步的时候就要面对了 对于2,你说的对,不到万不得已无需sharding,5千万只是举例,目前还要根据真实的性能测试数据来说话,对于我们的服务器配置,性能的平衡点在哪里? 对于3,我想问下,中间件是DIY自己搞好?还是用成熟的方案? 如果DIY自己搞的话是让应用程序直接抛SQL语句过来解析返回?还是走restful,只支持特定几个业务查询接口呢?

@leapon 额,大牛提点建议哦~

@DoubleSpout 疑问与回答 1:你们mysql 存储engine用的是myisam? 这个在大量并发插入性能是差的(在你们场景就是迁移的时候),它是表锁 2:中间件node.js目前没有特别牛逼的,如果不要求中间件通用的话,根据业务来做分库分表在业务层上处理下也可以的,就是比如查询,你可以知道具体查询计划,在业务层处理

@DoubleSpout 写得已经很好了。:)

@fantasyni 谢谢你的回答 1、引擎室 innodb,迁移其实可以不停业务的,从备库上做好了,昨晚再切生产,没问题的 2、通用的话感觉难度有点大,而且给其他部门用效率不能保证,还是跟业务走,限定查询条件,订制查询计划,这样我们还能针对性的做缓存等,效率应该比较高一些。这块功能不一定用Node.js做,看测试性能了 再次感谢大牛的指点~

写的足够好了,其实一致性哈希主要就是解决宕机和扩容的问题,点个赞。

@DoubleSpout 不是很明白为什么要引入一致性哈希 前面也有同学提到一致性哈希主要就是解决宕机和扩容的问题

你这里引入一致性哈希主要是为了重新计算哈希,将多出来的数据进行迁移, 那使用最简单的取模不是一样能达到这个效果么, 本质还是将一部分的数据进行迁移。

不知道我的看法对不对,还请指教

回到顶部