The OpenNET Project / Index page

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

Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10.4 и libfpta 0.3.9

11.10.2021 20:37

Состоялся выпуск библиотек libmdbx 0.10.4 (MDBX) с реализацией высокопроизводительной компактной встраиваемой базы данных класса ключ-значение, и связанной библиотеки libfpta 0.3.9 (FPTA), реализующей поверх MDBX табличное представление данных с вторичными и составными индексами. Обе библиотеки распространяются под лицензиями одобренными OSI. Поддерживаются все актуальные операционные системы и архитектуры, а также российский Эльбрус 2000.

Исторически libmdbx является глубокой переработкой СУБД LMDB и превосходит своего прародителя по надёжности, набору возможностей и производительности. В сравнении с LMDB, в libmdbx большое внимание уделяется качеству кода, стабильной работе API, тестированию и автоматическим проверкам. Поставляется утилита проверки целостности структуры БД с некоторыми возможностями восстановления.

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

Для libmdbx предлагается C++ API, а также поддерживаемые энтузиастами привязки к языкам Rust, Haskell, Python, NodeJS, Ruby, Go, Nim. Для libfpta публично доступно только описание API в виде заголовочного файла C/C++.

Основные новшества, доработки и исправления, добавленные после предыдущей новости от 9 мая:

  • Обеспечена возможность воспроизводимых сборок.
  • Устранена ошибка, из-за которой при очень редком стечении обстоятельств в ходе фиксации транзакции могло происходить зацикливание/зависание. Проблема выявлена специалистами Positive Tecnologies при внутреннем тестировании собственных продуктов.
  • Доработаны тесты и расширены тестовые сценарии для проверки всех достижимых не изоморфных состояний дерева страниц и содержимого GC внутри БД.
  • В C++ API исправлен лишний "noexcept", добавлены дополнительные перегрузки для метода "cursor::erase()", реализация буферов избавлена от использования "std::string" для обеспечения выравнивания (актуально для CLANG libstdc++).
  • Устранён регресс в алгоритме спиллинга грязных страниц (избирательное вытеснение изменённых страниц БД) проявлявшейся редкой неожиданной ошибкой MDBX_PROBLEM при изменении данных в огромных транзакциях.
  • Проведена проверка фазингом с добавлением ряда проверок для обеспечения стабильности при намеренном повреждении БД.
  • Устранены незначительные предупреждения UndefinedBehaviorSanitizer и Coverity Scan issues.
  • Исправлена проверка устаревшего и уже неиспользуемого внутреннего флага "P_DIRTY" во вложенных страницах внутри образов БД созданных старыми версиями библиотеки.
  • В скриптах CMake доработан поиск компонентов компилятора необходимых для LTO (link-time optimization).
  • Максимальное кол-во одновременных читателей увеличено до 32767.
  • Ускорена работа при использовании Valgrind и AddressSanitizer.
  • На Windows устранено рекурсивное использование SRW-lock при работе в режиме MDBX_NOTLS (без использования thread local storage), исправлена генерация bootid в случае изменении системного времени, доработано детектирование WSL1 и WSL2, добавлена возможность открытия БД на Plan 9 смонтированной посредством DrvFS.
  • Суммарно внесено более 160 изменений в 57 файлов, добавлено ~5000 строк, удалено ~2500.

Отдельно хочется поблагодарить команду проекта Erigon (экосистема Ethereum) за помощь в тестировании в экстремальных сценариях использования. Показательно, что за пять месяцев с момента выхода libmdbx v0.10.0, при объёме БД 1-2 Тб в каждой инсталляции Erigon (используется на 7% узлов Ethereum), поступило только три сообщения о повреждении БД, все произошли из-за внешних причин, а не ошибок ПО: в двух случаях причиной были сбои ОЗУ, в третьем ошибка обнуления данных в специфической конфигурации подсистемы хранения с использованием BTRFS.

  1. Главная ссылка к новости (https://github.com/erthink/lib...)
  2. OpenNews: Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10
  3. OpenNews: Опубликован второй кандидат в релизы встраиваемой СУБД libmdbx 1.0
  4. OpenNews: Выпуск LDAP-сервера ReOpenLDAP 1.1.9
  5. OpenNews: Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9.2
  6. OpenNews: Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9.3
Автор новости: Леонид Юрьев
Тип: Программы
Короткая ссылка: https://opennet.ru/55949-libmdbx
Ключевые слова: libmdbx, database
Поддержать дальнейшую публикацию новостей на OpenNET.


Обсуждение (57) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 20:54, 11/10/2021 Скрыто модератором [﹢﹢﹢] [ · · · ]
  • –4 +/
     
     
  • 2.4, Enamel (ok), 21:11, 11/10/2021 Скрыто модератором
  • +2 +/
     
  • 2.7, Аноним (7), 21:23, 11/10/2021 Скрыто модератором
  • +1 +/
     

     ....ответы скрыты модератором (2)

  • 1.3, Аноним (7), 21:09, 11/10/2021 Скрыто модератором [﹢﹢﹢] [ · · · ]
  • –5 +/
     
     
  • 2.5, Аноним (5), 21:14, 11/10/2021 Скрыто модератором
  • +1 +/
     
     
  • 3.6, Аноним (7), 21:21, 11/10/2021 Скрыто модератором
  • +/
     
     
  • 4.8, Аноним (5), 21:26, 11/10/2021 Скрыто модератором
  • +/
     
     
  • 5.10, Аноним (7), 21:31, 11/10/2021 Скрыто модератором
  • –1 +/
     
     
  • 6.17, pansa3 (?), 22:09, 11/10/2021 Скрыто модератором
  • +1 +/
     
     
  • 7.20, Аноним (7), 22:15, 11/10/2021 Скрыто модератором
  • +1 +/
     
  • 3.14, еуые (?), 22:04, 11/10/2021 Скрыто модератором
  • +/
     
     
  • 4.16, Аноним (7), 22:08, 11/10/2021 Скрыто модератором
  • +/
     
     
  • 5.55, n00by (ok), 09:50, 12/10/2021 Скрыто модератором
  • +/
     
  • 4.25, Аноним (7), 22:28, 11/10/2021 Скрыто модератором
  • +/
     
  • 2.9, Аноним (7), 21:27, 11/10/2021 Скрыто модератором
  • +1 +/
     
  • 2.11, QwertyReg (ok), 21:59, 11/10/2021 Скрыто модератором
  • –1 +/
     
     
  • 3.15, Аноним (7), 22:05, 11/10/2021 Скрыто модератором
  • +/
     
  • 2.13, kusb (?), 22:04, 11/10/2021 Скрыто модератором
  • +/
     
     
  • 3.19, Аноним (7), 22:13, 11/10/2021 Скрыто модератором
  • +/
     
     
  • 4.27, Аноним (27), 22:44, 11/10/2021 Скрыто модератором
  • +2 +/
     
     
  • 5.30, Аноним (7), 22:58, 11/10/2021 Скрыто модератором
  • –1 +/
     
     
  • 6.35, erthink (ok), 23:39, 11/10/2021 Скрыто модератором
  • +/
     
     
  • 7.45, kusb (?), 07:45, 12/10/2021 Скрыто модератором
  • +/
     
  • 2.28, Аноним (28), 22:46, 11/10/2021 Скрыто модератором
  • +/
     
     
  • 3.31, Аноним (7), 23:02, 11/10/2021 Скрыто модератором
  • +/
     

     ....ответы скрыты модератором (21)

  • 1.12, Аноним (12), 21:59, 11/10/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +10 +/
    >поддерживаемые энтузиастками

    фото энтузиасток в студию

     
     
  • 2.18, erthink (ok), 22:11, 11/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Ща поищу :)
     

  • 1.21, pashev.me (?), 22:16, 11/10/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > превосходит своего прародителя по надёжности, набору возможностей и производительности

    В наше время за такое сразу в нос. Где пруфы?

     
     
  • 2.24, erthink (ok), 22:26, 11/10/2021 [^] [^^] [^^^] [ответить]  
  • +4 +/
    1. производительность: git clone libmdbx; git clone ioarena; make bench-couple
    https://t.me/libmdbx/2236

    2. надежность: В частности, Erigon перешел с LMDB на MDBX, так как падало...
    https://github.com/ledgerwatch/erigon/wiki/Criteria-for-transitioning-from-Alp

    3. набор возможностей: https://github.com/erthink/libmdbx#improvements-beyond-lmdb

    Но остальное и в следующий раз, пожалуйста, гуглите самостоятельно.

     
     
  • 3.34, pashev.me (?), 23:39, 11/10/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    По первому пункту - только воздух сотрясать:

    Some simple benchmark which I done within /dev/shm on an old laptop with an Intel i7-4600U @ fixed 2GHz.

    $ make bench-mdbx_25000000.txt
    // TIP: Use 'make V=1' for verbose.
      RUNNING ioarena for mdbx/25000000...
    throughput: 124.021Kops/s
    throughput:  13.570Mops/s
    throughput:   1.138Mops/s

    $ make bench-lmdb_25000000.txt
    // TIP: Use 'make V=1' for verbose.
      RUNNING ioarena for lmdb/25000000...
    throughput: 108.858Kops/s
    throughput:  14.758Mops/s
    throughput:   1.211Mops/s

    So, by this benchmark:

    1) libmdbx is ~14% faster than LMDB in CRUD cases.
    Such acceleration should be expected in most use cases (without taking into account the waiting time for disk operations).

    2) libmdbx is ~8% slower than LMDB when iterating records sequentially.
    This is expected, since libmdbx has more checks (for the correctness of arguments and database structure) and in this scenario, these overhead costs become noticeable because the engine performs significantly less other actions.

    However, in most real-world scenarios, a difference will most likely be less noticeable, since most of time will taken the waiting for disk operations.

    По второму: как часто падало? А теперь?

    Пл третьему - вообще субъективно, кому что нужно.

    Итого: профов нет, есть подлог.


    Нас, после рекомендации ВОЗ по маскам, не проведёшь!

     
     
  • 4.36, erthink (ok), 23:42, 11/10/2021 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Всё четко, ясно и понятно.

    А с вашей демагогией - в лес, пожалуйста.

     

  • 1.29, Аноним (29), 22:53, 11/10/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Про ReOpenLdap новостей нет?
     
     
  • 2.33, erthink (ok), 23:35, 11/10/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Про ReOpenLdap новостей нет?

    Нет, и видимо уже не будет.

    Софтверное решение, которое работало с использованием ReOpenLDAP внутри МегаФона, примерно в 2017 было заменено на tarantool (что архитектурно правильно).
    Со своей стороны я поддерживал subj еще три года, но постепенно это потеряло смысл:
    - не было явно заинтересованных пользователей.
    - сам я не пользуюсь ReOpenLDAP и не использую в production, поэтому разработка и тестирование стали сильно отнимать время.
    - для принципиального повышения качества и поддерживаемости его нужно переписать (собственно я всегда это говорил).

    Если кому-то нужен LDAP-сервер с мульти-мастер репликацией, то "стюардессу" можно реанимировать.
    Ну а "родительский" OpenLDAP лучше вообще не использовать, тем более в режиме мульти-мастер репликации.

     
     
  • 3.39, Аноним (29), 00:51, 12/10/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Спасибо.
     
  • 3.43, mos87 (ok), 06:53, 12/10/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ясно.

    Вопрос - если хочется хранить накопляемые данные в иерархическом виде, лучше делать с "нуля" на каком-нибудь тарантуле, редисе и тд (а в скуль перекачивать и использовать только для отчетов)? Или ЛДАП имеющий уже систему прав доступа, апи для язычков, прочий обвес можно/нужно под это приспособить? Как там вообще с созданием собственных схем, а так же их изменением "на лету"?
    Объем (и частота прибытия) данных не столь велИк (не биллинг). Приходят обычно в форме файлов, обычно XMLек (но чем меньше работы с этим чудесным форматом тем лучше, поэтому лучше уж парсить и запихивать).

     
     
  • 4.49, erthink (ok), 08:40, 12/10/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ясно.
    > Вопрос - если хочется хранить накопляемые данные в иерархическом виде, лучше делать
    > с "нуля" на каком-нибудь тарантуле, редисе и тд (а в скуль
    > перекачивать и использовать только для отчетов)? Или ЛДАП имеющий уже систему
    > прав доступа, апи для язычков, прочий обвес можно/нужно под это приспособить?
    > Как там вообще с созданием собственных схем, а так же их
    > изменением "на лету"?
    > Объем (и частота прибытия) данных не столь велИк (не биллинг). Приходят обычно
    > в форме файлов, обычно XMLек (но чем меньше работы с этим
    > чудесным форматом тем лучше, поэтому лучше уж парсить и запихивать).

    Схемы в LDAP достаточно просты - по сути два списка: что может быть и что должно быть.
    Менять их "на лету", если где-то и можно, то только так, чтобы не было конфликтов с уже записанными данными (т.е. примерно только добавлять список необязательных атрибутов).

    Во всех LDAP-ах внутри линейная схема хранения, т.е. для каждого элемента формируется ключ по его пути в иерархии.
    Если вы представляете как эффективно сделать такой маппинг в вашем случае, то вероятно сможете реализовать необходимое поверх любого более-менее приличного key-value (я бы взял libfpta, либо тарантул).

     
     
  • 5.51, mos87 (ok), 09:00, 12/10/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Спасибо.

    SQL СУБД предоставляет определённые привычные возможности, но хочется применять её не как единое монструозное решение для всего (в принципе там и XML хранить можно), а для чего наиболее подходит.

    Но я просто не работал со всеми этими тарантулами, монгами, и редисками (как кстати первый по сравн. с последними?).
    Насколько сложно выстроить свою БД на них, куда бы мы складывали входящие данные, хранили расчётные, а для аналитики и отчетов сливали в SQL?
    С правами доступа и т.д. Почему в сторону LDAP сначала посмотрел, там это уже всё есть (включая формат обмена данными). Даже слишком много всего. Или плюнуть на использование LDAP в таком контексте? SQL конечно гибче в плане прихотей типа "поменять тип столбца, добавить, переименовать"...

     
     
  • 6.59, erthink (ok), 10:13, 12/10/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Redis vs Tarantool - если поискать, то наверное у "редиски" есть что-то отсутствующее в тарантуле.
    Но с учетом всех возможностей тарантула я бы на редиску даже не смотрел.

    Скорее всего ваша задача полностью решается в тарантуле, ибо там есть "винил" и SQL.
    Но если аналитики много, то clickhouse.

    Более-менее гибкие права доступа есть только в SQL.
    В мире NoSQL это не затребовано и (как-правило) реализуется на уровне логики приложения, хотя всегда есть исключения...

    LDAP для другого - это прежде всего справочник пользователей, который редко меняется и много читается.
    Но относительно подходит, так как в принципе это key-value ("путь в иерархии" -> "набор атрибутов").
    Причем чем больше вам подходит key-value, тем больше подходит и LDAP.
    Сам бы я не смотрел на LDAP при наличие тарантула, с одним исключением - для LDAP возможна мульти-мастер синхронизация содержимого (aka репликация) без привязки к линейной истории транзакций, а таратнуле наоборот (репликация примерно как replay транзакций).

    Думаю вам надо пробовать - потратить неделю на тарантул.
    Принципиально более полного ответа вам никто не даст, только вы сами.

     
     
  • 7.64, mos87 (ok), 14:04, 12/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Думаю как раз суперпродвинутые и не нужны будут Хотя я теперь понял что все эти... большой текст свёрнут, показать
     

  • 1.38, Виталий (??), 00:28, 12/10/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А кто может сказать какая область применения ее?
     
  • 1.41, Аноним (1), 02:12, 12/10/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Btrfs все так же теряет данные))) сколько лет прошло
     
     
  • 2.42, Аноним (42), 04:37, 12/10/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Истину глаголишь
     

  • 1.44, Аноним (44), 07:32, 12/10/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    может кто знает? Можно ли использовать для задачи: ключ фиксированного размера, value с multimap но все данные переменной длины? Из доки не понятно, в примере только фиксированный размер..
     
     
  • 2.46, Аноним (44), 07:53, 12/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    и может ли value превышать размер страницы?
     
     
  • 3.47, erthink (ok), 08:22, 12/10/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > и может ли value превышать размер страницы?

    Значения в multimap ограничены по длине примерно половиной страницы (хранятся как ключи во вложенном дереве).

    Точные значения = https://github.com/erthink/libmdbx#limitations

     
     
  • 4.50, Аноним (44), 08:56, 12/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    спасибо, но этого маловато будет, да и вложенных баз вроде 32к только
     
     
  • 5.52, erthink (ok), 09:16, 12/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > спасибо, но этого маловато будет, да и вложенных баз вроде 32к только

    Вложенные b-tree для значений в multimap создаются автоматически и прозрачно для пользователя, когда одному ключу соответствует много значений.
    Кол-во таких вложенных b-tree ограниченно размером БД.

    А 32765 - это вложенные именованные key-value пространства, которые вы явно создаете для размещения данных.
    Использование термина "subdatabase" сюда пришло из BDB, хотя "space" тарантуле подходит больше.

     
     
  • 6.54, Аноним (44), 09:36, 12/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    тоесть получается, если данные порезать на чанки в полстраницы с префиксом: тип данных и номер в серии, В+ будет сортировать их всегда последовательно и все эти данные будут привязаны на один ключ, который будет в единственном числе в индексе? все это будет жить? (не хотелось бы кучу одинаковых ключей, ключи нужно уникальные)
     
     
  • 7.57, erthink (ok), 09:54, 12/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > тоесть получается, если данные порезать на чанки в полстраницы с префиксом: тип
    > данных и номер в серии, В+ будет сортировать их всегда последовательно
    > и все эти данные будут привязаны на один ключ, который будет
    > в единственном числе в индексе? все это будет жить? (не хотелось
    > бы кучу одинаковых ключей, ключи нужно уникальные)

    Да, будет жить.

    И то что ключ будет в одном экземпляре для миллионов значений - является одной из важных фишек для построения вторичных индексов.

    ---

    В LMDB теоретически это тоже должно работать, но практически - длина ключей сильно меньше, а если попробовать изменить #define в коде, то LMDB может тихо потерять данные и/или поломать БД.

    MDBX же либо не примет слишком длинные значения, либо будет работать корректно.
    Но увлекаться ключами (для multimap также и значениями) предельной длины не стоит, ибо эффективность b-tree при этом существенно ниже.

     
     
  • 8.58, Аноним (44), 10:08, 12/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    напрашивается ввести переменную в options, если она отлична от 0, в data дереве ... текст свёрнут, показать
     
     
  • 9.60, erthink (ok), 10:21, 12/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Деградация не из-за сравнений, а из-за роста высоты b-tree и как следствие мно... текст свёрнут, показать
     
  • 9.61, erthink (ok), 10:32, 12/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    А нужно кол-во байт можно сравнивать уже сейчас, задав собственный компаратор ... текст свёрнут, показать
     
     
  • 10.62, Аноним (44), 11:11, 12/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    та не, этот счетчик лишний, не сильно думал Тут баланс надо искать не очевидный... текст свёрнут, показать
     
  • 2.48, erthink (ok), 08:22, 12/10/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > может кто знает? Можно ли использовать для задачи: ключ фиксированного размера, value
    > с multimap но все данные переменной длины? Из доки не понятно,
    > в примере только фиксированный размер..

    Да, так можно.

     

  • 1.74, data man (ok), 10:21, 17/10/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Недавно в Microsoft/FASTER добавили возможность использования liburing.
    Не планируете тоже использовать?
    Или профит невелик?
     
     
  • 2.75, erthink (ok), 14:28, 17/10/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В libmdbx файл БД разшарен в памяти, нет выделенного сервера и есть поддержка WRITEMAP:
    - в режиме MDBX_WRITEMAP очереди не нужны, данные и так не копируются и ядро само пишет их как удобно.
    - без MDBX_WRITEMAP всё равно потребуется копирование в unified page cache, данные которого составляют маппинг файла и могут быть использованы внутри ядра для избавления от лишнего копирования в DMA-буфера.

    Поэтому профит примерно только от сокращения системных вызовов pwritev() при коммите транзакций, и только в режиме без MDBX_WRITEMAP.
    В текущем понимании это не стоит усложнения кода, риска регрессов и затрат времени.

     
     
  • 3.76, data man (ok), 15:07, 17/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо!
    А MithrilDB уже скоро? :)
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:
    При перепечатке указание ссылки на opennet.ru обязательно



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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