Lightning Memory-Mapped Database (LMDB) представляет собой интересный, во многом уникальный движок базы данных класса Berkeley DB и Level DB с ребус-подобным исходным кодом. Будучи относительно малоизвестным, LMDB показывает ЧЕМПИОНСКУЮ производительность по чтению. Однако при интенсивной записи всё не так радужно… Было ещё несколько проблем и недостатков, которые нам пришлось устранить, разбираясь в ребусах исходного кода. Доклад точно будет интересен разработчикам, интересующимся внутренностями баз данных или характеристиками отдельных движков. Проект реализуется силами компании Петер-Сервис R&D, резидента Сколково, для применения в телеком-проектах федерального масштаба. Информация о нашем проекте https://github.com/ReOpen/ReOpenLDAP/wiki, об исходной версии LMDB http://symas.com/mdb/.

1. Движок LMDB
- особенный чемпион
Леонид Юрьев,
Петер-Сервис РнД

2. http://www.billing.ru
Для крупных операторов связи:
BSS, Telco, BigData, HA & HL
Более 20 лет разработки, внедрения и
сопровождения
>125 миллионов абонентов обслуживается с
применением нашего софта

3. Наш герой
LMDB
RocksDB
WiredTiger
Sophia
LevelDB
ForestDB
READ4
SYNC
CRUD
LAZY
CRUD

4. Как мы докатились до LMDB
Немного о внутренностях
Плюсы и минусы
Наша MDBX
ГОСТ 7211-86
ЗУБИЛА СЛЕСАРНЫЕ

5. 1. LDAP используется, нужен сервер
2. Нечаянно выбрали OpenLDAP
3. LMDB внутри
4. Год сурка
5. Вот
Telco  LMDB
MDBX

6. Космический LDAP
1. LDAP-кластер от 2+2
2. До 100 миллионов «записей»
3. Чтение 10K – 100K, Запись 5K – 50K
 принципиально отличается от
«обычных» сценариев использования…

7. Что такое
LMDB ?

8. Встраиваемый движок key-value (!)
Memory-mapped, просто файл и mmap()
B+tree, без WAL, COW
–  восстановление
–  компактификация
ACID поверх MVCC
10К SLOC, 64К кода x86_64
LMDB (1)

9. N неблокируемых читателей
– чтение и поиск без ожидания, всегда
1 писатель
– изменения строго последовательны
– никаких deadlock и rollback error
Амортизационно 𝑶 log 𝟐 𝑵
– включая RAF и WAF
– примерно всегда
LMDB (2)

10. Приятные неожиданности:
– вложенные транзакции
– именованные таблицы
– сортировка для дубликатов
– size_t ключи
И ещё:
– горячее резервное копирование
–  копирования и накладных расходов
– read-write mapping, backed by kernel (!)
LMDB (3)

11. Препарируем…

12. ОБЩИЙ ПУЛ СТРАНИЦ
Три притопа, два прихлопа…
META PAGE
txn #
FREE DBMAIN DB
2

13. META
txn #41
META
txn #42
Copy-On-Write + FLIP-FLOP
 
W
X Y
Z
C
D E
F

14. Отслеживание мусора
42  { C, D, E, F }
C
D E
F
META
txn #41
META
txn #42
 
FREE DB

15. Рабочий цикл
t
free()
alloc()
39  {OPQR}
38  { STUV }
37  { W X Y Z }
42  { C D E F }
41  {EFGH}
40  {KLMN}Занято чтением
Доступно для
переработки
ABCDEFGHIJKLM
NOPQRSTUVWXYZ
ABCDEFGHIJKLM
NOPQRSTUVWXYZ
ABCDEFGHIJKLM
NOPQRSTUVWXYZ
ABCDEFGHIJKLM
NOPQRSTUVWXYZ
ABCDEFGHIJKLM
NOPQRSTUVWXYZ
Последняя транзакция
ABCDEFGHIJKLM
NOPQRSTUVWXYZ

16. Проблемы и
особенности

17. 1. Курсоры, страницы, …
2. Volatile, барьеры памяти
 компилятор гуляет
 heisenbug
3. Read-Write Mapping
 порядок записи не гарантирован
 повреждение базы
Ошибки

18. Проблемы
tНельзя трогать
Кольцо рециркуляции
1. Зависший читатель
 MDB_MAP_FULL
 вымывание I/O-кэша

19. 1. Нет WAL
 𝐖𝐀𝐅 = 𝑶 log 𝟐 𝑵 в страницах
 восстановление не нужно
2. Простой memory-mapping
 paging = 𝑶 log 𝟐 𝑵
 новое = старое
 zero-copy
3.  Предсказуемость поведения*
Особенности

20. OpenLDAPOpenLDAP
1
2
Горизонт
событийИногда падает,
надо бы поправить…

21. 1. АВТО-SYNC и LIFO  лучше IOPS
2. OOM-Handler  бодрит читателей
3. Путь записи
 надежность для Write-Mapping
 steady/weak, есть TODO...
4. MDBX_CHK
Доработки
 MDBX

22. LIFO в MDBX
t
LIFOFIFO
кольцо минимально !

ЗанятоДоступно для переработки

23. Рост B+tree
root42
1 764
74 088
3 111 696
130 691
232
42
5

24. LIFO и BBCbattery-backed cache
𝑁 ∆ × 2 %
128M / 512M
IOPS
FIFO / LIFO
результат
128М / 512М
42 0,34 — 2 / 0,00 —
1 764 14,12 — 3 / 0,00 —
74 088 592,93 21,59% 4 / 0,78 5,10 / 29,31
3 111 696 24,32 0,51% 5 / 1,78 2,81 / 4,48
130 691 232 1021,41 0,01% 6 / 2,78 2,16 / 2,84
результат
128М / 512М
результат
128М / 512М
результат
128М / 512М
результат
128М / 512М
Снижение нагрузки на диск в разы

25. LIFO и BBCbattery-backed cache
Устраняет архитектурную проблему
В разы:
– снижает нагрузку на диски
– повышает производительность
Паралимпиец  Чемпион:
– зависшие читатели не так страшны
– только в MDBX

26. Попробуем
сравнить…

27. Теплое и Мягкое
ТЕПЛОЕ
А
холодное
и жесткое
МЯГКОЕ
Б
холодное
и жесткое
НЕ НУЖНО
= < > 
?

28. Теплое и Мягкое
<
МЯГЧЕ
А Б
>
ТЕПЛЕЕ
А Б
=
С УГЛАМИА Б

29. Метрики
1. КАЧЕСТВО ОБСЛУЖИВАНИЯ
– задержка
– вариация задержки
2. СТОИМОСТЬ
– CPU
– IOPS, WAF, RAF
– место на диске

30. Режимы
SYNC WAL
– непосредственно на диск
– ничего не теряется
 redo
LAZY
– асинхронная фиксация
– хвост может отпасть
NOSYNC
– можно потерять все изменения

31. Бенчмарки
SET – добавляем/обновляем
GET – читаем
CRUD – классическая четверка
BATCH – много четверок пачкой
ITERATE – упорядоченно по ключам
DELETE – чистим

32. Многопоточность
1 NR NR+W NR+NW R+NW NW
SET ●
GET ● ● ●○ ●○ ●○
CRUD ● ○● ○● ○● ●
BATCH ● ○● ○● ○● ●
ITERATE ● ● ●○ ●○ ●○
DELETE ●
SYNC LAZY NOSYNC

33. НЕ ИССЛЕДОВАНИЕ,
А СРАВНЕНИЕ
МИНИМУМ СЦЕНАРИЕВ
– иначе не рассказать
24 ЧАСА
– иначе никогда не успеть
DATA < RAM
– иначе долго, либо не репрезентативно

34. Результаты!

35. Разгон по CPU…
LMDB
WiredTiger
Sophia
RocksDB
LevelDB
ForestDB
8
4
2
1

36. SYNC CRUD104
0.00
0.00
0.00
0.01
0.04
0.11
0.33
1.00
0
100
200
300
400
500
600
700
LMDB WT SOPHIA ROCKS LEVEL FOREST
RPS & LATENCY
сек

37. LAZY CRUD105
1.0E-6
1.0E-5
1.0E-4
1.0E-3
1.0E-2
1.0E-1
1.0E+0
0
10
20
30
40
50
60
70
80
90
100
LMDB WT SOPHIA ROCKS LEVEL FOREST
Thousands
RPS & LATENCY
сек

38. NOSYNC CRUD106
1.0E-6
1.0E-5
1.0E-4
1.0E-3
1.0E-2
1.0E-1
1.0E+0
1.0E+1
0
20
40
60
80
100
120
LMDB WT SOPHIA ROCKS LEVEL FOREST
Thousands
RPS & LATENCY
сек

39. Стоимость
LMDB
WiredTiger
Sophia
RocksDB
LevelDB
Forest I/O SPACECPU

40. Стоимость без ForestDB
LMDB
WiredTiger
Sophia
RocksDB
LevelDB
I/O SPACECPU

41. Что дальше?

42. OpenLDAP & LMDB
forever

43. Что дальше с MDBX ?
1. Фоновая фиксация
– автоматически weak  steady
2. Порядок/Оптимизация
– лишние проверки
– узкие места
3. Release
– документирование
– пакетирование

44. Что потом с MDBX ?
50/50
MDBX  389DS
– Red Hat Directory Server (RHDS)
Merkle Tree  MDBX
– полная потеря совместимости
+ 1Hippeus
OpenDJ  Петер-Сервис

45. Да или Нет ?

46. LMDB или НЕТ ?
Подходит НЕ подходит

47. Спасибо !
LMDB
http://symas.com/mdb/
MDBX
https://github.com/ReOpen/libmdbx
IOARENA2
https://github.com/ReOpen/ioarena