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

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

前回はOracle Database In-Memoryで全件検索と一意検索を実行し、従来のアクセス方法と比べて数十倍の性能になっていることを確認しました。今回は結合処理などもう少し踏み込んだパターンについて、動作のポイントを紹介します。

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

カラム型の効果が期待できる処理


前回は全件検索と一意検索を試しながら、インメモリ・カラムストアの中にストレージ索引という独自の仕組みがあることを紹介しました。今回はより現実的な性能を計測するために、多数の表を結合する分析系のクエリを実行していきます。

検証に使用するのは、前回と同じくStar Schema Benchmarkです。Star Schema BenchmarkはDWHの代表的なデータ・モデルであるスター・スキーマを採用しており、ファクト表であるLINEORDER表を中心に、放射状にディメンション表が配置されています。

LINEORDER表には商品の購入履歴(明細データ)が約6億件格納されており、ディメンション表にはマスター・データ(分析軸)となる顧客IDや商品IDなどの情報が少ない件数で格納されています。LINEORDER表の列は大半がNUMBER型で、顧客名や商品名といった文字列ではなくIDのみが記録されています。何度も出てくる情報を文字列からID(番号)にすることで表のサイズを抑えられますが、分析処理においてはファクト表とディメンション表の結合が必要になります。

Star Schema Benchmarkのデータ・モデル

図1:Star Schema Benchmarkのデータ・モデル

結合のイメージを具体的なSQLで見てみましょう。以下のSQLはStar Schema Benchmarkにあらかじめ用意されているもので、1993年の売上高を特定の条件をもとに集計しています。返される結果は1件だけですが、6億件あるLINEORDER表の広範囲にアクセスし、さらにDATE1表との結合も行われるため、それなりに負荷の高いSQLであると言えます。

SQL


本来であれば、こうした「少数の列+多数の行」を扱うSQLはロー型であるOracle Databaseが苦手とする処理です。しかし、カラム型にとっては得意な処理であるため、Oracle Database In-Memoryを使うことで高速化できるはずです。

見慣れない実行計画


先ほどのSQLがどの程度高速化するのか、従来のOracle Databaseと比較してみましょう。今回は以下のパターンで結果を取得しました。

Star Schema Benchmark Query1.1の性能比較

図2:Star Schema Benchmark Query1.1の性能比較

※検証サーバのスペックや初期化パラメータについては、 前回の記事 をご参照ください。

グラフを見れば一目瞭然ですが、Oracle Database In-Memoryが桁違いの速さになっています。従来のOracle Databaseでは最速でも11秒かかっていたものが、Oracle Database In-Memoryでは0.6秒まで短くなっています。「少数の列+多数の行」を扱う処理が苦手なロー型と、得意なカラム型の差が顕著に現れた結果と言えます。

さらに、Oracle Database In-Memoryの速さにはもうひとつのポイントがあります。先ほど実行したSQLの実行計画を確認すると、何やら見慣れないオペレーションが行われていることが分かります。「JOIN FILTER」や「BF0000」とは一体何なのでしょうか?

SQL


※実行計画が見やすいよう、パラレル処理ではなくシリアル処理の結果を掲載しています。

カラム型の特性を活かした結合


SQLのチューニングに詳しい方はご存知かもしれませんが、実は「JOIN FILTER」や「BF0000」といった情報が実行計画に出力されるのはOracle Database In-Memoryが初めてではありません。「BF0000」はブルーム・フィルタというOracle Database 10g Release 2から実装されていた処理で、結合の前に対象となるレコードを絞り込むという働きをします。

※ブルーム・フィルタは考案者であるBurton Bloom氏にちなんで名付けられた確率的データ構造のことで、Oracle Databaseの機能名ではありません。

ブルーム・フィルタは、これまでパーティション表の結合において不要なパーティションを排除する場合などに使われてきましたが、Oracle Database In-Memoryではカラム型の特性を活かして結合するレコードを絞り込むことができます。以下のようにカラム検索を使用して結合する列にフィルタを作成し、条件に合うものだけを抽出することで結合処理が高速になります。

Oracle Database In-Memoryの結合処理

図3:Oracle Database In-Memoryの結合処理

改めて、先ほどの実行計画を確認してみましょう。ここではDATE1表とLINEORDER表のハッシュ結合を行っていますが、サイズの小さいDATE1表のスキャン(①)においてブルーム・フィルタが作成されており、それをサイズの大きいLINEORDER表のスキャン(②)で使用しています。③を見ると、WHERE句で指定したものに加えて「SYS_OP_BLOOM_FILTER(:BF0000,"LO_ORDERDATE"))」という条件でも絞り込みが行われているのが分かります。つまり、WHERE句で絞り込んだレコードのうち、対象になるものだけをフィルタリングしてから結合しているのです。

ブルーム・フィルタが使用された場合の実行計画

図4:ブルーム・フィルタが使用された場合の実行計画

※実行計画が見やすいよう掲載内容を調整しています

このようなブルーム・フィルタの動作によって、Oracle Database In-Memoryの結合処理では従来と比べて数倍速い時間で結果を返すことができます。

ブルーム・フィルタの有無による性能差


ブルーム・フィルタの効果を分かりやすく測定するため、今度はOracle Database In-Memoryでブルーム・フィルタを有効にした場合と無効にした場合で結果を比較してみます。なお、Oracle Database 12cではブルーム・フィルタがデフォルトで有効になっているため、今回の検証では隠しパラメータを変更して無効化しています。SELECT文はこれまでと同じものを使用します。

ブルーム・フィルタの有無による性能差

ブルーム・フィルタの有無による性能差

パラレル度を変えながら複数パターンで試してみましたが、どのパターンでもおよそ2~3倍程度性能が向上することが分かりました。Oracle Database In-Memoryでは特別な設定を必要とせず自動的にブルーム・フィルタが使用されるため、こうした検証でもしない限り効果を計ることはできませんが、数字を見ると性能向上に大きく貢献していることが分かります。

SQLトレースを見ると、ブルーム・フィルタがない場合は78552553行を処理しているのに対し、ブルーム・フィルタがある場合はおよそ1/6となる11915774行だけで済んでいます。この違いが2~3倍という性能向上に繋がっているのです。

SQL


Oracle Database In-Memoryは単純にインメモリだから速いというだけではなく、こうした工夫もしっかりと考えられているのが面白いところです。性能評価や試使用を行う際には、こうした実行計画の違いに目を向けてみてはいかがでしょうか。


関 俊洋(Toshihiro Seki)

アシスト:関 俊洋

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

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

関の紹介記事はこちら

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

関連製品/サービス


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

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



ページの先頭へ戻る