libmdbx 0.10.4 (MDBX) ライブラリは、高性能でコンパクトな組み込みキー/値データベースと、セカンダリ インデックスと複合インデックスを使用したデータの表形式表現を実装する関連する libfpta 0.3.9 (FPTA) ライブラリの実装とともにリリースされました。 MDBX の上にあります。どちらのライブラリも OSI 承認のライセンスに基づいて配布されます。現在のすべてのオペレーティング システムとアーキテクチャ、およびロシアの Elbrus 2000 がサポートされています。
歴史的に、libmdbx は LMDB DBMS を徹底的に作り直したもので、信頼性、機能セット、パフォーマンスの点で先祖を上回っています。 LMDB と比較して、libmdbx はコードの品質、API の安定性、テスト、自動チェックに重点を置いています。いくつかの回復機能を備えたデータベース構造の整合性をチェックするためのユーティリティが提供されています。
テクノロジー的には、libmdbx は、ACID、強力な変更シリアル化、および CPU コア全体の線形スケーリングによるノンブロッキング読み取りを提供します。自動圧縮、自動データベース サイズ管理、範囲クエリ推定がサポートされています。 2016 年以来、プロジェクトは Positive Technologies から資金提供を受けており、2017 年からはその製品に使用されています。
libmdbx は、C++ API に加えて、愛好家がサポートする Rust、Haskell、Python、NodeJS、Ruby、Go、Nim の言語バインディングを提供します。 libfpta の場合、API の説明のみが C/C++ ヘッダー ファイルの形式で公開されています。
9 月 XNUMX 日の前回のニュース以降に追加された主な革新、改善、修正:
- 再現可能なビルドを可能にします。
- 非常にまれな状況で、トランザクションのコミット中にループ/フリーズが発生する可能性があるバグを修正しました。この問題は、Positive Tecnologies の専門家が自社製品の内部テスト中に特定しました。
- テストが改善され、データベース内のページ ツリーと GC コンテンツの到達可能な非同型状態をすべてチェックするようにテスト シナリオが拡張されました。
- C++ API では、余分な「noexc」が修正され、「cursor::erase()」メソッドに追加のオーバーロードが追加され、バッファの実装では位置合わせを確実にするために「std::string」の使用が省略されました。 (CLANG libstdc++ に関連)。
- 大規模なトランザクションでデータを変更する際にまれに発生する予期しないエラー MDBX_PROBLEM によって明らかとなった、ダーティ ページ スピル アルゴリズム (変更されたデータベース ページの選択的排出) の回帰は解消されました。
- データベースに意図的な損傷が発生した場合の安定性を確保するために、いくつかのチェックを追加してフェーズ テストが実行されました。
- 軽度の警告である UnknownBehaviorSanitizer および Coverity Scan の問題を修正しました。
- 古いバージョンのライブラリで作成されたデータベース イメージ内のネストされたページで、古くなって使用されなくなった内部フラグ「P_DIRTY」をチェックする問題を修正しました。
- CMake スクリプトでは、LTO (リンク時最適化) に必要なコンパイラー コンポーネントの検索が改善されました。
- 同時リーダーの最大数が 32767 に増加しました。
- Valgrind と AddressSanitizer を使用するときのパフォーマンスが向上しました。
- Windows では、MDBX_NOTLS モード (スレッド ローカル ストレージを使用しない) で動作するときの SRW ロックの再帰的使用が排除され、システム時刻が変更された場合の bootid 生成が修正され、WSL1 および WSL2 の検出が改善され、 DrvFS 経由でマウントされた Plan 9 でデータベースを開く機能が追加されました。
- 合計 160 を超える変更が 57 のファイルに加えられ、約 5000 行が追加され、約 2500 行が削除されました。
特に、極端な使用シナリオでのテストを支援してくれた Erigon プロジェクト チーム (イーサリアム エコシステム) に感謝したいと思います。各 Erigon インストール (Ethereum ノードの 0.10.0% で使用) でデータベース ボリュームが 1 ～ 2 TB の libmdbx v7 のリリースから XNUMX か月間で、データベース破損の報告が XNUMX 件しか受け取られなかったことは重要です。そのうち XNUMX 件はソフトウェア エラーではなく外部の理由で発生しました。XNUMX 件の原因は RAM の障害で、XNUMX 件目は BTRFS を使用したストレージ サブシステムの特定の構成でのデータのリセット時のエラーでした。
出所： オープンネット.ru