[转帖]JDBC与Hibernate读取性能

本文对比了JDBC与Hibernate在不同场景下的读取性能。结果显示JDBC在精心编写的情况下性能最佳,而Hibernate的List和Iterator各有优势。List适用于需要多次操作结果集的场景,Iterator则适用于仅需一次遍历或从大数据集中获取少量数据的情况。
JDBC与Hibernate读取性能

1、JDBC仍然是最快的访问方式,不论是Create还是Read操作,都是JDBC快。

2、Hibernate使用uuid.hex构造主键,性能稍微有点损失,但是不大。

3、Create操作,JDBC在使用批处理的方式下速度比Hibernate快,使用批处理方式耗用JVM内存比不使用批处理方式要多得多。

4、读取数据,Hibernate的Iterator速度非常缓慢,因为他是每次next的时候才去数据库取数据,这一点从观察任务管理器的java进程占用内存的变化也可以看得很清楚,内存是几十K几十K的增加。

5、读取数据,Hibernate的List速度很快,因为他是一次性把数据取完,这一点从观察任务管理器的java进程占用内存的变化也可以看得很清楚,内存几乎是10M的10M的增加。

6、JDBC读取数据的方式和Hibernate的List方式是一样的(这跟JDBC驱动有很大关系,不同的JDBC驱动,结果会很不一样),这从观察java进程内存变化可以判断出来,由于JDBC不需要像Hibernate那样构造一堆Cat对象实例,所以占用JVM内存要比Hibernate的List方式大概少一半左右。

7、Hibernate的Iterator方式并非一无是处,它适合于从大的结果集中选取少量的数据,即不需要占用很多内存,又可以迅速得到结果。另外Iterator适合于使用JCS缓冲。
最终结论:
由于MySQL的JDBC驱动的重大缺陷,使得测试结果变得毫无意义,不具备任何参考价值,只是我们能够大概判断出一些结论:
一、精心编写的JDBC无论如何都是最快的。
二、Hibernate List和Iterator适用的场合不同,不存在孰优孰劣的问题

我个人认为Hibernate Iterator是JDBC Result的封装,Hibernate List是Scrollable Result的封装,所以我推测,如果在Oracle或者DB2上面做同样的Read测试,如果结果集小于FetchSize,4者在速度上应该都不会有差别;如果结果集大于FetchSize的话,但是不是FetchSize的很多倍,速度排名应该是:
JDBC Scrollable Result (消耗时间最少) < Hibernate List < JDBC Result < Hibernate Iterator

如果结果集非常大,但是只取结果集中的部分记录,那么速度排名:
JDBC Result < Hibernate Iterator < JDBC Scrollable Result < Hibernate List


为了避免造成误导,我最后强调一下我的结论:

一、“精心编写”的JDBC一定是性能最好的

实际上,不管CMP,Hibernate,JDO等等,所有的ORM都是对JDBC的封装,CMP则是一个重量级封装,JDO中度封装,Hibernate是轻量级的封装。从理论上来说,ORM永远也不可能比JDBC性能好。就像任何高级语言的运行性能永远也不会好过汇编语言一个道理。

对于Create和Update操作来说,由于普通的Java程序员未必会使用JDBC的Batch的功能,所以Hibernate会表现出超过JDBC的运行速度。

对于Read的操作来说,ORM普遍都会带有双层缓冲,即PrepreadStatement缓冲和ResultSet缓冲,而JDBC本身没有缓冲机制,在使用连接池的情况下,一些连接池将会提供PrepreadStatement缓冲,有的甚至提供ResultSet缓冲,但是普遍情况下,Java程序员一般都不会考虑到在写JDBC的时候优化缓冲,而且这样做也不太现实,所以在某些情况下,ORM会表现出超过JDBC的Read速度。


二、Hibernate List和Iterator方式的比较

这是我在测试中想要重点考察的方面,但是由于JDBC驱动问题,结果变的很不可信,不过仍然可以得到一些有用的结论。

Read操作包括两步:第一步是把数据库的数据取出,构造结果集,把数据放入到结果集中;第二步是遍历结果集,取每行数据。

List方式是1次性把所有的数据全部取到内存中,构造一个超大的结果集,主要的时间开销是这一步,这一步的时间开销要远远超过JDBC和Iterator方式下构造结果集的时间开销,并且内存开销也很惊人;而对结果集的遍历操作,速度则是非常的惊人(从上面的测试结果来看,30万记录的内存遍历不到100ms,由于这一步不受JDBC影响,因此结果可信)。因此,List方式适合于对结果集进行反复多次操作的情况,例如分页显示,往后往前遍历,跳到第一行,跳到最后一行等等。

Iterator方式只取记录id到内存中,并没有把所有数据取到内存中,因此构造结果集的时间开销很小,比JDBC和List方式都要少,并且内存开销也小很多。而对结果集的遍历的操作的时候,Iterator仍然要访问数据库,所有主要的时间开销都花在这里。因此,Iterator方式适合于只对结果集进行1次遍历操作的情况,并且Iterator方式特别适合于从超大结果集中取少量数据,这种情况Iterator性能非常好。另外Iterator方式可以利用JCS缓冲,在使用缓冲的情况下Iterator方式的遍历操作速度将不受数据库访问速度的影响,得到彻底的提升。
Hibernate Iterator JCS方式应该是最快的,Hibernate List速度和JDBC比较接近,而Hibernate Iterator速度还是慢的离谱。另外JDBC和List受到Fetch Size的影响很大,当Fetch Size大于50的时候,速度有非常显著的提升,而Hibernate Iterator的速度似乎不受Fetch Size的影响。
代码下载链接: https://pan.quark.cn/s/c1461e438541 高校教学管理系统数据流图的绘制方法,旨在展现管理信息系统中信息流转的动态过程,这构成了系统设计的关键环节,其目的是为了深入理解和剖析高校教学管理的信息处理机制。数据流图通常由数据流、处理逻辑、数据存储以及外部实体这四个核心要素构成。我们必须明确高校教学管理系统的高层次业务流程。在该系统中,涉及的关键实体涵盖省教委、校长、各相关机构、学生、教师以及用人单位。系统的核心功能主要涉及学生学籍管理、成绩管理、教务管理和招生管理等方面。学生学籍管理子系统负责处理学生的个人资料、学籍变动情况、新生名单以及学籍审核等事务。数据流可能从招生部门启动,通过新生登记表格收集新生资料,经历初步审核和复审阶段,最终形成学籍档案并完成统计报表的制作。在此过程中,存在错误的新生登记表格需要经过审核和更正。成绩管理子系统主要承担学生成绩的记录、统计分析以及报告生成工作。教师负责录入期末考试成绩,系统会对这些成绩进行评估,生成学生成绩单,并供给学生、教师、管理层和用人单位参考使用。教务管理子系统包含教学计划的拟定、课程安排、课表编制以及教师任务分配等内容。该子系统还需处理教学改革的各项项目,例如立项申请立项统计工作,并根据教学计划打印课表。信息管理不仅限于学生和成绩范畴,还包括教师的基本资料管理和教学实施状况。教师信息登记表、教学计划统计报表等都是教务管理的重要组成部分。在绘制数据流图时,应采用自上而下的策略,将庞大的系统逐步分解为易于理解和实现的子系统。每一层数据流图均需保持系统的完整性一致性,同时确保逻辑功能明确,便于用户掌握。每个处理逻辑的扩展程度应适宜,通常控制在7至8个处理逻辑以内,以维持图示...
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值