TOP>企業情報>コラム>技術情報>はじめましてOracle! Vol.5

はじめましてOracle! Vol.5

はじめましてOracle!

第5回目となる今回は、Oracle Database Applianceの性能を検証した結果について解説します。

(全6回連載)

Vol.5 買ってつないだらすぐ使える!Oracle Database Applianceがやってきた!(性能検証編)

Pay as you grow使用時のCPUスケーラビリティ検証


今回検証するのは、Oracle Database Applianceの目玉とも言えるPay as you growです。Oracle Database Applianceには1サーバーあたり6コアのCPUが2基搭載されていますが、Pay as you growによって実際に使用するコア数を制限することで、ライセンスのコストを大幅に抑えることができます。

このPay as you growによって、少ないコア数でスモール・スタートし、稼働状況をみてコアを増やすというこれまでにない運用が可能になります。

例えば、利用者数の増加が予測できないような新規のシステムや、順次複数のシステムを統合していくような場合に効果を発揮します。

しかし、コア数に応じてライセンスのコストが増えるため、効果が見込めない限りは追加の投資を行うことができません。そこで今回は、Pay as you growでコア数を増やした場合の効果を検証してみます。

検証方法

Javaのアプリケーションからオンライン・トランザクション(OLTP)系の処理を実行し、Oracle Database Applianceのコア数を2,4,8,10,12と増やした場合のスループットとCPU使用率を計測します。

今回実施するOLTP系の処理は、100~1,000セッションが同時にSQLを実行するため、CPUに大きな負荷が掛かります。こうした状況下であれば、コア数を増やした場合の効果が顕著に表れるはずです。

検証方法

検証方法

検証結果

まずは、CPUコア数とスケーラビリティの関係から見ていきます。

Pay as you growの最小構成である2コアの場合、セッション数が200になった時点で処理が頭打ちになっていることが分かります。つまり、秒間350トランザクションあたりが2コアの処理限界点ということになります。

スケーラビリティ検証


このように処理限界を迎えた場合にPay as you growによるコア数の追加が検討されることになります。検証結果を見ると、4,8,10,12とコア数を増やした場合に処理限界点が何倍にも引き上げられていることが分かります。

12コアの場合は1,000セッションでもまだ処理限界点が見えず、秒間2,000トランザクションに迫る数値を記録しています。コア数を増やしたことによる効果がはっきりと見て取れます。

続いてCPU使用率を見ると、コア数を増やすにつれて%userの割合が減少し、代わりに%idleの割合が上昇しています。コア数を増やしたことで、CPUに余裕が生まれています。

CPUリソース使用傾向


検証の結果、Pay as you growでコア数を増やすことで、リニアに処理性能が向上することが確認できました。当たり前の結果かもしれませんが、コア数はデータベース・システムの性能とコストを決める重要な要素なので、Pay as you growによって選択肢が広がるというのは、Oracle Database Applianceならではのメリットだと言えます。

Enterprise EditionのほうがStandard Editionより安い!?


続いての検証では、Standard EditionとEnterprise Editionの性能差がどの程度あるのかを比較します。

Oracle Database Applianceでは、Oracle DatabaseのエディションがEnterprise Editionのみと決められています。「なぜStandard Editionが使えないの?」と思うかもしれませんが、実はPay as you growによって少ないコア数からスタートすると、Standard Editionとほとんど変わらないライセンス・コストに抑えることができます。

例えば、CPUを2基搭載したサーバー2台でStandard EditionのRACを構築する場合、合計4プロセッサ分のライセンスが必要となりますが、Oracle Database ApplianceのRAC構成でPay as you growを使用した場合、最小2プロセッサ分のライセンスで済みます。

両者のライセンス・コストはほとんど変わりませんが、Enterprise Editionには独自の機能が実装されているため、管理性や性能などがStandard Editionよりも大幅に強化されています。検証の前に各機能についておさらいしておきましょう。

代表的なEnterprise Editionの機能

代表的なEnterprise Editionの機能


Enterprise Editionの機能は、標準機能とオプション機能の2つに分類されます。

Enterprise Edition標準機能は、特に追加のライセンスを必要とせずに使用することができます。

Enterprise Edition標準機能
機能 説明
高速増分バックアップ Recovery Manager(以下、RMAN)の増分バックアップを強化する機能です。変更があったブロックのみを追跡して読み込むため、バックアップ時間を大幅に短縮できます。
フラッシュバックデータベース データベース全体またはテーブルを、過去の一時点に戻すことができる機能です。誤操作によるデータの削除や更新などの人為的なエラーから素早く復旧できます。
オンライン表再定義、
索引メンテナンス
アプリケーションからのアクセスを中断させずに、列の追加や索引の再作成などの操作を行う機能です。計画停止の機会を減らすことができます。
ビットマップ索引 性別のような一意性の低い列において、索引検索を高速化する機能です。索引キーの値をビットマップとして持つため、一意性が低いほど索引のサイズが小さくなり、オンキャッシュで処理できる可能性が高くなります。
パラレル処理 1つの処理を複数プロセスに分割して並列実行する機能です。CPUコアを多く搭載している環境において、パフォーマンスが大幅に向上します。


一方のオプション機能は、運用管理やパフォーマンス、セキュリティといった特定の分野を大きく強化することができます。

オプション機能
機能 説明
Diagnostics Pack Enterprise Managerの機能を強化するオプションです。自動的にデータベースの稼働状況を診断・分析し、対処方法を管理者に通知します。
Tuning Pack Enterprise Managerの機能を強化するオプションです。負荷の高いSQLを特定し、対処方法を管理者に提示します。
Advanced Compression OLTP表の圧縮を可能にするオプションです。パフォーマンスを落とすことなくストレージ容量を抑えることができます。
Partitioning 表や索引をデータベース内部で分割(パーティション化)して管理するオプションです。アプリケーションからは1つに見えますが、内部的に必要なパーティションにだけアクセスされるため、パフォーマンスや管理性が向上します。
Advanced Security セキュリティを強化するオプションです。パフォーマンスを落とすことなく、通信の暗号化やデータファイルの暗号化などが可能です。


「機能が多すぎてよく分からない!」という場合は、以下の項目に当てはまるかどうかチェックしてみてください。1つでも当てはまれば、Enterprise Editionの効果が期待できます。

  • バックアップの時間を短くしたい
  • オペレーション・ミスの対策を実装したい
  • システムを停止させずに表や索引のメンテナンスを行いたい
  • データウェアハウス系の大規模検索処理を高速化したい
  • CPUのリソースをフル活用したい
  • GUIでデータベースの稼働状況を確認したい
  • データベースに問題が発生したら自動的に通知してほしい
  • GUIでデータベースのチューニングを行いたい
  • データ量が増加してきたので、ストレージコストを抑えたい
  • データ量が増加してきたが、パフォーマンスを低下させたくない
  • 情報漏えいを防ぐために、データを暗号化したい

Enterprise Edition機能の効果を検証


今回の検証では、Partitioningやパラレル処理、圧縮といったEnterprise Editionの機能を使って、性能がどの程度向上するのかを確認します。

検証方法

データウェアハウスを想定した大規模な検索処理を行って応答時間を計測します。

Enterprise Editionの機能を使わない(Standard Edition相当)の場合と、Enterprise Editionの機能を駆使した場合との結果を比較して効果を測定します。

ベンチマークにはStar Schema Benchmarkを使用します。スタースキーマとは、データウェアハウスでよく利用されるデータモデルで、ファクトと呼ばれる数値が格納されるテーブルと、ディメンションと呼ばれる名前、商品名、地域などの属性(マスタ)データが格納されるテーブルで構成されています。ディメンションがファクトを囲んでいる形が星に似ていることから、スタースキーマと呼ばれます。

スタースキーマのデータモデル

スタースキーマのデータモデル

今回実行する検索処理は、約100GBのデータを対象とした売上高の集計です。

結果として返されるのは1行だけですが、検索範囲が広いため大量のデータにアクセスしなければなりません。

実行したSQL(Star Schema Benchmarkより)

select
 sum(lo_extendedprice*lo_discount) as revenue
from
 lineorder,date1
where
 lo_orderdate = d_datekey
 and d_year = 1993
 and lo_discount between 1 and 3
 and lo_quantity < 25;


検証結果

Enterprise Editionの機能を使わない(Standard Editon相当)場合の応答時間を100として、結果を比較します。

大規模な検索処理の応答時間比較


まず、Enterprise Editionの機能であるパーティション、圧縮、ビットマップ索引を使った場合の結果(グラフの中央)を見てみると、応答時間が半分以下に短縮されています。

これは各種機能によって、検索時にアクセスしなければならないデータベースのブロック数が大幅に少なくなっているためです。

この際パラレル処理は行っていないので、検索は単一のプロセスで実行されています。

つまり、Pay as you growで少ないコア数を選択したとしても、Standard Editionと比べて倍以上の性能が期待できるということになります。

パラレルを有効にした場合(グラフの右側)は更に応答時間が短縮され、Standard Edition相当と比較すると1/10以下になっています。Enterprise Editionの効果がはっきりと見て取れるのではないでしょうか。

次回は、Oracle Database Applianceがどのようなシステムで活用できるのかを解説します。


執筆者紹介

岸和田 隆

岸和田 隆(Takashi Kishiwada)

株式会社アシスト データベース技術本部

アシスト入社後、Oracle Database の研修講師、フィールド・ サポート、新バージョンの検証を経て、2007年 自社ブランド 「DODAI」の準アプライアンス製品の企画・開発、2009年 PostgreSQL、2011年 EDB Postgres、MySQL / MariaDB の事業立上を担当。 現在は「データベースのアシスト」を目指した活動を行っている。

岸和田の紹介記事はこちら



関 俊洋

関 俊洋(Toshihiro Seki)

株式会社アシスト データベース技術本部

2006年、株式会社アシスト入社。データベース・システムの構築や運用トラブルの解決といったフィールド・サポート業務を経験し、その後は新製品の検証やハードウェアとデータベースを組み合わせたソリューション(DODAI)の立ち上げに従事。現在はデータベースの価値や魅力を伝えるための執筆・講演活動を行っている。『SQL逆引き大全363の極意』共著。

関の紹介記事はこちら

連載記事一覧


Facebookで情報をお届けしています

Facebookでは、アシストの「今」を週3回のペースでお届けしています。「めげない、逃げない、あまり儲けない」を合言葉に日々頑張っておりますので、応援よろしくお願いします。



ページの先頭へ戻る