JDBC vs Hibernate

JDBC and Hibernate differences

When I first started learning Java, I thought that Hibernate was a sacred thing, like SSH, to go around the world. Remember once in the Maple Leaf interview, we several students out also said this company how so backward, there is JDBC, not a little self-motivated. But after graduation only found, but found himself like a frog in the same. However, do not want to do with the wind Catkins, so decided to well summarize, JDBC and hibernate differences.

JDBC has the advantage of JDBC flexibility over performance compared to hibernate. Hibernate has some advantages in easy learning and ease of use. JDBC has an advantage when it comes to many complex multi-table and complex database operations.

Same point:

Both are Java's database operations middleware.

Both objects that operate directly on the database are not thread-safe and need to be shut down in a timely manner.

Both can make explicit transactions on the database's update operations.

different points :

Different SQL languages used: JDBC uses a relational database-based standard SQL language, Hibernate uses the HQL (Hibernate query Language) language

Different objects are manipulated: JDBC operates data, passes data directly to the database through SQL statements, and hibernate operates on persisted objects, which are updated to the database by the data of the underlying persisted object.

Data state is different: the data of the JDBC operation is "instantaneous", the value of the variable cannot be consistent with the value in the database, and the data of hibernate operation is durable, that is, the value of the persisted object's data property can be consistent with the value in the database.

JDBC and Hibernate read performance

1, JDBC is still the fastest way to access, whether it is a create or read operation, is JDBC fast.

2, Hibernate uses Uuid.hex constructs the primary key, the performance slightly somewhat loses, but is not big.

3. Create operation, JDBC is faster than hibernate using batch processing, and consumes JVM memory in batch mode much more than not using batch processing mode.

4, read the data, Hibernate iterator speed is very slow, because he is each next time to go to the database to fetch data, this point from observing the Task Manager Java process Memory changes can also be seen clearly, memory is dozens of k dozens of k increase.

5, read the data, Hibernate list speed quickly, because he is a one-time to take the data out, this point from observing the Task Manager Java process Memory changes can also be seen clearly, memory is almost 10M 10M increase.

6, the way JDBC read data and hibernate is the same as the list (it is very much related to the JDBC driver, different JDBC driver, the results will be very dissimilar), this from the observation of the Java process memory changes can be judged, Because JDBC does not need to construct a bunch of cat object instances like Hibernate, it takes up about half of the JVM's memory than Hibernate's list.

7, Hibernate's iterator way is not useless, it is suitable to select a small amount of data from a large result set, that does not need to occupy a lot of memory, but also can quickly get results. The iterator is also suitable for use with JCS buffering. Final conclusion:

Because of the major flaws in MySQL's JDBC drive, the test results become meaningless and do not have any reference value, but we can probably determine some conclusions:

Well-written JDBC is the fastest in any case.

Second, Hibernate list and iterator applicable to different occasions, there is no question of which is superior or inferior

I personally think that hibernate iterator is the encapsulation of JDBC result, and Hibernate list is the encapsulation of scrollable result, so I speculate that if I do the same read test on Oracle or DB2, If the result set is less than fetchsize,4 there should be no difference in speed, if the result set is greater than fetchsize, but not many times fetchsize, the speed ranking should be:

JDBC Scrollable result (least time consuming) < Hibernate List < JDBC Result < Hibernate Iterator

If the result set is very large, but only some of the records in the result set are taken, the speed is ranked:

JDBC Result < Hibernate Iterator < JDBC scrollable result < hibernate List

To avoid misleading, I conclude by emphasizing my conclusion:

First, "well-written" JDBC must be the best performance

In fact, regardless of cmp,hibernate,jdo and so on, all ORM is a JDBC package, CMP is a heavyweight package, JDO medium package, Hibernate is a lightweight package. In theory, ORM can never be better than JDBC performance. Just like any high-level language, running performance will never be better than assembly language.

For create and update operations, Hibernate will show more speed than JDBC because normal Java programmers do not necessarily use the functionality of JDBC batch.

For read operations, ORM generally has a double-layer buffer, that is, prepreadstatement Buffering and resultset buffering, and JDBC itself has no buffering mechanism, in the case of using connection pooling, Some connection pools will provide prepreadstatement buffering, some even provide resultset buffering, but in general, Java programmers generally do not consider optimizing buffering while writing JDBC, and this is not realistic, so in some cases The ORM will show more than the read speed of JDBC.

Ii. Comparison of Hibernate list and iterator mode

The aspects that JDBC and hibernate want to focus on in testing are list and iterator, but because of the JDBC driver problem, the results are very unreliable, but some useful conclusions can still be drawn.

The read operation consists of two steps: The first step is to take the data out of the database, construct the result set, put the data into the result set, and the second step is to iterate through the result set and fetch each row of data.

The list mode is 1 times to take all the data into memory, to construct a large result set, the main time overhead is this step, this step is far more than the time cost of constructing result set in JDBC and iterator mode, and the memory overhead is also astonishing, and the traversal operation of the result set, The speed is very amazing (from the test results above, 300,000 recorded memory traversal less than 100ms, because this step is not affected by JDBC, so the result is trustworthy). Therefore, the list method is suitable for repeated operations on the result set, such as paging, traversing backwards, jumping to the first row, jumping to the last line, and so on.

The iterator method takes only the record ID into memory and does not take all the data into memory, so the time overhead of constructing the result set is small, less than the JDBC and list methods, and the memory overhead is much smaller. In the case of the traversal of the result set, iterator still accesses the database, and all the major time overhead is spent here. As a result, the iterator approach is suitable for only 1 traversal operations on the result set, and the iterator approach is particularly well suited to taking small amounts of data from the very large result sets, which iterator performance is very good.

In addition, the iterator method can be used JCS buffer, in the case of buffering, the traversal operation speed of iterator mode will not be affected by the speed of database access, and get a thorough promotion. Hibernate Iterator JCS mode should be the fastest, hibernate list speed is closer to JDBC, and hibernate Iterator speed is very slow. In addition, the JDBC and list are affected by the fetch size, and when fetch size is greater than 50, the speed is significantly increased, and the speed of hibernate iterator does not seem to be affected by the size of the fetch.

JDBC vs Hibernate (GO)