精华频道 → 开源软件
阅读更多

开源软件
名家访谈 采访分布式数据访问层(Data Access Layer)作者许超前  

2009-09-15  编辑 ouspec 评论(62条) 有108923人浏览
DAL Data Access Layer MySQL Proxy Memcached 数据访问

声明：ITeye精华文章的版权属于ITeye网站所有，严禁任何网站转载本文，否则必将追究法律责任！

分布式(Distributed)数据访问层(Data Access Layer)(以下简称DAL)是综合MySQL Proxy、Memcached、集群等等技术优点而构建的一个软件系统。目的是为了解决在构建大中型网站时遇到的和数据访问有关的诸多问题，如怎么使得切库分表透明化，如何使得缓存存取清除自动化，怎样才能更好地防止服务单点故障等等。DAL是手机之家团队近几年在开发和运营上的经验的总结以及智慧的结晶。

许超前 是手机之家一位资深的开发者和架构师, JavaEye非常荣幸的采访了他。

许超前博客：http://www.longker.org/

欢迎大家推荐更多开源项目和业界专家给我们，支持中国的IT发展，发站内短信给JavaEye管理员或者发信到webmaster@iteye.com，谢谢。

采访分布式数据访问层(Data Access Layer)作者许超前（十四） Top

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的味道)，老人可以招学徒，新人可以拜师傅。

许超前 介绍 Top

许超前，男，毕业于华中师范大学计算机科学与技术系，现居住在北京。98年开始喜欢上计算机，曾有过存储、搜索、Java NIO框架、Java Cache系统、消息队列等等的研发经验。一毕业就任职于手机之家(中国手机用户最受推崇的品牌)，前后已经4年了，目前担任架构师一职，负责分布式数据访问层(Data Access Layer, 简称DAL)软件的架构、设计和开发工作。

除了技术方面，爬山是最大的爱好，喜欢摄影，偶尔打打太极柔力球。

许超前博客：http://www.longker.org/

由于许超前太低调，只提供了一张背影给我们遐想   ：






评论 共 62 条
32 楼 Qring 2009-10-10 14:09
我们应该抱着学习研究的态度看待问题，而不是泛泛而谈这个简单那个容易，再简单的问题也有他复杂的一面。就是因为我们老是眼高手低，所以才让自己，让整个技术界都平平凡凡，而自己却感觉天下无敌。
31 楼 wzjin 2009-10-09 11:49
好东西拿出来show都是好样的。
30 楼 许超前 2009-09-29 01:16
@dennis_zane
谢谢
29 楼 许超前 2009-09-29 01:10
@kingrom
一）
kingrom 写道
从1000万人的大型系统，要考虑更快的为客户展现，如何去考虑这个问题：3个方面，1、数据库的优化，集群，数据同步。2、架构的设计，应用的优化，减少到数据库的查询，缓存，cache，代码的优化，业务流程的优化，服务器集群，cache服务器，文件服务器，3、页面优化，cache。这个是技术方面。
这么多个业务范围，都很复杂吗？新浪的业务范围更多，，，，如何切分业务，，，应用切割，

我想您应该相信手机之家的研发团队在这些个方面的认知和经验。您不妨访问一下手机之家网站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这边基本上都是之前未曾有过的请求。


四）
kingrom 写道
23楼的，我说的是否是真的，你自己看看项目的说法，http://www.longker.org/
我就是觉得他们的思路是有问题，解决什么问题，
一）如何降低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是否匹配，还要考虑索引是不是合适，以及是不是能产生最优的结果。最优选择往往是一个困难的过程，但索引选的不好，在表比较大的情况下，我想后果大家都知道。这也是我把它列为重难点的原因。
28 楼 许超前 2009-09-29 01:09
@kongqz
谢谢
27 楼 许超前 2009-09-29 01:08
不好意思，最近因为个人的原因无法及时地回答大家的问题。
26 楼 kingrom 2009-09-28 14:39
写一个Data Access Layer，是不是只针对项目而言，我不能直接下判断，我感觉象。
这么说吧，一个Data Access Layer群，只能解决业务数据整合的概念，并不能对业务切分，应用切分。所以啊我觉得他考虑的不够周全，不稳重。。。。
25 楼 kingrom 2009-09-28 14:29
从1000万人的大型系统，要考虑更快的为客户展现，如何去考虑这个问题：3个方面，1、数据库的优化，集群，数据同步。2、架构的设计，应用的优化，减少到数据库的查询，缓存，cache，代码的优化，业务流程的优化，服务器集群，cache服务器，文件服务器，3、页面优化，cache。这个是技术方面。

    * 首页
    * 手机大全
    * 选机中心
    * 手机新闻
    * 3G
    * 手机游戏
    * 手机软件
    * 手机彩图
    * 和弦铃声
    * 手机主题
    * K-JAVA
    * 电子书
    * 交易
    * 软件签名
    * 软件检测
    * 答题赢奖
    * 手机论坛
这么多个业务范围，都很复杂吗？新浪的业务范围更多，，，，如何切分业务，，，应用切割，
24 楼 dennis_zane 2009-09-28 14:00
kingrom 写道
23楼的，我说的是否是真的，你自己看看项目的说法，http://www.longker.org/
我就是觉得他们的思路是有问题，解决什么问题，
一）如何降低CPU负载及减少内存占用。

二）如何提高查询条件的分析速度。

三）如何更有效地路由到相应的库和表上。

四）如何提高缓存的命中率。

五）如何更有效的进行数据复制。
这五个是难点吗？

我看了从头看到尾巴，就没有看出什么新思路出来，，，还分布式数据访问层。。。看不出来。轮子。。知道不。。。


是没有什么新思路，然而如果能将上面5个问题解决好就已经非常了不起。真正的问题在于，我们不知道超前已经实现到什么程度，DAL是如何解决这5个问题，这部分没有谈，而这个才是我关心的。考虑到这只是一个访谈介绍，你也不能指望别人透漏什么，毕竟不是开源的东西，有兴趣你完全可以找他私人聊聊。

至于是不是轮子，我不敢下结论，我们公司内部也是在做此类分布式的数据访问层，每个公司遇到的情况不一定相同，通用的产品总有一些不适宜或者不趁手的地方，因此另起炉灶也不是什么特别奇怪的事情吧，我们还自己搞MQ呢。
23 楼 kingrom 2009-09-28 13:53
23楼的，我说的是否是真的，你自己看看项目的说法，http://www.longker.org/
我就是觉得他们的思路是有问题，解决什么问题，
一）如何降低CPU负载及减少内存占用。

二）如何提高查询条件的分析速度。

三）如何更有效地路由到相应的库和表上。

四）如何提高缓存的命中率。

五）如何更有效的进行数据复制。
这五个是难点吗？

我看了从头看到尾巴，就没有看出什么新思路出来，，，还分布式数据访问层。。。看不出来。轮子。。知道不。。。
22 楼 dennis_zane 2009-09-28 13:35
kingrom 写道
3月初开始,80个小时，多人做。我只能认为你的架构师不称职，考虑的不周详，
就象个傻子，要自己写个框架出来，不借用其他的框架。这个架构是不可取的。
你看看现在的企业项目或者老外的项目，尽可能的简单化。4年的工作经验就象一张白纸，
你认为你称职吗？怎么样，就鄙视你。

你这人可真莫名其妙，我都看不下去了，你在质疑什么？说了一通废话之后就开始人身攻击了？你说别人不规范，超前问你是什么规范，你又顾左右而言他扯一些众所周知的常识来质疑别人，你看看你的逻辑站不站得住脚。
21 楼 kingrom 2009-09-28 12:49
3月初开始,80个小时，多人做。我只能认为你的架构师不称职，考虑的不周详，
就象个傻子，要自己写个框架出来，不借用其他的框架。这个架构是不可取的。
你看看现在的企业项目或者老外的项目，尽可能的简单化。4年的工作经验就象一张白纸，
你认为你称职吗？怎么样，就鄙视你。
20 楼 kingrom 2009-09-25 11:43
在大中型项目中必须配备缓存服务器去缓存数据，命中率更高，降低WEB服务器及数据库的压力，我不知道你的缓存是单台还是网络？
你这个你没有考虑到，最大化地提高查询的效率是1、对分库分表的结构拆分精简，2、应该对查询的语句进行优化，
做产品与做项目是两回事，你开发DAL是为了解决什么问题？效率？高可用性？良好的性能？易于编程？安全？
19 楼 许超前 2009-09-24 01:41
@kingrom
一）不知您所说的规范是指什么？
二）DAL可以选择是否开启Cache。
三）DAL2.x并不是为某一个项目或系统专门定制的。目前已经有几个项目在使用。
四）对于这个采访里的言辞，我已经非常谨慎了，怕的就是夸大其辞、误人子弟。如有谬误，烦请指正，本人诚心接受，谢谢。
18 楼 tianyue 2009-09-21 16:05
如果是一班牛人，一个系统做得越久，将会越容易维护。 如果是技术水平一般的一堆人，一个系统确实折腾不了5年就没有办法维护了。

17 楼 kingrom 2009-09-20 13:39
看了你们这些介绍，建议大家不要专注这个项目，这个项目可能有所收获，但不规范是事实。会给我们的项目增加很多烦恼。
16 楼 kingrom 2009-09-20 13:28
AL和Hibernate两者不具有可比性，从出发点来看就不同，DAL一开始是为了提高网站的负载能力，而Hibernate则是为了能更快地开发Java应用。手机之家采用混合编程，上层应用不一定是用Java写的，要让(非Java)程序员对每个模块涉及到的表结构都用Java实体类写一遍，不太现实。相反，我们采取了不同的思考方式，我们的程序员面向的是表和记录，而不是实体类和实体对象。虽然，DAL也有Mapping的概念，但是它的Mapping是指逻辑表到物理表的Mapping，而不是Java对象到数据库模式的Mapping。DAL的逻辑表可能对应着多个物理表，程序员看到的是逻辑表，不用关心后面有多少个物理表。

这个应该重写了DATA ACCESS LAYER ，CACHE缓存应该是自己写的，很多地方感觉你们的DATA ACCESS LAYER不是很规范，纯粹是以项目做的。解释的也不是很清楚及理解错误。
15 楼 许超前 2009-09-18 01:40
感谢大家的支持。。。

@axxxx2000
您好。

@mpl398235717，mudong ， 超级潜水员
DAL现在是还没放出来，有些特性需要完善，还有些特性需要添加。
预计是年底或明年年初，能有个说法。
不过，在这之前，我会以其它的形式，比如发Blog、参加会议等和大家一块分享、讨探一些想法和做法。

@Arbow
别这么说自己。我只是想把这个软件做好。

@dennis_zane， lordhong， keating，fangwei，C_J
谢谢。
14 楼 C_J 2009-09-18 01:01
确实很超前·
13 楼 fangwei 2009-09-17 12:38
lordhong 写道
Arbow 写道
引用
JavaEye：8.你每周大概花多少时间在分布式(Distributed)数据访问层(Data Access Layer)项目上面？

许超前：每周大概80个小时左右。

嗯，我等每周40小时的民工就是没得比

真是强大... 佩服~~~~~

景仰之
12 楼 七月十五 2009-09-16 20:59
思想是最重要的，发现问题比解决问题难得多
有了DAL，经后大家架构的时候就有思路了
为什么一定要求源码呢？
11 楼 mpl398235717 2009-09-16 11:07
能说下 下载地址吗，我对性能很感兴趣
10 楼 mpl398235717 2009-09-16 11:06
在哪下载啊 我想要
9 楼 wxq594808632 2009-09-16 10:41
引用


想办法让老人多发言，同时也给新人提供一个学习成长的地方。比如可以弄个师徒频道(有点SNS的味道)，老人可以招学徒，新人可以拜师傅



这个很期待。。
8 楼 axxxx2000 2009-09-16 10:00
校友
7 楼 keating 2009-09-16 08:49
每天工作11个小时  每周则是77个小时（周六、周天不休）...
还差3小时!
6 楼 lordhong 2009-09-15 22:04
Arbow 写道
引用
JavaEye：8.你每周大概花多少时间在分布式(Distributed)数据访问层(Data Access Layer)项目上面？

许超前：每周大概80个小时左右。

嗯，我等每周40小时的民工就是没得比

真是强大... 佩服~~~~~
5 楼 超级潜水员 2009-09-15 16:54
没有源码
4 楼 mudong 2009-09-15 16:04
弱弱的问一句，上哪下载啊？
3 楼 gmizr 2009-09-15 15:48
80小时

发表评论

您还没有登录,请您登录后再发表评论

相关推荐

  • 电子商务平台技术选型和架构设计

    最终一致性（Eventually consistent）意味着系统保证数据最终一致性，系统的数据副本不会因为网络通信延时或其他原因而超前于数据真实状态，系统组件在任何时刻都可以访问到最新的数据副本。 2.2.11 API API...

  • 分布式数据访问层(DAL)

    概述分布式(Distributed)数据访问层(Data Access Layer)，简称DAL，是利用MySQL Proxy、Memcached、集群等技术优点而构建的一个架构系统。主要目的是为了解决在高并发、大数据流操作遇到的和数据访问有关的诸多问题...

  • 专访:采用分布式数据访问层

    【IT168 报道】分布式(Distributed)数据访问层(Data Access Layer)(以下简称DAL)是综合MySQL Proxy、Memcached、集群等等技术优点而构建的一个软件系统。目的是为了解决在构建大中型网站时遇到的和数据访问有关的...

  • 卷积神经网络超详细介绍

    海量的有标记的训练数据，也就是李飞飞团队提供的大规模有标记的数据集ImageNet计算机硬件的支持，尤其是GPU的出现，为复杂的计算提供了强大的支持算法的改进，包括网络结构加深、数据增强（数据扩充）、ReLU、...

  • 这一年，这些书：2022年读书笔记

    Note: 以下 `markdown` 格式文本由 `json2md` 自动转换生成，可参考[JSON转Markdown：我把阅读数据从MongoDB中导出转换为.md了](https://blog.csdn.net/u013810234/article/details/113360229)了解具体的转换过程。...

  • Robot Operating System 2: Design, Architecture, and Uses In The Wild

    主张以下原则： 分布式 与类似的复杂领域一样，机器人技术中的问题最好通过分布式系统方法来解决[23]。需求被分成功能独立的组件，例如硬件设备驱动程序、感知系统、控制系统、执行程序等。在运行时，这些组件有自己...

  • Chubby — 用于松耦合分布式系统的锁服务

    例如，一个应用程序可能使用锁来选举一个primary，然后这个primary在一段相当长的时间可能是数小时或数天里，处理所有对数据的访问。这两种使用方式意味着对锁服务器的不同的需求。 粗粒度的锁在锁服务器引入的负载...

  • 网摘

    采访分布式数据访问层(Data Access Layer)作者许超前 http://www.javaeye.com/wiki/interview/1931-data-access-layer nginx, lighttpd, squidhadoop, cassandra http://nginx.org/http://www.nginx.com.cn/ http

  • Linux 操作系统原理介绍

    地址总线指定了数据传输的内存位置（地址），数据总线保存了传输的数据。数据总线是双向的，它允许CPU读取，也允许CPU写。控制总线包含了各种信号线用于在系统中发送时钟和控制信号。有许多种不同的总线类型，ISA和...

  • 大数据的概述

    在分布式计算中,由于数据量的大小及格式超出了典型数据库软件的采集、存储、管理和分析等能力,因此需要采用新的技术来完成当前数据量的处理及分析,于是大数据(BgDaa)技术就应运而生。 一、大数据的产生 大数据：就是...

  • 集成电路芯片半导体中英文对照术语词汇表

    data center 数据中心 data center 数据中心 data communication 数据通信 data flow 数据流 data hungry 需要大量数据的 data line 数据线 data mask 数据掩码 data path|datapath 数据路径 data preamble 数据前...

  • (转)Linux Kernel核心中文手册

     微处理器处理二进制数据：这些数据由 1 和 0 组成。这些 1 和 0 对 应电气开关的开或关。就好像 42 代表 4 个 10 和 2 个单元，二进制数字 由一系列代表 2 的幂数的数字组成。这里，幂数意味着...

  • 基金会总线协议分析（FF协议）

    FF协议 一、总体介绍 基金会总线（FF， Foundation Fieldbus）是在过程自动化领域得到广泛支持和具有良好发展前景的技术。其前身是以美国Fisher-...它以ISO/OSI开放系统层上增加了用户层。用户层主要针对自动化

  • 计算机网络I-考前指导复习提纲

    每一层的地址： domain name域名：应用层(application) port端口第四层（OSI的）(transport) IP地址是第三层(network) MAC地址：第二层(TCP/IP的network access) What network devices are operating at each layer?...

  • 左耳听风——笔记二：程序员练级攻略

    经典图书 经典论文 分布式事务 Paxos 一致性算法 Raft 一致性算法 Gossip 一致性算法 分布式存储和数据库 分布式消息系统 日志和数据 分布式监控和跟踪 数据分析 与编程相关的论文 其它的分布式论文阅读列表 小结 ...

  • 四川大学软件学院操作系统笔记

    关于作者 操作系统分数：96/100 友链 可以结合 yy 同学的中文笔记，很详细：四川大学软件学院 操作系统 期末复习知识点202302 这篇博客的使用方式 此博客笔记结合《操作系统——精髓与设计原理（第九版）》英文版和 ...

  • DRBD9用户指南

    处理过时数据的策略. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.16. 三路叠加复制. . . . . . . . . . . . . . . . ...

  • 硬件工程师学习英语必备

    1 - 英文电子专业词汇（硬件工程师学习英语必备） 1 backplane 背板 2 Band gap voltage reference 带隙电压参考 3 bench top supply 工作台电源 4 Block Diagram 方块图 5 Bode Plot 波特图 6 Bootstrap 自举 ...

  • 关于Internet的92问与答

    1．什么是Agent(代理程序) 答:　Agent(代理程序)是在客户机／服务器计算模式中，为客户机端程序或服务器端程序作数据准备和数据交换的系统部分。例如，在一些数据库查询系统中，用户可以采用自己喜欢的格式提出查询...

Global site tag (gtag.js) - Google Analytics