È stata rilasciata la libreria libmdbx 0.10.4 (MDBX) con l'implementazione di un database embedded compatto ad alte prestazioni di tipo chiave-valore, e la libreria correlata libfpta 0.3.9 (FPTA), che implementa una rappresentazione tabellare dei dati con indici secondari e compositi sopra MDBX. Entrambe le librerie sono distribuite con licenze approvate dall'OSI. Sono supportati tutti i sistemi operativi e architetture attuali, inclusi gli Elbrus 2000 russi.
Storicamente, libmdbx è una profonda rivisitazione del DBMS LMDB e supera il suo predecessore in termini di affidabilità, funzionalità e prestazioni. Rispetto a LMDB, libmdbx pone grande attenzione alla qualità del codice, al funzionamento stabile dell'API, ai test e alle verifiche automatiche. È fornuto uno strumento per il controllo dell'integrità della struttura del database con alcune possibilità di recupero.
Tecnologicamente, libmdbx offre ACID, una stretta serializzazione delle modifiche e una lettura non bloccante con scalabilità lineare sui core della CPU. Supporta l'autocompattazione, la gestione automatica delle dimensioni del DB e la stima dei volumi di query per intervallo (range query estimation). Dal 2016, il progetto è finanziato da Positive Technologies e dal 2017 viene utilizzato nei suoi prodotti.
Per libmdbx è disponibile un'API C++, oltre a binding supportati da appassionati per i linguaggi Rust, Haskell, Python, NodeJS, Ruby, Go, Nim. Per libfpta è disponibile solo una descrizione pubblica dell'API sotto forma di file di intestazione C/C++.
Principali novità, aggiornamenti e correzioni aggiunti dopo l'ultima notizia del 9 maggio:
- È stata garantita la possibilità di build riproducibili.
- È stato risolto un bug che in circostanze molto rare poteva causare un ciclo infinito/blocco durante il commit delle transazioni. Il problema è stato identificato dagli specialisti di Positive Technologies durante i test interni sui propri prodotti.
- Sono stati perfezionati i test e ampliati gli scenari di test per verificare tutti gli stati non isomorfi raggiungibili dell'albero delle pagine e del contenuto GC all'interno del DB.
- Nell'API C++ è stato corretto un eccessivo "noexcept", aggiunte le sovraccariche per il metodo "cursor::erase()", e l'implementazione dei buffer è stata liberata dall'uso di "std::string" per garantire l'allineamento (rilevante per CLANG libstdc++).
- Risolto il regressione nell'algoritmo di spooling delle pagine sporche (sostituzione selettiva delle pagine modificate del DB), che si manifestava con un raro errore inatteso MDBX_PROBLEM durante la modifica dei dati in enormi transazioni.
- Eseguita una verifica di fase con l'aggiunta di una serie di controlli per garantire stabilità in caso di danneggiamento volontario del DB.
- Eliminate segnalazioni minori di UndefinedBehaviorSanitizer e problemi di Coverity Scan.
- Corretta la verifica di un flag interno obsoleto e non più utilizzato "P_DIRTY" all'interno delle pagine incorporate nei dati DB creati con versioni obsolete della libreria.
- Nei script CMake è stato migliorato il rilevamento dei componenti del compilatore necessari per LTO (ottimizzazione del tempo di collegamento).
- Il numero massimo di lettori simultanei è stato aumentato a 32767.
- Accelerata l'operatività con Valgrind e AddressSanitizer.
- In Windows, recursive use of SRW-lock has been eliminated when operating in MDBX_NOTLS mode (without using thread local storage), bootid generation has been fixed in case of system time changes, WSL1 and WSL2 detection has been improved, and the ability to open databases on Plan 9 mounted via DrvFS has been added.
- A total of more than 160 changes have been made in 57 files, with approximately 5000 lines added and 2500 lines removed.
I would like to especially thank the Erigon project team (Ethereum ecosystem) for their assistance in testing under extreme usage scenarios. Notably, in the five months since the release of libmdbx v0.10.0, with a database size of 1-2 TB in each Erigon installation (used in 7% of Ethereum nodes), there have been only three reports of database corruption, all of which were due to external reasons rather than software errors: in two cases, the cause was RAM failures, and in the third, a data reset error in a specific storage subsystem configuration using BTRFS.
Fonte: opennet.ru
