|
锁定老帖子 主题：数据库水平切分的实现原理解析
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-06-29
最后修改：2009-06-29
liufeng820 写道 firebody 写道 liufeng820 写道 firebody 写道 zhuyx808 写道 其实我不想回复的，不过看上面那么多人讲来讲去就忍不住了，LZ的这篇文章名应该取做：数据库水平切分的实现方法概述，为什么这么讲，LZ一直在数据库切分问题上一直在外围、皮毛上绕而根本没有切进实质重点去讲，没有对一些重点难点问题比如业务统计查询，事务等方面没有做讲解，而是一笔带过，对数据库Master、Slave、group之间如何同步如何保证一致仅仅依靠mysql的Proxy机制……LZ所省略不去讲的东东才是数据库切分的重点难点，解决了这些重点难点，数据库切分就想怎么切就怎么切了
赞同，我提一些我的看法，做架构/产品设计既要有注重“大” 也要注重“小”。 大的我觉得楼主具备了，也很有思路，敏锐。 小的呢，我觉得有所欠缺。 有大缺小，我觉得远远要比有小缺大要危险的多。 做架构、产品设计，思路要灵活、开阔，但是细节问题更要仔细把握，认真分析，权衡再三。 而光看着大气，赶潮流的方案，就热解沸腾的兴奋状思考，激动完毕，一股脑写成实际方案推行，这样的方案十有八九是陷阱方案。 每个方案都有每个方案的利弊，这些东西你的思考里面一定要仔细斟酌分析清楚，并在你的设计里面写得清清楚楚，这样的方案无论是给客户，还是给自己的团队，都才是实在的可行的东西。 很遗憾，我从讨论的帖子来看，避重就轻，光看着优点，对缺点几乎没做啥分析。 所以，少头脑发热，多踏实做事。 说的太好了...人家抛砖引玉来讨论个问题...你们这帮人除了冷嘲热讽外..一点自己的想法都不拿出来... 说的太好了...还好有楼主这样的人..虽然技术一般..头脑发热...但是人家愿意把自己的所学所想分享给大家.. 而不是像你这样...冷静优雅的否定别人的想法...而不是说出自己的见解... 这叫什么? 自己想想吧... 或许我说的话有些过分，但是其实我是想给LZ做一些提醒。 我看了他的帖子，一篇接着一篇，都是分析如何针对这个设计做拓展，如何解决这个设计碰到的问题，如何优化这个设计，以及这个设计的优点。 我说这么严厉（泼冷水），其实是想做一个善意的提醒： 别为了设计而设计。 从任何一个点都可以衍生出很多可以思考讨论的东西来，就比如这么一个设计，光是这么一个设计就可以衍生出众多的讨论出来，正如LZ所说的故障检测，性能分析，负载均衡..... 但是，任何东西在你真正做之前先得分析这个东西是出于什么目的，它能够解决什么问题，不能够解决什么问题 。 他对它所适用的场景有何优势，和其他可选方案对比有何优缺点。 我感觉楼主是花了很大力气来做这块工作的，所以需要提醒的就是开头有这个说明。 才能更全面整体的分析自己的方案。 很多情况是，0可以否定1，何来1后面衍生出的2，3，4，5来呢？ 就我的感觉而言，做这么大一个方案，如果我是BOSS，至少需要判断这个方案是否和此类相关的成熟产品做过对比分析？ 没有，那么可以丢到垃圾桶里去了。 当然，苛刻一点，我还得加一个前提，做这个设计的团队是否有足够的经验，以前是否一致使用过相关的产品来做过研发，有足够的经验来做对比分析，整体考虑。没有，也可以让这个团队历练历练再说。 设计，有时候真的可以上瘾而疯狂的，嘿嘿，不是吗？ 很抱歉前面针对你的话语有了不礼貌的地方... 其实有些东西是很难做到的,特别以楼主一个还在学校的学生.在写毕业论文的时候, 使用了这个题目. 不客气的说, 如果他能有一个完美的解决方案. 那么他现在直接就会被 Oracle , Mircosoft , IBM 等抢走的. 我想.他做不到. 他能做到的是. 提出这样一个问题. 这种问题可能我们多多少少都曾经遇到过. 也尝试解决过.可是我们也失败了. 或者觉得问题过于复杂. 采用别的方法绕了过去. 但是, 他发起了一个课题. 想解决它. 他自己的经验知识可能无法完成这个任务. 但是我们有 goolge . 有 javaeye , 现在不是 20年前那种英雄主义的时代. 而是可以大家共智共力来解决问题. 有你的提醒.我想如果是在一个真正的项目中.那么会让这个项目减少风险.思路清晰的走下去. 而在此时. 楼主需要的仅仅是大家的一些经验和想法. 来帮他完善自己的构思. 您说.不是吗? 是的，这个确实是我本科毕业论文的一部分，后面的实现部分还没有写呢。。。 这个论题是我在公司实习期间接触到的，现在也有比较成型的线上产品在运行。最初的设计目标并不打算做成通用的广泛的DDAL。。。而是针对特定技术的解决方案！ |
| 返回顶楼 | |
|
发表时间：2009-06-29
有实用性，毕竟用mysql和几台工作站或者pc,替换更昂贵的DBMS和硬件，这个还是很划算。
不过这有几个问题： 1.同类数据分散在不同表和库中，在做统计时，貌似无法用常规方法得到。不过可以考虑单独做个统计数据，在每次更新表数据时，先在这里更新一次统计数据，以后需要统计数据时，从这里计算。这只是个大概的想法，只能做预先设计好的统计。 2.事务的管理。小弟对mysql不了解，不知道能否支持跨库的事务。也许在应用程序级中控制事务？每次提交sql都附送一个反向操作sql？或则每张表设置个有效字段？（事务这点也不是一定，不是所有应用都具有事务性。） 3.最终要的是，sql语句的解析。提供给用户的接口应该是让用户书写标准的sql，后面的分库分表对用户应该都是透明的，而程序需要将标准sql解析后进行跨库跨表的读写。 小弟的一些愚见，也请楼主和各位指点。 |
| 返回顶楼 | |
|
发表时间：2009-06-29
sucker 写道 有实用性，毕竟用mysql和几台工作站或者pc,替换更昂贵的DBMS和硬件，这个还是很划算。
不过这有几个问题： 1.同类数据分散在不同表和库中，在做统计时，貌似无法用常规方法得到。不过可以考虑单独做个统计数据，在每次更新表数据时，先在这里更新一次统计数据，以后需要统计数据时，从这里计算。这只是个大概的想法，只能做预先设计好的统计。 2.事务的管理。小弟对mysql不了解，不知道能否支持跨库的事务。也许在应用程序级中控制事务？每次提交sql都附送一个反向操作sql？或则每张表设置个有效字段？（事务这点也不是一定，不是所有应用都具有事务性。） 3.最终要的是，sql语句的解析。提供给用户的接口应该是让用户书写标准的sql，后面的分库分表对用户应该都是透明的，而程序需要将标准sql解析后进行跨库跨表的读写。 小弟的一些愚见，也请楼主和各位指点。 想法还是不错的:) 2.一般来说事务可以通过合理的表结构设计来规避，核心的思想是能不用事务就不用，如果要用事务就把事物关联的表放在一个物理库。其余的通过补偿的机制来完成。 3.是的。不过这东西还是有局限的。 |
| 返回顶楼 | |
|
发表时间：2009-06-29
好文啊，学到了不少东西
|
| 返回顶楼 | |
|
发表时间：2009-06-30
最后修改：2009-06-30
作为一个架构方面的文章来说确实是个好文章
但是实际中里面的泥潭不是一般的深，LZ用的是mysql，那如果换一个数据库该怎么办？确实上面有很多地方值得讨论，就这个架构里面的随便一个关键点拿出来讨论都够写上好几篇论文了，我很早就考虑过这种架构，但是迫于原来说的哪些难点（统计，查询，更新，同步，事务，透明……）一直没有得到很好的解决，最后就放弃掉了，我想LZ如果有好的实现不妨拿出一个demo或者解决方案出来，这样才更有实用性，原来写的哪些不是来泼冷水，只是讲讲我的观点，希望能有个好的解决方案 |
| 返回顶楼 | |
|
发表时间：2009-06-30
liufeng820 写道 firebody 写道 liufeng820 写道 firebody 写道 zhuyx808 写道 其实我不想回复的，不过看上面那么多人讲来讲去就忍不住了，LZ的这篇文章名应该取做：数据库水平切分的实现方法概述，为什么这么讲，LZ一直在数据库切分问题上一直在外围、皮毛上绕而根本没有切进实质重点去讲，没有对一些重点难点问题比如业务统计查询，事务等方面没有做讲解，而是一笔带过，对数据库Master、Slave、group之间如何同步如何保证一致仅仅依靠mysql的Proxy机制……LZ所省略不去讲的东东才是数据库切分的重点难点，解决了这些重点难点，数据库切分就想怎么切就怎么切了
赞同，我提一些我的看法，做架构/产品设计既要有注重“大” 也要注重“小”。 大的我觉得楼主具备了，也很有思路，敏锐。 小的呢，我觉得有所欠缺。 有大缺小，我觉得远远要比有小缺大要危险的多。 做架构、产品设计，思路要灵活、开阔，但是细节问题更要仔细把握，认真分析，权衡再三。 而光看着大气，赶潮流的方案，就热解沸腾的兴奋状思考，激动完毕，一股脑写成实际方案推行，这样的方案十有八九是陷阱方案。 每个方案都有每个方案的利弊，这些东西你的思考里面一定要仔细斟酌分析清楚，并在你的设计里面写得清清楚楚，这样的方案无论是给客户，还是给自己的团队，都才是实在的可行的东西。 很遗憾，我从讨论的帖子来看，避重就轻，光看着优点，对缺点几乎没做啥分析。 所以，少头脑发热，多踏实做事。 说的太好了...人家抛砖引玉来讨论个问题...你们这帮人除了冷嘲热讽外..一点自己的想法都不拿出来... 说的太好了...还好有楼主这样的人..虽然技术一般..头脑发热...但是人家愿意把自己的所学所想分享给大家.. 而不是像你这样...冷静优雅的否定别人的想法...而不是说出自己的见解... 这叫什么? 自己想想吧... 或许我说的话有些过分，但是其实我是想给LZ做一些提醒。 我看了他的帖子，一篇接着一篇，都是分析如何针对这个设计做拓展，如何解决这个设计碰到的问题，如何优化这个设计，以及这个设计的优点。 我说这么严厉（泼冷水），其实是想做一个善意的提醒： 别为了设计而设计。 从任何一个点都可以衍生出很多可以思考讨论的东西来，就比如这么一个设计，光是这么一个设计就可以衍生出众多的讨论出来，正如LZ所说的故障检测，性能分析，负载均衡..... 但是，任何东西在你真正做之前先得分析这个东西是出于什么目的，它能够解决什么问题，不能够解决什么问题 。 他对它所适用的场景有何优势，和其他可选方案对比有何优缺点。 我感觉楼主是花了很大力气来做这块工作的，所以需要提醒的就是开头有这个说明。 才能更全面整体的分析自己的方案。 很多情况是，0可以否定1，何来1后面衍生出的2，3，4，5来呢？ 就我的感觉而言，做这么大一个方案，如果我是BOSS，至少需要判断这个方案是否和此类相关的成熟产品做过对比分析？ 没有，那么可以丢到垃圾桶里去了。 当然，苛刻一点，我还得加一个前提，做这个设计的团队是否有足够的经验，以前是否一致使用过相关的产品来做过研发，有足够的经验来做对比分析，整体考虑。没有，也可以让这个团队历练历练再说。 设计，有时候真的可以上瘾而疯狂的，嘿嘿，不是吗？ 很抱歉前面针对你的话语有了不礼貌的地方... 其实有些东西是很难做到的,特别以楼主一个还在学校的学生.在写毕业论文的时候, 使用了这个题目. 不客气的说, 如果他能有一个完美的解决方案. 那么他现在直接就会被 Oracle , Mircosoft , IBM 等抢走的. 我想.他做不到. 他能做到的是. 提出这样一个问题. 这种问题可能我们多多少少都曾经遇到过. 也尝试解决过.可是我们也失败了. 或者觉得问题过于复杂. 采用别的方法绕了过去. 但是, 他发起了一个课题. 想解决它. 他自己的经验知识可能无法完成这个任务. 但是我们有 goolge . 有 javaeye , 现在不是 20年前那种英雄主义的时代. 而是可以大家共智共力来解决问题. 有你的提醒.我想如果是在一个真正的项目中.那么会让这个项目减少风险.思路清晰的走下去. 而在此时. 楼主需要的仅仅是大家的一些经验和想法. 来帮他完善自己的构思. 您说.不是吗? 明白了，原来LZ在写毕业论文呢，论文论文，用笔写写出来也不错。 算我多嘴。 我还以为他是在给公司团队写方案呢， 学生做这么大的课题，不错，精神可嘉。 可以参考开心农场的架构思考一下，开心农场的架构其实也是专门针对他自己的领域做得特有的设计。 加一些实际的经验性的总结，论文看上去更可信一些，也少掉一些学院派的气氛。 |
| 返回顶楼 | |
|
发表时间：2009-06-30
最后修改：2009-06-30
实际上我目前就在尝试封装高度分片的分布式数据库，提供给应用层一个统一的仓储API。然而实际上应用层的需求是无穷无尽的，因此不可能覆盖100%的用例，只能提供一些常用的操作的封装。当时曾想过在这个封装层里编译SQL，生成查询计划，然后分发到各个分片节点上查询，最后在封装层里完成归并，这样可以达到最大化的透明度，后来很快就发现这种做法几乎不可行，一个简单的例子就是SNS系统里，查看好友最新日志这么一个需求。看似简单，不就是 friend 与 note两个表 join 一下再 order by 即可？但当一个人的好友数达到几万（开心网上就有好多人达到这个数）时，选择 top 10 条好友日志，在分片上进行手工 join 时就会遇到困难：需要先取出几万个好友id，然后去 note 表里进行几万个 id 的 in 操作，再 order by，这个操作的效率不仅在数据库层面非常低下，在网络传输层面也效率也非常低。如果 order by 的域还涉及 friend 里的某些域，则这种查询几乎不可能在应用层完成。因此这种 DDAL 对我来说只能是“乌托邦”了。另外，《high performance mysql 2nd edition》里也有一段话提到了这个“乌托邦”：
A completely automated, high-performance, transparent way to partition data and make it look like it lives on a single server would be wonderful, but it doesn’t exist yet. In the future, MySQL’s NDB Cluster storage engine might be fast and robust enough to work well for this purpose. |
| 返回顶楼 | |
|
发表时间：2009-07-06
lishuaibt 写道
downpour 写道
我最关心的还是查询和统计。
按照我的理解，可能需要一个完整的数据访问层，这个数据访问层能够处理jdbc拥有的一切功能。 我想请问一下，楼主是如何实现的。
目前不支持多表联查，毕竟可能链接的表不再同一个物理节点中，实现起来效率回事个比较大的问题。现在这个ddal依然在起步阶段，还有很多需要改进的地方。希望各位大侠能给点建议!
|
| 返回顶楼 | |
|
发表时间：2009-07-10
在脚本层面做这种SQL分析的工作的确是很大的问题，而且涉及到业务逻辑的变动，需要对原有的脚本进行修改。
目前来说，相对好一点的方案就是那个叫阿巴米的变形虫项目了。 |
| 返回顶楼 | |
|
发表时间：2009-07-10
eason007 写道 在脚本层面做这种SQL分析的工作的确是很大的问题，而且涉及到业务逻辑的变动，需要对原有的脚本进行修改。
目前来说，相对好一点的方案就是那个叫阿巴米的变形虫项目了。 amoeba非常优秀，能很透明的解决掉数据拆分的问题，不过最好是在应用一开始就计划好，否则迁移的成本还是非常大的 |
| 返回顶楼 | |
