Download - IIR 輪講復習 #4 Index construction
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