지난번 테이블 행당 하나의 문서를 사용하여 Couchbase에서 SQL 테이블을 매우 원시적이고 간단하게 가져올 수 있게 되었습니다. 하지만 아직 해야 할 일이 남아 있습니다. 이 과정에서 기본 키가 변경되었으므로 이를 수정해야 합니다. 그리고 SQL 데이터베이스에는 테이블만 있는 것이 아닙니다. 비즈니스 로직을 전달하는 다른 구조와 함수가 있으며 애플리케이션 계층으로 이동해야 합니다.
JOIN
가져오기 후 가장 먼저 하고 싶은 작업은 문서에서 JOIN을 실행하는 것인데, 이는 본질적으로 정확한 매핑이므로 SQL 데이터베이스에서도 동일한 방식으로 수행할 수 있습니다. N1QL 쿼리를 직접 실행하는 것만큼 간단하지는 않습니다. N1QL의 JOIN은 문서의 키에서만 작동하며, 충돌을 피하기 위해 가져올 때 키를 변경했습니다. 따라서 다른 외래 키를 변경해야 합니다. 좋은 소식은 N1QL 데이터 조작 언어를 사용하면 정말 쉽게 할 수 있다는 것입니다. 다음에 대한 지원이 있습니다. 업데이트, MERGE, 삽입 또는 UPSERT.
1 |
cbq> 업데이트 기본값 d SET language_id = "언어::" || 토스트링(d.language_id) 어디 _tableName = "film"; |
이 쿼리는 버킷 기본값에 있는 _tableName 필드가 "film"으로 설정된 모든 문서의 language_id 필드를 변경합니다. language_id는 숫자 유형 필드에서 문자열로 바뀝니다. 1이었다면 이제 "language::1"이 됩니다. 이것은 문서의 실제 키에 해당하며, RowMapper가 추가한 것이기 때문입니다.
'||' 연산자는 문자열 연결에 사용됩니다. 그리고 language_id는 숫자이기 때문에 이를 변환하려면 toString 메서드를 사용해야 합니다. 데이터베이스의 모든 외래 키에 대해 이 쿼리를 실행해야 합니다. 그런 다음 JOIN, NEST 및 UNNEST를 사용하여 N1QL 쿼리를 실행할 수 있어야 합니다.
1 2 3 4 |
cbq> 선택 * FROM `기본값` AS a JOIN `기본값` AS b 켜기 키 a.language_id; cbq> 선택 * FROM `기본값` AS a NEST `기본값` AS b 켜기 키 a.language_id; |
시퀀스, 보기, 트리거, 도메인 및 함수
SQL 데이터베이스에서 Couchbase로 직접 마이그레이션할 수 없는 것이 몇 가지 있습니다. 좀 더 구체적으로 말하면, SQL 데이터베이스에 있던 모든 비즈니스 로직을 애플리케이션 계층으로 옮겨야 합니다. 어떤 것은 다른 것보다 더 간단하게 이동할 수 있습니다. 데이터 계층에 비즈니스 로직을 두는 것이 좋은지 아닌지는 여러분이 결정할 수 있습니다. 개인적으로 선호하지는 않지만, 다양한 앱이 동일한 데이터베이스를 사용할 수 있으므로 DB 수준에서 표현되는 제약이 좋은 것일 수 있다는 것을 이해합니다. 저는 이러한 앱이 데이터베이스로 바로 이동하는 대신 서비스에 의존해야 한다고 생각합니다.
시퀀스
시퀀스는 다음과 같이 볼 수 있습니다. 원자 카운터를 사용하여 간단하게 만들 수 있습니다:
1 2 3 4 5 6 |
제이슨롱도큐먼트 rv = 버킷.카운터(키, 20, 100); 로거.정보("델타=20, 이니셜=100. 현재 값은 " + rv.콘텐츠()); rv = 버킷.카운터(키, 1); 로거.정보("델타=1. 현재 값은 " + rv.콘텐츠()); |
조회수
SQL 뷰는 SQL 쿼리의 결과로 생성된 동적 테이블로 볼 수 있습니다. Couchbase에서는 보기 는 증분 맵/축소 함수를 사용하여 동적으로 생성되는 인덱스(인덱스를 두 열의 테이블이라고 생각하세요)로, 대부분 뷰의 복잡성에 따라 달라집니다. 뷰는 데이터를 다른 컨텍스트에 표시하는 데 사용됩니다. NoSQL에서는 그렇게 하려면 데이터를 비정규화하기 시작하여 데이터를 복제합니다. 따라서 작업 시 주의해야 합니다. 이 데이터를 자주 수정해야 하는 경우 비정규 정규화는 좋은 생각이 아닐 수도 있습니다(현재 작업 중인 SubDocument API에서는 상황이 달라질 수 있지만). 다음은 보기의 예시를 통해 아이디어를 얻을 수 있습니다:
도메인
SQL 도메인은 제약 조건이 통합된 새로운 유형(기존 유형에 기반)입니다. 제 SQL 샘플에서는 type이라는 새 도메인이 다음과 같이 정의되어 있습니다:
1 2 3 4 5 6 7 |
만들기 도메인 public.년 AS 정수 컨스트레인트 년도_확인 확인 (VALUE >= 1901 AND VALUE <= 2155); ALTER 도메인 public.년 소유자 TO postgres; |
기존 정수 타입에서 연도라는 새로운 타입을 정의합니다. 연도 값은 1901에서 2155 사이여야 한다는 제약 조건을 추가합니다. 이 제약 조건을 Java로 표현하려면 다음과 같은 유효성 검사 프레임워크를 사용할 수 있습니다. 최대 절전 모드 유효성 검사기. 연도 유형은 다음과 같습니다:
1 2 3 4 |
@Min(1901) @최대(2155) 비공개 int 년; |
트리거
트리거는 데이터베이스에서 특정 INSERT, DELETE 또는 UPDATE와 같은 특정 작업이 발생할 때 실행되는 SQL 함수입니다. 데이터의 무결성을 강화하거나 작업을 자동화할 수 있는 좋은 방법입니다. Couchbase Server에는 이와 유사한 기능이 없으므로 애플리케이션 계층으로 이동해야 합니다. 예를 들어 애플리케이션 이벤트 버스를 사용하여 이를 재현할 수 있습니다. 이것은 아마도 Couchbase를 사용하여 수행할 수 있습니다. DCP
기능
대부분의 SQL 데이터베이스에서는 사용자가 직접 함수를 정의할 수 있습니다. 현재 N1QL에서는 이것이 불가능합니다. 해당 함수에 넣는 모든 로직은 애플리케이션 계층에 넣어야 합니다.
결론
이제 SQL 데이터베이스에서 Couchbase로 간단하게 마이그레이션하는 방법에 대해 어느 정도 이해하셨을 것입니다. 이것이 얼마나 간단한 마이그레이션 경로인지 아무리 강조해도 지나치지 않습니다. 여기에는 데이터 모델링이 필요하지 않습니다. 전체 마이그레이션에는 데이터 모델을 잘 살펴보고 무엇을 비정규화할 수 있는지 확인해야 합니다.
아래 댓글로 여러분의 의견을 알려주세요. 예를 들어 이미 SQL 마이그레이션을 수행하셨다면 어떻게 수행하셨는지 알려주시면 기쁩니다.)