Hibernate Second-Level Query Cache가 작동하지 않는다. Eager Fetchching

Question

Hibernate Profiler에서 연관에 대해 eager fetching을 사용할 때 HQL Query에서 "left join fetch"를 사용하거나 Criteria Query 쿼리에서 .SetFetchMode()를 사용하는 것을 관찰했다. 쿼리 캐시에 더 오래 캐시됩니다.

사실 아주 기본적인 쿼리 만 캐시되어있는 것을 볼 수 있습니다. 누구든지 어떤 쿼리를 캐시에 저장할지, 어떤 캐시를 캐시에 저장할지에 대한 통찰력을 줄 수 있다면 대답을 표시 할 것입니다.

차이가 있다면 Memcached를 사용하고 있습니다 ... 쿼리 밀도가 높은 시스템에서 L2 캐시를 사용하는 것이 더 좋은 선택입니까?

나는 열심히로드를 사용하면 데이터베이스에서 모든 엔티티를 가져 오지만로드 할 필요가없는 열의로드를 사용하지 않으면 (캐시를 사용함) N + 1 문제가 발생하지만 캐싱 없음.

두꺼운 분리 선이있는 것처럼 보이지만 두 전략 모두 성능이 향상되지만 두 전략 모두 다른 전략의 성능을 떨어 뜨립니다.

누구나이 '굵은 선'의 대략적인 위치에 대해 어떤 통찰력을 제공 할 수 있다면 나는 최적의 성능을 가지거나 줄을 더 얇게 만들 수 있어야합니다 ... 나는 매우 관대하고 답을 표시 할 것입니다.

Answer 1

업데이트 : 내 관련 질문은 here을 참조하십시오. 결론은 fetch = "select"를 사용하여 이미 2 차 레벨 캐시에있는 오브젝트와 결합하지 못하게하는 것입니다.

---

내 이전의 대답

쿼리 캐시는 식별자가 제대로해야

1. 를 사용하려면 실제 개체를 쿼리하지에서
   을 반환 캐시 (여전히 유용 할 수있다) 장소 소유자 (?나 : 변수 varName) true로
2. 설정 쿼리 캐시 (당신이 한)
3. 쿼리는 select foo.bar from Foo foo을 객체가 아닌 속성 (from Foo을하지 반환해야합니다)
4. 반환되는 객체는해야 중 2 레벨 캐시, 또는 이후에 호출이 동일한 동면 세션 (동일한 트랜잭션)에 있음

2 개의 다른 트랜잭션이 정확한 매개 변수로 정확한 2 차 수준 캐시, 데이터베이스 히트는 실제 객체를 가져 오기 위해 계속 발생합니다 (아마도 선택 ..)

쿼리 캐시는 캐시되지 않은 항목에 대한 HQL 쿼리의 동일한 트랜잭션에서 데이터베이스에 다시 충돌하지 않도록하고로드 또는 가져 오기 명령에 자동으로 사용되는 HQL 쿼리에 대해 2 단계 캐시 된 개체 활용을 허용합니다.

숲을 맑게하고 싶습니다 ...

Answer 2

나는 Hibernate에 대해 모른다. 그러나 Hibernate에서는 쿼리 사용 힌트를 위해 명시 적으로 쿼리 캐싱을 활성화해야한다. L2 캐시는 개별 객체를 자동으로 캐시 할 수 있지만 쿼리의 경우에는 명시적인 지시가 필요합니다.

Answer 3

답변이 아니라 오히려 힌트 ... 컬렉션 및 쿼리 캐시 모두 실제로 결과를 저장하지 않습니다. 그들은 단지 결과 엔티티의 식별자를 저장합니다. 엔티티의 데이터를 저장하는 엔티티/클래스 캐시입니다.

생각해 보면 쿼리가 여러 엔티티 유형 (즉 열렬한로드)을 반환하는 경우 엔티티간에 관계가 있으므로 ids 배열을 합리적으로 저장할 수 없습니다. 나는 캐시 자체가 매우 간단한 구조라고 생각한다.

'값'검색어에 대해 확실하지 않습니다. 즉, 클래스 대신 프로젝션을 사용합니다. 나는 당신이 이것을 캐쉬 할 수 없다고 말할 것입니다. 그러나 나는 틀릴지도 모른다.

이제는 문제가 해결되지 않을 수도 있지만 다른 방법도 있습니다. 즉 일괄 적재 및 적절한 엔티티 캐시. 나는 콜렉션 캐시에주의해야한다. 나는 그들에게 몇 번 물 렸습니다.

도움이 되길 바랍니다 (적어도 조금).