A nagy teljesítményű beágyazott DBMS libmdbx 0.10.4 és libfpta 0.3.9 kiadása

A libmdbx 0.10.4 (MDBX) könyvtárat egy nagy teljesítményű kompakt beágyazott kulcsérték-adatbázis megvalósításával adták ki, valamint a hozzá tartozó libfpta 0.3.9 (FPTA) könyvtárat, amely az adatok táblázatos megjelenítését valósítja meg másodlagos és összetett indexekkel. az MDBX tetején. Mindkét könyvtár az OSI által jóváhagyott licencekkel kerül terjesztésre. Minden jelenlegi operációs rendszer és architektúra támogatott, valamint az orosz Elbrus 2000.

Történelmileg a libmdbx az LMDB DBMS mélyreható átdolgozása, és megbízhatóságban, szolgáltatáskészletben és teljesítményben felülmúlja elődjét. Az LMDB-hez képest a libmdbx nagy hangsúlyt fektet a kódminőségre, az API stabilitására, a tesztelésre és az automatizált ellenőrzésekre. Az adatbázis-struktúra sértetlenségének ellenőrzésére szolgáló segédprogram, néhány helyreállítási lehetőséggel is rendelkezésre áll.

Technológiai szempontból a libmdbx ACID-ot, erős változás-sorosítást és nem blokkoló olvasást kínál lineáris skálázással a processzormagok között. Az automatikus tömörítés, az automatikus adatbázisméret-kezelés és a tartománylekérdezések becslése támogatott. 2016 óta a projekteket a Positive Technologies finanszírozza, és 2017 óta használják termékeiben.

A libmdbx C++ API-t, valamint rajongók által támogatott nyelvi kötéseket kínál a Rust, Haskell, Python, NodeJS, Ruby, Go és Nim számára. A libfpta esetében csak az API leírása érhető el nyilvánosan C/C++ fejlécfájl formájában.

Főbb újítások, fejlesztések és javítások az előző, május 9-i hír óta:

  • Lehetővé teszi a reprodukálható buildeket.
  • Javítottunk egy hibát, amely miatt nagyon ritka esetekben hurok/lefagyás fordulhat elő a tranzakció véglegesítése során. A problémát a Positive Tecnologies szakemberei saját termékeik belső tesztelése során azonosították.
  • A teszteket továbbfejlesztették, és a tesztforgatókönyveket kibővítették az oldalfa és az adatbázison belüli GC-tartalom összes elérhető nem izomorf állapotának ellenőrzésére.
  • A C++ API-ban egy extra “noexcept”-et javítottak, a “cursor::erase()” metódushoz további túlterhelések kerültek hozzáadásra, a pufferek megvalósítása megkímélte az “std::string” használatát az igazítás érdekében. (releváns a CLANG libstdc++ esetén).
  • Kiküszöböltük a szennyezett oldalak kiszóródási algoritmusának regresszióját (a megváltozott adatbázis-oldalak szelektív kidobása), amely egy ritka, váratlan MDBX_PROBLEM hibában nyilvánult meg, amikor hatalmas tranzakciók során adatokat változtattak.
  • Fázisos tesztet hajtottak végre számos ellenőrzés hozzáadásával, hogy biztosítsák a stabilitást az adatbázis szándékos megrongálása esetén.
  • Kijavítottuk az UndefinedBehaviorSanitizer és a Coverity Scan problémákat.
  • Javítva az elavult és már nem használt belső „P_DIRTY” jelző ellenőrzése a könyvtár régebbi verziói által létrehozott adatbázis-képek beágyazott oldalain.
  • A CMake szkriptekben az LTO-hoz (link-time optimization) szükséges fordítókomponensek keresése javult.
  • Az egyidejű olvasók maximális számát 32767-re emelték.
  • Jobb teljesítmény a Valgrind és az AddressSanitizer használatakor.
  • Windows rendszeren megszűnt az SRW-zár rekurzív használata MDBX_NOTLS módban (szál helyi tárhely használata nélkül) végzett munka során, a rendszerindítási azonosító generálás javításra került, ha a rendszeridő megváltozott, a WSL1 és WSL2 észlelése javult, és a Nyisson meg egy adatbázist a DrvFS-en keresztül csatlakoztatott Plan 9-en.
  • Összesen 160 fájlon több mint 57 módosítás történt, ~5000 sor került hozzáadásra, ~2500 törölve.

Külön szeretném megköszönni az Erigon projektcsapatnak (Ethereum ökoszisztéma) az extrém felhasználási forgatókönyvek tesztelésében nyújtott segítségét. Lényeges, hogy a libmdbx v0.10.0 kiadása óta eltelt öt hónap alatt, minden Erigon telepítésben 1-2 TB adatbázis-térfogattal (az Ethereum csomópontok 7%-án használták), mindössze három jelentés érkezett adatbázis-sérülésről. amely külső okok miatt következett be, és nem szoftverhiba: két esetben a RAM meghibásodása volt az ok, a harmadik esetben a tároló alrendszer egy adott konfigurációjában, a BTRFS segítségével történt adatok visszaállítása során.

Forrás: opennet.ru

Hozzászólás