検索
特集

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

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

Share
Tweet
LINE
Hatena
SourceForge.JP Magazine

 昨日は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コマンドはうまく動かない。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

       | 次のページへ

Copyright © 2010 OSDN Corporation, All Rights Reserved.

ページトップに戻る