Hibernate performance optimization software considerations _ _ Hibernate
Abstract: This paper HIBERNATE help with documents, books and some network experience sorted out by the project, only elements and ideas, concrete practices message can be explored in greater detail or to find some more specific information.
In this paper, in accordance with the help HIBERNATE documents, books and some network experience sorted out by the project, only elements and ideas, concrete practices message can be explored in greater detail or to find some more specific information.
HIBERNATE beginning with the people may have encountered performance problems and achieving the same function, using HIBERNATE JDBC performance difference between using more than 10 times normal, if not early adjustment is likely to affect the progress of the entire project.
In general, the HIBERNATE Xingnaidiaoyou the main consideration is as follows:
Ø database design adjustment
Ø HQL Optimization
Ø API to the correct use (such as different types of business use different sets and enquiries API)
Ø main configuration parameters (log, for caching, fetch_size, batch_size, etc.)
Ø mapping file optimization (ID generation strategy, L2 cache, delay loading, association optimization)
Ø a cache management
Ø against two cache, there are also many unique strategy
Ø Service control strategy.
1, Database Design
A) reduce the complexity of the association
B) try not to use the primary key
C) ID the formation mechanism, different databases provided by the mechanism is not exactly the same
D) appropriate data redundancy, but the pursuit of high-Paradigm
2, HQL Optimization
If it aside HQL HIBERNATE itself with some cache mechanism related to the optimization techniques HQL with ordinary SQL optimization techniques, can be very easy to find some hot line.
3, the main configuration
A) for cache, the cache with the following stresses not the same, it is against the cache HQL statement that the full implementation of the same statement again to use a cache data. However, in a cache on the trading system (data changes frequently, the probability for the same conditions do not) may be counterproductive: it will simply spend a lot of system resources but difficult to use.
B) fetch_size with JDBC similar role in the relevant parameters, parameter is not the better, and should be based on business characteristics to set up
C) batch_size Ibid.
D) production systems, make sure to turn off the SQL statement printing.
4, cache
A) the database level cache: This level cache is the most efficient and safe, but may be different database management level is not the same as, for example, in ORACLE, it can be built in the table will be designated under the table cache of .
B) SESSION Cache: a HIBERNATE SESSION effective, it can interfere with the level of cache is not strong, mostly in HIBERNATE automatically manage, but it provides removal of the cache, this increase in volume / update operations are effective. For example, at the same time increase the 100,000 records, according to conventional methods, are likely to find OutofMemeroy abnormal, then it may need to manually remove a cache: Session.evict and Session.clear
C) Application Cache: SESSIONFACTORY in an effective, because it is the optimization of the most important, therefore, to consider the various strategies more data in the cache Add to this level before, the need to consider a number of prerequisites:
I. revised data will not be a third party (for example, whether there is another application to amend these data?)
Ii. Data will not be too great
Iii. Data is not updated frequently (otherwise be counterproductive to use CACHE)
Iv. Data will be frequent enquiries
V. data is not the key data (such as involving money, security and other aspects).
There are several forms of cache can be configured in the mapping file: read-only (ROM, and little change in the application of the static data / historical data), nonstrict-read-write, read-write (in the form of more general, the general efficiency ), transactional (JTA, and the support of cache products less)
D) Distributed Cache: the same c) configuration, the selection of products is different cache, in the current HIBERNATE options in the small oscache, jboss cache, the majority of projects, and for their collection Groups use (especially key trading systems) are a conservative approach. In the cluster environment, using only the database level cache is the most safe.
5, loading delay
A) delay loading entities: to achieve through the use of dynamic agent
B) Set delay loading: through the realization of its own SET / LIST, HIBERNATE provide support in this respect
C) delay loading attributes:
6, Methods
A) completion of the same thing, HIBERNATE provide alternative ways, but the specific use of what approach might Performance / code will be affected. , A return of 100,000 records (List / Set / Bag / Map, etc.) processing, is likely to lead to insufficient memory problem, and if we use based on the cursor (ScrollableResults) or Iterator result sets, no such problem existed.
B) Session of the load / get, the former use of L2 cache, while the latter do not use.
C) Query and list / iterator, if they are to look carefully, you may find many interesting situation, the two main differences (if using Spring, in the corresponding find HibernateTemplate, iterator method):
I. list can only be used for cache (but in the trading system in the little role for cache), the two can not use a single entity cache, but found the target list will be written into the L2 cache, but it generally generate less the implementation of SQL statements, the situation is a lot of (unrelated).
Ii. Iterator L2 cache may be used for a query, it will start from the database to find all the records meet the requirements of the ID, and through the ID to find cache, the cache no records to tectonic Statements identified from the database, it is easy to know that if the cache has no record of the conditions, the use of iterator will have N +1 of the SQL statement (N record for the number of eligible)
Iii. Through the iterator, with cache management API, in Massive Data Query can be satisfactorily resolved memory issues, such as:
While (it.hasNext ()) (
YouObject object = (YouObject) it.next ();
Session.evict (youObject);
SessionFactory.evice (YouObject.class, youObject.getId ());
)
If list method, it is very possible to OutofMemory wrong.
Iv. Through the above note, I think you should know how to use these methods of.
7, the selection pool
HIBERNATE 3.1 in the document's "19.5. Understanding Collection performance" in detail.
8, Service Control
Matters affecting performance include: A mode of selection, isolation level, as well as the selection of lock
A) Service Selection way: If we do not involve a number of affairs manager affairs, do not use JTA, only JDBC can control the affairs.
B) isolation level: See standard SQL isolation level
C) lock selection: pessimistic Lock (from the general management of the affairs of specific Implementation), for the low efficiency of services, but security. Optimistic Lock (usually in the application level achieved), as in the HIBERNATE VERSION in the field can be defined, obviously, if there are multiple applications operating data, and with these applications instead of using an optimistic locking mechanism, it will be optimistic lock failure. Therefore, in view of different data should be different strategies, with the case in front of many, many times we are in the efficiency and safety / accuracy, to find a point of balance, in any case, optimization is not a purely technical problem, you should your application and operational characteristics have sufficient understanding.
9, batch operation
Even the use of JDBC, in a large number of data updates, and do not use BATCH BATCH efficiency is also a great difference. We can be set up to allow batch_size support volume operation.
For example, to delete a table in the volume of the object, such as the "delete Account," a statement by, will find HIBERNATE ACCOUNT identify all the ID and then deleted, mainly for the sake of safeguarding L2 cache, so High efficiency can not be sure, in the follow-up version has been added bulk delete / update, but it will not solve the cache maintenance issues. In other words, because of the maintenance problems of L2 cache, HIBERNATE quantities operational efficiency is not satisfactory!
From the front, many of the points can be seen, and very often we are in the efficiency and safety / accuracy, to find a point of balance, in any case, optimization is not a purely technical problem, you should be on your application and operational characteristics have sufficient understanding of , the general, optimizing the structure of the programme should be determined on the basic design phase, it could cause unnecessary rework, resulting extension of the project, and as architects and project managers, developers may have to face complaints After all, our users the controlling power demand changes little, but technical / risk framework should be aware that in the early and proper formulation of relevant countermeasures.
Another point to note is the application layer of cache icing on the cake, it should not be forever when life-saving straw, the foundation of application (database design, algorithm, and efficient operation of statements, such as the choice of appropriate API) is the most important.
↑ Back
Tags: hibernate, Performance