TOP＞比較データ＞ pgbenchを使った運用性能の測定
OSS評価手法
オープンソースソフトウェアの性能・信頼性評価手法

第７回：大規模データベースにおけるPostgreSQLの性能評価
 著者：SRA  松田 亮一   2005/6/27
前のページ  1  2  3  4
pgbenchを使った運用性能の測定

   運用性能とはデータベースのロード／バックアップ／リストアといった、運用時に必要となる機能の性能である。大規模なデータベースを運用するには、通常運用でのバックアップが現実的な時間内で完了できるのか、障害復旧などのリカバリ時間がどのくらい必要なのか、といった事を運用開始前に把握しておかなくてはならない。さもないと、緊急時の復旧時間が予測できないことになる。
pgbenchとは

   バックアップとリストアには、PostgreSQLの標準的なツールであるpg_dumpとpg_restoreを使用した。ロードについては様々な方法が考えられるが、今回の評価ではpgbenchを使用した。pgbenchはPostgreSQLに標準で含まれるツールで、データベース作成とTPC-B類似の性能測定が行えるが、今回はデータベース作成機能のみを使用した。
pgbenchのテーブル構成とデータ量

   テーブルに投入するデータ量はスケールファクターという単位で指定でき、それがデータベースの規模となる。各テーブルに投入するデータの行数は、スケールファクターを基準にして決定される。図6にテーブル構造およびテーブル毎の行数を示す。

テーブル構造と行数
図6：テーブル構造と行数

   スケールファクターの単位がDBT-3とは異なることに注意されたい。
運用性能の測定内容

   運用性能の測定では、次の5つの機能に要した時間を測定する。

  • 大規模データのロード
  • バックアップ
  • リストア
  • インデックス再構築
  • PITRによるクラッシュリカバリ（PostgreSQL 8.0のみ）

   データのロードにはpgbenchを使用するので、ロードするデータがテキストファイルとして作成されるのではなく、pgbenchによって直接テーブルに挿入される。プログラムでデータを作りながらファイルを経由することなく、データベースへ挿入する時間が測定できる。なお、ファイルからのロードについては、既に説明したDBT-3のロードテストで測定してあるのでそちらを参照されたい。

   ここまでに説明したpgbenchのインストール方法と、運用性能の測定方法の詳細については、報告書のDB層7章の7.1〜7.3を参照のこと。
運用性能を測定した結果

   PostgreSQLのバージョンおよび設定として、次の4種類の環境で測定した。

  • PostgreSQL 7.4
  • PostgreSQL 8.0
  • PostgreSQL 8.0（テーブルスペースを使用）
  • PostgreSQL 8.0（アーカイブログを使用）

   テーブルスペースは3台のディスクに対して、行数の多いaccountsのテーブル・ファイル、accountsのインデックス・ファイル、それ以外のファイル群を割り当てた。これにより、ディスクアクセスの分散が効率よく行われると予想した。

   また、PITRによるクラッシュリカバリを使用するためには、アーカイブログを設定する必要がある。アーカイブログを設定するとデータベースへの書き込み時にロギングされるので、その分だけ書き込み時のパフォーマンスの低下が予想される。

   実行結果については、ハードウェア等の環境により結果が異なるので、以下に記述する内容については、ひとつの例として参考にして頂きたい。

   バックアップ時間の結果を図7に示す。性能差はほとんどなかった。バックアップは参照系SQLでインデックスも使わないので、テーブルスペースやアーカイブログの影響はないため、想定の結果となった。

バックアップ時間
図7：バックアップ時間

   リストア／クラッシュリカバリ時間の結果を図8に示す。7.4と8.0（通常）がほとんど同じ性能であった。8.0（アーカイブログ）のリストアが少し遅いのはアーカイブログの書き込みが発生しているためである。8.0（テーブルスペース）が少し速いのは、インデックス構築時にディスク分散の効果があるためである。そして、8.0（クラッシュリカバリ）は、pg_restoreによるリカバリと比較して、およそ1/3の時間でリカバリが完了した。

   クラッシュリカバリを使用するためにはアーカイブログを設定する必要があり、更新系SQLの性能低下が少しあるが、緊急時のリカバリ時間が厳しいシステムでは使用する価値があるだろう。

   なお、スケールファクター4000のデータが取れていない部分については、ディスク容量不足が原因である。

リストア／クラッシュリカバリ時間
図8：リストア／クラッシュリカバリ時間

   ロード時間とインデックス再構築時間については、本記事では記述を省略する。報告書のDB層7章の7.4.1を参照のこと。
おわりに

   前々回から今回までの3回に渡り、IPAおよび、日本OSS推進フォーラム・開発基盤ワーキンググループによって公開された「DB層の評価」報告書を基に、評価手順ならびに評価結果を説明してきた。

   今回は、大規模データベースにおけるPostgreSQLの性能評価として、DBT-3を使った検索性能の測定と、pgbenchを使った運用性能の測定について、手順と結果の概略を説明した。詳細については、「DB層の評価」報告書の6〜7章を参照して頂きたい。

   最後に苦労点を記しておきたい。DBT-3 ver 1.4がまともに動作するようになるまで、かなりの時間が必要であった。ようやく動作した頃にver 1.5がリリースされたが、こちらの動作にもかなりの時間を費やした。報告書は、当時の最新版であるver 1.5を対象としている。今回、本記事執筆の締切直前にver 1.6がリリースされた。ざっくりと見たところ、我々がver 1.5の評価の一環で作成した修正パッチについても、ver 1.6に取り込まれている事が確認できた。本記事および報告書に基づきDBT-3を実行する場合は、バージョンについて注意されたい。
前のページ  1  2  3  4

株式会社SRA 松田 亮一
 著者プロフィール
株式会社SRA  松田 亮一
Smalltakerを目指すべく中途入社。現在はPostgreSQL+Javaに関するサポート／コンサル／セミナー講師などを業務としている。また、The Seasar Projectコミッタ、Jun for Java Projectコミッタとして、OSS活動を行っている。
INDEX
第7回：大規模データベースにおけるPostgreSQLの性能評価
  はじめに
  DBT-3のクエリー
  DBT-3を実行した結果
pgbenchを使った運用性能の測定