Oracle In-Memory Database CacheによるOracleデー …...Oracle In-Memory Database Cache によるOracle データベースの迅速化 1. はじめに Oracle TimesTenは、ビジネス･プロセスを高速化し、リアルタイムなビジネス・インテリジェンスを可能にし、顧客が使用するアプリケーションの

Oracle テクニカル・ホワイト・ペーパー 2009 年 7 月

Oracle In-Memory Database Cache によるOracle データベースの高速化

Oracle In-Memory Database Cache による Oracle データベースの迅速化

......................................................................................................................... 2 1. はじめに

................................................................................. 4 2. アプリケーション層のキャッシュ

.......................................................................... 5 3. Oracle TimesTen In-Memory Database

........................................................................... 8 3.1 Oracle TimeTenのパフォーマンス

.................................... 8 4. Oracle In-Memory Database Cacheによるデータ・キャッシュ

........................................................................... 10 4.1 キャッシュのコンテンツの定義

.....................................................................11 4.2 データのロードとキャッシュの管理

................................................................ 12 4.3 キャッシュ・グリッド間のデータ共有

............................................................................................. 13 4.4 データ整合性の維持

................................................................................................................ 18 4.5 高可用性

............................................................................................................ 21 5. パフォーマンス

.................................................................................................................................. 23 6. 例

.......................................................................................... 23 6.1 読取り専用キャッシュ

....................................... 24 6.2 読取り専用スライディング・ウィンドウ・キャッシュ

.......................................................................................... 24 6.3 更新可能なキャッシュ

................................................................................... 25 6.4 更新可能な動的キャッシュ

............................................................. 25 6.5 不均等な到着率のデータ取得キャッシュ

............................................................. 26 6.6 到着率が常に高いデータ取得キャッシュ

.................................................................... 27 6.7 更新可能なユーザー管理キャッシュ

........................................................................... 27 6.8 読取り専用動的分散キャッシュ

.............................................................................................................................. 27 7. 結論

....................................................................................................................... 28 8. 参考資料


1. はじめに Oracle TimesTen は、ビジネス･プロセスを高速化し、リアルタイムなビジネス・インテリジェンスを可能にし、顧客が使用するアプリケーションの

パーソナライズを容易にします。

Oracle In-Memory Database Cache（Oracle IMDB Cache）は、パフォーマンスを重視するOracleデー

タベースのサブセットをアプリケーション層でキャッシュするための理想的なOracle Database製品

オプションです。Oracle IMDB Cacheの使用により、アプリケーションの応答時間およびスループッ

トが向上します。Oracle IMDB Cacheは、3 つの主要なテクノロジー・コンポーネントで構成されて

います。アプリケーション層のリアルタイム・データ管理を行うOracle TimesTen In-Memory

Database（Oracle TimesTen）、頻繁にアクセスされる表をOracle Databaseサーバーからアプリケー

ション層へキャッシュし、キャッシュされたデータの整合性を維持するキャッシュ・テクノロジー、

そして層間の高可用性を保証するトランザクション・データ・レプリケーション・コンポーネント

です。

Oracle TimesTen は、メモリに最適化したリレーショナル・データベースであり、パフォーマンス

を重視するシステムに非常に短い応答時間と高いスループットを提供します。アプリケーションに

近いアプリケーション層で実行され、アプリケーションと協調して動作することも可能です。Oracle

TimesTen データベースは、通常のデータベースとして使用することも、Oracle データベースへの

キャッシュとして使用することもできます。

アプリケーションは、Oracle TimesTen のデータベース表の作成および管理が可能で、また Oracle

IMDB Cache に Oracle Database の頻繁にアクセスされるサブセットをキャッシュすることが可能

です。キャッシュ表およびキャッシュではない通常の表は、同じインメモリ・データベースに共存

することが可能です。これらの表はすべて永続的でリカバリ可能です。キャッシュされているデー

タおよびキャッシュではないデータへの問合せおよび更新は、アプリケーションから ODBC、JDBC、

Oracle Call Interface（OCI）、TTClasses、Pro*C などを使用して実行された PL/SQL または SQL92

によって行われます。

キャッシュ・グリッドは、パフォーマンスおよび容量のスケーラビリティを向上させるために使用

できます。ここで 1 つのキャッシュ・グリッドは、Oracle IMDB Cache の集合によって構成され、

アプリケーションがキャッシュしたデータを一括管理します。キャッシュされたデータは、グリッ

ド・メンバーにわたって配布され、アプリケーションからみたデータの位置透過性がキャッシュ・

グリッドによって提供されるます。そのため、アプリケーションに対して、すべてのグリッド・メ

ンバーにキャッシュされているデータの集合を効果的に提供可能になります。キャッシュ・グリッ

ドにより、グリッド・メンバーのオンライン追加（および削除）を通じた増分スケーラビリティが

実現します。

2


グリッド・メンバーは、キャッシュ・グリッド・メンバー間にキャッシュされたデータと Oracle

Database の整合性を維持します。

Oracle IMDB Cache は、アプリケーション層とデータベース・サーバー層の間のデータの可用性を

管理します。これにより、障害の発生場所に関係なく、高可用性が保証され、トランザクション・

ロスがなくなります。たとえ障害がキャッシュ・ノードの 1 つ、Oracle RAC ノードの 1 つ、ネット

ワーク・レベルまたは RAC クラスタ全体で発生したとしても、高可用性およびトランザクション・

ロスの排除が保証されます。

Oracle TimesTen および Oracle IMDB Cache には、ネットワーク通信サービス、運用サポート・シ

ステム、コンタクト・センター、航空会社および予約システム、指揮統制システム、証券取引など

の、リアルタイムな企業やタイム・クリティカルな業界の本番環境において採用実績があります。

世界中で何百もの企業が本番アプリケーションにおいて Oracle TimesTen および Oracle IMDB Cache

を使用しています。おもな企業としては、Alcatel-Lucent、Amdocs、Aspect、Avaya、Bombay Stock

Exchange、Bridgewater Systems、BroadSoft、Cisco、Deutsche Börse、Ericsson、JP Morgan、NEC、

NYFIX、Smart Communications、および Sprint があります。

3


2. アプリケーション層のキャッシュ

アプリケーション層のキャッシュは通常、データ・アクセスの待機時間の短縮やバックエンド・データベースのワークロード軽減に使用されます。

データベースのアクセス・パフォーマンスを改善したり、バックエンドのデータベース・サーバー

の競合を軽減したりするため、さまざまなキャッシュ技術が開発されています。リアルタイム・ア

プリケーションや顧客が使用するアプリケーションでは、高速な応答時間が特に重要です。また、

バックエンドのデータベースのワークロードの削減が、ユーザーが増え続けているホスト型ソフト

ウェア・サービス、e コマース・サイトや通信サービスなどのアプリケーションにおいて重要となり

ます。

キャッシュする情報とその情報のキャッシュ先には、多くの選択肢があります。どの選択肢にも利

点とのトレードオフが存在します。開発済みのキャッシュ技術には次のようなものがあります。

• 問合せリザルト・キャッシュ。この技術は通常、アプリケーション層で使用され、アプリケーショ

ンからキャッシュを隠蔽する専用のソフトウェアで管理されます。このシナリオでは、データ

ベース・システムに送信された問合せの結果がキャッシュ・ソフトウェアによって自動的に保存

されます。パラメータ値が同じであるなど、その問合せが以前に送信された問合せと完全に一致

する場合は、キャッシュ・ヒットとして認識され、キャッシュからの処理が行われます。このよ

うなキャッシュは単純であり、同じ問合せが繰返し送信されるようなアクセス・シナリオにも対

応できる点が優れています。ただし、キャッシュのコンテンツでは問合せ処理ができないため、

範囲が制限されています。

• オブジェクト・リレーショナル・マッピング・ツール・キャッシュ。オブジェクト・リレーショ

ナル・マッピング・ツール（O/Rマッピング・ツール）では、オブジェクトとリレーショナル・

データとのマッピングが透過的になるため、オブジェクト指向のプログラマーからはリレーショ

ナル・データベースが隠蔽されます。リレーショナル・データをオブジェクト表現にマッピング

すると、そのデータが不要になるか古くなるまで、O/Rマッピング・ツールによってキャッシュ

されます。O/Rマッピング・ツールによるキャッシュは、プログラミング言語のオブジェクト・

モデルとデータベースのリレーショナル・モデルとのマッピングのコストが増大することを防ぐ

ための一般的な技術です。

• オブジェクト・キャッシュ。ここでは、キャッシュという呼び名はいくらか誤りがあります。こ

のキャッシュに格納されるオブジェクトは必ずしも別の場所に保存されたオブジェクトのサブセッ

トではないためです。このような"キャッシュ"は、オブジェクトの発生元から独立したオブジェ

クトのリポジトリです。通常は、アプリケーションに対して透過的ではありません。アプリケー

ションでは、キャッシュのオブジェクトに対して"配置"、"取得"、"挿入"および"削除"を行います。

市場にはそのようなキャッシュを提供する製品がいくつかあり、サポートされる機能のレベルは

様々です。キャッシュは完全にメモリに常駐する場合もあれば、ディスクや別のデータ管理シス

テムに戻される場合もあります。並行処理制御を提供する製品や、ネットワーク内の複数ノード

に透過的な分散を行う製品、可用性に優れた製品もあります。

4


Oracle In-Memory Database Cache のキャッシュは、フル・リレーショナルな SQL 機能、Oracle Database とのデータ整合性の自動的なメンテナン

ス、およびリアルタイムなパフォーマンスを備えています。

Oracle In-Memory Database Cache では、表または表の断片を Oracle Database からアプリケーション層

へキャッシュすることによる独自の方法が使用されます。表の断片は拡張 SQL 構文で定義され、Oracle TimesTen In-Memory Database にキャッシュされます。キャッシュされたデータは、アプリケーショ

ンによって SQL、PL/SQL または Pro*C を使用して読取り、更新が行われ、Oracle IMDB Cache によ

り、更新内容が Oracle Database からキャッシュへ、またはその逆方向に自動的に伝播されます。

Oracle IMDB Cache の集合は、キャッシュ・グリッドとして構成できます。キャッシュされたデータ

は、グリッド・メンバーにわたって配布され、アプリケーションから見たデータの位置透過性と並

行処理制御がキャッシュ・グリッドによって提供されます。そのため、アプリケーション対して、

すべてのグリッド・メンバーにキャッシュされるデータの集合を、効果的に提供可能です。アプリ

ケーションのパフォーマンスや容量を増加させる必要がある場合は、サービスを中断することなく

ノードをキャッシュ・グリッドに追加することが可能です。そのため、Oracle IMDB Cache によりア

プリケーションにリレーショナル・データベースのすべての汎用性と機能が提供され、位置透過性

とともにスケーラビリティが増加し、Oracle Database とのキャッシュの整合性が自動的にメンテナン

スされ、インメモリ・データベースのリアルタイムなパフォーマンスが提供されます。

Oracle IMDB Cache のアプローチには、パフォーマンス全体の改善に役立つおもな利点が 2 つあります。

1 つ目は、Oracle IMDB Cache を使用するアプリケーションにおいて、Oracle TimesTen のインメモリ・

アーキテクチャによって、応答時間が大幅に短縮されてスループットが増加し、アプリケーション

層とデータベース・サーバー間の通信がなくなる点です。2 つ目は、バックエンド・データベースの

ワークロードが軽減されるため、すべてのアプリケーションのスループット全体が向上する点です。

リアルタイムのパフォーマンス、インクリメンタル・スケーラビリティ、および自動キャッシュ管

理とともにリレーショナル・データベースのあらゆる利点を提供できる点が、Oracle IMDB Cache の

独自の機能です。Oracle IMDB Cache は、パフォーマンスを重視する Oracle データベースのサブセッ

トのキャッシュに理想的です。これにより、キャッシュされたデータの読取りも更新も可能になり、

データ整合性が自動的に管理されるようになります。

次の 2つの項では、Oracle TimesTen In-Memory Databaseを簡単に紹介し（詳細については[1]を参照）、

Oracle In-Memory Database Cache によるデータのキャッシュおよび管理方法について説明します。

キャッシュに関するシナリオもいくつか説明します。

3. Oracle TimesTen In-Memory Database

Oracle TimesTen In-Memory Database により、標準 API を使用したトランザクションでデータやリレーショナル機能にアクセスできるようになります。

Oracle TimesTen In-Memory Databaseは、メモリを適化したリレーショナル・データベースで、

Pro*C/C++に加えてODBC、JDBC、Oracle Call Interface（OCI）およびTTClasses1 APIを通じて、SQL92

1 TimesTen C++ Interface Classes（TTClasses）は、もっとも一般的なODBC機能のラッパーを提供するC++クラス・ライブラリで

す。これは、ODBCよりも使用が簡単で、迅速なパフォーマンスを維持しながらベスト・プラクティスを促進します。

5


および PL/SQL に対応します。Oracle TimesTen は、標準インタフェースおよび一般的なオラクルの

インタフェースをサポートすることによって、既存のアプリケーションによる適用を簡単にします。

Oracle TimesTen は、メイン・メモリにあるデータ上で動作しますが、Oracle TimesTen データベース

は、ソフトウェア、ハードウェアの障害、電源異常時においても永続的であり、リカバリが可能で

す。永続性は、チェックポイントおよびディスクへのロギングにより保証されます。アプリケーショ

ンのトランザクションには ACID プロパティを選択できますが、よりパフォーマンスを高めるため

の柔軟なオプションを使用することもできます。Oracle TimesTen ではコストベースの問合せオプ

ティマイザが提供され、アプリケーションによっては問合せプランを表示および変更できます。Oracle TimesTen データベースは、ライブラリとしてアプリケーションにリンクして使用することも可能で

すし、クライアント/サーバーのオプション経由で使用することも可能です。クライアント/サーバー

のオプション経由で Oracle TimesTen にアクセスすると、アプリケーションや Oracle TimesTen サー

バーが同一マシン上で実行されていたとしても、Oracle TimesTen への要求では、プロセス間通信の

オーバーヘッドが発生します。それに対し、Oracle TimesTen がアプリケーションとリンクしている

場合は、Oracle TimesTen に対して要求を行ってもローカルで呼び出されるだけで、ごくわずかなオー

バーヘッドしか発生しません。また、アプリケーションと Oracle TimesTen とでデータ転送を行って

も安価なメモリ・コピー操作しか発生しません。さらに、レプリケーションにより、可用性が向上

します。インタラクティブな SQL ユーティリティ、データベース開発およびキャッシュ構成向けグ

ラフィカル・ツール、オンライン・バックアップとリストア、バルク・ロードなど、さまざまなユー

ティリティも使用できます。データベース・メンテナンス操作は、プログラム API 経由でも行えま

す。

データベースのコピーは、実行時はメイン・メモリにあります。このデータベースは、そのデータ

ベースに接続したどのプロセスからもアクセスできる共有メモリ・セグメントで管理されます。図 1は Oracle TimesTen In-Memory Database システムのアーキテクチャを示しています。

Oracle TimesTen In-Memory Database のデータ構造とアルゴリズムは、データのメモリ領域に合わせて最適化されます。

Oracle TimesTen のデータ構造とアクセス・アルゴリズムにより、データベースのメモリ領域が検索

されるため、パフォーマンスが飛躍的に改善されます。完全にキャッシュされたディスクベースの

データベースと比較すると、メモリに適化された Oracle TimesTen のアーキテクチャでは使用され

る CPU のサイクルが格段に少なくなります。これは、メモリのバッファを管理するオーバーヘッド

や複数のデータ・ロケーション（ディスクとメモリ）のアカウントが排除されるためです。

メモリの適化により Oracle TimesTen のパフォーマンスが向上し、トランザクションのプロパティ

や永続性メカニズムが提供されます。また、システム障害からのリカバリを可能にする機能も補完

されます。ロック、マルチユーザー分離、ロギングに関してはさまざまな選択肢があり、一時的な

6


検索のキャッシュから重要なトランザクション型金融取引や通信請求システムまで、さまざまなア

プリケーション・シナリオに対応できます。

図 1：Oracle TimesTen のアーキテクチャ

Oracle TimesTen データベースは、永続的でリカバリ可能です。

Oracle TimesTen の永続性は、コミットされたトランザクションの変更をディスクにログとして記録

し、チェックポイントによって定期的にデータベースのディスク・イメージを更新することで実現

されます。ディスクがログに書込みを行うタイミングは、トランザクション終了時に同期的に行う

か、後で行うかのいずれかをアプリケーションで設定します。後で行うほうがパフォーマンスは向

上します。大抵の場合、特に通信ネットワーク内で携帯電話の位置を数秒ごとに追跡する場合など、

取引金額が低く、トランザクション・データが一時的な場合は、同期ロギングよりもスループット

が向上するほうが好まれます。

Oracle TimesTen では、アプリケーションで特定の表の変更内容を追跡することが可能です。これは、

特定イベントの発生に敏感なアプリケーション環境で役立ちます。たとえば、アプリケーションに

よっては、特定株式の価格がいつ所定のしきい値を超えたかを把握する必要があります。この変更

通知機能は、実表の変更だけでなく、マテリアライズド・ビューの変更も追跡できるため、特に役

立ちます。

7


3.1 Oracle TimesTen のパフォーマンス

ハードウェアを追加しただけでは、それほど応答時間を短縮できません。Oracle TimesTen では、固有のアーキテクチャにより、待機時間を大幅に短

縮できます。

Oracle TimesTen では、インメモリ・アーキテクチャにより、マイクロ秒単位の応答時間が可能にな

ります。Oracle TimesTen を使用すると、データベース・レコードを読み込むトランザクションの応

答時間は、5 マイクロ秒未満になり、レコードを更新または挿入するトランザクションの応答時間は、

15 マイクロ秒未満になります。

図 2：Oracle TimesTen の応答時間

図 2 は、Oracle Enterprise Linux 5.2 を実行する 2-CPU Intel E5450（8-way@3GHz）システムでトラン

ザクションの読込みおよび更新を実行するアプリケーションにおける応答時間を示したものです。

4. Oracle In-Memory Database Cache によるデータ・キャッシュ

Oracle IMDB Cache には、Oracle Database 表のサブセットが含まれます。

Oracle IMDB Cache によって、Oracle Database からアプリケーション層への表のサブセットのキャッ

シュが可能になります。キャッシュされた表は更新され、Oracle IMDB Cache によって Oracle Databaseとキャッシュの間でデータが同期化されます。

キャッシュされたデータを管理するデータベース・エンジンは、Oracle TimesTen In-Memory Databaseです。Oracle TimesTen In-Memory Database には、キャッシュされたデータをロードし、同期化する

機能が追加されています。Oracle IMDB Cache と関連するバックグランド・プロセスの 1 つである

Cache Agent は、同期化の一部を管理します。図 3 は、Oracle IMDB Cache のアーキテクチャを示し

たものです。

8


図 3：Oracle IMDB Cache のアーキテクチャ

図 4：複製された 5 つのグリッド・メンバーからなるキャッシュ・グリッド

9


キャッシュ・グリッドは、アプリケーション・データを一括管理するOracle IMDB Cacheの集合です。

1 つのキャッシュ・グリッドは、それぞれがOracle IMDB Cacheにサポートされている 1 つまたは複

数のグリッド・メンバーで構成されます。グリッド・メンバーは、中央のOracleDatabaseであるOracle Real Application Cluster（Oracle RAC）から表をキャッシュします。キャッシュされたデータは、共有

ストレージを持たずに複数のノードまたはOracle IMDB Cacheに分散されます。また、キャッシュ・

グリッドによって、ノード間のデータの整合性が保証されます。グリッド・メンバーは、複製され

る場合があります。

図 4 は、5 つの複製されたグリッド・メンバーからなるキャッシュ・グリッドを示しています。グリッ

ド・メンバーは、操作を中断することなく段階的に追加できます。Oracle IMDB Cache で使用される

必要のあるレプリケーション構成は、アクティブ・スタンバイ・ペア構成です。

4.1 キャッシュのコンテンツの定義

Oracle IMDB Cache のコンテンツは、拡張 SQL 構文によって定義されます。

キャッシュ・グループは、外部キー制約によって関連し、頻繁に使用されるOracleデータベース表の

セットに対応するOracle IMDB Cache表のセットです。SQL構文はキャッシュ・グループを定義し、

Oracleデータベース表からキャッシュされる列と行を選択するために使用します。ユーザーは、キャッ

シュ・グループをプログラム経由で使用したり、インタラクティブなttIsqlユーティリティ経由で定

義したりできます。

以下に例を示します。

以下の表が Oracle Database に存在するとします。

− Customer (CustId, Name, Age, Gender, StreetAddress, State, ZipCode, PhoneNo)

− Order (CustId, OrderId, PurchaseDate, Amount)

− CustInterest (CustId, Interest)

アプリケーションで、2009 年 1 月 1 日から発注を行っている顧客のプロファイルをキャッ

シュします。そのために、以下の 2 つのキャッシュ・グループを定義します。

• 1つ目のキャッシュ・グループには、上の 3つの表のサブセットが含まれます。このキャッ

シュ・グループは 2009 年 1 月 1 日以降に発注を行い、米国の太平洋沿いに住んでいる顧

客を対象としています。さらに、アプリケーションでは表の列のサブセットのみをキャッ

シュするように選択することも可能です。たとえば、以下の列をキャッシュします。

− Customer (CustId, Name, Age, Gender, State)

− Order (CustId, PurchaseDate, Amount)

− CustInterest (CustId, Interest)

• 2 つ目のキャッシュ・グループにも 1 つ目のキャッシュ・グループと同じ情報が含まれ

ますが、対象の顧客は米国の山沿いに住んでいます。

この 2 つのキャッシュ・グループは、Oracle IMDB Cache を実行している別のノードにキャッ

シュできます。

10


Oracle IMDB Cacheではこの他に、キャッシュ・インスタンスの概念が使用されます。キャッシュ・

インスタンスとは一意に識別可能な関連レコードの集合であり、複雑なオブジェクトのモデル化に

使用されます。キャッシュ・インスタンスによりキャッシュをロードする単位が形成されます。

キャッシュ・エージングについては後ほど説明します。上記の例では、所定の顧客ID（CustId）が割

り当てられたCustomer、Order、CustInterest表のすべてのレコードは、同じキャッシュ・インスタン

スに属し、互いに外部キー制約によって関連付けられています。CustIdはキャッシュ・インスタンス

を一意に識別するため、キャッシュ・インスタンス・キーと呼ばれます。

Oracle TimesTen は Oracle Database と同じデータ型に対応しています。

独自のデータ型に対応するだけでなく、Oracle TimesTen は Oracle Database と同じ基本データ型にも

対応しています。そのため、Oracle Database のデータ型を Oracle TimesTen のデータ型にマッピング

する必要がありません。ただし、OracleDatabase のデータ型をより効率的な Oracle TimesTen 実装に

マッピングすることもできます。たとえば、アプリケーションで Oracle Database の NUMBER データ

型を Oracle TimesTen の INTEGER データ型にマッピングできます。

アプリケーション開発者は、インメモリ・キャッシュ表に索引を作成できます。インメモリ・キャッ

シュの索引は、Oracle Database の索引と一致する場合もあれば、一致しない場合もあります。アプリ

ケーション設計者は、Oracle TimesTen の柔軟性を利用して、複数の索引を同一表に作成したり、複

数列に渡って索引を定義したりできます。

4.2 データのロードとキャッシュの管理

アプリケーションでは、キャッシュ・グループのデータを Oracle IMDB Cache へロードして処理する

方法を判断する必要があります。データのロードには以下の手法を使用できます。

• 明示的ロード。以下のうちの 1 つの方法を使用できます。

o キャッシュ・グループ全体を一度にロード。この手法は、キャッシュ・グループ全体のコン

テンツがそのキャッシュに適合している場合に向いています。キャッシュ・グループ全体を

アンロードすることも可能です。

o "WHERE 句による"キャッシュ・インスタンスのロード。この場合、WHERE 句を使用して

キャッシュに取り込むキャッシュ・インスタンスのサブセットを記述します。アプリケーショ

ンは、キャッシュ・インスタンスを"WHERE 句によって"アンロードすることもできます。

o "ID による"キャッシュ・インスタンスのロード。この場合、キャッシュ・インスタンス IDのリストを使用してキャッシュに取り込むキャッシュ・インスタンスを指定します。アプリ

ケーションは、キャッシュ・インスタンスを"ID によって"アンロードすることもできます。

• 動的ロード。この手法は、キャッシュ・インスタンスのロードに使用できます。動的ロードは、

キャッシュ・グループが大きすぎてキャッシュに収まらず、アプリケーションの作業用セットの

みがキャッシュにとどまっている場合に有効です。この場合、SQL文2で要求したデータがキャッ

2 キャッシュ・インスタンスの動的ロードは、キャッシュ・インスタンスの任意のレコードの主キーまたは外部キー上に等価式

があるSQL文で可能です。

11


シュに見つからないなどのキャッシュ・ミスが発生した際に、キャッシュ・インスタンスを構成

するレコードが自動的にキャッシュにロードされます。キャッシュ・インスタンスがキャッシュ

内にある場合は、キャッシュから直接、SQL 文が実行されます。

動的ロードは通常、自動キャッシュ・エージングと組み合わせられます。キャッシュの処理能力

を超えると、キャッシュ・インスタンスはエージングによりキャッシュから自動的に削除されま

す。Oracle IMDB Cacheは、利用ベースのエージングと時間ベースのエージングに対応しています。

利用ベースのエージングではLRU（Least Recently Used）スキームを使用して、キャッシュ処理能

力の超過時にキャッシュ・インスタンスをエージングによって削除します。時間ベースのエージ

ングは、キャッシュ・インスタンスにキャッシュの一定期間のライフタイムを与えます。そのた

め、キャッシュ・グループのいずれか 1 つの表にタイムスタンプ列を必要とします。タイムスタ

ンプ列の値はアプリケーションごとに管理されます。キャッシュ・インスタンスは、タイムスタ

ンプの値とライフタイムを足した値が現在の時刻を超えるまで、キャッシュに保持されます。

キャッシュ・エージングは動的ロードから独立して使用できます。実際、Oracleデータベースか

らキャッシュされないOracle TimesTenの通常の表とともに使用することも可能です。

アプリケーションではどのキャッシュ・グループをエージングの対象にするかを選択できます。

たとえば、アプリケーションではキャッシュに常にカタログ情報を保持できます。それとは別に、

ユーザーがアプリケーションに接続した際にユーザーのプロファイルをオンデマンドでロード

したり、ユーザーが接続を切断すると、自動的にプロファイルをエージングによって削除したり

できます。キャッシュ・インスタンスはアプリケーションによって明示的にアンロードすること

も可能です。

インメモリ・キャッシュ表にロードされたデータは、JDBC、ODBC、TTClasses および OCI による

SQL、PL/SQL および Pro*C 処理に使用できます。

4.3 キャッシュ・グリッド間のデータ共有

キャッシュ・グループは、ローカルまたはグローバルのいずれかです。ローカル・キャッシュ・グ

ループでは、キャッシュされたデータは同一のキャッシュ・グリッドのメンバー間で共有されませ

ん。グリッド・メンバーには分離データや重複データが含まれる場合があり、データをグリッド・

メンバー間に分配する方法はアプリケーションに依存します。たとえば、読取り専用のカタログ・

データは、適なパフォーマンスを実現するためにすべてのグリッド・メンバーにキャッシュされ、

更新可能な顧客情報は異なるグリッド・メンバーに地域別にパーティション化されます。キャッシュ

された表のコミットされた更新は、他のグリッド・メンバーとの調整をせずにOracle表に伝播されま

す。ローカル・キャッシュ・グループは、明示的なロードまたは動的なロードとして定義されます。

キャッシュ・グループは、グローバルとして定義されない場合、デフォルトではローカルです。

12


グローバル・キャッシュ・グループでは、キャッシュされたデータは、同一のキャッシュ・グリッ

ドのメンバー間で共有されます。グリッド間で平行処理制御が実施され、グリッドの任意の場所で

実行されるトランザクションは、常にキャッシュ・インスタンスがコミットされた新バージョン

を示します。異なるグリッド・メンバーによって同一のキャッシュ・インスタンスにコミットされ

た更新は、データ整合性の確保のためにグリッド内でコミットされた順序でOracleデータベースに伝

播されます。

4.4 データ整合性の維持

Oracle IMDB Cache は、キャッシュされたデータへの更新をサポートし、キャッシュと Oracle Database 間の整合性を自動的に維持します。

キャッシュされたデータは、Oracle IMDB Cache 内または Oracle Database 内で更新されます。Oracle IMDB Cache を使用することで、キャッシュから Oracle Database への更新およびその逆方向の更新を

自動的に伝播させることができます。ただし、キャッシュ・グループの大部分か全部がキャッシュ、

または Oracle Database で更新されることが前提です。キャッシュおよびバックエンド・データベー

スでの大量な更新が予想される表のセットをキャッシュするデザイン・フローではこれが主流です。

ただし、両方で更新を行うのが適切なシナリオもあります。たとえば、Oracle データベースでの更新

は、メンテナンス上の理由により夜間にしか発生せず、日中はキャッシュでの更新が発生する場合

や、中央データの更新が Oracle データベースで発生し、地域データの更新はキャッシュで発生する

場合などです。

キャッシュ・グループはシステム管理またはユーザー管理のいずれかです。システム管理キャッシュ・

グループには次の 3 つの種類があります。

• 読取り専用キャッシュ・グループ。このキャッシュ・グループは、キャッシュ内で更新されませ

ん。Oracleデータベース内で更新され、Oracle IMDB CacheによりOracleデータベースからキャッ

シュへの更新の伝播が管理されます。

非同期ライトスルー（AWT）キャッシュ・グループ。• このキャッシュ・グループは、キャッシュ

内では更新されますが、Oracleデータベース内では更新されません。トランザクションのコミッ

ト後、Oracle IMDB CacheによりキャッシュからOracleデータベースへ更新が非同期的に伝播され

ます。

同期ライトスルー（SWT）キャッシュ・グループ。• このキャッシュ・グループは、キャッシュ内

では更新されますが、Oracleデータベース内では更新されません。インメモリ・キャッシュ表の

更新が、トランザクションのコミットと同時にOracleデータベースに同期的に伝播されます。

システム管理キャッシュ・グループには、セマンティックとそのセマンティックを実施するための

制限が明確に定義されています。反対に、ユーザー管理キャッシュ・グループのセマンティックは

アプリケーションに委ねられています。たとえば、ユーザー管理キャッシュ・グループは、キャッ

シュと Oracle データベースの両方で更新できます。

読取り専用、AWT、SWT およびユーザー管理キャッシュ・グループは、すべてローカル・キャッシュ・

グループです。ただし、動的 AWT キャッシュ・グループのみ、グローバル・キャッシュ・グループ

と指定されます。

13


次の表は、使用可能なさまざまなキャッシュ・グループのロード、キャッシュ・グリッドの共有、

および整合性の維持のオプションをまとめたものです。

キャッシュ・グループへのデータのロード

明示的ロード動的ロード読取り専用キャッ

シュ・グループ x x

データ

整合

性の

維

持

AWT キャッシュ・グループ

x x x

SWT キャッシュ・グループ

x x

ユーザー管理キャッ

シュ・グループ x x

ローカル・キャッ

シュ・グループ

グローバル・キャッ

シュ・グループローカル・キャッ


グローバル・キャッ


キャッシュ・グリッド間のデータ共有

Oracle IMDB Cacheアプリケーションは、Oracle IMDB Cacheデータベースに単独で接続することで、

SQL文をキャッシュ・グループ、またはOracle Databaseのいずれかに送信できます。この単独の接続

機能は、パススルー機能により有効になります。この機能では、SQL文がインメモリ・キャッシュ表

によりローカルで処理できるのか、またはOracle Databaseにリダイレクトする必要があるのかを

チェックします。パススルー機能の設定では、どのタイプの文をパススルーするか、およびどの状

況でパススルーするかを指定します。中でも、データベースを更新する文をすべてOracle Databaseに渡すように指定する設定は、特に役立ちます。この設定により、Oracle Databaseでの実行内容をアプ

リケーションで更新することができ、単独接続によってOracle IMDB Cacheでの実行内容の読取りが

行われます。

以下の項ではキャッシュ・データの整合性維持のために使用できる Oracle IMDB Cache 操作について

説明します。そのうち、一部の操作は Oracle IMDB Cache によって自動的に開始されますが、それ以

外の操作はアプリケーションによって明示的に開始されます。

4.4.1 グローバル・キャッシュ・グループにおける Oracle IMDB Cache から Oracle Database および

キャッシュ・グリッド・メンバー間の更新の伝播

前に説明したように、グローバル・キャッシュ・グループは、動的 AWT キャッシュ・グループでも

あります。グローバル・キャッシュ・グループを持つアプリケーションは、グリッド・メンバーの 1 つに接続されます。ほとんどの場合、すでにグリッド・メンバーにキャッシュされたキャッシュ・

インスタンスにアクセスします。ただし、グリッド・メンバーにないキャッシュ・インスタンスに

アクセスしようとする場合は、更新されたキャッシュ・インスタンスの新バージョンがある場所

に応じて、別のグリッド・メンバーまたは Oracle Database のいずれかから、Oracle IMDB Cache によっ

てそのキャッシュ・インスタンスが動的にロードされます。これは、アプリケーションからの操作

を必要とせず、自動的に実行されます。Oracle IMDB Cache は、新のコピーがある場所を判断し、

14


ピアツーピア通信を使用してそのグリッド内の他の Oracle IMDB Cache データベースと情報を交換

します。

トランザクションによって、いずれかのグリッド・メンバーでキャッシュ・インスタンスが更新さ

れる場合、次のメカニズムを使用して、Oracle データベースとキャッシュとの同期状態を保つことが

できます。

• 伝播。Oracle IMDB Cacheは、トランザクションのコミット後、Oracle Databaseへの更新を伝播し

ます。別のトランザクションが別のグリッド・メンバーの同一のキャッシュ・インスタンスを更

新し、その直後にコミットした場合、Oracle IMDB Cacheによって、コミットが正しい順序でOracle Databaseに伝播されることが保証されます。

図 5 は、3 つのグリッド・メンバーからなるキャッシュ・グリッドを示しています。すべてのグリッ

ド・メンバーは、同一のグローバル・キャッシュ・グループをキャッシュし、各グリッド・メンバー

がそのキャッシュ内に含むのは、グローバル・キャッシュ・グループのいくつかのキャッシュ・イ

ンスタンスのみです。これらのインスタンスがキャッシュされるのは、近それぞれのグリッド・

メンバーにアクセスされたためです。時間の経過に伴い、各インスタンスは、そのグリッド・メン

バー内でアクセスを受け続けてその場所にとどまるか、または別のグリッド・メンバー内でアクセ

スされてそのメンバーに移動するか、またはまったくアクセスされずにキャッシュ・グリッドから

エージングによって完全に削除されます。

図 5：更新の伝播およびグローバル・キャッシュ・グループのキャッシュの整合性

4.4.2 ローカル・キャッシュ・グループにおける Oracle IMDB Cache から Oracle Database への更新の伝播

キャッシュ内で更新されるローカル・キャッシュ・グループの場合、以下のメカニズムを使用して

Oracle データベースとキャッシュとの同期状態を保つことができます。

• 伝播。伝播オプションを有効にすると、挿入、更新、削除といったキャッシュ・グループのすべ

ての修正がOracle Databaseに自動的に伝播されます。伝播を行うタイミングは、SWTのキャッ

シュ・グループとAWTのキャッシュ・グループとで異なります。SWTキャッシュ・グループの

場合、キャッシュ・グループが修正されているトランザクションがアプリケーションで完了する

15


と、トランザクションは、初に Oracle Database にコミットされ、次に Oracle IMDB Cache にコ

ミットされます。この手法では、データに関連する必要なロジックを Oracle IMDB Cache にコミッ

トする前に Oracle Database で適用できます。AWT キャッシュ・グループの場合、アプリケーショ

ンでトランザクションが完了すると、そのトランザクションは、Oracle IMDB Cache にコミット

され、制御がアプリケーションに戻ります。その後、トランザクションで行われた変更が非同期

的に Oracle Database に伝播されます。

• フラッシュ。この操作はアプリケーションからの明示的な要求によって行われ、キャッシュ・グ

ループまたはキャッシュ・インスタンスに適用されます。伝播オプションが無効になっている

キャッシュ・グループとキャッシュ・インスタンスにしか使用できません。この操作では、Oracle Databaseのレコードがキャッシュにあるレコードの値で更新されます。この操作は、同じレコー

ド・セット上で特定の期間に頻繁に更新が行われる場合に役立ちます。各更新を実行のたびに伝

播するのではなく、各レコードの終イメージがOracle Databaseに送信および適用されます。

アプリケーションでは、異なるグリッド・メンバーのいくつかの更新可能なローカル・キャッシュ・

グループによってキャッシュ・グリッドを構成します。グリッド・メンバーから Oracle Database へ

の更新の伝播は、Oracle IMDB Cache によって管理されますが、異なるグリッド・メンバーのローカ

ル・キャッシュ・グループが重複しないようにすることを推奨します。これは、同じデータに対し

て同時に複数の更新が別のノードで発生すると、バックエンドで予測不能なデータ値が発生するた

めです。

図 6：更新可能なローカル・キャッシュ・グループにおける更新の伝播

16


4.4.3 ローカル・キャッシュ・グループにおける Oracle Database から Oracle IMDB Cache への更新の伝播

3Oracleデータベースで更新されるローカル・キャッシュ・グループの場合、以下のメカニズムを使

用してキャッシュのコンテンツとOracleデータベースとの同期状態を維持できます。

• リフレッシュ。リフレッシュは、キャッシュ・グループ全体または特定のキャッシュ・インスタ

ンスのリフレッシュに関する、アプリケーションからの明示的な要求です。この要求は、アンロー

ド操作後のロード操作に相当します。

• 完全自動リフレッシュ。完全自動リフレッシュにより、アプリケーションにリフレッシュの実行

頻度が示され、Oracle IMDB Cacheのキャッシュ・グループがアプリケーションに示された間隔ご

とに自動的にリフレッシュされます。

• 増分自動リフレッシュ。完全自動リフレッシュとは異なり、増分自動リフレッシュでは、Oracleデータベース内で後のリフレッシュ以降に修正されたレコードのみが更新されます。完全自動

リフレッシュと同様、アプリケーションにリフレッシュの頻度が示され、Oracle IMDB Cacheでは、

その頻度ごとに増分リフレッシュが自動的に実行されます。

増分自動リフレッシュはスライディング・ウィンドウをキャッシュに保持するための、時間ベー

スのエージングで使用します。たとえば、顧客サポート・アプリケーションの場合、過去 5 日間

に報告されたすべてのインシデントをキャッシュに保持する必要があります。この場合、キャッ

シュ・グループで増分自動リフレッシュを使用し、時間ベースのエージングのライフタイムを 5日間にするように指定できます。新しいインシデントが Oracle データベースに挿入されると、増

分自動リフレッシュによってそのインシデントがインメモリ・キャッシュ表に自動的に伝播され

ます。インシデントが Oracle データベース内で更新されると、その更新内容がインメモリ・キャッ

シュ表に自動的に伝播されます。インシデントにはアプリケーションによってメンテナンスされ

るタイムスタンプが必要です。タイムスタンプの値が現在の日付の 5 日前より古くなると、関連

するインシデントがエージングにより、キャッシュから自動的に削除されます。

上に挙げた 3 つの手法は、さまざまな状況で役立ちます。1 日 1 回、コンテンツ・プロバイダのサイ

トのアクティビティが小になる午前 2 時にキャッシュ・グループをリフレッシュする必要がある

とします。この場合、完全自動リフレッシュが適です。一方、5 分ごとにリフレッシュする必要が

あるキャッシュ・グループの場合は、増分自動リフレッシュが適しています。また、頻繁なリフレッ

シュが必要ではなく、リフレッシュの時期が予測不能でアプリケーションにしか把握されないキャッ

シュ・グループの場合は、リフレッシュ・オプションを使用する必要があります。

3 グローバル・キャッシュ・グループはOracle Databaseでは更新されません。

17


アプリケーションによっては、異なるグリッド・メンバーのいくつかの読取り専用のローカル・キャッ

シュ・グループによってキャッシュ・グリッドを構成することがあります。異なるグリッド・メン

バーのキャッシュ・グループは、完全に分離しているか、部分的に重複しているか、または同一で

あるかのいずれかです。Oracle Database からすべてのグリッド・メンバーへの更新が伝播されると、

Oracle IMDB Cache で管理されます。

図 7：読取り専用ローカル・キャッシュ・グループの増分自動リフレッシュ

4.5 高可用性

Oracle IMDB Cache は、アプリケーション層およびデータベース・サーバー層に渡って高可用性をサポートします。

Oracle TimesTen をレコードのデータベース専用として使用すると、Oracle Database のインメモリ・

データベース・キャッシュとは対照的に、レプリケーションによるデータや各種オンライン操作、

フェイルオーバー、リカバリ、オンライン・アップグレードをサポートするさまざまなユーティリ

ティの可用性が向上します。自動障害検出とデータベースおよびアプリケーションのフェイルオー

バーは、Oracle Clusterware と統合することにより可能になります。同様に、Oracle Database では Oracle Real Application Clusters、Oracle Automatic Storage Management（Oracle ASM）および Oracle Data Guardなどの機能セットにより、データの可用性向上をサポートします。さらに、Oracle IMDB Cache のレ

プリケーション・コンポーネントで提供される機能により、キャッシュ・データの可用性が高まり、

アプリケーション層およびデータベース層の Oracle データベースに及ぶ障害から自動的にリカバリ

できます。これについては次に説明します。

4.5.1 インメモリ・キャッシュ・ノードの障害処理

キャッシュ・データをキャッシュ・ノードの障害から保護し、絶え間なく使用できるようにするた

め、Oracle TimesTen のレプリケーション機能は、キャッシュ・ノードの障害時にリカバリ処理を行

います。複数の読取り専用サブスクライバによるアクティブ・スタンバイ・ペアのレプリケーション

18


構成は、構成の一部に Oracle Database を含み、キャッシュ・ノードのフェイルオーバーとリカバリ

を提供するように設計されています。

アクティブ・スタンバイ・ペアでは、すべての更新内容が常にアクティブ・ノードから適用されま

す。次に更新内容はスタンバイ・ノードに複製され、後にスタンバイ・ノードからすべての読取り

専用サブスクライバ・ノードに複製されます。そのため、スタンバイ・ノードはどの読取り専用サ

ブスクライバ・ノードよりも必ず上にあります。これにより、アクティブ・ノードがダウンしても、

どのサブスクライバ・ノードが次のアクティブ・ノードになるかが明確に決定されます。

読取り専用キャッシュ・グループ

アクティブ・スタンバイ・ペアのレプリケーション構成は読取り専用のキャッシュ・グループでも、

ライトスルー・キャッシュ・グループでも動作するように設計されています。読取り専用キャッ

シュ・グループの場合、Oracle データベースに適用された更新はアクティブ・ノードにしか伝播され

ません。次に、Oracle TimesTen レプリケーションにより、まずスタンバイ・ノードを通過してから、

他のすべてのノードに更新内容が伝播されます。

図 8：アクティブ・スタンバイ・ペア構成を使用した読取り専用キャッシュ・グループ

アクティブ・ノードで障害が発生すると、スタンバイ・ノードが次のアクティブ・ノードになりま

す。それ以降は Oracle Database の更新内容が新しいアクティブ・ノード（つまり、これまでのスタ

ンバイ・ノード）に伝播され、読取り専用サブスクライバに複製されます。以前のアクティブ・ノー

ドがオンライン状態に戻ると、再びスタンバイ・ノードになります。Oracle TimesTen レプリケーショ

ンでは、アクティブからスタンバイへの更新伝播の切替えと障害ノードのリカバリを自動的に行い

ます。

同様に、スタンバイ・ノードに障害が発生すると、アクティブ・ノードからのレプリケーションは

自動的に読取り専用サブスクライバ・ノードにリダイレクトされます。スタンバイ・ノードがオン

ライン状態に戻ると、レプリケーションによって、スタンバイ・ノードの役割が再開する前に更新

された内容がすべてさかのぼって取得されるようになります。

19


ライトスルー・キャッシュ・グループ

ライトスルー・キャッシュ・グループでは、更新内容がアクティブ・ノードに適用されます。次に、

その内容がスタンバイ・ノードに複製されます。さらに Oracle Database に伝播され、すべての読取

り専用サブスクライバ・ノードに複製されます。

図 9：アクティブ-スタンバイ構成を使用したライトスルー・キャッシュ・グループ

アクティブ・ノードで障害が発生すると、スタンバイ・ノードが次のアクティブ・ノードになりま

す。それ以降は、すべての更新内容が必ず新しいアクティブ・ノード（すなわち、前出のスタンバ

イ・ノード）に送られます。新しいアクティブ・ノードの更新内容は Oracle Database に伝播され、

読取り専用サブスクライバ・ノードに複製されます。以前のアクティブ・ノードがオンライン状態

に戻ると、再びスタンバイ・ノードになります。Oracle TimesTen レプリケーションでは自動的に新

しいスタンバイ・ノードのリカバリが行われ、バックエンドへの更新伝播の役割が新しいスタンバ

イ・ノードに転送されます。

同様に、スタンバイ・ノードに障害が発生した場合は、アクティブ・ノードからのレプリケーショ

ンが自動的に読取り専用サブスクライバ・ノードにリダイレクトされ、アクティブ・ノードから Oracle Database への直接の更新伝播が開始します。スタンバイ・ノードがオンライン状態に戻ると、レプリ

ケーションによって、スタンバイ・ノードの役割が再開する前のすべての更新内容がさかのぼって

取得されるようになります。また、スタンバイ・ノードで Oracle Database および読取り専用サブス

クライバへの更新伝播が再開されます。

4.5.2 Oracle Database での障害処理

ネットワーク障害、ハードウェア障害、Oracle Database 障害などの理由を問わず Oracle IMDB Cacheが Oracle Database にアクセスできなくなった場合、Oracle IMDB Cache では障害に対する弾力性を保

つように設計されています。インメモリ・キャッシュは引き続きアプリケーションからアクセスで

きます。

20


さらに、AWT キャッシュ・グループの場合はキャッシュの更新が引き続き Oracle TimesTen に記録

されるため、再度 Oracle Database にアクセスできるようになると、その更新内容が Oracle Databaseに伝播されます。同様に、Oracle Database の読取り専用キャッシュ・グループに対して実行された変

更でまだインメモリ・キャッシュに伝播されていないものは、Oracle データベースに記録が残り、再

度 Oracle データベースにアクセスできるようになるとキャッシュにその記録が伝播されます。

さらに、Oracle IMDB Cacheは、Oracle RACの高可用性機能を大限に活用します。Oracle RACの構

成は複数ノードからアクセス可能な単一の物理データベースで成り立っています。単一ノードの実

行時構成はインスタンスと呼ばれます。Oracle RACにより、ロードバランシング、高可用性、イン

スタンス全体に渡るデータ整合性が実現されます。

Oracle IMDB Cache では、ユーザーの介入なしに Oracle RAC のノード障害から迅速に復旧します。

このため、Oracle IMDB Cache では、常に Oracle の透過的アプリケーション・フェイルオーバー（TAF）および高速アプリケーション通知（FAN）機能が使用されます。ただし、Oracle クライアントのバー

ジョン、サーバー、TAF の構成によっては使用できないことがあります。Oracle IMDB Cache の接続

先である Oracle インスタンスに障害があると、自動的に別のインスタンスに接続されます。障害発

生時にリフレッシュ、完全自動リフレッシュ、または増分自動リフレッシュを操作していた場合、

インメモリ・データベースで発生した変更内容は自動的にロールバックされ、操作が再度実行され

ます。障害発生時に AWT キャッシュ・グループの伝播操作中だった場合、ロールバックが必要であ

れば Oracle Database で発生した変更内容が自動的にロールバックされ、トランザクションの伝播操

作が再度実行されます。

Oracle データベースが同期データ・ガードを使用してスタンバイ・データベースに複製された場合、

アクティブ Oracle データベースに障害が発生すると、データを損失することなく Oracle IMDB Cacheがスタンバイ Oracle データベースに自動的にフェイルオーバーします。

5. パフォーマンス

Oracle IMDB Cache のパフォーマンスを測定するため、携帯電話ネットワークで使用するHome Location Register（HLR）アプリケーションをシミュレートするベンチマークを開発しました。ベンチマーク

は、7 つのトランザクションのセットで構成され、それぞれ着信転送の設定、削除や携帯電話サブス

クライバの情報更新など、HLR で実行される一般的な操作がモデル化されています。

ベンチマークは、2 種類の構成で実行しました。1 つ目の構成では、Oracle Database に対してベンチ

マーク・アプリケーションが実行され、一方のサーバーで HLR アプリケーションを実行し、もう一

方のサーバーで Oracle Database 10g を実行しました。2 つ目の構成では、Oracle Database の前に Oracle IMDB Cache を追加しました。一方のサーバーで Oracle TimesTen キャッシュ・データベースと直接

リンクされた HLR アプリケーションのプログラムを実行し、もう一方のサーバーで Oracle Database 10g を実行しました。キャッシュ・データは、AWT キャッシュ・グループに保存され、キャッシュ・

データに対する更新は Oracle Database に自動的に伝播されます。

21


このアプリケーションは、データ・アクセス用の JDBC を使用して Java で実装されました。4 つの

サーバーの構成はすべて同一で、6GB の物理 RAM、Oracle Enterprise Linux 5.2 で稼働するハイパー

スレッドを搭載した 2 基の Intel Xeon 2.4GHz プロセッサを備えています。

Oracle Database に対して実行した場合と Oracle IMDB Cache に対して実行した場合において、各タイ

プのトランザクションの平均応答時間を測定しました。以下のグラフは、Oracle IMDB Cache を使用

した場合にアプリケーションの応答時間が大幅に短縮することを示しています。

図 10：HLR ベンチマーク・アプリケーションの応答時間比較

2 つの構成ですべてのトランザクションを組み合わせた場合のスループットも測定しました。以下の

グラフは、Oracle IMDB Cache を使用した場合にアプリケーションのスループットが大幅に増加する

ことを示しています。

図 11：HLR ベンチマーク・アプリケーションのスループット比較

22


このベンチマークは、Oracle IMDB Cache の使用による利点を示しています。上のグラフに示すよう

に、アプリケーションの応答時間は 10 倍から 40 倍短縮し、スループット全体では 7 倍以上も短縮

しています。一般的に、Oracle IMDB Cache による改善率は、ハードウェアやプラットフォームによっ

て異なります。

6. 例

この項では、キャッシュ・シナリオとそのシナリオに推奨される Oracle IMDB Cache 構成およびキャッ

シュ・グループ・タイプについて検証します。それぞれの例では特定のタイプのキャッシュ・グルー

プに焦点を当てていますが、アプリケーションの要件を適な状態で満たすため、同じ Oracle IMDB Cache に別のタイプのキャッシュ・グループが共存する場合があります。

6.1 読取り専用キャッシュ

増分自動リフレッシュを使用する読取り専用キャッシュ・グループは、頻繁に参照するデータのキャッシュに適しています。

読取り専用キャッシュにより、多くのアプリケーションに利点がもたらされます。利点がもたらさ

れるアプリケーションには、一部のレコード・セットの問合せが何度も行われるという特徴があり

ます。問合せが行われるレコードの更新頻度はまちまちですが、書込みに対する読取りの比率はお

おむね高くなっています。該当するレコードの例として、オンライン・ショッピング・アプリケー

ションの価格リスト、航空券予約アプリケーションのフライト・スケジュール、ホテル予約アプリ

ケーションの空室情報などがあります。

このようなデータには、増分自動リフレッシュを使用した（システムで管理される）読取り専用ロー

カル・キャッシュ・グループのキャッシュ構成がもっとも適しています。データはバックエンド・

データベースで更新されます。また、更新内容は自動的にキャッシュに伝播されます。伝播頻度は

アプリケーションごとに決定されますが、バックエンドの更新頻度やアプリケーションに必要なデー

タの基準によって異なる場合もあります。

キャッシュ・グリッドの複数のグリッド・メンバーにキャッシュが配置されると、ローカル・キャッ

シュ・グループがグリッド・メンバー上で定義され、各メンバーはバックエンド・データベースか

ら直接更新されます。

オンライン・ショッピング・アプリケーションでは通常、価格リストへの変更は頻繁に行われない

ため、キャッシュされた価格リストを頻繁に更新する必要がありません。一方で、フライト追跡ア

プリケーションは、読取り集中型であると同時に、キャッシュされたフライトのステータスを新し

い状態に維持しておく必要があります。読取り専用キャッシュ・グループに定義された 5 分ほどの

小さな増分自動リフレッシュの時間間隔で Oracle Database を更新するのが適です。Oracle IMDB Cache は、更新されたデータを含むグリッド・メンバーへすべての更新を自動的に伝播します。グリッ

ド・メンバーに接続されたアプリケーションでは、Oracle IMDB Cache キャッシュへの単独接続を設

定できます。また、パススルー・オプションを使用して、キャッシュでの読取り中に Oracle Databaseにすべての更新をルーティングできます。

23


6.2 読取り専用スライディング・ウィンドウ・キャッシュ

増分自動リフレッシュおよび時間ベースのエージングを使用した読取り専用キャッシュ・グループは、スライディング・ウィンドウに該当する、頻繁

に参照されるデータのキャッシュに適しています。

大抵の場合、アプリケーションで必要とされる読取り専用データには時間コンポーネントが含まれ

ています。時間コンポーネントでは、古いデータよりも新しいデータの方がより頻繁にアクセスさ

れます。この特定のアプリケーション・クラスでは、新しいデータが常に生成され、古いデータの

価値が失われていきます。これに対処するため、固定長の時間間隔を検討することができます。こ

の時間間隔の両端のうち一方はデータが送られると常に前方移動し、もう一方はそれに伴って短く

なります。アプリケーションが対象とするのは間隔内のデータのみです。通常これをスライディン

グ・ウィンドウと呼びます。

スライディング・ウィンドウに該当するデータを必要とするアプリケーションの例として、株式取

引アプリケーションやニュース配信アプリケーションがあります。たとえば、株式取引アプリケー

ションでは過去 3 日分の取引が、ニュース配信アプリケーションでは過去 24 時間分のニュース・ク

リップが必要な場合があります。

スライディング・ウィンドウに該当するデータをキャッシュするには、新しいデータを自動的に

キャッシュに取り込み、古いデータをエージングによって自動的にキャッシュから削除する必要が

あります。また、バックエンドで変更が行われた場合に備えてキャッシュのデータを自動的に更新

する必要があります。このようなデータには、増分自動リフレッシュと時間ベースのエージングを

使用した（システムで管理される）読取り専用キャッシュ・グループのキャッシュ構成がもっとも

適しています。

前の例と同様、キャッシュ・グリッドの複数のグリッド・メンバーにキャッシュが配置されると、

ローカル・キャッシュ・グループはグリッド・メンバー上で定義され、各メンバーは Oracle Databaseから直接更新されます。

6.3 更新可能なキャッシュ

更新可能なキャッシュには非同期ライトスルー・キャッシュ・グループが適しています。

アプリケーションによっては、Oracle Database への更新の終伝播とともに、キャッシュ・データを

迅速にリアルタイムで更新する必要があります。たとえば、電話のサブスクリプション・サービス

の管理やプロビジョニングを行い、サブスクリプション・サービスへのアクセス権を認証するサブ

スクリプション・アプリケーションでは通常、Oracle IMDB Cacheにサブスクライバ情報がキャッシュ

されます。ユーザーのサービス変更は、迅速にキャッシュに反映され、バックエンド・データベー

スに伝播されます。

このようなデータには非同期ライトスルー・キャッシュ・グループの構成がもっとも適しています。

サブスクライバの人口が多く、アプリケーションをキャッシュ・グリッドの複数のグリッド・メン

バーに渡って配置する必要がある場合、各メンバーがサブスクライバ人口のサブセットを所有し、

異なるグリッド・メンバーが所有するサブセット内で重複しないキャッシュ・グループとともにグ

リッド・メンバー上でローカル・キャッシュ・グループを定義します。たとえば、サブスクライバ

は、地域コード別にパーティション化されます。

24


6.4 更新可能な動的キャッシュ

更新可能な動的キャッシュには、動的ロードと利用ベースのエージングを使用した非同期ライトスルー・グローバル・キャッシュ・グループが適して

います。

一部のアプリケーションではアクティブなデータへのアクセスが速くなりますが、アクティブなデー

タのセットは、時間によって変化し、より大きなデータ量のサブセットになります。これではデー

タが大きすぎるためキャッシュに全体を保持できません。アクティブなデータは、オンデマンドで

キャッシュに取り込む必要があり、キャッシュのコンテンツはアクティブなデータと古いデータを

置き換えられるように動的である必要があります。

このようなアプリケーションの例に、大容量の同時顧客セッションを管理するコール・センターが

あります。このアプリケーションは通常、いくつかのアプリケーション・サーバー・ノードに渡っ

て配置されます。コール・センターに連絡した顧客は利用可能なアプリケーション・サーバー・ノー

ドに自動的にルーティングされ、適切な顧客プロファイルがそのサーバー・ノード上で利用できる

ようになります。

このシナリオの構成には、動的ロードと利用ベースのエージングを使用し、グリッド・メンバーが

それぞれのアプリケーション・サーバー・ノード上で構成された AWT グローバル・キャッシュ・グ

ループがもっとも適しています。

この構成では、利用可能なサーバー・ノードへ顧客がルーティングされると、適切な顧客プロファ

イルが Oracle データベースからグリッド・メンバーへ動的にロードされます。顧客がコールを完了

すると、顧客のプロファイルへの変更が Oracle IMDB Cache から Oracle データベースへ伝播されま

す。LRU エージングにより、非アクティブな顧客のプロファイルが Oracle IMDB Cache から自動的

に削除されます。初のコールの直後に同じ顧客がコール・センターに連絡して別のノードにルー

ティングされた場合、顧客プロファイルは、新のコピーが存在する場所に応じて、以前ロードさ

れた Oracle データベースまたはグリッド・メンバーのどちらかから新しいノードに動的にロードさ

れます。Oracle IMDB Cache によって、新のコピーがある場所が判断されます。Oracle IMDB Cacheは、グリッド内データへの同時更新も管理します。

すべての顧客データは、Oracle データベースに保存されます。Oracle データベースは、組み合わされ

た Oracle IMDB Cache データベースよりはるかに大きく、Oracle IMDB Cache のリアルタイムのパ

フォーマンスを必要としないが大容量データへのアクセスを必要とするアプリケーションがアクセ

スするのに適です。このようなアプリケーションには、請求書作成アプリケーションやデータ・

マイニング・アプリケーションなどがあります。

顧客ベースが増加し、より多くの顧客に同時に対処する要求が高まるにつれ、コール・センターで

はアプリケーション・サーバー・ノードを追加して配置しようとします。新規の Oracle IMDB Cacheメンバーは、グリッドで進行中の要求を中断することなく、Oracle IMDB Cache グリッドを結合でき

ます。同様に、個々のノードに発生した障害や削除によって残りのグリッドの操作が中断されるこ

とはありません。

6.5 不均等な到着率のデータ取得キャッシュ

不均等な到着率のデータ取得には、利用ベースのエージングを使用した非同期ライトスルー・キャッシュ・グループが適しています。

25


新しいデータが特定の期間中は非常に高い割合で生成され、それ以外の期間では中程度の割合で生

成されるアプリケーション・クラスがあります。アクティビティが盛んな期間、バックエンド・デー

タベースではアプリケーションで要求されるスループットを実現できないことが多くあります。そ

のようなアプリケーションでは、新しく生成されるデータの到着率を事実上"平滑化"するキャッシュ

により利点がもたらされます。

たとえば、株ティッカー・アプリケーションでは、新しい値の到着率が時間によって大幅に変化し

ます。市場の開始時と終了時は特に高く、それ以外の時間は低くなります。ピーク時の到着率は、

ディスクベースのデータベースでは通常処理できませんが、Oracle IMDB Cache では処理できます。

このようなデータには、利用ベースのエージングを使用した（システムで管理される）非同期ライ

トスルー・キャッシュ・グループのキャッシュ構成がもっとも適しています。ライトスルー・キャッ

シュ・グループに挿入された内容は、バックエンドの Oracle データベースに自動的に伝播されます。

また、利用ベースのエージングによりインメモリ・キャッシュからデータが自動的に削除され、キャッ

シュ領域が確保されます。

6.6 到着率が常に高いデータ取得キャッシュ

到着率が常に高いデータを取得するには、利用ベースのエージングを使用した非同期ライトスルー・キャッシュ・グループと利用ベースのエージング

を使用した Oracle TimesTen 表を組み合わせて使用するのがもっとも適しています。

新しいデータが高い割合で生成されても、その高い到着率が必ずしも低下しないアプリケーション・

クラスもあります。バックエンド・データベースでキャッチアップする間がないことが原因で到着

率が低下しない場合は、到着率が高すぎてバックエンド・データベースに吸収されない一時データ

をキャッシュしても、この問題は解決しません。ただし、このようなアプリケーションでは新しく

生成したデータをバックエンド・データベースに永続的に保存する前に、より凝縮した形式で集計

できることがあります。また、リアルタイムで収集したデータを分析して、注視すべきパターンや

異常なパターンを発見できることもあります。

上記のようなアプリケーションの例として、センサーや RFID リーダーからデータを収集するアプリ

ケーションがあります。データは繰返しが多く、収集が容易です。またリアルタイムの分析を必要

とします。

このようなアプリケーションには、データが到着するたびに Oracle TimesTen のみで管理される表に

挿入される構成がもっとも適しています。つまり、バックエンド・データベースにはこのデータの

イメージが存在しません。キャッシュされない Oracle TimesTen のみの表は利用ベースのエージング

で構成できます。データをアプリケーションごとに集計すると、利用ベースのエージングを使用し

た（システムが管理する）非同期ライトスルー・キャッシュ・グループのキャッシュに挿入できる

ようになります。Oracle IMDB Cache は、その集計内容をバックエンド・データベースに自動的に伝

播します。Oracle TimesTen のみの表もキャッシュ表も利用ベースのエージングで構成されるため、

もっとも長い時間使用していないレコードがエージングにより自動的に削除され、新しいレコード

のためにキャッシュの領域が確保されます。

26


6.7 更新可能なユーザー管理キャッシュ

更新は頻繁に行われ、ビジネス・トランザクションは頻繁に行われないアプリケーションの場合は、明示的なフラッシュを使用するユーザー管理キャッ

シュ・グループがもっとも適しています。

アプリケーションによっては、パフォーマンスを適にするためにキャッシュ内で複数の更新を実

行する必要がありますが、終トランザクションは、Oracle Database に永続的に記録しなければなり

ません。そのようなアプリケーションの例として、アクティブなユーザーのショッピング・カート

が大量に維持される e コマース・アプリケーションがあります。ショッピング・カートはキャッシュ

内で繰り返し更新されます。更新された値が小さい場合は、Oracle Database に伝播する必要はありま

せん。ただし、ユーザーが購入を実行すると、そのトランザクションは永続的に Oracle Database に

記録する必要があります。

そのようなデータにはユーザー管理の更新可能キャッシュ・グループの構成がもっとも適しています。

この場合、Oracle Database にトランザクションを記録する必要がある場合にはいつでも、アプリケー

ションで明示的にフラッシュ要求を発行します。この構成と利用ベースのエージングを組み合わせ

ることで、放置されたショッピング・カートがキャッシュから自動的に削除されます。

6.8 読取り専用動的分散キャッシュ

読取り専用動的分散キャッシュには、動的ロードと利用ベースのエージングを使用した読取り専用の表がもっとも適しています。

場合によっては、単一ノードで処理できないスループット率を処理するために複数ノード間でアプ

リケーションを分散できます。また、アプリケーションで必要とされるアクティブなデータのセッ

トは動的であり、常に完全なデータ・セットよりもはるかに小さなサブセットになります。そのよ

うなアプリケーションの例として、アクティブなトレーダーのプロファイルがアクティブなデータ

となる、トレーディング・アプリケーションがあります。

そのようなデータには Oracle Database の同一の表セットに読取り専用キャッシュ・グループを含む

ノードごとにインメモリ・キャッシュを構成するのがもっとも適しており、キャッシュ表では動的

ロードと利用ベースのエージングを使用します。これにより、必要なときに自動的にロードする必

要があるトレーダーのプロファイルが各ノードに含まれるようになります。このプロファイルは不

要になるとエージングによりキャッシュから削除されるため、必要なプロファイルのための領域が

確保されます。

7. 結論

Oracle In-Memory Database Cache を使用することで、パフォーマンスを重視する表のサブセットと表

の断片が Oracle データベースからアプリケーション層にキャッシュされるため、アプリケーション

のトランザクションの応答時間を短縮できます。単純なリザルト・キャッシュのメカニズムとは対照

的に、アプリケーションではキャッシュ・データ上で SQL および PL/SQL コマンドを実行できます。

これは、Oracle TimesTen In-Memory Database では、キャッシュ表が通常のリレーショナル・データ

ベース表として管理されるためです。また、キャッシュは異なるアプリケーション間で共有できます。

27


更新内容はキャッシュに適用できるため、キャッシュとOracle Databaseとの整合性が保持されます。

Oracle IMDB Cache によるデータのキャッシュは、他のキャッシュ技術よりも優れています。ここで

は、完全なリレーショナル機能、位置透過性を伴う段階的なスケーラビリティ、卓越したパフォー

マンス、Oracle Database とのデータ整合性の自動メンテナンスおよび層間の高可用性がアプリケー

ション層で実行されるアプリケーションに提供されるためです。

データをアプリケーションの近くに置き、インメモリ・データベースで問合せを処理することで、

Oracle In-Memory Database Cache の応答時間が大幅に短縮されます。また、Oracle データベース・サー

バーから一部のデータ処理作業の負荷を軽減させることで、集中管理やバックエンド・データベー

スの管理が妨げられることなく、アプリケーション全体のスループットが大幅に改善します。

8. 参考資料

1. 『Extreme Performance Using Oracle TimesTen In-Memory Database』Oracle ホワイト・ペーパー 2009 年 7 月

28

Oracle In-Memory Database Cache による

Oracle データベースの迅速化 2009 年 7 月 Copyright © 2008, 2009, Oracle and/or its affiliates. All rights reserved. 本文書は情報提供のみを目的として提供されており、ここに記載される内容は予告なく変更されることがあります。本文書は一

切間違いがないことを保証するものではなく、さらに、口述による明示または法律による黙示を問わず、特定の目的に対する商

品性もしくは適合性についての黙示的な保証を含み、いかなる他の保証や条件も提供するものではありません。オラクル社は本

文書に関するいかなる法的責任も明確に否認し、本文書によって直接的または間接的に確立される契約義務はないものとしま

す。本文書はオラクル社の書面による許可を前もって得ることなく、いかなる目的のためにも、電子または印刷を含むいかなる

形式や手段によっても再作成または送信することはできません。

Oracle Corporation World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065 U.S.A.

お問い合わせ： Oracle は米国 Oracle Corporation およびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。電話：+1.650.506.7000 ファクシミリ：+1.650.506.7200

oracle.com 0109

Documents