문서 저장소와 키-값 저장소의 차이점은 무엇인가요?
문서 데이터베이스는 저장된 내용을 쿼리하고 조작할 수 있지만, 키-값 저장소에서는 값이 불투명한 미스터리로 남아 있습니다.
카우치베이스 서버 4.5에서는 새로운 하위 문서 API를 도입하여 문서의 본문에 대한 쿼리 및 변경 액세스를 강화했습니다.
하위 문서 기본 사항
그렇다면 Couchbase의 새로운 하위 문서 기능에 대한 요약은 무엇일까요?
- 문서의 일부를 검색합니다.
- 문서의 일부를 변경하여 변경 사항을 Couchbase Server로 전송합니다.
- 이제 모든 공식 Couchbase Server SDK에서 사용할 수 있습니다.
- 뷰에서 제공하는 쿼리와 N1QL에서 제공하는 쿼리 및 변형을 보완합니다.
자, 이제 그 이유에 대해 알아보겠습니다.
왜 하위 문서 작업인가요?
두 사람 간의 채팅 로그를 저장하는 1MB JSON 문서가 Couchbase에 있다고 가정해 보겠습니다. 채팅 참가자가 새로운 내용을 작성할 때마다 로그 문서에 추가하고 싶습니다.
하위 문서 작업이 없다면 그렇게 해야 합니다:
- 전체 문서 가져오기
- 애플리케이션에서 역직렬화
- 대화의 새 줄을 추가합니다.
- 다시 JSON으로 직렬화
- 전체 문서를 Couchbase에 다시 전송하여 저장합니다.
Couchbase의 Python 클라이언트를 사용하면 다음과 같이 보일 것입니다:
|
1 2 3 |
rv = cb.get('chatlog') # 전체 문서 보기 rv.doc.메시지 += ['nvm lol'] # 로컬에서 문서 수정하기 cb.대체(rv.키, rv.doc, cas=rv.cas) # 전체 문서 다시 업로드 |
꽤 낭비인 것 같네요. 이제 사람들이 인스턴트 메시징 대화에서 채팅하는 속도를 생각해 보세요. 그리고 얼마나 많은 채팅이 동시에 진행될 수 있는지 생각해 보세요.
카우치베이스 서버는 그 역할을 충실히 수행할 수 있지만 네트워크에 불필요한 부담을 주고 데이터베이스 계층 기능으로 간주할 수 있는 것을 처리하기 위해 애플리케이션 코드를 유지 관리해야 합니다.
하위 문서 작업을 사용하면 훨씬 더 적은 작업을 수행할 수 있습니다. 채팅 로그에 새 줄을 추가하는 것은 파이썬에서는 다음과 같이 보일 것입니다:
|
1 2 |
가져오기 카우치베이스.하위 문서 as SD cb.mutate_in('chatlog', SD.추가('메시지', 'nvm lol')) |
변경할 문서와 문서 내 위치를 지정하여 새 줄을 Couchbase Server로 보냅니다.
이렇게 하면 왕복 작업을 피하고, 변경된 내용만 전송하여 네트워크 대역폭을 절약하며, 문서 업데이트 책임을 애플리케이션에서 데이터베이스 계층으로 옮길 수 있습니다.
하위 문서 작업의 작동 방식
Couchbase SDK는 세 가지 API를 사용하여 Couchbase Server와 함께 작동합니다:
- 키-값, 멤캐시드 바이너리 프로토콜 사용
- 보기, CouchDB REST 프로토콜 사용
- N1QL의 REST 프로토콜을 사용합니다.
SDK는 세부 사항을 추상화하지만 Couchbase Server로 작업한 적이 있다면 어떤 유형의 상호 작용을 하고 있는지 알고 있습니다.
하위 문서 작업은 키-값 연산을 처리하는 멤캐시드 프로토콜의 확장을 사용하여 이루어집니다.
하위 문서 찾기
하위 문서 작업을 수행하려면 두 가지가 필요합니다:
- 문서 키
- 상위 문서 내 하위 문서의 경로입니다.
경로란 무엇을 의미하나요?
경로는 문서 내에서 작업을 수행하려는 위치로, N1QL에서 사용하는 것과 동일한 표기법입니다.
간단한 온라인 스토어의 고객 프로필로 작업한다고 가정해 보겠습니다. 다음은 프로필 문서의 예시입니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
{ "name": "더글러스 레이놀름", "이메일": "douglas@reynholmindustries.com", "주소": { "청구": { "line1": "123 애니 스트리트", "line2": "애니타운 ", "country": "영국" }, "delivery": { "line1": "123 애니 스트리트", "line2": "애니타운 ", "country": "영국" } }, "구매": { "완료": [ 339, 976, 442, 666 ], "버려진": [ 157, 42, 999 ] } |
고객의 배송 주소에 있는 국가 필드의 경로가 됩니다:
|
1 2 |
주소.배달.국가 |
마찬가지로 구매 내역이 신규 구매부터 이전 구매까지 나열된 경우 고객의 두 번째로 최근 구매의 ID를 찾습니다:
|
1 2 |
구매.완료[1] |
따라서 하위 문서는 우리가 제공한 경로에서 문서의 어느 부분이든 찾을 수 있습니다. 거대한 객체일 수도 있고 배열의 단일 인덱스일 수도 있습니다.
하위 문서 작업 사용
버킷 수준에서는 정말 간단합니다. 두 가지 새로운 방법만 있으면 됩니다:
- 룩업인(키)
- mutateIn(키).
Java SDK에서는 빌더 패턴을 사용하여 구현됩니다. 따라서 이 두 버킷 메서드는 특정 문서에 연결된 객체를 생성하여 하위 문서를 쿼리하거나 변경하는 실제 작업을 수행할 수 있도록 합니다.
Java로 고객의 배송 주소를 찾는 예제를 살펴보겠습니다.
|
1 2 |
룩업인빌더 빌더 = 카우치베이스.버킷().룩업인('customer123'); |
먼저 고객의 문서로 프라이밍된 빌더 객체를 생성합니다. 그런 다음 해당 빌더 문서에서 하위 문서 작업을 수행할 수 있습니다.
|
1 2 3 |
빌더 = 빌더.get("addresses.delivery"); 문서 조각 결과 = 빌더.doLookup(); |
이 글의 앞부분에 있는 샘플 JSON 문서를 사용하는 경우, 결과 가 될 것입니다:
|
1 2 3 4 5 6 |
{ "line1": "123 애니 스트리트", "line2": "애니타운 ", "country": "영국" } |
이 쿼리는 모든 것을 하나로 연결하여 단순화할 수 있습니다:
|
1 2 3 4 |
문서 조각 결과 = 카우치베이스.버킷().룩업인('customer123') .get("addresses.delivery") .doLookup(); |
더 복잡한 쿼리와 변형을 구축할 때 많은 연산을 함께 연결할 수 있습니다. Java SDK에서, doLookup 는 쿼리의 끝을 나타내며 실행을 위해 쿼리를 전송합니다.
앞서 인스턴트 메시징 예제에서 살펴본 것처럼 하위 문서 API를 사용하여 문서를 수정할 수도 있습니다.
고객 청구 주소의 일부를 변경하고 싶다고 가정해 보겠습니다. Python에서는 하위 문서 API를 사용하여 다음과 같이 변경할 수 있습니다:
|
1 2 3 4 5 |
가져오기 카우치베이스.하위 문서 as SD cb.mutate_in('customer123', SD.업서트('billing.line1', '123 Main St'), SD.업서트('billing.line2', '어딘가')) |
Java에서와 마찬가지로 먼저 키로 문서를 선택한 다음 그 내용에 대해 일련의 연산을 수행합니다.
다음 단계
원하는 언어로 하위 문서 API를 사용하는 방법에 대한 자세한 내용은 업데이트된 SDK 설명서를 참조하세요.
곧 게시될 마크의 글에서 하위 문서 API 사용에 대해 자세히 설명하는 글도 읽어보실 수 있습니다.
