Download - MADRID! Query Processing
WWW2009 MADRID!Query Processing
於 WWW 論文読み会（ webkai ）東京大学 岡崎直観（辻井研究室）
最適に整列された文書群に対する転置インデックス圧縮及びクエリ処理
H. Yan, S. Ding, and T. Suel. (NYU & Yahoo! Research)Inverted index compression and query processing with optimized document ordering, WWW2009, pp. 401-410.
転置リスト（ inverted list; posting list ）◦ “ 直観” : [[56, 1, [34]], [198, 2, [14,23]], [1034, 1, [43]]]
d-gap による転置インデックスの圧縮◦ 文書 ID の最割り当て
アイディア : 文書 ID をうまく並べ替えて，転置リスト中の文書 IDを互いに近い値にしたい
うまい方法 : 文書の URL のアルファベット順に文書 ID を再割当 ↑ 「直観」という語は www.chokkan.orgドメインで頻出する
“ 直観” : [[56, 1, [34]], [57, 2, [14,23]], [60, 1, [43]]]◦ 文書 ID の差分（ d-gap）で転置リストを表現
“ 直観” : [[55, 1, [34]], [0, 2, [14,23]], [2, 1, [43]]] d-gap は小さい値を取るので，圧縮しやすくなる
転置インデックスの圧縮
文書 ID 頻度 出現位置
d-gap は 0から始まる
Var-Byte Coding◦ 表現形式 : fddddddd （ f: 連結フラグ ; d: 値）
f が 1 なら後に続く 8bit の数値と連結する◦ 142 = (10001110)b → 10000001 00001110◦ 2 = (10)b → 00000010◦ デコードは速いけど，圧縮率が低い
Rice Coding◦ 表現形式 : 1q0rrrr… （ q 個の 1 の後 0 ，続いて m bit の r ）
q = int(n / 2m), r = n % 2m
m = 4 のとき， 142 → (q = 8, r = 14) → 1111111101110 2 → (q = 0, r = 2) → 00010
Var-Byte Coding よりはデコードが遅いけど，圧縮率が良い
小さい整数の表現方法 (1/3)
Simple9 (S9)◦ 表現形式 : ssssdddd dddddddd dddddddd dddddddd
4 bit のステータスコードで， d の箇所に何個の数字が詰まっているかを表す（以下の９通り） 0000: 28 個の数（ 1bit ）， 0001: 14 個の数（ 2bit ）， 0010: 9 個の数（ 3bit ）， 0011: 7 個の数（ 4bit ）， 0100: 5 個の数（ 5bit ）， 0101: 4 個の数（ 7bit ）， 0110: 3 個の数（ 9bit ）， 0111: ２個の数（ 14bit ）， 1000: 1 個の数（ 28bit ）
◦ (142 2 17) を S9 で表現すると 01100100 01110000 00001000 00100010
◦ ステータスコードの部分をビットマスクで取り出し，テーブルジャンプでデータを読み取れば，高速にデコードできる
◦ S16 という拡張は， 16 通りのデータ表現で圧縮率を向上
小さい整数の表現方法 (2/3)
PForDelta◦ 数値を N 個ずつエンコードする（例えば N = 128 ）
それらの数値の 90% を格納できるビット長 b を決める 2b以上の数値は，例外として別に格納する
◦ (23, 41, 8, 12, 30, 68, 18, 45, 21, 9, …) を格納する 90% 以上が 25 = 32 未満とし， m = 5 と決定 |1 23 3 8 12 30 1 18 2 21 9 …|… 45 68 41|
◦ 高速化のテクニック 異なる b 毎にハードコーディングしておく キャッシュに載るようにブロック毎にデコードする
Interpolative Coding◦ 面白いけど省略
小さい整数の表現方法 (3/3)
先頭の例外位置
これらの数字は 5bit で格納例外は 4 バイトで表
現（逆順に並べる）
PForDelta (PFD) を速度，圧縮率の面で改良する 転置リストに含まれる頻度数値の圧縮方法を提案
◦ move-to-front coding にインスパイアされた 文書 ID を並べ替えることの効果を調べる
◦ TREC GOV2 でインデックスのサイズを 50% 削減 様々な圧縮方法の速度，圧縮率を調べる
◦ 転置リスト毎に圧縮方法を適応的に決める方法を示す
TREC GOV2 とは◦ 2004 年にクロールされた .gov ドメインの 2520 万件の
ウェブページと， 10 万件のクエリ例
本論文の提案
NewPFD◦ 既存の PFD の問題点
オフセットの値が 2b に収まりきらないとき， 2b よりも小さい数を例外扱いにして，オフセットのリストを連結しなければならない
◦ 改善法 例外を格納する配列，例外の位置を示す配列を分離させる (23, 41, 8, 12, 30, 68, 18, 45, 21, 9, …) で m=5 の場合
下位ビット数値配列 : (21 9 8 12 30 4 18 13 21 9 …) 例外オフセット配列 : (1 3 1 …) 上位ビット数値配列 : (9 4 13)
OptPFD◦ デコード速度と圧縮率はトレードオフの関係にある◦ インデックスのサイズとデコード速度の比が最小になるように m
を決める（詳細は省略）
PForDelta の改善法
S16 でエンコードする
NewPFD, OptPFD の性能
単調増加ではないが…◦ 文書 ID を URL 順で整列すれば，似
たような頻度が近くに出現 同じドメインのウェブページの単語頻度
分布は似る 先頭移動法
◦ Move-To-Front (MTF ）◦ Burrows-Wheeler変換（ブロックソート）等と組み合わせて，データ圧縮に用いられる
Most-Likely-Next (MLN)◦ Q 個の数値に対して Q×Q の行列を作り， i行 j列が，数値 iの後に (j+1)番目に出現しやすい数値を格納しておく
◦ jのインデックス番号のみをエンコードする
これらの手法は同一，もしくは似たような頻度の数値が連続するときに有効
頻度数値の圧縮方法
# 値 テーブル 符号0 (1, 2, 3, 4, 5) ()1 5 (5, 1, 2, 3, 4) (5)2 5 (5, 1, 2, 3, 4) (5, 1)3 5 (5, 1, 2, 3, 4) (5, 1, 1)4 3 (3, 5, 1, 2, 4) (5, 1, 1, 4)5 2 (2, 3, 5, 1, 4) (5, 1, 1, 4, 4)6 2 (2, 3, 5, 1, 4) (5, 1, 1, 4, 4, 1)
(5, 5, 5, 3, 2, 2) を MTF 圧縮する例
MTF, MLN の性能
RuralCafe: 農村開発途上地域におけるウェブ検索
J. Chen, L. Subramanian, J. Li.(NYU)RuralCafe: Web Search in the Rural Developing World, WWW2009, pp. 411-420
世界には Web に繋がりづらい地域がたくさんある◦ 100-1000人のユーザーが， 128Kbps の帯域を分け
合っている大学や会社など インドの BPO 部門では， 50-100人のスタッフが 64Kbps
のインターネット回線を共有している◦携帯電話におけるデータ転送よりも SMS のコストが安
いので， SMS ベースで検索をやることがある◦巡回インターネット・キオスク
アジア，アフリカ，ラテンアメリカの農村部において，バスなどで巡回している WiFi インターネット・キオスク
◦停電が頻発する地域もある
背景
2009 年 9月10日◦ BBC News （動画有り）
http://news.bbc.co.uk/2/hi/africa/8248056.stm
◦ ITMedia News http://www.itmedia.co.jp/ne
ws/articles/0909/10/news075.html
伝書鳩◦ 4GB のメモリースティックを装着した生後 11ヶ月のハトが，80km を 1時間8 分で飛ぶ
◦ コンピュータとメモリースティック間のデータを転送する時間を含めても， 2時間6分 57秒だった
◦ その間，通信会社大手のテルコムのデータ転送は， 4% しか完了しなかった
南アの通信会社、データ転送速度で伝書バトに敗北
RuralCafe と呼ばれる検索環境を提案する◦ シンプルな検索インタフェースを提供
従来の検索インタフェースは，断続的なインターネット接続環境に十分とは言えない
◦ ローカルなキャッシュの検索をサポート◦ よく用いられる検索フレーズをローカルに保存
ユーザーのクエリは不十分だったり曖昧であることが多い◦断続的なインターネット接続環境の様々なケースに対応◦検索結果の先読みを行い，ローカルなキャッシュ上で検索できるように準備する
目標
RuralCafe のインタフェース
検索ジョブの進行状況を表示するペーン
「テキストのみ」「テキストと画像」「全部」
曖昧（たくさんの短い検索結果が返される），普通，深い（長めの少ない検索結果が返される）
クエリ拡張やクエリ訂正を行うペーン
通常のクエリ，合成クエリ（ OR連結），エンティティ絞り込み検索（電話番号など）
RuralCafe の構成
N-gram によるクエリ拡張・訂正
ローカル検索 データ転送制御
GPU を用いた高性能なクエリ処理
S. Ding, J. He, H. Yan, T. Suel.(NYU & Yahoo! Research)Using Graphics Processors for High Performance IR Query Processing, WWW2009, pp. 421-430.
情報検索システムは数千のサーバーでクラスター化◦ １サーバーあたりの速度を向上させることも大切
本研究では，以下のタスクにおいて GPU の利用を考える◦ 圧縮された転置リストのデコード◦ 圧縮された転置リストをデコードしながら join を取る
GPU の利用環境◦ NVIDIA GeForce 8800 GTS (640MB; 32 threds)◦ Compute Unified Device Architecture (CUDA)
本研究の内容
Inclusive parallel prefix sum◦ [a0, a1, …, an-1] → [a0, a0+a1, …, a0+a1+…+an-1]
Exclusive parallel prefix sum◦ [a0, a1, …, an-1] → [0, a0, a0+a1, …, a0+a1+…+an-2]
普通に実装すると，並列化が難しい◦ for (i =1;i <= n;++i) s[i] = s[i-1] + a[i-1]◦ n 回の加算演算で O(n)
CUDA による実装は，以下の資料を参照◦ http://developer.download.nvidia.com/compute/cuda
/sdk/website/projects/scan/doc/scan.pdf◦ 2*(n-1) 回の加算， (n-1) 回のコピーで， O(n)
演算回数は増えているが， 32 個のスレッドを使うので高速
並列化計算の例 :Parallel Prefix Sum
Parallel Prefix Sum (up-sweep)
Parallel Prefix Sum(down-sweep)
Rice符号でエンコードされた d-gap 列から文書 ID列を復元◦ Rice符号をデコードしなが
ら Parallel Prefix Sum を取る
文書 ID 列を d-gap 列に変換し Rice符号エンコード◦ 文書 IDs: [143, 146, 164]◦ d-gaps: [142, 2, 17]◦ Rice符号 (m = 4 のとき )
q系列 : 111111110010 r系列 : 111000100001
文書 ID 列のデコード◦ q系列のデコード
まず， q系列を 1-bit で構成された数値列と見なして parallel prefix sumを計算 [1, 2, 3, 4, 5, 6, 7, 8, 8, 8, 9, 9]
元々の q系列で 0 が埋められていた箇所の数字を抜き出して配列に [8, 8, 9]
◦ r系列のデコード 4-bit で構成される数値列と見なして
parallel prefix sum を計算 [14, 16, 17]
◦ 最後にまとめる [8*24+14+1, 8*24+16+2,
9*24+17+3] = [143, 146, 164]
Rice符号列のデコード
通常の rice符号とは異なり， q とr を別々のビットストリームに格納
Rice符号◦ GPU よりも CPU の方が若干高速だった◦ ただし， CPU は d-gap から文書 ID の復元を行っていな
いのに対し， GPU では同時に行っている PForDelta
◦ CPU よりも GPU の方が高速だった
CPU と GPU のデコード速度の比較
基本的なアイディア◦ ２つの転置リストをマージするとき，分割要素を適当に決め
て，転置リストをセグメントに分割する◦ 分割されたセグメント同士でリストのマージを並列に行う
実際には，転置リストを２分割する処理を分割統治で再帰的に行い，セグメントを細分化してマージする
GPU を用いた転置リストマージ
CPU と GPU のクエリ処理時間の比較
スキップポインタを用いた集合和・積 GPU を用いた並列スコア計算
◦ 今回の実験では BM25 を利用している GPU を用いた top-k 文書選択 OR検索のサポート
◦ Term-At-A-Time (TAAT) で文書 ID 毎にスコアを計算 CPU と GPU を上手く組み合わせるスケジューリ
ング
論文でカバーされている他の内容
