Database Support Blog

  • Oracle Database
2014.10.16

既存の概念を覆す!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は単純にインメモリだから速いというだけではなく、こうした工夫もしっかりと考えられているのが面白いところです。性能評価や試使用を行う際には、こうした実行計画の違いに目を向けてみてはいかがでしょうか。


連載記事

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


執筆者のご紹介

アシスト関 俊洋

関 俊洋
クラウド技術本部

2006年入社。データベース・システムの構築や運用トラブルの解決といった業務を経験し、その後新製品の検証やソリューションの立ち上げを経てエバンジェリストへ。2016年にクラウド事業を立ち上げ、現在はクラウドとデータベースの二足の草鞋を履いている。...show more

本記事をご覧いただいている方へのご案内

最後までご覧いただきありがとうございました。
本記事でご紹介した製品・サービスに関するコンテンツをご用意しています。また、この記事の他にも、IT技術情報に関する執筆記事を多数公開しておりますのでぜひご覧ください。


■本記事の内容について
 本記事に示した定義及び条件は変更される場合があります。あらかじめご了承ください。

■商標に関して
 ・Oracle®、Java、MySQL及びNetSuiteは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。
 ・Amazon Web Services、AWS、Powered by AWS ロゴ、[およびかかる資料で使用されるその他の AWS 商標] は、Amazon.com, Inc. またはその関連会社の商標です。
  文中の社名、商品名等は各社の商標または登録商標である場合があります。

関連している記事

  • Oracle Database
2024.04.08

【Oracle Database】FAQで安定運用に貢献!サポートセンターのナレッジ公開の取り組み

アシストオラクルサポートセンターが公開しているFAQは、仕様に関するQAやエラー発生時の対処方法などはもちろん、不具合情報や障害発生時の情報取得方法といった安定運用に役立つ内容も扱っています。そのFAQをどのように作成しているのか、サポートセンターの取り組みをご紹介します。

  • Oracle Cloud
  • Oracle Database
2024.02.02

OCIにおけるOracle Database 11g R2、12g R1、12g R2の新規プロビジョニング終了とその影響

Oracle Databaseのバージョン11g R2、12g.R1、12g.R2は既にすべてのメーカーサポートが終了しています。OCIのBase Database Serviceでも2024年1月中旬ころから11g R2、12g R1、12g R2での新規プロビジョニングができなくなりました。

  • Oracle Database
  • その他
2023.12.21

【Oracle Database】サポートセンターでの生成AI(Glean)活用

アシストでは全社員にAIアシスタントGleanを導入しました。サポートセンターで2ヶ月間使ってみて感じた効果やメリットをお伝えします。

ページの先頭へ戻る