sharding的lookup

数据库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机制的，有什么好的方法或想法非常欢迎大家来分享。