MongoDB MongoDB: 문서 지향 NoSQL

MongoDB

MongoDB는 NoSQL로서, 오픈소스 문서 지향(Document-Oriented) 데이터베이스 시스템입니다.

 

우리가 기존에 접할 수 있는 RDBMS(MySQL, Oracle)와는 다른 데이터 형식을 갖고 있는 NoSQL에 대해 먼저 설명하도록 하겠습니다.

 

MongoDB의 특징

NoSQL

NoSQL은 'Not Only SQL' 또는 'Non-Relational'의 약자로, 관계형 데이터베이스(RDBMS)와는 다른 DB 시스템입니다.

NoSQL은 다양한 유형으로 나뉘며, 각 유형마다 특정한 데이터 모델과 사용 사례에 최적화되어 있습니다. 아래와 같은 유형은 NoSQL의 대표적인 유형입니다.

• Document Store: MongDB
• Key-Value Store: Redis, DynamoDB
• Wide-Column Store: Cassandra, HBase
• Graph Store: Neo4j

 

MongoDB의 특징

1. Schema가 자유롭다.

MySQL 같은 경우 정해진 스키마에 따라 테이블 간의 관계를 정의하고, 데이터는 정형화된 테이블에 저장됩니다.

| id | user_id |     email    | age |
| 1  | test1   | test1@gmail  | 18  |
| 2  | test2   | test2@gmail  | 44  |

 

MongoDB는 도큐먼트로 데이터를 표현을 합니다. 이때, JSON 형태로 표현하기 때문에 기존 RDBMS에서는 하지 못했던 데이터 표현을 할 수 있습니다. 아래 예시를 보면 배열로 데이터를 표현함으로 가시성이 더 좋아졌습니다.

{
    _id: 1,
    user_id: "test1",
    email: "test1@gmail.com",
    phone: "010-1234-5678",
    friends: [
            {id: "friend1", email:"friend1@gmail.com"},
            {id: "friend2", email:"friend2@gmail.com"}
    ]
}

 

또한 스키마가 자유롭기 때문에 데이터 모델을 App의 요구사항에 맞게 데이터를 수용할 수 있고, 스키마 변경에 공수가 적습니다. 

 

반대로 스키마가 자유롭기 때문에 데이터의 중복이 발생할 수 있습니다. 때문에 자유롭더라도, 스키마 설계를 잘해야 성능 저하를 피할 수 있습니다.

 

2. 응답 속도가 빠르다.

RDBMS의 경우 데이터를 가져오기 위해 Join을 통해 데이터를 추출할 수 있었다면, MongoDB는 조인없이 하나의 도큐먼트로 원하는 데이터를 가져올 수 있어서 응답 속도가 일반적으로 빠릅니다.

 

3. 수평적 확장

RDBMS는 주로 단일 서버의 성능을 증가시키는 수직적 확장 방식으로 사용한다면, NoSQL은 여러 머신에 데이터를 분산하여 처리하고 저장하는 수평적 확장 방식을 사용합니다.

(MySQL Cluster 등을 통해 수평 확장이 가능하지만 주요 특성을 개념적으로 받아들이자~)

MongoDB는 HA(High Availability)와 Scale-Out Solution을 자체적으로 지원하고 있어 Scale-Out이 간편합니다. 또한 확장 시, Application을 변경하지 않아도됩니다.

자세한 설명은 다른 포스팅에서 다루도록 하겠습니다.

 

4. Secondary Index 지원 및 다양한 종류의 Index 제공

MongoDB는 Primary Key를 제외한 모든 필드에 대해 Secondary Index를 생성할 수 있습니다. 이를 통해 여러 필드에 대한 검색 및 정렬 작업을 효과적으로 수행할 수 있습니다.

 

5. 다양한 종류의 Index 제공

다양한 종류의 Index를 제공하기 때문에 다양한 요구 사항을 만족할 수 있습니다. 아래는 몇 가지 예시입니다.

• Single Field Index: 개별 필드에 대한 인덱스를  생성하여 검색 가속화
• Compound Index: 복합 인덱스를 지원하여 여러 필드 동시 검색 최적화
• Text Index: 풀 텍스트 검색 지원으로 텍스트 데이터 검색 효율적 수행
• Geospatial Index: 지리 정보에 대한 검색 지원으로 위치 기반 쿼리 효율적 수행
• Multikey Index: 배열 형태의 데이터에 대한 검색 지원으로 배열 요소 검색 최적화

 

 

MongoDB 구조

RDBMS vs MongoDB 계층 구조

 

1. Database

MongoDB 설치시 기본적으로 3개의 DB가 설치됩니다. admin, config, local database는 MongoDB를 관리하는데 사용됩니다.

 

admin:
데이터베이스는 관리 목적으로 사용되며, 사용자 관리, 권한 부여 등과 관련된 작업을 수행합니다. MongoDB는 관리자 권한을 가진 사용자를 이 데이터베이스에서 생성하고 관리합니다.

local:

MongoDB 내부에서 사용되는 데이터를 저장합니다. 주로 복제(replication)와 관련된 정보, 즉 레플리카셋의 상태, 동기화 정보 등이 이곳에 저장됩니다.
config:
샤딩(Sharding)과 관련된 설정 정보를 저장합니다. 샤딩을 사용하는 경우, 여러 머신에 데이터를 분산하고 관리하기 위한 설정이 이곳에 저장됩니다.

 

2. Collection

Collection은 MongoDB에서 문서(document)의 그룹을 의미합니다. RDBMS의 테이블에 해당합니다.

 

RDBMS에서 테이블에 데이터를 넣으려면, 테이블을 먼저 생성해야 하지만, MongoDB는 스키마가 자유롭기 때문에 Collection을 먼저 생성하지 않아도 데이터(Document를 생성)를 삽입할 수 있습니다.

아래는 member라는 Collection이 존재하지 않았지만, 데이터를 삽입함으로 생성됨을 확인할 수 있습니다.

// Document 삽입 & Collection 생성
> db.member.insertOne({
... name: "alice",
... age: 25,
... email: "alice@gmail.com"
... })

// Collection 확인
> show collections
member

 

동일한 Collection 내의 문서들은 서로 다른구조를 가질 수 있습니다.

> db.member.find()
[
    // Document 1
    {
      _id: ObjectId("5f8c66a92fbb3b5a5c37fa2a"),
      name: "Alice",
      age: 25,
      email: "alice@example.com"
    }

    // Document 2
    {
      _id: ObjectId("5f8c66a92fbb3b5a5c37fa2b"),
      username: "bob123",
      joined_date: ISODate("2021-01-01T00:00:00Z"),
      active: true
    }
]

Collection의 스키마가 동적이고 자유롭더라도, 스키마를 어느정도 정해주어야합니다.
그 이유는 Collection 내에 있는 특정 필드로 Index를 생성하고, Shard를 나눌 수도 있기 때문에 연관된 데이터를 담고 있는 것이 중요합니다.

 

 

3. Document

• Document는 MongoDB에서 데이터를 저장하는 기본 단위입니다. 
• JSON 형식과 유사한 BSON(Binary JSON) 형태로 저장되며, 필드와 값의 쌍으로 이루어져 있습니다.
• 각 Document에는 '_id' 필드가 있습니다. 이 필드는 고유한 값으로 중복이 되지 않습니다. '_id'를 명시하지 않고 데이터를 삽입하면 ObjectId 타입의 고유한 값이 저장됩니다.
• Document의 최대 크기는 16MB로 고정되어 있습니다.

 

4. Field

Field는 Document 내에서 각각의 데이터를 나타냅니다. 필드는 키-값 쌍으로 이루어져 있으며, 값은 다양한 데이터 유형일 수 있습니다. 예를 들어, 문자열, 숫자, 배열, 내장 문서 등 다양한 유형의 데이터를 저장할 수 있습니다.