ктото работал с ней? реально она самая быстрая во всех сценариях? по идее судя по архитектуре быстрее сделать невозможно, но мож есть какието drawbackи?

Здравствуйте, Barbar1an, Вы писали:

B>ктото работал с ней? реально она самая быстрая во всех сценариях? по идее судя по архитектуре быстрее сделать невозможно, но мож есть какието drawbackи?

Я с ней не работал. Но ты должен понимать, что быть самым быстрым "во всех сценариях" невозможно, drawbackи есть всегда.
https://dbdb.io/db/lmdb

Так же есть https://github.com/erthink/libmdbx

Здравствуйте, Barbar1an, Вы писали:

B>ктото работал с ней? реально она самая быстрая во всех сценариях? по идее судя по архитектуре быстрее сделать невозможно, но мож есть какието drawbackи?

Ну, это просто key-value поверх B-tree, со всеми вытекающими плюсами и минусами.
Конкретно в этой реализации — не факт, что persistance будет наиболее эффективным, так как при fsync идет запись всех изменившихся страниц с данными, а не только потоковая запись лога (т.е. если часто менять по одному ключу в разных местах, то производительность будет невысокой).
Настройка эффективности работы кэшей на OS тоже вещь нетривиальная, а производительность этой БД сильно зависит именно от OS.
Ну и с гарантиями надежности все довольно грустно, нет репликации, например.
И горизонтального масштабирования никакого нет.

Так что это довольно быстрое решение для очень, очень специфических кейсов (
Я бы предпочел FoundationDB для ACID key-value

B>ктото работал с ней? реально она самая быстрая во всех сценариях? по идее судя по архитектуре быстрее сделать невозможно, но мож есть какието drawbackи?
Работал. Основатели стартапа схватили её тупо потому что решение модное и типа "самое быстрое", после чего "гребцы" сделали много удивительных открытий

Закончилось всё тем что в куче мест типичной оптимизацией стало сначала отработать на обычной concurrent-коллекции, и потом скинуть всё в LMDB — типа долговременное хранилище. Иначе перфоманс становился неприемлимым.

В общем я бы второй раз в это чудо влез только при наличии письменных гарантий что нет и никогда не будет _ни_одного_ сценария для которого LMDB "не очень приспособлена". Потому что в их случае "не очень" значит "очень не".

Если уж совсем хочется LMDB — посмотри на libmdbx, это вроде как переосмысление LMDB с исправлением хотя-бы части бед. Обещают CRUD аж на 30% быстрее и много других фич. Сам не работал, но вроде активно используется в продакшене другими и git более живой.

Здравствуйте, Barbar1an, Вы писали:

B>ктото работал с ней? реально она самая быстрая во всех сценариях? по идее судя по архитектуре быстрее сделать невозможно, но мож есть какието drawbackи?

Недостатки/проблемы описаны в документации, и при желании их можно вывести/предсказать из архитектуры.
Как уже советовали лучше смотреть на libmdbx, вот тут например история перехода Ethereum на libmdbx.
Соответственно о недостатках см gotchas и restrictions.

---

Идеологически Говард Чу взял нужное для его сценариев использования и отказался от лишнего.
Целевым же сценарием использования был LDAP, где чтений намного больше апдейтов, а апдейты в основном точечные и без длительных транзакций с большими запросами.
Поэтому в libmdbx/LMDB используется b-tree, нет WAL, полная сериализация пишущих транзакций и почти lockfree для читателей с линейным масштабированием по ядрам.

Это позволило минимизировать накладные расходы, одновременно оставить в базисе Olog(N) для стоимости всех операций.
Из этого следует "алгоритм" понимания подходит ли libmdbx/LMDB для конкретного применения:
— будет ли толк от минимизации накладных расходов (zero-copy при чтении, минимальное кол-ов операций CPU внутри кода СУБД, все остальные фишки/возможности).
— нет ли явных противопоказаний (см ниже и по приведенным выше ссылкам).
— подходит ли модель key-value, либо её надстройки (см libfpta).

--

Отсутствие WAL определяет противопоказанный сценарий: высокий темп пишущих транзакций с размещением БД на шпиндельных дисках без write-back кеша (aka RAID с батарейкой).
Проблема тут в следующем:
— в libmdbx/LMDB используется MVCC за счет CoW и shadow paging, соответственно обновление одной key-value пары требует обновление цепочки страниц от корня b-tree до листа, что генерирует 1+Olog(N) операций seek+write.
— для HDD средняя длительность seek+write составляет 5-20 мс, что позволяет получить только 10-50 транзакций в секунду.
— если же размер БД сильно больше ОЗУ, то операции холодного чтения/поиска также будут генерировать seek+read (как во всех БД).

Особо плохо без WAL когда много коротко-живущих данных: записали, а через несколько секунд удалили.
Для таких сценариев показано LSM, а другие подходы могут сильно уступать.
Однако, при наличии write-back кеша (крайне рекомендуется во всех нагруженных применениях) и/или использовании SSD, ситуация может быть обратной.

--

Второе противопоказание: очень длительные читающие транзакции, на фоне постоянных пишущих транзакций. В той или иной мере эта проблема есть во всех БД с MVCC, но в libmdx/LMDB проявляется сильнее из-за намеренных упрощений. Суть проблемы — долгое чтение останавливает переработку старых снимков MVCC, что в пределе может приводить к распуханию или полному заполнению БД. В libmdbx с этим принципиально лучше, пояснения см по ссылкам выше.

--

Вопросы о libmdbx лучше задавать в телеграм-группе.