[MongoDB] [Study11] 모델링

Document 관계 유형

• 1:N 관계
• 예시) 게시판과 게시글 관계
• 임베디드 방식으로 관계를 표현 가능

샘플
{
    _id:ObjectId()
    , 이름 : 자유게시판
    , 게시글 : [ { no : 1
        , 제목 : 첫번째글
        , 내용 : 편하네요
        } ,
        { no : 2
        , 제목 : 두번째글
        , 내용 : 편하네요2
        }
    ]
}

• 하지만 하나의 Document 크기가 커지면 이 때 2개의 Collection으로 1:N 관계로 변경을 고려.
• N:N 관계
• 예시) 게시글과 사용자 관계
• 조회를 해야 하는 경우 별도의 조회용 Collection 을 생성하여 조회를 해야하는 정보들을 미리 저장하고 있다가, 해당 Collection 조회 결과 값을 이용하여 찾는 방식
• 이렇게 하면 별도의 조회용 Collection과 게시글 또는 사용자와 관계가 1:N 관계로 엮임
• 또는 게시글 Document에 조회  field를 생성하여 배열로 구성 가능
• 1:1 관계
• 예시)사용자와 포인트 관계
• 이럴 때에는 사용자 Document에 포인트 정보를 포함하면 간단. (조인을 줄이는게 목적)
• 하지만 하나의 Document 크기가 커지면 이 때 2개의 Collection으로 1:1 관계로 변경을 고려.

MongoDB 모델링

• 유연한 스키마
• Insert 하기 전 Schema를 정의할 필요 없음
• 문서를 Entity 또는 Field에 쉽게 매핑 가능
• Collection 에 유효성 검사 적용 가능 (schema-validation 참고(https://docs.mongodb.com/manual/core/schema-validation/) )

 

Atomicity of Write(원자성) 작업

• 하나의 Document에 대해서는 원자성을 보장
• updateMany 의 경우 처럼 여러 (multiple) document에 수정을 할 때 하나씩(single) document에 대해서는 원자성을 보장하지만, 전체에 대해서는 원자성을 보장하지 않음 (하나하나씩 진행 하기 때문)
• Multiple 에 대해 원자성을 보장받기 위해서는 Transaction 을 이용하여 진행이 필요
• Transaction 을 사용 시 성능이 떨어지기 때문에 가급적 Transaction 사용을 최소화가 필요

 

MongoDB 모델링 시 고려사항 정리

• Data와 Business 중심의 설계
• Application의 쿼리 중심 설계를 의미
• 비즈니스 요구사항에 맞춰서 비정규화(Embedded), 데이터 중복 허용
• Document 관계 데이터 저장 유형
• Embedded vsReferences 
• 자식 객체가 자신의 부모 객체 외부에 절대 나타나지 않는 경우라면 포함시키고, 그렇지 않다면 별도의 collection 을 만들어 저장.
• 조인이 필요한 경우라면 포함 시키고, 필요 없다면 collection 으로 개발을 추천하는 의미로 해석
• Embedded
• 16Mb 제한
• 빈번한 업데이트, 크기가 증가하는 업데이트일 경우 권장하지 않음 (단편화 발생)
• 읽기 속도 향상 : 한번의 쿼리로 원하는 데이터 추출 가능
• References
• 복잡하지만 유연한 데이터 구조
• 데이터 크기 제한 없음
• 상대적으로 강한 일관성 제공 가능
• 해당 Document만 삭제,수정,추가만 하면 되기 때문

 

Embedded

• Document 내에 존재
• 1개의 Document 데이터를 다른 Document key 의 value 에 저장하는 방법

// Person
{
   _id: "joe",
   name: "Joe Bookreader",
   address: {
      street: "123 Fake Street",
      city: "Faketon",
      state: "MA",
      zip: "12345"
  }
}


// Address
{
   pataron_id: "joe",
   street: "123 Fake Street",
   city: "Faketon",
   state: "MA",
   zip: "12345"
}

Database References

• 하나의 Document 내에 저장되는 비 정규화된 데이터 모델에 최적 (경우에 따라 별도의 Document에 저장이 바람직한 경우도 존재)
• Pointer 개념으로 이해하면 쉬움 (Embedded 의 경우 Document를 통채로 저장하는 반면, Reference의 경우 ID 를 저장하는 것)
• 하나의 Document 내에 embeded 형태 보다 더 유연한 방식
• 3.2 에서는 $lookup 파이프라인을 이용하여 동일 DB 내 샤드 되지 않은 Collection에 left outer join 가능
• 3.4 이후부터 $graphLookup 파이프라인을 이용하여 샤드 되지 않은 Collection에 재귀 검색을 수행 가능 (자신의 collection의 의미로 해석)
• 2가지 방법을 이용하여 Document 참조 가능
• Manual 참조
• 참조할 Document의 _id 필드를 다른 Collection 내 Document에 하나의 key(필드)로 참조 저장

db.places.insert({
    name: "Broadway Center",
    url: "bc.example.net"
})
db.people.insert({
    name: "Erin",
    places_id: db.places.findOne({name: "Broadway Center"})._id,
    url:  "bc.example.net/Erin"
})

> var peopleDoc = db.people.findOne({name: "Erin"});
> var placeID = peopleDoc.places_id;
> var placesDoc = db.places.findOne({_id: placeID});
> placesDoc.url
bc.example.net

# 또는

> db.places.findOne({ _id: db.people.findOne({name: "Erin"}).places_id }).url
bc.example.net

•  DBRefs
• 참조할 Document의 "_id" 필드의 값과 옵션으로서의 DB 이름을 이용하여 어느 하나의 Document가 다른 Document를 참조하는 것
• 여러 Collection에 위치한 Document를 단일 Collection Document에서 쉽게 연결하여 조회 가능
• DBRef는 3개의 인자를 가지는데, 처음 두 개는 필수 인자이며($ref, $id), 세 번째 인자는 옵션 인자($db)
• $ref
• 참조할 Document가 존재하는 Collection 이름
• $id
• 참조된 Document 내 _id 필드 값
• $db
• 참조할 Document가 존재하는 DB 이름

출처 : 맛있는MongoDB

MongoDB 인 액션

https://blog.voidmainvoid.net/241

NoSQL강의) mongoDB에서 data 모델링하는 방법. 예제포함.

https://cinema4dr12.tistory.com/375

[MongoDB] Database References

https://devhaks.github.io/2019/11/30/mongodb-model-relationships/