such as oracle, hibernate is used oracle fastest paging, the specific can go to see OracleDialect source code
Other databases are also
Other databases are also
Our database is a very large data, the hibernate query statement is good optimization. Specifically, you can go to see the OracleDialect source code
Other databases are also
For particularly large data, hibernate's get and load methods are no matter how many full check, on big data, get or load is to get a piece of data, here you need to use a delayed load
Batch sql time, you need to set the batch size, and turn off the second level of caching, while using flush to synchronize the database, in the use of clear to empty the session cache, so as not to overflow the memory, hibernte documentation on the example
Or use a stored procedure, if you understand hibernate you will use his strengths If you know hibernate you will use its strengths and avoid its weaknesses
There are a lot of people who think that Hibernate is inherently inefficient. Indeed, it is true that, in general, the need to convert the execution of the SQL statement
Hibernate's efficiency is lower than that of the direct JDBC access, however, after a better optimization of the performance of the performance of Hibernate is still quite satisfactory, especially after the application of the second-level cache. In particular, after the application of the second-level cache, you can even get better performance than JDBC without cache
The usual Hibernate optimization strategies:
1. Crawl Optimization
Crawl refers to how Hibernate navigates between associative relationships, and how Hibernate acquires the associated object strategy. , which defines two main aspects: how to capture and when to capture
1) How to capture.
Hibernate3 there are two main kinds of capture methods, divided into . Applied to object-associated instances (many-to-one, one-to-one) and object-associated sets
(set, map, etc.), the total *** is four variations
JOIN grab: By using OUTER JOIN in the SELECT statement to get the object-associated instances or associative sets)
SELECT capture: In addition to sending a SELECT statement to capture the current object's associated entities and collections
In my development experience, the performance optimization here is relatively limited, and does not deserve too much attention
2) When to capture
Mainly divided into delayed loading and immediate capture, by default, Hibernate3 uses delayed loading on the object's associated entities, and ordinary Hibernate3 uses delayed loading on the object's associated entities. By default, Hibernate3 uses delayed loading for objects and immediate capture for common attributes. With delayed loading and appropriate capture granularity, performance can often be improved by several times compared to non-optimization
Immediate capture: when the host object is captured, the associated object and the associated set, as well as the attributes, are captured at the same time
Delayed loading: when the host object is captured, it is not captured but loaded only when a call is made to the host object. Instead, it is loaded when a call is made to its object
For delayed loading, it is important to note that the use of delayed objects must be done before the session is closed, and Hibernate's
LazyInitalizationException is often due to the use of delayed objects outside the lifetime of the session. When we do web development, we can use the OpenSessionInView pattern to open the session when the request starts and close the session only when the request response ends, however, when using the OpenSessionInView pattern, we need to be careful that if the response time is longer (the business is more complex or the client is a low-speed network), the Session resources (that is, the database connection) occupied for too long can lead to resource exhaustion
3) Crawl granularity
Crawl granularity refers to the number of objects in the association relationship is navigated at a time when the number of pre-loaded, Hibernate program performance is often poorer is not on the crawl granularity carefully considered, when loading a list and in the list of each object in the object to the When loading a list and navigating through the associations of each object in the list, this often results in N+1 SQL queries.
There is no agreed upon value for this value, it depends on the situation, if the associated table has less data, then it can be set smaller
3-20, if it is larger then it can be set to 30-50, note that it is not the more the merrier, when the value is more than 50, it doesn't improve the performance much but consumes memory unnecessarily
2. . Second-level cache
Hibernate's data caching consists of two levels: first-level cache, carried out at the session level, mainly object cache, to save the object with its id as the key, during the life of the session; second-level cache, carried out at the level of the SessionFactory, object cache and query cache, query cache. saves query results with the query condition as the key and exists for the lifetime of the SessionFactory. By default, Hibernate enables only the first level of caching, and by using the second level of caching correctly, you can often get unexpected performance.
1) Object Caching:
After grabbing an object, Hiberate caches it with the id as the key, and when the next time you run into an object with the same grabbed id, you can use the following configuration
Method 1: Configure the cached object
<class ... >
<cache useage="read-only/write/...." regions="group" />
</class>
useage indicates what type of cache to use, such as read-only, read-write, etc. (see the Hibernate Reference Guide for more details), and it's worth noting that some caches do not have read-write cache in the Hibernate implementation, such as JBernate. cache, for example, JBossCache is only a read-only cache in the Hibernate implementation. See org.hibernate.cache package regions for cache implementation support
Indicates cache chunking. Most cache implementations tend to chunk the cache, and this part is optional. Each cache implementation
Method 2: Configure in hibernate.cfg.xml
<cache class="..." useage="..." regions="..." />
I think the second one is better, it can be managed in a unified way
2) Query Cache
The query results will be saved with the query condition as the key when querying, which needs to be configured as follows
A. Configure it in hibernate.cfg.xml (Enable Query Cache)
< property name="hibernate.cache.use_query_cache">true</property> (see constants for previous property names
org.hibernate.cfg.Enviroment.USE_QUERY_ CACHE)
B.Program
query.setCacheable(true);
query.setCacheRegions(...) )
It should be noted that the query cache and object cache to combine more effective, because the query cache only cache the primary key data of the query results list In general in the development of some of the more stable and frequently referenced data, such as data dictionaries and so on, it will be the second level of caching, for some of the query conditions and query data change infrequently and often used in the query, will be the second level of caching. L2 cache for queries with infrequent changes in query conditions and query data that are frequently used. Since the secondary cache is placed in memory, and Hibernate's cache is not a weak reference cache (WeekReference), be careful not to put large chunks of data into it, or else the memory may be under greater pressure.
3. Bulk data operations
When a large number of data operations (tens of thousands or even hundreds of millions), you need to pay attention to two points, one, batch submit, two, clear the first level of cache data in a timely manner do not need
1) the so-called batch submit, that is, do not use the session of the flush more often than necessary, every time to flush, Hibernate will be the PO data. Hibernate will PO data in the database for synchronization, for massive data operations is a performance disaster (submit thousands of data and submit a data flush performance difference may be dozens of times the difference). Generally put the data operation in the transaction, when the transaction is committed Hibernate automatically help you flush operation.
2) timely clear the unwanted first-level cache data: because Hibernate defaults to a level of cache, and in the life of the session, all the data will be put into a level of cache after capture, and when the data size is relatively large, the data captured into memory will make the memory pressure is very large, the general operation of the data in batches, after an operation will be the first level of cache clearing
4. Miscellaneous
dynamic-insert, dynamic-update, dynamic insertion and dynamic update, means that Hibernate inserts only non-empty data when inserting data, and modifies only changed data when modifying data, for example,
Dynamic-insert, dynamic-update, dynamic insertion and dynamic update, means that Hibernate inserts only non-empty data, and only changes data when modifying data, for example,
Dynamic-insert, dynamic-update, dynamic insertion and dynamic update. For
class User
{
id
username
password
}
If u.id=1, u.username="ayufox", u.password=null, then if no set dynamic insert then its sql statement is insert
into users(id, username, password) values (1, 'ayufox', '), if set then its sql statement is insert into users(username) valeus(' ayufox')
In the case as above, if u.password = '11' is modified, then if dynamic update is not set, then the sql statement is
update users set username='ayufox', password='11' where id = 1, if set then it is
update user set password='11' where d = 1
The settings are in the class mapping file as follows
<class name="User" table="users" dynamic=insert="true/ false" dynamic-update="true/false" ... >
</class>
This setting has a more limited performance gain