Опубликован выпуск библиотеки libmdbx 0.13.7 (MDBX) с реализацией высокопроизводительной компактной встраиваемой базы данных класса ключ-значение. Код libmdbx распространяется под лицензией Apache 2.0. Поддерживаются все актуальные операционные системы и архитектуры, а также российский Эльбрус 2000. Для libmdbx предлагается развитое API для C++, а также поддерживаемые энтузиастами привязки к языкам Rust, Haskell, Python, NodeJS, Ruby, Go, Nim, Deno, Scala. Из проектов, использующих libmdbx, можно отметить Isar, Erigon и Reth, а также разработки компаний StarkWare и Positive Technologies...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63653
Что-то ошибок многовато
Автор как-то слишком страшно и дотошно формулирует описание исправлений.
Ошибки-то в совсем новом API и проявлялись только на маке.
А остальное и ошибками можно не называть, в GCC таких сотни, если не тысячи.
Вот что автор пишет про свою СУБД:
"libmdbx is extraordinarily fast ... in the case of libmdbx, a simple linear search may be more profitable than complex indexes"Просто перебирайте значения
Вот ещё:
"In comparison to LMDB, libmdbx make things “just work” perfectly and out-of-the-box"
А вот так и есть.
Работает без глюков LMDB.
Почитайте блог разрабов Erigon.
Про асимптотическую сложность не слышал, чо. Действительно, нафига нам индексы.
Ага, и написано это в подразделе Gotchas.On the other hand, if you make something suboptimally, you can notice detrimentally only on sufficiently large data.
Автор там похоже удачно стебёться над любителями кодить и читать по-верхам не вникая ;)
Там имелось в виду, что нужно вдумчиво подходить к вопросу селективности.Например, увеличение длины ключа на 1 байт ради более точного поиска может сделать хуже/медленнее чем приблизительный поиск DUPSORT-куста и перебор в нём значений.
Пользуюсь, нареканий нет, спасибо автору!
Офигенно работает, и поддержка первоклассная!В телеге автор очень оперативно и подробно отвечает на все вопросы.
Помог быстрее чем службы поддержки ptsecurity и солара.
Спасибо.
Ещё на его странице: "Donations are welcome to the Ethereum/ERC-20 ... Всё будет хорошо!"А для кого хорошо? Напомню, оплата товаров и услуг криптовалютой запрещена в России с 2021 года
А причем тут донаты и продажа крипты?
"Since 2020 libmdbx is used in Ethereum"
Ну так логично что автор собирает донаты от индустрии.
Но причем тут запрет на оплату криптой товаров и услуг?
Так эти самые донейшены - разве не скрытая оплата товара?
Диванные юристы на опеннете :)
Нет тут никакой скрытой продажи, ведь вы не приобретаете ни товар, ни услугу.
Исходники, документация, поддержка доступны вне зависимости от крипты.Причем приём платежей в крипте запрещен внутри РФ, но разрешен из-за рубежа.
Что-то баз данных ключ-значение много очень стало
десятилетиями блобы хранились в обычных реляционных субд, но кто-то с похмелья подумал что блобы в традиционных субд хранятся неоптимально, на страницах с обычными данными и оперативная память "забивается", и понеслась...
Дидам хватало — и нам должно хватать, да.
Только полные еб***шки думают что SQL db появились __ДО__ key-value db ...
О сколько _вам_ открытий чудных готовит!(С) Наше всиО
Если "сводные таблицы" не планируются, то зачем заморачиваться с реляционностью?
Чем она лучше dbm?
ACID
Доступ из нескольких процессов.
Работа читателей без блокировок.
Поддержка "дубликатов", когда с ключом связано очень много значений они хранятся во вложенном b-tree.
Много key-value таблиц в одном файле.
Нахрена козе боян когда есть всеми используемый sqlite?
Для большинства web-поделок и мобильных свистелок sqlite подходит идеально.
И 99% разработчиков MDBX не нужна, именно как баяйн козе.Но есть куча сценариев где удобство sqlite малополезно или слишком дорого, либо когда масштаб не-лайтовый как в Ethereum. Поэтому, например, Erigon и Reth сидят на MDBX.
Еще sqlightning (https://github.com/LMDB/sqlightning) намекает что sqlite можно ускорить заменив внутреннее хранилище и b-tree на LMDB. За 12 лет инфа конечно устарела, но в Isar (БД для Flutter, с блекджеком и т.п.) была поддержка sqlite и выходило что MDBX примерно вдвое быстрее. Картинки с результатами и исходники бенчмарков где-то на Github.
На фоне BerkeleyDB это MDBX просто школьное поделие. Мало того, у BDB лицензия AGPL, а у MDBX -- Apache.
Ключевое различие между лицензиями:
- AGPL накладывает сильные обязательства по открытию исходного кода при любом использовании программного продукта, в том числе через сеть, что характерно для копилефтных лицензий.
- Apache 2.0 — разрешительная лицензия с защитой патентов, дающая больше свободы в использовании и включении кода в закрытые проекты без обязательств раскрывать исходный код.
Поделие уделывает LMDB, а LMDB как тузик грелку рвет этот ваш фон.
Не только лишь все могут это принять.
Главное батхерт успеть вылечить до начала деменции.
> Поделие уделывает LMDB, а LMDB как тузик грелку рвет этот ваш фон.Смешно. Оно и пятой части возможностей BDB не реализует, какая тут грелка. Попытка что-то сляпать на замену. Поверх BDB MySQL был написан. Напиши что-либо похожее поверх этого поделия.
По части MySQL вы заблуждаетесь, а информация с отсылкой к MySQL не соответствует действительности:1. MySQL не был написан поверх Berkeley DB.
Поддержка BDB как одного из storage engine была добавлена в 2000 спустя примерно 5 лет после первого релиза, а еще через 5 лет удалена.
Подключали BDB (предположительно, свечку не держал) для "попробовать улучшить" некоторые показатели, но результат не оправдал ожиданий.
Berkeley DB не дала ничего хорошего: ни производительности, ни стабильности, ни уменьшения потребления памяти, ни популярности.
Пользователи не пользовались BDB, а по объективным причинам предпочитали MyISAM или InnoDB.
Поэтому возможность использования Berkeley DB удалили из MySQL почти 20 лет назад.2. Нет принципиальных препятствий для использования MDBX/LMDB в качестве storage engine в SQL-движках, в том числе в MySQL.
Это может подтвердить любой специалист разбирающийся в теме.
Более того, эксперимент с SQLightning (SQLite пересаженный на LMDB) показал кратный рост производительности в релевантных сценариях.
Далее, если не ошибаюсь, то уже давал комментарии/пояснения по теме "сравнения" BerkeleyDB и MDBX, но видимо стоит повторить.1. MDBX является развитием/допеределкой LMDB.
При этом исправлено множество ошибок, добавлены новые возможности, ликвидированы или смягчены архитектурные проблемы, принципиально (до нескольких порядков) увеличена производительность в специфических нагруженных сценариях, и т.д. Однако, все базовые свойства и возможности сохранены.
Поэтому сравнивать с BDB лучше LMDB, но не забывая что MDBX "тоже самое, только лучше".2. LMDB была создана Говардом Чу (Howard Chu) для OpenLDAP ради избавления от проблем BerkeleyDB.
В Сети можно найти массу соответствующих материалов (слайды, статьи, видео, результаты бенчмарков и исходный код).
Первые тесты Говарда показали что LMDB в 2-3 раза быстрее BerkeleyDB, процесс slapd потреблял в 2-3 раза меньше памяти, даже БД была на 30% меньше, и т.д.3. Пожалуй принципиальное отличие MDBX/LMDB от BerkeleyDB в отсутствии накладных расходов на лишнее.
Нет затрат на возню с блокировками, так как для читателей обеспечивается lockfree, а пишущие транзакции сериализуются одним мьютексом.
Нет затрат на возню с кешированием, так как файл БД отображенный в память автоматически кешируется ядром ОС (причем с использованием всего свободной памяти).
Нет затрат на WAL и undo/redo/replay при открытии БД, и т.д.
Поэтому MDBX/LMDB просто делают меньше системных вызовов и меньше тратят таков ЦПУ на обработку запросов.4. Тем не менее, MDBX/LMDB действительно являются относительно простыми/прозрачными движками хранения (без собственных тредов, без WAL) с отображением БД в ОЗУ.
Соответственно, "совершенно внезапно" они хорошо подходят для одних сценариев использования и совсем не подходят для других (много раз отвечал/пояснял в комментариях на opennet).
В том числе, конечно, есть сценарии где BDB будет предпочтительнее и/или даже лучшим вариантом из-за наличия конкретных фичей/возможностей.5. В подходящих (хотя-бы не противопоказанных) сценариях использования, MDBX/LMDB позволяют получить потребительские качества кратно превосходящие Berkeley DB.
Это не значит что так будет всегда, и/или во всех случаях, и/или без дополнительных усилий, но всё-таки MDBX/LMDB _могут_ быть намного быстрее BDB.
А MDBX еще может эффективно обрабатывать огромные пишущие транзакции (с объемом изменений в сотни гигабайт, в БД размером в несколько терабайт).Как-то так.
> 2. LMDB была создана Говардом Чу (Howard Chu) для OpenLDAP ради избавления
> от проблем BerkeleyDB.От нормальных курсоров и вторичных индексов, да? От детального управления транзакциями, в том числе и вложенными? И что в таком случае остается? -- А то, что невозможно использовать кроме как на локалхосте для кеширования.
Все то, от чего избавился этот ваш Чу, позволяет во многих случаях избавиться от использования sql-серверов. Я знаю несколько достаточно больших проектов на базе BDB, реально работающих более 15 лет. Среди них есть такой, который обслуживает в режиме OLTP полторы сотни клиентов в среднем одновременно.
Исходное API LMDB во многом копирует Berkeley DB, но с существенным упрощением за счет отказа от лишнего.Курсоры в MDBX/LMDB такие же как в Berkeley DB.
Точнее говоря, некоторые отличия есть, но сводятся к объективным отличиям в возможностях движков.
Вложенные транзакции тоже есть, и non-durable тоже. Но ими почти никто не пользуется.В OpenLDAP вторичные индексы были не нужны и Говард не стал их делать (а я бы наверное сделал).
Однако, несмотря на полезность вторичных индексов в реальности они оказались не востребованными:
- если возможностей простого key-value не хватает индустрия предпочитает SQL (SQLite либо внешний сервер);
- там где накладные расходы на SQL слишком велики и вложения в разработку оправданы, реализуются собственные схемы со всякими трюками и экономией на спичках.30 лет назад, когда делали BDB, всё было иначе. В том числе, диски были медленнее и собственные накладные расходы BDB на кеширование и блокировки были незаметны.
Языков программирования и их runtime-сред было сильно меньше.
Темп изменений в схемах данных был на порядок меньше.
Поэтому было приемлемо заморачиваться с BDB и возится с собственными кортежами и индексами.Сейчас же всё сводится к трем вариантам и их комбинации:
1) SQLite или SQL-сервер;
2) key-value из-за достаточности и/или простоты схемы данных;
3) собственные решения ради уменьшения накладных расходов.Вторичные индексы BDB тут оказываются не востребованными, а часто и BDB в целом.
MDBX/LMDB же работают в пунктах 2 и 3, но (конечно) не во всех случаях, а там где подходят под сценарий использования БД.Всё сказанное не ставит под сомнения факта что есть много проектов использующих BDB.
Однако, в основном это именно проекты возрастом от 15 лет и старше.