MongoDB architecture

MongoDB가 단순한 NoSQL 데이터베이스를 넘어, 내부 저장 엔진(Storage Engine)과 아키텍처를 어떻게 혁신해왔는지에 대한 깊이 있는 내용을 담고 있습니다.

1. 데이터베이스의 기본 구조: 프론트엔드와 저장 엔진¶

모든 데이터베이스는 크게 두 부분으로 나뉩니다.

프론트엔드(API): 사용자가 데이터베이스와 소통하는 통로입니다. (예: SQL, MongoDB의 get/set API)
저장 엔진(Storage Engine): 데이터를 실제로 디스크에 어떻게 쓰고 읽을지 결정하는 핵심 모듈입니다. 데이터의 압축, 트랜잭션, 인덱스 관리, WAL(Write Ahead Log/저널링)을 통한 복구 등을 담당합니다.

핵심 포인트: 저장 엔진은 데이터가 '문서'인지 '행'인지 관심이 없습니다. 오직 페이지(Page) 단위의 바이트 덩어리로 데이터를 처리합니다.

변화: 2014년 인수를 통해 도입된 고성능 엔진으로, 문서 수준 잠금(Document-level Locking)과 데이터 압축을 지원합니다.
인덱스 구조: * 내부적으로 레코드 ID(64비트) 기반의 숨겨진 클러스터형 B-트리를 사용합니다.
하지만 사용자가 사용하는 ID(기본 키)로 조회할 때, 'ID 인덱스 스캔 → 레코드 ID 획득 → 실제 데이터 조회'라는 이중 조회(Double Lookup) 과정이 발생하여 성능 오버헤드가 있었습니다.

2022년 7월경 도입된 기능으로, MongoDB 아키텍처의 정점이라 할 수 있습니다.

개념: 기존의 숨겨진 레코드 ID를 제거하고, 사용자의 ID 필드를 직접 클러스터 인덱스의 키로 사용합니다.
장점:
단일 검색(Single Lookup): 한 번의 검색으로 실제 데이터(문서)에 즉시 도달합니다.
성능 향상: IO 횟수가 줄어들고, 데이터가 실제 키 순서대로 물리적으로 정렬되어 범위 쿼리(Range Scan)에 매우 유리합니다.
주의점:
보조 인덱스(Secondary Index)들이 이제 레코드 ID가 아닌 사용자 ID를 가리킵니다.
만약 ID 값이 너무 크거나(예: 무분별한 UUID 사용) 무작위라면 보조 인덱스의 크기가 커지고 효율이 떨어질 수 있습니다 (MySQL의 설계 고민과 유사해짐).

구분	MMAP (V1)	WiredTiger (기본)	클러스터형 컬렉션 (v5.3+)
잠금 단위	DB / 컬렉션 수준	문서(Document) 수준	문서(Document) 수준
압축	지원 안 함	지원 (높은 효율)	지원 (높은 효율)
조회 방식	인덱스 → 오프셋(O(1))	이중 검색 (B-트리 2회)	단일 검색 (B-트리 1회)
데이터 물리 구조	순차적 저장	레코드 ID 기준 정렬	사용자 ID 기준 정렬