Издаване на високопроизводителна вградена СУБД libmdbx 0.10.4 и libfpta 0.3.9

Библиотеките libmdbx 0.10.4 (MDBX) бяха пуснати с внедряването на високопроизводителна компактна вградена база данни с ключ-стойност и свързаната библиотека libfpta 0.3.9 (FPTA), която реализира таблично представяне на данни с вторични и съставни индекси върху MDBX. И двете библиотеки се разпространяват под одобрени от OSI лицензи. Поддържат се всички актуални операционни системи и архитектури, както и руската Elbrus 2000.

Исторически libmdbx е дълбока преработка на LMDB DBMS и превъзхожда своя предшественик по надеждност, набор от функции и производителност. В сравнение с LMDB, libmdbx поставя голям акцент върху качеството на кода, стабилността на API, тестването и автоматизираните проверки. Доставя се помощна програма за проверка на целостта на структурата на базата данни с някои възможности за възстановяване.

Технологично, libmdbx предлага ACID, силна сериализация на промените и неблокиращи четения с линейно мащабиране в ядрата на процесора. Поддържат се автоматично уплътняване, автоматично управление на размера на базата данни и оценка на заявката за диапазон. От 2016 г. проекти се финансират от Positive Technologies и от 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.
  • Коригирана проверка на остарелия и вече неизползван вътрешен флаг „P_DIRTY“ във вложени страници в изображения на база данни, създадени от по-стари версии на библиотеката.
  • В скриптовете CMake търсенето на компоненти на компилатора, необходими за LTO (оптимизиране на времето за връзка), е подобрено.
  • Максималният брой едновременни читатели е увеличен до 32767.
  • Подобрена производителност при използване на Valgrind и AddressSanitizer.
  • В Windows рекурсивното използване на SRW-lock при работа в режим MDBX_NOTLS (без използване на локално хранилище на нишка) е елиминирано, генерирането на bootid е коригирано, ако системното време се е променило, откриването на WSL1 и WSL2 е подобрено и възможността за Добавено е отваряне на база данни на Plan 9, монтирана чрез DrvFS.
  • Общо бяха направени повече от 160 промени в 57 файла, ~5000 реда бяха добавени, ~2500 бяха изтрити.

Бих искал специално да благодаря на екипа на проекта Erigon (екосистема на Ethereum) за тяхната помощ при тестване в сценарии на екстремна употреба. Показателно е, че за пет месеца от пускането на libmdbx v0.10.0, с обем на базата данни от 1-2 TB във всяка инсталация на Erigon (използвана на 7% от възлите на Ethereum), бяха получени само три доклада за повреда на базата данни, всички което е възникнало поради външни причини, а не софтуерни грешки: в два случая причината е повреди в RAM, в третия грешка при нулиране на данни в специфична конфигурация на подсистемата за съхранение с помощта на BTRFS.

Източник: opennet.ru

Добавяне на нов коментар