Wydanie wysokowydajnego wbudowanego systemu DBMS libmdbx 0.10.4 i libfpta 0.3.9

Biblioteki libmdbx 0.10.4 (MDBX) zostały wydane wraz z implementacją wysokowydajnej, kompaktowej wbudowanej bazy danych klucz-wartość i powiązanej biblioteki libfpta 0.3.9 (FPTA), która implementuje tabelaryczną reprezentację danych z indeksami wtórnymi i złożonymi na górze MDBX. Obie biblioteki są dystrybuowane na licencjach zatwierdzonych przez OSI. Obsługiwane są wszystkie obecne systemy operacyjne i architektury, a także rosyjski Elbrus 2000.

Historycznie rzecz biorąc, libmdbx jest głęboką przeróbką systemu LMDB DBMS i przewyższa swojego przodka pod względem niezawodności, zestawu funkcji i wydajności. W porównaniu do LMDB, libmdbx kładzie duży nacisk na jakość kodu, stabilność API, testowanie i automatyczne kontrole. Dostarczone jest narzędzie do sprawdzania integralności struktury bazy danych z pewnymi możliwościami odzyskiwania.

Z technologicznego punktu widzenia libmdbx oferuje ACID, serializację silnych zmian i nieblokujący odczyt z liniowym skalowaniem pomiędzy rdzeniami procesora. Obsługiwane jest automatyczne kompaktowanie, automatyczne zarządzanie rozmiarem bazy danych i szacowanie zapytań o zakres. Od 2016 roku projekty finansowane są przez Positive Technologies, a od 2017 roku wykorzystywane są w jej produktach.

libmdbx oferuje interfejs API C++, a także obsługiwane przez entuzjastów powiązania językowe dla Rust, Haskell, Python, NodeJS, Ruby, Go i Nim. W przypadku libfpta tylko opis API jest publicznie dostępny w postaci pliku nagłówkowego C/C++.

Najważniejsze innowacje, ulepszenia i poprawki dodane od czasu poprzedniej wiadomości z 9 maja:

  • Umożliwia powtarzalne kompilacje.
  • Naprawiono błąd, przez który w bardzo rzadkich przypadkach podczas zatwierdzania transakcji mogła wystąpić pętla/zamrożenie. Problem został zidentyfikowany przez specjalistów Positive Tecnologies podczas wewnętrznych testów własnych produktów.
  • Udoskonalono testy i rozszerzono scenariusze testowe, aby sprawdzały wszystkie osiągalne nieizomorficzne stany drzewa stron i zawartości GC wewnątrz bazy danych.
  • W API C++ naprawiono dodatkowy „noexcept”, dodano dodatkowe przeciążenia dla metody „cursor::erase()”, w implementacji buforów oszczędzono stosowania „std::string” w celu zapewnienia wyrównania (dotyczy CLANG libstdc++).
  • Wyeliminowano regresję w algorytmie rozlewania brudnych stron (selektywne wyrzucanie zmienionych stron bazy danych), która objawiała się rzadkim, nieoczekiwanym błędem MDBX_PROBLEM podczas zmiany danych w dużych transakcjach.
  • Przeprowadzono test fazowy z dodatkiem szeregu kontroli zapewniających stabilność w przypadku celowego uszkodzenia bazy danych.
  • Naprawiono drobne ostrzeżenia dotyczące problemów z UnknownBehaviorSanitizer i Coverity Scan.
  • Naprawiono sprawdzanie przestarzałej i nieużywanej już wewnętrznej flagi „P_DIRTY” na zagnieżdżonych stronach wewnątrz obrazów baz danych tworzonych przez starsze wersje biblioteki.
  • W skryptach CMake poprawiono wyszukiwanie komponentów kompilatora wymaganych dla LTO (optymalizacja czasu łącza).
  • Zwiększono maksymalną liczbę jednoczesnych czytelników do 32767.
  • Poprawiona wydajność podczas korzystania z Valgrind i AddressSanitizer.
  • W systemie Windows wyeliminowano rekurencyjne użycie blokady SRW podczas pracy w trybie MDBX_NOTLS (bez korzystania z lokalnej pamięci wątków), naprawiono generowanie bootidu w przypadku zmiany czasu systemowego, poprawiono wykrywanie WSL1 i WSL2 oraz możliwość dodano opcję otwierania bazy danych na Planie 9 zamontowanym przez DrvFS.
  • W sumie wprowadzono ponad 160 zmian w 57 plikach, dodano ~5000 linii, usunięto ~2500.

Chciałbym szczególnie podziękować zespołowi projektowemu Erigon (ekosystem Ethereum) za pomoc w testowaniu w scenariuszach ekstremalnego użytkowania. Znaczące jest, że w ciągu pięciu miesięcy od wydania libmdbx v0.10.0, przy wolumenie bazy danych 1-2 TB w każdej instalacji Erigon (używanej na 7% węzłów Ethereum), otrzymano tylko trzy raporty o uszkodzeniu bazy danych, wszystkie które wystąpiły z przyczyn zewnętrznych, a nie błędów oprogramowania: w dwóch przypadkach przyczyną były awarie pamięci RAM, w trzecim błąd resetowania danych w określonej konfiguracji podsystemu pamięci masowej za pomocą BTRFS.

Źródło: opennet.ru

Dodaj komentarz