Kazuho@Cybozu Labs

　HDD に比較した場合 SSD のメリットは、その圧倒的なランダムリード性能にあります。一方で、シーケンシャルアクセスの場合は大差ありませんし、書き込み性能や信頼性の点ではまたまだ不安も多いです。では、一体どういうところで SSD を使うべきなのでしょう。今回は、Tritonn (MySQL+Senna) のストレージとしての SSD の使用を検討することにしました。全文検索アルゴリズムは一般にランダムリードが頻発するため、索引をメモリにキャッシュして運用することが多い (参考: [Senna-dev 661] Re: インデックスをキャッシュに保持する方法について) 一方で、一般にスレーブとして運用されるため、故障しても大きな問題にならないためです。現にパストラックでも Tritonn をスレーブとして使い、全文索引をメインメモリに載せています。が、検索回数はそれほどでもないので、CPU はほとんど遊んでしまっています。これを、メインメモリほど高速ではないが、バイト単価が大幅に安い SSD で置き換えることができないか、というわけです。

2. 簡易ベンチマーク

　というわけで、手元のサーバでパストラックのテストデータ (実際のデータから特定時期のみを切り出したもの) を使ってベンチマークをとってみました。環境は以下のとおりです。比較対象として SSD を買うのは面倒だったので、一般的な USB メモリを利用しています。ここからどうやって内蔵型の SSD のパフォーマンスを予測するかは、追って説明します。

　この環境に対して、2000個のキーワードに合致する上位20件のデータを要求するクエリを２並列で実行し、その所要時間を測定したところ、以下のようになりました。また、この際に iostat を用いて観測した I/O トランザクションのサイズは、平均 10〜15KB 程度でした。

3. 結論

　ベンチマークから明らかなように、検索データのストレージとして読み込み専用で使うのであれば、一般的な USB メモリでも HDD より数倍高速であることがわかります。また、メインメモリにキャッシュさせた時の速度が USB メモリにアクセスした時の 10 倍弱であることから、10KB台のサイズでのランダムリード性能が数十MB/秒クラスの SSD を用意できれば、一昔前のサーバにオンメモリで索引を置いた場合に近い速度が発揮できそうです。最近だと Intel の X25-M のように、10万円以下、100GB 以上、20MB/sec 以上、という性能をもつ SSD も発売になっています。

　検索サービスを運用しようと思うと、従来は、メインメモリへキャッシュすることを前提に考える必要があったため、検索データ 1GB あたり１万円以上の投資が必要でした。しかし、SSD をうまく使えば、その 1/10 程度のコストでサービスを構築できそうに思えます。これから数年は、また、検索サービス関連が盛り上がるかもしれませんね。

注1: メインメモリにキャッシュした状態のベンチマーク以外は、swapoff -a, swappiness=0 等に設定してキャッシュメモリを 180KB 程度に抑制
注2: 試験環境でのシーケンシャルリードは 15MB/sec. 程度、ライトは 800KB/sec. 程度
注3: SEN* ファイルの合計サイズ