[MongoDB] 스키마를 설계해보자

NoSQL 에서 스키마?

NoSQL 은 스키마라는 개념이 없다.

그래서 NoSQL 인 MongoDB 에서 스키마를 설계한다는 말이 이해가 안 될 수 있다.

 

우선 RDBMS 와 같은 스키마 개념은 없다고 보는게 맞다.

엄밀이 비유하면 Table 은 Collection , Row 는 Document 로 표현은 가능하지만 그렇다고 스키마를 설계하지는 않는다.

 

그렇다면 여기에서 말하는 스키마란 무엇일까?

 

 

MongoDB 스키마 디자인

MongoDB 스키마 디자인은 RDBMS 의 디자인과 많이 다르게 작동한다.

 

먼저 규칙, 정규화에 대한 개념이 없고 Document 에 Key-Value 구조로 저장된다.

 

아래 데이터의 경우 RDBMS 라면 정규화를 거쳐 배열데이터를 별도의 테이블/로우로 분리 할 수도 있지만

MongoDB 는 모든 데이터를 하나의 Document 에 담고 한번에 불러온다.

{
  "Site": "Tistory",
  "BlogName": "Mozi",
  "Catalog": ["Oracle", "MySQL", "MongoDB"],
  "Title": [
    {
      "Catalog": "MongoDB",
      "Name": "Title1"
    },
    {
      "Catalog": "MongoDB",
      "Name": "Title2"
    }
 }

 

그러나 이 Document 를 _id 를 참조하는 방식으로 설계할 수는 있다.

 

 

MongoDB 임베딩과 참조

임베딩

위와 같이 하나의 Document 에 모든 데이터를 담는 방식이다.

# Document 1

{
  "_id": "A12",
  "Name": "Mozi",
  "Category": "MongoDB",
  "Title": "MongoDB Schema"
}

 

참조

Doucment 를 생성하면 _id 라는 고유한 값이 생성된다.

다른 Document 에서 이 _id 값을 참조로 넣는 방식이다.

# Document 1

{
  "_id": "A12",
  "Name": "Mozi",
}

# Document 2
{
  "_id": "TX10",
  "Category": "MongoDB",
  "Title": "MongoDB Schema",
  "ParentId": "A12"
}

	임베디드	참조
장점	하나의 호출로 모든 관련된 정보를 확인 애플리케이션 코드에서 조인 구현 불필요 관련 정보를 단일 원자성 작업으로 업데이트	하나의 Document 는 작은 문서를 갖게 됨 16MB 제약도달 가능성 낮아짐 자주 액세스하지 않는 정보는 호출하지 않음 데이터 중복량을 줄일 수도 있음
단점	대부분 필드가 의미없을 때 많은 오버헤드 발생 하나의 Document 크기는 16MB 가 최대로, 너무 많은 데이터를 담으면 잠재적 제한에 도달	최소 두개의 쿼리

 

언제사용해?

그럼 언제 임베딩을 언제 참조를 사용해야 좋을까?

	모델
1:1 관계	임베딩
1:N ( Few or Many )	임베딩
1:N ( Squillions  )	참조
N:N	참조

 

 

 

 

 

참고자료

https://www.mongodb.com/developer/products/mongodb/mongodb-schema-design-best-practices/

MongoDB Schema Design Best Practices | MongoDB