LIT-bdb-lmdb-comparison

요약

BDB(Berkeley DB)와 LMDB(Lightning Memory-Mapped Database)는 모두 임베디드 key-value 데이터베이스이지만, 설계 철학이 근본적으로 다르다. BDB는 자체 캐시(MPool), WAL, 2PL 등 전통적인 데이터베이스 서브시스템을 모두 갖춘 "미니 RDBMS"이며, LMDB는 OS의 메모리 매핑(mmap)에 캐싱을 위임하고 Copy-on-Write B+Tree로 WAL을 제거한 "OS에 기대는 최소 설계"이다. LMDB는 OpenLDAP의 Howard Chu가 BDB의 캐시 관리 문제를 해결하기 위해 개발했으며, 현재 OpenLDAP, 389 DS, MIT Kerberos 등이 BDB에서 LMDB로 마이그레이션하고 있다.

핵심 포인트

설계 철학의 대비

BDB와 LMDB의 근본적 차이는 **"데이터베이스가 얼마나 많은 것을 직접 관리하는가"**이다:

관심사	BDB	LMDB
캐시 관리	자체 MPool (LRU)	OS mmap()에 위임
쓰기 내구성	WAL (데이터 2번 기록)	Copy-on-Write (데이터 1번 기록)
동시성 제어	2PL (기본) + MVCC (선택)	MVCC (기본, 단일 쓰기자)
복구	ARIES 기반 undo/redo 로깅	Shadow paging (로그 불필요)
튜닝	캐시 크기, 잠금 설정 등 다수	Zero-tuning
코드 크기	수백 KB	~32KB

BDB는 모든 것을 스스로 관리하는 "자급자족형"이고, LMDB는 OS가 잘하는 일(메모리 관리, 페이지 캐싱)을 OS에 맡기는 "위임형"이다. [추론]

LMDB가 탄생한 이유: BDB의 캐시 문제

2009년 Howard Chu가 OpenLDAP 개발자 메일링 리스트에서 제기한 문제:

이중 캐싱: BDB의 MPool과 OS의 파일시스템 캐시가 같은 데이터를 중복 캐싱
캐시 튜닝의 어려움: MPool 크기를 잘못 설정하면 성능이 급격히 저하
잠금 경합: 2PL 기반 잠금이 고부하에서 병목

LMDB는 이 세 가지를 모두 제거했다: mmap으로 이중 캐싱 제거, 튜닝 파라미터 제거, MVCC로 읽기-쓰기 간 잠금 제거.

Copy-on-Write B+Tree: WAL 없는 ACID

LMDB의 가장 혁신적인 설계는 Write-Ahead Logging 없이 ACID를 보장하는 것이다:

기존 (BDB):
  1. 변경 내용을 WAL에 기록 (1번째 쓰기)
  2. 실제 데이터 페이지를 수정 (2번째 쓰기)
  → 데이터를 항상 2번 기록

LMDB:
  1. 변경된 페이지를 새 위치에 기록 (1번째이자 마지막 쓰기)
  2. B+Tree 루트를 새 트리로 원자적 갱신 (shadow paging)
  → 데이터를 1번만 기록

새 트리가 완전히 기록되기 전에 장애가 발생하면, 루트가 아직 이전 트리를 가리키므로 이전 상태가 그대로 유지된다. 이것이 "copy-on-write"의 내구성 보장 방식이다.

성능 특성 비교

항목	BDB	LMDB
읽기 성능	보통	수 배~수십 배 빠름
읽기 확장성	잠금 경합으로 제한	CPU 코어 수에 선형 비례
쓰기 처리량	다중 쓰기자 가능	단일 쓰기자 (직렬)
벌크 로드	보통	최고 수준
메모리 효율	이중 캐싱 (MPool + OS)	단일 캐싱 (OS만)
디스크 효율	WAL로 2배 쓰기	1번 쓰기

LMDB는 읽기 비중이 높은 워크로드에 최적화되어 있다. LDAP 디렉토리 서비스, DNS, Kerberos KDC 등은 읽기가 쓰기보다 압도적으로 많으므로, LMDB가 이상적인 선택이다. [추론]

BDB→LMDB 마이그레이션의 두 가지 원인

BDB에서 LMDB로의 마이그레이션은 기술적 이유와 정치적 이유 두 가지에 의해 가속화되었다:

기술적: LMDB의 성능 우위, zero-tuning, 더 작은 코드베이스
정치적: 2013년 Oracle의 AGPL 라이선스 변경. BDB가 라이브러리이므로 링크하는 모든 프로그램이 AGPL 호환이어야 함 → 많은 오픈소스 프로젝트에서 사용 불가

라이선스 변경이 없었더라도 LMDB가 기술적으로 우월하므로 마이그레이션은 일어났을 것이지만, AGPL 변경이 마이그레이션을 급격히 가속화했다. [추론]

이 vault에서 조사한 프로젝트의 BDB→LMDB 상황

프로젝트	BDB 상태	LMDB 상태
OpenLDAP	back-bdb, back-hdb (deprecated)	back-mdb가 기본 (2012~)
389 DS	BDB 백엔드 (deprecated)	LMDB로 마이그레이션 진행 중
MIT Kerberos	DB2 백엔드 (기본)	LMDB 백엔드 지원 추가

세 프로젝트 모두 LDAP/Kerberos 인프라라는 공통점이 있으며, 읽기 비중이 높은 워크로드 특성상 LMDB가 특히 적합하다.

BDB의 현재 상태

BDB는 사실상 레거시 상태이다:

Oracle의 마지막 릴리스는 약 2020년 (18.1)
AGPL 라이선스로 인해 새 프로젝트에서의 채택이 거의 없음
기존 사용자들이 LMDB, RocksDB 등으로 이탈
그러나 RPM 등 일부 레거시 시스템에서는 여전히 사용 중

LMDB의 제한사항

LMDB가 만능은 아니다:

단일 쓰기자: 높은 쓰기 동시성이 필요하면 RocksDB 등이 더 적합
디스크 공간 비회수: 삭제해도 DB 파일 크기가 줄어들지 않음 (compaction 없음)
메모리 매핑 의존: 32비트 시스템에서 주소 공간 제한

쓰기 비중이 높은 워크로드(예: 로그 저장, 시계열 데이터)에는 RocksDB(LSM-Tree 기반)가 더 적합하다. [추론]

나의 생각

LMDB의 "OS에 위임" 설계는 이 vault에서 반복적으로 나타나는 "중간 레이어 제거" 패턴의 전형이다. Ceph의 BlueStore가 파일시스템 레이어를 제거하고 raw block device를 직접 사용한 것과 같은 맥락이다 (LIT-ceph-overview 참조). 다만 방향이 반대이다 — BlueStore는 OS 파일시스템을 우회하고, LMDB는 OS 메모리 관리를 활용한다. [추론]
BDB의 역사는 오픈소스 라이선스 정책이 기술 생태계에 미치는 영향의 사례 연구이다. Sleepycat License → AGPL 변경 하나로 수십 년간 쌓인 생태계가 무너졌다. Heimdal이 미국 수출 규제 때문에 탄생한 것(LIT-kerberos-implementations-overview 참조)과 마찬가지로, 기술 외적 요인이 기술 생태계를 결정적으로 바꾸는 사례이다. [추론]
Howard Chu가 OpenLDAP의 BDB 캐시 문제를 해결하려고 LMDB를 만들었고, 그 LMDB가 OpenLDAP뿐 아니라 389 DS, MIT Kerberos, Monero, Meilisearch 등 전혀 다른 영역에서도 채택된 것은 흥미로운 기술 전파 사례이다. 특정 문제를 위한 해결책이 범용 도구가 된 것이다. [추론]
LMDB의 Copy-on-Write B+Tree는 WAL을 제거함으로써 쓰기 I/O를 절반으로 줄인 것이 핵심이다. 이것은 단순한 최적화가 아니라 내구성 보장 메커니즘 자체를 교체한 것이다 — WAL 기반 "실패 시 로그에서 복구" 대신 shadow paging 기반 "실패 시 이전 트리가 그대로 존재"로 전환한 것이다. [추론]

gonnux.com