Database Support Blog

  • Oracle Database
2017.03.06

さらに使いやすく!Oracle Database 12cR2のDatabase In-Memory

さらに使いやすく!Oracle Database 12cR2のDatabase In-Memory

こちらでOracle Database 12c Release 2(以下、12cR2)のマルチテナントについて紹介しました。今回はOracle Database In-Memory(以下、Database In-Memory)です。インメモリ技術によって分析処理を高速化するDatabase In-Memoryも12cR2で進化し、より使い勝手が良くなりました。Oracle Database 12c Release 1(以下、12cR1)から12cR2への変更点をBefore/Afterで整理して解説します。





Database In-Memoryは12cR1のPSR12.1.0.2から提供されている機能です。従来の行フォーマットでデータを保持するバッファ・キャッシュに加え、列フォーマットでデータを保持する「インメモリ・カラムストア」という新しいメモリ領域を展開します。このメモリ領域にデータを列フォーマットで保持することで、大量データの分析クエリを高速に処理できます。

図1:Oracle Database In-Memoryの概要

図1:Oracle Database In-Memoryの概要

バッファ・キャッシュには直近で使用されたデータや、使用頻度の高いデータがデータ・ブロック単位で格納され、使用頻度の低いデータはメモリから除外されます。一方、インメモリ・カラムストアにはあらかじめ指定したオブジェクトのみが格納されます。分析で利用される大規模なデータを確実にメモリに展開し、かつ列フォーマットを採用することで高速な参照処理を可能にします。

※以下の記事で詳細なアーキテクチャや検証結果を解説していますので、併せてご参照ください。

このように唯一無二のアーキテクチャで構成されるDatabase In-Memoryは、マルチテナントと同様、日本国内では12cR2の普及に合わせ急速に展開されていくものと予測されます。また、近年のOracle OpenWorldの講演から、将来のOracle Databaseを語る上でDatabase In-Memoryが重要な位置づけにあることがわかります。

図2:Database In-Memoryに関するOracle OpenWorldでの発表

図2:Database In-Memoryに関するOracle OpenWorldでの発表

2014年のDatabase In-Memoryリリースに続き、2015年のOpenWorldでは「Software in Silicon」と呼ばれる、チップ内でSQLを処理する技術を搭載したSPARC M7が発表されました。インメモリになると、ボトルネックがディスクI/OからCPUに移るので、“如何にCPUを効率よく回してデータベースを速くするか!”という観点で開発されています。

そして2016年のOpenWorldでは12cR2のリリースが発表され、具体的な内容は後述しますが、Database In-Memoryも大きく進化しています。

また、「Non-Volatile Memory is Coming」という発表の中で、「不揮発性メモリの開発に着手していて、2018年には提供を開始する。既にOracle Databaseへの対応も開発中」というアナウンスがされました。従来から“如何にディスクI/Oを減らして効率を上げるか”と考えられてきたデータベースの仕組みが、不揮発性メモリの登場で根本的に変わります。Oracle Databaseはディスクベースからインメモリデータベースへ移り変わる流れの中で、ソフトウェアとハードウェアの両面から着々とピースを揃えてきています。その中でも、Database In-Memoryはデータベースエンジニアにとって重要な1ピースと言えるでしょう。

メモリサイズの動的変更やインメモリ化オブジェクトの自動管理など…運用管理が楽になった!


Database In-Memoryの1つの特徴は「使い始めのステップが簡単」なことです。まず、インメモリ・カラムストアを初期化パラメータINMEMORY_SIZEで設定します。その後、インメモリ化するオブジェクトを指定します。テーブルや一部の列、パーティションなど指定できますが、テーブルの場合は

と実行するだけで設定可能です。最後に、指定したオブジェクトをインメモリ・カラムストアに展開する“ポピュレーション”を行って完了。たったこれだけのステップでDatabase In-Memoryは使い始められます。

図3:Database In-Memoryを使い始めるまでの3ステップ

図3:Database In-Memoryを使い始めるまでの3ステップ

使い始めが簡単なDatabase In-Memoryですが、12cR1では以下の難点もありました。

  • インメモリ・カラムストアは静的に確保される
  • オブジェクトのインメモリ属性の有効化や無効化は、全て手動

これらの点が、12cR2で改善されています。

動的なサイズ変更が可能になったインメモリ・カラムストア


12cR1までインメモリ・カラムストアのサイズ変更には、データベースの再起動が必要でした。データベースを停止すると、インメモリ・カラムストアに展開していたデータも無くなるため、データベース再起動後はもう一度ポピュレーションし直さねばならずたとえ、データベースの起動・停止が自由に可能な環境だったとしても、使い勝手の悪いものでした。それが、12cR2からはデータベースを起動したままインメモリ・カラムストアのサイズ変更が可能となり、データ量の増加に合わせてメモリを柔軟に拡張できるようになりました。

図4:12cR1と12cR2でのインメモリ・カラムストアの変更点

図4:12cR1と12cR2でのインメモリ・カラムストアの変更点

ただし、メモリサイズは拡張できても縮小はできない等の制限もあるため注意が必要です。また、インメモリ・カラムストアはSGA内に展開されますが、自動メモリ管理の対象とはならないので、データベース管理者がサイジングを行わなければなりません。サイジングのポイントは以下の2つです。インメモリ・カラムストアに格納した時のサイズはデータによって異なるため、事前の検証をお勧めします。

  • INMEMORY_SIZEの20~30%は管理用領域として確保される
  • データは列フォーマット変換と圧縮が施されるので、インメモリ・カラムストア上には1/2~1/20のサイズで格納される

図5:インメモリ・カラムストアの構成

図5:インメモリ・カラムストアの構成


インメモリ・カラムストア内のデータ管理自動化で運用の手間が省ける!


Database In-Memoryを使っていくと、「アクセス頻度の少ないテーブルはインメモリ・カラムストアから除外したい」とか、「直近1ヵ月分のパーティションだけインメモリ化したい」といった、運用上の要望が出てくるでしょう。12cR1まで、これらの作業は全てデータベース管理者が手動で実行しなければなりませんでしたが、12cR2ではAutomatic Data Optimization(自動データ最適化、以下ADO)とHeat Mapと呼ばれる2つの機能により大きく改善されました。

実はこの2つの機能は12cR1から実装されています。ADOは管理者が定義したポリシーに従ってデータの移動などを自動で実行する機能で、ポリシーには、何を、いつ、どんな条件で、どうするか、という内容を指定できます。例えば、アクセスが一定期間無かったデータは圧縮して配置する、などの操作が自動で行えます。またこの例での「アクセスが一定期間無かった」等のアクセス情報を記録する機能が、Heat Mapです。Heat Mapは表やセグメントなどのOracle Databaseの論理単位ごとに、データへのアクセス頻度等を記録します。

図6:ADOとHeat Mapの概要

図6:ADOとHeat Mapの概要

これらの機能が12cR2で拡張され、Database In-Memoryに対応しました。「アクセスが少なくなったオブジェクトはインメモリ・カラムストアから除外する」など、条件とそれに伴う動作の自動化が可能となったことで、データベース管理者が定期的に手動で行うタスクは削減され、運用の手間も大きく軽減されます。

図7:12cR1と12cR2でのインメモリ・カラムストア管理方法の変更点

図7:12cR1と12cR2でのインメモリ・カラムストア管理方法の変更点

このように、Database In-Memoryの使い勝手は12cR2で格段に向上しています。

インメモリにしたらCPUがボトルネックに…そんな分析クエリをCPUの追加なく高速化する新機能


ここまではセットアップや運用のフェーズでしたが、次は分析クエリを実行するフェーズでの新機能をご紹介します。

12cR1のDatabase In-Memoryでも分析クエリを高速に処理することはできましたが、CPUがボトルネックとなるクエリの場合、その効果を十分に発揮することができませんでした。搭載するCPU数を増やせばいいのか、と言っても、ハードウェア費用とライセンス費用が必要となるため簡単な話ではありません。そこで、12cR2からはCPUを消費する演算や結合の効率を上げる機能が追加されています。

高度な分析クエリの中には複雑な計算式を含むものもあります。12cR1では、インメモリの効果でデータアクセスが早くなっても、演算処理を行うCPUがボトルネックになってしまうという課題がありましたが、12cR2では、演算結果をあらかじめ仮想列に格納し、その仮想列をインメモリ・カラムストアに展開することで処理を高速化するIn-Memory Expressions機能が追加されました。

図8:In-Memory Expressions機能の概要図

図8:In-Memory Expressions機能の概要図

これでCPU負荷の高い演算処理を参照の都度行わずに済むので、CPUボトルネックが緩和されます。高度な計算処理を行う環境でお勧めの機能です。

12cR1のDatabase In-Memoryでも結合処理に対しては、ブルーム・フィルタと呼ばれる機能で高速化を実現していました。しかし、クエリによってはブルーム・フィルタが適用されずデータの解凍やハッシュ結合でCPUを多く消費してしまうケースがありました。

※ブルーム・フィルタは考案者であるBurton Bloom氏にちなんで名付けられた確率的データ構造のことで、Oracle Databaseの機能名ではありません。また、12cR1からの新機能ではありません。詳細はこちらで紹介しています。

そこで12cR2からは、結合する列同士であらかじめ圧縮値を共有しクエリで利用するジョイン・グループ機能が追加されました。結合列同士が同じ圧縮値を持つので、解凍とハッシュ結合のオーバーヘッドを軽減できます。

図9:ジョイン・グループ機能の概要図

図9:ジョイン・グループ機能の概要図

ただし、ジョイン・グループはCREATE INMEMORY JOIN GROUP文により事前に手動で作成しておく必要があります。自動では作成されないのでご注意ください。

12cR2の目玉!In-Memory on Active Data Guard


最後に12cR2での目玉とも言えるIn-Memory on Active Data Guardをご紹介します。そもそもDatabase In-Memoryでは、更新処理が行われると図10のように動作します。

図10:Database In-Memoryで更新直後のデータを分析できる仕組み

図10:Database In-Memoryで更新直後のデータを分析できる仕組み

この仕組みによりリアルタイム分析が可能となりますが、図の中の3つ目のステップで、更新時にインメモリ・カラムストアの情報を無効化する処理が増えるため、更新系の処理への影響が懸念されます。この点を12cR1で検証した結果、高負荷環境になると更新処理のスループットが十数%低下するという結果となりました。また、この更新時のオーバーヘッドの課題は、バンドルパッチレベルで改善され、12cR2での更新時のオーバーヘッドは数%まで改善しています。

こちらで詳しくご紹介しています。

ミッションクリティカルなシステムでトランザクション処理と分析処理を分散させたいが、分析データの鮮度は高めたいという要件がある場合、12cRcからActive Data GuardのスタンバイDBでDatabase In-Memoryが利用できるようになりました。これでプライマリDBの更新処理に影響を与えることなく、鮮度の高いオンライン分析が可能となり、分析基盤と災害対策基盤を同時に実現することにつながります。また、スタンバイDBのリソースを有効活用できる点も大きなメリットと言えるでしょう。

図11:In-Memory on Active Data Guardの概要図

図11:In-Memory on Active Data Guardの概要図

さらに、スタンバイDBはOracle Cloud上にも構築できます。クラウド環境を活用してリアルタイム分析基盤が構築できないか検討される場合、選択肢の1つとなるはずです。

今回紹介した機能の他にも、Database In-Memoryには数多くの新機能が追加されており、より使いやすく、より効果的になりました。「ちょっと検証してみようかな」と思われた方には、前回ご紹介したExadata Express Cloud ServiceやDatabase Cloud Serviceがお勧めです。ハードウェアの調達なしで簡単に最新のOracle Database環境を手に入れることができます。また、時間単位の課金で利用できるため、短期間のテストならコストメリットも大きくなります。

12cR2へのバージョンアップをご検討の方は是非アシストまでご相談ください。


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

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


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

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

関連している記事

  • 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ヶ月間使ってみて感じた効果やメリットをお伝えします。

  • Oracle Database
  • Oracle Cloud
2023.12.15

ライセンスの観点から考えるOracle Cloudのススメ

オラクル社が提供しているクラウドサービス「Oracle Cloud」は、Oracle Databaseライセンス観点でも様々な効果があることはご存じでしょうか? ここでは「ライセンス」に焦点をあて、Oracle Cloudがおススメできるポイントを説明します。

ページの先頭へ戻る