Couchbase를 사용한 키-값 데이터 모델링에 관한 게시물에서 주요 관심사는 다음과 같습니다:
- * 데이터 삽입 시기 및 참조 시기
- * 보조 인덱스 구축
- * 키 디자인.
N1QL의 세계에서 우리는 여전히 비슷한 것에 대해 생각하고 있으며, 이 글에서는 그 중 두 가지를 살펴볼 것입니다:
- * 문서 유형을 표현하는 방법
- * 문서 간의 관계를 모델링합니다.
근본적으로는 여전히 올바른 절충안을 만들어서 물리적 데이터 모델 논리 모델을 가장 효율적으로 표현합니다. 변경된 것은 몇 가지 구현 세부 사항뿐입니다.
아무것도 하지 않음
먼저, 변경할 필요 없이 기존 JSON 데이터를 쿼리할 수 있다는 점을 말씀드리고 싶습니다. N1QL은 기존 데이터베이스 전체를 개조할 것을 요구하지 않습니다.
하지만 모델을 변경하여 N1QL의 효율을 높이고 쿼리를 더 쉽게 작성할 수 있습니다. 그리고 처음부터 다시 시작하는 경우에는 처음부터 N1QL 쿼리 가능성을 고려하는 것이 좋습니다.
문서 유형
키-값 데이터 모델링에서 가장 중요한 부분 중 하나는 키 설계입니다. 키-값 세계에서 키는 무엇을 저장하고 있는지 알려주고 다시 쉽게 찾을 수 있어야 한다는 막중한 책임을 지고 있습니다.
예를 들어 고객 기록의 키는 다음과 같은 형식을 취할 수 있습니다:
* cust::name주요 고객 기록* cust::name::payment고객의 결제 세부 정보
리치 쿼리를 사용하면 키 이름의 역할이 변경됩니다. 키를 직접 요청하는 대신 원하는 데이터를 요청하게 됩니다. 저장하는 내용을 설명하고 데이터를 쉽게 찾을 수 있도록 하는 두 가지 책임이 문서 자체의 문서 유형으로 이동합니다.
여기서 N1QL과 SQL의 큰 실질적인 차이점 중 하나를 발견했습니다: 오늘날 N1QL에서 FROM은 더 적은 작업을 수행합니다. Couchbase 버킷의 범위는 일반적인 관계형 테이블의 범위와 크게 다릅니다.
SQL FROM은 관심 있는 데이터로 쿼리 범위를 좁힙니다. N1QL FROM은 쿼리 엔진에 어떤 버킷을 살펴볼지 알려줍니다. 일반적인 버킷에는 하나의 애플리케이션에 대한 모든 데이터가 포함되어 있으므로 문서 유형을 구분하는 다른 방법이 필요합니다.
고객
한 고객을 자세히 살펴보겠습니다. 다음은 간단한 기록입니다:
{
"이름": "앨런 파트리지",
"이메일": "alan@example.com",
"위치": "노리치",
"전화": "+44-1603-619-331",
"docInfo":
{
"type": "고객",
"created": "2015-10-22T10:17:24.731Z",
"schemaVersion": "1.2.3"
}
}
그리고 유형 값을 입력하여 N1QL 쿼리의 범위를 좁힙니다:
SELECT * FROM 기본값 WHERE 유형 = 고객;
사용 유형 를 사용하면 특정 유형의 문서만 포함하는 인덱스를 만들 수 있습니다. 예를 들어
기본값에 인덱스 고객 만들기 WHERE type=고객;
문서 스키마에 이미 유형이 지정되어 있을 가능성이 높으며, 특히 Couchbase 보기를 사용하고 있는 경우에는 더욱 그렇습니다. 어느 쪽이든 문서를 만들 때는 문서 본문 내에 유형을 지정해야 합니다.
향후 카우치베이스와 N1QL의 반복 작업에서는 버킷 수준 이하의 네임스페이스를 볼 수 있지만, 유형은 항상 저렴한 비용으로 문서를 구분할 수 있는 방법을 제공할 것입니다.
문서 간의 관계
에 대한 질문 임베드 시기 및 참조 시기 은 N1QL을 모델링할 때 여전히 중요한 요소입니다. 차이점은 N1QL은 JOIN을 통해 이러한 관계를 처리한다는 것입니다.
N1QL 조인은 그 사이에 이루어질 수 있습니다:
- * 다른 버킷에 있는 문서
- * 같은 버킷에 있는 문서
두 경우 모두 조인은 왼쪽에 있는 문서의 값을 오른쪽에 있는 문서의 키 이름과 일치시킵니다. 따라서 한 문서에 다른 문서의 키 이름이 포함되어 있는 경우 두 문서를 조인할 수 있습니다.
가상의 고객의 가장 최근 구매를 프로필에 추가해 보겠습니다:
{ lastPurchase: "prod::drivinggloves" }
여기의 값은 버킷의 다른 곳에 있는 제품 문서의 키 이름이기도 합니다.
따라서 Norwuch에 거주하는 모든 고객에 대해 고객의 이름과 마지막 구매 가격을 반환하려면 다음 N1QL을 사용합니다:
SELECT r.name, a.price FROM default r JOIN 기본값 a ON KEYS r.lastPurchase WHERE r.location = "Norwich";
결과는 다음과 같습니다:
{
"요청ID": "a2284985-541f-491d-b921-4c248f154293",
"서명":
{
"name": "json",
"price": "json" },
"결과":
[
{ "name": "앨런 파트리지",
"price": "9.99"
}
],
"상태": "성공",
"메트릭":
{
"elapsedTime": "5.223111ms",
"실행 시간": "5.124029ms",
"resultCount": 1,
"결과 크기": 77
}
}
N1QL을 사용하면 문서 간에 일대일, 일대다, 다대다 관계를 생성할 수 있습니다. 따라서 이전에는 임베디드 문서가 카우치베이스에서 데이터를 모델링하는 데 큰 부분을 차지했지만, N1QL을 사용하면 개발자가 쉽게 사용할 수 있습니다.
요약
이 게시물에서 주목해야 할 두 가지 주요 사항은 다음과 같습니다:
- 문서에는 쿼리에서 범위를 좁히는 데 사용할 수 있는 유형이 있어야 합니다.
- 조인은 왼쪽 문서의 본문에 나타나는 오른쪽 문서의 기본 키에 의존합니다.
궁극적으로 N1QL을 사용하기 위해 JSON 데이터에 대해 크게 변경할 필요는 없습니다. N1QL에 대해 더 자세히 알아가다 보면 다른 것보다 더 잘 작동하는 문서 형태를 발견하게 될 것입니다. 그렇다면 그 모양을 카우치베이스 포럼!
