ついにメジャーアップデート！爆速KVS「LMDB 1.0」が正式リリース

超高速かつ信頼性の高いキーバリューストアとして知られる「Lightning Memory-Mapped Database Manager (LMDB)」が、待望のバージョン1.0に到達しました。メモリマップドファイルの特性を最大限に活かしたこのライブラリは、高い並列処理性能とACID特性を両立しており、データベースエンジニアにとって見逃せないマイルストーンとなります。

LMDB 1.0の新機能は以下の通り:

• 増分バックアップのサポート
• ページレベルのチェックサムと暗号化のサポート
• Rawブロックデバイス上のDBサポート
• 2相コミットのサポート
• 最大64KBまでのページサイズサポート

それに加えて、APIへのその他の細かい追加機能もあるね。

HTTPだって？勘弁してくれよ

LMDBを実際に使ってみて、信頼性に関していい経験してる人っている？本番環境では使ったことないんだけど、データベース実装の授業のためにコードと設計ドキュメントは一通り読んだんだ。

奇妙なコード（「呼び出し側が戻り値にアクセスする前に4k以上のスタック領域を使わない限り機能する」といったコメントと共に、戻り値をスタックの4k上にプッシュするとか）があったのを覚えてるし、作者が未定義動作（Undefined Behavior）についてかなり型破りな見解（「コンパイラは決定的だ。コンパイル先のプラットフォームを知っていれば、未定義な動作なんて存在しない。もしコンパイラの作者たちがそう思わないなら、彼らはバカだ」といったもの）を共有していたのも記憶してる。

まあ、徹底的にテストされてるんだろうから、実際には問題にならないのかな？実際に使っている人の意見をぜひ聞きたい。自分は今のところSQLiteばかり使ってるんだ。

この部分は書き直したほうがいいかもね。「デフォルトで読み取り専用なのは、破損に対して完全な免疫を提供するからです。読み書きモードを使うと書き込みパフォーマンスは大幅に向上しますが、ポインタを介した意図しないアプリケーションからの書き込みによってデータベースが密かに破損するリスクが増えます。」

読み書きモードのほうが読み取り専用よりも書き込みパフォーマンスが高いってのは、一般的にそう思うよ :)

一部の人がmmapを過剰に評価する理由が理解できないんだよね。メモリマップドファイルIOなんて、RAMキャッシュに隠れたシステムコール（ページフォールト）を組み合わせただけのものだろ。O_DIRECTを使って通常の匿名メモリを埋めることで同じことが自分でできる。もし共有したければ、マッピング済みの共有memfdを埋めることもできるしね。

memfdはシール（seal）することもできるから、「読み取り専用」モードの実装なんて簡単だよ。memfdを書き込み用でマップして、F_SEAL_FUTURE_WRITEを適用して、読み取り専用にしたい相手にそのmemfdを共有すればいいだけ。

カーネルのデフォルト設定に頼らず自分でO_DIRECT IOを行えば、より細かく制御できる。先読み（readahead）の量や、リードクラスタのサイズ、キャッシュの追い出し戦略、いつ書き戻すかさえも自分で決められるんだから。

ちなみに、O_DIRECTはaioやio_uringを使って非同期で行うこともできる。非同期のページフォールトなんて存在しないしね。それにIOエラーについてはどうする？EIOとSIGBUS、どっちに対処したい？

なぜカーネルにそんなことを任せたいのか。カーネルは自分よりも情報を持っていないし、汎用的なヒューリスティックに頼るしかないから、結果として自分でやるより悪い仕事しかできないはずだよ。

それに、速度だって変わらない。O_DIRECTはDMAだし、ページキャッシュの読み込みだってDMAだ。同じ操作を別の方法でやってるに過ぎないんだよ。

https://www.meilisearch.com/docs/resources/internals/storage

まいったな。俺がPythonバインディングのメンテナーなんだよ。

さて、どうやって両方のバージョンをサポートするか考えないといけないな……