技术选型带来的困扰

公司接到一个ERP系统改造的项目，数据库采用原有的AS400上的DB2 5.4。数据量巨大，大约有30年的历史了，而且表之间没有关联关系。由于本人技术能力有限，所以在技术选型时感到很迷茫。迷茫的原因是一方面要考虑到系统性能问题，另一方面还要考虑开发的难易程度和系统健壮性，等等一系列问题。
我将目前比较流行的技术方案分别做了一个demo，并且以查询10万条数据为标准做性能测试。结果如下：

方案名称                第一次执行耗时 第二次执行耗时 第三次执行耗时
Struts+Jdbc                 2192ms 1315ms 1299ms
Struts+Spring(JdbcTemplate) 2335ms 1317ms 1299ms
Struts+Ibatis                 3081ms 1525ms 1458ms
Struts+Spring+ibatis         4172ms 2969ms 2938ms
Struts+Hibernate    Java.lang.OutOfMemoryError: Java heap space

测试方法是在Action中调用DAO中的方法，在调用方法前和返回数据后，打印当前时间来计算查询所耗费的时间。
开始的时候想采用Struts+Spring+ibatis这个方案，但是通过测试后，发现这个方案的耗时要比采用Struts+Spring(JdbcTemplate)高出将近2秒。Struts+Spring(JdbcTemplate)在性能上占有一定的优势，可是在编写代码上总是给人一种不太舒服的感觉，代码如下：
public List<Employee> getEmployeeList() {
  
// TODO Auto-generated method stub
String sql = "select * from employee where id<?;";

return jdbcTemplate.query(sql, new Object[]{100000}, new RowMapper(){
public Object mapRow(ResultSet rs,int index)throws SQLException{
Employee employee = new Employee();
employee.setId(rs.getInt("id"));
employee.setDempId(rs.getInt("emp_id"));
employee.setEmpId(rs.getInt("dept_id"));
employee.setFirstName(rs.getString("first_name"));
employee.setLastName(rs.getString("last_name"));
employee.setJobCat(rs.getString("job_cat"));
employee.setSalary(rs.getInt("salary"));

return employee;

}


});


}
可能一直使用Hibernate的原因吧，总感觉这段代码不太舒服。而且Spring(JdbcTemplate)没有提供分页功能，实现起来比较麻烦。
希望各位高手能给在下一些建议？谢谢先！



2008/05/07补充：
由于昨天没机会看帖子，今天刚回来就看到这篇帖子已经出现在了首页。
激动之余发表两点感谢：
1.狂谢热心参与本次讨论的各位朋友们，小弟将会把最终的项目案例与大家分享，希望能为中国软件事业的崛起贡献微薄之力。
2.感谢javaeye提供了这样好的交流平台，希望今后越做越好。

评论

46 楼 birdjavaeye 2008-05-08  

zq0459 写道

2.使用struts+hiberntate查询时，将返回值装配到List中抛出Java.lang.OutOfMemoryError: Java heap space。（测试数据库postgreSQL8）
查询代码如下：
public List<Employee> selectAllEmployee() {
// TODO Auto-generated method stub
Session session = null;
List<Employee> list = new ArrayList<Employee>();
try {
session = HibernateUtil.currentSession();
Query query = session.createQuery("from Employee ");
list = (List<Employee>) query.list();
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
System.out.println("<<-------------" + e.toString());
}

return list;
}

你的 Employee是怎么定义的？贴出相关的 annotation 和 hbm.xml 看看
也许是 Employee关联了许多其他类，但没有lazy读取

45 楼 icewubin 2008-05-06  

HenryYu 写道

icewubin 写道

neora 写道

以我的经验谈谈我的个人看法:
1、首先，积累了30年的数据库数据量想必大得惊人。如果你的应用需要频繁的查询数千万的数据，那么必须在适当的地方采用存储过程来表现业务逻辑，尽量利用数据库自身的能力来完成复合的数据查找、比较和筛选。商用数据库本身在这方面的处理是非常强劲而稳定的。其数据处理能力是Java虚拟机所无法比拟的（无论你用任何框架，写出任何出色的代码）。
2、尽量保持由存储过程处理完毕后的数据量在较小的范围内，缩减到“数万”这个级别，然后再交给Java虚拟机来完成其他的业务逻辑。
3、你觉得参杂了存储过程会让你们的代码不够OO，但这样的程序稳定性会高出许多。
4、完全采用Hibernate这种小玩意儿来做海量规模的数据处理绝对是下下策，我见过的所有完全采用Hibernate的电信级计费系统无一例外都是失败案例。至少在可靠性和鲁棒性上极其脆弱。我所经历的基于存储过程的案例几乎都是非常成功的。
5、我不是说Hibernate不好，事实上它在做Web应用中非常非常出色。但不适合将所有的数据逻辑都交给它。把很“搞人脑袋”的逻辑交给Hibernate,把很“搞CPU”的交给存储过程。
6、使用Hibernate的时候，切忌此类简单用法：将要处理的数据全部从数据库中以Active状态捞到JVM，指望让JVM来完成所有工作。有时候，你一不小心，就会这么做。
7、方案，存储过程+Hibernate

个人看法。

1、如果原来有存储过程，就善加利用，如果没有说明这个系统数据量不够真正的大。
2、业务需求不明，即使超过万仍然是有办法的，但是需求要给出才能评估。
3、OO和稳定性没有矛盾之处，存储过程一样容易出bug。OO的代码不稳定也是一种bug，没有本质区别。
4、Hibernate是小玩意儿，那是你不知道使用技巧，适用范围不是看数据量大小的，是要看需求的，比如是否需要实时生成新的表。
5、Hibernate要用得好，sql一定也很好，不可能完全交给Hibernate的，必须要清楚任何状态下生成的sql的大致形态。
6、其他框架也有类似问题，只是不那么容易内存溢出而已，其实是数据结构的基础问题。
7、可以考虑，如果原来没有存储过程的话，需求中又有类似电信计费这种，你又熟悉存储过程的话，建议如此。

两位观点并不矛盾，只是设计策略和出发点不同。问题症结就在于究竟是OO对象模型还是数据关系模型为驱动设计的问题。从OO出发，采取hibernate等O/R映射框架会很顺手；从数据关系出发，jdbc存取（或一定的存储过程）会更加直接高效。不过，根据我经验来看，我个人偏重从数据关系出发来解决问题，采取jdbc+dao解决方案，我始终认为在当前相当长的一段时间内O/R映射解决方案都不是企业应用持久层开发的合适技术，这是因为制约各种O/R映射技术发展的根本原因不是各种编程技术的不成熟，而正是各种成熟的关系模型的数据库。关系模型的目标是如何合理、简便、快速地存取数据，而不是按照面向对象的思想建立的实体模型来存取数据的，这就是这两种思想的差别所在，也是决定了O/R映射技术不能面面俱到解决所有关系模型问题的根本命运。关系数据库理论经历数10年发展已经是一个十分成熟理论，经得起考验，所以短时间内出现一个成熟的面向对象的实体型数据库是不太可能的。也许，到了哪一天，我们的数据存取就可以完全面向对象了，也不用搞什么O/R映射了。

在我的大脑中，hibernate就是一个sql生成器+缓存机制，不存在什么OO的概念，OO我觉得就是代码可读性高，代码量少能使bug减少，提供编译期检查，利用IDE的重构功能，如此而已，hibernate生成sql的能力大家都是知道的，但是hibernate抓取数据并封装到自定义对象或者是map的能力很多人是不清楚的，其实也是超强的。所以不认为hibernate有什么太大的性能问题，就是精通的学习成本较高。
比如，可以有取舍么，比如级联这种很容易性能失控的东西就可以不用，适当的倒退，把Hibernate当成是sql生成器来用思路就会清楚很多，对象图的获取和遍历的合理性都能精确的控制，这是其他框架不如hibernate的地方。OO特性太空泛了，没有什么具体的价值，好比OO还不是由很多段面向过程的语句合成的，写代码就是代码如何组织，业务逻辑处在什么位置的问题。

44 楼 lgx522 2008-05-06  

三条路：

1、重新设计DB并迁移数据，一定要符合范式，这样才会配得上OO。在此前提下，使用强制OO的Spring、Hibernate、Ibatis、Struts等等才有价值。
2、如果难以迁移DB，继续sql和存储过程，不要用什么framework，就用jdbc、Servlet和JSP。
3、如果系统是以写为主，界面交互复杂，建议老兄不要赶髦，老老实实用VB或者Delphi写C/S。

千万不要为了OO而OO，为了Java而Java，为了Spring而Spring。

43 楼 天下有鹏 2008-05-06  

lz数据迁移是否用etl工具？

42 楼 HenryYu 2008-05-06  

icewubin 写道

neora 写道

以我的经验谈谈我的个人看法:
1、首先，积累了30年的数据库数据量想必大得惊人。如果你的应用需要频繁的查询数千万的数据，那么必须在适当的地方采用存储过程来表现业务逻辑，尽量利用数据库自身的能力来完成复合的数据查找、比较和筛选。商用数据库本身在这方面的处理是非常强劲而稳定的。其数据处理能力是Java虚拟机所无法比拟的（无论你用任何框架，写出任何出色的代码）。
2、尽量保持由存储过程处理完毕后的数据量在较小的范围内，缩减到“数万”这个级别，然后再交给Java虚拟机来完成其他的业务逻辑。
3、你觉得参杂了存储过程会让你们的代码不够OO，但这样的程序稳定性会高出许多。
4、完全采用Hibernate这种小玩意儿来做海量规模的数据处理绝对是下下策，我见过的所有完全采用Hibernate的电信级计费系统无一例外都是失败案例。至少在可靠性和鲁棒性上极其脆弱。我所经历的基于存储过程的案例几乎都是非常成功的。
5、我不是说Hibernate不好，事实上它在做Web应用中非常非常出色。但不适合将所有的数据逻辑都交给它。把很“搞人脑袋”的逻辑交给Hibernate,把很“搞CPU”的交给存储过程。
6、使用Hibernate的时候，切忌此类简单用法：将要处理的数据全部从数据库中以Active状态捞到JVM，指望让JVM来完成所有工作。有时候，你一不小心，就会这么做。
7、方案，存储过程+Hibernate

个人看法。

1、如果原来有存储过程，就善加利用，如果没有说明这个系统数据量不够真正的大。
2、业务需求不明，即使超过万仍然是有办法的，但是需求要给出才能评估。
3、OO和稳定性没有矛盾之处，存储过程一样容易出bug。OO的代码不稳定也是一种bug，没有本质区别。
4、Hibernate是小玩意儿，那是你不知道使用技巧，适用范围不是看数据量大小的，是要看需求的，比如是否需要实时生成新的表。
5、Hibernate要用得好，sql一定也很好，不可能完全交给Hibernate的，必须要清楚任何状态下生成的sql的大致形态。
6、其他框架也有类似问题，只是不那么容易内存溢出而已，其实是数据结构的基础问题。
7、可以考虑，如果原来没有存储过程的话，需求中又有类似电信计费这种，你又熟悉存储过程的话，建议如此。

两位观点并不矛盾，只是设计策略和出发点不同。问题症结就在于究竟是OO对象模型还是数据关系模型为驱动设计的问题。从OO出发，采取hibernate等O/R映射框架会很顺手；从数据关系出发，jdbc存取（或一定的存储过程）会更加直接高效。不过，根据我经验来看，我个人偏重从数据关系出发来解决问题，采取jdbc+dao解决方案，我始终认为在当前相当长的一段时间内O/R映射解决方案都不是企业应用持久层开发的合适技术，这是因为制约各种O/R映射技术发展的根本原因不是各种编程技术的不成熟，而正是各种成熟的关系模型的数据库。关系模型的目标是如何合理、简便、快速地存取数据，而不是按照面向对象的思想建立的实体模型来存取数据的，这就是这两种思想的差别所在，也是决定了O/R映射技术不能面面俱到解决所有关系模型问题的根本命运。关系数据库理论经历数10年发展已经是一个十分成熟理论，经得起考验，所以短时间内出现一个成熟的面向对象的实体型数据库是不太可能的。也许，到了哪一天，我们的数据存取就可以完全面向对象了，也不用搞什么O/R映射了。

41 楼 tedeyang 2008-05-06  

同意楼上godlikeme、coolzyt的看法，
jdbc、ibatis、jdbctemplate、hibernate我都使用过很久。现在用的是我们自己写的基于jdbctemplate的sqlmap框架（主要增加了惯例、再写个代码生成工具、加上一堆辅助API、稍微做点数据库兼容改造）——也是因为jdbctemplate写起代码来太啰嗦了。

我的个人经验：从性能的角度出发，这些技术都不会存在问题，足以应对百万级的性能要求了。
如果楼主对sql很精通，那就用ibatis，如果对OOP很精通，那就用hibernate。
都是很成熟的玩意，除了问题也容易解决。

至于为什么ibatis+spring会比纯ibatis慢这么多，实在是很奇怪！我认为这里面必然有性能调整空间。spring仅仅提供session、DAO层而已，而理论上（实际应用也是）ibatis比jdbc就多了一点点自动映射操作，随着jdk的发展这个性能损失越来越小，应该不会导致这么大的差距。

40 楼 csrcom 2008-05-06  

其实我觉得这些不单单是技术选型问题了。

如果数据库单表里面超过了10亿级别以上的数据，你该如何处理？

传统的这种单台数据库结构到最后都存在瓶颈，有钱的公司可以用小型机、大型机器，超大的内存..没钱的公司怎么办？

不是技术选型，更应该是寻找解决这些业务需求的方案。你的方案会支撑未来日益增长的数据多少年？

39 楼 icewubin 2008-05-06  

neora 写道

以我的经验谈谈我的个人看法:
1、首先，积累了30年的数据库数据量想必大得惊人。如果你的应用需要频繁的查询数千万的数据，那么必须在适当的地方采用存储过程来表现业务逻辑，尽量利用数据库自身的能力来完成复合的数据查找、比较和筛选。商用数据库本身在这方面的处理是非常强劲而稳定的。其数据处理能力是Java虚拟机所无法比拟的（无论你用任何框架，写出任何出色的代码）。
2、尽量保持由存储过程处理完毕后的数据量在较小的范围内，缩减到“数万”这个级别，然后再交给Java虚拟机来完成其他的业务逻辑。
3、你觉得参杂了存储过程会让你们的代码不够OO，但这样的程序稳定性会高出许多。
4、完全采用Hibernate这种小玩意儿来做海量规模的数据处理绝对是下下策，我见过的所有完全采用Hibernate的电信级计费系统无一例外都是失败案例。至少在可靠性和鲁棒性上极其脆弱。我所经历的基于存储过程的案例几乎都是非常成功的。
5、我不是说Hibernate不好，事实上它在做Web应用中非常非常出色。但不适合将所有的数据逻辑都交给它。把很“搞人脑袋”的逻辑交给Hibernate,把很“搞CPU”的交给存储过程。
6、使用Hibernate的时候，切忌此类简单用法：将要处理的数据全部从数据库中以Active状态捞到JVM，指望让JVM来完成所有工作。有时候，你一不小心，就会这么做。
7、方案，存储过程+Hibernate

个人看法。

1、如果原来有存储过程，就善加利用，如果没有说明这个系统数据量不够真正的大。
2、业务需求不明，即使超过万仍然是有办法的，但是需求要给出才能评估。
3、OO和稳定性没有矛盾之处，存储过程一样容易出bug。OO的代码不稳定也是一种bug，没有本质区别。
4、Hibernate是小玩意儿，那是你不知道使用技巧，适用范围不是看数据量大小的，是要看需求的，比如是否需要实时生成新的表。
5、Hibernate要用得好，sql一定也很好，不可能完全交给Hibernate的，必须要清楚任何状态下生成的sql的大致形态。
6、其他框架也有类似问题，只是不那么容易内存溢出而已，其实是数据结构的基础问题。
7、可以考虑，如果原来没有存储过程的话，需求中又有类似电信计费这种，你又熟悉存储过程的话，建议如此。

38 楼 icewubin 2008-05-06  

zq0459 写道

1.原有系统大约有200多张表，冗余表很多。在抽象数据模型时，我在考虑一部分采用原有的数据模型，另一部分将根据业务需要自己创建数据模型。
2.使用struts+hiberntate查询时，将返回值装配到List中抛出Java.lang.OutOfMemoryError: Java heap space。（测试数据库postgreSQL8）
查询代码如下：
public List<Employee> selectAllEmployee() {
// TODO Auto-generated method stub
Session session = null;
List<Employee> list = new ArrayList<Employee>();
try {
session = HibernateUtil.currentSession();
Query query = session.createQuery("from Employee ");
list = (List<Employee>) query.list();
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
System.out.println("<<-------------" + e.toString());
}

return list;
}

1.内存溢出，先看JVM是不是设得太小了，建议256-1500MB，Hibernate一级缓存放不下了。
2.10万条数据全取的hibernate不是这么写的，如果楼主对Hibernate再花点时间看看书，夏昕的《深入浅出Hibernate》推荐，如果要上JDK1.5，再看一本Hibernate实战第2版（翻译得不太好，入门的人不要看）。
10万条数据你需要一次性取出么？设计需求就有问题吧，应该加分页条件的吧，不加分页条件有什么实际价值？
如果一定要取出，一定要给出需求，我给你方案。
3.Hibernate对SQL的支持我认为比iBatis好，还是看你Hibernate功力如何，ORM善加利用，开发效率和执行效率都是超过其他方案的，存储过程不算，存储过程要单独讨论的。如果是10万条记录的库以上这些框架根本不是问题，又不是100亿条数据。

37 楼 gysh 2008-05-06  

neora 写道

以我的经验谈谈我的个人看法:
1、首先，积累了30年的数据库数据量想必大得惊人。如果你的应用需要频繁的查询数千万的数据，那么必须在适当的地方采用存储过程来表现业务逻辑，尽量利用数据库自身的能力来完成复合的数据查找、比较和筛选。商用数据库本身在这方面的处理是非常强劲而稳定的。其数据处理能力是Java虚拟机所无法比拟的（无论你用任何框架，写出任何出色的代码）。
2、尽量保持由存储过程处理完毕后的数据量在较小的范围内，缩减到“数万”这个级别，然后再交给Java虚拟机来完成其他的业务逻辑。
3、你觉得参杂了存储过程会让你们的代码不够OO，但这样的程序稳定性会高出许多。
4、完全采用Hibernate这种小玩意儿来做海量规模的数据处理绝对是下下策，我见过的所有完全采用Hibernate的电信级计费系统无一例外都是失败案例。至少在可靠性和鲁棒性上极其脆弱。我所经历的基于存储过程的案例几乎都是非常成功的。
5、我不是说Hibernate不好，事实上它在做Web应用中非常非常出色。但不适合将所有的数据逻辑都交给它。把很“搞人脑袋”的逻辑交给Hibernate,把很“搞CPU”的交给存储过程。
6、使用Hibernate的时候，切忌此类简单用法：将要处理的数据全部从数据库中以Active状态捞到JVM，指望让JVM来完成所有工作。有时候，你一不小心，就会这么做。
7、方案，存储过程+Hibernate

个人看法。

赞同你的想法！！对数据库进行复杂的查询，用存储过程，性能会有提高！毕竟商家的数据库性能想对我们的程序来说很稳定，很有效率的！！交给数据库处理能提高效率！！至于存储过程我个人经验告诉我！！采用Ibatis还是比较优秀的！！

36 楼 wolfbrood 2008-05-06  

<div class='quote_title'>neora 写道</div>
<div class='quote_div'>以我的经验谈谈我的个人看法: <br/>1、首先，积累了30年的数据库数据量想必大得惊人。如果你的应用需要频繁的查询数千万的数据，那么必须在适当的地方采用存储过程来表现业务逻辑，尽量利用数据库自身的能力来完成复合的数据查找、比较和筛选。商用数据库本身在这方面的处理是非常强劲而稳定的。其数据处理能力是Java虚拟机所无法比拟的（无论你用任何框架，写出任何出色的代码）。 <br/>2、尽量保持由存储过程处理完毕后的数据量在较小的范围内，缩减到“数万”这个级别，然后再交给Java虚拟机来完成其他的业务逻辑。 <br/>3、你觉得参杂了存储过程会让你们的代码不够OO，但这样的程序稳定性会高出许多。 <br/>4、完全采用Hibernate这种小玩意儿来做海量规模的数据处理绝对是下下策，我见过的所有完全采用Hibernate的电信级计费系统无一例外都是失败案例。至少在可靠性和鲁棒性上极其脆弱。我所经历的基于存储过程的案例几乎都是非常成功的。 <br/>5、我不是说Hibernate不好，事实上它在做Web应用中非常非常出色。但不适合将所有的数据逻辑都交给它。把很“搞人脑袋”的逻辑交给Hibernate,把很“搞CPU”的交给存储过程。 <br/>6、使用Hibernate的时候，切忌此类简单用法：将要处理的数据全部从数据库中以Active状态捞到JVM，指望让JVM来完成所有工作。有时候，你一不小心，就会这么做。 <br/>7、方案，存储过程+Hibernate <br/><br/>个人看法。</div>
<p> </p>
<p> 赞成楼上观点。</p>
<p>尽量使用数据库的特性完成任务，而不是jvm。如果想用jvm来做大批量数据筛选是不可取的，会生成很多对象，到时jvm回收的时候也麻烦，还是引起频繁的回收。没必要非要把程序设计成多平台（操作系统和数据库）可移植，说白了那是一种骗人的东西，我们只能往上面靠拢，如果数据库提供了好的解决方案还是建议用数据库的功能。 对于大的项目不太可能会考虑数据库移植的，一般都会一直使用一家公司的数据库。</p>
<p> </p>

35 楼 wolfbrood 2008-05-06  

如果你要出报表，比如要写很复杂的sql，我建议你这部分不要用hibernate之类，还是用jdbc比较好，自己好控制。或者你也可以再建立辅助表，写job做预处理，然后再从处理一遍的结果中查找数据。比如一些统计的数据可以做预处理，每天处理一次，存在一个表里面，出报表的时候就从这里面查找数据。


对于数据量大的表预处理很重要很重要，sql优化很重要。

34 楼 wolfbrood 2008-05-06  

以前我也做过数据库的开发，银行的项目，数据量也非常之大。下面给你几个建议，仅供参考：
1.申请能不能整理数据，把一些历史数据移到别的地方，如果不能整理数据就算了
2.优化表结构，如果不能修改表的字段，那么至少要能创建索引，关键字之类的。
3.把表分类处理，比如一些表经常要修改，数据量很大，而一些表修改不是很大，这类表可以想办法缓存数据到内存中，没必要在查询的时候做连接
4.你说的那几个组合都无所谓，这些组合都能满足你的要求。重要的是你要设计好你的程序，对于数据量大的表做查询的时候一定要走索引，我以前做过3000万级别的表查询，oracle数据库，走索引的时候查询也很快，对于10万条左右的表查询，如果是单表，即使不用索引也会很快。建议你还是走索引。
5.sql一定要优化，具体优化先看你是什么数据库，然后查找相应的方法优化。

33 楼 sofar1218 2008-05-06  

<div class='quote_title'>allenwang 写道</div>
<div class='quote_div'>从DB2向Oracle迁移？如果这样的话，建议数据持久化用Hibernate，统计等大数据操作可以使用PL/SQL,速度要快很多。当然，如果你非要考虑数据库的可移植性等等问题，那么PL/SQL可能并不适合你</div>
<p>
迁移的同时也要整合，否则没意义。好不容易来一次凤凰涅槃。</p>
<p>既然你的程序也要重写，就重新设计ER模型，包括业务模型的梳理， 老数据的价值一是引用（基础数据），一是分析。</p>
<p>所以<span style='color: #ff00ff;'><span style='font-size: small;'>ETL</span></span> 是必要的</p>

32 楼 Godlikeme 2008-05-06  

neora 写道

以我的经验谈谈我的个人看法:
1、首先，积累了30年的数据库数据量想必大得惊人。如果你的应用需要频繁的查询数千万的数据，那么必须在适当的地方采用存储过程来表现业务逻辑，尽量利用数据库自身的能力来完成复合的数据查找、比较和筛选。商用数据库本身在这方面的处理是非常强劲而稳定的。其数据处理能力是Java虚拟机所无法比拟的（无论你用任何框架，写出任何出色的代码）。
2、尽量保持由存储过程处理完毕后的数据量在较小的范围内，缩减到“数万”这个级别，然后再交给Java虚拟机来完成其他的业务逻辑。
3、你觉得参杂了存储过程会让你们的代码不够OO，但这样的程序稳定性会高出许多。
4、完全采用Hibernate这种小玩意儿来做海量规模的数据处理绝对是下下策，我见过的所有完全采用Hibernate的电信级计费系统无一例外都是失败案例。至少在可靠性和鲁棒性上极其脆弱。我所经历的基于存储过程的案例几乎都是非常成功的。
5、我不是说Hibernate不好，事实上它在做Web应用中非常非常出色。但不适合将所有的数据逻辑都交给它。把很“搞人脑袋”的逻辑交给Hibernate,把很“搞CPU”的交给存储过程。
6、使用Hibernate的时候，切忌此类简单用法：将要处理的数据全部从数据库中以Active状态捞到JVM，指望让JVM来完成所有工作。有时候，你一不小心，就会这么做。
7、方案，存储过程+Hibernate

个人看法。

大部分赞同你的观点，
第5，6点也不是不可以，只是对开发人员的要求很高，也要看具体情况。
不是所有的批量数据处理都必须是存储过程，用hibernate一样可以做，关键点在于批量处理是否可以拆分为单笔处理。

比较流行的观点认为hibernate比较适合做 联机交易处理，存储过程比较适合做 联机分析处理，但其中有交叉之处，不那么绝对。

对于第4点，对电信计费知道点皮毛，计费有很强的实时性要求，对处理速度要求比较高，而且不会缓存，且数据模型不OO，不适合用Hibernate，而不仅仅是因为海量数据（一般一次处理几十万，百万吧），全用hibernate不现实。

31 楼 drinkjava 2008-05-06  

zq0459 写道

如果持久化层使用Spring（JdbcTemplate），那么分页功能的实现依赖于数据库吗？也就是说目前采用的是DB2，以后要移植到ORACLE，分页功能需要改吗？

真是死脑筋，转个弯都不会。持久化层用Spring（JdbcTemplate)，用Hibernate来专做分页不就行了? Hibernate即然号称分页很强，跨数据库,那很好，那就让它来专干这个好了,(当然不用它的缓存了) 。
至于做法可参见本文http://www.iteye.com/post/293393，由工具自动生成遗留数据库的配置，忽略对象间的关联。本来嘛，遗留数据库也没有对象关联这一说。

30 楼 neora 2008-05-05  

以我的经验谈谈我的个人看法:
1、首先，积累了30年的数据库数据量想必大得惊人。如果你的应用需要频繁的查询数千万的数据，那么必须在适当的地方采用存储过程来表现业务逻辑，尽量利用数据库自身的能力来完成复合的数据查找、比较和筛选。商用数据库本身在这方面的处理是非常强劲而稳定的。其数据处理能力是Java虚拟机所无法比拟的（无论你用任何框架，写出任何出色的代码）。
2、尽量保持由存储过程处理完毕后的数据量在较小的范围内，缩减到“数万”这个级别，然后再交给Java虚拟机来完成其他的业务逻辑。
3、你觉得参杂了存储过程会让你们的代码不够OO，但这样的程序稳定性会高出许多。
4、完全采用Hibernate这种小玩意儿来做海量规模的数据处理绝对是下下策，我见过的所有完全采用Hibernate的电信级计费系统无一例外都是失败案例。至少在可靠性和鲁棒性上极其脆弱。我所经历的基于存储过程的案例几乎都是非常成功的。
5、我不是说Hibernate不好，事实上它在做Web应用中非常非常出色。但不适合将所有的数据逻辑都交给它。把很“搞人脑袋”的逻辑交给Hibernate,把很“搞CPU”的交给存储过程。
6、使用Hibernate的时候，切忌此类简单用法：将要处理的数据全部从数据库中以Active状态捞到JVM，指望让JVM来完成所有工作。有时候，你一不小心，就会这么做。
7、方案，存储过程+Hibernate

个人看法。

29 楼 coolzyt 2008-05-05  

建议分页再进行测试
不过大数据量分页还是用sql分页比较好，ibatis好像是取出来以后再sublist的

28 楼 Godlikeme 2008-05-05  

yuankai 写道

Godlikeme 写道

AX400？ AS400？
用10万条来做性能测试，靠谱么？是不是数据量太小了点。至少要百万往上吧。
不太明白为什么struts+hibernate会outof memory, 10万条都取出来也没多少内容。>100M?
这么点数据查询就这么慢，数据库有问题吧，或者代码逻辑有问题。

我觉得有几方面比较关键，
新的数据模型如何能够兼容旧模型又能满足业务要求。
数据如何移植，从旧数据模型映射到新数据模型中。
关键数据 数据量有多大。

我原来用Spring+hibernate也就碰到过outof memory问题，这个主要是没有分页导致的。
一次性取10W条记录不使用分页肯定会出问题的。

会不会outof memory由数据量大小而定，
以lz所说employee表，暂定单条记录为1k，（一般系统的主信息档也不过这个量级），10w记录大约在100M。预估Hibernate使用的内存容量<120M。

这是我说不太明白内存会溢出的原因。

从后面的代码可以看出，lz用不同技术的查询条件是不一样的，这样带来的问题是不具有可比性。
在我看来这样的性能比较，无论从数据量，还是从对比的实现上看参考意义都不大。
建议还是更多的在数据模型基本建立，数据移植方案明确的情况下再对比不同技术的技术风险。

27 楼 Joo 2008-05-05  

dearmite 写道

这坛子上关于JAVA虚拟机的高手，实在太多，
我就不好发表这方面的意见了。

只是我以前跟踪调试过这样的东西。

感觉JVM高手这里的确多 呵呵 但是往往接着问个问题就甩一句google...其实很多时候我在提问前google过好半天了
就是因为找不到满意的资料才上JE问得 结果屡次被B4...-_-
能不能说说怎么跟踪到JVM里面去?