[Database] MongoDB 이해하기

MongoDB란

MongoDB는 NoSQL 데이터베이스로, Document-Oriented(문서 지향) 모델을 사용하는 오픈소스 데이터베이스 시스템이다. NoSQL 데이터베이스답게 동적으로 스키마 구성이 가능하고, 대용량의 데이터 처리 속도가 빠르며, 수평적 확장, 높은 가용성에 장점이 있다.

Document 데이터베이스

Document란 필드와 값의 쌍으로 이루어진 데이터를 JSON과 같은 형식으로 저장한 문서를 뜻한다. 이러한 구조는 복잡한 관계형 데이터베이스의 테이블을 사용하지 않고도 데이터를 자연스럽게 표현할 수 있도록 한다.(실제 현실세계와 요구사항에 매우 유연하게 적용 가능) 관계를 갖는 데이터의 경우, 중첩 Document와 배열을 사용하여 1개의 Document로 표현이 가능하다. 또한 MongoDB는 성능에 이점이 있다. 데이터 입출력 시에는 JSON 형식의 Document를 사용하고, 데이터베이스에 저장할 때는 이진포맷으로 인코딩한 BSON(Binary JSON) 형식을 사용하여 저장한다. 이로써 더 나은 읽기 및 쓰기 성능을 지원하고, 다양한 데이터 타입 지원, 확장성 등에 이점이 있다.

유연한 스키마

MongoDB는 유연한 스키마를 지원하여 데이터 모델을 쉽게 변경하고 확장할 수 있다. 관계형 데이터베이스처럼 테이블 구조를 먼저 생성하고 레코드를 추가하는 방식과는 달리, 스키마의 선언 없이 필드의 추가, 삭제가 자유로운 Schema-less 구조를 띄고 있다. 관계형 데이터베이스는 테이블 내의 모든 Row의 칼럼집합이 동일하고 같은 칼럼은 동일한 데이터 타입을 갖는 정형 스키마이지만, MongoDB는 컬렉션 내 모든 Document들의 필드 집합이 동일하지 않고, 같은 필드라도 데이터 타입이 다를 수 있는 비정형 스키마이다.

비관계형 데이터베이스

MongoDB는 관계형 데이터베이스와 달리 비관계형 데이터베이스로 분류된다. 이는 데이터를 조금 더 단순하게 저장하고, 질의하는 방식에 중점을 두었다. 따라서 join을 지원하지 않고, 대신 임베디드 방식의 Document 구조를 사용하거나 레퍼런스 방식의 도큐먼트 구조를 사용하여 관계를 나타낸다.

비트랜잭션

MongoDB는 명시적인 트랜잭션을 지원하지 않는다. 따라서 관계형 데이터베이스 Commit 또는 Rollback 개념이 없고, 모두 auto-commit으로 처리된다. BASE 모델의 트랜잭션 방식을 통해 데이터의 일관성보다는 가용성을 우선적으로 고려하여 성능에 초첨을 맞췄다.

Load Balancing

MongoDB는 여러 인스턴스 데이터를 분할하여 수평으로 확장하는 sharding 개념을 사용한다. 사용자는 컬렉션 안의 데이터 배포 방식을 결정하는 Sharding Key를 선택하게 된다. 데이터는 여러 Range(Sharding Key에 따라)로 분리되며 여러 샤드로 배포된다. (샤드는 하나 이상의 리플리카가 존재하는 마스터이다)

 따라서 여러 서버를 통해 실행될 수 있으며, 중복데이터를 통해 하드웨어 장애가 발생 시에도 시스템을 계속 가동할 수 있다.

다양한 컬렉션 지원

컬렉션은 관계형 데이터베이스의 테이블과 같은 개념으로 용도가 같거나 유사한 도큐먼트들의 그룹을 묶는 단위를 의미하며, 4가지 종류의 일반 컬렉션, 캡드 컬렉션, TTL 컬렉션, 시스템 컬렉션으로 나뉜다.

• 일반 컬렉션 : 가장 일반적으로 사용되는 컬렉션
• 캡드 컬렉션 : 고정된 크기를 갖는 컬렉션으로 높은 성능의 로깅 기능을 위해 설계
• TTL 컬렉션 : 특정시간이 경과한 도큐먼트를 자동으로 삭제하는 컬렉션으로 TTL 인덱스에 의해 지원되는 기능
• 시스템 컬렉션 : mongoDB 내부에서 사용되는 컬렉션으로 사용자가 지정하여 사용할 수 없음

Replication

MongoDB는 레플리카 세트와 함께 고가용성을 제공한다. 레플리카 세트는 둘 이상의 MongoDB 인스턴스로 구성된다. 각 레플리카 세트는 언제든지 각각의 역할을 수행할 수 있다. 주 복제본은 사용자와 상호작용하여 모든 읽기 쓰기 작업을 수행하는 것은 기본 레플리카에서 수행된다. 세컨더리 레플리카는 내장된 레플리케이션 기능을 사용하여 기본 레플리카의 데이터 사본을 관리한다. 기본 레플리카가 실패하면 레플리카 세트는 어느 세컨더리 프라이머리가 되면 좋을지 결정하기 위해 선거 과정을 자동으로 수행한다. 세컨더리 레플리카들은 선택적으로 읽기 및 조작을 할 수 있으나 해당 데이터는 기본적으로 일관성을 유지한다.

Indexing

MongoDB 내에서 검색 성능을 향상시키기 위한 인덱스를 지원한다. MongoDB 문서의 모든 필드는 인덱싱 할 수 있다. B-Tree 인덱스로  구현되어 있다. PK는 자동적으로 인덱스 되며, 고유한 값을 유지하기 위해 유니크 키를 사용한다. MongoDB는 여러 개의 세컨더리 인덱스를 허용하기에 여러 조회 조건을 빠르게 처리할 수 있다. 세컨더리 인덱스에 대해 오름차순, 내림차순, 유니크 키, 복합 인덱스, 해시 인덱스, Text 인덱스, Geospatial 인덱스와 같은 관계형 데이터베이스에서 볼 수 있는 거의 모든 인덱스가 사용 가능하다.

Ad-hoc 쿼리(비정형 쿼리)

MongoDB는 field, Range 쿼리, 정규 표현식 검색을 지원한다. 쿼리는 특정 필드의 도큐먼트를 반환할 수 있으며 사용자 지정 javascript 함수를 포함할 수도 있다. 쿼리는 주어진 크기의 임의의 결과 샘플을 반환하도록 설정할 수도 있다.

관계형 데이터베이스와 MongoDB의 논리적 구조 비교

RDBMS	MongoDB
Database	Database
Table	Collection
Row	Document
Column	Field
Primary Key	_id
Relationship	Embedded & Link
Index	Index

 

Id

• Id 필드는 Document의 고유한 값을 나타낸다.
• 문서의 기본키와 같은 역할
• Id 필드가 없는 새 문서를 작성하면 자동으로 필드 작성 후 각 문서에 24자리 고유 번호 추가

Document

• 데이터의 기본단위로, BSON 형식으로 표현되는 데이터 레코드
• field-value 형태의 데이터 구성
• Document의 최대 크기는 16MB
• 최대 크기를 초과하는 경우 컬렉션 분리를 고려해야 함
• 컬렉션 분리
  • 단일 컬렉션 쓰기 작업이 많은 경우
  • 단일 컬렉션에서 대량의 데이터를 정기적으로 삭제하는 경우
  • 단일 컬렉션에서 저장되는 도큐먼트들의 액세스 패턴이 다양한 경우
  • 자주 조회되거나 도큐먼트 수가 적은 컬렉션의 경우 캐시될 수 있도록 고려

Collection

• Document들의 그룹을 의미
• 관련 Document들을 함께 저장하고, 인덱싱하여 효율적으로 관리할 수 있는 컨테이너
• 관계형 데이터베이스와 다르게 특정한 종류와 구조를 사용하지 않아도 됨

MongoDB의 CRUD Operations [참고]

Create

• db.collection.insertOne({ name: "sue", age: 26, status: "pending" })
• db.collection.insertMany([{ name: "sue", age: 26, status: "pending" }, { name: "alex", age: 27, status: "pending" }])

Read

• db.collection.find( <query>, <filter>, <options> )
• projection : Document를 조회할 때 보일 field
• find().pretty()를 붙이면 깔끔하게 조회 가능
• 연산자 살펴보기

Update

• db.collection.updateOne({age: {$gt: 25}}, {$set:{status:”C”}}, {multi: true})
• db.collection.updateMany()
• db.collection.replaceOne()

Delete

• db.collection.deleteOne()
• db.collection.deleteMany()

데이터의 관계 표현하기

 

 

Embedded 방식

하나의 Document 안에 다른 Document를 중첩하여 저장하는 방식으로, 하나의 Document 안에 모든 정보가 포함되어 있기 때문에 읽는 속도가 빠르다. 단, 중첩된 Document의 특정 필드만 업데이트하려면 전체 업데이트를 해야 하고, 여러 Document에 동일한 데이터가 들어가는 데이터 중복 문제가 발생할 수 있다.

• 임베디드 방식은 강의정보처럼 동일한 데이터를 각 학생 도큐먼트에 저장하여 구조를 단순화하는 반정규화 모델
• 임베디드 방식은 조회성능이 좋고 도큐먼트에 포함된 관련 데이터를 모두 업데이트할 수 있음
• 데이터 관리가 직관적이고 쿼리가 단순함

Reference 방식

 

Document 간에 참조를 사용하여 서로 연결하는 방식이다. 다른 Document를 참조하는 필드를 사용하여 참조된 Document의 _id 값을 저장한다. 참조하는 Document에 업데이트 발생 시 해당 Document만 업데이트하면 되기에 복잡하지 않고, 중복되는 데이터를 최소화할 수 있다. 단, 데이터를 읽을 때 조인이 필요하므로 성능이 저하되는 문제가 있을 수 있다.

• 레퍼런스 방식은 데이터가 중복되지 않도록 업무 성격별로 컬렉션을 분리 후 참조하므로 데이터 불일치 문제가 발생하지 않는 정규화 모델이다.
• 적절한 업무 단위의 컬렉션으로 데이터가 분리되어 임베디드 방식 대비 도큐먼트의 크기 증가가 작음
• 업무 요건 추가 및 변경으로 인한 도큐먼트 구조에 미치는 영향이 적음

---

참조한 사이트

Introduction to MongoDB — MongoDB Manual

mongoDB Story 3: mongoDB 데이터 모델링 : NHN Cloud Meetup

[MongoDB] 강좌 3편 Document Query(조회) – find() 메소드 | VELOPERT.LOG

MongoDB란 - 역사, 설계 목표, 핵심 기능, 몽고DB를 사용하는 이유

MongoDB Schema Design Best Practices | MongoDB

LINE 알림 센터의 메인 스토리지를 Redis에서 MongoDB로 전환하기