È stata rilasciata la libreria libmdbx 0.10.4 (MDBX) con l'implementazione di un database embedded compatto e ad alte prestazioni di tipo chiave-valore, e la libreria correlata libfpta 0.3.9 (FPTA), che realizza una rappresentazione tabellare dei dati su MDBX con indici secondari e compositi. Entrambe le librerie sono distribuite con licenze approvate da OSI. Sono supportati tutti i sistemi operativi e architetture attuali, così come l'Elbrus 2000 russo.
Storicamente, libmdbx è un rifacimento profondo del DBMS LMDB e supera il suo predecessore in termini di affidabilità, funzionalità e prestazioni. Rispetto a LMDB, libmdbx presta grande attenzione alla qualità del codice, stabilità dell'API, test e verifiche automatiche. Viene fornuto uno strumento per il controllo dell'integrità della struttura del DB con alcune capacità di ripristino.
Tecnologicamente, libmdbx offre ACID, una rigorosa serializzazione delle modifiche e lettura non bloccante con scalabilità lineare su core CPU. Supporta la compattazione automatica, la gestione automatica della dimensione del DB, la stima del volume delle query per intervallo (range query estimation). Dall'anno 2016, i progetti sono finanziati 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 è pubblicamente disponibile solo una descrizione dell'API sotto forma di file di intestazione C/C++.
Le principali novità, miglioramenti e correzioni aggiunte dopo l'ultima notizia del 9 maggio:
- È stata garantita la possibilità di build riproducibili.
- È stato corretto un errore che, in circostanze molto rare, durante il commit di una transazione poteva causare un ciclo infinito/impasse. Il problema è stato individuato dagli specialisti di Positive Technologies durante i test interni dei propri prodotti.
- Sono stati migliorati i test e ampliati gli scenari di test per verificare tutti gli stati non isomorfici raggiungibili dell'albero delle pagine e del contenuto di GC all'interno del DB.
- Nell'API C++ è stato corretto un eccessivo «noexcept», sono state aggiunte ulteriori 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 regresso nell'algoritmo di spilling delle pagine sporche (sostituzione selettiva delle pagine modificate del DB) che si manifestava con un raro errore imprevisto MDBX_PROBLEM durante la modifica dei dati in enormi transazioni.
- Eseguita una verifica tramite phased con l'aggiunta di diversi controlli per garantire la stabilità in caso di danneggiamento intenzionale del DB.
- Risolti avvisi minori da UndefinedBehaviorSanitizer e problemi di Coverity Scan.
- Corretta la verifica del flag interno obsoleto e già non utilizzato «P_DIRTY» nelle pagine nidificate all'interno delle immagini DB create da vecchie versioni della libreria.
- Modificato il supporto nella ricerca dei componenti del compilatore necessari per LTO (ottimizzazione al momento del link) negli script CMake.
- Il numero massimo di lettori simultanei è stato aumentato a 32767.
- Accelerata l'operatività con Valgrind e AddressSanitizer.
- Su Windows risolto l'uso ricorsivo del SRW-lock quando operante in modalità MDBX_NOTLS (senza utilizzo di thread local storage), corretta la generazione del bootid in caso di modifica dell'orario di sistema, migliorato il rilevamento di WSL1 e WSL2, aggiunta la possibilità di aprire un DB su Plan 9 montato tramite DrvFS.
- In totale sono state apportate oltre 160 modifiche in 57 file, aggiunte ~5000 righe, rimosse ~2500.
Un ringraziamento particolare va al team del progetto Erigon (ecosistema Ethereum) per il supporto nel testing in scenari d'uso estremi. È significativo che, nei cinque mesi dalla pubblicazione di libmdbx v0.10.0, con DB di 1-2 TB in ciascuna installazione di Erigon (utilizzato nel 7% dei nodi Ethereum), sono stati ricevuti solo tre segnalazioni di danneggiamento del DB, tutte causate da fattori esterni e non da errori software: in due casi la causa è stata un guasto della RAM, nel terzo un errore di azzeramento dei dati in una specifica configurazione del sottosistema di archiviazione con l'uso di BTRFS.
Fonte: opennet.ru
