为什么ORM性能比iBATIS好.docVIP

缓存是有很多层次的，有web server前端缓存，有动态页面静态化，有页面片断缓存，有查询缓存，也有对象缓存。不同层面的缓存适用于不同的应用场景，作用也各自不同，如果可以，你全部一起用上，他们不矛盾，但这个话题比较大，现在不展开谈。 针对OLTP类型的web应用，只要代码写的质量没有问题，最终的性能瓶颈毫无疑问还是数据库查询。应用服务器层面可以水平扩展，但是数据库是单点的，很难水平扩展，所以如何有效降低数据库查询频率，减轻数据库压力，是web应用性能问题的根源。 以上所有的缓存方式都可以直接或者间接的降低数据库访问，但缓存是有应用场景的，虽然新闻网站非常适合使用动态页面静态化技术，但是例如电子商务网站就不适合动态页面静态化，而页面缓存和查询缓存可以使用的场景也不多。但是对象缓存是所有缓存技术当中适用场景最广泛的，任何OLTP应用，即使实时性要求很高，你也可以使用对象缓存，而且好的ORM实现，对象缓存是完全透明的，不需要你的程序代码进行硬编码。 用不用对象缓存，怎么用对象缓存，不是一个调优的技巧问题，而是整个应用的架构问题。在你开发一个应用之前，你就要想清楚，这个应用最终的场景是什么？会有多大的用户量和数据量。你将采用什么方式来架构这个应用： OK，也许你偏爱SQL，那么你选择iBATIS，数据库设计当中大表有很多冗余字段，会尽量消除大表之间的关联关系，最终用户量和访问量很高以后，你会选择使用Oracle，雇佣资深的DBA，进行数据库调优和SQL调优，这是大多数公司走的路。 但是我告诉你，你还有另外一条路可以走。你可以选择ORM(不见得一定是Hibernate)，数据库设计当中避免出现大表，比较多的表关联关系，通过ORM以对象化方式操作。当用户量和访问量很高以后，除了数据库端本身的优化，你还有对象缓存这条途径。对象缓存是怎样提高性能的呢？随便举个例子： 论坛的列表页面，需要显示topic的分页列表，topic作者的名字，topic最后回复帖子的作者，如果是iBATIS，你准备怎么做？ Sql代码 select?...?from?topic?left?join?user?left?join?post?.....?? select ... from topic left join user left join post ..... 你需要通过join user表来取得topic作者的名字，然后你还需要join post表取得最后回复的帖子，post再join user表取得最后回贴作者名字。 也许你说，我可以设计表冗余，在topic里面增加username，在post里面增加username，所以通过大表冗余字段，消除了复杂的表关联： Sql代码 select?...?from?topic?left?join?post...?? select ... from topic left join post... OK，且不说冗余字段的维护问题，现在仍然是两张大表的关联查询。然后让我们看看ORM怎么做？ Sql代码 select?*?from?topic?where?...?--分页条件??select * from topic where ... --分页条件 就这么一条SQL搞定，比上面的关联查询对数据库的压力小多了。 也许你说，不对阿，作者信息呢？回贴作者信息呢？这些难道不会发送SQL吗？如果发送SQL，这不就是臭名昭著的n+1条问题吗？ 你说的对，最坏情况下，会有很多条SQL： Sql代码 select?*?from?user?where?id?=?topic_id...; ?? .... ?? select?*?from?user?where?id?=?topic_id...; ?? ?? select?*?from?post?where?id?=?last_topic_id...; ?? .... ?? select?*?from?post?where?id?=?last_topic_id...; ?? ?? select?*?from?user?where?id?=?post_id...; ?? .... ?? select?*?from?user?where?id?=?post_id...;?? select * from user where id = topic_id...; .... select * from user where id = topic_id...; select * from post where id = last_topic_id...; .... select * from post where id = last_topic_id...;