Shulou(Shulou.com)06/02 Report--

Java persistence skills, I believe that many inexperienced people do not know what to do, so this article summarizes the causes of the problem and solutions, through this article I hope you can solve this problem.

A high-performance data access layer requires a lot of knowledge about database internals, JDBC, JPA, and Hibernate. Here are some important techniques that can be used to optimize enterprise applications.

1. SQL statement log

If you use a framework that generates statements that match your usage habits, you should always verify the validity and efficiency of each statement. It is better to use the assertion mechanism to validate when testing, because N + 1 query problems can be captured even before the code is submitted.

two。 Connection management

The connection overhead of the database is very high, so you should always use the connection pool mechanism.

Because the number of connections is given by the capabilities of the underlying database cluster, you need to release connections as quickly as possible.

In performance tuning, you always have to measure and set the correct connection pool, and the pool is about the same size. But tools like FlexyPool can help you find the right size, even if you have deployed your application to a production environment.

3.JDBC batch processing

JDBC batching allows us to send multiple SQL statements in a single database round trip. Performance gains are important on both the driver and the database side. PreparedStatements is well suited for batch processing, while some database systems, such as Oracle, only support batches for preprocessing statements.

Because JDBC defines unique API for batches (such as PreparedStatement.addBatch and PreparedStatement.executeBatch), if you generate statements manually, you should know from the beginning whether batches should be used or not. With Hibernate, you can switch to batches that use a single configuration.

Hibernate 5.2 provides session-level batch processing, so it is more flexible in this respect.

4. Statement cache

Statement caching is one of the least known performance optimizations you can easily take advantage of. Depending on the underlying JDBC driver, PreparedStatements can be cached on the client side (driver) or database side (syntax tree or even execution plan).

5.Hibernate identifier

When using Hibernate, the IDENTITY generator is not a good choice because it disables JDBC batching.

The TABLE generator is even worse because it uses a separate transaction to get the new identifier, which puts pressure on the underlying transaction log and the connection pool, because we need a separate connection every time we need a new identifier.

SEQUENCE is the right choice, and SQL Server has been supported even since version 2012. For SEQUENCE identifiers, Hibernate always provides an optimizer, such as pooled or pooled-lo, which reduces the number of database round trips required to obtain new entity identifier values.

6. Select the correct column type

You should always use the correct column type on the database side. The more compact the column type, the more entries the database working set can hold, and the index will be better adapted to memory. To do this, you should take advantage of database-specific types (such as inet for IPv4 addresses in PostgreSQL), especially when implementing new custom types, Hibernate is very flexible.

7. Relationship

Hibernate comes with many relational mapping types, but not all relational mapping types are equal in efficiency.

You should avoid unidirectional collections and @ ManyToMany lists. If you do need to use entity collections, two-way @ OneToMany associations are preferred. For @ ManyToMany relationships, use Set (s) because they are more efficient in this case, or simply map linked many-to-many tables and transform the @ ManyToMany relationship into two two-way @ OneToMany associations.

However, unlike queries, collections are not flexible because they are not easily paged, which means that we cannot use them when the number of child associations is quite high. For this reason, you should consider whether a collection is really necessary. In many cases, entity queries may be a better choice.

8. Inherit

In terms of inheritance, the mismatch between object-oriented languages and relational databases becomes more obvious. JPA provides SINGLE_TABLE,JOINED and TABLE_PER_CLASS to handle inheritance mapping, and each strategy has its own advantages and disadvantages.

SINGLE_TABLE performed best in SQL statements, but we failed in data integrity because we couldn't use NOT NULL constraints.

When more complex statements are provided at the same time, JOINED adopts data integrity restrictions. This strategy is fine as long as you don't use basic types of polymorphic queries or @ OneToMany associations. Its real purpose is to correlate polymorphic @ ManyToOne supported by policy patterns on the data access layer.

You should avoid using TABLE_PER_CLASS because it does not generate valid SQL statements.

9. Size of the persistence context

When using JPA and Hibernate, you should always pay attention to the size of the persistence context. For this reason, you should not use managed entities too much. By limiting the number of managed entities, we can get better memory management, and the default checking mechanism will be more efficient.

10. Grab only what is necessary

Getting too much data may be the primary cause of performance problems in the data access layer. One problem is that even with read-only Projections, entity queries are dedicated.

DTO projections is more suitable for obtaining custom views, while entities can only be obtained when the business flow needs to be modified.

EAGER fetching is the worst, and you should avoid Anti-Pattern, such as Open-Session in View.

11. High-speed cache

Relational database systems use many memory buffer structures to avoid disk access. Database caching is often ignored. We can significantly reduce response time by properly tuning the database engine so that the working set resides in memory rather than getting it from disk all the time.

Application-level caching is not optional for many enterprise applications. Application-level caching can reduce response time while providing a read-only secondary repository for database shutdown for maintenance or due to some serious system failure.

Secondary caching is useful for reducing the response time of read-write transactions, especially in the master-slave replication architecture. According to the requirements of the application, Hibernate allows you to choose between READ_ONLY,NONSTRICT_READ_WRITE,READ_WRITE and TRANSACTIONAL.

twelve。 Concurrency control

In terms of performance and data integrity, the choice of transaction isolation level is very important. For multi-request Web processes, to avoid losing updates, you should use optimistic locking on separate entities or EXTENDED persistence contexts.

To avoid false positives in optimistic locking, you can split entities using versionless optimistic concurrency control or read-write-based property sets.

13. Release the database query function

Just because you use JPA or Hibernate doesn't mean you shouldn't use native queries. You should take advantage of window functions, CTE (common table expressions), and CONNECT BY,PIVOT queries.

These constructs allow you to avoid getting too much data for later conversion at the application layer. If you can let the database process, you can only get the final result, so you can save a lot of disk I / O and network overhead. To avoid overloading the master node, you can use database replication and have multiple secondary nodes so that data-intensive tasks are performed on the secondary node instead of the master node.

14. Scale out and scale up

Relational databases are very scalable. If Facebook, Twitter, Pinterest, or StackOverflow can extend their database systems, chances are you can extend enterprise applications to their specific business needs.

Database replication and fragmentation are good ways to improve throughput, and you should be able to take advantage of these tested architectural patterns to extend your enterprise applications.

The high-performance data access layer must respond to the underlying database system. Understanding the inner workings of relational databases and the data access framework in use can make a difference between enterprise high-performance applications and applications that have little crawls.

After reading the above, have you mastered Java persistence skills? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.