1. MongoDB 설계 방식

1.1. 기존 MySQL에서 사용하던 패턴을 사용

• 장점
  • 간단함
  • 이식하기 편함
• 단점
  • 모든 Workspace를 통틀어서 고유 ID를 관리해야함 ⇒ 현재도 고유 ID를 관리함

2. Workspace 단위로 Document를 생성하여 그 안에서 Object를 관리

• 장점
  • 특정 Workspace에 속한 Object SELECT 연산 시 더 빠른 속도 예상
• 단점
  • ObjectId가 unique한지 판단하지 않음

3. 1과 2의 절충안 → populate

결론

1의 경우 MongoDB의 문자열 검색이 MySQL에 비해 현저히 느리다는 자료가 존재, 하나의 Workspace에서 수많은 Object를 생성하면 다른 Workspace의 Object 탐색에 영향을 줄 수 있다고 판단하여 1안은 하지 않기로 결정함.

우선 2의 방법으로 구현한 후 성능이 심각하게 저하될 경우 3번에서 populate가 아닌 aggregate를 사용하자.

고려 사항

• Docuemt 기본 최대 크기 = 16MB → 2번, 3번의 경우 Workspace 내 Object가 많아진다면? 각 Workspace Document는 Object를 얼마나 감당할 수 있는가?