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

果然是论文。

而且前面后面有矛盾， 一开始说不要master-slave， 后来又来了一个master-slave(延时的问题，数据丢失/恢复问题， 如果master挂了， 选择master策列等）（mysql的master-slave有很多问题）。


不过呢， 给大家做一个理解还是不错的（如过没有看过这方面的）。

[quote="xiaoyu"]果然是论文。 而且前面后面有矛盾， 一开始说不要master-slave， 后来又来了一个master-slave(延时的问题，数据丢失/恢复问题， 如果master挂了， 选择master策列等）（mysql的master-slave有很多问题）。 不过呢， 给大家做一个理解还是不错的（如过没有看过这方面的）。

麻烦这位大侠在评价的同时给点建设性的意见和建议，好吗？

写得不错呀

写成这样已经很不容易了..说实话..你要解决的问题其实是一个关系型数据库自由分割的问题..
并不是随随便便哪个程序员就能搞明白你的目的...

你写的很多, 写的很好. 但是如果看的人并没有经历过那种 pv 过亿的动态查询系统.他们是不会明白
我们为何这么热衷于水平分割 DB.

从数据库设计范式上来说. 这种分割已经属于破坏范式了.你在文章中也已经提到.
那么其实现在的主要的问题在于.基于单台服务器的能力有限. 已经不能满足海量数据的处理.

我们势必要将这些数据分割到不同的服务器上去. 那么既然有了分割.
就必然要牵扯到业务逻辑的分割. 因为如果不使用业务逻辑分割. 那么必然是由数据库底层提供分割.

比如 Oracle .它的产品很好. 可是要钱. 我们自己做 DB 分割. 必然不能做到像 Oracle 那样.
对于各种业务都能够很好的支持. 因为涉及到硬件底层的东西. 对于程序员来说. 它们是不可见的.

所以. 结局只有一条. 进行业务逻辑的分割. 就如你提到的 use_id . 至于用 hash , 还是取摸. 这其实
都是边边角角的东西.

真正的东西在于. 你这么分割.是否能保证你所要求的业务逻辑.
比如上面有人说了.怎么做统计查询. 因为你将 10000 条数据分割到 10个数据库中. 每个 1000 条.
那么这些数据之间如果有跨库关联.那么该怎么做.

如果跨库的数据需要事务保证. 那么又要怎么做?

遗憾的是. 我一直在考虑. 可是觉得这个问题不是我能解决的. 因为关系型数据库的事务保证.
以及 JTA 的所谓跨库事务保证. 是以牺牲性能为代价的. 那不是我想要的.

目前来说. 数据库的水平分割. 如果不考虑业务逻辑. 那是无解的..
如果自行按照业务逻辑来分割. 那么你的方法已经很合适了. 但是分割时要考虑能否实现系统所要求的
跨库数据统计及关联即可.

这里给个小意见.那就是把无关的数据进行隔离. 比如你分割数据了. 那就从业务上. 再也不要有跨库的
查询和事务要求..

如果有统计数据. 可以在系统缓存中做. 然后找一个独立的数据库保存. 而不要用程序进行跨库统计.

-------------

我一直在做 java 金融系统. 也碰到过这种系统瓶颈. 其实 mysql 的性能不是像大家想的那样.
一定比 oracle 差. 如果大家有机会测试一下 mysql , oracle 的 pi .
其实影响这个的主要是机器配置.

感觉楼主可能是淘宝的..呵呵..有机会会见面的..

PI只能说明计算能力吧
并不能说明数据库系统的综合能力

既然你那么牛X怎么不用两三句来写给大家看看，最讨厌这种人不认可别人的成果，即便你很厉害也不需要这样说，毕竟这里不是每个人都像你那么牛X,支持楼主

发现 je上就以打击人和挑毛病为乐趣，就拿这个方案来说吧。我们做的是互联网系统，而不是报表统计系统。
互联网产品首要就是解决速度问题，至于统计也可以通过其他方式来解决。好像目前门户网站都是基于这种分库分表的处理手段。

今天终于看完了楼主的长篇，支持多发此类文章。不过不太确定的细节建议不要往上写。

谢谢忠言啊。。嘿嘿

谢谢支持！