문서 데이터베이스에서 문서 구조 구성하기

Couchbase는 스키마가 없습니다. 이는 전통적인 RDBMS의 역사와 경험에 반하는 것이지만, NoSQL 데이터베이스에서 가장 호평을 받는 기능 중 하나로 입증되었습니다.

애플리케이션을 빌드하기 전에 스키마를 개발할 필요가 없으므로 시간을 크게 절약할 수 있습니다. 신속한 프로토타입 제작이 가능하고 애플리케이션 내에서 다양한 용도로 사용하면서 문서의 구조를 만들 수 있습니다.

그러나 필수적이고 공식적인 스키마가 없다고 해서 문서가 일관된 구조나 '내재적' 스키마를 가짐으로써 가치를 얻지 못하는 것은 아닙니다.

카우치베이스용 문서를 작성할 때 가장 중요한 고려 사항 중 하나는 데이터를 얼마나 세분화할 것인가, 즉 하나의 개념에 대해 하나의 문서 또는 여러 개의 문서로 분할할 것인가 하는 것입니다.

다음은 Couchbase에서 데이터를 구성하는 방법을 선택할 때 주요 의사 결정권자가 고려해야 할 사항입니다:

이 문서는 실제 생활에서 어떤 모습일까요?
우리의 경우에는 양조장과 그들의 맥주가 있습니다. 각각에 대한 명사가 있고 이전 게시물에는 각각에 대한 문서가 있었습니다. 자연스럽고 말이 되죠.

얼마나 자주 업데이트하나요?

양조장과 맥주는 상당히 정적인 주제입니다. 맥주에 대한 설명을 업데이트하거나 맥주 양조장의 주소를 변경하기보다는 맥주 포트폴리오에 맥주 문서를 추가할 가능성이 더 높습니다. 이러한 일이 발생하긴 하지만 주식 시세, 센서 데이터 또는 소셜 게임 활동과 비교하면 드문 경우입니다.

이 모든 데이터를 함께 업데이트하시겠습니까?
Couchbase에서 문서는 가장 작은 단위의 원자 수준입니다. Brewery와 Beer 데이터를 하나의 문서로 결합하면, Beer 데이터를 변경할 때마다 이를 포함하는 전체 Brewery 문서도 함께 전송해야 합니다. 모든 생성 및 업데이트 작업은 전체 컬렉션에서 마치 하나의 작업인 것처럼 이루어집니다. 이렇게 하면 서로 다른 업데이트를 하나의 간소화된 요청으로 통합할 수 있다는 장점이 있지만, 포함된 개념이 변경될 때마다 더 큰 규모의 업데이트가 필요하다는 단점이 있습니다.

현재 문서를 디자인할 때 사용할 수 있는 옵션은 두 가지입니다:

• 모든 고유 개념에 대해 하나의 문서
• 가장 큰 '컨테이너' 개념에 대한 하나의 문서

하지만 세 번째 옵션이 있습니다. 나중에 MapReduce를 사용해 표준 데이터를 결정하는 것입니다. 콘텐츠는 문서 중에서 표준 데이터가 무엇인지 나타내는 인덱스를 구축할 수 있는 '총계정원장'처럼 존재하도록 구조화될 수 있습니다. 또한 오래된 데이터가 활성 자료를 보는 방식에 미치는 영향에 대해 걱정할 필요 없이 과거(현재는 '오래된') 데이터를 데이터베이스에 남겨둘 수 있습니다. 이는 과거 데이터를 계속 사용하려는 경우에 유용할 수 있습니다. 이 경우 양조장 및 맥주 문서 모두에 양조장의 주소를 입력하면 맥주가 원래 양조장의 원래 위치에서 제조되었다는 사실을 찾을 수 있습니다. 흥미로운 옵션이 많습니다!

카우치베이스는 정규화 해제 친화적이므로 각 맥주 문서에 Brewery 데이터를 넣을 수 있습니다:

양조장 개체가 있는 맥주

이렇게 하면 요청 시간을 크게 절약할 수 있습니다. 또한 맥주가 처음 양조된 곳의 이력 기록으로도 사용할 수 있습니다(몇 년 후 양조장의 주소가 변경된 경우). 앱에서 표준 양조장 정보가 필요한 경우(오래된 데이터가 아닌 경우), 양조장 이름(적어도 이 앱에서는)으로 양조장 ID를 구성하고 권위 있는 양조장 문서에서 주소를 조회할 수 있습니다. 양조장 문서는 양조장에 대한 정보의 표준 소스가 될 것이며, 맥주 문서의 양조장 주소 정보는 과거 참조 자료로 사용될 수 있습니다.

장점:

• 맥주 문서를 받으면 한 번의 요청으로 양조장 정보를 얻을 수 있습니다.
• 맥주 문서에 대한 양조장 정보는 역사적 목적에 도움이 될 수 있습니다.
• 관계를 구성하기 위해 MapReduce 뷰 콜레이션을 사용할 필요가 없습니다.

단점:

• 최신 양조장 정보를 가져오려면 두 번째 요청 또는 멀티겟(두 ID를 모두 알고 있는 경우) 또는 MapReduce 보기가 필요합니다.

맥주 오브제가 있는 양조장

마지막 예시를 뒤집어 보겠습니다. 브루어리의 양조 맥주. 양조장에서 레시피를 공개하지 않았거나 공개했더라도 특별한 산수(또는 다른 무엇)로 특별한 방식으로 만든 특정 맥주는 해당 양조장 외에는 누구에게도 구할 수 없습니다. 그렇다면 모든 맥주를 브루어리 문서에 저장하는 것은 어떨까요?

이 새로운 구조가 어떻게 생겼는지 살펴봅시다. 처음 몇 줄은 원래 뉴 벨기에 브루잉 문서에서 가져온 것입니다. 새로 추가된 것은 '맥주' 키와 그 값으로 설정된 맥주 정보 객체입니다.

새로운 "beer" 자식 객체에는 앞서 본 맥주 문서의 키와 거의 동일한 ID를 사용하는 각 맥주에 대한 키가 있습니다("beer_" 접두사만 제외).

장점:

• 양조장과 그 맥주에 대한 단일(아마도 꽤 큰 규모의) 요청
• 데이터 정렬 보기를 사용하여 관계를 구성할 필요가 없습니다.

단점:

• 맥주 문서는 직접 검색할 수 없습니다(MapReduce 필요).
• 대형 양조장의 경우 응답 규모가 상당히 클 수 있습니다(소규모 양조장의 경우 +1!).

결론

이 두 가지 접근 방식 중 어느 것이든 사용 사례에 따라 유효할 수 있습니다. 하나의 결합된 문서 경로를 통해 관계 '패키지'를 빠르게 검색하려는 경우, 이 방법을 최적화하는 것이 좋습니다.

자유롭게 옵션을 고려하고 프로토타입을 제작해 보세요!

다음에는 원본 맥주 및 양조장 문서에서 색인을 작성하는 방법을 살펴보겠습니다. 계속 지켜봐 주세요!