数据库水平切分的实现原理解析

继续写啊，帅帅

一个user的articles会不会插入到不同的Group中去？如果是，怎样查询？

一个user的article不会插入到不同的group中去的，group只是为了保证数据库的可用性做的集群的概念，group中的每一个DB数据都是一样的。。

路由规则抽象出来了，用xml文件进行配置。。其实用户程序员需要做的就是传递一个user_id到ddal的routerule层去就OK了，因为user_id是最终的一个区分字段，是分库的一个依据吧！当然现在还有route对象的存在，需要用户显示的去传递route参数，当然下一步也是可以屏蔽掉这一块的，直接传递user_id当作查询参数传入也是可以的。。。

改进中。。

浮出水面，呼吸氧气看见此片文章。

希望各位大侠能有所指点啊。。。。小弟万分感激啊！

在水平切分的数据上做统计是个麻烦事

1、系统有那些关键数据需要切分
系统有静态数据和动态数据。
静态数据往往数据量小不需要切分，那么就需要独立一个单独的静态配置库，考虑到很多sql一定会用join的方式进行关联静态数据，那么静态数据肯定会往动态数据库中进行复制。同时，一个单独的静态库，对于静态数据的管理非常方便。
动态数据，是只有横向切分，还是采用纵向切分加上横向切分。比如：按照用户和blog进行纵向切分后，在进行用户和blog的横向切分。
切分的粒度需要精确掌握，否则会引起开发和维护的很多困难。
2、全局唯一ID
如果采用hash分库或者地理位置属性分库进行了横向切分后，用户ID或者blog的ID肯定具有含义，能够通过ID定位到对应的切分库中。
无论那种方式，ID一定是有含义的，从字面上或者算法上都能够识别数据归属那个切分库。
3、切分数据一体化（连带性）
如果是一个庞大的数据库，其中必定有很多模型。比如：用户模型，资料模型等等，是否一个用户对应的资料都能够在这个用户对应的数据库中找到。这样做，会尽量减少开发的难度，不可能完全的要求开发避免关联表的使用。
4、分表的管理
采用了横向数据库切分后，必然存在数据库分表。
是否切分库中存在一个分表，还是一个切分库中存在多个分表。
那些分表在那个库中，那些分表归属一个切分库，这些都需要管理。
如果一个切分库就一个类型的一张分表，也太浪费数据库资源了。
5、分库后的连接管理
数据库切分后，数据库增多，必然会导致连接的增多。
一个应用是连接所有的分库？还是划分某个功能的应用连接特定的分库？
如果采用oracle的rac，还要考虑rac的gc buffer busy的问题。
6、开发上sql的配合
如果系统不大，可以采用配置sql+xml文件方式。采用分库的系统，一般都很庞大。
采用sql+xml的配置，一定会出现很多问题，开发的难度和不配合程度一定会直线上升。需要将sql下放给开发人员，针对sql中的表可以采用抽象和逻辑的管理模式。既提高了开发效率，又能管理需要执行到分库中的sql。
7、业务参数
如果业务逻辑很复杂，要求每一个函数或者每一个方法，都显示的传递分库参数。就将分库的逻辑和应用完全的柔和在一起，将导致后期的维护和升级极其的困难。
采用在页面或者接口层面传递一次业务逻辑参数，后期在orm底层使用这些参数。
比如：http://a.com/a.action?RouteType=UserID&RouteValue=1222211&业务参数
8、业务的取舍
以前的应用，可以按照名字进行查询。分库后，无法进行这样的查询，需要按照分库属性进行查询。将会导致业务上或者上操作上的变更。
一般会有些业务的操作会随着分库的进行而变动。
9、分布式事务
切分多个库后，难免有业务操作多个数据库，那么就会带来分布式事务的问题（分布式事务不仅仅出现在多个数据库中）。同时，一个繁忙的数据库，进行跨库操作的时候，要避免跨库的死锁。数据库可不会检测到另外一个库与自己的死锁。

系统的切分是个很复杂的技术活，要综合考虑，而不仅仅从数据库层面考虑。
业务的使用、分库的原则、数据的割接、开发的侵入、可操作的易难程度、后期的管理等等都是需要考虑的因素。
本人刚刚完成一个电信级别的50T的oracle的数据库拆分，采用的是用户归属的地域属性进行的横向分库，按照业务进行了纵向的数据库拆分。

基于ibatis，以前我写过一个原型ibaits-sharding来做数据的水平切分，不过后来有了amoeba，我们的方案做了些修改，在很多场景下ibatis-sharding还是很不错的，看了楼主的方案，似乎也差不多啊

amoeba又是另外一个层面的实现了吧。。