LMDB 1.0 — 메모리 맵 기반 고성능 임베디드 DB
LMDB(Lightning Memory-Mapped Database)는 B-Tree 구조를 기반으로 한 임베디드 데이터베이스 라이브러리로, BerkeleyDB API를 느슨하게 모델로 삼되 훨씬 단순하게 설계되었다. 1.0 버전이 릴리즈되면서 0.9 시절의 아키텍처를 계승하면서도 안정성과 문서화가 보강되었다. Java 백엔드 개발자 입장에서는 직접 사용 빈도가 낮을 수 있지만, RocksDB·LMDB를 내부 스토리지로 채택한 라이브러리(예: Chronicle Map, 일부 임베디드 캐시 엔진)를 선택할 때 동작 원리를 이해하는 것이 중요하다.
메모리 맵과 Zero-Copy의 의미
LMDB의 가장 큰 특징은 데이터베이스 전체를 OS의 메모리 맵(mmap)으로 노출한다는 점이다. 데이터를 읽을 때 별도의 페이지 캐시 레이어나 malloc, memcpy가 전혀 발생하지 않으며, 매핑된 메모리 주소를 직접 반환한다. 이는 JVM 기반 애플리케이션에서 자주 문제가 되는 GC 압력을 OS 레벨에서 원천 차단하는 구조이기도 하다.
전통적인 WAL(Write-Ahead Log) 방식이나 Append-Only 구조의 DB는 주기적인 체크포인팅이나 컴팩션이 필요하다. 반면 LMDB는 사용하지 않는 페이지를 자체 추적해 재사용하기 때문에 별도의 유지보수 작업 없이 운영할 수 있다.
트랜잭션과 동시성 모델
LMDB는 완전한 ACID 트랜잭션을 지원하며, 동시성 모델도 독특하다.
- 쓰기 직렬화: 쓰기 트랜잭션은 동시에 하나만 활성화된다. 이 덕분에 writer 간 데드락이 구조적으로 불가능하다.
- MVCC 기반 읽기: 데이터베이스 구조가 다중 버전(Multi-Versioned)이므로 reader는 락 없이 동작한다. writer가 reader를 블로킹하거나, reader가 writer를 블로킹하는 상황이 발생하지 않는다.
- Copy-on-Write 페이지: 활성 데이터 페이지를 직접 덮어쓰지 않으므로 시스템 크래시 이후 별도 복구 절차가 필요 없다.
// LMDB C API 예시 (Java에서 JNI 바인딩으로 호출되는 구조 이해용)
MDB_env *env;
mdb_env_create(&env);
mdb_env_open(env, "./testdb", 0, 0664);
MDB_txn *txn;
mdb_txn_begin(env, NULL, 0, &txn); // 쓰기 트랜잭션 시작
// ... put/get 작업
mdb_txn_commit(txn);
Java 환경에서는 lmdbjava 같은 JNI 바인딩을 통해 동일한 트랜잭션 모델을 활용할 수 있다. 읽기 트랜잭션을 장시간 열어두면 오래된 페이지가 회수되지 못하는 문제가 있으므로, 읽기 트랜잭션의 생명주기 관리는 운영 시 주의해야 할 포인트다.
실무에서의 활용 맥락
LMDB는 소규모 임베디드 스토리지나 로컬 캐시 레이어가 필요한 상황에 적합하다. 예를 들어 마이크로서비스 내부에서 외부 DB 호출 없이 빠른 로컬 조회가 필요하거나, 설정·메타데이터를 영속화할 때 LMDB를 선택지로 고려할 수 있다. 또한 메모리 맵 방식 특성상 읽기 집약적 워크로드에서 특히 높은 성능을 발휘한다.
단, 쓰기가 직렬화되기 때문에 쓰기 처리량이 병목인 워크로드에는 적합하지 않다. 이 경우 RocksDB처럼 LSM-Tree 기반의 쓰기 최적화 엔진을 검토하는 것이 바람직하다.
정리
- LMDB는 mmap 기반 Zero-Copy 설계로 페이지 캐시와 GC 부담 없이 극도로 빠른 읽기 성능을 제공한다.
- MVCC 구조 덕분에 reader/writer 간 블로킹이 없으며, 쓰기 직렬화로 데드락이 구조적으로 방지된다.
- WAL·컴팩션이 불필요해 운영 부담이 낮지만, 쓰기 병렬 처리가 필요한 워크로드에는 적합하지 않다.