마이바티스와 최대 절전 모드의 차이점

Java 개발에 사용되는 두 가지 주요 프레임워크 조합은 SSM, Spring, SpringMVC, MyBatis 및 SSH, Struts2, Spring 및 Hibernate입니다. 오늘은 먼저 두 데이터베이스 프레임워크의 차이점을 살펴보겠습니다.

첫 번째 측면: 개발 속도 비교

개발 속도 측면에서 보면 Mybatis보다 Hibernate를 제대로 마스터하는 것이 더 어렵습니다. Mybatis 프레임워크는 상대적으로 간단하고 사용하기 쉽지만 상대적으로 조잡합니다. 개인적으로 마이바티스를 잘 사용하기 위해서는 먼저 Hibernate를 이해해야 한다고 생각합니다. (추천 학습: Java 동영상 튜토리얼)

둘의 개발 속도를 비교했을 때, 둘의 특성과 성능을 고려해야 할 뿐만 아니라, 이를 기반으로 프로젝트 개발에 어느 것이 더 적합한지 고려하는 것도 필요합니다. a 기본적으로 프로젝트에는 복잡한 쿼리가 사용되지 않고 단순한 추가, 삭제, 수정 및 쿼리만 사용됩니다. 이러한 방식으로 기본 SQL 문이 캡슐화되어 있기 때문에 최대 절전 모드를 선택하는 효율성이 매우 빠릅니다. , SQL 문을 전혀 작성할 필요가 없으므로 시간이 많이 절약되지만 대규모 프로젝트의 경우 복잡한 문이 많기 때문에 hibernate를 선택하는 것은 속도를 많이 향상시키는 좋은 선택이 아닙니다. , 명세서 관리도 더욱 편리해졌습니다.

두 번째 측면: 개발 작업량 비교

Hibernate와 MyBatis는 둘 다 해당 코드 생성 도구를 가지고 있습니다. 간단하고 기본적인 DAO 레이어 메소드를 생성할 수 있습니다. 고급 쿼리의 경우 Mybatis에서는 SQL 문과 ResultMap을 수동으로 작성해야 합니다. Hibernate는 좋은 매핑 메커니즘을 가지고 있습니다. 개발자는 SQL 생성 및 결과 매핑에 신경 쓸 필요가 없으며 비즈니스 프로세스에 더 집중할 수 있습니다.

세 번째 측면: SQL 최적화

Hibernate 쿼리는 테이블의 모든 필드를 쿼리하므로 성능이 소모됩니다. Hibernate는 쿼리해야 하는 필드를 지정하기 위해 자체 SQL을 작성할 수도 있지만 이는 Hibernate 개발의 단순성을 파괴합니다. Mybatis의 SQL은 수동으로 작성되므로 필요에 따라 쿼리 필드를 지정할 수 있습니다.

Hibernate HQL 문을 튜닝하려면 SQL을 인쇄해야 하는데, Hibernate의 SQL은 너무 보기 흉하기 때문에 많은 사람들이 싫어합니다. MyBatis의 SQL은 직접 수동으로 작성하기 때문에 조정이 쉽습니다. 그러나 Hibernate에는 자체 로그 통계가 있습니다. Mybatis 자체에는 로그 통계가 없으며 로깅을 위해 Log4j를 사용합니다.

네 번째 측면: 객체 관리 비교

Hibernate는 완전한 객체/관계형 매핑 솔루션으로, 개발자가 더 이상 기본 데이터베이스 시스템의 세부 사항에 대해 걱정할 필요가 없도록 객체 상태 관리(상태 관리) 기능을 제공합니다. . 즉, SQL 문을 관리해야 하는 일반적인 JDBC/SQL 지속성 계층 솔루션과 비교하여 Hibernate는 Java 애플리케이션에서 데이터를 유지하기 위해 보다 자연스러운 객체 지향 관점을 채택합니다.

즉, Hibernate를 사용하는 개발자는 항상 객체의 상태에 집중해야 하며 SQL 문의 실행을 고려할 필요가 없습니다. 이러한 세부 사항은 이미 Hibernate에 의해 처리되며 개발자만이 시스템 성능을 조정할 때 이를 이해하면 됩니다. MyBatis에는 이 영역에 대한 문서가 없으며 사용자는 개체를 직접 세부적으로 관리해야 합니다.

다섯 번째 측면: 캐싱 메커니즘

Hibernate 캐시

Hibernate 1단계 캐시는 세션 캐시입니다. 1단계 캐시를 잘 활용하려면 세션 수명 주기를 관리해야 합니다. 작업 작업에서는 세션을 사용하는 것이 좋습니다. 첫 번째 수준 캐시에는 세션에 대한 엄격한 관리가 필요합니다.

Hibernate 2차 수준 캐시는 SessionFactory 수준 캐시입니다. SessionFactory의 캐시는 내장 캐시와 외부 캐시로 구분됩니다. 내장 캐시는 애플리케이션에 대해 읽기 전용인 SessionFactory 객체의 일부 컬렉션 속성(매핑 요소 데이터 및 예약된 SQL 문 등)에 포함된 데이터를 저장합니다. 외부 캐시는 데이터베이스 데이터의 복사본을 저장하며 그 기능은 1차 캐시와 유사하며, 저장 매체로 메모리를 사용하는 것 외에도 하드 디스크와 같은 외부 저장 장치를 사용할 수도 있습니다. 두 번째 수준 캐시는 프로세스 수준 캐시 또는 SessionFactory 수준 캐시라고 하며 모든 세션에서 공유할 수 있습니다. 해당 수명 주기는 SessionFactory의 수명 주기와 함께 소멸됩니다.

MyBatis Cache

MyBatis에는 매우 쉽게 구성하고 사용자 정의할 수 있는 매우 강력한 쿼리 캐싱 기능이 포함되어 있습니다. MyBatis 3의 캐시 구현에 대한 많은 개선 사항이 구현되어 더욱 강력하고 구성하기 쉬워졌습니다.

기본적으로 캐싱은 활성화되어 있지 않습니다. 로컬 세션 캐싱 외에도 수익 창출을 향상할 수 있으며 순환 종속성을 처리하는 데에도 필요합니다. L2 캐시를 활성화하려면 SQL 매핑 파일에

라는 줄을 추가해야 합니다. 이 간단한 문의 효과는 다음과 같습니다.

매핑 문 파일의 모든 select 문이 캐시됩니다.

매핑 문 파일의 모든 삽입, 업데이트 및 삭제 문은 캐시를 새로 고칩니다.

캐시는 LRU(Least Recent Used) 알고리즘을 사용하여 복구합니다.

일정(예: 플러시 간격 없음, 새로 고침 간격 없음)에 따라 캐시는 시간 순서에 따라 새로 고쳐지지 않습니다.

캐시는 목록 컬렉션 또는 개체에 대한 1024개의 참조를 저장합니다(쿼리 메서드가 반환하는 내용에 관계 없음).

캐시는 읽기/쓰기 캐시로 간주됩니다. 즉, 개체 검색은 공유되지 않으며 다른 호출자나 스레드의 잠재적인 수정을 방해하지 않고 호출자가 안전하게 수정할 수 있습니다.

이러한 모든 속성은 캐시 요소의 속성을 통해 수정할 수 있습니다.

예:

이 고급 구성은 FIFO 캐시를 생성하고 512 참조마다 새로 고칩니다. 결과 개체 또는 목록에 저장되고 반환된 개체는 읽기 전용으로 간주되므로 서로 다른 스레드의 호출자 간에 개체를 수정하면 충돌이 발생할 수 있습니다. 사용 가능한 제거 전략은 기본값은 LRU:

LRU입니다. - 가장 최근에 사용되지 않은 항목: 가장 오랫동안 사용되지 않은 개체를 제거합니다.

FIFO – 선입선출: 캐시에 들어가는 순서대로 개체를 제거합니다.

SOFT – 소프트 참조: 가비지 수집기 상태 및 소프트 참조 규칙을 기반으로 개체를 제거합니다.

WEAK – 약한 참조: 가비지 수집기 상태 및 약한 참조 규칙을 기반으로 객체를 더욱 적극적으로 제거합니다.

flushInterval은 양의 정수로 설정할 수 있으며 합리적인 기간을 밀리초 단위로 나타냅니다. 기본값은 설정되어 있지 않습니다. 즉, 새로 고침 간격이 없으며 명령문이 호출될 때만 캐시가 새로 고쳐집니다.

크기(참조 수)는 캐시하는 개체 수와 실행 환경에서 사용 가능한 메모리 리소스 수를 염두에 두고 임의의 양의 정수로 설정할 수 있습니다. 기본값은 1024입니다.

readOnly(읽기 전용) 속성은 true 또는 false로 설정할 수 있습니다. 읽기 전용 캐시는 캐시된 개체의 동일한 인스턴스를 모든 호출자에게 반환합니다. 따라서 이러한 개체는 수정할 수 없습니다. 이는 중요한 성능 이점을 제공합니다. 읽기-쓰기 캐시는 (직렬화를 통해) 캐시된 객체의 복사본을 반환합니다. 속도는 느리지만 더 안전하므로 기본값은 false입니다.

유사점: 시스템의 기본 캐싱 메커니즘을 사용하는 것 외에도 Hibernate 및 Mybatis의 두 번째 수준 캐시는 자체 캐시를 구현하거나 다른 타사 캐싱 솔루션용 어댑터를 생성하여 캐싱 동작을 완전히 재정의할 수 있습니다.

차이점: Hibernate의 2차 캐시 구성은 SessionFactory가 생성한 구성 파일에 자세히 구성되어 있으며, 캐시 유형은 특정 테이블-객체 매핑에서 구성됩니다.

MyBatis의 두 번째 수준 캐시 구성은 각 특정 테이블-객체 매핑에서 자세히 구성되므로 다양한 캐싱 메커니즘을 다양한 테이블에 맞게 사용자 지정할 수 있습니다. 그리고 Mybatis는 Cache-ref를 통해 네임스페이스에서 동일한 캐시 구성과 인스턴스를 공유할 수 있습니다.

둘 사이의 비교: Hibernate는 쿼리 객체에 대한 좋은 관리 메커니즘을 가지고 있기 때문에 사용자는 SQL에 신경 쓸 필요가 없습니다. 따라서 2차 캐시를 사용할 때 더티 데이터가 나타나면 시스템은 오류를 보고하고 프롬프트를 표시합니다.

이와 관련하여 MyBatis는 2단계 캐시를 사용할 때 특히 주의해야 합니다. 데이터 업데이트 작업의 범위를 완전히 결정할 수 없는 경우 캐시를 무작정 사용하지 마세요. 그렇지 않으면 더티 데이터의 출현으로 인해 시스템의 정상적인 작동에 큰 숨겨진 위험이 초래됩니다.

자바 관련 기술 기사를 더 보려면 Java 개발 튜토리얼 칼럼을 방문하여 알아보세요!

위 내용은 마이바티스와 최대 절전 모드의 차이점의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!