SSDとSATAのベンチマーク比較 第2ラウンド:サーバアプリケーション:Validation Case Study(2/2 ページ)
SSDとSATA HDDのベンチマーク比較第2弾では、SSDのシークタイムが極めて短いことがサーバにおいてどれだけ有利に働くのか、シークタイムの短さに関して特にどん欲なサーバアプリケーションの1つであるリレーショナルデータベースを使って検証する。
テストで特定のインデックスを評価するときは、それ以外のインデックスが存在しない状況でテストすることにしている。そこで、SSD上のインデックスをテストするときはHDD上のインデックスを事前に削除し、HDD上のインデックスをテストするときはSSD上のインデックスを削除する。インデックスごとに3種類のselectコマンドを実行した。各コマンドはそれぞれコールドキャッシュを使う操作、ホットキャッシュを使う操作、“クロス”キャッシュを使う操作に対応する。
コールドキャッシュによる操作では、いったんPostgreSQLデータベースを停止し、データベースとSSDテーブル空間の置かれているディスクをマウント解除してからテストを行った。ホットテストでは、同じクエリを2回実行した。クロステストのためには、ある特定の状態で最初にコールドテストとホットテストを実行してから別の状態でクエリを実行する必要がある。最初の状態のコールドテストとホットテストでPostgreSQLは、その状態に対応するインデックスページをRAMにキャッシュする。次に別の状態でクエリを実行すると、一部のインデックスページはRAMにキャッシュされているものが利用されるかもしれないが、必要なすべてのページでキャッシュが使われるわけではない。絶えずアクセスされるデータベースで、しかもパフォーマンスを気にしてインデックス用にSSDを装備しようと考えるほどのデータベースの場合、インデックスページのどれかがRAMにキャッシュされないことなど PostgreSQLではほとんどあり得ず、SSDの優位性は低下する。一方、ホットテストは現実的でない。必要なインデックスページがすべてキャッシュされる可能性が非常に高いからだ。クロステストは折衷的になるように工夫されている。つまり、一部のインデックスページはキャッシュに存在するだろうが、クエリに必要なすべてのインデックスページがキャッシュに含まれることはない。
クエリからどれだけの数のタプルが返される見込みがあるかでデータベース側のクエリの解決方法が変化するため、PostgreSQLで常にインデックスが使われるように、あまり多くの結果を返さないようなクエリを使用した。具体的には、出生地(pob:places of birth)のリストからFlorida(pob=12)、Puerto Rico(pob=72)、Nevada(pob=32)を選択したわけだが、SQLのexplainコマンドによると、これらのクエリでpob上のインデックスが使われることが分かったからだ。これらのクエリはそれぞれ5万4445個、1万134個、4722個のタプルをテーブル内の合計245万8285個のタプルの中から見つける。クロステストの順番はFlorida、Puerto Rico、次にPuerto Rico、Nevada、次にNevada、Floridaの順である。SQLクエリは以下に示すとおり、至って簡単なものだ。PostgreSQLに不慣れなら、先頭にexplainキーワードをつけてクエリを実行するとよい。クエリを実行したとき実際にどのようなことが起こるかをPostgreSQLが教えてくれる。以下の例では、インデックスが本当に使われるか確認するためにexplainを使用している(結果はIndex Scan行に示される)。インデックススキャン後に実行されるAggregateは、返されたタプルの数をカウントするだけである。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
SSDは、XFSでフォーマットし、最大のパフォーマンスを得るためにnobarrierオプションを指定してマウントした。nobarrierオプションを指定すると、突然電源が切れた場合にジャーナル内のトランザクションが失われる恐れがあるが、サーバ環境ではUPSが突然の電源故障からマシンを保護するものと考えられるので、nobarrierオプションを指定しても問題はない。また、PostgreSQLでpobssdインデックスが使われるようにするためにテーブル空間(tablespace)としてSSDを指定した。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
平均すると、ホットキャッシュによるパフォーマンスは、SSDとHDDのどちらのインデックスでも速度的によく似ており、SSDでの必要な時間はHDDのインデックスで同じクエリを使用したときの70〜85%になった。しかし、Nevadaに関するデータを検索したとき特異的な現象が起こり、ホットキャッシュの使用時にSSDのインデックスでは5ミリ秒しかかからないのに、HDDのインデックスでは約200ミリ秒もかかった。Nevadaだけパフォーマンスが異なる理由は、よく分からない。
右のグラフは、コールドキャッシュとクロスキャッシュ関して、SSDのインデックスとHDDのインデックスのパフォーマンスを比較したものだ。コールドキャッシュの場合、SSDのインデックスはHDDのインデックスのときの3〜10%程度の時間でクエリを解決できている。コールドキャッシュでパフォーマンスが最低となるクエリはFloridaで、これはほかのケースよりも多くのタプルをフェッチする必要があるからだ。また、FlordaについてはSSDインデックスで必要な時間がHDDインデックスでの時間の10%となっているが、これはたぶん、インデックスそのものよりもベーステーブルにかんする負荷が大きいせいだ。クロスキャッシュを使うクエリの結果は興味深い。前回のクエリでインデックスの一部のページがRAMにキャッシュされていても、SSDはHDDキャッシュのときの20%以下で同じクエリを実行できている。
まとめ
SSDの最大容量は従来のHDDに比べるとまだ小さく、Gバイト当たりのコストもかなり高く付くが、1台のSSDにより得られるシークタイムは6台のHDDで構成されるハードウェアRAIDよりも優れている。データベースサーバを運用していて、インデックスページのキャッシュに使えるRAMを既に限界まで増設している場合、さらにパフォーマンスを上げる必要があるなら、データベースのインデックスのパフォーマンスを引き上げるために32Gバイトか64GバイトのSSDを増設することを検討してもよいだろう。
Ben Martinは、ここ10年以上ファイルシステムに取り組んできた。博士号を取得し、現在はlibferris、各種ファイルシステム、検索ソリューションを中心にコンサルティングサービスを手掛けている。
関連記事
- SSDとSATA RAIDのベンチマーク比較
一昔前に比べれば安価になったSSD。シークタイムの点ではHDDより圧倒的に優れているものの、HDDから移行する価値はどのくらいあるのだろうか。幾つかの比較を行ってみた。 - ハードウェアRAIDとLinuxカーネルによるソフトウェアRAIDのベンチマーク比較
ソフトウェアの処理で行うソフトウェアRAIDと、高価なハードウェアRAIDカードとではディスクアクセスの速度はどれほど向上するのだろうか。ベンチマーク結果を基に、すこし硬派な検証を行ってみよう。 - RAIDで高速デスクトップ
RAIDを使用すればディスク性能はどのくらい向上させることができるのか。ここでは、3タイプのユーザーを想定して、日常的に繰り返し行う必要のある代表的な操作でパフォーマンスの検証を行った。 - ハイエンドNICは実際にどの程度ネットワークスループットを向上させるのか?
オンボードのNICとデスクトップ用のハイエンドNICはどの程度性能が違うのだろう。幾つかのベンチマークテストを通して、その性能差を検証してみよう。価格にふさわしい性能差はあるのだろうか。 - イーサネットのセカンドポートの有効な活用法
カタログスペックにだまされて2つのイーサネットポートを持つPCを購入したはいいが、結局1つしか使っていない――そんな読者のために、2つ目のイーサネットポートを活用する方法をお知らせしよう。 - マルチコアCPUを活用したファイル圧縮
マルチコアに対応しているmgzipとpbzip2を使えば、ファイルの圧縮/復元処理にマルチコアの真の実力を解放させることができる。ここでは、実際にそれぞれの処理に要する時間を計測してみた。 - LAMP vs. LAMP──mod_perlとmod_phpのパフォーマンス比較
ダイナミックWebサイトの構築ではPerlとPHPが広く使われている。では、mod_perlとmod_phpのパフォーマンスはどちらがよいのだろうか。ちょっとしたテストをしてみたので報告する。
Copyright © 2010 OSDN Corporation, All Rights Reserved.