也谈数据库拆分database sharding

 

在我们的应用里，有一张业务数据表，目前数据量大概在2－3亿，放在oracle的一张表里，并且一般是每年会翻倍，以前一直在同一张表里，前不久我们将他拆分为16个小的数据库(实际上目前只是在同一服务器的不同schema)里，见链接 。因为数据是和会员相关的，因此拆分规则很简单，根据会员计算hash值，然后确定数据拆分到哪一个数据库，这个业务从本上上是没问题的。

 

在我们的计划里，接下来是要将这张表的数据拆分到64个mysql数据库中去，按照预估，再怎么也能撑几年了，做到这份上，也差不多了，谁让这个世界变化太快呢？

 

因为采用的是开源的amoeba 方案，对于应用来说，很简单，直接将jdbc驱动换成mysql，链接地址修改一下就ok了，到目前为止非常完美。这是amoeba这个方案带来的好处，就是对应用透明。

 

但是，在考虑接下来的工作的时候，碰到一些麻烦。主要问题有几点：

＊路由的规则是在amoeba服务器上，和业务完全隔离

    一开始看来问题不大的，但是和其他团队的交流来看，有时候是需要业务逻辑来参与这个路由的过程的，在amoeba上实现感觉不是很干净

＊由于整个表的数据量特别大，往mysql转换的时候时间太长

    目前主表大概100多G，往mysql里转的时候由于没有合适的工具，估计只能由应用来做，这个过程比较漫长，这是一个线上的应用，停机去做代价太大了，不停机的话，也比较麻烦，估计只能先把大部分线下转换掉，然后切换的时候短暂停机，做增量的同步，不过这个增量也不小的，还需要仔细评估

    因此，我们需要考虑oracle和mysql并存的可行性，这样就可以小部分小部分的转，不管怎样都可以减小风险，但是就目前看来，因为应用里使用到的sql有挺多oracle相关的语法，例如sequence啊，三层嵌套的分页查询之类的，这样看来，对应用透明的oracle/mysql并存方案不大可行

* 我们的应用规模这么大，迟早要服务化，现在的情况是 application -> amoeba -> db，如果再加上一个服务层，就变成了 application -> service -> amoeba -> db，又多了一层，虽然和服务化带来的好处来说，多一层的性能消耗是可以接受的，但是总是不爽

 

废话了这么多，不得不提一下当时我对拆分这张表的打算：

＊ 收拢所有访问这张表的DAO API，集中统一管理（这个做了，而且现在也享受到了)

＊ 将这张表的DAO先做成服务，远程对应用服务，就是 application->service->db

＊ 在service这一层处理数据拆分的逻辑，为此我还开发了一个原型ibatis-sharding ，基于ibatis提供数据库的sharding方案，理念类似hibernate-shards

 

在服务这一层来提供数据库拆分方案，和amoeba的方案来说，对比如下：

 

ibatis-sharding与amoeba解决数据库拆分的对比

feature	ibatis-sharding	amoeba
能实现数据库拆分	Y	Y
拆分逻辑对应用透明	半透明(Service)	Y
拆分逻辑的灵活性	好	一般
能方便实现不同数据库并存	通过ibatis改进来实现	目前无法实现

 

 

 

 

 

 

 

 

 

 

 

（晕，这个表格怎么没法修改啊，想加一行都不行）

 

另外，从性能上对比，在服务化的情景下，amoeba是 ： application -> service -> amoeba -> dbs，而使用ibatis-sharding，由于ibatis-sharding只是一个类库，是和service部署在一起的，因此是： application->service->dbs，这样反而是使用ibatis-sharding的方案更省一些，而且还能享受到路由规则贴近应用的好处，方便啊，灵活啊，呵呵

 

总的说来，大部分情况下使用amoeba是第一选择，因为透明，简单，而且性能好，不过在有些场景下，比如路由规则太复杂，需要不同数据库并存，或者是有service层的架构，使用应用层的实现方案可能会更好

评论

7 楼 argan 2009-07-03  

cx6445 写道

看来是我表达能力有限了，我是说一看就知道是tb收藏夹项目,不是说这个项目技术不行。相反是很成功。

刚好，我说的就不是tb的收藏夹项目，他们的实现其实是很别扭的，我大概知道其方案

我这里提到的其实是别的一个项目，现在已经在实施过程中了，目前的状态是在原来的数据库里拆分成了很多小的schema，假装是很多数据库，下一步要做的就是拿出来，放到更多的mysql里去

不过这个过程是很复杂的，涉及到很多数据的导出和导入（异构数据库，还有CLOB字段），而且，由于是线上OLTP应用的表，还不能停机（或者很短时间的停机），操作起来挑战还是有的。

6 楼 cx6445 2009-06-27  

看来是我表达能力有限了，我是说一看就知道是tb收藏夹项目,不是说这个项目技术不行。相反是很成功。

5 楼 sdh5724 2009-05-24  

sequence

cx6445 写道

一看杭州，一看拆库，一看分成64个表，就知道是收藏夹

很嚣张么, 你以为就北京, 上海技术?  拆库会说的人很多, 但是真正做到透明的有几个?

4 楼 argan 2009-05-22  

cx6445 写道

一看杭州，一看拆库，一看分成64个表，就知道是收藏夹

没仔细看过就不要随意下结论吧，虽然是同一件事情，但是完全就是不同的思路

3 楼 cx6445 2009-05-20  

一看杭州，一看拆库，一看分成64个表，就知道是收藏夹

2 楼 argan 2009-05-04  

数据仓库和在线的系统是不一样类型的系统
解析redolog还不是非常完善，还相对比较初级而已，等成熟之后是没问题的

1 楼 jjjava 2009-04-22  

你开发ibatis-sharding 调研过hivedb 吗?
转mysql 没有合适工具，你们数据仓库团队都不用ETL工具的?
你们能够解析redo log 怎么可能转100g 这么小的数据量还要短暂停机，请告诉我你们在忽悠我们? 不然我会以为你们用的是ak47, 但是杀人都是用枪把把人打死的.