행사에 나가면, 둘 다 NoSQL 영역에 속하고 문서 데이터베이스이기 때문에 MongoDB와 Couchbase Server의 차이점에 대한 질문을 많이 받습니다. 특히 데이터 모델링과 관련된 질문이 많습니다. MongoDB는 BSON을 사용하고 Couchbase는 JSON을 사용하므로 데이터 모델이 다르지 않을까요?
몇 가지 MongoDB 문서 모델을 살펴보고 최소한의 노력으로 Couchbase에서 동일한 작업을 수행하는 방법을 살펴보겠습니다.
먼저 두 가지를 말씀드리겠습니다. MongoDB 그리고 카우치베이스 에는 NoSQL 문서 모델링에 대한 훌륭한 문서가 있습니다. 두 문서 모두 비슷한 일련의 사례를 참조하고 있습니다.
임베디드 데이터 모델
중첩된 객체와 중첩된 배열이 있는 엄청나게 복잡한 NoSQL 문서를 사용할 수 있으므로 관계형 데이터베이스와는 조금 다른 방식으로 작업을 수행할 수 있습니다.
다음 몽고DB 문서를 예로 들어보겠습니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
{ "_id": <ObjectId>, "first_name": "Nic", "last_name": "Raboy", "address": { "city": "Mountain View", "state": "California" }, "social_media": [ { "type": "twitter", "url": "https://www.twitter.com/nraboy" }, { "type": "mastodon", "url": "https://toot.cafe/@nraboy" } ] } |
위의 예에서는 일부 MongoDB 컬렉션의 객체 ID로 정의된 단일 문서에 중첩된 객체와 배열을 포함시켰습니다.
Couchbase에서는 동일한 MongoDB 문서가 다음과 같이 보일 수 있습니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
{ "_type": "person", "first_name": "Nic", "last_name": "Raboy", "address": { "city": "Mountain View", "state": "California" }, "social_media": [ { "type": "twitter", "url": "https://www.twitter.com/nraboy" }, { "type": "mastodon", "url": "https://toot.cafe/@nraboy" } ] } |
위의 Couchbase 예제는 MongoDB 예제와 거의 동일하지만 _id 속성이 되는 _유형 속성으로 설정합니다. Couchbase에서 문서 ID는 문서 자체에 존재하지 않고 메타 속성으로 존재합니다. 카우치베이스에는 컬렉션이라는 개념이 없기 때문에 일반적으로 문서를 유형 속성으로 구분하지만, 반드시 필요한 것은 아닙니다.
객체와 배열을 단일 문서에 포함하면 데이터에 대한 일반적인 작업을 수행하는 데 필요한 단계가 제한되므로 유용합니다. 하지만 문서가 커지면 성능이 문제가 될 수 있습니다.
다음 문서 모델링 접근 방식은 바로 여기에서 시작됩니다.
정규화 또는 참조 데이터 모델
관계형 데이터베이스를 사용하는 사람이라면 누구나 데이터베이스 내의 여러 테이블에서 데이터를 정규화해야 한다는 것을 알고 있습니다. 그런 다음 데이터에 함께 액세스해야 할 때 이러한 테이블은 어떤 방식으로든 조인됩니다.
이 개념은 관계형 데이터베이스에서 볼 수 있는 것과 완전히 동일하지는 않더라도 NoSQL에서도 여전히 적용될 수 있습니다.
첫 번째 예로 돌아가서, MongoDB가 정규화된 데이터 모델이라고 부르는 작업을 해보겠습니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
{ "_id": <ObjectId1>, "first_name": "Nic", "last_name": "Raboy", "address": <ObjectId2>, "social_media": [ { "type": "twitter", "url": "https://www.twitter.com/nraboy" }, { "type": "mastodon", "url": "https://toot.cafe/@nraboy" } ] } |
임베디드 모델은 다음을 이동하여 약간 변경되었습니다. 주소 를 자체 문서에 추가할 수 있습니다. 이 경우 주소 속성은 이제 개체 ID와 같으며 새 문서는 다음과 같이 표시됩니다:
|
1 2 3 4 5 |
{ "_id": <ObjectId2>, "city": "Mountain View", "state": "California" } |
문서를 여러 개의 문서로 분할하면 여러 영역에서 도움이 될 수 있습니다. 이제 문서 크기가 더 작아지고 문서 작업이 더 빨라질 수 있습니다. 또한 임베디드 모델에서 발생할 수 있는 데이터 중복에 대한 걱정 없이 여러 사람이 동일한 주소에 존재할 수 있다는 점에서 데이터는 이제 정규화됩니다.
몽고DB 문서에 따라:
... 그러나 클라이언트 측 애플리케이션은 참조를 해결하기 위해 후속 쿼리를 실행해야 합니다. 즉, 정규화된 데이터 모델은 서버에 더 많은 라운드 트립이 필요할 수 있습니다.
애플리케이션 계층은 정규화된 모델의 관계를 관리할 책임이 있습니다. 또한 애플리케이션은 데이터베이스에 대해 더 많은 요청을 해야 합니다.
이제 정규화된 모델은 카우치베이스에서 어떤 모습일까요? 정규화 모델이라고 부르는 대신 Couchbase에서는 참조 모델이라고 부르기도 하며, 다음과 같이 보일 것입니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
{ "_type": "person", "first_name": "Nic", "last_name": "Raboy", "address": "address1", "social_media": [ { "type": "twitter", "url": "https://www.twitter.com/nraboy" }, { "type": "mastodon", "url": "https://toot.cafe/@nraboy" } ] } |
ID는 메타 정보로 저장되며 대부분의 문서에는 어떤 유형의 문서인지 정의하는 속성이 있습니다. 문서의 주소 속성을 다른 문서에 대한 키로 사용하고 있습니다. 개념은 몽고DB의 객체 ID와 동일하지만, 몽고DB에서 객체 ID는 데이터 유형입니다.
주소 데이터가 포함된 문서를 보면 다음과 같은 내용이 있습니다:
|
1 2 3 4 5 |
{ "_type": "address", "city": "Mountain View", "state": "California" } |
위 문서의 문서 키 또는 ID는 다음과 같습니다. 주소1 를 다른 문서에서 예상되는 것과 일치하도록 수정합니다.
하지만 여기서 중요한 점이 있습니다. 카우치베이스에서 참조된 문서는 애플리케이션 계층이 처리하도록 강요하지 않고 N1QL을 통해 단일 서버 측 작업으로 결합할 수 있습니다.
결론
제가 한 문장으로 요약할 수 있는 것은 MongoDB의 데이터 모델링과 Couchbase의 데이터 모델링이 동일하다는 것입니다. BSON을 사용하든 JSON을 사용하든 상관없이 개념은 둘 다에 적용됩니다. MongoDB에서 Couchbase로 전환할 경우, MongoDB 문서에 대해 알고 있던 모든 것을 그대로 이어받을 수 있습니다.
핵심적인 차이점은 문서를 쿼리하는 방식에 있습니다. 문서 모델링 방식에 관계없이 N1QL 및 기타 쿼리 전략을 통해 Couchbase에서 데이터를 쿼리하는 것이 훨씬 더 쉽습니다.
제가 녹화한 모델링 및 쿼리 동영상을 보고 싶으시다면 다음 동영상을 확인해 보세요. 여기.
카우치베이스 사용에 대한 자세한 내용은 다음을 참조하세요. 카우치베이스 개발자 포털 예제 및 기타 문서가 포함되어 있습니다.
