Python xapianのストレージ構造

プロジェクト内の検索サービスをサポートするために、バックエンド検索エンジンとして xapian を使用します。これは、その優れたパフォーマンスと使いやすさで人気があります。 以下は、非常にシンプルなコードです。使用するために、私はそのストレージについて常に懸念していました。エンジンに少し興味があったので、最新のストレージ エンジンの実装を調べてみました。以下はデータ ディレクトリ全体の階層です:

/tmp/user_index

flintlock
iamchert
postlist.baseA
postlist.baseB
postlist.DB //すべての Term から docid へのマッピングを保存します
record.baseA
record.baseB
record.DB //すべての docid を対応するデータ マッピングへ保存します
termlist.baseA
termlist.baseB
termlist.DB //すべての docid を対応する用語にマッピングします。

Brass ストレージ エンジンによって使用されるデータ構造は BTree なので、上記の各 *.DB には *.baseA/B が格納されます。対応する .DB のこの大きなデータを含む ファイルのどのデータ ブロックが使用されたか、どの空きビットマップ、バージョン番号などの関連情報が含まれます。xapian では、BTree の各レベルが BTree のレイヤに対応します。そして、このレイヤーのカーソルを維持します。現在アクセスされている特定のデータ ブロックと、データ ブロック内の特定の位置を指すために使用されます。各データ ブロックのデータ構造は次のとおりです。各ブロックをわかりやすく解説 データ要素情報に加えて、各小項目にI（データユニット全体の長さ）、K（データユニットキーの長さ）が含まれる小さなデータユニットです。 + x (キー識別子)) , C (あるキーに対応する値が大きすぎると値が分割されてしまうため、対応するキーがいくつの項目で構成されているかを示します。したがって、C は合計で何点あるかを意味します。前の x は、この単位がどのデータであることを意味します。このキーの大きな値全体を読み取る必要がある場合は、シリアル番号 x に従ってマージできます。)、タグは、先ほど述べたキーに対応する値です。ただし、xapian はそれをタグとして定義します。これはユニバーサル ストレージ構造であるため、この定義は意味があります。たとえば、BTree の非リーフ ノード タグは、関連するデータ ブロックの次の層のアドレスを格納します。これで、ツリー全体のストレージ構造が明確に表示されました。ここで興味深い問題が発生します。それは、特定のホットワードに 100 万個の docid が含まれているとします。増分更新を実行します 場合によっては、この用語から特定の docid を削除したい場合、この docid がどのデータ ブロックに含まれているかをできるだけ早く見つけるにはどうすればよいでしょうか?この問題を解決するために、作者は BTree のキーとして term+docid を使用し、その値はすべてこの docid より大きいサイズに設定されます。これにより、代わりに docid ブロックをできるだけ早く見つけることができます。

xapian は、増分更新のための複数のリーダーとシングルスレッド ライターもサポートしているため、更新によって読み取り操作がブロックされることはありません。現在、作成者は、他のマシンへの増分更新をサポートできるレプリケーション方法を開発中です。これにより、データの信頼性 (単一マシンのディスク損傷によるデータ損失なし) と高可用性 (単一マシンのディスク損傷) を実現できます。レイヤーはバックアップ マシンに切り替えることができます)

ところで、私はこの 2 日間で xapian devel メーリング リストを読みましたが、質問は何も提出していませんでしたが、著者 (Olly Betts) が回答する予定でした。どの質問にも、彼は本当に親切で、丁寧に答えてくれます。