MongoDB - (9) - 애플리케이션 설계

본 섹션은 내게는 굉장히 유의미한 섹션이 될 것이다.

따라서 다른 포스팅 처럼 대충하지 않고 열심히 해보겠다.

 

한 번에 전부 기술하지 않고 연결된 포스팅으로 아래사항을 다룰 것이다.

1. 스키마 설계 고려 사항
2. 데이터 embed 방식과 참조 방식 중 결정하기
3. 최적화를 위한 팁
4. 일관성 고려 사항
5. 스키마 마이그레이션 방법
6. 스키마 관리 방법
7. 몽고 DB가 데이터 스토리지로 적합하지 않은경우

 

스키마 설계 고려 사항

RDBMS와는 달리 스키마를 모델링하기 위해서는

• 쿼리
• 데이터 접근 패턴

을 이해해야한다.

 

다음은 설계 시 주요 요소이다.

• 제약 사항
• 쿼리 및 쓰기의 접근패턴
• 관계 유형
• 카디널리티

 

제약 사항

몽고 DB의 도큐먼트 최대 크기는 16MB이며

디스크에서 전체 도큐먼트를 읽고 쓴다.

갱신은 전체 도큐먼트를 다시 쓰며,

원자성 갱신은 도큐먼트 단위로 실행된다.

 

 

쿼리 및 쓰기의 접근 패턴

쿼리 수를 최소화하라.

함께 쿼리되는 데이터가 동일한 도큐먼트에 저장되도록 설계하라.

반대로 쿼리에 사용되지 않는 데이터는 다른 컬렉션에 넣어라.

동적(읽기/쓰기)데이터와 정적(대부분 읽기)데이터를 분리할 수 있으면 분리해라.

 

사실 이게 가장 중요하다.

 

 

관계 유형

Application의 요구 사항과 Documents간 관계 측면에서 어떤 데이터가 관련되어 있는지를 고려하라.

그런 다음 데이터나 도큐먼트를 내장하거나 참조할 방법을 결정한다.

추가로 쿼리하지 않고 도큐먼트를 참조하는 방법을 파악해야 하며

관계가 변경될 때 갱신되는 도큐먼트의 개수를 알아야한다.

또한 데이터가 쿼리하기 쉬운 구조인지도 고려하자.

 

카디널리티(Cardinality)

카디널리티는 데이터의 중복요소의 정도다.

age와 email 를 저장할 때,

age는 중간정도의 카디널리티를 갖고,

email은 고윳값 수준이기 때문에 매우 높은 카디널리티를 갖는다.

 

따라서 도큐먼트와 데이터 간의 카디널리티를 고려해야한다.

1:1, 1:M, N:M 등 관계를 고려해야하고,

개별적으로 접근되는지 혹은 상위 개체의 컨텍스트에서만 접근되는지 고려한다.

또한, 데이터 필드에 대한 읽기 갱신 비율도 고려해야한다.

 

다음 장에서 스키마 설계 패턴을 알아본다.

 

https://inventer.tistory.com/29

MongoDB - (7) - 집계 프레임워크