MongoDB - Data modeling (2)

2022.04.14 - [mongoDB] - MongoDB - Data modeling (1) 에 이어서 이제 좀 더 심도 있게 알아보도록 하자

---

 The Number of Collections

  개발을 하다보면 하나의 collection에 data를 다 저장할지 아니면 세분화해서 여러 collection에 나누어 저장할지 고민해야 되는 상황이 올 수 있다. 예를 들어서 log 정보를 관리하고자 한다고 생각해 보자.

{ log: "prod", ts: ..., info: ...}
{ log: "dev", ts: ..., info: ... }
{ log: "debug", ts: ..., info: ...}

 여기서 만약 전체 documents의 수가 적으면 그냥 collection하나에 type으로 document를 관리할 수 있다. 하지만 로그와 같은 data는 documents의 수가 많을 것으로 예상된다. 그리고 사용성 측면에서 보면 prod, dev는 동시에 사용하지 않을 data로 예상된다. 그러면 이렇게 하나의 collection에 data를 담는 것보다 "logs_dev", "logs_prod" 와 같이 collection을 나누는게 더 좋다. 왜나하면, collection의 갯수는 성능 저하에 영향을 미치지 않는다.

 어떻게 많은 수의 collection을 관리할 때 왜 문제가 없을까?

• 각각의 collection은 overhead가 매우작다. 고작 몇 KB 수준이다.
• 각각의 index는 최소 8kB정도의 data space를 차지한다.
• 각각의 database에서 single namespace 별로 file을 관리하고 이곳에 database를 위한 모든 메타 데이터를 저장한다. index와 collection은 각각의 namespace가 있다.

즉, collection이 많다고 하더라도 각각의 namespace file에서 관리하기 때문에 문제가 없고 오히려 high-throughput batch 처리에 더 좋다.

---

size가 작은 documents를 많이 갖고있는 Collection

 많약 size가 작은 documents가 많이 있다고 가정하면 성능이 낮아질 것이다. 그럼 이를 어떻게 처리해야 할까?

바로 논리적인 관계로 그룹하고 찾을 때 이 grouping을 사용하면 된다. 즉 embedded documents의 array를 갖고있는 larger documents로 small documents를 "rolling-up" 하면 된다.

 small documents를 논리적 그룹으로 "Rolling up" 하면 검색 쿼리에서 sequential read와 더 적은 random disk access를 하게 해준다. (기본적으로 I/O는 random access보다 sequential read의 성능이 훨씬 좋다.) 그리고 document "rolling-up"과 larger document로 공통 field를 옮기는 작업은 이런 fields들의 index에도 효과적이다. 공통 fields에 대한 copy가 줄어들고 상응하는 index에 연관된 key 항목이 줄어든다.

 하지만 만약 grouping을 했어도 group 내부의 하위 집합을 검색하게 될 경우가 많을 경우 성능 향상이 되지 않을 것이다. 

---

 Small Documents를 위한 Storage 최적화

 mongoDB document 각각은 어느정도의 overhead를 갖고 있다. 평소에는 딱히 상관 없지만 document가 매우 작거나 field가 한 두개 있을 때 이는 중요하다. 이에 대한 전략은 아래와 같다.

• 명시적으로 _id field 사용하기
  • _id는 monboDB에서 자동으로 생성하거나 사용자가 입력한 값에 맞게 12byte 로 저장되고 자동 indexing 하기 때문에 작은 document는 이를 명시적으로 사용하는게 좋다.
• 짧은 field name 사용하기
• documents를 embed하기

---

Data Lifecycle Management

 TTL을 통해서 Data Lifecycle을 관리할 수 있다. 만약 사용하지 않는 data가 계속 쌓인다면 이는 성능에 영향을 줄 수 있다. 저장 공간이 늘어나고 쓸데없는 indexing 관리 같은 낭비가 될 수 도 있다. 

 만약, timesieries collection를 사용한다면 ExpireAfterSeconds 옵션을 사용하면 된다.

Expire Data from Collections by Setting TTL — MongoDB Manual