阅读:110394次
评论:66条
更新时间:2011-05-26
分布式(Distributed)数据访问层(Data Access Layer)(以下简称DAL)是综合MySQL Proxy、Memcached、集群等等技术优点而构建的一个软件系统。目的是为了解决在构建大中型网站时遇到的和数据访问有关的诸多问题，如怎么使得切库分表透明化，如何使得缓存存取清除自动化，怎样才能更好地防止服务单点故障等等。DAL是手机之家团队近几年在开发和运营上的经验的总结以及智慧的结晶。
许超前 是手机之家一位资深的开发者和架构师, JavaEye非常荣幸的采访了他。
许超前博客：http://www.longker.org/
欢迎大家推荐更多开源项目和业界专家给我们，支持中国的IT发展，发站内短信给JavaEye管理员或者发信到webmaster@iteye.com，谢谢。
许超前 是手机之家一位资深的开发者和架构师, JavaEye非常荣幸的采访了他。
许超前博客：http://www.longker.org/
欢迎大家推荐更多开源项目和业界专家给我们，支持中国的IT发展，发站内短信给JavaEye管理员或者发信到webmaster@iteye.com，谢谢。
采访分布式数据访问层(Data Access Layer)作者许超前（十四）
JavaEye：1.Hi，许超前，你好，非常荣幸能够采访你，首先你能够向大家介绍一下分布式(Distributed)数据访问层(Data Access Layer)吗？
许超前：简单说来，分布式数据访问层(以下简称DAL)是综合MySQL Proxy、Memcached、集群等等技术优点而构建的一个软件系统。目的是为了解决在构建大中型网站时遇到的和数据访问有关的诸多问题，如怎么使得切库分表透明化，如何使得缓存存取清除自动化，怎样才能更好地防止服务单点故障等等。后面，我会在我的博客上以及今年的SD2China大会上做进一步的说明，有兴趣的可以留意。
JavaEye：2.分布式(Distributed)数据访问层(Data Access Layer)是什么时候诞生的，能否介绍一下发展历程？
许超前：DAL的产生是经历一番波折的。
2007 年，手机之家的用户已经接近1000万、PV也到了500万以上，正处于中小型网站向大型网站的过渡时期。那时候，我们明显感觉到我们在技术上已经遇上了瓶颈：一个是系统负载过高，经常要担心我们的数据库是不是又挂了，进而造成整个系统的瘫痪；第二个是5年积累下来的代码也已经非常难以维护，因为分层模糊，结果到处充满着数据库访问逻辑、到处充满着缓存读写逻辑，再加上表的设计不合理，造成无法简单地进行水平伸缩。总之，我们的系统已经到了不得不进行改造的地步了。
后来，老高(手机之家创始人高春辉)组了一个研发团队，旨在从根本上解决上述提到的问题。在此后一年的时间里，我们走了很多弯路，经历了很多痛苦，不过，也正是在这段时间里，产生了DAL的雏形，经过若干次改进，变成了后来的DAL1.0。DAL的产生完全是形势使然。。。到了那个时间、在那个地点、做了那件事。
DAL1.0上线后数据库的QPS明显下降，从几千降到几百。事实证明，我们找到了一条行得通的路子。所以才有DAL的后续版本的开发，才有今天的DAL2.x版本的产生。
JavaEye：3.能介绍一下手机之家网站和技术团队吗？
许超前：手机之家是一个旨在提供全方位的手机相关服务的资讯类网站。在7年的时间里，手机之家从无到有，已经发展成为极具人气、最受关注的手机产品资讯网站。有点广告的味道，不过说的都是事实，呵呵。
以下是今年3月份在Beta技术沙龙上提到的统计数据：
a. 1000w+用户
b. 3000w+帖子
c. 1.1TB+附件
d. 780w+ Page View/每天
e. 5~10w在线用户/15分
现在，用户应该是1200万了吧，其它的也有所变动。最近比较忙，没再去关注。
手机之家现在有个技术部，负责网站的日常维护事宜；我们还有个项目组，负责整个系统的架构设计及新技术的研究和探索等等。
JavaEye：4.分布式(Distributed)数据访问层(Data Access Layer)的主要特点是什么？能否简要分析一下它实现的主要技术核心？
许超前：要说特点，摘抄一下我在博客里写的关于新版DAL的项目目标，这些目标在DAL2.x里已经得到了相对较好的实现，我想这应该就是它最大的特点了吧：
一）可伸缩。
这里是指Scale Out.，即水平可伸缩。事实上，这点更应该是整个系统要考虑的目标了，而非DAL，DAL要考虑的是怎么更好地支持。举例说，我们可以一个库一个服务，甚至可以是一个表一个服务；库、表拆分后，DAL应能路由查询、合并结果，而不是让应用程序去操心这些事。
二）高可用性。
1) 我们认为出错失败是很正常的，一台机器倒下了，其它机器应继续保持系统正常运作。容错是很重要的一个要求。
2) 系统规模大了以后，很容易出现“异构“的情况，如原有模块MySQL表引擎是MyISAM的，是不支持事务的，而新上的模块又采用了InnoDB表引擎，在这种情况下，DAL应能对原有模块进行优雅降级。
3)失败恢复也是要考虑的，失败后，需要把失败前驻留在内存中的消息找回来。
4) 另外，DAL本身也在快速的迭代当中，升级是很经常的事，应能进行在线热升级(不重启原有服务)。
三）良好的性能。
对于根据Id来取记录的查询，在缓存命中的情况下，应该达到和Memcached不相上下的读取速度。在缓存不命中的情况下，则应该充分利用分库分表和并行计算的优势，最大化地提高查询的效率。对于修改型查询，挂在上面的监听器，不应该影响性能。
四）系统可监控。
资源占用情况，命中率如何，系统当前压力怎样等等，都应该是可知的。应该有报警机制，当压力到达一个阀值以后，通知相关人员进行处理。还应该有详细的错误日志，便于排查问题。
五）安全。
没有SQL注入问题；避免或尽量减少分表和索引表之间的数据不一致问题等等。
六）易于编程。
需要设计一套简单好用的API，便于应用程序的开发。API必须是自完备的，应用开发者不需要太费力就能记住的。
应用开发人员不再关心分库分表问题，不再关心缓存问题， 特别是缓存清除问题。甚至不再关心后端的数据库是MySQL，还是Oracle，或者是其它。
七）可定制、可扩展、可维护的架构设计。
像连接池组件、缓存组件、查询分析组件、消息队列组件、通讯协议等等不应该写死，应设计成可方便定制的。还应该提供足够的钩子用于扩展。只有这样，DAL 的架构才是灵活的、拥抱变化的。简单说，我们定的是机制，提供的是策略；机制是软件目标和宗旨的体现，一般是不能轻易改变的，而策略则应当是能比较简单地进行切换的。
这里面，每一点都可以说说，还是在以后的博客里，再来详细和大家讨论吧。
JavaEye：5.分布式(Distributed)数据访问层(Data Access Layer)应用的主要场景是什么？能否详细比较一下分布式(Distributed)数据访问层(Data Access Layer)和类似产品比如hibernate的区别吗？
许超前：DAL比较适用于大中型网站，对于想提高系统负载能力及响应速度的小型网站也是适用的，但可能获得的好处不如大中型网站那么明显。
DAL和Hibernate两者不具有可比性，从出发点来看就不同，DAL一开始是为了提高网站的负载能力，而Hibernate则是为了能更快地开发Java应用。手机之家采用混合编程，上层应用不一定是用Java写的，要让(非Java)程序员对每个模块涉及到的表结构都用Java实体类写一遍，不太现实。相反，我们采取了不同的思考方式，我们的程序员面向的是表和记录，而不是实体类和实体对象。虽然，DAL也有Mapping的概念，但是它的Mapping是指逻辑表到物理表的Mapping，而不是Java对象到数据库模式的Mapping。DAL的逻辑表可能对应着多个物理表，程序员看到的是逻辑表，不用关心后面有多少个物理表。
MySQL Proxy也提供了一些类似的特性，DAL与它的第一个不同在于，我们的缓存处理是内置的，我们从设计之初就特别认真地考虑缓存这块，而MySQL Proxy得自己写Lua脚本。第二个不同在于，我们针对的不仅仅是MySQL这一种数据库。而且，我们还有很多其它的事情要做。
另外，国内还有一个开源项目叫Amoeba。Amoeba关注的领域是切分，在这个领域，Amoeba对概念的抽象还是不错的。DAL更像是一个完整的系统，当然，也可以只用DAL来做切分，其它的逻辑自己编写，想拥有哪些特性都是可配置的。这样设计一个是为了易用，一拿来就能用，另一个是为了能更好的和现有的解决方案(如Hibernate)集成，虽然DAL在很多方面都可以取代它们(如Hibernate)。
最后，我相信，肯定还存在很多类似的解决方案，只是我们不曾得知。或许是过于定制化了，或许是还不够成熟。。。
JavaEye：6.目前大概有多少用户在使用分布式(Distributed)数据访问层(Data Access Layer)？
许超前：目前DAL主要用在手机之家网站上面，当然，还有其它的项目也在用。
JavaEye：7.目前分布式(Distributed)数据访问层(Data Access Layer) 开发的技术难点是哪里？
许超前：要说技术难点，我觉得有以下几点：
一）如何降低CPU负载及减少内存占用。
二）如何提高查询条件的分析速度。
三）如何更有效地路由到相应的库和表上。
四）如何提高缓存的命中率。
五）如何更有效的进行数据复制。
JavaEye：8.你每周大概花多少时间在分布式(Distributed)数据访问层(Data Access Layer)项目上面？
许超前：每周大概80个小时左右。
JavaEye：9.开发分布式(Distributed)数据访问层(Data Access Layer)带给你最大的收获是什么？
许超前：一）贵在坚持。一个长开发周期的软件，到了后面，不仅是对开发人员体力、智力的综合考验，更是对开发人员心理承受能力的考验，因为这时会有来自各方的及自发的压力。如果能坚持下去，扛过这一关，事情往往就成了一半。
二）找一些和你有共同目标的人一块共事。否则会耗费大量的沟通成本。
三）用数据说话。事务都在变化当中，几年前的经验，也许到今天就不灵了。而且很多事情并不是像我们想象得那样去发展。
四）中国不打折。
JavaEye：10.开发分布式(Distributed)数据访问层(Data Access Layer)的roadmap是什么？近期远期的开发计划计划是什么？
许超前：接下来的版本要做的事有这几个方面：
一）更多的协议开发，这样才能作为透明代理使用，比如我们的PMA也可以使用了。
二）数据库厂商中立的数据复制。
三）嵌入式API，考虑和Spring、Guice等集成，方便Java应用开发人员的使用。
JavaEye：11.你的开发环境是什么？ 使用什么操作系统，和IDE？
许超前：一直用Linux操作系统，现在是Ubuntu，IDE用Eclipse。
JavaEye：12.开发分布式(Distributed)数据访问层(Data Access Layer)项目是如何推广的？未来有什么推广方面的计划吗？
许超前：DAL目前只在内部项目中使用。等足够成熟了，我们会采取一系列办法进行推广的。
JavaEye：13.通过开发开发分布式(Distributed)数据访问层(Data Access Layer)项目 ，你对中国的开源软件现状有什么看法？对国内软件开发人员做开源项目有什么感受和想法吗？
许超前：我们的IT行业起步晚，开源文化还不够深入人心，再加上我们中的大部份人还在为生计发愁，所以对开源事业上心的人还是少数。因此，和欧美发达国家比起来，我们的开源事业相对滞后。
我由衷地敬佩那些做开源项目的开发人员，如果可能，我也希望多做些开源软件和大家一块分享。
JavaEye：14.作为一个JavaEye的会员，你对JavaEye网站有什么建议和意见吗？
许超前：想办法让老人多发言，同时也给新人提供一个学习成长的地方。比如可以弄个师徒频道(有点SNS的味道)，老人可以招学徒，新人可以拜师傅。
许超前：简单说来，分布式数据访问层(以下简称DAL)是综合MySQL Proxy、Memcached、集群等等技术优点而构建的一个软件系统。目的是为了解决在构建大中型网站时遇到的和数据访问有关的诸多问题，如怎么使得切库分表透明化，如何使得缓存存取清除自动化，怎样才能更好地防止服务单点故障等等。后面，我会在我的博客上以及今年的SD2China大会上做进一步的说明，有兴趣的可以留意。
JavaEye：2.分布式(Distributed)数据访问层(Data Access Layer)是什么时候诞生的，能否介绍一下发展历程？
许超前：DAL的产生是经历一番波折的。
2007 年，手机之家的用户已经接近1000万、PV也到了500万以上，正处于中小型网站向大型网站的过渡时期。那时候，我们明显感觉到我们在技术上已经遇上了瓶颈：一个是系统负载过高，经常要担心我们的数据库是不是又挂了，进而造成整个系统的瘫痪；第二个是5年积累下来的代码也已经非常难以维护，因为分层模糊，结果到处充满着数据库访问逻辑、到处充满着缓存读写逻辑，再加上表的设计不合理，造成无法简单地进行水平伸缩。总之，我们的系统已经到了不得不进行改造的地步了。
后来，老高(手机之家创始人高春辉)组了一个研发团队，旨在从根本上解决上述提到的问题。在此后一年的时间里，我们走了很多弯路，经历了很多痛苦，不过，也正是在这段时间里，产生了DAL的雏形，经过若干次改进，变成了后来的DAL1.0。DAL的产生完全是形势使然。。。到了那个时间、在那个地点、做了那件事。
DAL1.0上线后数据库的QPS明显下降，从几千降到几百。事实证明，我们找到了一条行得通的路子。所以才有DAL的后续版本的开发，才有今天的DAL2.x版本的产生。
JavaEye：3.能介绍一下手机之家网站和技术团队吗？
许超前：手机之家是一个旨在提供全方位的手机相关服务的资讯类网站。在7年的时间里，手机之家从无到有，已经发展成为极具人气、最受关注的手机产品资讯网站。有点广告的味道，不过说的都是事实，呵呵。
以下是今年3月份在Beta技术沙龙上提到的统计数据：
a. 1000w+用户
b. 3000w+帖子
c. 1.1TB+附件
d. 780w+ Page View/每天
e. 5~10w在线用户/15分
现在，用户应该是1200万了吧，其它的也有所变动。最近比较忙，没再去关注。
手机之家现在有个技术部，负责网站的日常维护事宜；我们还有个项目组，负责整个系统的架构设计及新技术的研究和探索等等。
JavaEye：4.分布式(Distributed)数据访问层(Data Access Layer)的主要特点是什么？能否简要分析一下它实现的主要技术核心？
许超前：要说特点，摘抄一下我在博客里写的关于新版DAL的项目目标，这些目标在DAL2.x里已经得到了相对较好的实现，我想这应该就是它最大的特点了吧：
一）可伸缩。
这里是指Scale Out.，即水平可伸缩。事实上，这点更应该是整个系统要考虑的目标了，而非DAL，DAL要考虑的是怎么更好地支持。举例说，我们可以一个库一个服务，甚至可以是一个表一个服务；库、表拆分后，DAL应能路由查询、合并结果，而不是让应用程序去操心这些事。
二）高可用性。
1) 我们认为出错失败是很正常的，一台机器倒下了，其它机器应继续保持系统正常运作。容错是很重要的一个要求。
2) 系统规模大了以后，很容易出现“异构“的情况，如原有模块MySQL表引擎是MyISAM的，是不支持事务的，而新上的模块又采用了InnoDB表引擎，在这种情况下，DAL应能对原有模块进行优雅降级。
3)失败恢复也是要考虑的，失败后，需要把失败前驻留在内存中的消息找回来。
4) 另外，DAL本身也在快速的迭代当中，升级是很经常的事，应能进行在线热升级(不重启原有服务)。
三）良好的性能。
对于根据Id来取记录的查询，在缓存命中的情况下，应该达到和Memcached不相上下的读取速度。在缓存不命中的情况下，则应该充分利用分库分表和并行计算的优势，最大化地提高查询的效率。对于修改型查询，挂在上面的监听器，不应该影响性能。
四）系统可监控。
资源占用情况，命中率如何，系统当前压力怎样等等，都应该是可知的。应该有报警机制，当压力到达一个阀值以后，通知相关人员进行处理。还应该有详细的错误日志，便于排查问题。
五）安全。
没有SQL注入问题；避免或尽量减少分表和索引表之间的数据不一致问题等等。
六）易于编程。
需要设计一套简单好用的API，便于应用程序的开发。API必须是自完备的，应用开发者不需要太费力就能记住的。
应用开发人员不再关心分库分表问题，不再关心缓存问题， 特别是缓存清除问题。甚至不再关心后端的数据库是MySQL，还是Oracle，或者是其它。
七）可定制、可扩展、可维护的架构设计。
像连接池组件、缓存组件、查询分析组件、消息队列组件、通讯协议等等不应该写死，应设计成可方便定制的。还应该提供足够的钩子用于扩展。只有这样，DAL 的架构才是灵活的、拥抱变化的。简单说，我们定的是机制，提供的是策略；机制是软件目标和宗旨的体现，一般是不能轻易改变的，而策略则应当是能比较简单地进行切换的。
这里面，每一点都可以说说，还是在以后的博客里，再来详细和大家讨论吧。
JavaEye：5.分布式(Distributed)数据访问层(Data Access Layer)应用的主要场景是什么？能否详细比较一下分布式(Distributed)数据访问层(Data Access Layer)和类似产品比如hibernate的区别吗？
许超前：DAL比较适用于大中型网站，对于想提高系统负载能力及响应速度的小型网站也是适用的，但可能获得的好处不如大中型网站那么明显。
DAL和Hibernate两者不具有可比性，从出发点来看就不同，DAL一开始是为了提高网站的负载能力，而Hibernate则是为了能更快地开发Java应用。手机之家采用混合编程，上层应用不一定是用Java写的，要让(非Java)程序员对每个模块涉及到的表结构都用Java实体类写一遍，不太现实。相反，我们采取了不同的思考方式，我们的程序员面向的是表和记录，而不是实体类和实体对象。虽然，DAL也有Mapping的概念，但是它的Mapping是指逻辑表到物理表的Mapping，而不是Java对象到数据库模式的Mapping。DAL的逻辑表可能对应着多个物理表，程序员看到的是逻辑表，不用关心后面有多少个物理表。
MySQL Proxy也提供了一些类似的特性，DAL与它的第一个不同在于，我们的缓存处理是内置的，我们从设计之初就特别认真地考虑缓存这块，而MySQL Proxy得自己写Lua脚本。第二个不同在于，我们针对的不仅仅是MySQL这一种数据库。而且，我们还有很多其它的事情要做。
另外，国内还有一个开源项目叫Amoeba。Amoeba关注的领域是切分，在这个领域，Amoeba对概念的抽象还是不错的。DAL更像是一个完整的系统，当然，也可以只用DAL来做切分，其它的逻辑自己编写，想拥有哪些特性都是可配置的。这样设计一个是为了易用，一拿来就能用，另一个是为了能更好的和现有的解决方案(如Hibernate)集成，虽然DAL在很多方面都可以取代它们(如Hibernate)。
最后，我相信，肯定还存在很多类似的解决方案，只是我们不曾得知。或许是过于定制化了，或许是还不够成熟。。。
JavaEye：6.目前大概有多少用户在使用分布式(Distributed)数据访问层(Data Access Layer)？
许超前：目前DAL主要用在手机之家网站上面，当然，还有其它的项目也在用。
JavaEye：7.目前分布式(Distributed)数据访问层(Data Access Layer) 开发的技术难点是哪里？
许超前：要说技术难点，我觉得有以下几点：
一）如何降低CPU负载及减少内存占用。
二）如何提高查询条件的分析速度。
三）如何更有效地路由到相应的库和表上。
四）如何提高缓存的命中率。
五）如何更有效的进行数据复制。
JavaEye：8.你每周大概花多少时间在分布式(Distributed)数据访问层(Data Access Layer)项目上面？
许超前：每周大概80个小时左右。
JavaEye：9.开发分布式(Distributed)数据访问层(Data Access Layer)带给你最大的收获是什么？
许超前：一）贵在坚持。一个长开发周期的软件，到了后面，不仅是对开发人员体力、智力的综合考验，更是对开发人员心理承受能力的考验，因为这时会有来自各方的及自发的压力。如果能坚持下去，扛过这一关，事情往往就成了一半。
二）找一些和你有共同目标的人一块共事。否则会耗费大量的沟通成本。
三）用数据说话。事务都在变化当中，几年前的经验，也许到今天就不灵了。而且很多事情并不是像我们想象得那样去发展。
四）中国不打折。
JavaEye：10.开发分布式(Distributed)数据访问层(Data Access Layer)的roadmap是什么？近期远期的开发计划计划是什么？
许超前：接下来的版本要做的事有这几个方面：
一）更多的协议开发，这样才能作为透明代理使用，比如我们的PMA也可以使用了。
二）数据库厂商中立的数据复制。
三）嵌入式API，考虑和Spring、Guice等集成，方便Java应用开发人员的使用。
JavaEye：11.你的开发环境是什么？ 使用什么操作系统，和IDE？
许超前：一直用Linux操作系统，现在是Ubuntu，IDE用Eclipse。
JavaEye：12.开发分布式(Distributed)数据访问层(Data Access Layer)项目是如何推广的？未来有什么推广方面的计划吗？
许超前：DAL目前只在内部项目中使用。等足够成熟了，我们会采取一系列办法进行推广的。
JavaEye：13.通过开发开发分布式(Distributed)数据访问层(Data Access Layer)项目 ，你对中国的开源软件现状有什么看法？对国内软件开发人员做开源项目有什么感受和想法吗？
许超前：我们的IT行业起步晚，开源文化还不够深入人心，再加上我们中的大部份人还在为生计发愁，所以对开源事业上心的人还是少数。因此，和欧美发达国家比起来，我们的开源事业相对滞后。
我由衷地敬佩那些做开源项目的开发人员，如果可能，我也希望多做些开源软件和大家一块分享。
JavaEye：14.作为一个JavaEye的会员，你对JavaEye网站有什么建议和意见吗？
许超前：想办法让老人多发言，同时也给新人提供一个学习成长的地方。比如可以弄个师徒频道(有点SNS的味道)，老人可以招学徒，新人可以拜师傅。
许超前 介绍
许超前，男，毕业于华中师范大学计算机科学与技术系，现居住在北京。98年开始喜欢上计算机，曾有过存储、搜索、Java NIO框架、Java Cache系统、消息队列等等的研发经验。一毕业就任职于手机之家(中国手机用户最受推崇的品牌)，前后已经4年了，目前担任架构师一职，负责分布式数据访问层(Data Access Layer, 简称DAL)软件的架构、设计和开发工作。
除了技术方面，爬山是最大的爱好，喜欢摄影，偶尔打打太极柔力球。
许超前博客：http://www.longker.org/
由于许超前太低调，只提供了一张背影给我们遐想
：
除了技术方面，爬山是最大的爱好，喜欢摄影，偶尔打打太极柔力球。
许超前博客：http://www.longker.org/
由于许超前太低调，只提供了一张背影给我们遐想
：
您还没有登录,请您登录后再发表评论
36 楼 wushunlian 2009-10-18 19:42
35 楼 Qring 2009-10-10 14:09
34 楼 wzjin 2009-10-09 11:49
33 楼 许超前 2009-09-29 01:16
谢谢
32 楼 许超前 2009-09-29 01:10
一）
这么多个业务范围，都很复杂吗？新浪的业务范围更多，，，，如何切分业务，，，应用切割，
我想您应该相信手机之家的研发团队在这些个方面的认知和经验。您不妨访问一下手机之家网站http://www.imobile.com.cn/，尤其是全动态的论坛http://bbs.imobile.com.cn/。方便的话开一下YSLOw，观察一下展现速度。
二）您的言语里多次出现Cache这个字眼，我想这是很多做网站的技术人员的共识。正是因为Cache如此重要，所以DAL集成了Cache(可以内置也可以外延)，这个Cache对应用来说是透明的。
三）至于您关心的命率问题，我在这里稍微描述一下。手机之家现在有4组DAL服务，以下是自近期升级或reload(重载配置和元数据)以来的Cache命中率统计：
a)
[rowCacheHits] => 1999443615(96.53%)
[rowCacheMisses] => 71820652(3.47%)
b)
[rowCacheHits] => 728834651(82.44%)
[rowCacheMisses] => 155230407(17.56%)
c)
[rowCacheHits] => 717269426(93.35%)
[rowCacheMisses] => 51101159(6.65%)
d)
[rowCacheHits] => 217927450(74.06%)
[rowCacheMisses] => 76326220(25.94%)
其中，b组服务命中率低的原因是：上面跑的是论坛，全动态的，更新频繁;
d组服务命中率低的原因是：应用层又做了缓存了，到DAL这边基本上都是之前未曾有过的请求。
四）
我就是觉得他们的思路是有问题，解决什么问题，
一）如何降低CPU负载及减少内存占用。
二）如何提高查询条件的分析速度。
三）如何更有效地路由到相应的库和表上。
四）如何提高缓存的命中率。
五）如何更有效的进行数据复制。
这五个是难点吗？
DAL发展至今，在大架子基本上敲定的情况下，这5个对我们来说已经成为重难点。最近，DAL已经部署到外部的项目上，我更是觉得做产品到了后来就是做细节了。
至于，我为什么这么说，也是有依据的。
1)DAL的缓存占用现在已经比较可观了，如何减少内存占用已经成为一个重难点。
以下是手机之家网站4组DAL缓存占用情况：
a)5.2G, b)12G, c)3.7G, d)6.2G。
缓存大了，是有喜也有忧。喜是因为数据被缓存了；忧则是担心进程出问题。不过，就目前来看，表现还不错，运行很长一段时间才会出现对老代的收集。一般耗时在0.2秒以内，我们认为是可以接受的。同样是4组缓存服务的垃圾回收情况：
a)
430610.121: [GC 430610.121: [ParNew: 970596K->44174K(990336K), 0.0256880 secs] 4481307K->3554885K(5184640K), 0.0258610 secs] [Times: user=0.19 sys=0.00, real=0.03 secs]
430620.486: [GC 430620.487: [ParNew: 976270K->48820K(990336K), 0.0262000 secs] 4486981K->3559531K(5184640K), 0.0263790 secs] [Times: user=0.19 sys=0.00, real=0.03 secs]
430634.904: [GC 430634.904: [ParNew: 980916K->50728K(990336K), 0.0299380 secs] 4491627K->3562274K(5184640K), 0.0301230 secs] [Times: user=0.21 sys=0.00, real=0.03 secs]
430647.934: [GC 430647.934: [ParNew: 982824K->37053K(990336K), 0.0329200 secs] 4494370K->3550926K(5184640K), 0.0331400 secs] [Times: user=0.22 sys=0.00, real=0.03 secs]
b)
416275.295: [GC 416275.295: [ParNew: 990336K->48297K(990336K), 0.0973960 secs] 10629874K->9712340K(12524672K), 0.0974940 secs] [Times: user=0.54 sys=0.02, real=0.09 secs]
416300.211: [GC 416300.211: [ParNew: 980393K->58240K(990336K), 0.1081660 secs] 10644436K->9750993K(12524672K), 0.1082560 secs] [Times: user=0.57 sys=0.02, real=0.11 secs]
416323.653: [GC 416323.653: [ParNew: 990336K->58240K(990336K), 0.1131280 secs] 10683089K->9781286K(12524672K), 0.1132320 secs] [Times: user=0.63 sys=0.02, real=0.11 secs]
416344.535: [GC 416344.535: [ParNew: 990336K->45931K(990336K), 0.1059780 secs] 10713382K->9796606K(12524672K), 0.1060800 secs] [Times: user=0.60 sys=0.02, real=0.11 secs]
c)
430107.117: [GC 430107.117: [ParNew: 488106K->27846K(495168K), 0.0482880 secs] 3289951K->2832064K(3640896K), 0.0485100 secs] [Times: user=0.15 sys=0.00, real=0.05 secs]
430124.541: [GC 430124.541: [ParNew: 493894K->19566K(495168K), 0.0484850 secs] 3298112K->2827443K(3640896K), 0.0487180 secs] [Times: user=0.15 sys=0.00, real=0.05 secs]
430140.861: [GC 430140.862: [ParNew: 485614K->22204K(495168K), 0.0491390 secs] 3293491K->2832961K(3640896K), 0.0493860 secs] [Times: user=0.16 sys=0.00, real=0.05 secs]
430155.071: [GC 430155.071: [ParNew: 488252K->22652K(495168K), 0.0585010 secs] 3299009K->2837236K(3640896K), 0.0587300 secs] [Times: user=0.17 sys=0.00, real=0.06 secs]
d)
346635.015: [GC 346635.015: [ParNew: 985396K->51289K(990336K), 0.0575730 secs] 5606751K->4682230K(6377232K), 0.0577020 secs] [Times: user=0.32 sys=0.01, real=0.06 secs]
346684.600: [GC 346684.600: [ParNew: 983385K->58240K(990336K), 0.0652490 secs] 5614326K->4701406K(6377232K), 0.0653740 secs] [Times: user=0.35 sys=0.02, real=0.06 secs]
346737.473: [GC 346737.473: [ParNew: 990336K->42276K(990336K), 0.0550940 secs] 5633502K->4694264K(6377232K), 0.0552260 secs] [Times: user=0.31 sys=0.01, real=0.05 secs]
346784.224: [GC 346784.224: [ParNew: 974372K->37784K(990336K), 0.0535490 secs] 5626360K->4698018K(6377232K), 0.0536790 secs] [Times: user=0.30 sys=0.00, real=0.06 secs]
看起来还可以，但是我认为还是有提升的空间，最近一直在弄这个问题。
2)DAL2.x性能相比DAL1.x有了提升，但还不够，我们和Memcached比起来还有一点差距，profile了一下，发现瓶颈在查询分析上。但问题是查询我已经做了一定的优化。
以下是一些在Linux Imobile-11 2.6.18-128.7.1.el5 #1 SMP Mon Aug 24 08:21:56 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux&jdk6上运行的统计数据：
1)复杂情况：id IN (6, 7, 8, 9) AND (a>b AND (c IN (1,2,3,4) OR d NOT LIKE "ab%" OR e<=3) OR f=6) or id=4
10000000(1千万)次单线程建树耗时测试。
10377ms 963669.654042594棵/s
10265ms 974184.120798831棵/s
10286ms 972195.216799533棵/s
2)通常情况: siteId=1 OR cateId=5 AND publishTime<=1251216000 AND articleType=2
10000000(1千万)次单线程建树耗时测试。
3840ms 2604166.666666667棵/s
3705ms 2699055.330634278棵/s
3769ms 2653223.666755107棵/s
3)简单情况: postId=1
10000000(1千万)次单线程建树耗时测试。
647ms 15455950.540958269棵/s
644ms 15527950.310559006棵/s
643ms 15552099.533437014棵/s
要想在性能上和Memcached不相上下，查询分析自然也成了重难点。
DAL2.x是有了相对较好的实现，但在这点上，DAL还有提升的余地，这也是我博客上迟迟没有后续更新的一个原因，因为我认为还没达到预期的目标。
3)至于3、4、5，我说一下3，其它的就不在这赘述了，时间不早了。
选择合适的库和表，不仅要考虑schema是否匹配，还要考虑索引是不是合适，以及是不是能产生最优的结果。最优选择往往是一个困难的过程，但索引选的不好，在表比较大的情况下，我想后果大家都知道。这也是我把它列为重难点的原因。
31 楼 许超前 2009-09-29 01:09
谢谢
30 楼 许超前 2009-09-29 01:08
29 楼 kingrom 2009-09-28 14:39
这么说吧，一个Data Access Layer群，只能解决业务数据整合的概念，并不能对业务切分，应用切分。所以啊我觉得他考虑的不够周全，不稳重。。。。
28 楼 kingrom 2009-09-28 14:29
* 首页
* 手机大全
* 选机中心
* 手机新闻
* 3G
* 手机游戏
* 手机软件
* 手机彩图
* 和弦铃声
* 手机主题
* K-JAVA
* 电子书
* 交易
* 软件签名
* 软件检测
* 答题赢奖
* 手机论坛
这么多个业务范围，都很复杂吗？新浪的业务范围更多，，，，如何切分业务，，，应用切割，
27 楼 dennis_zane 2009-09-28 14:00
我就是觉得他们的思路是有问题，解决什么问题，
一）如何降低CPU负载及减少内存占用。
二）如何提高查询条件的分析速度。
三）如何更有效地路由到相应的库和表上。
四）如何提高缓存的命中率。
五）如何更有效的进行数据复制。
这五个是难点吗？
我看了从头看到尾巴，就没有看出什么新思路出来，，，还分布式数据访问层。。。看不出来。轮子。。知道不。。。
是没有什么新思路，然而如果能将上面5个问题解决好就已经非常了不起。真正的问题在于，我们不知道超前已经实现到什么程度，DAL是如何解决这5个问题，这部分没有谈，而这个才是我关心的。考虑到这只是一个访谈介绍，你也不能指望别人透漏什么，毕竟不是开源的东西，有兴趣你完全可以找他私人聊聊。
至于是不是轮子，我不敢下结论，我们公司内部也是在做此类分布式的数据访问层，每个公司遇到的情况不一定相同，通用的产品总有一些不适宜或者不趁手的地方，因此另起炉灶也不是什么特别奇怪的事情吧，我们还自己搞MQ呢。
26 楼 kingrom 2009-09-28 13:53
我就是觉得他们的思路是有问题，解决什么问题，
一）如何降低CPU负载及减少内存占用。
二）如何提高查询条件的分析速度。
三）如何更有效地路由到相应的库和表上。
四）如何提高缓存的命中率。
五）如何更有效的进行数据复制。
这五个是难点吗？
我看了从头看到尾巴，就没有看出什么新思路出来，，，还分布式数据访问层。。。看不出来。轮子。。知道不。。。
25 楼 dennis_zane 2009-09-28 13:35
就象个傻子，要自己写个框架出来，不借用其他的框架。这个架构是不可取的。
你看看现在的企业项目或者老外的项目，尽可能的简单化。4年的工作经验就象一张白纸，
你认为你称职吗？怎么样，就鄙视你。
你这人可真莫名其妙，我都看不下去了，你在质疑什么？说了一通废话之后就开始人身攻击了？你说别人不规范，超前问你是什么规范，你又顾左右而言他扯一些众所周知的常识来质疑别人，你看看你的逻辑站不站得住脚。
24 楼 kingrom 2009-09-28 12:49
就象个傻子，要自己写个框架出来，不借用其他的框架。这个架构是不可取的。
你看看现在的企业项目或者老外的项目，尽可能的简单化。4年的工作经验就象一张白纸，
你认为你称职吗？怎么样，就鄙视你。
23 楼 kingrom 2009-09-25 11:43
你这个你没有考虑到，最大化地提高查询的效率是1、对分库分表的结构拆分精简，2、应该对查询的语句进行优化，
做产品与做项目是两回事，你开发DAL是为了解决什么问题？效率？高可用性？良好的性能？易于编程？安全？
22 楼 许超前 2009-09-24 01:41
一）不知您所说的规范是指什么？
二）DAL可以选择是否开启Cache。
三）DAL2.x并不是为某一个项目或系统专门定制的。目前已经有几个项目在使用。
四）对于这个采访里的言辞，我已经非常谨慎了，怕的就是夸大其辞、误人子弟。如有谬误，烦请指正，本人诚心接受，谢谢。
21 楼 tianyue 2009-09-21 16:05
20 楼 kingrom 2009-09-20 13:39
19 楼 kingrom 2009-09-20 13:28
这个应该重写了DATA ACCESS LAYER ，CACHE缓存应该是自己写的，很多地方感觉你们的DATA ACCESS LAYER不是很规范，纯粹是以项目做的。解释的也不是很清楚及理解错误。
18 楼 许超前 2009-09-18 01:40
@axxxx2000
您好。
@mpl398235717，mudong ， 超级潜水员
DAL现在是还没放出来，有些特性需要完善，还有些特性需要添加。
预计是年底或明年年初，能有个说法。
不过，在这之前，我会以其它的形式，比如发Blog、参加会议等和大家一块分享、讨探一些想法和做法。
@Arbow
别这么说自己。我只是想把这个软件做好。
@dennis_zane， lordhong， keating，fangwei，C_J
谢谢。
17 楼 C_J 2009-09-18 01:01
16 楼 fangwei 2009-09-17 12:38
许超前：每周大概80个小时左右。
嗯，我等每周40小时的民工就是没得比
真是强大... 佩服~~~~~
景仰之
15 楼 七月十五 2009-09-16 20:59
有了DAL，经后大家架构的时候就有思路了
为什么一定要求源码呢？
14 楼 mpl398235717 2009-09-16 11:07
13 楼 mpl398235717 2009-09-16 11:06
12 楼 wxq594808632 2009-09-16 10:41
想办法让老人多发言，同时也给新人提供一个学习成长的地方。比如可以弄个师徒频道(有点SNS的味道)，老人可以招学徒，新人可以拜师傅
这个很期待。。
11 楼 axxxx2000 2009-09-16 10:00
10 楼 keating 2009-09-16 08:49
还差3小时!
9 楼 lordhong 2009-09-15 22:04
许超前：每周大概80个小时左右。
嗯，我等每周40小时的民工就是没得比
真是强大... 佩服~~~~~
8 楼 超级潜水员 2009-09-15 16:54
7 楼 mudong 2009-09-15 16:04