SSDとSATAのベンチマーク比較 第2ラウンド：サーバアプリケーション：Validation Case Study（1/2 ページ）

SSDとSATA HDDのベンチマーク比較第2弾では、SSDのシークタイムが極めて短いことがサーバにおいてどれだけ有利に働くのか、シークタイムの短さに関して特にどん欲なサーバアプリケーションの1つであるリレーショナルデータベースを使って検証する。

[ITmedia]

　昨日はBonnie++を用いてクライアントマシンにおけるソリッドステートドライブ（SSD：Solid State Drive）のベンチマーク評価を行い、同じ予算で複数台のHDDを購入するのに比べて1台のSSDを購入することにどれだけメリットがあるかを論じた。今日はSSDのシークタイムが極めて短いことがサーバにおいてどれだけ有利に働くかを見てみよう。

　SSDの応用例はもっぱらモバイル志向でノートPCのHDDをSSDに置き換えることに関心が向けられており、そうした利用形態ではSSDの最大のメリットであるシークタイムの高速性が生かされることはない。シークタイムの短さに関して特にどん欲なサーバアプリケーションの1つにリレーショナルデータベースがある。今回テストに用いたSSDはサイズが非常に小さく、データベースのタプルそのものを格納することはたぶんできないが、インデックスを格納するには十分な大きさである。一般的なインデックスアクセスは、1つのインデックスブロックを読み込み、次のインデックスブロックがどれか確かめ、そのブロックを読み込む、というように行われる。さらに1つのクエリの評価過程で複数のインデックスが使われるなら、インデックスをSSDに格納することで高速化の効果がより顕著に表れる可能性もある。

　リレーショナルデータベースのインデックスをSSDに格納した場合の効果を実証するため、2.2GHzのAMD Athlon X2プロセッサ搭載マシンにハードウェアRAIDカード経由で比較用の6台のサムスン社製750GバイトSATA HDDを接続し、64ビットFedora 9環境でPostgreSQL 8.3.3を実行した。

　PostgreSQLではテーブル空間（tablespace）という機能によりテーブルまたはインデックスをデータベースオブジェクトとは別のディスクやファイルシステムに格納できる。インデックスを作成する際にtablespace句でインデックスの場所を明示的に指示してやるわけだ。後になってプライマリーインデックス用のSSDをアップデートすることになった場合、以前のSSDを一時テーブル用に残してもよいだろう。これらのテーブルは大きなデータセットをソートするとき使われる。

　テスト用のデータセットを探すのは決まって面倒な仕事になる。必要なのは無料で入手でき、数百万規模のタプルを含み、そのデータが誰からも理解されるようなデータセットだ。インデックスをSSDに格納した場合のパフォーマンスを従来のHDDによるRAID構成と比較してテストするためには、データセットが十分大きいことが必要で、そうすれば、インデックスの格納場所の違いによるパフォーマンスの変化を測定できるだけの十分な大きさのインデックスをテーブルのいずれかの欄に作れるからである。数ある特性の中でいま相手にしようとしているのは、インデックスをつけるプロセスそのものを効率化するBツリーという仕組みだ。Bツリーでは膨大な数のタプルにインデックスをつけることができ、たった3回か4回のシーク動作でインデックス全体から必要な項目にたどり着いてしまう。

　UCIデータセットは、教師付き機械学習アルゴリズムをテストする目的で作られたデータセット集だ。これらのデータセットの中に非常に多くのタプルを持つものが幾つかあり、それをデータベースに読み込むと中規模のメインテーブルが作られる。例えば、1990 USA Censusという未加工サンプルを読み込むと、約1GBのテーブルが1つ作られ、出生地（pob: place of birth）欄のインデックスは50Mバイトになる。本稿では、インデックスをHDDに格納した場合とSSDに格納した場合についてメインテーブルで幾つかクエリを実行して、そのパフォーマンスをテストした。

　UCIのWebサイトでは、この人口調査データを未加工のタブ区切り形式のテキストファイルとして配布している。使用したデータベーススキーマは後記のとおり。以下のコマンドにより、テキストファイルが読み込まれ、データベースが解析され、HDDにインデックスが作られる。一意のIDフィールドをプライマリキーとする都合上、copyコマンドにすべての欄を明示的に指定する必要がある。USCensus1990raw.data.txtファイルにはファイルの最後に空白行が1つあって、これを取り除かないとcopyコマンドはうまく動かない。

create database ucicensus1990;
\c ucicensus1990;


create table census (


AAGE boolean, AANCSTR1 boolean, AANCSTR2 boolean, AAUGMENT boolean, ABIRTHPL boolean, ACITIZEN boolean,
ACLASS boolean, ADEPART  boolean, ADISABL1 boolean, ADISABL2 boolean, AENGLISH boolean, AFERTIL boolean,
AGE int, AHISPAN  boolean, AHOUR89  boolean, AHOURS boolean, AIMMIGR  boolean, AINCOME1 int,
AINCOME2 int, AINCOME3 int, AINCOME4 int, AINCOME5 int, AINCOME6 int, AINCOME7 int, AINCOME8 int,
AINDUSTR boolean, ALABOR   boolean, ALANG1   boolean, ALANG2   boolean, ALSTWRK  boolean,
AMARITAL boolean, AMEANS   boolean, AMIGSTAT boolean,  AMOBLLIM boolean, AMOBLTY  boolean,
ANCSTRY1 int, ANCSTRY2 int, AOCCUP boolean, APERCARE boolean, APOWST boolean, ARACE boolean,
ARELAT1 boolean, ARIDERS boolean, ASCHOOL boolean, ASERVPER boolean, ASEX boolean, ATRAVTME boolean,
AVAIL int, AVETS1 boolean, AWKS89 boolean, AWORK89 boolean, AYEARSCH boolean, AYRSSERV boolean,
CITIZEN int, CLASS int, DEPART int, DISABL1 int, DISABL2 int, ENGLISH int, FEB55 boolean, FERTIL int,
HISPANIC int, HOUR89 int, HOURS int, IMMIGR int, INCOME1 int, INCOME2 int, INCOME3 int, INCOME4 int,
INCOME5 int, INCOME6 int, INCOME7 int, INCOME8 int, INDUSTRY int, KOREAN boolean, LANG1 int, LANG2 int,
LOOKING int, MARITAL int, MAY75880 boolean, MEANS int, MIGPUMA int, MIGSTATE int, MILITARY int,
MOBILITY int, MOBILLIM int, OCCUP int, OTHRSERV boolean, PERSCARE int, POB int, POVERTY int, POWPUMA int,
POWSTATE int, PWGT1 int, RACE int, RAGECHLD int, REARNING int, RECTYPE text, RELAT1 int, RELAT2 int,
REMPLPAR int, RIDERS int, RLABOR int, ROWNCHLD boolean, RPINCOME int, RPOB int, RRELCHLD boolean,
RSPOUSE int, RVETSERV int, SCHOOL int, SEPT80 boolean, SERIALNO text, SEX int, SUBFAM1 int,
SUBFAM2 int, TMPABSNT int, TRAVTIME int, VIETNAM boolean, WEEK89 int, WORK89 int, WORKLWK int,
WWII boolean, YEARSCH int, YEARWRK int, YRSSERV int,


 id serial primary key
);


copy census ( AAGE, AANCSTR1,  AANCSTR2, AAUGMENT, ABIRTHPL, ACITIZEN, ACLASS,
   ADEPART, ADISABL1, ADISABL2, AENGLISH, AFERTIL, AGE, AHISPAN, AHOUR89, AHOURS, AIMMIGR,
   AINCOME1, AINCOME2, AINCOME3, AINCOME4, AINCOME5, AINCOME6, AINCOME7, AINCOME8, AINDUSTR,
   ALABOR, ALANG1, ALANG2, ALSTWRK, AMARITAL, AMEANS, AMIGSTAT, AMOBLLIM, AMOBLTY, ANCSTRY1,
   ANCSTRY2, AOCCUP, APERCARE, APOWST, ARACE, ARELAT1, ARIDERS, ASCHOOL, ASERVPER, ASEX,
   ATRAVTME, AVAIL, AVETS1, AWKS89, AWORK89, AYEARSCH, AYRSSERV, CITIZEN, CLASS, DEPART,
   DISABL1, DISABL2, ENGLISH, FEB55, FERTIL, HISPANIC, HOUR89, HOURS, IMMIGR, INCOME1, INCOME2,
   INCOME3, INCOME4, INCOME5, INCOME6, INCOME7, INCOME8, INDUSTRY, KOREAN, LANG1, LANG2, LOOKING,
   MARITAL, MAY75880, MEANS, MIGPUMA, MIGSTATE, MILITARY, MOBILITY, MOBILLIM, OCCUP, OTHRSERV,
   PERSCARE, POB, POVERTY, POWPUMA, POWSTATE, PWGT1, RACE, RAGECHLD, REARNING, RECTYPE, RELAT1,
   RELAT2, REMPLPAR, RIDERS, RLABOR, ROWNCHLD, RPINCOME, RPOB, RRELCHLD, RSPOUSE, RVETSERV, SCHOOL,
   SEPT80, SERIALNO, SEX, SUBFAM1, SUBFAM2, TMPABSNT, TRAVTIME, VIETNAM, WEEK89, WORK89, WORKLWK,
  WWII, YEARSCH, YEARWRK, YRSSERV )
from '/.../USCensus1990raw.data.txt';


create index pob on census ( pob );
analyse;


SELECT relname, reltuples, relpages * 8 / 1024 AS "MB" FROM pg_class ORDER BY relpages DESC;
              relname              |  reltuples  |  MB
-----------------------------------+-------------+------
 census                            | 2.45828e+06 | 1010
 census_pkey                       |  2.4583e+06 |   52
 pob                               | 2.45828e+06 |   52
...
explain select count(*) from census where pob = 33;
                                   QUERY PLAN
--------------------------------------------------------------------------------
 Aggregate  (cost=33994.42..33994.43 rows=1 width=0)
   ->  Index Scan using pob on census  (cost=0.00..33965.20 rows=11686 width=0)
         Index Cond: (pob = 33)
(3 rows)