IIR 輪講復習#4 Index

construction

お知らせ

たつをさんによる補足情報 http://chalow.net/clsearch.cgi?cat=IIR

復習資料おきば http://bloghackers.net/~naoya/iir/ppt/

参考

http://www-csli.stanford.edu/~hinrich/information-retrieval-book.html

本資料は書籍の輪読会に向けたサマリ 資料内で一部上記ドキュメントからの引用あ

り

4 章のテーマ

インデックス構築に関する実装面の話題 巨大なインデックスをどう構築するか 主にソートの話題 ハードウェアの制限とインデクシングアルゴリズム

の関係

扱う手法 BSBI, SPIMI Distributed Indexing (MapReduce) Dynamic Indexing (logarythmic merging)

検索とハードウェア

検索システムとハードウェア

検索システムの構成はハードウェアの特徴に依存する

ディスクは遅い、大きい メモリは速い、小さい

速度 メモリ : 5 x 10^-9 sec / byte ディスク : 2 x 10^-8 sec / byte

2007 年における典型的な数字

ディスクの読み書き

ヘッドのシーク時間が支配的 ひとつの塊なら 10MB を 0.2 sec 100 個ばらばらなら 10MB に 0.7 sec 隣接させて読み書きしよう

CPU 処理と I/O 処理のオーバーラップ 圧縮して読み書きすると良い時がある

BSBI

インデックス作成時の問題点

インデックス作成 term, docID ペアを集める term を主キー , docID をセカンダリキーと

してソート docID → postings list として組織化 巨大だとメモリだけでは処理できない →

ディスク I/O が発生するため遅い

ディスクを使うなら

外部ソート ソート中のランダムなディスクのシーク

回数を最小化する なるべくシーケンシャルに読む

BSBI

blocked sort-based indexing コレクションを等しいサイズに分割 各断片の termID, docIDs ペアをインメモリ

でソート ( 単語 → termID のマッピングが必要 )

中間のソート結果をディスク上に保存 最後に中間ファイルをマージ

BSBI

BSBI のポイント

メモリブロックでディスク I/O を最適化 ディスクのブロックサイズと同じ ( もしくは

整数倍 ) の固定サイズのメモリブロックに結果を書き出す

メモリブロックが一杯になったらディスクに中間ファイルとして出力

新しいメモリブロックを用意 最後に中間ファイルをマージ

優先度付きキューなどを使うと良い。

BSBI の図

BSBI の複雑度

Θ(T log T) ソート処理に依存 ただし、全体の処理は

PARSENEXTBLOCK と最後のマージ (MERGEBLOCKS) が支配的

SPIMI

BSBI の欠点

単語 → termID マップが必要 巨大なコレクションではこのマップがメ

モリにフィットしない

SPIMI

single-pass in-memory indexing termID は使わない term, docID ペアをストリームで処理 ブロック毎に辞書も書き込む

ディスク容量が許す限りどんなサイズでもインデクシングできる

SPIMI

SPIMI のポイント

BSBI と前処理、後処理は似ている BSBI が termID, docID ペア全体をイン

メモリで扱うのに対し、 SPIMI は term, docID をストリームで

各 postings list のサイズは最初には見積もることができない → 足りなくなったら倍々に増やす

BSBI と SPIMI の違い

SPIMI は a posting を postings list に直接追加する

ソートがないため高速 termID が必要ないのでメモリを節約できる

単一のブロックでの処理比較は SPIMI の方が効率が良い

SPIMI の複雑度

Θ(T) BSBI は Θ(T log T) ソートが要らない ほとんどのオペレーションがコレクションサ

イズに対して線形

Distributed Indexing

分散インデックス

WWW 検索規模などでは、インデクス構築は単一マシンでは時間、サイズともに実現が難しい

計算機クラスタでのインデクス構築 ∴ 分散インデックス

partitioned index

インデックス全体を docID か termID のどちらかを軸に分割する

docID での分割が多いらしい term partitioned index, document partitioned i

ndex

MapReduce

Google の分散インデックス構築システム

計算機クラスタによる並列計算 並列計算をするための分散ハードウェア環境

と、ソフトウェア環境 コモディティなマシンで構成 「 100 ~ 1000 台」 計算途中でノードが壊れても自律的に復旧

Map と Reduce

マスタノードがワーカー群に指示 ワーカーの役割

Map Reduce ワーカーはどちらにでもなり得る

Map

key, value ペアを別の key, value ペアにする

{docID, 文書 }, {docID, 文書 } ... → {term, docID}, {term, docID}, {term, doc} ...

できあがった key, value ペアは中間ファイル”群” (segment files) として保存する ファイル 1 a-f: {apple => 1}, {apple => 2} ... ファイル 2 g-p: {hatena => 1}, {naoya => 2} ... ファイル 3 q-z: {tatuwo => 5}, { unix => 5} ...

Reduce

Map がはき出した sefment files から、同じ key の key, value ペアを集めて所望の出力を作る

{“apple”, 1}, {“apple”, 5}, {“apple”, 6}→ apple => [1, 5, 6] ( すなわち term => postings lis

t)

マスタノード

Map や Reduce を実行するノードを管理

ワーカーは Map にも Reduce にもなれる 与えられた入力を断片に分割、これを空

いているなワーカーに振り分ける Map が中間ファイルをはき出すと、 Red

uce にそれを集めるように指示 中間ファイルはネットワーク I/O を最小化す

るため、 Map ノードのローカルに。

MapReduce

MapReduce ほか

完成した分散インデックスからの検索 フロントエンドから複数の検索サーバーに並行して問い合わせて、結果をマージする

document partitioned index term partitioned index を document partitioned index

に変換するのも MapReduce の役割

MapReduce は汎用的な並列計算クラスタ MapReduce のアーキテクチャに適合する多用な問

題を解くことができる

Dynamic Indexing

Dynamic Indexing

更新があまりないドキュメント群 スクラッチからインデックスを作り直す

更新が多いドキュメント群 スクラッチからビルド ? Dynamic Indexing

補助インデックス + メインインデックス

補助インデックス + メインデックス 補助インデックス

インメモリ、追加可能 検索は両方のインデックスに行い、マージ 削除は Invalidation bit vector + フィ

ルタ 更新 = 削除 + 追加

補助インデックスが追加によって大きくなりすぎたら、メインインデックスへマージ

インデックスのマージ

マージのコスト : インデックスの保存形態に依存

各 postings list 毎にファイル : ○ マージは簡単 × ファイルシステムは大量のファイルを効率的に

扱うことができない postings list を一つのファイルに

× マージが大変 ○ postings list が大量になっても処理できる

Logarithmic merging

マージ T/n 個の posting をマージ → Θ(T^2 /

2) n 補助インデックスのサイズ T postings の合計数

Logarithmic merging アルゴリズム Θ(T^2/n) → log( T log(T/n) )

Logarithmic merging

Logarithmic merging

n 個の postings を扱うインメモリのインデックス Z0

Z0 が一杯 → ディスク上に 2^0 * n 個の I0 次に Z0 が一杯 → 2^1 x n 個の Z1

Z0 + I0 → Z1 Z1

I1 がなければ I1 としてソート I1 があったら Z2 にマージ

... ( 繰り返し )

複数インデックスの欠点

正確な統計情報が単純な探索では分からなくなる ( 検索ヒット数など )

スペル訂正アルゴリズム、 ranked retrieval などに影響

実際の Dynamic Indexing はもっと複雑

大きなサーチエンジンではスクラッチからの再構築が使われることも多い

最近は Dynamic Indexing も ?

まとめ

検索システムの設計は対象のドキュメント群のサイズとハードウェアの性質に依存

メモリとディスクの性能のギャップ

ドキュメントが少い → 力業でシンプルに 多少多くても単一マシンで処理できる程度 → BSBI や

SPIMI が有効

複数サーバーが必要とされるような大規模な問題となるとパラダイムが変わる。 MapReduce 。

別の軸の問題として、インデックスの再構築問題がある 定期的なスクラッチからの再構築 Dynamic Indexing