Просмотр исходного текста страницы Libmdbx key-value storage — кандидат в лучшие из встраиваемых (Леонид Юрьев, OSSDEVCONF-2017)

=== Сценарии использования libmdbx ===
Исходя из свойств и внутренних механизмов libmdbx можно выделить три группы областей применений или сценариев
использования libmdbx: подходящие, пограничные, противопоказанные. Однако, практика показывает что такое подразделение
достаточно условно и правильнее оценивать сумму факторов, каждый из которых вытекает из отдельного свойства libmdbx и
может быть как положительным, так и отрицательным в каждом конкретном случае. Кратко рассмотрим самые важные свойства и
связанные с ними плюсы/минусы:

Встраиваемый движок:

Встраиваемость становится весомым плюсом когда отдельный серверный процесс не требуется, тем более если этого хочется
избежать.

С другой стороны, при встраивании, со стороны остального кода, есть неизбежный риск повреждения внутренних структур
данных движка. Что может приводить к повреждению БД. Характерным примером может служить «удачная» запись нуля по
некорректному указателю, которая заставит движок сделать запись в нулевую (управляющую) мета-страницу БД.

Данные отображены в ОЗУ:

Отображение в память позволяет кардинально снизить накладные расходы на доступ к данным и не иметь какой-либо
собственной инфраструктуры кеширования (всё необходимое выполняется ядром ОС). В частности, в libmdbx можно легко
избежать лишнего копирования данных (zero copy) получая непосредственно указатель на read-only отображение в памяти.

С другой стороны, могут быть затруднения если объём данных превышает размер ОЗУ или механизмы управления виртуальной
памятью неверно настроены и/или работаю не оптимально (Windows 8).

Кроме этого, в сравнении с хранилищами основанными на LSM-деревьях (Log-Structured Merge-tree), в libmdbx новые и старые
данные равны между собой. Поэтому на больших объёмах libmdbx может проигрывать в сценариях с частым доступом к недавно
добавленным данных. Однако, стоит отметить, что на практике ситуация зависит от массы факторов и может быть кардинально
обратной. Например, «горячие» и/или недавно добавленные данные с большой вероятностью НЕ будут вытесняться из ОЗУ и
кэша процессора, и тогда libmdbx может быть на порядок более эффективнее LSM-деревьев, что подтверждается
соответствующими тестами.

Отсутствие журнала транзакций:

Пожалуй это один из самых принципиальных моментов, который, в зависимости от требований, может становиться как
радикальным плюсом, так и большим минусом. Вопрос сложен и неразрывно связан с гарантиями сохранности данных и
производительностью для операций изменяющих данные. Но давайте попробуем тезисно разобраться (далее предполагается что
читатель знаком или ознакомится с терминами «журнал опережающей записи» и «журнализация транзакций» в Википедии).
*  При низком темпе изменений данных, отсутствие или наличие журнала не окажет значимой разницы. Скорее всего мы
предпочтем полностью фиксировать данные на диске после каждой транзакции. Например, такой простой сценарий является
классическим для LDAP.

В этом случае libmdbx вероятно будет абсолютным чемпионом, так как позволяет выполнять читающие запросы сколь угодно
параллельно, без блокировок и с минимальными накладными расходами.
*  При высоком темпе изменений, точнее при фиксации этих изменений, узким местом становится диск. Чтобы записывать
меньше данных, и преимущественно последовательно, придётся вести журнал и тратить на него ресурсы, в том числе что-то
делать дважды: сначала делать промежуточное «быстрое» фиксирование в журнале, а позже ещё раз внутри БД. 

Однако, важнее то, что использование журнала потребует восстановления БД после аварии. Такое восстановление может быть
длительным, и даже потребовать участия человека (например, при нехватке места), что в ряде применений может быть
неприемлемым. Поэтому отсутствие фазы восстановления в libmdbx может стать решающим плюсом.
*  Несомненно использование журнала дает выигрыш в производительности, особенно на шпиндельных дисках (HDD). Но
нередко упускается тот факт, что для гарантии сохранности данных требуется фиксировать изменение самого журнала после
каждой транзакции, что крайне драматически сказывается на итоговой производительности.

Например, журнал обычно располагается в файловой системе, нередко на одном физическом устройстве с телом БД или другими
изменяемыми сущностями. При этом реальная фиксация данных требует выполнения носителем всей очереди команд и выдачи
подтверждения (наличие нескольких логических очередей не означает что драйвер и ОС будут ими пользоваться, а также не
означает что встроенный контроллер носителя будет действительно независимо их обслуживать). В результате, фиксация
транзакции всё также «стреляет по диску дробью», как если-бы журнала не было. Причём в случае SSD ситуация во многом
схожая — нет затрат на перемещение головок, зато данные пишутся большими секторами в несколько шагов, что при
синхронном выполнении с подтверждением занимает достаточно времени.

Поэтому, практически всегда приходится жертвовать гарантиями сохранности данных. Проще говоря, если при аварии мы готовы
потерять некоторое количество последних изменений, то можем фиксировать журнал реже или как-получится, тем самым подняв
производительность ещё на порядок или более.

В целом, здесь речь всегда идёт о компромиссе между производительностью и гарантиями сохранности данных в терминах
объема потерь при аварии. В libmdbx предлагается несколько вариантов подобного компромисса:
* «простая» отложенная запись в файлы ядром ОС;
* автоматическая фиксация по объёму изменений и/или по времени;
* асинхронная «догоняющая» фиксация (в разработке);
* полностью асинхронная фиксация по усмотрению ядра ОС;
* явная «ручная» фиксация через API.

По оценкам автора, за счёт предлагаемых компромиссов и возможностей, libmdbx  может более чем успешно конкурировать в
подавляющем большинстве сценариев. Тем не менее, следует понимать что в абсолютных цифрах WAF (Write Amplification
Factor) в libmdbx, скорее всего и почти всегда, будет больше чем в движках с хорошо реализованным WAL (write-ahead
log).

Проблема долгих чтений в MVCC:

Подобная проблема так или иначе существует во всех СУБД, которые обеспечивают конкурентную обработку читающих и пишущих
запросов с соблюдением ACID (aka MVCC bloat). Суть в том, что для любой читающей транзакции, на всё время жизни такой
транзакции, СУБД должна обеспечивать консистентный набор данных, который не меняется с точки зрения читателя. Если при
этом происходит интенсивное изменение данных, то все данные могут быть изменены и для поддержания долгой читающей
транзакции может потребоваться дополнительное место, равное объёму данных на момент старта читающей транзакции.

В случае libmdbx проблема проявляется более остро и на это есть две веские причины:
*  Ради производительности libmdbx отслеживает использование страниц через линейную проекцию истории их изменения.
Поэтому сборка мусора крайне эффективна (дешева), но может происходить только последовательно от старых версий снимков
данных к новым. В результате сборка мусора вынужденно приостанавливается на самой старой (дальней)
используемой/читаемой точки в истории данных.

Другими словами, одного «застрявшего» читателя достаточно чтобы приостановить сборку мусора и вызвать переполнение БД.
*  Высокая производительность позволяет израсходовать всё свободное место относительно быстро.

Для решения проблемы текущая версия libmdbx предлагает использовать обратный вызов, который, в частности, может либо
подождать «застрявшего» читателя, либо прервать его транзакцию.

В будущих версиях libmdbx планируется реализовать механизм аварийной сборки мусора, который ценой относительно большого
объёма операций будет искать неиспользуемые страницы глядя «сквозь» всю линейную историю, не останавливаясь на
последней используемой версии данных. Можно сказать, что этот механизм будет по-требованию выполнять аналог VACUUM из
PostreSQL.