50
Oracle Database 12c：インメモリー・アーキテクチャ
Oracleは、前述の2つの基本的な法則を認識しています。また顧 客にも認識してほしいと思っています。しかし、Oracleは顧客が 飛べるように支援することも望んでいます。支援を現実にするた めに、Oracle Database 12cのインメモリー・オプションは、デュ アル・フォーマットのデータ・ストアをベースにしています。
• データは永続的にディスクに保存されます。しかも行形式での みで保存されます。
• データは、読取り/書込み操作（データ操作）で要求されるたび に、従来の行ストア（バッファ・キャッシュ）にロードされます。
• データが読取り専用操作で要求されると、データは新しいイン メモリー・列ストアにロードされます。これには、行から列形式へ
の変換が含まれます。
• 挿入、更新、削除を含むトランザクションのコミットごとに、新し いデータが行ストアとインメモリー・列ストアの両方に即時にし かも同時に反映されます。したがって、両方のストアにはトラン ザクションに関する一貫性があります。
このアプローチは、必ずしも大きいメモリーを必要としません。
両方のストアに同じデータを入力する必要もありません。OLTP で使用される場合、データは列ストアに入力されません。DSSの みで使用される場合、データは行ストアに保持されません。ま た（すぐにわかるように）、インメモリー・列ストアに入力される データは、表データのサブセットに限定することができます。
このアプローチには、顧客にとって多くの重要なメリットがあり ます。
• アプリケーションを変更する必要がありません。すべての既存 のアプリケーションを変更なしで新しいアーキテクチャで実行 できます。
• データベースを変更する必要はありません。Oracle Database 12cのインメモリー・オプションは、データベースの移行または 表の再構成なしで実装できます。
• データベースまたは表のサイズに制限がありません。Oracle Database 12cのインメモリー・オプションは、あらゆるサイズ のデータベースおよびシステムと併用できます。
• したがって、インフラの変更も必要ありません。新しいインメモ リー機能を既存のハードウェアに実装できます。
最初の法則では、実際に、ディスク・ベースおよび行ベースの データベース・テクノロジとメモリー・ベースおよび列ベースのテ クノロジを1つの製品に結合することがなぜ努力に値するか説 明します。私たちのテクノロジがあらゆるタイプのトランザクショ ンを最適に処理できる場合、組合せはまったく意味をなしませ ん。ここでは、「重力」は次のことを意味します。OLTPとDSSを1つ の製品/システムで統合することが目標であるならば、列型のみ のアーキテクチャでは可能性がありません。
第2の法則は、最新のインメモリー・データベース・システムでさ え従来のコンピュータ上で動作し、ディスク・ストレージを使用す る必要があります。これが、2つ目の「重力」です。
様々なベンダーのマーケティング・チームはこれを異なった方法 で表現します。一部のチームは、行形式とディスク・ストレージの サポートを黙って追加しながら、主にインメモリー・カラム・コン ピューティングについて語ります。他のチームは、インメモリー・
コンピューティングとは従来のディスク・ベースのコンピューティ ングの拡張機能だと言います。ただし、どちらの場合も真意は、
「私たちは飛びたいけれど、重力を無視できません」ということ です。
図1: Oracle 12c– デュアル・フォーマットのインメモリー・データベース
51
より精度の高い制御
簡単なスタートをベースに様々な状況に対応できます。Oracle の顧客が求めているのは、まさにこれです。また、Oracleの顧 客は、特殊なケースでの精度の高い制御とチューニングを可 能にするメカニズムも求めています。Oracle Database 12cの インメモリー・オプションは、顧客が求めるメカニズムを提供し ます。次に3つの例を見てみましょう。
（1）Oracle Database 12cのインメモリー・オプションを使用 する場合にも、すべてのデータはディスクに行形式で保存 されます。これは、ALTER TABLE文によって変更されるこ とはありません。また表データがインメモリー列ストアに入 力されることもありません。この文は、ある時点で表データ をインメモリー列ストアで使用可能にしたいと、データ ベースに伝達しているだけです。
しかし、どの時点でしょうか。この質問に対する答えとして、2つ の基本的なオプションが使用できます。（a）オンデマンド、また は（b）データベース・システムの起動時。オプション（a）はデ フォルトです。表データは、クエリーによって最初に参照された ときに、インメモリー列ストアに入力されます（図2、表T2およ びT3を参照）。この動作が適切でない場合、データベース管 理者はジョブをデータベース・サーバーの起動中に実行する よう指定できます（図2、表T1を参照）。これらのオプションを 組み合せて使用すると、入力の作業時間を分散できます。
• Oracleのインメモリー・オプションは、表圧縮、表の暗号化、表 のパーティショニングなど、Oracle Databaseの他のオプション 機能に完全に対応しています。また、Real Application Clusters
（RAC）が提供するスケールアウト・アーキテクチャ、および既 存のすべての高可用性テクノロジ（Data Guardなど）にも対応 しています。これらの機能は、インメモリー・オプションの使用 の有無にかかわらず、同じように動作します。
• 顧客は、新しいアーキテクチャを実装する方法を決定できま す。顧客が革命を求める場合:新しいハードウェアを購入して、
インメモリー列ストアにできるかぎり多くの表を保存すること を望むならば、これは可能です。これに対し、顧客が、むしろ進 化を選ぶ場合:既存のハードウェアのままでインメモリー列スト アにいくつかの表を保存して様子を見ることを望むならば、こ れも可能です。
簡単なスタート
メリットはもう1つあります。Oracleは、インメモリー・オプションを 簡単に起動できるようにしました。必要な作業は次のとおりです。
• 初期化パラメータinmemory_sizeに新しい値を割り当て、イン メモリー列ストアのサイズを定義します。
• インメモリー列ストアで使用可能にする表を選択します。
ALTER TABLE T1 INMEMORY;
これだけです。
図2: インメモリー列ストアの入力
Oracle Database 12c インメモリー・オプション
52
Database In-Memory Optionにより、異なった表の列に異なっ たインメモリーの特性を指定して除外できます。
最初のレッスンで学んだこと
サブセット構築に関する私たちの説明は簡単ですが、はっきりし ていることはOracle Database 12cのインメモリー・オプション が特定の概念に基づいているということです。必ずしも他のす べてのインメモリー・データベース製品が同じ概念に基づいて いるとは限りません。「インメモリー・データベース」がすべての データはメモリーに保存される必要があるという意味だと仮定 した場合、またOracle Database 12cのインメモリー・オプション を貧弱なHANAと同じと考えた場合、この新しい機能を実装しよ うとする試みはすべて失敗します。成功の鍵は、HANAとOracle Database 12cの間の根本的な違いに気がつくことです。
SAPとOracleは、次の2つの声明で同 意しています。最初の声明については すでに説明しました。それは、現在の研 究開発の目標を定義します。行ベース および列ベースのテクノロジを1つの 製品に結合することは道理にかなって います。顧客がOLTPとDSSを1つのシ ステムに結合し、完全に新しいアプリ ケーションを開発できるからです。2番 目の声明は、ハードウェアおよびハー ドウェア・ベンダーによる過去10年間 の進歩についてです。現在入手可能な ハードウェアにより、一体化したOLTP/DSSシステムを構築する ことができます。このような組合せは、20年前にはまったくの考 えられないことでしたが、現在のハードウェアは様々なアークテ クチャに対応できる十分なパワーが備えられています。
しかし、2社の合意点は、まったく異なった2つのアプローチを表 面化させました。SAPは、ハードウェア・ベンダーによる進歩に関 する意見を次のように説明しています。「メモリーが非常に安価 になったため、データベース全体をメモリーに収めることができ ます。」Oracleは、この意見は短絡的であり、現在使用可能なオプ ションを自然に制限すると考えています。Oracleの意見は、次の ように要約できます。「多数の異なった分野で目覚ましい進歩が あるため、1つのテクノロジだけに制限することは意味がありま せん。
（2）表には、過去に使用された（ILM用語では「コールド」）データ が含まれている場合があります。更新されることもなく、クエ リーによるアクセスもないデータを含む表が非常に大きい 場合、インメモリー列ストアに完全に保存することはメモリー の浪費になります。管理者は、入力プロセスをDSSクエリーが 本当に必要とするデータに制限したいと考えるでしょう。
INMEMORY属性は、表レベルだけではなくパーティションまた はサブパーティション・レベルでも指定できるため、管理者はこ れを表のパーティショニングと組合せて実行できます（図3、左側 を参照）。表が有効な方法（月別など）でパーティショニングされ ている場合は、内部構造を使用して表データの水平サブセット を定義し、インメモリー列ストアに保持できます。
（3）CUSTOMERS表には、列に分類された通常のデータ（名前、
郵便番号、市など）、さらに、販売担当者が顧客固有のコメン トの保存に使用する、テキスト文字列が含まれている場合が あります（図3、右側、列C5を参照）。この列のデータは非構造 化データで、異なった長さの一意の値で構成され、ほぼ確実 にDSSクエリーに関連していません。
この場合にも、データベース管理者は、インメモリー列ストアに 保存するデータを制限したいと考えるかもしれませんが、この場 合に必要なのは、表データの垂直サブセットを定義すること、つ まり、複数の列を入力プロセスから除外することです。Oracle 図3: 水平サブセットと垂直サブセットの定義