HIBERNATE of early use may have experienced performance problems, to achieve the same functionality, with the use of JDBC used HIBERNATE ten times the difference between the performance of normal, if not early adjustment is likely to affect the progress of the entire project.
In general, for performance tuning HIBERNATE main consideration is as follows:
◆ ◆ HQL database design to optimize the adjustment of the proper use of ◆ API (for example, depending on choice of business type and query a collection of different API)
◆ the main configuration parameters (log, query cache, fetch_size, batch_size etc.)
◆ optimized mapping file (ID generation strategy, the secondary cache, lazy loading, associated optimization)
◆ ◆ level management of the cache for the secondary cache, there are also many unique ◆ Service Control Strategy Strategy
1, database design
a) reduce the complexity associated
b) try not to use a joint primary key
c) ID generation mechanism, provided by different databases are not exactly the same mechanism
d) appropriate data redundancy, but at high paradigm
2, HQL Optimization
HQL if HIBERNATE itself set aside some of its cache with the associated mechanisms, HQL optimization techniques to optimize SQL with ordinary skills, like, you can easily find some online experiences.
3, the main configuration
a) query cache, the cache with the following do not speak, it is cached for the HQL statement, that is exactly the same statement can be used again when the data cache. However, the query cache in a trading system (data change frequently, the probability of query is not the same) may be counter-productive: it will waste a lot of system resources make it difficult to come in handy.
b) fetch_size, with JDBC for purposes similar to those of the relevant parameters, the parameters are not the better, and should be based on business characteristics to set
c) batch_size Ibid.
d) production systems, remember to turn off the SQL statement printing.
4, the cache
a) the database-level cache: This cache is the most efficient and safe, but different levels of database management is not the same as, for example, in ORACLE, you can specify in the building when the entire table will be placed in the cache which .
b) SESSION Cache: HIBERNATE SESSION in an effective, this class can be cached intervention is not strong, mostly in management HIBERNATE automatically, but it provides ways to clear the cache, which in large quantities increase / update operations are effective. For example, at the same time increase the record 100,000, according to conventional manner, is likely to find abnormal OutofMemeroy, then may need to manually clear the cache at this level: Session.evict and Session.clear
c) Application Cache: SESSIONFACTORY in an effective, optimized and therefore the top priority, therefore, to consider various types of strategies more data in the cache at this level before the Add, to consider a number of prerequisites:
i. modified data will not be a third party (for example, whether there is also another application to amend the data?)
ii. the data will not be too great
iii. the data is not frequently updated (otherwise the use of CACHE may be just the opposite)
iv. the data will be frequent inquiries
v. data is not critical data (for example, is about money, security and other issues).
There are several forms of cache can be configured in the mapping file: read-only (read-only applies to very few changes to the static data / historical data), nonstrict-read-write, read-write (more common form, efficiency general), transactional (JTA in the cache and support for products less)
d) Distributed Cache: with c) the same configuration, but with different cache products, HIBERNATE in the current limited options, oscache, jboss cache, the majority of the current project, for their the use of clusters (in particular, is a key trading systems) are holding a conservative attitude. In the cluster environment, only the use of database-level cache is the most safe.
5, lazy loading
a) lazy loading entities: through the use of dynamic agent
b) lazy collections: the realization of its own through the SET / LIST, HIBERNATE provide support in this area
c) attribute the delay to load
6, Methods
a) accomplish the same thing, HIBERNATE provides a number of options, but in what way the specific use, it may be the performance / code will be affected. Showed a return of 100,000 records (List / Set / Bag / Map, etc.) to deal with, is likely to lead to the problem of insufficient memory, and if the cursor-based (ScrollableResults) or Iterator result set, this problem does not exist.
b) Session of the load / get methods, the former will use the secondary cache, while the latter is not used.
c) Query and list / iterator, If you go to look at them, you may find a lot of interesting situations, the two main differences (if the use of Spring, in HibernateTemplate corresponding find, iterator method):
i. list can only use query cache (but in the trading system is not the role of query cache), the secondary cache can not be used in a single entity, but the target list will be found to write the secondary cache, but it generally generate fewer SQL statements to implement in many cases is a (non-linked).
ii. iterator may be used as the secondary cache, for a query, it will start with the database to identify all eligible records ID, then ID to find the cache, the cache is not the record, and then structure statement identified from the database, making it easy to know that if the cache does not meet the requirements of any records, use the iterator will have N +1 article SQL statement (N in order to comply with the conditions of the number of records)
iii. through the iterator, with the cache management API, query in the mass data can be a very good solution to memory problems, such as:
If the list method, it is probably a mistake OutofMemory.
iv. the adoption of the above to say that I think you should know how to use these two methods has been.
7, a collection of selected
HIBERNATE 3.1 documents in the "19.5. Understanding Collection performance" is described in detail.
8, transaction control
Matters affecting the performance include: the choice of the way services, transaction isolation level and lock the selection.
a) Service methods Optional: If you do not involve a number of Service Manager Service, then do not need to use JTA, only JDBC control of affairs can be.
b) transaction isolation level: See the SQL standard transaction isolation level.
c) the choice of locking: pessimistic locking (usually from the specific realization of the transaction manager), and low efficiency for long transaction, but security. Optimistic-lock (the achievement of general application-level), such as in the HIBERNATE in the VERSION field can be defined, it is clear that if there are multiple applications operating data, and these applications instead of using the same type of optimistic locking mechanism, it would be optimistic lock failure. Therefore, there should be different data for different strategies, with many of the previous case, very often we are in terms of efficiency and security / accuracy to find a balance point, in any case, optimization is not a purely technical problem, you should your business applications and have sufficient understanding of the characteristics.
9, batch operations
Even the use of JDBC, in a large number of data updates, BATCH and BATCH efficient not to use there are also great differences. We can set up their batch_size to support batch operations.
For example, to bulk delete a table of objects, such as "delete Account", played by the statement, you will find all ACCOUNT identified HIBERNATE the ID, then delete, mainly in order to maintain the secondary cache, such high efficiency can not be sure, in the follow-up version has been added to bulk delete / update, but also the maintenance of the cache can not solve the problem. In other words, because of the maintenance of secondary cache, HIBERNATE bulk operational efficiency is not satisfactory!
From the front of the main points can be seen in many, many times we are in terms of efficiency and security / accuracy to find a balance point, in any case, optimization is not a purely technical issue, you should for your business applications and have sufficient understanding of the characteristics of in general, and optimize the program structure should be determined on the basic design phase, or may result in unnecessary rework, resulting in delayed projects, as architect and project managers, developers may have to face the complaint, after all, our users control needs to change, but technology / architecture of risk should be aware at an early stage and to develop better countermeasures related.
Another point to note that the application layer of cache is only icing on the cake, never put it when life-saving straw, the foundation of the application (database design, algorithms, and efficient operation statement, the choice of an appropriate API, etc.) is the most important.
In general, for performance tuning HIBERNATE main consideration is as follows:
◆ ◆ HQL database design to optimize the adjustment of the proper use of ◆ API (for example, depending on choice of business type and query a collection of different API)
◆ the main configuration parameters (log, query cache, fetch_size, batch_size etc.)
◆ optimized mapping file (ID generation strategy, the secondary cache, lazy loading, associated optimization)
◆ ◆ level management of the cache for the secondary cache, there are also many unique ◆ Service Control Strategy Strategy
1, database design
a) reduce the complexity associated
b) try not to use a joint primary key
c) ID generation mechanism, provided by different databases are not exactly the same mechanism
d) appropriate data redundancy, but at high paradigm
2, HQL Optimization
HQL if HIBERNATE itself set aside some of its cache with the associated mechanisms, HQL optimization techniques to optimize SQL with ordinary skills, like, you can easily find some online experiences.
3, the main configuration
a) query cache, the cache with the following do not speak, it is cached for the HQL statement, that is exactly the same statement can be used again when the data cache. However, the query cache in a trading system (data change frequently, the probability of query is not the same) may be counter-productive: it will waste a lot of system resources make it difficult to come in handy.
b) fetch_size, with JDBC for purposes similar to those of the relevant parameters, the parameters are not the better, and should be based on business characteristics to set
c) batch_size Ibid.
d) production systems, remember to turn off the SQL statement printing.
4, the cache
a) the database-level cache: This cache is the most efficient and safe, but different levels of database management is not the same as, for example, in ORACLE, you can specify in the building when the entire table will be placed in the cache which .
b) SESSION Cache: HIBERNATE SESSION in an effective, this class can be cached intervention is not strong, mostly in management HIBERNATE automatically, but it provides ways to clear the cache, which in large quantities increase / update operations are effective. For example, at the same time increase the record 100,000, according to conventional manner, is likely to find abnormal OutofMemeroy, then may need to manually clear the cache at this level: Session.evict and Session.clear
c) Application Cache: SESSIONFACTORY in an effective, optimized and therefore the top priority, therefore, to consider various types of strategies more data in the cache at this level before the Add, to consider a number of prerequisites:
i. modified data will not be a third party (for example, whether there is also another application to amend the data?)
ii. the data will not be too great
iii. the data is not frequently updated (otherwise the use of CACHE may be just the opposite)
iv. the data will be frequent inquiries
v. data is not critical data (for example, is about money, security and other issues).
There are several forms of cache can be configured in the mapping file: read-only (read-only applies to very few changes to the static data / historical data), nonstrict-read-write, read-write (more common form, efficiency general), transactional (JTA in the cache and support for products less)
d) Distributed Cache: with c) the same configuration, but with different cache products, HIBERNATE in the current limited options, oscache, jboss cache, the majority of the current project, for their the use of clusters (in particular, is a key trading systems) are holding a conservative attitude. In the cluster environment, only the use of database-level cache is the most safe.
5, lazy loading
a) lazy loading entities: through the use of dynamic agent
b) lazy collections: the realization of its own through the SET / LIST, HIBERNATE provide support in this area
c) attribute the delay to load
6, Methods
a) accomplish the same thing, HIBERNATE provides a number of options, but in what way the specific use, it may be the performance / code will be affected. Showed a return of 100,000 records (List / Set / Bag / Map, etc.) to deal with, is likely to lead to the problem of insufficient memory, and if the cursor-based (ScrollableResults) or Iterator result set, this problem does not exist.
b) Session of the load / get methods, the former will use the secondary cache, while the latter is not used.
c) Query and list / iterator, If you go to look at them, you may find a lot of interesting situations, the two main differences (if the use of Spring, in HibernateTemplate corresponding find, iterator method):
i. list can only use query cache (but in the trading system is not the role of query cache), the secondary cache can not be used in a single entity, but the target list will be found to write the secondary cache, but it generally generate fewer SQL statements to implement in many cases is a (non-linked).
ii. iterator may be used as the secondary cache, for a query, it will start with the database to identify all eligible records ID, then ID to find the cache, the cache is not the record, and then structure statement identified from the database, making it easy to know that if the cache does not meet the requirements of any records, use the iterator will have N +1 article SQL statement (N in order to comply with the conditions of the number of records)
iii. through the iterator, with the cache management API, query in the mass data can be a very good solution to memory problems, such as:
while(it.hasNext()){
YouObject object = (YouObject)it.next();
session.evict(youObject);
sessionFactory.evice(YouObject.class, youObject.getId());
} |
If the list method, it is probably a mistake OutofMemory.
iv. the adoption of the above to say that I think you should know how to use these two methods has been.
7, a collection of selected
HIBERNATE 3.1 documents in the "19.5. Understanding Collection performance" is described in detail.
8, transaction control
Matters affecting the performance include: the choice of the way services, transaction isolation level and lock the selection.
a) Service methods Optional: If you do not involve a number of Service Manager Service, then do not need to use JTA, only JDBC control of affairs can be.
b) transaction isolation level: See the SQL standard transaction isolation level.
c) the choice of locking: pessimistic locking (usually from the specific realization of the transaction manager), and low efficiency for long transaction, but security. Optimistic-lock (the achievement of general application-level), such as in the HIBERNATE in the VERSION field can be defined, it is clear that if there are multiple applications operating data, and these applications instead of using the same type of optimistic locking mechanism, it would be optimistic lock failure. Therefore, there should be different data for different strategies, with many of the previous case, very often we are in terms of efficiency and security / accuracy to find a balance point, in any case, optimization is not a purely technical problem, you should your business applications and have sufficient understanding of the characteristics.
9, batch operations
Even the use of JDBC, in a large number of data updates, BATCH and BATCH efficient not to use there are also great differences. We can set up their batch_size to support batch operations.
For example, to bulk delete a table of objects, such as "delete Account", played by the statement, you will find all ACCOUNT identified HIBERNATE the ID, then delete, mainly in order to maintain the secondary cache, such high efficiency can not be sure, in the follow-up version has been added to bulk delete / update, but also the maintenance of the cache can not solve the problem. In other words, because of the maintenance of secondary cache, HIBERNATE bulk operational efficiency is not satisfactory!
From the front of the main points can be seen in many, many times we are in terms of efficiency and security / accuracy to find a balance point, in any case, optimization is not a purely technical issue, you should for your business applications and have sufficient understanding of the characteristics of in general, and optimize the program structure should be determined on the basic design phase, or may result in unnecessary rework, resulting in delayed projects, as architect and project managers, developers may have to face the complaint, after all, our users control needs to change, but technology / architecture of risk should be aware at an early stage and to develop better countermeasures related.
Another point to note that the application layer of cache is only icing on the cake, never put it when life-saving straw, the foundation of the application (database design, algorithms, and efficient operation statement, the choice of an appropriate API, etc.) is the most important.