数据访问层开发实践

1、 数据访问层开发实践许超前手机之家2010年04月03日11)前言a) 关于数据访问层(Data Access Layer)b) 关于Dal2) Dal的产生3) Dal的发展a) Dal2.1.xb) Dal2.2.x4) Dal的未来5)关于我们6) Q&A目录目录目录2前言3关于数据访问层引用维基百科:A Data Access Layer (DAL) is a layer of a computer program which provides simplified access to data stored in persistent storage of some kind, su

2、ch as an entity-relational database.This data access layer is used in turn by other program modules to access and manipulate the data within the data store without having to deal with the complexities inherent in this access.4关于数据访问层(续)应用程序Data Access LayerDBAPI文件DAL在系统中的位置5关于Dal - 概览Dal是手机之家开发的数据访问

3、层软件的产品名。Dal1.0、Dal2.1.x、Dal2.2.x及Dal2.x则是该软件的不同版本系列的一个引用。Dal是手机之家研发团队近几年在开发和运营上的经验的总结以及智慧的结晶。开发Dal的目的是为了解决在构建大中型网站时遇到的和数据访问有关的诸多问题，如怎样使得分表透明化，怎样使得缓存存取清除自动化，怎样才能更好地防止服务单点故障等等。Dal1.0是一个具有里程碑意义的版本，但在很多方面仍然欠考虑。Dal2.1.x是一个经过精心设计、认真编写，具有较高可用性的分布式数据访问层，是综合数据代理(如MySQL Proxy)、名值对缓存(如Memcached)、集群等等思想而构建的一个软件

4、系统。Dal2.2.x是目前的最新系列，引入了很多新特性：如分布式事务，支持数据库主从等等。6关于Dal - 软件定位1) 不但具备了memcached和mysql proxy的优点，还避免了两者的缺点。2) Dal作为一个中间件，应保持语言中立、数据库中立。3) 让系统在数据访问层上具备分布式计算能力。4) 不造ORM轮子，只是发明访问数据的接口。 7关于Dal - 核心概念1) 透明分片透明，缓存透明，主从透明。2) 虚库(逻辑库)和实库(物理库)虚库：不是一个真正存在的库。也叫逻辑库。实库：是真实存在的库。也叫物理库。3) 虚表(逻辑表)和实表(物理表)虚表：不是一个真正存在的表。也叫逻

5、辑表。实表：是真实存在的表。也叫物理表。4) 分片(分表)分片可以分布在同一个库中，也可以在多个库中。也叫分表。8关于Dal - 核心概念(续)5) 映射虚库 实库;虚表 实表;应用列名 数据库列名;6) 条目缓存和查询缓存7) 辅助索引8) 分片情况：不分片、分片无辅助索引、分片有辅助索引9) 面向库的开发方式这是指，Dal自动从数据库获得需要的信息，而不是由应用开发人员在配置文件里显示配置。开发人员要配的只是分表的规则、连接池的使用、缓存的使用等。只在应用层需要和数据库不一样的信息时(如字段名)，才在配置文件里显式写出。9关于Dal - 核心概念(续)逻辑表A逻辑表B逻辑库物理表B_0物理

6、表B_1物理表B_2物理库物理库物理表A物理库辅助索引IDPID.列名idpid.列名10关于Dal - 设计指导思想Dal总体上设计成(Core + Plugins)的形式。Core负责一些不可插件化(或难以插件化)的组件，Plugins则是那些可插化的组件。我们定的是机制，提供的是策略；机制是软件目标和宗旨的体现，一般是不能轻易改变的，而策略则应当是能比较简单地进行切换的。那么，Core即机制，Plugins即策略。11Dal的产生12 Dal的产生 - 多数现有系统的经典问题1) 由于web server可以直接访问db server，在高峰阶段，并发量比较大，导致db server经常

7、down掉。2) 添加缓存代码以降低数据库访问压力，但由于开发人员自己控制缓存使得： a)缓存访问逻辑混杂在系统的各个角落，造成代码维护成本上升。 b)开发人员根据自己的喜好来控制缓存的KEY和VALUE，造成缓存混乱。 c)开发人员既要负责业务逻辑的编写，还要负责缓存管理，造成编程复杂度提高、开发效率低下。13 Dal的产生 - 多数现有系统的经典问题(续)3)在分表的情况下，程序员需要考虑和编写大量繁杂的和分表有关的代码： a)需要根据规则计算出数据的存取目标是在哪个分表当中。 b)如果取回的数据分布在不同的分表中，需要合并结果。 c)由于大表切分后变成了多个小的分表，对于有排序要求的查找

8、， 需要通过建立并查找辅助索引来解决。 d)如果一套分表有多个辅助索引，需要寻找最优辅助索引。14 Dal的产生 - Dal1.0应需而生HTTPMySQLMemcached存条目表现层逻辑层Dal1.0MyCached存id list及聚合运算结果15 Dal的产生 - Dal1.0的典型用法接口采用API Invocation+Call Chain的方式，所有的方法名取自SQL关键字，方便记忆。1)增：DataAccessor:insert()-table(imobile.post.db_post)-data(array(post_id=1, .)-dup()-execute();2)删：

9、DataAccessor:delete()-table(imobile.post.db_post)-where(post_id, IN, array(1, 2, 3)-limit(3)-execute();16 Dal的产生 - Dal1.0的典型用法(续)3)改：DataAccessor:update()-table(imobile.post.db_post)-data(array(level=0)-where(user_id, limit(100)-execute();4)查：DataAccessor:select()-table(imobile.post.db_post)-columns

10、(post_id)-where(array(thread_id=1, forum_id=2)-getAll();17Dal的产生 - Dal1.0的成效Dal1.0使得数据库的QPS从几千降到几百，缓存命中率稳定在60%80%之间。Dal1.0还标准化了调用接口，简化了编程，使程序员在业务逻辑层面不再关心缓存与分表问题，极大地提高了生产力。18Dal的产生 - Dal1.0的问题但是，Dal1.0仍然有很多不足： 1)Dal1.0直接和数据库打交道。 2)如果操作的数据分布在不同的分表中，为了提高性能，需要并行处理。但是PHP不好做到。 3)为了保证索引和分表数据的一致性，需要引入事务。但是D

11、al1.0没有。 4)Dal1.0直接针对MySQL编码，万一将来需要采用其它的数据库，怎么办？ 5)MyCached和Memcached在不同的进程，很多情况下需要两次请求才能组合出完整的数据。 6)如果需要支持其它的语言，怎么办？要弥补这些不足，必须从根本上进行重新设计。如果说Dal1.0是为易用性而设计，那么Dal2.x就是为性能、可用性等等而设计。19Dal的发展20Dal的发展 - Dal2.1.x大图MySQL Dal ServerJDBCOracle?JDBCJDBCJavaDal ClientPHPDal ClientPythonDal Client?Dal ClientDAL

12、PDALPDALPDALP缓存组件21Dal的发展 Dal Server2.1.x大图Monkey NIO Frameworkquery executorrouting strategyquery parsercache providerEvent listenerMySQLconn providerconfig managerbig queuedal handlerOracleDALP22Dal的发展 Dal2.1.x在手机之家系统中的位置应用消息队列服务M3搜索索引服务搜索更新客户端MySQL计划任务内置消息队列事件监听器Dal2.1.x调度器回调应用程序读取消息发送更新任务读写数据写消息

13、读写数据每分钟调一次23Dal的发展 Dal2.1.x/Dal1.0性能简单对比测试方法：每次涉及1个记录，循环10000次，每次涉及的记录都不相同。Dal2.1.xinsert: 8.22s, 8.2881560325623s, 8.29sdelete: 8.928288936615s, 8.4321990013123s, 8.8s update: 8.9594140052795s, 7.6687839031219s, 7.580326795578sselect: 7.9645628929138s, 3.65s, 3.21sDal1.0insert: 42.473783969879s, 43

14、.7s, 42.9sdelete: 25.484493017197s, 25.382812976837s, 25.41899895668supdate: 74.74593091011s, 74.557103872299s, 74.246424913406sselect: 14.9s, 9.7374119758606s, 6.5931770801544s24Dal的发展 Dal2.1.x/Dal1.0对比结果分析在增、删、改、查四类查询当中，Dal2.1.x都比Dal1.0有了很大的提升。原因在于：减少了一次socket请求、采用了异步消息处理机制、引入连接池及优化了算法等等。25Dal的发展

15、Dal2.1.x/Memcached简单性能对比测试方法Dal2.1.xMemcached1.4.2每次获取1个，循环10000次，每次获取的记录都不相同10.839928150177s(全部不命中的情况)3.55s3.13s3.31s1.9119760990143s1.85s1.8564429283142s1.82s每次获取10000个，执行1次，所有的记录都不相同。0.64966702461243s0.553s0.52798008918762s0.57868385314941s0.28920984268188s0.28875994682312s0.28748893737793s0.2767

16、1718597412s 26Dal的发展 Dal2.1.x/Memcached对比结果分析从时间消耗的数量级来看，Dal2.1.x和Memcached1.4.2属于同一个级别；从时间消耗的绝对值来看，Dal2.1.x还是有一定的差距。那么这1/31/2的时间消耗都花在哪了？主要是在协议解析及查询分析上。27Dal的发展 Dal2.1.x的成效以下是手机之家某个时刻4组Dal服务的缓存命中率统计快照：1)entryCacheHits = 1999443615(96.53%)entryCacheMisses = 71820652(3.47%)2)entryCacheHits = 728834651

17、(82.44%)entryCacheMisses = 155230407(17.56%)3)entryCacheHits = 717269426(93.35%)entryCacheMisses = 51101159(6.65%)4)entryCacheHits = 217927450(74.06%)entryCacheMisses = 76326220(25.94%)其中，2)组服务命中率低的原因是：上面跑的是论坛，全动态的，更新频繁；4)组服务命中率低的原因是：应用层又做了缓存了，到Dal的冷请求变多了。28Dal的发展 Dal2.1.x的问题1) Dal2.1.x采用的是内置缓存，而且存放

18、的数据结构也不好(大量的Map及字符串)，在缓存数据量大的情况下，JVM不堪重负，将进行频繁的GC。在高峰情况下，甚至会出现全GC，这时客户端connection timeout就频繁出现了。2) 不支持分布式事务。这使得在分片分布在多个库的情况下，数据的完整性得不到保证。而跨查询事务问题更是得不到解决。3) 不能简单的支持数据库主从。4) 缓存不能简单地进行外置。5) 不好在高峰时段进行配置Reload。6) 不管分不分片，都得写一大堆配置。7) 内置消息队列占用太多内存。8) 不能把dal作为嵌入式包来使用。29Dal的发展 Dal2.2.x大图Dal专用客户端DalServer#aCache#cCache#aDalServer#bDalServer#cDalServer#dCache#bCache#dDal2.2.x缓存集群数据库集群DB