최대 절전 모드 캐시 문제 관련:

1. Hibernate 캐시 문제에 대하여:
1.1.1 기본 캐시 원칙
Hibernate 캐시는 두 가지 레벨로 나누어져 있으며, 첫 번째 레벨 캐시라고 합니다. 기본적으로 제거할 수 없습니다.

두 번째 수준은 sessionFactory에 의해 제어되는 프로세스 수준 캐시입니다. 이는 전역적으로 공유되는 캐시이며 두 번째 수준 캐시를 호출하는 모든 쿼리 메서드는 이 캐시의 이점을 누릴 수 있습니다. 두 번째 수준 캐시는 올바르게 구성된 경우에만 작동합니다. 동시에 조건부 쿼리를 수행할 때 캐시에서 데이터를 얻으려면 해당 방법을 사용해야 합니다. 예를 들어 Query.iterate() 메서드, 로드, 가져오기 메서드 등이 있습니다. session.find 메소드는 항상 데이터베이스에서 데이터를 가져오며, 필요한 데이터가 포함되어 있더라도 두 번째 수준 캐시에서는 데이터를 가져오지 않는다는 점에 유의해야 합니다.

쿼리 시 캐시를 사용하는 구현 과정은 필요한 데이터가 1차 캐시에 있는지 먼저 쿼리하고, 없으면 2차 캐시에 없으면 2차 캐시에 쿼리합니다. , 쿼리 데이터베이스 Work를 실행합니다. 이 세 가지 방법의 쿼리 속도는 순차적으로 감소한다는 점에 유의해야 합니다.
1.2. 기존 문제
1.2.1. 1단계 캐시의 문제점과 2단계 캐시를 사용하는 이유
Session의 수명이 매우 짧은 경우가 많기 때문에 1단계가 가장 빠릅니다. Session 내부에 존재하는 캐시 물론 Life Cycle도 매우 짧기 때문에 1단계 캐시의 적중률은 매우 낮습니다. 시스템 성능 향상도 매우 제한적입니다. 물론 이 세션 내부 캐시의 주요 기능은 세션의 내부 데이터 상태를 동기화된 상태로 유지하는 것입니다. 시스템 성능을 크게 향상시키기 위해 최대 절전 모드에서는 제공되지 않습니다.
hibernate 사용 성능을 향상시키려면 주의가 필요한 몇 가지 기존 방법(예:
지연 로딩, 긴급 외부 연결, 쿼리 필터링 등 사용) 외에도 Hibernate의 두 번째 방법도 구성해야 합니다. -레벨 캐시. 시스템의 전반적인 성능이 향상되면 즉각적인 결과가 나타나는 경우가 많습니다!
(이전 프로젝트 경험에 따르면 일반적으로 3~4배의 성능 향상이 있을 것입니다.)

1.2.2 N+1 쿼리의 문제점
조건 쿼리 실행 시 반복 ( ) 메소드에는 유명한 "n+1" 쿼리 문제가 있는데, 이는 첫 번째 쿼리에서 iterate 메소드가 조건을 충족하는 쿼리 결과 수에 1개(n+1) 쿼리를 더한 쿼리를 실행한다는 의미입니다. 그러나 이 문제는 첫 번째 쿼리에서만 발생하며, 나중에 동일한 쿼리를 실행하면 성능이 크게 향상됩니다. 이 방법은 많은 양의 데이터가 포함된 비즈니스 데이터를 쿼리하는 데 적합합니다.
그러나 참고: 데이터 양이 특히 큰 경우(예: 파이프라인 데이터 등) 캐시에 존재하는 최대 레코드 수 설정과 같이 이 영구 개체에 대한 특정 캐시 전략을 구성해야 합니다. , 캐시 존재 시간 및 기타 매개 변수는 시스템이 동시에 많은 양의 데이터를 메모리에 로드하여 메모리 자원을 빠르게 소모하고 실제로 시스템 성능을 저하시키는 것을 방지하기 위해! ! !

1.3. Hibernate의 2차 캐시 사용 시 기타 고려 사항:
1.3.1 데이터의 유효성에 대해
또한 Hibernate는 자체적으로 2차 캐시에 데이터를 유지합니다. 캐시의 데이터가 데이터베이스의 실제 데이터와 일치하는지 확인하십시오! save(), update() 또는 saveOrUpdate() 메서드를 호출하여 객체를 전달하거나 load(), get(), list(), iterate() 또는 scroll() 메서드를 사용하여 객체를 얻을 때마다 객체는 세션의 내부 캐시에 추가됩니다. 이후에 플러시() 메서드가 호출되면 객체의 상태가 데이터베이스와 동기화됩니다.

즉, 데이터 삭제, 업데이트, 추가 시 캐시도 동시에 업데이트됩니다. 물론 여기에는 L2 캐시도 포함됩니다!

데이터베이스 관련 작업을 수행하기 위해 hibernate API가 호출되는 한. Hibernate는 캐시된 데이터의 유효성을 자동으로 보장합니다! !

그러나 JDBC를 사용하여 hibernate를 우회하고 데이터베이스에 직접 작업을 수행하는 경우. 현재 Hibernate는 자체적으로 데이터베이스에 대한 변경 사항을 감지하지 못하거나 감지할 수 없으며 더 이상 캐시에 있는 데이터의 유효성을 보장할 수 없습니다! !

이 역시 모든 ORM 제품의 공통적인 문제입니다. 다행스럽게도 Hibernate는 우리에게 캐시 삭제 방법을 공개하여 데이터 유효성을 수동으로 확인할 수 있는 기회를 제공합니다! !
1차 수준 캐시와 2차 수준 캐시에는 해당 삭제 방법이 있습니다.

2차 캐시에서 제공하는 삭제 방법은 다음과 같습니다.
객체 클래스별로 캐시 삭제
객체 클래스 및 객체의 기본 키 ID별로 캐시 삭제
캐시된 데이터 삭제 물건 수집 등

1.3.2.적합한 상황
모든 상황이 2차 캐시 사용에 적합한 것은 아니며, 구체적인 상황에 따라 결정해야 합니다. 동시에 영구 객체에 대한 특정 캐시 전략을 구성할 수 있습니다.

2차 캐시 사용에 적합:
1. 데이터는 제3자에 의해 수정되지 않습니다.

일반적인 상황에서는 다음과 같은 데이터를 구성하지 않는 것이 가장 좋습니다. 일관되지 않은 데이터가 발생하는 것을 방지하기 위해 최대 절전 모드 이외의 레벨 캐시로 수정됩니다. 그러나 성능상의 이유로 이 데이터를 캐시해야 하고 SQL과 같은 제3자에 의해 수정될 수 있는 경우 해당 데이터에 대한 보조 캐시를 구성할 수도 있습니다. 단지 SQL을 수정한 후 캐시 지우기 메서드를 수동으로 호출하면 됩니다. 데이터 일관성을 보장하기 위해

2. 데이터 크기가 허용 범위 내에 있어야 합니다.

데이터 테이블의 데이터 양이 특히 큰 경우 현재로서는 보조 캐시에 적합하지 않습니다. . 그 이유는 캐시된 데이터가 너무 많으면 메모리 리소스 제약이 발생하여 성능이 저하될 수 있기 때문입니다.

데이터 테이블의 데이터 양이 특히 많을 경우 최신 데이터만 사용하는 경우가 많습니다. 이때 두 번째 수준 캐시를 구성할 수도 있습니다. 그러나 지속성 클래스의 캐싱 전략은 최대 캐시 수, 캐시 만료 시간 등과 같이 별도로 구성해야 하며 이러한 매개 변수는 합리적인 범위로 줄여야 합니다(너무 높으면 메모리 리소스 제약이 발생하고, 너무 낮으면 캐싱이 거의 중요하지 않습니다.)

3. 데이터 업데이트 빈도가 낮습니다.

데이터 업데이트 빈도가 너무 높은 데이터의 경우 캐시에 있는 데이터를 자주 동기화하는 데 드는 비용은 쿼리를 통해 얻는 이점과 동일할 수 있습니다. 캐시의 데이터는 단점과 장점이 서로 상쇄됩니다. 캐싱은 현재로서는 거의 중요하지 않습니다.


4. 중요하지 않은 데이터(금융 데이터 등은 아님)

금융 데이터 등은 매우 중요한 데이터로, 유효하지 않은 데이터는 절대 등장하거나 노출되어서는 안 됩니다. 사용하므로, 이때는 안전상의 이유로 2단계 캐시를 사용하지 않는 것이 가장 좋습니다.
현재로서는 "정확성"의 중요성이 "고성능"의 중요성보다 훨씬 크기 때문입니다.

2. 현재 시스템에서 hibernate 캐시 사용에 대한 권장 사항
1.4. 현재 상황
일반적으로 시스템에서 데이터베이스 작업을 수행하기 위해 hibernate를 우회하는 세 가지 상황이 있습니다.

1. Multiple 애플리케이션 시스템이 동시에 데이터베이스에 접근합니다
이 경우 hibernate 2차 캐시를 사용하면 필연적으로 데이터 불일치가 발생하게 됩니다
이때 상세한 설계가 필요합니다. 예를 들어, 동일한 데이터 테이블에 대한 동시 쓰기 작업을 방지하고
데이터베이스에서 다양한 수준의 잠금 메커니즘을 사용하는 등의 설계가 있습니다.

2. 동적 테이블 관련

소위 '동적 테이블'이란 시스템 구동 시 사용자의 운영체제에 따라 자동으로 생성되는 데이터 테이블을 말한다.

예를 들어 사용자 정의 확장 개발의 특성에 속하는 "사용자 정의 양식" 및 기타 기능 모듈은 런타임에 데이터 테이블이 생성되므로 최대 절전 모드 매핑을 수행할 수 없습니다. 따라서 이에 대한 작업은 최대 절전 모드를 우회하는 직접 데이터베이스 JDBC 작업만 가능합니다.

이때 동적 테이블의 데이터가 캐시되지 않으면 데이터 불일치 문제가 발생하지 않습니다.

이때 고유한 캐시 메커니즘을 설계했다면 고유한 캐시 동기화 방법을 호출하면 됩니다.

3. SQL을 사용하여 hibernate 영속 객체 테이블을 일괄 삭제하는 경우

이때 일괄 삭제를 실행하면 삭제된 데이터가 캐시에 존재하게 됩니다.
분석:
3조(SQL 일괄 삭제)가 실행되면 후속 쿼리는 다음 세 가지 방법으로만 가능합니다.
a.session.find() 메서드:
이전의 In에 따르면 요약하면 find 메소드는 2차 캐시의 데이터를 조회하지 않고 데이터베이스를 직접 조회합니다.
그래서 데이터 유효성 문제는 없습니다.
b.iterate 메소드를 호출하여 조건부 쿼리를 수행하는 경우:
iterate 쿼리 메소드의 실행 방법에 따라 매번 조건에 맞는 id 값을 데이터베이스에 쿼리한 후, 이 ID를 기반으로 캐시의 데이터입니다. 캐시에 이 ID를 가진 데이터가 없는 경우에만 데이터베이스 쿼리가 실행됩니다.
이 레코드가 SQL에 의해 직접 삭제된 경우 반복은 실행 시 이 ID를 쿼리하지 않습니다. 아이디 쿼리입니다. 따라서 이 레코드가 캐시에 존재하더라도 고객이 이를 얻을 수 없으며 불일치도 발생하지 않습니다. (이 상황은 테스트를 통해 확인되었습니다.)

c. get 또는 load 메소드를 사용하여 ID로 쿼리합니다.

객관적으로 이 시점에서는 만료된 데이터가 쿼리됩니다. 하지만 시스템에서 SQL 일괄 삭제는 일반적으로 중간 관련 데이터 테이블의 경우

,

중간 연관 테이블의 질의는 일반적으로 조건부 질의를 사용하는데, 특정 연관 관계를 id로 질의할 확률은 매우 낮기 때문에 이런 문제는 없습니다. id로 쿼리 관계를 쿼리하려면 데이터 양이 많기 때문에 SQL을 사용하여 일괄 삭제를 수행합니다. 이 두 가지 조건이 충족되면 ID별 쿼리가 올바른 결과를 얻을 수 있도록 2차 캐시에서 이 개체의 데이터를 수동으로 삭제하는 방법을 사용할 수 있습니다!!
(이 상황은 덜합니다. 발생할 가능성 있음)

1.5.권장 사항
1. 데이터 지속성 개체의 데이터를 직접 업데이트할 때는 SQL을 사용하지 않는 것이 좋지만 일괄 삭제는 가능합니다. (시스템에서 일괄 업데이트가 필요한 곳도 적습니다.)

2. SQL을 사용하여 데이터를 업데이트해야 하는 경우 이 개체의 캐시된 데이터를 지워야 합니다.
SessionFactory.evict(class)
SessionFactory.evict(class,id)
및 기타 메소드를 호출합니다.

3. 일괄 삭제 데이터의 양이 크지 않은 경우에는 Hibernate의 일괄 삭제를 직접 사용할 수 있으므로 Hibernate의 SQL 실행으로 인해 발생하는 캐시 데이터 일관성을 우회하는 문제가 없습니다.

4. 대량의 레코드 데이터를 삭제하기 위해 최대 절전 모드의 일괄 삭제 방법을 사용하는 것은 권장되지 않습니다.
이유는 Hibernate의 일괄 삭제가 1개의 쿼리문과 조건을 만족하는 n개의 삭제문을 실행하기 때문입니다. 한 번에 하나의 조건부 삭제 문을 실행하는 대신! !
삭제할 데이터가 많을 경우 엄청난 성능 병목현상이 발생하게 됩니다! ! ! 일괄적으로 삭제할 데이터의 양이 큰 경우(예: 50개 항목 이상)에는 JDBC를 사용하여 직접 삭제할 수 있습니다. 이것의 장점은 SQL 삭제 문이 하나만 실행되므로 성능이 크게 향상된다는 점입니다. 동시에 캐시 데이터 동기화 문제의 경우 최대 절전 모드를 사용하여 2차 캐시에서 관련 데이터를 지울 수 있습니다.
SessionFactory.evict(class) 및 기타 메소드를 호출합니다.

그래서 일반적인 응용 시스템 개발(클러스터가 아닌, 분산 데이터 동기화 문제 등)의 경우 중간 연관 테이블의 일괄 삭제를 수행할 때만 sql 실행이 호출되고 동시에 중간 연관 테이블 일반적으로 조건부 쿼리를 실행할 때 id로 쿼리를 실행하는 경우는 거의 없습니다. 따라서 이때 캐시 삭제 메소드를 호출하지 않고도 sql 삭제를 직접 수행할 수 있습니다. 이렇게 하면 나중에 두 번째 수준 캐시를 구성할 때 발생하는 데이터 유효성 문제가 발생하지 않습니다.

한발 물러서서, 나중에 중간 테이블 객체를 ID로 조회하는 방법이 실제로 호출되더라도 캐시를 지우는 방법을 호출하면 해결될 수 있다.

4. 구체적인 구성 방법

내가 아는 바에 따르면 많은 Hibernate 사용자들은 해당 메서드를 호출할 때 "Hibernate가 스스로 성능 문제를 처리할 것이다"라고 미신적으로 믿고 있습니다. ” 또는 “hibernate는 우리의 모든 작업에 대해 자동으로 캐시를 호출합니다.” 실제 상황은 Hibernate가 우리에게 좋은 캐싱 메커니즘과 확장된 캐시 프레임워크 지원을 제공하지만 작동하기 전에 올바르게 호출되어야 한다는 것입니다. ! 따라서 hibernate를 사용하는 많은 시스템에서 발생하는 성능 문제는 실제로는 hibernate가 비효율적이거나 나쁘기 때문에 발생하는 것이 아니라 사용자가 hibernate를 사용하는 방법을 올바르게 이해하지 못하기 때문에 발생합니다. 반대로, 적절하게 구성되면 최대 절전 모드의 성능은 여러분을 상당히 "놀라게" 만들 것입니다. 아래에서는 구체적인 구성 방법을 설명합니다.

ibernate는 두 번째 수준의 캐시 인터페이스를 제공합니다.

net.sf.hibernate.cache.Provider,

도 기본 구현인 net.sf를 제공합니다. .cache.HashtableCacheProvider,
는 ehcache, jbosscache 등과 같은 다른 구현도 구성할 수 있습니다.

구체적인 구성 위치는 hibernate.cfg.xml 파일에 있습니다.

true

net.sf.hibernate.cache.HashtableCacheProvider

많은 Hibernate 사용자는 이 단계를 구성하면 완료되었다고 생각합니다.

참고: 실제로 이것은 유일한 구성은 최대 절전 모드의 두 번째 수준 캐시가 전혀 사용되지 않는다는 것입니다. 동시에, 대부분의 경우 최대 절전 모드를 사용할 때 즉시 세션을 닫으므로 첫 번째 수준 캐시는 아무런 역할도 하지 않습니다. 결과적으로 캐시가 사용되지 않고 모든 최대 절전 모드 작업이 데이터베이스에서 직접 수행됩니다! ! 성능은 예상대로입니다.

올바른 방법은 위의 구성 외에도 각 vo 개체의 특정 캐시 전략을 구성하고 이를 매핑 파일에서 구성하는 것입니다. 예:

캐시 사용량="읽기-쓰기"/>

<속성 이름="name" 열="NAME" type="java.lang.String"/>
<속성 이름="dbType" 열="DBTYPE" type="java.lang .String"/>

핵심은 이것이입니다.
읽기 전용, 읽기-쓰기, 트랜잭션 등 여러 옵션이 있습니다.
그런 다음 쿼리를 실행할 때 주의하세요. 조건부 쿼리이거나 모든 결과를 반환하는 쿼리인 경우 session.find( ) 방법이 사용됩니다. 캐시의 데이터는 검색되지 않습니다. 캐시된 데이터는 query.iterate() 메서드가 호출될 때만 조정됩니다.

동시에 get 및 load 메소드는 캐시의 데이터를 쿼리합니다.

캐시 프레임워크마다 구체적인 구성 방법은 다르지만 일반적으로 위 구성은 동일합니다.

(또한 후속 글에서 트랜잭션과 클러스터를 지원하는 환경 구성을 공개하도록 노력하겠습니다)

3. 요약
비즈니스 조건과 프로젝트 조건에 따라 Hibernate를 효과적으로 구성하고 올바르게 사용하며 강점을 극대화하고 약점을 방지합니다. 모든 상황에 적용할 수 있는 일률적인 솔루션은 없습니다.