The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Выпуск встраиваемой СУБД libmdbx 0.13

08.09.2024 22:09

Опубликован выпуск библиотеки libmdbx 0.13.1 (MDBX) с реализацией высокопроизводительной компактной встраиваемой базы данных класса ключ-значение. Код libmdbx распространяется под лицензией Apache 2.0. Поддерживаются все актуальные операционные системы и архитектуры, а также российский Эльбрус 2000. Для libmdbx предлагается развитое API для C++, а также поддерживаемые энтузиастами привязки к языкам Rust, Haskell, Python, NodeJS, Ruby, Go, Nim, Deno, Scala.

Исторически libmdbx является глубокой переработкой СУБД LMDB и превосходит своего прародителя по надёжности, набору возможностей и производительности. В сравнении с LMDB, в libmdbx большое внимание уделяется качеству кода, стабильной работе API, тестированию и автоматическим проверкам. Поставляется утилита проверки целостности структуры БД с некоторыми возможностями восстановления. Технологически libmdbx предлагает ACID, строгую сериализацию изменений и неблокирующее чтение с линейным масштабированием по ядрам ЦПУ. Поддерживается автокомпактификация, автоматическое управление размером БД, оценка объёма выборок по диапазонам (range query estimation).

Основные изменения:

  • Изменение лицензии на код с OpenLDAP Public License на Apache 2.0.
  • Расширение API курсоров более удобными и очевидными операциями позиционирования по аналогии условиям <, <=, ==, >=, > как для ключей, так и для пар ключ-значение. Добавлены функции mdbx_cursor_unbind(), и mdbx_txn_release_all_cursors() для гибкого управления курсорами в сценариях повторного использования для уменьшения накладных расходов. Функции mdbx_cursor_scan() и mdbx_cursor_scan_from() для сканирования таблиц с использованием функционального предиката и уменьшением сопутствующих накладных расходов.
  • Переработка курсоров для унификации поведения, более регулярного кода, уменьшения количества ветвлений и машинных операций.
  • Перенос функциональности утилиты mdbx_chk внутрь библиотеки в виде функции mdbx_env_chk() для проверки целостности структуры БД, в том числе с вовлечением логики приложения.
  • Опция MDBX_opt_gc_time_limit для более гибкого контроля времени, расходуемого на поиск последовательностей соседствующих свободных страниц в GC.
  • Существенное снижение накладных расходов на запуск транзакций в сценариях с большим количеством DBI-хендов, за счёт отложенной/ленивой инициализации элементов служебных таблиц. В том числе, механизм поддержки разрежённых наборов DBI-хендов, управляемый опцией сборки MDBX_ENABLE_DBI_SPARSE, которая включена по умолчанию.
  • Снижение накладных расходов на открытие DBI-хендов. В том числе, механизм отложенного освобождения и поддержки быстрого пути открытия без использования блокировок, управляемый опцией сборки MDBX_ENABLE_DBI_LOCKFREE, которая включена по умолчанию.
  • Поддержка “парковки” читающих транзакций с их вытеснением ради переработки старых MVCC-снимков и предотвращения проблем, вызываемых приостановкой переработки мусора. Механизм парковки и вытеснения припаркованных транзакций является как дополнением, так и более простой в использовании альтернативой обратному вызову Handle-Slow-Readers. Для удобства функции mdbx_txn_park() и mdbx_txn_unpark() имеют дополнительные аргументы, позволяющие запросить автоматическую “распарковку” припаркованных и перезапуск вытесненных транзакций. В утилиту mdbx_copy добавлены соответствующие опции -d и -p.
  • Поддержка восстановления открытой среды работы с БД в дочернем процессе после ветвления/расщепления процесса посредством mdbx_env_resurrect_after_fork().
  • Поддержка переименования таблиц посредством mdbx_dbi_rename() и mdbx_dbi_rename2(). Добавлена функция mdbx_enumerate_tables() для получения информации об именованных пользовательских таблицах.
  • Режим работы MDBX_NOSTICKYTHREADS вместо MDBX_NOTLS для упрощения интеграции с легковесными потоками/нитями их мультиплексирования вместе с транзакциями по потокам операционной системы.
  • Для идентификации БД добавлен UUID доступный в поле mi_dxbid структуры MDBX_envinfo, получаемой посредством mdbx_env_info_ex(). Реализовано получение информации о БД без её открытия посредством mdbx_preopen_snapinfo().
  • Поддержка функций логирования обратного вызова без функциональности vprintf(), что существенно облегчает использование логирования в привязках к другим языкам программирования.
  • Добавление в API функций mdbx_txn_copy2pathname() и mdbx_txn_copy2fd().
  • Реструктуризация исходного кода с рефакторингом.
  • Использование термина "таблица" вместо "subDb".
  • Объявление устаревшими опций MDBX_COALESCE и MDBX_NOTLS. Замена сборочной опции MDBX_USE_VALGRIND на общепринятую ENABLE_MEMCHECK.


  1. Главная ссылка к новости (https://gitflic.ru/project/ert...)
  2. OpenNews: Выпуск встраиваемой СУБД libmdbx 0.12.3
  3. OpenNews: Релиз LDAP-сервера ReOpenLDAP 1.2.0
  4. OpenNews: Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/61830-libmdbx
Ключевые слова: libmdbx
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (33) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 23:08, 08/09/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Скажите, есть ли какой-то смысл использовать подобные db вместо, например, sqlite?
    В чём преимущество?
     
     
  • 2.2, мяя (?), 23:12, 08/09/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Скорость, компактность реализации.
     
  • 2.3, Совершенно другой аноним (?), 23:24, 08/09/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ну, как-бы, это разные вещи. В SQLite доступ посредством SQL, табличное представление данных, а в тут - доступ спец-функциями и представление данных "ключ-значение".
     
     
  • 3.6, Аноним (1), 23:39, 08/09/2024 [^] [^^] [^^^] [ответить]  
  • –3 +/
    В плане представления данных разница не такая уж большая между SQL и ключ-значение. В SQL базах строки таблиц это тоже по сути поле-ключ и всё остальное (остальные поля).
    Но SQL сильно упрощает создание запросов и управление структурой db - удаление/добавление таблиц/индексов, задание связей между таблицами. Для баз ключ-значение больше труда нужно для создания цепочек вызовов функций, а результат тот же.
    Явный недостаток SQL - то что движок сложнее.
     
     
  • 4.13, Карлос Сношайтилис (ok), 02:37, 09/09/2024 [^] [^^] [^^^] [ответить]  
  • +/
    SQL – это диалект.
    Его могут поддерживать разные, по типу, бд, например, строчные или колоночные. А у них сильно разные принципы хранения.
     
     
  • 5.46, Аноним (46), 19:56, 10/09/2024 [^] [^^] [^^^] [ответить]  
  • +/
    SQL - это не диалект а язык. Диалекты у его реализаций.
     
  • 2.4, Самый умный аноним (?), 23:28, 08/09/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > В чём преимущество?

    gitflic.ru

     
     
  • 3.31, OpenEcho (?), 13:30, 09/09/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > gitflic.ru

    Это все равно что ткнуть в github.com

     
  • 2.5, Аноним (5), 23:38, 08/09/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Если вас устраивает условный sqlite, то подобные движки вам не нужны.

    Преимущество же в меньших накладных расходах и, соответственно, более высокой производительности и/или меньшем потреблении ресурсов.

    Например, Ethereum сейчас сидит на libmdbx, а Monero на LMDB.
    Упомянутый sqlite такое не потянет, будет в 1000 раз медленнее и памяти будет жрать раз в 100 больше.

     
     
  • 3.11, нах. (?), 01:47, 09/09/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    "показатели достигли потолка, с которого первоначально и были взяты"(c)

    Подтверждать эту чепуху тестами вы конечно же не будете, джентльменам ведь верят на слово.

     
     
  • 4.14, Аноним (5), 03:36, 09/09/2024 [^] [^^] [^^^] [ответить]  
  • +6 +/
    1.
    Автор LMDB в 2010-2014 публиковал результаты бенчмарков. В том числе он сделал sqlightning (пересадил sqlite на LMDB), на простых тестах там _местами_ разница более 20 раз.

    2.
    У Erigon был блог, где Alex Sharp описывал приключения по выбору движка БД, включая многие эксперименты.
    В результате они остановились сначала на LMDB, а когда начались проблемы перешли на MDBX.

    3.
    Команда Paradigm (разработчики Reth) после "заимствования" кода у Akula, несколько раз пытались соскочить с libmdbx по идейно-политическим соображениям. Но так и не смогли из-за "catastrophic performance degradation", несмотря на лимоны зелени в бюджете.

    --

    Короче, в подходящих сценариях и при правильном использовании, libmdbx точно может быть до 20-25 раз быстрее sqlite. А на масштабах Ethereum выигрыш может быть намного больше, просто из-за большого кол-ва данных (и работе unified page cache).

    Другое дело, что не все сценарии подходящие и большинство пользователей/разработчиков никогда не заметят разницы между 0.001 и 0.00001 секунд. Ну и использование SQL гораздо комфортнее чем возня с key-value.

     
     
  • 5.19, llolik (ok), 07:13, 09/09/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну и использование SQL гораздо комфортнее чем возня с key-value

    От того же автора есть libfpta, которая построена на libmdbx, и по-сути реализует классические таблицы над key-value libmdbx.

    https://gitflic.ru/project/erthink/libfpta

     
  • 5.23, Gemorroj (ok), 09:47, 09/09/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    это же пох.  с ним говорить вообще бесполезно. он конченный
     
     
  • 6.27, Аноним (27), 11:09, 09/09/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    почему? польза есть, вон сколько фактов интересных написали в ответ
     
     
  • 7.35, _ (??), 16:46, 09/09/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > почему?

    Потому что пЫонеров чмырит "с особым цЫнизмом"(С) :-)
    Вон слёзки как капают у некоторых...

    А по профессии он не чаще других загонялся и гнал пургу :) Но это мы все могЁм, включая меня :)

     
  • 6.29, OpenEcho (?), 13:04, 09/09/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Помоему в данном, конкретном случае его коммент на фразу: "будет в 1000 раз медленнее и памяти будет жрать раз в 100 больше." очень даже уместен. Это же цифры правда с потолка, в отличии от follow up на пох пост
     
  • 5.28, Аноним (28), 12:55, 09/09/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Делать бенчмарки, сравнивающие key-value хранилище c sql-бд - вот что полностью характеризует человека и все его поделки.
     
     
  • 6.32, Аноним (32), 14:49, 09/09/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, на подобном сравнивании теплого с мягким вырос целый Фороникс.
    Не смотря на присущий скептицизм при анализе результатов проводимых им тестов,
    он все же сделал много и полезного (те же тесты от фороникса).
     
  • 6.42, Аноним (42), 21:04, 09/09/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Делать бенчмарки, сравнивающие key-value хранилище c sql-бд - вот что полностью характеризует человека и все его поделки.

    Так вы даже не поняли написанного.

    Там сравнивались НЕ key-value с sql, а оригинальный sqlite (с собственным b-tree) и sqlightning (sqlite, в котором исходный b-tree "грязно и тупо" заменен на LMDB).

    Иначе говоря, сравнивалось НЕ "теплое с мягким", а LMDB и собственный внутренний движок хранения sqlite.
    Причем при одинаковом sql-фронтенде и исполнительной машине байт-кода "скомпилированного sql".

     
  • 5.43, Аноним (43), 23:04, 09/09/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо, конечно, за любопытные сведения, но прирост в 20 раз на *некоторых* простых тестах это далеко не
    >Упомянутый sqlite такое не потянет, будет в 1000 раз медленнее и памяти будет жрать раз в 100 больше.
     
     
  • 6.44, Аноним (42), 23:22, 09/09/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Если смотреть на Ethereum, точнее говоря на  Erigon (который самый быстрый из "frontiers", готовых к продуктовому использованию), то объем БД там 2-6 терабайт (в зависимости от типа узла и подвида блокчейна), а объем транзакций (суммарный размер вставляемых и/или обновляемых данных) порядка 10-100 гигабайт.

    Так вот, если верить написанному по ссылке ниже, то производительность sqlite деградирует нелинейно с увеличением размера БД и объема транзакций. Поэтому весьма и весьма вероятно, что sqlite впендюренный (уж извините) в Erigon будет работать действительно на 2-3 порядка медленнее libmdbx.

    Причем это не считая операций чтения, которые (судя по бенчмаркам и исходному коду) в sqlite примерно в 20-25 раз медленнее чем в libmdbx. И тут важно понимать, что никаких чудес нет -- libmdbx просто почти ничего не делает, только минимум операций (предельно близко к теоретическому пределу) и подкачка данных с диске (причем тут существенный overhead из-за hard page faults, ибо  memory mapped).

    https://softwareengineering.stackexchange.com/questions/332069/what-is-a-reali

     
  • 2.41, Аноним (41), 18:06, 09/09/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Зависит от задачи.
    Если sqlite - это РСУБД, которая сама реализует стратегии объединения, сортировки, группировки и т.д., и выбирает их, построив план запроса (который может оказаться удачным, а может и не очень - это всегда в определенной мере эвристика), то подобные библиотеки представляют низкоуровневые API, с помощью которых это всё делается самостоятельно из небольших кирпичиков, что требует заметно больших усилий, но и позволяет максимально оптимизировать под конкретные задачи.
     

  • 1.8, Амомин (?), 00:24, 09/09/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Кроме Эфира есть еще какие-то на слуху проекты использующие сабж?
     
     
  • 2.9, Аноним (5), 00:30, 09/09/2024 [^] [^^] [^^^] [ответить]  
  • +/
    ptsecurity.ru
     
     
  • 3.21, Амомин (?), 08:10, 09/09/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ого, а зачем рекламному сайту лендингу быстрая встраиваемая БД?
     
     
  • 4.22, я (?), 08:25, 09/09/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Ого, а зачем рекламному сайту лендингу быстрая встраиваемая БД?

    Не лендингу, а используется в продуктах компании. Собственно для этого и делается.

     
     
  • 5.39, Амомин (?), 17:09, 09/09/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Окей так и запишем - нигде кроме эфира и каких-то проприетарных продуктов какой-то компании которые большинство местных в глаза не видело и врядли увидит не используется.
     
     
  • 6.45, Аноним (42), 23:25, 09/09/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Есть подозрение, что глобусу и сове на нём как-то всё равно что вы там куда-то записали ;)
     
  • 2.10, я (?), 00:43, 09/09/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Аффтар где-то писал, что на libmdbx переходят все у кого были проблемы с LMDB, и это вроде-бы как 10% от проектов использующих LMDB.

    Ну м в эфире два разных проекта (erigon на Go и reth на Rust).

     
     
  • 3.16, ананим.orig (?), 04:22, 09/09/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Не знаю как сабж, а вот lmdb database backend в самбе можно использовать
    https://wiki.samba.org/index.php/Using_the_lmdb_database_backend
     
     
  • 4.20, dab1818 (?), 07:56, 09/09/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    как они все оттуда и выросли же:
    lmdb в составе openldap - одних авторов,
    libmdbx как форк lmdb в составе reOpenLdap форка openldap - товарищем Леонидом Юрьевым.
     
  • 2.34, Аноним (34), 16:11, 09/09/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А он не децентрализованный чтоли? Что еще за БД в блокчейне?
     
     
  • 3.40, Амомин (?), 17:10, 09/09/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ну а сам чейн этих самых блоков как-то надо хранить локально, не?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру