数据库sharding Lookup技术探讨

运维 数据库运维 其他数据库
数据库sharding技术最近几年越来越火热。Sharding是shared-nothing的缩写,也可称其为horizontal partitioning/horizontal split,即数据库切片。将一个大的数据库切成几个功能一样,逻辑关系和物理上毫不相干的数据库。

数据库sharding有几个主要的优点:

1. Database sharding提供了近似线性扩展的架构。可以随着应用的增长线性的增加更多的服务器。

2. 提高了数据库的可用性。如果只有一个数据库,一旦down掉的话,对其所提供的service影响是100%,如果拆成10台数据库,那么一台数据库down掉的影响只有10%。

3. 小的数据库压力比较小,风险更小,性能更好。做过DBA的都知道,管理一台3000 TPS的数据库和一台300 TPS的数据库的压力是完全不一样的。

其缺点在于:

1. 首先要业务逻辑支持,并不是任何类型的数据库都支持拆分。如果业务逻辑不支持拆成几个不相干的数据的话,拆开后各个数据库之间数据join会带来额外的开销,而且随着数据库的增多,开销越来越大。

2. 更多的数据库也带来一些维护上的开销,例如升级数据库,打patch等。

3. 因为数据分散了,所以要提供机制能够找到所需数据所在的数据库。这也是本篇文章讨论的重点,即数据的lookup技术。

下面重点讨论lookup技术。数据被分散在不同的数据库中,当应用需要查询数据时,要能够定位到相应的数据库中查询。如果没有Lookup机制,则需要到每一个数据库中查询,这样的话就不可能做到线性扩展,数据库Sharding也就失去了其主要的优势。

Lookup技术主要从以下几个方面来考虑:

1. 成本

2. 效率

3. 再次拆分的难度

4. 是否支持在线拆分

我接触到或者想到的Lookup技术有以下几种,下面分别讨论其优缺点。

1. 建立Lookup数据库

这是很自然想到的一种方法。Lookup数据库中记录 (ID, Server)的对应关系。
其优点在于灵活性很高,数据可以存放在任何一个数据库中,可以在不同的数据库之间在线迁移数据来平衡数据库压力,迁移数据时同时更新Lookup数据库中相应的记录。

缺点也很明显,就是需要一套Lookup数据库来支持,有不小的额外开销。Lookup数据库的数据必须集中存放,不好再做水平切割。虽然其数据结构简单,存放的数据量并不大,但是所有的应用都需要到Lookup数据库上查找数据,其查询的频率很高。而且Lookup数据库在这个方案中也成为了一个故障节点。所以不能用一台数据库做Lookup DB,否则前面提到的sharding数据库可用性的优势又失去了。我们可以用Master/Slave的方式来实现Lookup数据库的scalability和availability。Master数据库提供写操作,Slave数据库提供读的操作。

对于oracle来说,可以采用复制软件来实现master和slave之间的同步,例如shareplex,也可以采用oracle logical standby或者oracle active physical standby(11g)来实现。

MySQL数据库的话,memory engine很适合做Slave服务器,因为Lookup表的数据库不大,可以放在内存中,而且hash index很适合等式查找。Memory engine可以支持大并发量的查询。Mater数据库可以采用Innodb,文档中提到在高版本的MySQL中支持不同storage engine之间的复制。实际应用中不知道有没有公司这么使用。

2. 采用划分区间的方式

将数据按照range来划分。比方说以1万为一个区间长度,ID在1~10000的在数据库D1中,10001~20000的在数据库D2中,20001~30000在数据库D3中,依此类推。当分配的ID用完或者新增服务器时,继续分配后面的ID供其使用。可以通过sequence来实现。
其优点在于不需要额外的开销,应用通过简单的映射就可以得知数据存放于哪个数据库中,缺点在于各个数据库之间很难实现在线的数据迁移。如果应用的增长不是因为数据量增长而增长,而是因为执行次数的增加的话,很难做到在线的压力平衡。另外当区间内分配的ID数用完了,需要DBA手工分配新的区间。

3. 采用hash函数的方式

比方说最简单的hash函数—mod函数。将数据进行mod(ID, 13860) (13860= 2*3*5*6*7*11),如果有十台数据库,每个数据库中存放1386个mod。将mod和数据库之间的mapping关系存放于数据库中,应用服务器可以将其load进自己的内存中(这个表很小)。当新增服务器时,从各个数据库中转移一部分mod到新的服务器上。
其优点在于不需要额外的开销,可以通过查找应用端很小的内存链表就能获知数据存放的位置,缺点在于当新增服务器后转移数据过程中要保持数据的同步,需要同步机制。

4. 采用hash函数和Lookup数据库相结合的方式

基本划分的方法和第三种一样,但是多了一套Lookup数据库来提供miss查询。这套Lookup数据库解决了方法三中新增服务器数据同步的问题。新增服务器转移数据时就不需要同步了,而是采用move的方式,这样在旧的服务器中miss了,但可以通过Lookup数据库来定位到新的服务器,当单个mod完全转移了,可以更新mapping表,这样就可以直接定位到新的服务器上。

不知道大家是如何实现Lookup机制的,有什么好的方法或想法非常欢迎大家来分享。

【编辑推荐】

  1. 如何在DB2中提高IMPORT性能
  2. 使用DB2必须了解的几个知识点
  3. DB2下数据转移任务操作实例
责任编辑:彭凡 来源: dbafan
相关推荐

2017-03-14 13:57:15

数据库权限分配探讨

2022-05-30 11:47:49

数据技术监测

2023-01-12 17:18:06

数据库多云

2010-05-07 13:09:06

2015-07-10 10:25:09

2011-03-15 14:54:08

NoSQL

2011-03-24 14:24:05

2019-01-16 14:20:42

2022-03-02 09:13:00

分布式数据库Sharding

2017-06-12 18:24:25

数据库压缩技术

2011-08-02 13:37:17

2010-08-02 16:19:00

ibmdw面向对象

2011-05-13 13:54:02

数据库文档数据库

2011-07-27 08:56:32

Oracle数据库绑定变量软解析

2010-07-23 13:39:19

SNS网站

2011-05-17 15:02:15

ORACLE数据库备份

2011-05-19 10:29:40

数据库查询

2011-05-18 09:39:19

Oracle数据库性能优化

2011-03-04 10:03:45

EJB数据库应用
点赞
收藏

51CTO技术栈公众号