스프링 부팅 및 스프링 데이터를 사용한 카우치베이스

새로운 기술을 사용하기 시작하려는 사람들에게 가장 큰 장벽 중 하나는 보통 학습 곡선입니다. 종종 새로운 프로젝트를 시작할 때 초반의 마찰을 피하기 위해 이미 알고 있는 것을 사용하게 되는 경우가 많습니다.

저는 대부분의 경력을 Java 개발자로 일해 왔으며 지난 몇 년 동안 저는 JPA + 스프링 부팅 + 롬복 + 스프링 데이터 조합을 사용했지만 여전히 저를 괴롭히는 한 가지는 관계 매핑이었습니다.

JPA는 데이터베이스에서 불필요한 데이터를 로드하는 것으로 유명하며, 시간이 지남에 따라 일부 엔터티를 다시 방문하여 몇 가지 관계를 EAGER에서 LAZY로 변경해야 합니다. 불필요한 조인을 많이 피할 수 있으므로 성능이 크게 향상될 수 있지만 공짜로 제공되는 것은 아닙니다. 새로운 지연 객체가 필요할 때마다 이를 로드하려면 많은 리팩터링을 수행해야 합니다.

이 일반적인 패턴은 항상 저를 괴롭혔는데, 스프링 데이터와 카우치베이스가 연결될 수 있다는 사실을 알게 되었을 때 정말 기뻤습니다(전체 문서 보기). 관계형 데이터베이스에서 하는 것처럼 프로그래밍할 수 있으면서도 Couchbase의 모든 속도와 N1QL의 강력한 기능을 활용할 수 있는 두 세계의 장점을 모두 누릴 수 있습니다. 간단한 프로젝트를 설정하는 방법을 살펴보겠습니다.

Spring 데이터, Spring Boot 및 Couchbase 설정하기

전제 조건:

• 이미 Couchbase가 설치되어 있다고 가정하고, 설치되어 있지 않다면 다음과 같이 하세요. 여기에서 다운로드
• 저도 롬복을 사용하고 있으므로 IDE에 롬복의 플러그인을 설치해야 할 수도 있습니다: E클립 그리고 IntelliJ 아이디어

먼저, 내 프로젝트를 복제할 수 있습니다:

로 이동하거나 스프링 부팅 이니셜zr 를 클릭하고 종속성으로 Couchbase와 Lombok을 추가합니다:

참고: 롬복은 필수 종속 요소는 아니지만 코드 기반을 크게 줄이는 데 도움이 됩니다.

이제 버킷 구성을 정의해 보겠습니다. application.properties file:

여기까지입니다! 이미 다음을 사용하여 프로젝트를 시작할 수 있습니다:

엔티티 매핑

지금까지 우리 프로젝트는 아무것도 하지 않습니다. 첫 번째 엔티티를 생성하고 매핑해 보겠습니다:

• • @Document: 엔티티를 정의하는 카우치베이스의 어노테이션은 다음과 유사합니다. 엔티티 를 추가합니다. 카우치베이스는 자동으로 다음과 같은 프로퍼티를 추가합니다. _class 를 문서에 추가하여 문서 유형으로 사용하세요.
  • @Data:  롬복의 어노테이션, 게터 및 세터 자동 생성
  • @AllArgsConstructor: 롬복의 어노테이션, 클래스의 모든 필드를 사용하여 생성자 자동 생성, 이 생성자 테스트에 사용되었습니다..
  • 노아르그 생성자: 롬복의 어노테이션, 인수가 없는 생성자 자동 생성(스프링 데이터에 필요)
  • @EqualsAndHashCode: 롬복의 어노테이션, 자동 생성 등호 및 해시코드 메서드도 테스트에 사용되었습니다.
  • @NotNull: 예! Couchbase에서 javax.validation을 사용할 수 있습니다.
  • @Id: 문서의 핵심
  • @Field:  Couchbase의 주석은 다음과 유사합니다. 칼럼

Couchbase에서 엔티티 매핑은 매우 간단하고 직관적이며, 여기서 가장 큰 차이점은 필드 엔티티는 3가지 다른 방식으로 사용됩니다:

• 단순 속성: 다음과 같은 경우 id, 이름 그리고 companyId, 의 필드 와 매우 유사하게 작동합니다. 칼럼 를 입력합니다. 문서에 간단한 속성이 생성됩니다:

• 배열: 전화 번호의 경우 문서 내부에 배열이 생성됩니다:

• 엔티티: 마지막으로 영역의 경우입니다, 필드 처럼 작동합니다. @ManyToOne 관계와 가장 큰 차이점은 Area 엔티티에 아무것도 매핑할 필요가 없다는 점입니다:

리포지토리

리포지토리는 표준 Spring 데이터 리포지토리와 매우 비슷해 보이지만 몇 가지 추가 주석이 있습니다:

• @N1qlPrimaryIndexed: 이 주석 는 현재 리포지토리와 연결된 버킷에 N1QL 기본 인덱스가 있는지 확인합니다.
• @ViewIndexed:  이 주석 를 사용하면 디자인 문서의 이름과 보기 이름은 물론 사용자 지정 맵과 축소 기능을 정의할 수 있습니다.

위의 리포지토리에서 우리는 카우치베이스 페이징 및 정렬 저장소를 추가하여 쿼리의 페이지 매김을 지정할 수 있습니다. 페이지 가능 매개변수를 메서드 정의의 끝에 추가합니다.

기본적으로 리포지토리이기 때문에 모든 Spring 데이터 키워드 같은 FindBy, 사이, IsGreaterThan, 좋아요, 존재등을 지원합니다. 따라서 사전 지식이 거의 없어도 Couchbase 사용을 시작하고도 생산성을 높일 수 있습니다.

이미 알고 계시겠지만, 완전한 N1QL 쿼리와 비슷하지만 구문 설탕이 몇 가지 있습니다:

• #(#n1ql.bucket):  이 구문을 사용하면 쿼리에서 버킷 이름을 하드코딩하지 않아도 됩니다.
• #{#n1ql.selectEntity}: 구문-설탕에 SELECT * FROM #(#n1ql.bucket):  
• #{#n1ql.filter}: 구문-설탕을 사용하여 문서를 유형별로 필터링하는 것은 엄밀히 말하면 class = 'myPackage.MyClassName' (_class 는 스프링 데이터에서 카우치베이스로 작업할 때 문서에 자동으로 추가되어 유형을 정의하는 어트리뷰트입니다.)
• #{#n1ql.fields} 는 엔티티를 재구성하는 데 필요한 필드 목록(예: SELECT 절의 경우)으로 대체됩니다.
• #{#n1ql.delete} 는 다음에서 삭제 문으로 대체됩니다.
• #{#n1ql.반환} 는 엔티티를 재구성하는 데 필요한 반환 절로 대체됩니다.

N1QL의 멋진 기능 중 일부를 보여드리기 위해 리포지토리의 두 가지 방법을 조금 더 자세히 살펴보겠습니다: 전화 번호로 찾기 그리고 findByCompanyAndAreaId:

전화 번호로 찾기

위 사례에서는 단순히 전화번호로 건물을 검색하고 있습니다. 관계형 세계에서는 거의 동일한 작업을 수행하려면 일반적으로 2개의 테이블이 필요합니다. Couchbase를 사용하면 모든 것을 단일 문서에 저장할 수 있으므로 "건물"을 로드하는 속도가 다른 RDBMS를 사용할 때보다 훨씬 빨라집니다.

또한 다음과 같은 방법으로 쿼리 성능을 더욱 빠르게 향상시킬 수 있습니다. 전화 번호 속성에 인덱스 추가하기.

회사별 및 지역 ID 찾기

위의 쿼리에서 우리는 기본적으로 임의의 하위 노드(Area)를 제공하는 루트 노드(Building)를 찾으려고 합니다. Area에는 다른 영역의 목록도 포함될 수 있으므로 데이터는 트리로 구조화됩니다:

이러한 유형의 쿼리는 관계형 데이터베이스로 작업할 때 가장 비용이 많이 들고 복잡한 작업 중 하나이며, 대부분의 경우 루트 노드를 찾거나 손으로 또는 유니온 그리고 연결된 사람.

여기에서 다음과 같은 마법의 키워드를 사용하여 이 문제를 해결할 수 있습니다. WITHIN.

서비스

기본적으로 평소와 같이 서비스에 리포지토리를 삽입하고 사용하지만, 다음 방법을 사용하여 Couchbase의 특정 리포지토리 기능에 추가로 액세스할 수 있습니다. getCouchbaseOperations()

모든 것이 작동 중

서비스 사용은 사용자가 기대하는 대로 이루어집니다:

통합 테스트 클래스를 확인하세요. 빌딩 서비스 통합 테스트 를 클릭하세요.

궁금한 점이 있으면 다음 주소로 트윗해 주세요. @deniswsrosa 에 질문하거나 포럼