그리고 Spring 데이터 카우치베이스 커뮤니티 프로젝트는 역사적으로 1.4 공식의 세대 카우치베이스 자바 SDK이 있지만 SDK 2.0 가 출시된 지 꽤 오래되었습니다.
하지만 지금이 바로 업그레이드하기 좋은 시기입니다. Spring 데이터 카우치베이스 를 최신 2.2 SDK로 업데이트하는 것이 좋습니다. N1QL새로운 Couchbase 쿼리 언어인 "문서용 SQL"로도 알려져 있습니다.
2.x SDK 세대는 완전히 비동기식 레이어를 기반으로 구축되어 완전히 재작성되었으며 RxJava 관찰 가능를 사용할 수 있습니다. 따라서 별도의 Maven 아티팩트 이름을 가지며 스프링 데이터 카우치베이스의 주요 버전을 보증합니다.
스프링 데이터 카우치베이스 1.x 세대와 2.x 버전 간의 주요 차이점은 다음과 같습니다:
- 구성 요소는 Couchbase의 현실에 더 가깝습니다: 환경, 클러스터, 버킷(잠재적으로 생성할 수 있는
카우치베이스 템플릿각각 다른 버킷 또는 클러스터에 연결할 수 있습니다!) - 사용자 정의 메소드를 백업하는 것이 항상
조회수이제 더 이상은 기본적으로N1QL를 사용하면 훨씬 더 유연하고 서버 측 유지 관리가 훨씬 덜 필요합니다. - 다음을 사용하는 사용자 지정 메서드
조회수의 메서드가 Spring 데이터 철학에 더 잘 부합하도록 약간 수정되었습니다. 이로 인해 유연성은 감소하지만 구현은 메서드 이름("쿼리 파생“). - 이제 보기 축소 기능이 지원됩니다.
- 유형 정보를 저장하는 JSON 필드 이름 변경("
_class")가 이제 지원됩니다. 예를 들어동기화 게이트웨이-호환되는 것,javaClass에서 제공됩니다.매핑 카우치베이스 컨버터.TYPEKEY_SYNCGATEWAY_COMPATIBLE.
물론 여전히 하위 수준 API에 액세스하려면 카우치베이스 템플릿 가 아닌 카우치베이스 리포지토리 인터페이스에 액세스할 수도 있습니다. 버킷 를 사용하세요.
이러한 변화에 대해 좀 더 자세히 알아봅시다!
N1QL을 통한 리포지토리 방법
Couchbase 4.0의 가장 큰 새로운 기능은 다음과 같습니다. N1QL는 JSON 문서에서 작동하는 SQL의 상위 집합입니다(따라서 SQL에 JSON 관련 특수성을 추가했습니다).
이는 대부분의 쿼리 파생 키워드도 N1QL로 쉽게 변환되기 때문에 Spring Data의 리포지토리 패턴과 쿼리 파생에 특히 유용합니다.
이제 N1QL은 리포지토리 메서드에 대한 기본 지원 Couchbase 기능입니다. 또한 쿼리 인터페이스를 사용하세요.
예를 들어 N1QL을 사용하는 쿼리 파생 메서드는 다음과 같습니다:
매개 변수의 경우 "과일", "치즈케이크", 5를 입력하면 다음과 같은 N1QL 쿼리가 생성됩니다:
보시다시피, 프레임워크는 문서를 메타데이터를 포함하여 마샬링 해제할 수 있도록 선택할 필드(메타데이터 포함)를 올바르게 선택하기도 합니다. 파티케이크 엔티티입니다.
조회수에 관해서는 firstX 구문 LIMIT 그리고 countBy 대신 findAllBy 를 사용하여 셀렉트 카운트(*) 도 지원됩니다.
뷰에 비해 또 다른 장점은 단일 범용 인덱스(N1QL 관점에서 "기본 인덱스")를 가지고 모든 쿼리에 사용할 수 있으므로 각 쿼리마다 다른 뷰가 필요한 뷰에 비해 서버 측 조정이 덜 필요하다는 점입니다.
참고: 물론 N1QL에서 보다 전문화되고 효율적인 보조 인덱스를 만들 수도 있습니다.
보기를 통한 리포지토리 방법
이 버전의 큰 변화 중 하나는 이제 뷰를 기반으로 하는 리포지토리 쿼리(일명 사용자 정의 리포지토리 메서드)가 Spring 데이터 철학에 더 부합한다는 점입니다. 또한 이러한 쿼리에는 다음과 같이 명시적으로 주석을 달아야 합니다. @View(viewName="something").
즉, 리포지토리 인터페이스에 Couchbase와 관련된 어떤 것도 누출되어서는 안 됩니다. 대신, 여러분이 할 수 있는 일은 쿼리 파생 메커니즘을 사용하여 가장 간단한 쿼리를 처리할 수 있습니다.
즉, 다음과 같은 작업을 수행할 수 있습니다:
프레임워크는 해당 인터페이스를 가져와 메서드 이름과 주어진 매개변수로 쿼리를 생성합니다. 예를 들어 목록 의 과일 그리고 설탕 를 입력하면 다음과 같은 쿼리가 생성됩니다. ?keys=["fruit","sugar"].
쿼리 매개변수로 변환할 수 있는 메서드 이름의 키워드 전체 목록은 설명서를 참조하세요. 다른 모든 용도의 경우에는 직접 구현을 제공해야 합니다.
보기에서 축소 기능 사용
이전에는 지원되지 않았던 또 다른 새로운 기능은 기능 감소 가 있는 경우. 이제 이를 실행하기 위해 메서드를 선언하기만 하면 됩니다. 카운트 대신 findAll를 입력하면 긴 문자열을 반환합니다.
Couchbase의 축소 함수는 기존의 _count 하나를 반환하는 한, 긴.
마찬가지로 "topX" 또는 "firstX"을 메서드 이름에 포함하면 추가적으로 limit 요청에 설정되는 경우(예 findFirst5By성 를 누르면 목록이 5개로 제한됩니다).
일관성 구성, 자체 쓰기 읽기
뷰와 같이 비동기적으로 채워지는 보조 인덱스를 사용할 때 자주 발생하는 문제 중 하나는 GSI (N1QL을 지원하는 새로운 보조 인덱스 엔진)을 사용하려면 다음을 수행해야 합니다. 자신의 글 읽기.
이는 데이터가 아직 색인되는 과정 중에 있는 한 뷰/N1QL이 응답하지 않아야 한다는 것을 의미하므로 일관성을 위해 약간의 성능이 희생됩니다.
그 반대(그리고 스프링 데이터 카우치베이스의 현재 기본값)는 오래된 데이터를 반환하도록 허용하여 성능을 향상시키는 것입니다.
쿼리 도출을 통해 프레임워크에서 구성되는 모든 쿼리(뷰 기반 또는 N1QL 기반)에 대해 다음과 같은 개념에 대한 작은 추상화를 제공하여 이를 구성하는 전역 평균을 추가했습니다. 일관성.
이 작업은 추상 카우치베이스 구성's getDefaultConsistency() 메서드를 사용합니다. 일관성 은 다음 중 하나를 선택할 수 있는 열거형입니다. READ_YOUR_OWN_WRITES, 강력하게_일관성, UPDATE_AFTER 그리고 결국_일관성.
XML에서도 이 작업을 수행할 수 있습니다. 일관성 속성의 태그.
저장된 JSON의 유형 정보 필드 변경하기
마지막으로, 일부 사용자가 Spring 데이터 및 Couchbase Mobile 측면에서 다음과 같은 문제를 보고했습니다. 동기화 게이트웨이 밑줄로 접두사가 붙은 필드가 포함된 문서를 거부합니다.
스프링 데이터에서 유형 정보를 저장하는 경우 문제가 됩니다. _class 필드 :(
해결책은 구성을 통해 해당 유형 정보 필드의 이름을 선택할 수 있도록 허용하는 것입니다. 이렇게 하려면 typeKey() 메서드의 추상 카우치베이스 구성. 예를 들어 상수 매핑 카우치베이스 컨버터.TYPEKEY_SYNCGATEWAY_COMPATIBLE ("javaClass“).
이 필드는 리포지토리의 엔티티에 해당하는 문서만 필터링하기 위해 생성된 N1QL 쿼리에서 사용되는 필드입니다.
구성
2.0 SDK는 이제 다음과 같은 객체를 사용하여 Couchbase 클러스터의 용어에 더 가까워졌습니다. 클러스터 그리고 버킷 를 일등 시민으로 간주합니다. 결과적으로 스프링 데이터 구성에서는 카우치베이스클라이언트 를 사용하면 더 다양한 빈을 구성할 수 있습니다.
SDK의 튜닝은 별도의 클래스인 카우치베이스 환경를 사용하여 io 풀, 타임아웃 등을 조정할 수 있습니다... 환경은 가능한 한 전반적으로 재사용해야 합니다. 클러스터및 클러스터를 재사용하여 싱글톤 범위의 버킷(기본적으로 모든 것은 가능한 한 많이 재사용해야 합니다).
를 얻으려면 카우치베이스 템플릿를 사용하려면 환경, a 클러스터 및 버킷. 이들은 모두 JavaConfig를 확장할 때 자동으로 생성됩니다. 추상 카우치베이스 구성만 제공하면 됩니다:
- 부트스트랩할 노드 목록(IP 또는 호스트 이름만)
- 버킷의 이름
- 버킷의 비밀번호
물론 기본값을 재정의하려면 예를 들어 기본값인 환경 구성에서 해당 메서드를 재정의할 수 있습니다. 추상 카우치베이스 구성 (아래 스니펫에 표시된 것처럼):
XML로 환산하면 다음과 같습니다:
서버 측에서 설정하기
스프링 데이터 카우치베이스 CRUD 메서드에서 얻은 크러드 리포지토리 인터페이스는 모두 여전히 (단일 엔티티 또는 변이 엔티티로 작업할 때) 카우치베이스의 키/값 연산 또는 보기 (예를 들어 ID를 모르는 여러 엔티티에서 작업하는 경우) count() 또는 findAll() 메소드).
즉, 여전히 모든 엔티티의 인덱스가 Couchbase의 뷰 형태로 존재해야 합니다.
기본적으로 프레임워크는 디자인 문서의 엔티티 이름(대문자 없음)과 뷰의 이름을 찾습니다. 모두 (예. 파티케이크/모두 에 대한 파티케이크 엔티티 클래스).
결론
여기까지(현재로서는) Spring Data Couchbase 2.0.x의 첫 번째 프리뷰 버전입니다. 마음에 드셨기를 바랍니다!
그리고 프로젝트 문서 및 README가 이러한 새로운 기능으로 업데이트되었으며 모든 코드와 문서는 2.0.x 브랜치에서 Spring 데이터 카우치베이스 깃허브 리포지토리.
지원을 아끼지 않은 Spring 데이터 팀의 올리버와 기여 또는 개선 제안을 해 주신 사용자 여러분께 감사드립니다(전체 목록은 아닙니다):
바실리예프, 클라우스웅거, kdheerendra, 죠이젤, DWvanGeest, ajbrown, 윌슨디
이 미리보기를 다운로드하여 사용하려면 Maven (두 가지 모두 포함) 봄 스냅샷 및 카우치베이스 스냅샷 리포지토리):
