﻿<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/"><channel><title>BlogJava-Salomon's Java Castle-随笔分类-OR Mapping V.S Performance</title><link>http://www.blogjava.net/leslie/category/1855.html</link><description>Not ready yet</description><language>zh-cn</language><lastBuildDate>Fri, 02 Mar 2007 06:52:38 GMT</lastBuildDate><pubDate>Fri, 02 Mar 2007 06:52:38 GMT</pubDate><ttl>60</ttl><item><title>OR Mapping(hibnerate)下的Performance问题</title><link>http://www.blogjava.net/Leslie/archive/2005/06/26/6715.html</link><dc:creator>Salomon</dc:creator><author>Salomon</author><pubDate>Sun, 26 Jun 2005 04:18:00 GMT</pubDate><guid>http://www.blogjava.net/Leslie/archive/2005/06/26/6715.html</guid><wfw:comment>http://www.blogjava.net/Leslie/comments/6715.html</wfw:comment><comments>http://www.blogjava.net/Leslie/archive/2005/06/26/6715.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.blogjava.net/Leslie/comments/commentRss/6715.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/Leslie/services/trackbacks/6715.html</trackback:ping><description><![CDATA[<P>其实标题起的太大，<FONT face=Arial>anyway, 实在是找不到合适的题目。<BR><BR>在OnV项目已经作了1年多了，有些感触，写下来以备以后整理之用。<BR>好死不死负责Report这里，逻辑既复杂，Performance的要求又非常之高，与通常easy to code的J2EE其他模块有很大的不同。<BR><BR>项目技术背景：<BR><STRONG>OR Mapping Tool:</STRONG><BR>Hibernate 2.0<BR><STRONG>Web tier:</STRONG><BR>Struts 1.2<BR>Report Tool:<BR><STRONG>Jasper Reports</STRONG><BR><BR>构架没什么好说的，唯一特殊的是由于需求的关系，是multiple database (features and users两个dimensions上的multiple)<BR><BR>几点重要的经验教训：<BR>1. Model Design一定要好，项目之初由于大家都比较缺乏经验，尤其是一些Model由刚毕业的fresh people来做，实在后果不堪设想。<BR>这里其实很推荐Martin的那本J2EE企业构架的书，也就是说OR Mapping的一些指导原则。<BR>key point：lazy loading很重要；model之间的关联尽可能是双向，即便由于有些原因不能增加Hibernate语法上的association（Object A中有Object B作为属性），那么最好也要有Objecd A中有一个ObjectBId，但相关联将给query 带来很大麻烦。 例如：如果需求有根据B的ID array去查询A，那么没有这种关系，则必须从Object B入手查询A，这就造成unnecessary的2个表join 查询，很耗费资源。<BR>2. 尽可能地Batch操作，例如Batch save和loop save的操作，性能上天差地别。<BR>3. 在类似Report的Query(意指查询条件复杂，数据量大)，<STRONG>是不应当粗粒度操作的</STRONG>。一直觉得J2EE的一个特点就是，简化developers的工作，面向对象，并且粗粒度。但是在这种性质的查询里，如果粗粒度，结果就会导致性能的灾难。其实这个是老调重弹，2002年左右我记得CSDN上就有人在诟病J2EE说性能如何的差。其实关键是developers是否估计到Use scenario对粒度的影响。简化developers的工作是有限度的，OR mapping的工作也并不是为了使没有经验中学生就能够很容易的写出好的Enterprise application。其实数据更新也有类似的问题，例如无法update specific 的attribute而不得不更新整个Object，这个时候性能的差异就会体现出来，只不过大多数情况下，Object不会大到让人无法接受，也不会像Report query那样request大量的数据，所以这方面性能的影响，在<STRONG>一些</STRONG>系统中不会体现出来。<BR><STRONG>合理划分Query的group，真实的目的是减少一次查询中Join表的个数。Hibernate2的缺陷也可以有所规避（不能任意指定Join的方式）</STRONG><BR>如前所述，Report query很大程度上被Object Model Design所制约<BR><BR>还有别的一些杂感，例如Hibernate不能support View，动态mapping，都对提高Performance所能采取的stratagy做了限制。不过这些东西似乎在hibernate3中有了支持，还没有时间用，不过已经让team里的一个member去research一下hibernate3的new feature<BR><BR></FONT></P><img src ="http://www.blogjava.net/Leslie/aggbug/6715.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/Leslie/" target="_blank">Salomon</a> 2005-06-26 12:18 <a href="http://www.blogjava.net/Leslie/archive/2005/06/26/6715.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item></channel></rss>