MongoDB Data Modeling Pattern

I. 서론

1. 문서를 작성하게 된 계기

나는 8월 31일부터 현재까지 네이버 부스트캠프 웹/모바일 7기 웹풀스택 멤버십 과정에서 학습을 진행하고 있다. 현재는 그룹프로젝트를 진행하고 있고, 나는 백엔드 개발을 담당하고 있는데, 이번 프로젝트에서 ‘MongoDB를 도입하자’는 의견이 나왔다. MongoDB를 보다 잘 사용하기 위해서는 ‘데이터 모델링 패턴’이 있다는 것을 알게 되었고, 이 중 ‘우리 프로젝트에서 잘 맞는 패턴을 적용할 수 있지 않을까’라는 생각을 해서 패턴을 조사해보기로 하였다.

2. 프로젝트 소개

우리 그룹은 ‘부끄럼’이라는 프로젝트를 진행하게 되었는데, ‘부끄럼’은 애자일 기법 중 한 종류인 스크럼을 도와주는 도구이다. 스크럼을 온라인에서 처음 진행하게 되면 각 활동에서 무엇을 해야할지 고민하게 되고, 그 과정에서 답답함과 어려움을 느낄 수 있다. 그렇기 때문에 우리 그룹은 스크럼을 진행하는데에 도움을 줄 수 있는 협업툴을 만들기로 하였다.

3. 문서의 목적

MongoDB를 보다 잘 사용하기 위해서 ‘데이터 모델링 패턴’을 조사한 후 각 패턴에 대한 설명과 장단점을 기술하고, 우리 프로젝트에 맞는 ‘데이터 모델링 패턴’을 적용하고자 한다.

---

II. 본론

0. 사전 지식

1. MongoDB 계층도

2. Shading

3. BASE

참고할 것 https://kciter.so/posts/about-mongodb

4. 성능 향상

참고할 것 https://velog.io/@moongq/MongoDBMongoose-퍼포먼스-향상시키기

보완

https://marsettler.com/mongodb/mongodb-study-week-5/

Virtual Data

1. Approximation Pattern

Approximation Pattern은 **리소스 비용(시간, 메모리, CPU 주기)**이 많이 드는 계산이 자주 수행되고, 이러한 계산의 정밀도가 최우선 순위가 아닌 경우에 유용하다.

장점

• 데이터베이스에 대한 쓰기가 적음
• 통계적으로 유효한 숫자를 유지함

단점

• 정확한 숫자가 표시되지 않음
• 애플리케이션에서 구현해야 함

예제

• 일반적으로 700,000명이 사이트를 방문했는지 또는 699,983명이 방문했는지 아는 것은 중요하지 않음 ⇒ 따라서 애플리케이션에 카운터를 구축하고 임계값이 충족되면 데이터베이스에서 업데이트
• 아래 이미지와 같이 Approximation Pattern을 사용하여 cout 작업에 대한 쓰기를 줄임으로써, 아키텍처 복잡성과 비용을 줄일 수 있음

2. Attribute Pattern

Attribute Pattern은 유사한 필드가 많은 큰 문서를 기반으로 하지만 공통 특성을 공유하는 필드 하위 집합이 있고 해당 필드 하위 집합을 정렬하거나 쿼리하려는 문제에 유용하다. 정렬해야 하는 필드의 문서가 작은 하위 집합에서만 발견되는 경우, 또는 문서 내에서 두 조건이 모두 충족되는 경우.

장점

• 더 적은 인덱스가 필요함
• 쿼리 작성이 더 간단해지고 일반적으로 더 빨라짐

예제

적용 전

{
    title: "Star Wars",
    director: "George Lucas",
    ...
    release_US: ISODate("1977-05-20T01:00:00+01:00"),
    release_France: ISODate("1977-10-19T01:00:00+01:00"),
    release_Italy: ISODate("1977-10-20T01:00:00+01:00"),
    release_UK: ISODate("1977-12-27T01:00:00+01:00"),
    ...
}

적용 후

{
    title: "Star Wars",
    director: "George Lucas",
    …
    releases: [
        {
            location: "USA",
            date: ISODate("1977-05-20T01:00:00+01:00")
        },
        {
            location: "France",
            date: ISODate("1977-10-19T01:00:00+01:00")
        },
        {
            location: "Italy",
            date: ISODate("1977-10-20T01:00:00+01:00")
        },
        {
            location: "UK",
            date: ISODate("1977-12-27T01:00:00+01:00")
        },
        … 
    ],
    … 
}

3. Bucket Pattern

시계열, 실시간 분석 도는 사물 인터넷(IoT) 애플리케이션과 같은 스트리밍 데이터를 관리해야 할 때 유용하다.

장점

• 컬렉션의 전체 문서 수 감소
• 인덱스 성능 향상
• 사전 집계를 활용하여 데이터 액세스를 단순화 할 수 있음

예제

적용 전

{
  sensor_id: 12345,
  timestamp: ISODate("2019-01-31T10:00:00.000Z"),
  temperature: 40
}
{
  sensor_id: 12345,
  timestamp: ISODate("2019-01-31T10:01:00.000Z"),
  temperature: 40
}
{
  sensor_id: 12345,
  timestamp: ISODate("2019-01-31T10:02:00.000Z"),
  temperature: 41
}

적용 후

{
    sensor_id: 12345,
    start_date: ISODate("2019-01-31T10:00:00.000Z"),
    end_date: ISODate("2019-01-31T10:59:59.000Z"),
    measurements: [
        {
            timestamp: ISODate("2019-01-31T10:00:00.000Z"),
            temperature: 40
        },
        {
            timestamp: ISODate("2019-01-31T10:01:00.000Z"),
            temperature: 40
        },
        ...
        {
            timestamp: ISODate("2019-01-31T10:42:00.000Z"),
            temperature: 42
        }   
    ],
    transaction_count: 42,
    sum_temperature: 2413
}

• Document의 크기가 16MB로 제한되기 때문에, 해당 제한을 초과하지 않도록 주의해야 함
• 해당 Bucket에 포함 된 데이터에 대한 Aggregation 연산은 단일 Document 내부에서 진행 가능함 ⇒ Aggregation 연산을 낮은 비용에 할 수 있음

4. Computed Pattern

매우 읽기 집약적인 데이터 액세스 패턴이 있고 애플리케이션에서 해당 데이터를 반복적으로 계산해야 하는 경우 유용하다.

장점

• 빈번한 계산을 위한 CPU 작업량 감소
• 쿼리 작성이 더 간단해지고 일반적으로 더 빨라짐

단점

• 본 패턴의 필요성을 식별하기 어려울 수 있음
• 패턴을 적용하거나 남용하는 것은 필요하지 않는 한 피해야 함

예제

5. Document Versioning Pattern

MongoDB에서 Document의 이전 버전을 유지해야하는 경우에 사용된다.

장점

• 기존 시스템에서도 쉽게 구현할 수 있음
• 최신 버전의 쿼리 성능에 영향을 미치지 않음

단점

• 쓰기 횟수가 2배로 늘어남
• 쿼리는 올바른 컬렉션을 대상으로 해야 함

예제

6. Extended Reference Pattern

애플리케이션에서 자주 액세스하는 데이터를 모으기 위해 많은 JOIN 작업을 수행할 때 가장 유용하다.

장점

• JOIN 작업이 많을 때 성능이 향상됨
• 읽기 속도가 빨라지고 전체 JOIN 수 감소

단점

• 데이터 복제

예제

7. Outlier Pattern

일반적인 데이터 패턴의 나머지 부분에 맞지 않는 몇 가지 쿼리나 문서가 있고, 이러한 예외가 애플리케이션의 솔루션을 주도할 경우 유용하다.

장점

• 몇 가지 Document 혹은 쿼리가 애플리케이션의 솔루션을 결정하지 못하도록 함
• 쿼리는 “일반적인” 사용 사례에 맞게 조정되지만 이상값은 여전히 해결됨

단점

• 종종 특정 쿼리에 맞게 조정되므로 임시 쿼리가 잘 수행되지 않을 수 있음
• 이 패턴의 대부분은 애플리케이션 코드로 수행됨

예제

일반적인 도서 구매 내역

{
    "_id": ObjectID("507f1f77bcf86cd799439011")
    "title": "A Genealogical Record of a Line of Alger",
    "author": "Ken W. Alger",
    …,
    "customers_purchased": ["user00", "user01", "user02"]

}

베스트 셀러 : ****1000명 이상의 구매자가 존재하는지

{
    "_id": ObjectID("507f191e810c19729de860ea"),
    "title": "Harry Potter, the Next Chapter",
    "author": "J.K. Rowling",
    …,
   "customers_purchased": ["user00", "user01", "user02", …, "user999"],
   "has_extras": "true"
}

8. Pre-allocation Pattern

문서 구조를 알고 있고 애플리케이션에서 단순히 데이터를 채워야 하는 경우 유용하다.

장점

• 문서 구조가 미리 알려진 경우 디자인 단순화

단점

• 단순성과 성능

예제

근무일을 배열로 저장

근무일을 범위 목록으로 배열에 저장

9. Polymorphic Pattern

차이점보다 유사성이 더 많은 다양한 문서가 있고 문서를 단일 컬렉션에 보관해야 하는 경우 유용하다.

장점

• 구현이 쉬움
• 쿼리를 단일 컬렉션에서 실행할 수 있음

예제

적용전

적용 후

10. Schema Versioning Pattern

애플리케이션은 데이터 스키마에 대한 변경이 애플리케이션 수명 동안 자주 발생하는 경우(거의 모든 경우가 해당됨), 이 패턴을 사용하면 문서의 이전 버전과 현재 버전이 컬렉션에 나란히 존재할 수 있다.

장점

• ‘다운 타임’이 필요하지 않음
• 스키마 마이그레이션 제어
• 향후 기술 부채 감소

단점

• 마이그레이션 중에 동일한 필드에 대해 두 개의 인덱스가 필요할 수 있음

예제

Version 1

{
  "_id": "<ObjectId>",
  "name": "Darth Vader",
  "home": "503-555-0100",
  "work": "503-555-0110",
  "mobile": "503-555-0120"
}

Version 2

{
  "_id": "<ObjectId>",
  "schema_version": "2",
  "name": "Anakin Skywalker (Retired)",
  "contact_method": [
    { "work": "503-555-0210" },
    { "mobile": "503-555-0220" },
    { "twitter": "@anakinskywalker" },
    { "skype": "AlwaysWithYou" }
  ]
}

11. Subset Pattern

응용 프로그램에서 사용하지 않는 문서의 데이터가 많은 대용량 문서로 인해 작업 집합이 RAM 용량을 초과하는 문제를 해결한다.

장점

• 작업 세트의 전체 크기 감소
• 가장 자주 사용되는 데이터에 대한 디스크 액세스 시간 단축

단점

• 하위 집합을 관리해야 함
• 추가 데이터를 가져오려면 데이터베이스에 대한 추가 이동이 필요

예제

• 온라인 쇼핑몰에서 최근 리뷰 5개만 표시되고, 더보기를 클릭해야 전체 리뷰 목록을 볼 수 있는 것
• 인기 상품 목록을 우선 표시하고 더보기를 클릭해야 전체 상품 목록이 표시 되는 것
• 미리 결과를 만들어 놓고 요청이 있을 경우만 추가 쿼리를 진행하므로, MongoDB의 조회 요청을 줄일 수 있음

12. Tree Pattern

데이터가 계층적 구조이고 자주 쿼리될 때 유용하다.

장점

• 여러 JOIN 작업을 피함으로써 성능 향상

단점

• 그래프 업데이트는 애플리케이션에서 관리해야 함

예제

테이블

트리 구조

표현 : 5의 상위 노드로 3, 2, 1이 존재함

13. 사용 사례 분석

Real-Time Analytics?

• Approximation
• Bucket
• Computed
• Extended Reference
• Preallocated
• Schema Versioning

III. 결론

부끄럼에 적용

Attribute 패턴 혹은 Bucket 패턴을 사용해야할 것으로 보인다. 사실 Attribute 패턴과 Bucket 패턴의 정확한 차이를 잘 모르겠다. 이 두 패턴에 대한 비교는 추후에 자세히 다루어 보도록 하겠다.

그렇다면 Bucket 패턴을 적용하여, 현재 우리가 MongoDB를 사용할 때 저장해야할 데이터는 다음과 같다.

Workspace Data

{
	workspaceId,
  createAt,
	updateAt,
}

Object Data

{
	objectId,
	type,
	left,
	top,
	width,
	height,
	color,
	text,
	creator,
	workspaceId,
	fontSize,
	scaleX,
	scaleY,
}

종합하면 하나의 Document에 저장해야하는 데이터는 다음과 같다.

{
	workspaceId: 'workspaceId',
  createAt: ISODate(""),
	updateAt: ISODate(""),
  objects: [
		{
			objectId, type, left, top, width, height, color, text, creator, workspaceId, fontSize, scaleX, scaleY,
		},
		{
			objectId, type, left, top, width, height, color, text, creator, workspaceId, fontSize, scaleX, scaleY,
		},
		...
		{
			objectId, type, left, top, width, height, color, text, creator, workspaceId, fontSize, scaleX, scaleY,
		}
	],
	...
}

하나의 Document에는 workspaceId를 바탕으로 해당 Workspace에 저장되어 있는 Object들을 배열에 저장하도록 한다.

느낀 점

MongoDB는 굉장히 자율성이 높은 데이터베이스인 것 같다. 단순히 ‘RDBMS보다 속도가 빠르다’라는 생각으로 사용하게 된다면 큰 코 다칠 수 있다. 단순히 MongoDB를 사용해보는 것도 좋지만, 그 전에 데이터 구조를 잡고 가는 것을 추천한다. 무턱대고 사용하다가는 MongoDB의 장점인 ‘성능’과 ‘가용성' 두 마리 토끼 모두 놓칠 수 있다.

---

IV. Reference

Building with Patterns: A Summary | MongoDB Blog