高性能でコンパクトな組み込みキーバリューデータベースを実装したlibmdbx 0.10.4 (MDBX) ライブラリと、MDBX上にセカンダリインデックスと複合インデックスを備えた表形式のデータ表現を実装した関連ライブラリlibfpta 0.3.9 (FPTA) がリリースされました。両ライブラリは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 Technologiesの専門家が自社製品の内部テスト中に特定したものです。
- テストが改善され、テスト シナリオが拡張され、DB 内のページ ツリーと GC コンテンツの到達可能な非同型状態がすべてチェックされるようになりました。
- C++ API では、余分な「noexcept」が修正され、「cursor::erase()」メソッドにオーバーロードが追加され、バッファの実装でアライメントを確保するために「std::string」を使用する必要がなくなりました (CLANG libstdc++ に関連)。
- 大規模なトランザクションでデータを変更する際に稀に予期しない MDBX_PROBLEM エラーとして現れる、ダーティ ページ パイル アルゴリズム (変更された DB ページの選択的置き換え) の回帰を修正しました。
- データベースが意図的に破損された場合の安定性を確保するために、いくつかのチェックを追加したファズ テストが実行されました。
- 軽微な UndefinedBehaviorSanitizer 警告と Coverity Scan の問題を修正しました。
- ライブラリの古いバージョンによって作成された DB イメージ内のネストされたページで、廃止され使用されなくなった内部フラグ「P_DIRTY」のチェックを修正しました。
- CMake スクリプトでは、LTO (リンク時最適化) に必要なコンパイラ コンポーネントの検索が改善されました。
- 同時読者の最大数が 32767 に増加しました。
- Valgrind と AddressSanitizer を使用する際の作業が高速化されました。
- Windows では、MDBX_NOTLS モード (スレッド ローカル ストレージを使用しない) で作業する場合の SRW ロックの再帰使用が排除され、システム時間の変更の場合のブート ID 生成が修正され、WSL1 および WSL2 の検出が改善され、DrvFS 経由でマウントされた Plan 9 上の DB を開く機能が追加されました。
- 合計 160 を超える変更が 57 のファイルに加えられ、約 5000 行が追加され、約 2500 行が削除されました。
過酷な使用シナリオでのテストにご協力いただいたErigonプロジェクトチーム（Ethereumエコシステム）に感謝申し上げます。libmdbx v0.10.0のリリースから1ヶ月間、Erigonインストール（Ethereumノードの2%で使用）のDBボリュームが7～XNUMXTBであったにもかかわらず、DB破損の報告がわずかXNUMX件しかなかったことは特筆に値します。これらのDB破損はすべてソフトウェアエラーではなく、外部要因によるものでした。XNUMX件はRAM障害、XNUMX件目はBTRFSを使用したストレージサブシステムの特定の構成におけるデータのゼロ化エラーが原因でした。
出所： オープンネット.ru
