TOP>企業情報>コラム>技術情報>既存の概念を覆す!Oracle Database In-Memoryのテクノロジー Vol.2

既存の概念を覆す!Oracle Database In-Memoryのテクノロジー Vol.2

前回はOracle Database In-Memoryの仕組みを図解で解説しました。今回は実際にテーブルをインメモリ化して、検索処理の性能を測ってみます。Oracle Databaseにインメモリ+カラム型の技術が加わると、性能はどの程度向上するのでしょうか?

Vol.2 Oracle Database In-Memoryは本当に激速なのか(前編)

テーブルをポピュレーションする


前回のおさらいになりますが、Oracle Database In-Memoryには以下の特徴があります。分かりやすく表現すると、「Oracle Databaseにカラム型のメモリ領域(インメモリ・カラムストア)を追加したもの」がOracle Database In-Memoryです。

Oracle Database In-Memoryの特徴

  • メモリ上にロー型とカラム型のフォーマットを同時に保持する
  • OLTPとDWH処理の両方を高速化する
  • 更新処理では従来通りデータベース・バッファ・キャッシュ(ロー型)を使う
  • 検索処理では新しく実装されたインメモリ・カラムストア(カラム型)を使う
  • 両者の使い分けはオプティマイザが自動的に判断してくれるため、SQLの書き換えは不要


今回は、カラム型が得意とする検索処理を実行した時の性能を測っていきます。使用するハードウェアおよびOracle Databaseのパラメータは以下のとおりです。検証データはStar Schema Benchmarkを使って生成しており、テーブルのサイズは約70GB、レコード数は約6億です。

※Star Schema Benchmarkの詳細についてはこちら をご参照ください。

使用するハードウェアと初期化パラメータ

表1:使用するハードウェアと初期化パラメータ

Star Schema Benchmarkのテーブル構成

図1:Star Schema Benchmarkのテーブル構成

まずは、各テーブルをインメモリ・カラムストアに読み込みます。この動作は「ポピュレーション」と呼ばれ、メモリに読み込む際にカラム型への変換や圧縮が行われます。ポピュレーションを行うには、テーブルに対してALTER文でINMEMORY属性を指定します。今回は優先度をCRITICAL、圧縮レベルをFOR QUERY LOWとします。

ALTER文

優先度をNONE以外に設定した場合、バックグラウンド・プロセスが2分間隔でポピュレーションのタスクを実行してくれます。OS上からは「ora_wNNN_<SID>」というワーカー・プロセスがポピュレーションを行っている様子が確認できます。

ポピュレーション中のOS稼働状況

図2:ポピュレーション中のOS稼働状況

ポピュレーションはそれなりに負荷のかかる処理で、ディスクからデータを読み込むためのI/Oはもちろんのこと、圧縮のためにCPUのリソースを多く使用します。高負荷になるのが心配だという場合は、初期化パラメータのinmemory_max_populate_serversでワーカー・プロセスの数を変更することができます。

OS上からワーカー・プロセスが消えたら、ポピュレーションは完了です。今回は約70GBのテーブルをポピュレーションするのに4分かかりました。ポピュレーションの進捗やステータスは「V$IM」で始まるディクショナリ・ビューから参照できます。

ディクショナリ・ビュー


インメモリで全件検索した時の性能は?


ポピュレーションが完了したので、早速Oracle Database In-Memoryの性能を測ってみます。最初に実行するのは、6億行あるLINEORDER表への全件検索です。今回は以下のパターンで結果を取得し、比較していきます。

まずは従来のOracle Databaseで全件検索を実行します。今回は索引を作成しておらず、かつデータが6億行と膨大なため、ディスクにアクセスした場合は4分49秒、バッファ・キャッシュの場合は54秒かかりました。

全件検索


続いて、Enterprise Editionの機能であるインメモリ・パラレルクエリを使用して同様のSQLを実行します。今回は64並列で処理を行うことにより、3.6秒まで処理時間を短縮できました。

インメモリ・パラレルクエリ


最後に、Oracle Database In-Memoryで全件検索を実行します。

Oracle Database In-Memory


なんと、0.1秒で検索結果が返ってきました!!

今回実行したSQLはlo_ordertotalprice列だけを対象としているため、カラム型の効果が出やすいのですが、これまでの結果と比べて桁違いのスピードです。実行計画を見ると、これまでとは異なり「TABLE ACCESS INMEMORY FULL」と表示されています。統計のphysical readsが0になっており、一切ディスクにアクセスせずメモリ上で処理できていることが分かります(実は更に高速化の秘密があるのですが、それは後述します)。

実行計画


全4パターンの結果をまとめると、改めてOracle Database In-Memoryの速さが分かります。ディスクにアクセスした場合と比べて数千倍、バッファ・キャッシュと比べても数十倍高速化できており、分析系の性能に課題を持つシステムには非常に効果のある新機能と言えます。

全件検索の検証結果

表2:全件検索の検証結果

インメモリで一意検索した時の性能は?


Oracle Database In-Memoryの特徴のひとつに、「索引を削除することで更新性能が上がる」というものがあります。インメモリ+カラム型によって検索処理が高速になるため、索引が不要になるという意味なのですが、チューニングの要とも言える索引を削除して本当に大丈夫なのかが気になります。

そこで、索引が得意とする一意検索の性能を測ってみます。6億行あるLINEORDER表から1件のデータを取り出すのにどのくらいかかるのか、以下のパターンと比較していきます。

まずは従来のOracle Databaseで性能を測ります。該当列に索引がない場合は当然ながら全件検索になるため、4分47秒と時間がかかりますが、索引がある場合は0.03秒にまで短縮されます。

索引がない場合


次にOracle Database In-Memoryで同じSQLを実行します。

索引がない場合


結果は索引がある場合と同じ0.03秒でした。この性能であれば、更新速度を上げるために索引を削除するということも十分視野に入れることができます。しかし、実行計画を見るとTABLE ACCESS INMEMORY FULLになっており、1件のデータを検索するのに6億行すべてにアクセスするのは効率が悪いのでは?と思ってしまいます。

実は、インメモリ・カラムストア内のデータは「IMCU(In-Memory Compression Unit)」という単位で区切られており、さらにすべての列の最大値と最小値を記録する「ストレージ索引」が存在しています。以下のようにWHERE句の条件と最大値、最小値を照合することで、アクセスするIMCUを絞り込むことができるため、従来の索引がなくても高速に処理が行えます。最初に実施したMAX関数を使用した全件検索が高速だったのも、ストレージ索引のおかげです。

IMCUとストレージ索引

図3:IMCUとストレージ索引

ただし、ストレージ索引があるからといってすべての索引が不要になるわけではありません。今回試したようなOLTPでよく使われるシンプルな一意検索では、あえてOracle Database In-Memoryを使わずとも従来の索引だけで十分な性能が出ます。実行計画をよく見るとOracle Database In-Memoryの方がコスト的には高くなっているので、この場合は索引アクセスのほうが適切と言えます。

実行計画を決めるのはあくまでオプティマイザであるため、Oracle Database In-Memoryを使用した場合でも、従来の索引アクセスが選択される場合があります。索引の削除を検討するにあたっては、インメモリ化することによって必要以上にコストが高くなりすぎないか、十分に確認することが重要です。

次回は結合を含む検索処理について、Oracle Database In-Memoryの性能を検証します。


関 俊洋(Toshihiro Seki)

アシスト:関 俊洋

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

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

関の紹介記事はこちら

「既存の概念を覆す!Oracle Database In-Memoryのテクノロジー」
連載記事一覧はこちら

関連製品/サービス


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

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



ページの先頭へ戻る