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

1. 逻辑 schema 设计先遵守 E-R 模型；
2. 把所有逻辑表隔离开，为每个逻辑表定义数据源；
3. 经过步骤2后，再把单个逻辑表按多种划分方式（各个属性域上设置划分函数）分散开，实现多组原逻辑表的分片，内部数据源粒度变细，变成对各个分片定义数据源；
4. 分片实际上跟数据库索引的实现非常类似，如果你熟悉数据库索引的实现，就很容易明白分片只是一种手动实现数据表索引的方式，基于此可以比较容易地完成分片以及设计分片规则以支持各类操作；
5. select/update/delete 根据 where 条件选择合适的分片组，update/insert/delete 时传播相关修改到其它分片组上。
6. 表/分片的类型有很多种，不要局限于普通的模型表，可以考虑这些表类型：缓存表、临时表、缓冲表、摘要表、计数表、统计表、其它表……
7. 总有些查询，在高度分片的系统上是没法执行的，自己按业务进行折衷。

逻辑表

每个逻辑表定义数据源

各个属性域上设置划分函数（属性域  划分函数）

多组

分片

数据源粒度

传播

相关

模型表.缓存表、临时表、缓冲表、摘要表、计数表、统计表、其它表

我是不知道您是怎么解释这些很炫的词儿的，不过您能保证您写出来的这些东西被一个新读者读明白么？。。。

统计函数要做rewrite，最好是在connection层面做成透明的sql rewrite，然后对结果重处理，直接返回结果给client就完美了
其他的基本select对应分片索引直接并行执行，结果union就好了，也做到connection层面去吧

如果连这些词汇都理解不了的话，那我建议最好还是不要折腾数据库水平切分。

逻辑表很难理解吗？“逻辑”上的表，而不是物理上的表。比如 JavaEye 论坛的用户、板块、主题、回帖，都是逻辑表；
数据源就是 DSN，Data Source Name，有过 Web + DB 开发经验的几乎都知道这个；
属性域就是表的属性，比如用户这个逻辑表有 id、name、pass、reg_time、face等属性，这很难理解吗？
分片组的意思就是一组分片，数组你总该知道吧？ shard group[36]; 声明了一个 group，这个 group 是 36 个 shard，很难理解？
分片？不解释了；
数据源粒度…… 搞过面向对象和设计模式，UML什么的（搞 Java 的这些总该知道吧），都会听说过粒度这个词。你觉得数据源粒度很难理解？
传播，不解释了；
相关：回到用户这个逻辑表。你改了 pass 域的值，同时有其它分片组里也有这个域，那么你就必须把这些分片组里对应的 pass 也改掉。简单地说就是字段冗余，只不过这个冗余不是在不同的表里冗余，而是在不同的分片组里冗余。这个“对应”，就是相关；
其它的表类型，自己揣摩。

其实我不想回复的，不过看上面那么多人讲来讲去就忍不住了，LZ的这篇文章名应该取做：数据库水平切分的实现方法概述，为什么这么讲，LZ一直在数据库切分问题上一直在外围、皮毛上绕而根本没有切进实质重点去讲，没有对一些重点难点问题比如业务统计查询，事务等方面没有做讲解，而是一笔带过，对数据库Master、Slave、group之间如何同步如何保证一致仅仅依靠mysql的Proxy机制……LZ所省略不去讲的东东才是数据库切分的重点难点，解决了这些重点难点，数据库切分就想怎么切就怎么切了

抱歉，如果您每一个东西都能这样解释一下，再举个例子出来，我想这长度不比lz那篇文章短多少。
对于我这类新手来说，这可不符合您所谓"几句话就能说清楚"这个论点了。

没别的意思，我的意思只是如果您这样去论述一个问题，是很难把问题论说清楚地。

如果您觉得对此问题有研究，那就share,不要上来先装bi,如果您上来就说了1234567，我想没人会反感您的。

可惜您上来先说的是让人摸不找边际的话哈。

是的，这些东西才是真正宝贵的。只有真正在实战中碰到了问题，才能有这方面的经验积累。
我第一个回帖，就是因为看来看去也没看出啥有价值的东西出来，所以发了个回复表示不满。。

赞同，我提一些我的看法，做架构/产品设计既要有注重“大” 也要注重“小”。
大的我觉得楼主具备了，也很有思路，敏锐。
小的呢，我觉得有所欠缺。 有大缺小，我觉得远远要比有小缺大要危险的多。

做架构、产品设计，思路要灵活、开阔，但是细节问题更要仔细把握，认真分析，权衡再三。

而光看着大气，赶潮流的方案，就热解沸腾的兴奋状思考，激动完毕，一股脑写成实际方案推行，这样的方案十有八九是陷阱方案。

每个方案都有每个方案的利弊，这些东西你的思考里面一定要仔细斟酌分析清楚，并在你的设计里面写得清清楚楚，这样的方案无论是给客户，还是给自己的团队，都才是实在的可行的东西。

很遗憾，我从讨论的帖子来看，避重就轻，光看着优点，对缺点几乎没做啥分析。

所以，少头脑发热，多踏实做事。

大致看明白了楼主的文章。
在不考虑统计的情况下，对于压力的分担确实不错。
我们原来的系统也有使用到类似的方案（统计是闲时在后台跑的）。
不过，对于ORM来说，似乎不太友好。
因为库（或者说是group，如果采用这个的话）的连接地址需要根据key来动态分配，那么对于例如spring之类的IOC中的数据源的设置问题，怎么解决？

像AGE那样基于文件系统存储，提供类sql的工具，成为分布式数据库了。数据切分对AGE而言是天然的。