Lightning Memory-Mapped Database (LMDB) - представляет собой интересный, во многом уникальный, движок базы данных класса Berkeley DB / Level DB. Будучи относительно малоизвестным, LMDB показывает чемпионскую производительность по чтению и предлагает ряд компромиссов для достижения невероятной производительности по записи.

Так получилось, что мы сделали клон/fork исходного проекта и создали высокопроизводительное стабильное решение промышленного масштаба с открытым исходным кодом. Расскажу о внутреннем устройстве LMDB, о выявленных недостатках и наших доработках для их устранения.

Доклад точно будет интересен разработчикам, интересующимся "внутренностями" баз данных, а также специалистам, эксплуатирующим OpenLDAP в промышленном высоконагруженном масштабе: десятки миллионов записей, десятки тысяч запросов в секунду, геораспределенный кластер, многогигабайтные базы, 24x7.

LMDB был создан для использования внутри известного проекта OpenLDAP с открытым исходным кодом. Как разработчик и поставщик решений для «больших телекомов», компания «Петер-Сервис» решила задействовать связку OpenLDAP+LMDB в одном из своих проектов. Это был вход в кротовую нору, всё было как в сказке – чем дальше, тем страшнее...

В результате появился ReOpenLDAP – потомок общеизвестного OpenLDAP, ориентированный на промышленную эксплуатацию в сфере телекоммуникаций (десятки и сотни миллионов записей, высокие нагрузки, высокая доступность, 24x7). Проект реализован силами компании «Петер-Сервис R&D» для применения в телеком-проектах федерального масштаба.

LMDB представляет собой предельный вариант MVCC на основе B-tree с прямым отображением всех данных в память, подходом copy-on-write и lockfree при чтении. Это наделяет LMDB уникальным наборов свойств.

В сценариях использования с range lookup по чтению LMDB является чемпионом, что логично и подтверждается тестами. Но в сценариях с интенсивной записью всё не так радужно - для высокой производительности требовалось отказаться от гарантии консистентности данных, либо обзавестись подсистемой хранения, способной переварить огромные IOPSы по записи.

Был и еще целый ряд проблем и недостатков, которые нам пришлось устранить, разбираясь в ребусах исходного кода.

В докладе будет рассказ о внутреннем устройстве LMDB, о сильных и слабых сторонах движка, и, конечно, о сделанных нами доработках:
- Краткое пояснение того, зачем нам потребовался OpenLDAP и LMDB.
- Обзор внутреннего устройства LMDB с пояснением преимуществ.
- Разбор выявленных проблем и недостатков.
- Рассказ о наших доработках и их последствиях, а именно:
- подпункт 1: автоматические «точки синхронизации» по объему и по секундам.
- подпункт 2: LIFO-порядок для page reclaiming (Garbage Collection).
- подпункт 3: OOM-handler и «разборки» с отстающими читателями.
- подпункт 4: «устойчивые» и «слабые» снимки базы.
- подпункт 5: максимум асинхронной записи и автоматическое создание «устойчивых» снимков.
- Варианты развития: «контрольная сумма» для каждой страницы и Merkle Tree для внутренних структур (как git).

Информация о нашем проекте = https://github.com/ReOpen/ReOpenLDAP/wiki
Дополнительная информация об исходной версии LMDB = http://symas.com/mdb/