2009年4月8日開催のセミナー「Extreme Search! 次世代検索エンジンSedue 24が実現する驚異のパフォーマンス」における、セッション「SSD向け全文検索エンジン」の配布資料。

1. SSD向け全文検索エンジン
(株)プリファードインフラストラクチャー
研究開発部門
田中 英行
1

2. 概要
SSDとは
SSDの特徴
アルゴリズム概要
他の手法との比較
検索詳細
インデックス構築詳細
2

3. SSD(Solid State Drive)とは
NANDフラッシュを用いた記憶装置
SATAインターフェースなどを持ち、
HDDと同様に扱える
近年大容量化と高速化が
著しい
3

4. SSDの特徴
高速
HDDと異なり、ヘッドの移動がないので、
アクセスタイムが非常に小さい
シーケンシャルアクセスもHDDより高速
寿命
NANDフラッシュは、データの書き換えでメモリセルが
劣化し、データが書き込めなくなる
特定のブロックに書き込み回数が集中しないように、
ウェアレベリング(後述)によって均一化される
4

5. HDD vs SSD
HDD SSD
容量 ～2TB ～256GB
価格 ¥6/GB ¥200/GB
読み込み(逐次) 50～100MB/sec 100～200MB/sec
書き込み(逐次) 50～100MB/sec 100～200MB/sec
100μs～
レイテンシ* 10ms ～
* リクエストを出してからデータが得られるまでの時間
5

6. ウェアレベリング
書き換え回数を均一化する技術
予期せぬ書き込み性能の低下を招くことも
更新頻度の低いデータを移動させて均一化する
6

7. SSDに適しているアルゴリズム
ランダムアクセスが多いが総アクセス量が
少ない
ランダムアクセスは許容される
書き込みと読み込みの回数に非対称性が
ある(読み込みが多い)
寿命・ウェアレベリングのため
CPUの計算量が少ない
ディスクが速くなるとCPUがボトルネックになるため
7

8. Suffix Array (SA, 接尾辞配列)
文字列に対して、全てのSuffix（接尾辞）
をソートしたもの
0 abracadabra$ 11 $
1 bracadabra$ 10 a$
2 racadabra$ 7 abra$
3 acadabra$ 0 abracadabra$
4 cadabra$ 3 acadabra$
abracadabra$
5 adabra$ 5 adabra$
6 dabra$ 8 bra$
7 abra$ 1 bracadabra$
8 bra$ 4 cadabra$
9 ra$ 6 dabra$
10 a$ 9 ra$
11 $ 2 racadabra$
8

9. SAを用いた検索
検索の流れ
検索
ヒット
ヒット
クエリ 結果
文書
位置
スコアリング・
ソート
9

10. SAを用いた検索
検索したい文字列で二分探索
上限と下限二回
ヒット位置が分かる
11 $
10 a$
7 abra$
0 abracadabra$
3 acadabra$
abraを検索 5 adabra$
8 bra$
1 bracadabra$
4 cadabra$
6 dabra$
9 ra$
2 racadabra$
10

11. ヒット文書の計算
文章の開始位置を持っておいて二分探索
ヒット位置すべてについて行う
文書0開始位置
０
文書1開始位置
15
文書2開始位置
32
45 57 ・
・
70
・
98
・
・
・
11

12. 他の全文検索手法との比較(1)
転置ファイル
単語に対して、その出現位置を記録
高速な実装が可能
正しく単語に分割されなかった部分の検索が漏れる
…の場合、検索に転置ファイルを用いるこ…
125 128
単語 位置
“転置” を検索
100, 125, 200, …
検索
・対応する位置を読みだす
128, 300, 789, …
転置
… …
12

13. 他の全文検索手法との比較(2)
N-gram
文章を隣接したn文字でインデックスする
漏れがない
ヒット位置の計算にコストがかかる
…市を統合した形で東京都が設置された…
“東京都”を検索
位置
N-gram
・”東京” “京都” に分割 100, 256, 1234, …
東京
・1ずれている位置を抽出
80, 257, 777, …
京都
… …
13

14. 他の全文検索手法との比較(3)
Compressed Suffix Array
SAを圧縮した状態で検索が行えるデータ構造
Sedueで採用
ランダムアクセス回数がSAよりも多く、
ＳＳＤ上でも許容されない
14

15. SAが良い理由
ヒット位置の検索に必要な計算量、ファイ
ルアクセス量が少ない
数十GB時で、40回程度の文字列の比較だけ
小さなランダムアクセス
ＳＳＤ向き
二分探索はディスクアクセスの
局所性がある
15

16. 二分探索の高速化
前半と、後半のほとんどのディスクアクセスを
省略できる
後半狭い
前半のn回の探索は
範囲にある。
2n通りしかアクセスしない
ディスクの
キャッシュに載せる
ブロックサイズ
で読むと速い
＜
≧
＜
二分探索 ・・・
≧ ＜
ディスク上の
SA
≧
中盤はＩＯ必要
20段程度 10段程度 10段程度
16

17. 検索パフォーマンス
ヒット文書数に比例
平均的クエリ(数万文書程度)なら100qps～
10
検索時間(s)
1
20M docs
50GB index
0.1
8GB ram
Pentium Dual Core
2.0Ghz
0.01 G.Skill 256GB SSD
1 100 10000 1000000
ヒット文書数
17

18. インデックス構築
一つの大きなＳＡを作らなければならない
小さいSAをたくさん作っても検索はできるが、
分割に比例して時間とIOがかかる
ディスク上で効率よくSAを作るのが問題
I/O 9回×2 = 18 回
I/O 10 回
段数ほとんど
変わらず、
二回探索
分割
モノリシック
18

19. ディスクでの構築
HDDか、もしくはSSDで作るか
SSDといえども、メモリ上での構築アルゴ
リズムをそのまま持ってくるのは無理
メモリほどランダムアクセス性能が高いわけではない
ディスクに対してシーケンシャルアクセス
のみで構築するアルゴリズム（パイプライ
ンアルゴリズム）がある
これを用いると、HDDでもSSDでも大差がない
現在は安価なHDDを並べて構築
19

20. パイプラインアルゴリズム
次の三つの操作で構成
04262…
014321…
abracadabra… 01402030140…
13153…
前から順に
アクセス
001223…
並べ替え 00011122…
011244…
01402030140… 00000112344…
前から順に
生成
ソート 分割・マージ
スキャン・フィルタ
20

21. SA構築パイプラインアルゴリズムの例
Doubling (O(nlogn))
DC3 (O(n))
現在利用しているアルゴリズム
21

22. 構築の高速化
スキャンで出力をファイルに書き出さずに
次の段に直接出力を渡す
ファイル入出力の時間を隠ぺいする
入出力用のスレッドを立てるなど
ソートを速くする
これが一番重要
HDDの転送速度以上でソートする必要がある
22

23. 外部メモリ上でのソート
分割→メモリ上でソート→マージ
メモリに載る
サイズに分割
マージ
ディスクに
メモリ上で
一旦保存
ソート
23

24. メモリ上でのソート
手法いろいろ
quick sort (std::sort())
parallel quick sort (std::sort()を並列化)
radix sort
いろいろ試したが、結局quick sortが速い
140
120 Quick sort (std::sort)
100
80 Parallel quick sort
60
40 Radix sort
20
0
Core2Quad 2.6Ghz 500MB data
速度(MB/s) 24

25. マージ
各ブロックを順に読みだしながらマージ
一度にある程度たくさん読まないとHDDでは遅い
典型的HDDでおよそ8MB程度
メモリが足らない場合
分割数*8MB
8MB以下のサイズで読む
バッファが必要
多段マージ
SSDを使う
25

26. 構築パフォーマンス
1GBのテキストに対して約24分(0.71MB/s)
メモリ上での高速な構築アルゴリズムで4～5MB/s
現在のところCPUがボトルネック
周波数・コア数が増えれば速くなる
より高速なアルゴリズムを実装中
26

27. リアルタイム化
SAは部分更新ができない
全体を構築しなおし
新しい文書用に、メモリ上の小さいインデ
クス(CSAなど)と組み合わせ
CSAは逐次更新、
SAは一日おきに更新
SA
CSA
古いデータ 新しいデータ
27

28. まとめ
Suffix Arrayによる全文検索はSSDに
適している
高速に検索が可能
100qps～
構築が課題
0.71MB/sec（59GB/day）
高速化中
28