MongoDB Data Modeling

개요

SQL에서는 정규화라는 개념이 존재하여 Data Modeling을 수행합니다.

Document Database인 MongoDB에서는 Data Modeling을 어떻게 수행할 수 있을까요?

 

 

Data Modling

데이터 모델링은 업무 수행 시 비즈니스 요구사항 등으로 발생하는 데이터를 효율적으로 데이터베이스에 저장하기 위해 데이터 구조를 설계하는 과정입니다.

 

MongoDB는 유연한 스키마 모델을 가질 수 있습니다.

• 컬렉션(테이블) 내에 문서가 동일한 필드 집합을 가질 필요가 없습니다.
• 필드의 데이터 유형은 문서마다 다를 수 있습니다.

 

어떻게 데이터 모델링을 수행하는가에 따라 데이터 정합성과 성능에 큰 영향을 주게 되므로 데이터 모델링에 대한 이해가 필요합니다.

 

 

Schema 설계

물론 운영을 하면서 유연하게 스키마를 수정할 수 있지만 프로덕션 환경의 대규모 스키마를 수정하는 것 어려울 수 있습니다.

초기 스키마를 잘 설계해 두면 성능과 확장성에 도움이 됩니다.

 

대게 3가지 방법으로 설계를 수행합니다.

• 애플리케이션이 가장 자주 실행하는 작업 식별하기
• Schema 관계 정의하기
• 디자인 패턴 적용하기

 

 

가장 자주 실행하는 작업 식별

가장 자주 실행하는 작업을 식별하게 되면 효과적인 인덱스를 만들고 데이터베이스를 호출하는 횟수를 최소화하는데 도움이 됩니다.

 

이때 현재의 요구사항과 미래의 요구사항을 고민하여 설계해야 합니다.

 

표로 정리해보기

https://www.mongodb.com/docs/manual/data-modeling/schema-design-process/identify-workload/#std-label-data-modeling-identify-workload

 

Action은 유저가 하는 행위, Information은 쿼리에서 작성되거나 반환되는 문서 필드를 뜻합니다.

Frequency는 얼마나 자주 일어나는지, Priority는 애플리케이션에서 중요도를 뜻합니다.

 

스키마 관계 정의하기

스키마들이 1:1, 1:N, N:M 등의 어떤 관계를 가지는지 정의하는 작업입니다.

 

애플리케이션에서 관련 데이터를 쿼리하고 반환하는 방식을 고려해야 합니다.

관련 데이터를 처리할 때 권장하는 방법은 관련된 데이터는 문서 내부에 Embedded로 포함시키는 것입니다.

join과 비슷한 연산을 하는 $lookup 작업을 피할 수 있습니다.

 

스키마 관계를 정의하는 방법

• $lookup이 필요하면 Embedded를 고려하자
• 관련 데이터를 자주 update 해야 하면 reference 방식으로 참조해서 쓰기 량을 줄이자

 

 

Embbeded vs Reference

embedded 방식

하나의 문서에 관련 데이터를 Embedded 할 수 있습니다.

위의 예제는 연락처 및 액세스 필드가 임베드된 문서입니다:

 

자주 조회하는 데이터는 여러 collection에 중복되어 있어 비정규화 될 수 있습니다.

 

Embedded의 장점

• 읽기 작업의 성능 향상
• 한 번의 데이터베이스 작업으로 관련 데이터를 검색할 수 있습니다.
• 단일 원자 쓰기 작업으로 관련 데이터를 업데이트할 수 있는 기능

References 방식

다른 문서를 식별할 수 있는 Id를 가짐으로써 관련 데이터에 액세스 하는 방법입니다.정규화된 데이터 모델로 볼 수 있습니다.

 

다음 상황을 고려해야 합니다.

• 중복된 데이터를 감수할 만큼 성능 이점이 크지 않을 때
• 복잡한 N:M 구조를 표현해야 하는 경우

 

 

디자인 패턴 적용하기

스키마 디자인 패턴은 애플리케이션의 액세스 패턴에 맞게 데이터 모델을 최적화하는 방법입니다.

어떤 스키마 디자인 패턴은 쓰기 성능을 향상하는 반면, 어떤 스키마 디자인 패턴은 읽기 성능을 향상합니다.

따라서 애플리케이션을 이해하고 적절한 디자인 패턴을 적용해야 합니다.

 

subset patterns, computed pattern 등을 적용해 볼 수 있습니다.

그 외에도 Polymorphic, Attribute, Bucket, Outlier 등 다양한 패턴등이 있습니다.

 

subset patterns

현대의 메모리 용량은 무한하지 않습니다.

메모리를 추가하면 해결할 수 있지만 확장성이 떨어지게 됩니다.

이럴 때 subset pattern을 활용해 볼 수 있습니다.

 

더 자주 액세스하는 데이터에 더 작은 문서를 사용함으로써 작업 세트의 전체 크기를 줄일 수 있습니다. 

예를 들어 제품의 리뷰가 1000개가 있을 때 상위 10건만 하위 문서로 관리함으로써 적은 양의 데이터를 빠르게 접근할 수 있습니다.

 

computed pattern

최신 Amazon Alexa의 총판매 수익은 얼마인가요?

최신 블록버스터 영화를 시청한 시청자 수는 몇 명인가요?

이러한 유형의 질문은 데이터베이스에 저장된 데이터로 답을 구할 수 있지만 계산을 해야 합니다.

 

정확한 수치를 알 필요가 없다면 백그라운드에서 계산을 수행하고 가끔 정보를 update 하면 됩니다.

이미 계산된 값을 제공한다면 CPU, 디스크, 메모리의 부하를 줄일 수 있습니다.

 

 

 

 

참고자료

https://meetup.nhncloud.com/posts/276

https://www.mongodb.com/basics/data-modeling

https://www.youtube.com/watch?v=BC-NahZ5jsY