De libmdbx 0.10.4 (MDBX) -bibliotheken zijn uitgebracht met de implementatie van een krachtige, compacte, ingebedde sleutel-waardedatabase, en de bijbehorende libfpta 0.3.9 (FPTA) -bibliotheek, die een tabelweergave van gegevens implementeert met secundaire en samengestelde indexen bovenop MDBX. Beide bibliotheken worden gedistribueerd onder door OSI goedgekeurde licenties. Alle huidige besturingssystemen en architecturen worden ondersteund, evenals het Russische Elbrus 2000.
Historisch gezien is limbdbx een diepgaande herwerking van het LMDB DBMS en is het superieur aan zijn voorloper wat betreft betrouwbaarheid, functieset en prestaties. Vergeleken met LMDB legt licmdbx veel nadruk op codekwaliteit, API-stabiliteit, testen en geautomatiseerde controles. Er wordt een hulpprogramma meegeleverd voor het controleren van de integriteit van de databasestructuur met enkele herstelmogelijkheden.
Technologisch gezien biedt limbdbx ACID, sterke serialisatie van wijzigingen en niet-blokkerende leesbewerkingen met lineaire schaling over CPU-kernen. Automatische compactificatie, automatisch beheer van de databasegrootte en schatting van bereikquery's worden ondersteund. Sinds 2016 worden projecten gefinancierd door Positive Technologies en sinds 2017 gebruikt in haar producten.
libmdbx biedt een C++ API, evenals door liefhebbers ondersteunde taalbindingen voor Rust, Haskell, Python, NodeJS, Ruby, Go en Nim. Voor libfpta is alleen de API-beschrijving openbaar beschikbaar in de vorm van een C/C++ headerbestand.
Belangrijke innovaties, verbeteringen en correcties toegevoegd sinds het vorige nieuws op 9 mei:
- Maakt reproduceerbare builds mogelijk.
- Een bug opgelost waardoor, in zeer zeldzame omstandigheden, een lus/bevriezing kon optreden tijdens een transactievastlegging. Het probleem werd door specialisten van Positive Tecnologies vastgesteld tijdens interne tests van hun eigen producten.
- Tests zijn verbeterd en testscenario's zijn uitgebreid om alle bereikbare niet-isomorfe toestanden van de paginaboom en GC-inhoud in de database te controleren.
- In de C++ API is een extra “noexcept” opgelost, er zijn extra overbelastingen toegevoegd voor de “cursor::erase()” methode, de implementatie van buffers is het gebruik van “std::string” bespaard om uitlijning te garanderen (relevant voor CLANG libstdc++).
- Een regressie in het dirty page spilling-algoritme (selectief uitwerpen van gewijzigde databasepagina's), dat zich manifesteerde door een zeldzame onverwachte fout MDBX_PROBLEM bij het wijzigen van gegevens in grote transacties, is geëlimineerd.
- Er is een faseringstest uitgevoerd met toevoeging van een aantal controles om de stabiliteit te garanderen bij opzettelijke beschadiging van de database.
- Kleine waarschuwingen voor problemen met UndefinieerBehaviorSanitizer en Coverity Scan opgelost.
- Een probleem opgelost waarbij de verouderde en niet langer gebruikte interne vlag “P_DIRTY” werd gecontroleerd op geneste pagina's in database-afbeeldingen gemaakt door oudere versies van de bibliotheek.
- In CMake-scripts is het zoeken naar compilercomponenten die nodig zijn voor LTO (link-time-optimalisatie) verbeterd.
- Het maximale aantal gelijktijdige lezers is verhoogd naar 32767.
- Verbeterde prestaties bij gebruik van Valgrind en AddressSanitizer.
- Op Windows is het recursieve gebruik van SRW-lock bij het werken in de MDBX_NOTLS-modus (zonder gebruik van lokale threadopslag) geëlimineerd, het genereren van een bootid is opgelost als de systeemtijd is gewijzigd, de WSL1- en WSL2-detectie is verbeterd en de mogelijkheid om een database openen op Plan 9, gekoppeld via DrvFS, is toegevoegd.
- In totaal zijn er meer dan 160 wijzigingen aangebracht in 57 bestanden, zijn er ongeveer 5000 regels toegevoegd en zijn er ongeveer 2500 verwijderd.
Ik wil vooral het Erigon-projectteam (Ethereum-ecosysteem) bedanken voor hun hulp bij het testen in extreme gebruiksscenario's. Het is veelbetekenend dat er in vijf maanden sinds de release van libmdbx v0.10.0, met een databasevolume van 1-2 TB in elke Erigon-installatie (gebruikt op 7% van de Ethereum-nodes), slechts drie meldingen van databasecorruptie zijn ontvangen, allemaal die plaatsvond vanwege externe redenen, en niet vanwege softwarefouten: in twee gevallen was de oorzaak RAM-storingen, in het derde geval een fout bij het resetten van gegevens in een specifieke configuratie van het opslagsubsysteem met behulp van BTRFS.
Bron: opennet.ru