SSDの応用例は専らモバイル志向でノートPCのハードディスクをSSDに置き換えることに関心が向けられており、そうした利用形態ではSSDの最大のメリットであるシークタイムの高速性が活かされることはない。シークタイムの短さに関して特にどん欲なサーバーアプリケーションのひとつにリレーショナルデータベースがある。今回テストに用いたSSDはサイズが非常に小さく、データベースのタプルそのものを格納することは多分できないが、インデックスを格納するには十分な大きさである。一般的なインデックスアクセスは、1つのインデックスブロックを読み込み、次のインデックスブロックがどれか確かめ、そのブロックを読み込む、というように行われる。さらに1つのクエリの評価過程で複数のインデックスが使われるなら、インデックスをSSDに格納することで高速化の効果がより顕著に表れる可能性もある。
リレーショナルデータベースのインデックスをSSDに格納した場合の効果を実証するため、2.2GHzのAMD Athlon X2プロセッサ搭載マシンにハードウェアRAIDカード経由で比較用の6台のサムスン社製750GB SATA HDDを接続し、64ビットFedora 9環境でPostgreSQL 8.3.3を実行した。
PostgreSQLではテーブル空間（tablespace）という機能によりテーブルまたはインデックスをデータベースオブジェクトとは別のディスクやファイルシステムに格納できる。インデックスを作成する際にtablespace句でインデックスの場所を明示的に指示してやるわけだ。後になってプライマリインデックス用のSSDをアップデートすることになった場合、以前のSSDを一時テーブル用に残してもよいだろう。これらのテーブルは大きなデータセットをソートするとき使われる。
テスト用のデータセットを探すのは決まって面倒な仕事になる。必要なのは無料で入手でき、数百万規模のタプルを含み、そのデータが誰からも理解されるようなデータセットだ。インデックスをSSDに格納した場合のパフォーマンスを従来のハードディスクによるRAID構成と比較してテストするためには、データセットが十分大きいことが必要で、そうすれば、インデックスの格納場所の違いによるパフォーマンスの変化を測定できるだけの十分な大きさのインデックスをテーブルのいずれかの欄に作れるからである。数ある特性の中でいま相手にしようとしているのは、インデックスを付けるプロセスそのものを効率化するBツリーという仕組みだ。Bツリーでは膨大な数のタプルにインデックスを付けることができ、たった3回か4回のシーク動作でインデックス全体から必要な項目にたどり着いてしまう。
UCIデータセットは、教師付き機械学習アルゴリズムをテストする目的で作られたデータセット集だ。これらのデータセットの中に非常に多くのタプルを持つものがいくつかあり、それをデータベースに読み込むと中規模のメインテーブルが作られる。たとえば、1990 USA Censusという未加工サンプルを読み込むと、約1GBのテーブルが1つ作られ、出生地（pob: place of birth）欄のインデックスは50MBになる。本稿では、インデックスをハードディスクに格納した場合とSSDに格納した場合についてメインテーブルでいくつかクエリを実行して、そのパフォーマンスをテストした。