休眠真的很慢。 如何让它更快？

Question

In my app. I have Case and for each Case there can be 0 to 2 Claim . If a Case has 0 claims it runs pretty fast, 1 claims and it slows down, and 2 is awfully slow. Any idea how to make this faster? I didn't know if my case and claim were going back and forth causing an infinite recurison, so I added a JsonManagedReference and JsonBackReference, but that doesn't seem to help much with speeds. Any ideas? Here is my Case.java:

@Entity
public class Case {
    @OneToMany(mappedBy="_case", fetch = FetchType.EAGER)
    @Fetch(FetchMode.JOIN)
    @JsonManagedReference(value = "case-claim")
    public Set<Claim> claims;
}

In Claim.java:

@Entity
public class Claim implements Cloneable {

    @ManyToOne(optional = true)
    @JoinColumn(name = "CASE_ID")
    @JsonBackReference(value = "case-claim")
    private Case _case;
}

output of 0 claims: https://gist.github.com/elmatt/2cafbe7ecb1fa0b7f6a8

output of 2 claims: https://gist.github.com/elmatt/b000bc28909453effc95

Answer 1

Your problem has nothing to do with the relationship between Case and Claim.

FYI: 300ms is not "pretty fast." Your problem is that you expect hibernate to magically and quickly deliver a complex object hierarchy to you, with no particular effort on your part. I view ORM as "The Big Lie" - it is super easy to use and works great on toy problems, but tends to fail miserably when you try to scale to interesting applications (like yours).

Don't abandon hibernate, but realize that you are going to need to work harder than you thought you would in order to make it work for you.

I happen to work in a similar data domain (post-adjudication healthcare claim analysis and processing). You should be able to select this kind of data in well under 10ms per claim (with all associated dimensions) using MySQL on modest hardware from a table with >1 billion claims and the DB hosted on a separate server from the app.

How do you get from where you are to where you should be? 1. Minimize the number of round-trips to the database by minimizing the number of separate queries that are executed. 2. Hand-craft your important queries to grab just the rows and joins that you actually need. 3. Use explain plan on every query to make sure that it hits the tables in the right order and every step is appropriately supported by an index. 4. Consider partitioning your big tables and include the partition criteria in your queries to enable partition-pruning to focus the query on the proper data. 5. Be very hesitant to let hibernate manage your relationships between your entities. I generally do not let hibernate deal with any relationships.

A few years ago, I worked on a product that is an iPhone app where the user walks through workflows (eg, a nurse taking a patient's vitals) and each screen made a round-trip to the app server to execute the workflow step and get the data for the next screen. Think about how little data you can work with on an iPhone screen. Yet the DB portion of the round-trip generally took 2-5 seconds to execute. Everyone there took it for granted, because "That is how long it has always taken." I dug into the code and found that each step was pulling in a significant portion of the database (and then was not used by the business logic).

The only time they tweaked the default hibernate behavior was when they got an exception due to too many joins (yes, MySQL has a limit of something like 67 tables in one query).

The approach of creating your Java data model and simply ORM'ing it into the database generally works just fine on configuration data and the like, but tends to perform terribly for complex data models involving your transactional data. This is what is biting you now.

Your problem is totally fixable, and can be attacked incrementally - you don't have to tear apart the whole application to start making things better.

Answer 2

Can you enable hibernate logging and provide the output. It should indicate the SQL queries being executed against your DB. Information about which DB you are using would also be useful. When you have those I would recommend profiling the queries to ensure your DB is setup appropriately. It sounds like an non indexed query.

Size of the datasets would be helpful in targeting possible issues as well - number of rows and so on.

I would also recommend timing the actual hibernate call (could be as crude as log statement immediately before / after) vs overall processing to identify whether it really is hibernate or some other processing. Without further information & context that is not clear here.

---

Now you've posted your queries we can see what is happening. It looks like the structure of your entities is more complex than the code snippet originally posted. There are references to Person, Activities, HealthPlan and others in there.

As others have commented your query is triggering a very large select of a lot of data due to the nature of your model.

I recommend creating Named Queries for claims, and then load those using the ID of Case.

You should also review your hibernate model and switch to FetchType.LAZY, other hibernate will create large queries such as the one you have posted. The catch here is that if you try to access a related entity outside of the transaction you will get a lazyinitializationexception. You will need to consider each use case and ensure you load the data you need. Two common mistakes with Hibernate is to use FetchType.EAGER everywhere or to initiate the transaction to early to avoid this. There is not one correct design approach, but I normally do the following

JSP -> Controller -> [TX BOUNDARY] Service -> DAO

You service method(s) should encapsulate the business logic you need to load the data you require, before passing it back to the controller.

Again, per the other answer, I think you're expecting too much of Hibernate. It is a powerful tool but you need to understand how it works to get the best from it.