LMDB 1.0: 메모리 매핑으로 고성능 트랜잭션 데이터베이스의 새로운 기준을 제시하다
Lightning Memory-Mapped Database Manager (LMDB) 1.0
저는 LMDB 1.0을 통해 BerkeleyDB API를 단순화한 Btree 기반 데이터베이스 라이브러리를 소개합니다. 전체 데이터베이스를 메모리 맵으로 노출하여 데이터 가져오기 시 malloc나 memcpy가 발생하지 않아 극도의 성능과 메모리 효율성을 확보했습니다. 완전한 ACID 트랜잭션 지원과 복사 시 쓰기 전략을 통해 시스템 충돌 후 복구 절차 없이도 데이터 무결성을 보장하며, 별도의 유지 관리 없이도 안정적으로 운영됩니다.
메모리 맵이 읽기 전용으로 설정되면, 애플리케이션 코드에서 발생한 잘못된 포인터 작성으로 데이터베이스 무결성이 손상되는 것을 완전히 차단할 수 있습니다.
HN 토론
70- hmry
어떤 사람들이 mmap 에 갖는 매력을 저는 전혀 이해하지 못했습니다. 메모리 매핑 파일 IO 는 단순히 RAM 캐시와 캐시를 채우기 위한 숨겨진 시스템 호출 (페이지 폴트) 의 결합일 뿐입니다. O_DIRECT 를 사용하여 일반적인 익명 메모리를 채우는 방식으로 여러분도 똑같은 일을 할 수 있습니다. 좀 더 사회적인 느낌을 원한다면 매핑되고 공유된 memfd 를 채울 수도 있습니다.
memfd 도 시일 (seal) 할 수 있습니다. 즉, "읽기 전용" 모드를 구현하는 것은 매우 쉽습니다: memfd 를 쓰기용으로 매핑한 후 F_SEAL_FUTURE_WRITE 를 적용하고, 읽기 전용 접근 권한을 가진 모든 사람에게 memfd 를 공유하면 됩니다.
커널의 기본 설정에 의존하는 대신 직접 O_DIRECT IO 를 수행하면 훨씬 더 많은 제어권을 얻을 수 있습니다. 리드어헤드 (readahead) 를 얼마나 할지, 리드 클러스터 크기는 얼마로 할지, 캐시 제거 전략은 무엇으로 할지, 언제 백업 쓰기를 할지 모두 여러분이 선택합니다.
참고로: O_DIRECT 도 aio 나 io_uring 을 사용하여 비동기적으로 수행할 수 있습니다. 비동기 페이지 폴트라는 것은 존재하지 않습니다. 그리고 IO 오류는요? EIO 를 처리하는 것이 좋을까요, 아니면 SIGBUS 를 처리하는 것이 좋을까요?
왜 이러한 일들을 커널이 대신 해주기를 원하십니까? 커널은 여러분보다 정보가 적고, 전 세계 모든 프로그램이 아닌 여러분만의 프로그램에 맞지 않는 무딘 휴리스틱을 사용해야 하므로 더 나쁜 일을 할 뿐입니다.
그리고 속도가 더 빠른 것도 아닙니다. O_DIRECT 는 DMA 입니다. 페이지 캐시 채우기도 DMA 입니다. 단지 표현 방식이 다른 동일한 작업일 뿐입니다.