Comments
Transcript
Oracle In-Memory Database CacheによるOracleデータベースの迅速化
Oracle In-Memory Database Cache に よる Oracle データベースの迅速化 Oracle テクニカル・ホワイト・ペーパー 2008 年 3 月 Oracle In-Memory Database Cache による Oracle データベースの迅速化 Oracle TimesTen はマイクロ秒の違いが問 題となるリアルタイム・アプリケーションを 対象としています。Oracle TimesTen によ り、ビジネス･プロセスが迅速化し、リアル タイムなビジネス・インテリジェンスが可能 になり、顧客が使用するアプリケーションが パーソナライズされます。 1. はじめに Oracle In-Memory Database Cache は、キャッシュのパフォーマンスを重視する Oracle データベースのサブセットで、アプリケーション層のレスポンス時間を短 縮するために理想的な Oracle Database 関連製品です。Oracle In-Memory Database Cache は 3 つの主要テクノロジー・コンポーネントで構成されています。Oracle TimesTen In-Memory Database を使用してリアルタイムにデータ管理をおこなうイ ンメモリ・データベース、アプリケーション層でのデータの高い可用性を保証す るトランザクション・データ・レプリケーション・コンポーネント、Oracle デー タベースの頻繁にアクセスされる表をキャッシュするインメモリ・キャッシュ・ コンポーネントです。 Oracle TimesTen In-Memory Database はメモリを最適化したリレーショナル・デー タベースで、パフォーマンスを重視するシステムに非常に短いレスポンス時間で 高いスループットを提供します。アプリケーションに近いアプリケーション層で の実行を対象とし、アプリケーションに組み込んで実行することも対象としてい ます。Oracle TimesTen のインメモリ・データベースは通常のデータベースおよび Oracle Database へのキャッシュとして使用できます。 Oracle TimesTen には 1998 年以来、ネットワーク通信サービス、運用サポート・ システム、コンタクト・センター、航空会社および予約システム、指揮統制シス テム、証券取引などの、リアルタイムな企業やタイム・クリティカルな業界の本 番環境において採用実績があります。何百もの世界中の企業が本番アプリケー ションで Oracle TimesTen を使用しています。おもな企業には、Amdocs、Aspect、 Avaya、Bombay Stock Exchange、Bridgewater Systems、Cisco、Deutche Borse Systems AG、Ericsson、JP Morgan、Lucent、NEC、Nokia、Salesforce.com、Smart Communications や Sprint があります。 アプリケーションでは Oracle TimesTen のインメモリ・データベースにデータベー ス表を作成して管理したり、頻繁に使用する Oracle Database のサブセットをイン メモリ・キャッシュ表にキャッシュしたりできます。Oracle データベースおよび 通常の Oracle TimesTen の表からキャッシュされた表は、同じインメモリ・データ ベースに共存できます。これらの表はすべて永続的でリカバリ可能です。キャッ シュに対する問合せおよび更新は、標準 SQL を使用してアプリケーションから実 行できます。異なる中間層サーバーで実行中のアプリケーションは、同じバック エンドの Oracle データベースで異なるサブセット、または重複するサブセットを キャッシュする場合があります。Oracle In-Memory Database Cache では優れたパ フォーマンスをアプリケーションに提供しつつ、キャッシュとバックエンド・デー タベースとの同期状態を自動的に保ちます。 Oracle In-Memory Database Cache による Oracle データベースの迅速化 2 Oracle Corporation 発行「Using Oracle In-Memory Database Cache to Accelerate the Oracle Database」の翻訳版です。 2. アプリケーション層のキャッシュ アプリケーション層のキャッシュは通常、 データ・アクセスの待機時間の短縮やバック エンド・データベースのワークロード軽減に 使用されます。 データベースのアクセス・パフォーマンスを改善したり、バックエンドのデータ ベース・サーバーの競合を軽減したりするため、さまざまなキャッシュ技術が開 発されています。リアルタイム・アプリケーションやエンド・ユーザーと対話す るアプリケーションでは、迅速なレスポンス時間がとくに重要です。また、バッ クエンドのデータベースのワークロードを削減すると、ユーザーが増え続けてい るホスト型ソフトウェア・サービス、e コマース・サイトや通信サービスなどのア プリケーションにも影響します。 キャッシュする情報とその情報のキャッシュ先には、多くの選択肢があります。 どの選択肢にも利点とトレードオフがあります。開発済みのキャッシュ技術には 次のようなものがあります。 • 問合せ結果キャッシュ。この技術は通常、アプリケーション層で使用され、 アプリケーションからキャッシュを非表示にする特殊なソフトウェアで管理 されます。このシナリオでは、データベース・システムに送信された問合せ の結果がキャッシュ・ソフトウェアによって自動的に保存されます。パラメー タ値が同じであるなど、その問合せが以前に送信された問合せと完全に一致 する場合は、キャッシュ・ヒットとして認識され、キャッシュからの処理が おこなわれます。このようなキャッシュは単純であり、同じ問合せが繰返し 送信されるようなアクセス・シナリオにも対応できる点が優れています。た だし、キャッシュのコンテンツでは問合せ処理ができないため、範囲が制限 されています。 • オブジェクト・リレーショナル・マッピング・ツール・キャッシュ。Oracle TopLink や Jboss Hibernate などのオブジェクト・リレーショナル・マッピング・ ツール（O/R マッピング・ツール）では、オブジェクトとリレーショナル・ データとのマッピングが透過的になるため、オブジェクト指向のプログラマ からはリレーショナル・データベースが非表示になります。リレーショナル・ データをオブジェクト表現にマッピングすると、そのデータが不要になるか 古くなるまで、O/R マッピング・ツールによってキャッシュされます。O/R マッピング・ツールによるキャッシュは、プログラミング言語のオブジェク ト・モデルとデータベースのリレーショナル・モデルとのマッピングのコス トが増大することを防ぐための一般的な技術です。 • Oracle TimesTen のキャッシュはフル・リレーショ ナルな SQL 機能、Oracle Database とのデータ整 合性の自動的なメンテナンス、およびリアルタイ ムなパフォーマンスを備えています。 オブジェクト・キャッシュ。ここでは、キャッシュという呼び名はいくらか 誤りがあります。このキャッシュで終了するオブジェクトはかならずしも別 の場所に保存されたオブジェクトのサブセットではないためです。このよう な"キャッシュ"は、オブジェクトの発生元から独立したオブジェクトのリポジ トリです。通常はアプリケーションに対して透過的ではありません。アプリ ケーションでは、キャッシュのオブジェクトに対して"配置"、"取得"、"挿入"、 および"削除"をおこないます。市場にはそのようなキャッシュを提供する製品 がいくつかあり、製品はサポートする機能レベルによって異なります。キャッ シュは完全にメモリに常駐する場合もあれば、ディスクや別のデータ管理シ ステムに戻される場合もあります。並行処理制御を提供する製品や、ネット ワーク内の複数ノードに透過的な分散をおこなう製品、可用性に優れた製品 もあります。 Oracle In-Memory Database Cache はキャッシュに関して、現在市場にあるどの製品 も使用していない独自のアプローチをしています。この製品を使用することで、 表や表の一部分を Oracle Database からアプリケーション層にキャッシュできます。 表の部分は拡張 SQL 構文で定義され、インメモリ・キャッシュ表にキャッシュさ れます。アプリケーションでは標準 SQL を使用してインメモリ・キャッシュの読 取り、更新をおこない、Oracle In-Memory Database Cache により、更新内容がバッ Oracle In-Memory Database Cache による Oracle データベースの迅速化 3 Oracle Corporation 発行「Using Oracle In-Memory Database Cache to Accelerate the Oracle Database」の翻訳版です。 クエンド DBMS からキャッシュ、またはその逆方向に自動的に伝播されます。そ のため、Oracle In-Memory Database Cache によりアプリケーションにリレーショナ ル・データベースのすべての一般原則と機能が提供され、Oracle Database とキャッ シュの整合性が透過的にメンテナンスされ、インメモリ・データベースのリアル タイムなパフォーマンスが提供されます。 Oracle In-Memory Database Cache のアプローチには、パフォーマンス全体の改善に 役立つおもな利点が 2 つあります。1 つ目は、インメモリ・キャッシュを使用す るアプリケーションのレスポンス時間が大幅に短縮され、スループットが向上す る点です。これは、Oracle TimesTen データベースのインメモリ・アーキテクチャ によるものと、Oracle TimesTen データベースがアプリケーションの実行中や同一 マシンの共有メモリ IPC から実行できるため、アプリケーション層とデータベー ス・サーバーとで通信がおこなわれなくなるためです。2 つ目は、バックエンド・ データベースのワークロードが軽減されるため、すべてのアプリケーションのス ループット全体が向上する点です。 リレーショナル・データベースのあらゆる利点をリアルタイムなパフォーマンス、 使用ディスク領域の削減、組込み可能性とともに提供する機能は、Oracle TimesTen In-Memory Database に固有のものです。つまり、Oracle In-Memory Database Cache はパフォーマンスを重視する Oracle データベースのサブセットのキャッシュに 理想的です。これにより読取りも更新も可能になり、キャッシュと Oracle データ ベースとのデータ整合性が自動的に管理されるようになります。 次の 2 つの項では Oracle TimesTen In-Memory Database を簡単に紹介し（詳細につ いては[1]を参照）、Oracle In-Memory Database Cache を使用したデータのキャッ シュ方法について説明します。キャッシュに関する重要なシナリオもいくつか説 明します。 Oracle TimesTen In-Memory Database により、 標準 API を使用したトランザクションでデータ やリレーショナル機能にアクセスできるように なります。 3. Oracle TimesTen In-Memory Database Oracle TimesTen In-Memory Database はメモリに最適化されたリレーショナル・ データベースであり、標準 SQL-92 から ODBC および JDBC API に対応していま す。Oracle TimesTen はメイン・メモリにあるデータ上で動作しますが、Oracle TimesTen データベースはソフトウェア、ハードウェアの障害、電源異常時にも永 続的で、リカバリが可能です。永続性はチェックポイントからディスクへのロギ ングまで保証されます。アプリケーションのトランザクションには ACID プロパ ティを選択できますが、よりパフォーマンスを高めるための柔軟なオプションを 使用することもできます。Oracle TimesTen ではコストベースの問合せオプティマ イザが提供され、アプリケーションによっては問合せプランを表示して変更でき ます。Oracle TimesTen データベースはライブラリとして使用し、アプリケーショ ンやクライアント/サーバーのオプションからリンクすることが可能です。クライ アント/サーバーのオプションから Oracle TimesTen にアクセスすると、 アプリケー ションと Oracle TimesTen サーバーが同一マシン上で実行されていても、Oracle TimesTen への要求時のプロセス間通信でオーバーヘッドが発生します。それに対 し、Oracle TimesTen がアプリケーションとリンクしている場合は、Oracle TimesTen に対して要求をおこなってもサブルーチンが呼び出されるだけで、ごくわずかな オーバーヘッドしか発生しません。また、アプリケーションと Oracle TimesTen と でデータ転送をおこなっても安価なメモリ・コピー操作しか発生しません。レプ リケーションにより、可用性が向上します。インタラクティブな SQL ユーティリ ティ、オンライン・バックアップとリストア、バルク・ロードなど、さまざまな ユーティリティも使用できます。データベース・メンテナンス操作はプログラム Oracle In-Memory Database Cache による Oracle データベースの迅速化 4 Oracle Corporation 発行「Using Oracle In-Memory Database Cache to Accelerate the Oracle Database」の翻訳版です。 による API から使用することも可能です。 コピーされたデータベースは、実行時にはメイン・メモリにあります。このデー タベースは、そのデータベースに接続したどのプロセスからもアクセスできる共 有メモリ・セグメントで管理されます。図 1 は Oracle TimesTen In-Memory Database システムのアーキテクチャを示しています。 Oracle TimesTen のデータ構造とアルゴリズム は、データのメモリ領域に合わせて最適化され ます。 Oracle TimesTen のデータ構造とアクセス・アルゴリズムによりデータベースのイ ンメモリ領域が検索されるため、パフォーマンスが飛躍的に改善されます。完全 にキャッシュされたディスクベースのデータベースと比較すると、メモリに最適 化された Oracle TimesTen のアーキテクチャでは使用される CPU のサイクルが格 段に少なくなります。これは、メモリのバッファを管理するオーバーヘッドや複 数のデータ・ロケーション（ディスクとメモリ）のアカウントが排除されるため です。 メモリに最適化された Oracle TimesTen のパフォーマンスはトランザクションの プロパティや永続性メカニズムを提供し、システム障害からのリカバリを可能に する機能によって補完されます。 ロック、マルチユーザー分離、ロギングに関してはさまざまな選択肢があり、一 時的な検索のキャッシュから重要なトランザクション型金融取引や通信請求シス テムまで、さまざまなアプリケーション・シナリオに対応できます。 図 1 Oracle TimesTen のアーキテクチャ Oracle TimesTen データベースは永続的でリカ バリ可能です。 Oracle TimesTen の永続性は、コミットされたトランザクションの変更をディスク にログとして記録し、チェックポイントによって定期的にデータベースのディス ク・イメージを更新することで実現されます。ディスクがログに書込みをおこな うタイミングは、トランザクション終了時に同期的におこなうか、あとでおこな うかのどちらかをアプリケーションで設定します。あとでおこなうほうがパ フォーマンスは上がります。大抵の場合、とくに通信ネットワーク内で携帯電話 の位置を数秒ごとに追跡する場合など、取引金額が低く、トランザクション・デー タが一時的な場合は、同期ロギングよりもスループットが向上するほうが好まれ ます。 Oracle TimesTen では、アプリケーションで特定表の変更内容を追跡することが可能で す。これは、特定イベントの発生に敏感なアプリケーションの環境で役立ちます。た とえば、アプリケーションによっては、特定株式の価格がいつ所定のしきい値を超え たかを把握する必要があります。この変更通知機能は実表の変更だけでなく、マテリ Oracle In-Memory Database Cache による Oracle データベースの迅速化 5 Oracle Corporation 発行「Using Oracle In-Memory Database Cache to Accelerate the Oracle Database」の翻訳版です。 アライズド・ビューの変更も追跡できるため、とくに役立ちます。 3.1 Oracle TimesTen のパフォーマンス ハードウェアを追加しただけでは、それほどレ ス ポ ン ス 時 間 を 短 縮 で き ま せ ん 。 Oracle TimesTen では固有のアーキテクチャにより、 待機時間を大幅に短縮できます。 Oracle TimesTen ではインメモリ・アーキテクチャにより、マイクロ秒単位のレス ポンス時間が可能になります。Oracle TimesTen In-Memory Database では、データ ベース・レコードを読み取るトランザクションの場合、所要時間は 5 マイクロ秒 未満（マイクロ秒は 1 秒の 100 万分の 1）、レコードの更新または挿入をおこな うトランザクションの所要時間は 15 マイクロ秒未満です。 図 2 Oracle TimesTen のレスポンス時間 図 2 は、AMD Opteron 1.8GHz プロセッサの Red Hat Linux で測定した、読取りお よび更新のトランザクションをおこなうアプリケーションのレスポンス時間を示 しています。 4. Oracle In-Memory Database Cache を使用したデータ・ キャッシュ Oracle In-Memory Database Cache を使用すると、 アプリケーション層で実行されるイン インメモリ・データベース・キャッシュに は、Oracle Database 表のサブセットが含 まれます。 メモリ・データベースに、完全に Oracle TimesTen データベースに属する通常の表の ほかに Oracle Database からキャッシュされた表も含まれる場合があります。キャッ シュされた表は拡張 SQL 構文で記述された Oracle 表のサブセットである場合があり ます。また、拡張 SQL により Oracle 表から選択し、キャッシュされた表に射影する ことができます。 Oracle In-Memory Database Cache による Oracle データベースの迅速化 6 Oracle Corporation 発行「Using Oracle In-Memory Database Cache to Accelerate the Oracle Database」の翻訳版です。 図 3 Oracle TimesTen を使用したキャッシュ インメモリ・キャッシュ表はそれ自体がほかの Oracle TimesTen データベースに複 製される場合があります。または、重複するキャッシュが独立して Oracle データ ベースと同期する個別のキャッシュとして設定される場合もあります。設定に関 する選択肢はアプリケーションによって異なります。設定に関するさまざまな例 をこのホワイト・ペーパーの最後の項に挙げています。 4.1 キャッシュのコンテンツの定義 Oracle TimesTen のキャッシュのコンテン ツは、拡張 SQL 構文によって定義されます。 キャッシュ内容を定義するために、Oracle In-Memory Database Cache では Cache Administrator を提供しています。Cache Administrator ツールはブラウザベースで使 いやすく、アプリケーションの設計者が選択した Oracle バックエンド・データベー スのスキーマを表示できます。ユーザーは、キャッシュする必要があるサブスキー マを、キャッシュ・グループの概念を使用してそのスキーマから選択します。 キャッシュ・グループとは、Oracle TimesTen のインメモリ表のセットです。この 表は Oracle Database 内で（外部キー制約によって）関連し、頻繁に使用される表 のセットにあたります。SQL 構文はキャッシュ・グループを定義し、関連表のセッ トからキャッシュする列と行を選択するために使用します。Cache Administrator は、ユーザーがキャッシュ・グループを定義する際の支援や、適切な SQL 構文の 自動生成をおこないます。ユーザーはプログラムを使用したり、インタラクティ ブな ttIsql ユーティリティから SQL 構文を使用したりして、キャッシュ・グルー プを定義することも可能です。 以下に例を示します。 以下の表が Oracle Database に存在するとします。 − − − Customer（CustId、Name、Age、Gender、StreetAddress、State、ZipCode、 PhoneNo） Order（CustId、OrderId、PurchaseDate、Amount） CustInterest（CustId、Interest） アプリケーションで、2007 年 1 月 1 日から発注をおこなっている顧客の プロファイルをキャッシュします。そのために、以下の 2 つのキャッ シュ・グループを定義します。 Oracle In-Memory Database Cache による Oracle データベースの迅速化 7 Oracle Corporation 発行「Using Oracle In-Memory Database Cache to Accelerate the Oracle Database」の翻訳版です。 • 1 つ目のキャッシュ・グループには、上の 3 つの表のサブセットが 含まれます。このキャッシュ・グループは 2007 年 1 月 1 日以降に発 注をおこない、米国の太平洋沿いに住んでいる顧客を対象としてい ます。さらに、アプリケーションでは表の列のサブセットのみを キャッシュするように選択することも可能です。たとえば、以下の 列をキャッシュします。 − − − • Customer（CustId、Name、Age、Gender、State） Order（CustId、PurchaseDate、Amount） CustInterest（CustId、Interest） 2 つ目のキャッシュ・グループにも 1 つ目のキャッシュ・グループ と同じ情報が含まれますが、対象の顧客は米国の山沿いに住んでい ます。 この 2 つのキャッシュ・グループは Oracle In-Memory Database Cache を実 行している別のノードにキャッシュできます。 Oracle In-Memory Database Cache ではこのほかに、キャッシュ・インスタンスの概 念が使用されます。キャッシュ・インスタンスとは一意に識別可能な関連レコー ドの集合であり、複雑なオブジェクトのモデル化に使用されます。キャッシュ・ インスタンスによりキャッシュをロードする単位が形成されます。キャッシュ・ エージングについては後ほど説明します。上記の例では、所定の顧客 ID（CustId） が割り当てられた Customer、Order、CustInterest 表のすべてのレコードは同じ キャッシュ・インスタンスに属し、互いに外部キー制約によって関連づけられて います。CustId はキャッシュ・インスタンスを一意に識別するため、キャッシュ・ インスタンス・キーと呼ばれます。 独自のデータ型に対応するだけでなく、Oracle TimesTen は Oracle Database と同じ Oracle TimesTen は Oracle Database と 同じデータ型に対応しています。 基本データ型にも対応しています。そのため、Oracle のデータ型を Oracle TimesTen のデータ型にマッピングする必要がありません。ただし、Oracle のデータ型をよ り効率的な Oracle TimesTen 実装にマッピングすることもできます。たとえば、ア プリケーションで Oracle の NUMBER データ型を Oracle TimesTen の INTEGER デー タ型にマッピングできます。 アプリケーション開発者はインメモリ・キャッシュ表に索引を作成できます。イ ンメモリ・キャッシュの索引は Oracle Database の索引と一致する場合もあれば、 一致しない場合もあります。アプリケーション設計者は Oracle TimesTen のインメ モリ・データベースの柔軟性を利用して、複数の索引を同一表に作成したり、複 数列にわたって索引を定義したりできます。 4.2 データのロードとキャッシュの管理 キャッシュ・グループを定義すると、アプリケーションでは、Oracle データベー スから処理をおこなうインメモリ・データベース・キャッシュに、キャッシュ・ グループによって記述されたデータをロードする方法を決定する必要があります。 データのロードには以下の手法を使用できます。 動的キャッシュでは透過的ロードと キャッシュ・エージングが使用されます。 • キャッシュ・グループ全体を一度にロード。この手法は、キャッシュ・グルー プ全体のコンテンツがそのキャッシュに適合している場合に向いています。 キャッシュ・グループ全体をアンロードすることも可能です。 • キャッシュ・インスタンスを透過的にロード。透過的ロードはキャッシュ・ コンテンツが動的である場合に役立ちます。この場合、SELECT 問合せで要 求したデータがキャッシュに見つからないと、キャッシュ・インスタンスを 構成するレコードが自動的にキャッシュにロードされます。キャッシュ・イ Oracle In-Memory Database Cache による Oracle データベースの迅速化 8 Oracle Corporation 発行「Using Oracle In-Memory Database Cache to Accelerate the Oracle Database」の翻訳版です。 ンスタンスがキャッシュ内にある場合は、キャッシュから直接、SELECT 問 合せが実行されます。この手法は、キャッシュの処理能力ではキャッシュ・ グループで記述したすべてのデータを保持できない場合に役立ちます。 透過的ロードは通常、自動キャッシュ・エージング機能と組み合わせられま す。キャッシュの処理能力を超えると、キャッシュ・インスタンスはエージ ングによりキャッシュから自動的に削除されます。Oracle In-Memory Database Cache は利用ベースのエージングと時間ベースのエージングに対応していま す。利用ベースのエージングでは LRU（Least Recently Used）スキームを使用 して、キャッシュ処理能力の超過時にキャッシュ・インスタンスをエージン グによって削除します。時間ベースのエージングはキャッシュ・インスタン スにキャッシュの一定期間のライフタイムを与えます。そのため、キャッ シュ・グループのいずれか 1 つの表にタイムスタンプ列を必要とします。タ イムスタンプ列の値はアプリケーションごとに管理されます。キャッシュ・ インスタンスは、タイムスタンプの値とライフタイムを足した値が現在の時 刻を超えるまで、キャッシュに保持されます。キャッシュ・エージングは透 過的ロードから独立して使用できます。実際は、Oracle データベースから キャッシュされない Oracle TimesTen の通常の表とともに使用されます。 アプリケーションではどのキャッシュ・グループをエージングの対象にする かを選択できます。たとえば、アプリケーションではキャッシュに常にカタ ログ情報を保持できます。それとは別に、ユーザーがアプリケーションに接 続した際にユーザーのプロファイルをオンデマンドでロードしたり、ユー ザーが接続を切断すると、自動的にプロファイルをエージングによって削除 したりできます。キャッシュ・インスタンスはアプリケーションによって明 示的にアンロードすることも可能です。 • "WHERE 句によって"キャッシュ・インスタンスをロード。この場合、WHERE 句を使用してキャッシュに取り込むキャッシュ・グループのサブセットを記 述します。自動キャッシュ・エージングは WHERE 句でロードすると使用で きます。アプリケーションの"WHERE 句によって"キャッシュ・インスタンス をアンロードすることも可能です。 インメモリ・キャッシュ表にロードされたデータは JDBC または ODBC による SQL 処理に使用できます。 4.3 データ整合性の維持 Oracle TimesTen キャッシュは更新可能で あるため、キャッシュ・データと Oracle Database との整合性が自動的に維持され ます。 通常処理中は、アプリケーションでインメモリ・データベース・キャッシュに キャッシュされたデータの読取りおよび更新をおこないます。アプリケーション のノードが同一でも異なっていても、キャッシュを共有できます。さらに、バッ クエンドの Oracle データベースが同じでキャッシュが異なる場合は、ノードが同 じであったり、異なったりします。これらのキャッシュは同一であるか、異なる Oracle データベースのサブセットを含むか、または一部が重複している可能性が あります。たとえば、アプリケーション層はサブスクライバのサブセット処理専 用の複数のサーバーで構成されています。サブスクライバは郵便番号、国番号、 ユーザーID などにしたがってパーティション化されます。そのようなスキームの 場合、各サーバーにキャッシュされたデータには Oracle データベースのさまざま なサブセットが含まれます。 キャッシュされたデータはインメモリ・データベース・キャッシュ内または Oracle Database 内で更新されます。Oracle In-Memory Database Cache を使用することで、 キャッシュから Oracle Database への更新およびその逆方向の更新を自動的に伝播 Oracle In-Memory Database Cache による Oracle データベースの迅速化 9 Oracle Corporation 発行「Using Oracle In-Memory Database Cache to Accelerate the Oracle Database」の翻訳版です。 させることができます。ただし、キャッシュ・グループのほとんど、またはすべ てがキャッシュされるか、Oracle Database で更新されることが前提です。キャッ シュおよびバックエンド・データベースでの大量な更新が予想される表のセット をキャッシュするデザイン・フローではこれが主流です。ただし、キャッシュお よびバックエンドの Oracle データベースでの更新を許可するほうが適しているシ ナリオもあります。たとえば Oracle データベースでの更新はメンテナンス上の理 由により夜間にしか発生せず、キャッシュの更新が日中に発生する場合や、中央 データの更新が Oracle データベースで発生し、地域データの更新はキャッシュで 発生する場合などです。 キャッシュ・グループはシステム管理またはユーザー管理のいずれかです。シス テム管理キャッシュ・グループには次の 3 つの種類があります。 • 読取り専用。このキャッシュ・グループはキャッシュ内で更新されません。 Oracle データベース内で更新され、Oracle In-Memory Database Cache により Oracle データベースからキャッシュへの更新の伝播が管理されます。 • 非同期ライトスルー。このキャッシュ・グループはキャッシュ内では更新さ れますが、Oracle データベース内では更新されません。トランザクションの コミット後、Oracle In-Memory Database Cache によりキャッシュから Oracle データベースへ更新が非同期的に伝播されます。 • 同期ライトスルー。このキャッシュ・グループはキャッシュ内では更新され ますが、Oracle データベース内では更新されません。インメモリ・キャッシュ 表の更新が、トランザクションのコミットと同時に Oracle データベースに同 期的に伝播されます。 システム管理キャッシュ・グループには、セマンティックとそのセマンティック を実施するための制限が明確に定義されています。反対に、ユーザー管理キャッ シュ・グループのセマンティックはアプリケーションに委ねられています。たと えば、ユーザー管理キャッシュ・グループはキャッシュと Oracle データベースの 両方で更新できます。 Oracle In-Memory Database Cache アプリケーションは、Oracle TimesTen データベー スに単独で接続することで、SQL 文をキャッシュ・グループまたは Oracle Database のいずれかに送信できます。この単独接続機能はパススルー機能により有効にな ります。この機能では、SQL 文がインメモリ・キャッシュ表によりローカルで処 理できるのか、または Oracle Database にリダイレクトする必要があるのかを チェックします。パススルー機能の設定では、どのタイプの文をパススルーする か、およびどの状況でパススルーするかを指定します。なかでも、データベース を更新する文をすべて Oracle Database に渡すように指定する設定は、とくに役立 ちます。この設定により、Oracle Database での実行内容をアプリケーションで更 新することができ、単独接続によって Oracle In-Memory Database Cache での実行内 容の読取りがおこなわれます。 以 下 の 項 で は キャッシュ ・ データの整 合 性維持のた め に使用でき る Oracle In-Memory Database Cache 操作について説明します。そのうち、一部の操作は Oracle In-Memory Database Cache によって自動的に開始されますが、それ以外の操作はア プリケーションによって明示的に開始する必要があります。 Oracle In-Memory Database Cache による Oracle データベースの迅速化 10 Oracle Corporation 発行「Using Oracle In-Memory Database Cache to Accelerate the Oracle Database」の翻訳版です。 4.3.1 バックエンド・データベースから Oracle In-Memory Database Cache への 更新伝播 Oracle データベースで更新されるキャッシュ・グループの場合、以下のメカニズ ムを使用してキャッシュのコンテンツと Oracle データベースとの同期状態を維持 できます。 • リフレッシュ。リフレッシュは、キャッシュ・グループ全体または特定のキャッ シュ・インスタンスのリフレッシュに関する、アプリケーションからの明示的な 要求です。この要求はアンロード操作後のロード操作に相当します。 • 完全自動リフレッシュ。完全自動リフレッシュにより、アプリケーションに リフレッシュの実行頻度が示され、Oracle In-Memory Database Cache のキャッ シュ・グループがアプリケーションに示された間隔ごとに自動的にリフレッ シュされます。 • 増分自動リフレッシュ。完全自動リフレッシュとは異なり、増分自動リフレッ シュでは Oracle データベース内で最後のリフレッシュ以降に修正されたレ コードのみが更新されます。完全自動リフレッシュと同様、アプリケーショ ンにリフレッシュの頻度が示され、Oracle In-Memory Database Cache ではその 頻度ごとに増分リフレッシュが自動的に実行されます。 増分自動リフレッシュはスライディング・ウィンドウをキャッシュに保持す るための、時間ベースのエージングで使用します。たとえば、顧客サポート・ アプリケーションの場合、過去 5 日間に報告されたすべてのインシデントを キャッシュに保持する必要があります。この場合、キャッシュ・グループで 増分自動リフレッシュを使用し、時間ベースのエージングのライフタイムを 5 日間にするように指定できます。新しいインシデントが Oracle データベース に挿入されると、増分自動リフレッシュによってそのインシデントがインメ モリ・キャッシュ表に自動的に伝播されます。インシデントが Oracle Database 内で更新されると、その更新内容がインメモリ・キャッシュ表に自動的に伝 播されます。インシデントにはアプリケーションによってメンテナンスされ るタイムスタンプが必要です。タイムスタンプの値が現在の日付の 5 日前よ り古くなると、関連するインシデントがエージングにより、キャッシュから 自動的に削除されます。 上に挙げた 3 つの手法は、さまざまな状況で役立ちます。1 日 1 回、コンテンツ・ プロバイダのサイトのアクティビティが最小になる午前 2 時にキャッシュ・グ ループをリフレッシュする必要があるとします。この場合、完全自動リフレッシュ が最適です。一方、5 分ごとにリフレッシュする必要があるキャッシュ・グルー プの場合は、増分自動リフレッシュが適しています。また、頻繁なリフレッシュ が必要ではなく、リフレッシュの時期が予測不能でアプリケーションにしか把握 されないキャッシュ・グループの場合は、リフレッシュ・オプションを使用する 必要があります。 アプリケーション（複数可）は同一のバックエンド・データベースに対し、複数 のキャッシュを構成できます。キャッシュは完全に分離させたり、一部重複させ たり、同一にしたりできます。Oracle Database からすべてのキャッシュへの更新 が伝播されると、Oracle In-Memory Database Cache で管理されます。 Oracle In-Memory Database Cache による Oracle データベースの迅速化 11 Oracle Corporation 発行「Using Oracle In-Memory Database Cache to Accelerate the Oracle Database」の翻訳版です。 図 4 キャッシュ・グループの増分自動リフレッシュ 4.3.2 インメモリ・キャッシュから Oracle データベースへの更新伝播 キャッシュ内で更新されるキャッシュ・グループの場合、以下のメカニズムを使 用して Oracle データベースとキャッシュとの同期状態を保つことができます。 • 伝播。伝播オプションを有効にすると、挿入、更新、削除など、キャッシュ・ グループのすべての修正がバックエンドの Oracle Database に自動的に伝播さ れます。伝播をおこなうタイミングは同期ライトスルーのキャッシュ・グルー プと非同期ライトスルーのキャッシュ・グループとで異なります。同期ライ トスルーのキャッシュ・グループの場合、キャッシュ・グループが修正され ているトランザクションがアプリケーションで完了すると、トランザクショ ンは最初に Oracle データベースでコミットされ、次にインメモリ・キャッ シュ・データベースでコミットされます。この手法では、データに関連する 必要なロジックをインメモリ・キャッシュ・データベースでコミットする前 に Oracle Database で適用できます。非同期ライトスルーのキャッシュ・グルー プの場合、アプリケーションでトランザクションが完了すると、そのトラン ザクションはキャッシュ・データベースでコミットされ、制御がアプリケー ションに戻ります。その後、トランザクションでおこなわれた変更が非同期 的に Oracle Database に伝播されます。 • フラッシュ。この操作はアプリケーションからの明示的な要求によっておこ なわれ、キャッシュ・グループまたはキャッシュ・インスタンスに適用され ます。伝播オプションが無効になっているキャッシュ・グループとキャッ シュ・インスタンスにしか使用できません。この操作では、Oracle Database のレコードがキャッシュにあるレコードの値で更新されます。この操作は、 同じレコード・セット上で特定の期間に頻繁に更新がおこなわれる場合に役 立ちます。各更新を実行のたびに伝播するのではなく、各レコードの最終イ メージが Oracle Database に送信および適用されます。 Oracle In-Memory Database Cache による Oracle データベースの迅速化 12 Oracle Corporation 発行「Using Oracle In-Memory Database Cache to Accelerate the Oracle Database」の翻訳版です。 アプリケーションでは同一のバックエンド Oracle データベースに対し、複数のライト スルー・キャッシュを構成できます。キャッシュからバックエンド・データベースに 更新が伝播されると、Oracle In-Memory Database Cache で管理されますが、同じバック エンドに対する異なるライトスルー・キャッシュが互いに重複しないようにすること を推奨します。これは、同じデータに対して同時に複数の更新が別のノードで発生す ると、バックエンドで予測不能なデータ値が発生するためです。 図 5 更新の伝播 4.3.3 Oracle TimesTen のノード間の更新伝播 Oracle TimesTen のレプリケーションをさまざまなノードに構成することで、ノー ド間のキャッシュ・データの整合性を維持しつつ、ロード・バランシングや可用 性を向上させることができます。レプリケーションは読取り専用キャッシュ・グ ループ間やライトスルー・キャッシュ・グループ間で構成することができます。 同一の読取り専用キャッシュ・グループを有する 100 件のキャッシュ・ノードを 配置するアプリケーションの例を考えてみます。Oracle Database から直接増分自 動リフレッシュするキャッシュを 100 件設定するのではなく、アプリケーション にはキャッシュを 10 件のみ構成します。そして、これらのキャッシュのそれぞれ がデータを残りの 9 つの Oracle TimesTen データベースへ複製するようにして構成 します。 同様に、可用性を高めるため、マスター・キャッシュ・グループを保持するノー ドがダウンした場合に備えて、アプリケーションでそれぞれのライトスルー・ キャッシュ・グループの複製をメンテナンスする必要があります。 4.4 高可用性 Oracle TimesTen は中間層およびバックエ ンド・データベースの高可用性をサポートし ています。 Oracle TimesTen をデータベースとして単体で使用すると、Oracle Database のイン メモリ・データベース・キャッシュとして使用した場合とは対照的に、レプリケー ションによるデータや各種オンライン操作、フェイルオーバー、リカバリ、オン ライン・アップグレードをサポートするさまざまなユーティリティによって可用 性を保障します。同様に、Oracle Database では Oracle Real Application Clusters （Oracle RAC）、Oracle Automatic Storage Management（Oracle ASM）および Oracle Data Guard などの機能セットにより、データの可用性向上をサポートします。さ らに、Oracle In-Memory Database Cache のレプリケーション・コンポーネントで提 供される機能により、キャッシュ・データの可用性が高まり、アプリケーション 層およびデータベース層の Oracle データベースに及ぶ障害から自動的に復旧でき Oracle In-Memory Database Cache による Oracle データベースの迅速化 13 Oracle Corporation 発行「Using Oracle In-Memory Database Cache to Accelerate the Oracle Database」の翻訳版です。 ます。 Oracle In-Memory Database Cache による Oracle データベースの迅速化 14 Oracle Corporation 発行「Using Oracle In-Memory Database Cache to Accelerate the Oracle Database」の翻訳版です。 4.4.1 Oracle Database での障害処理 ネットワーク障害、ハードウェア障害、Oracle Database 障害などの理由を問わず Oracle In-Memory Database Cache が Oracle Database にアクセスできなくなった場合、 Oracle In-Memory Database Cache では障害に対する弾力性を保つように設計され ています。インメモリ・キャッシュは引き続きアプリケーションからアクセスで きます。さらに、非同期ライトスルー・キャッシュ・グループの場合はキャッシュ の更新が引き続き Oracle TimesTen に記録されるため、再度 Oracle Database にアク セスできるようになると、その更新内容が Oracle Database に伝播されます。同様 に、Oracle Database の読取り専用キャッシュ・グループに対して実行された変更 でまだインメモリ・キャッシュに伝播されていないものは、Oracle データベース に記録が残り、再度 Oracle データベースにアクセスできるようになるとキャッ シュにその記録が伝播されます。 さらに、Oracle In-Memory Database CacheはOracle RACの高可用性機能を最大限に 活用します。Oracle RACの構成は複数ノードからアクセス可能な単一の物理デー タベースで成り立っています。単一ノードの実行時構成はインスタンス 1と呼ばれ ます。Oracle RACにより、ロード・バランシング、高可用性、インスタンス全体 にわたるデータ整合性が実現されます。 Oracle In-Memory Database Cache では、ユーザーの介入なしに RAC ノード障害か ら迅速に復旧します。このため、Oracle In-Memory Database Cache では常に Oracle の透過的アプリケーション・フェイルオーバー（TAF）および高速アプリケーショ ン通知（FAN）機能が使用されます。ただし、Oracle クライアントのバージョン、 サーバー、TAF の構成によっては使用できないことがあります。Oracle In-Memory Database Cache の接続先である Oracle インスタンスに障害があると、自動的に別 のインスタンスに接続されます。障害発生時にリフレッシュ、完全自動リフレッ シュ、または増分自動リフレッシュを操作していた場合、インメモリ・データベー スで発生した変更内容は自動的にロールバックされ、操作が再度実行されます。 障害発生時に非同期ライトスルー・キャッシュ・グループの伝播操作中だった場 合、ロールバックが必要であれば Oracle Database で発生した変更内容が自動的に ロールバックされ、トランザクションの伝播操作が再度実行されます。 4.4.2 インメモリ・キャッシュ・ノードの障害処理 キャッシュ・データをキャッシュ・ノードの障害から保護し、絶え間なく使用で きるようにするため、Oracle TimesTen のレプリケーション機能ではキャッシュ・ ノードの障害およびリカバリ処理をおこないます。複数の読取り専用サブスクラ イバによるアクティブ・スタンバイ・ペアのレプリケーション構成は、構成の一 部に Oracle Database を含み、キャッシュ・ノードのフェイルオーバーとリカバリ を提供するように設計されています。 アクティブ・スタンバイ・ペアでは、すべての更新内容が常にアクティブ・ノー ドから適用されます。次に更新内容はスタンバイ・ノードに複製され、後にスタ ンバイ・ノードからすべての読取り専用サブスクライバ・ノードに複製されます。 そのため、スタンバイ・ノードはどの読取り専用サブスクライバ・ノードよりも かならず上位にあります。これにより、アクティブ・ノードがダウンしても、ど のサブスクライバ・ノードが次のアクティブ・ノードになるかが明確に決定しま す。 1 実際は、単一ノードに複数のインスタンスが存在します。 Oracle In-Memory Database Cache による Oracle データベースの迅速化 15 Oracle Corporation 発行「Using Oracle In-Memory Database Cache to Accelerate the Oracle Database」の翻訳版です。 4.4.2.1 読取り専用キャッシュ・グループ アクティブ・スタンバイ・ペアのレプリケーション構成は読取り専用のキャッ シュ・グループでも、ライトスルー・キャッシュ・グループでも動作するように 設計されています。読取り専用キャッシュ・グループの場合、Oracle データベー スに適用された更新はアクティブ・ノードにしか伝播されません。次に、Oracle TimesTen レプリケーションにより、まずスタンバイ・ノードを通過してから、ほ かのすべてのノードに更新内容が伝播されます。 図 6 アクティブ・スタンバイ・ペア構成を使用した読取り専用キャッシュ・グループ アクティブ・ノードで障害が発生すると、スタンバイ・ノードが次のアクティブ・ ノードになります。それ以降は Oracle Database の更新内容が新しいアクティブ・ ノード（すなわち、前出のスタンバイ・ノード）に伝播され、読取り専用サブス クライバ・ノードに複製されます。以前のアクティブ・ノードがオンライン状態 に戻ると、再びスタンバイ・ノードになります。Oracle TimesTen レプリケーショ ンでは、アクティブからスタンバイへの更新伝播の切替えと障害ノードのリカバ リを自動的におこないます。 同様に、スタンバイ・ノードに障害が発生すると、アクティブ・ノードからのレ プリケーションは自動的に読取り専用サブスクライバ・ノードにリダイレクトさ れます。スタンバイ・ノードがオンライン状態に戻ると、レプリケーションによっ て、スタンバイ・ノードの役割が再開する前に更新された内容がすべてさかのぼっ て取得されるようになります。 4.4.2.2 ライトスルー・キャッシュ・グループ ライトスルー・キャッシュ・グループでは、更新内容がアクティブ・ノードに適用さ れます。次に、その内容がスタンバイ・ノードに複製されます。さらに Oracle Database に伝播され、すべての読取り専用サブスクライバ・ノードに複製されます。 Oracle In-Memory Database Cache による Oracle データベースの迅速化 16 Oracle Corporation 発行「Using Oracle In-Memory Database Cache to Accelerate the Oracle Database」の翻訳版です。 図 7 アクティブ-スタンバイ構成を使用したライトスルー・キャッシュ・グループ アクティブ・ノードで障害が発生すると、スタンバイ・ノードが次のアクティブ・ ノードになります。それ以降は、すべての更新内容がかならず新しいアクティブ・ ノード（すなわち、前出のスタンバイ・ノード）に送られます。新しいアクティ ブ・ノードの更新内容は Oracle Database に伝播され、読取り専用サブスクライバ・ ノードに複製されます。以前のアクティブ・ノードがオンライン状態に戻ると、 再びスタンバイ・ノードになります。Oracle TimesTen レプリケーションでは自動 的に新しいスタンバイ・ノードのリカバリがおこなわれ、バックエンドへの更新 伝播の役割が新しいスタンバイ・ノードに転送されます。 同様に、スタンバイ・ノードに障害が発生した場合は、アクティブ・ノードから のレプリケーションが自動的に読取り専用サブスクライバ・ノードにリダイレク トされ、アクティブ・ノードから Oracle Database への直接の更新伝播が開始しま す。スタンバイ・ノードがオンライン状態に戻ると、レプリケーションによって、 スタンバイ・ノードの役割が再開する前のすべての更新内容がさかのぼって取得 されるようになります。また、スタンバイ・ノードで Oracle Database および読取 り専用サブスクライバへの更新伝播が再開されます。 Oracle In-Memory Database Cache による Oracle データベースの迅速化 17 Oracle Corporation 発行「Using Oracle In-Memory Database Cache to Accelerate the Oracle Database」の翻訳版です。 5. パフォーマンス Oracle In-Memory Database Cache のパフォーマンスを測定するため、携帯電話ネッ トワークで使用する Home Location Register（HLR）アプリケーションをシミュレー トするベンチマークを開発しました。ベンチマークは 7 つのトランザクションの セットで構成され、それぞれ着信転送の設定、削除や携帯電話サブスクライバの 情報更新など、HLR で実行される一般的な操作がモデル化されています。 ベンチマークは 2 種類の構成で実行しました。1 つ目の構成では、一方のサーバー にはベンチマーク・アプリケーションが実行され、もう一方のサーバーに Oracle Database 10g がある Oracle Database に対して HLR アプリケーションを実行しまし た。2 つ目の構成では、Oracle Database に Oracle In-Memory Database Cache を追加 し、HLR アプリケーションのプログラムが、一方のサーバーで実行中の TimesTen キャッシュ・データベースと、もう一方のサーバーで実行中の Oracle Database 10g に直接リンクされるようにしました。キャッシュ・データは非同期ライトスルー・ キャッシュ・グループに保存され、キャッシュ・データに対する更新が Oracle Database に自動的に伝播されるようになります。 このアプリケーションはデータ・アクセス用の JDBC を使用して Java で実装され ました。4 つのサーバーの構成はすべて同一で、6GB の物理 RAM、SUSE Linux Enterprise Server 9 で稼動するハイパースレッドを搭載した 2 基の Intel Xeon 2.4GHz プロセッサを備えています。 Oracle Database に対して実行した場合と Oracle In-Memory Database Cache に対して 実行した場合において、各タイプのトランザクションの平均レスポンス時間を測 定しました。以下のグラフは、Oracle In-Memory Database Cache を使用した場合に アプリケーションのレスポンス時間が大幅に短縮することを示しています。 図 8 HLR ベンチマーク・アプリケーションのレスポンス時間比較 Oracle In-Memory Database Cache による Oracle データベースの迅速化 18 Oracle Corporation 発行「Using Oracle In-Memory Database Cache to Accelerate the Oracle Database」の翻訳版です。 2 つの構成ですべてのトランザクションを組み合わせた場合のスループットも測 定しました。以下のグラフは Oracle In-Memory Database Cache を使用した場合にア プリケーションのスループットが大幅に増加することを示しています。 図 9 ベンチマーク HLR アプリケーションのスループット比較 このベンチマークは Oracle In-Memory Database Cache を使用することの利点を示 しています。上のグラフに示すように、アプリケーションのレスポンス時間は 10 倍から 40 倍短縮し、 スループット全体では 7 倍以上も短縮しています。一般的に、 Oracle In-Memory Database Cache による改善率はハードウェアやプラットフォー ムによって異なります。 6. 例 この項では、キャッシュ・シナリオとそのシナリオに推奨される Oracle In-Memory Database Cache 構成について検証します。 6.1 読取り専用キャッシュ 増分自動リフレッシュを使用する読取り専 用キャッシュ・グループは、頻繁に参照する データのキャッシュに適しています。 読取り専用キャッシュにより、多くのアプリケーションに利点がもたらされます。 利点がもたらされるアプリケーションには、一部のレコード・セットの問合せが 何度もおこなわれるという特徴があります。問合せがおこなわれるレコードの更 新頻度はまちまちですが、書込みに対する読取りの比率はおおむね高くなってい ます。該当するレコードの例として、オンライン・ショッピング・アプリケーショ ンの価格リスト、航空券予約アプリケーションのフライト・スケジュール、ホテ ル予約アプリケーションの空室情報などがあります。 このようなデータには、増分自動リフレッシュを使用した（システムで管理され る）読取り専用キャッシュ・グループのキャッシュ構成がもっとも適しています。 データはバックエンド・データベースで更新されます。更新内容は自動的にキャッ シュに伝播されます。伝播頻度はアプリケーションごとに決定されますが、バッ クエンドの更新頻度やアプリケーションに必要なデータの基準によって異なる場 合もあります。 Oracle In-Memory Database Cache による Oracle データベースの迅速化 19 Oracle Corporation 発行「Using Oracle In-Memory Database Cache to Accelerate the Oracle Database」の翻訳版です。 キャッシュが複数のノードに配置される場合、各ノードに独立したキャッシュを 設定します。その場合、各キャッシュは直接バックエンド・データベースから更 新されるか、またはノード間にレプリケーションが設定され、更新がまず中間層 に伝えられてからほかのノードに複製されます。 オンライン・ショッピング・アプリケーションでは通常、価格リストを更新する 必要はありません。価格リストの変更は中央の管理プロセスでおこなわれます。 一方、読取り集中型のホテル予約アプリケーションの場合は、新しく部屋を予約 するごとにデータベースを更新する必要があります。このような更新は、増分自 動リフレッシュを使用した Oracle Database にもっとも適しています。更新された データを含むすべてのキャッシュに対する更新が伝播されます。アプリケーショ ンでは Oracle TimesTen キャッシュ・データベースのみへの単独の接続を設定でき、 パススルー・オプションを使用して、キャッシュでの読取り中に Oracle Database にすべての更新をルーティングできます。 6.2 読取り専用スライディング・ウィンドウ・キャッシュ 増分自動リフレッシュおよび時間ベースのエー ジングを使用した読取り専用キャッシュ・グ ループは、スライディング・ウィンドウに該当 する、頻繁に参照されるデータのキャッシュに 適しています。 大抵の場合、アプリケーションで必要とされる読取り専用データには時間コン ポーネントが含まれています。時間コンポーネントでは、古いデータよりも新し いデータのほうがより頻繁にアクセスされます。この特定のアプリケーション・ クラスでは新しいデータが常に生成され、古いデータの価値が失われていきます。 これに対処するため、固定長の時間間隔を検討することができます。この時間間 隔の両端のうち一方はデータが送られると常に前方移動し、もう一方はそれに 伴って短くなります。アプリケーションが対象とするのは間隔内のデータのみで す。通常これをスライディング・ウィンドウと呼びます。 スライディング・ウィンドウに該当するデータを必要とするアプリケーションの例と して、株式取引アプリケーションやニュース配信アプリケーションがあります。たと えば株式取引アプリケーションでは過去 3 日分の取引が、ニュース配信アプリケー ションでは過去 24 時間分のニュース・クリップが必要な場合があります。 スライディング・ウィンドウに該当するデータをキャッシュするには、新しいデー タを自動的にキャッシュに取り込み、古いデータをエージングによって自動的に キャッシュから削除する必要があります。また、バックエンドで変更がおこなわ れた場合に備えてキャッシュのデータを自動的に更新する必要があります。この ようなデータには、増分自動リフレッシュと時間ベースのエージングを使用した （システムで管理される）読取り専用キャッシュ・グループのキャッシュ構成が もっとも適しています。 先に挙げた例のように、キャッシュが複数のノードに配置される場合、各ノード に独立したキャッシュを設定します。その場合、各キャッシュは直接 Oracle Database から更新されるか、またはノード間にレプリケーションが設定され、更 新がまず中間層に伝えられてからほかのノードに複製されます。 6.3 更新可能なキャッシュ 更新可能なキャッシュには非同期ライトス ルー・キャッシュ・グループが適しています。 アプリケーションによっては、Oracle Database の更新の最終伝播とともに、キャッ シュ・データを迅速にリアルタイムで更新する必要があります。たとえば、電話 のサブスクリプション・サービスの管理、プロビジョニングをおこない、サブス クリプション・サービスへのアクセス権を認証するサブスクリプション・アプリ ケーションでは通常、インメモリ・キャッシュ・データベースにサブスクライバ 情報がキャッシュされます。ユーザーのサービス変更は迅速にキャッシュに反映 Oracle In-Memory Database Cache による Oracle データベースの迅速化 20 Oracle Corporation 発行「Using Oracle In-Memory Database Cache to Accelerate the Oracle Database」の翻訳版です。 され、バックエンド・データベースに伝播されます。 このようなデータには非同期ライトスルー・キャッシュ・グループの構成がもっ とも適しています。 6.4 不均等な到着率のデータ取得キャッシュ 不均等な到着率のデータ取得には、利用ベース のエージングを使用した非同期ライトスルー・ キャッシュ・グループが適しています。 新しいデータがある期間では非常に高い割合で生成され、それ以外の期間では中 程度の割合で生成されるアプリケーションのクラスがあります。アクティビティ が盛んな期間、バックエンド・データベースではアプリケーションで要求される スループットを実現できないことが多くあります。そのようなアプリケーション では新しく生成されるデータの到着率を事実上”平滑化”するキャッシュにより利 点がもたらされます。 たとえば、株ティッカー・アプリケーションでは新しい値の到着率は時間によっ て大幅に変化します。市場の開始時と終了時はとくに高く、それ以外の時間は低 くなります。ピーク時の到着率はディスクベースのデータベースでは通常処理で きませんが、Oracle In-Memory Data Cache では処理できます。 このようなデータには、利用ベースのエージングを使用した（システムで管理さ れる）非同期ライトスルー・キャッシュ・グループのキャッシュ構成がもっとも 適しています。ライトスルー・キャッシュ・グループに挿入された内容は、バッ クエンドの Oracle データベースに自動的に伝播されます。また、利用ベースのエー ジングによりインメモリ・キャッシュからデータが自動的に削除され、キャッシュ 領域が確保されます。 6.5 到着率が常に高いデータ取得キャッシュ 到着率が常に高いデータを取得するには、利用 ベースのエージングを使用した非同期ライトス ルー・キャッシュ・グループと利用ベースのエー ジングを使用した Oracle TimesTen 表を組み合 わせて使用するのがもっとも適しています。 新しいデータが高い割合で生成されても、その高い到着率がかならずしも低下し ないアプリケーションのクラスもあります。バックエンド・データベースで取得 するインタールードがないのが原因で到着率が低下しない場合は、到着率が高す ぎてバックエンド・データベースに吸収されない一時データをキャッシュしても、 この問題は解決しません。ただし、このようなアプリケーションでは新しく生成 したデータをバックエンド・データベースに永続的に保存する前に、より凝縮し た形式で集計できることがあります。また、リアルタイムで収集したデータを分 析して、注視すべきパターンや異常なパターンを発見できることもあります。 上記のようなアプリケーションの例として、センサーや RFID リーダーからデー タを収集するアプリケーションがあります。データは繰返しが多く、収集が容易 です。またリアルタイムの分析を必要とします。 このようなアプリケーションには、データが到着するたびに Oracle TimesTen のみ で管理される表に挿入される構成がもっとも適しています。つまり、バックエン ド・データベースにはこのデータのイメージが存在しません。キャッシュされな い Oracle TimesTen のみの表は利用ベースのエージングで構成することができま す。データをアプリケーションごとに集計すると、利用ベースのエージングを使 用した（システムが管理する）非同期ライトスルー・キャッシュ・グループのキャッ シュに挿入できるようになります。 Oracle In-Memory Database Cache はその集計 内容をバックエンド・データベースに自動的に伝播します。Oracle TimesTen のみ の表もキャッシュ表も利用ベースのエージングで構成されるため、最近もっとも 使用していないレコードがエージングにより自動的に削除され、新しいレコード のためにキャッシュの領域が確保されます。 Oracle In-Memory Database Cache による Oracle データベースの迅速化 21 Oracle Corporation 発行「Using Oracle In-Memory Database Cache to Accelerate the Oracle Database」の翻訳版です。 更新可能な動的キャッシュには、透過的ロード と利用ベースのエージングを使用した非同期ラ イトスルー・キャッシュ・グループが適してい ます。 6.6 更新可能な動的キャッシュ 一部のアプリケーションではアクティブなデータへのアクセスが速くなりますが、 アクティブなデータのセットは時間によって変化し、より大きなデータ量のサブ セットになります。これではデータが大きすぎるためキャッシュに全体を保持で きません。アクティブなデータはオンデマンドでキャッシュに取り込む必要があ り、キャッシュのコンテンツはアクティブなデータと古いデータを置き換えられ るように動的である必要があります。 このようなアプリケーションの例として、オンラインで顧客に対応するための パーソナライズの使用があります。顧客が Web サイトを訪れると、顧客のプロファ イルが Web サイトにロードされます。顧客がサイトと対話すると、その顧客のプ ロファイルが更新されます。顧客がサイトを去ると、プロファイルは不要になり キャッシュから削除されます。 こうしたデータには、透過的ロードと利用ベースのエージングを使用した非同期 ライトスルー・キャッシュ・グループの構成がもっとも適しています。アプリケー ションがユーザーのプロファイルに SELECT を発行すると、そのプロファイルが キャッシュにない場合は自動的にキャッシュにロードされます。アプリケーショ ンでプロファイルが更新されると、その更新内容が Oracle Database に自動的に伝 播されます。また、キャッシュの領域がさらに必要な場合は、一定期間アクセス されていないプロファイルがキャッシュから自動的に削除されます。 6.7 更新可能なユーザー管理キャッシュ 更新は頻繁におこなわれ、ビジネス・トランザ クションは頻繁におこなわれないアプリケー ションの場合は、明示的なフラッシュを使用す るユーザー管理キャッシュ・グループがもっと も適しています。 アプリケーションによっては、パフォーマンスを最適にするためにキャッシュ内 で複数の更新を実行する必要がありますが、最終トランザクションは Oracle Database に永続的に記録しなければなりません。そのようなアプリケーションの 例として、アクティブなユーザーのショッピング・カートが大量に維持される e コマース・アプリケーションがあります。ショッピング・カートはキャッシュ内 で繰り返し更新されます。更新が重要でない場合は、Oracle Database に伝播する 必要はありません。ただし、ユーザーが購入を実行すると、そのトランザクショ ンは永続的に Oracle Database に記録する必要があります。 そのようなデータにはユーザー管理の更新可能キャッシュ・グループの構成が もっとも適しています。この場合、Oracle Database にトランザクションを記録す る必要がある場合にはいつでも、アプリケーションで明示的にフラッシュ要求を 発行します。この構成と利用ベースのエージングを組み合わせることで、放置さ れたショッピング・カートがキャッシュから自動的に削除されます。 6.8 読取り専用動的分散キャッシュ 読取り専用動的分散キャッシュには、透過的 ロードと利用ベースのエージングを使用した読 取り専用の表がもっとも適しています。 場合によっては、単一ノードで処理できないスループット率を処理するために複 数ノード間でアプリケーションを分散できます。また、アプリケーションで必要 とされるアクティブなデータのセットは動的であり、常に完全なデータ・セット よりもはるかに小さなサブセットです。そのようなアプリケーションの例として、 アクティブなトレーダーのプロファイルがアクティブなデータである、トレー ディング・アプリケーションがあります。 そのようなデータには Oracle Database の同一の表セットに対し、読取り専用 キャッシュ・グループを含むインメモリ・キャッシュを各ノードに構成するのが もっとも適しており、キャッシュ表では透過的ロードと利用ベースのエージング を使用します。これにより、ロードする必要があるトレーダーのプロファイルが、 Oracle In-Memory Database Cache による Oracle データベースの迅速化 22 Oracle Corporation 発行「Using Oracle In-Memory Database Cache to Accelerate the Oracle Database」の翻訳版です。 必要なときに自動的に各ノードに含まれるようになります。このプロファイルは 不要になるとエージングよりキャッシュから削除されるため、必要なプロファイ ルのための領域が確保されます。 7. 結論 Oracle In-Memory Database Cache を使用することで、パフォーマンスを重視する表 のサブセットと表の断片が Oracle データベースからアプリケーション層にキャッ シュされるため、アプリケーションのトランザクションのレスポンス時間を短縮 することができます。単純な結果キャッシュのメカニズムとは対照的に、アプリ ケーションではキャッシュ・データ上で SQL 問合せを新しく実行できます。これ は、Oracle TimesTen In-Memory Database ではキャッシュ表が通常のリレーショナ ル・データベース表として管理されるためです。キャッシュは異なるアプリケー ション間で共有できます。更新内容はキャッシュに適用できるため、キャッシュ と Oracle Database との整合性が保持されます。完全なリレーショナル機能、卓越 したパフォーマンス、Oracle Database とのデータ整合性の自動メンテナンスが、 アプリケーション層で実行されるアプリケーションでも実現するため、Oracle In-Memory Database Cache を使用したデータのキャッシュはほかのキャッシュ技 術よりも優れています。 データをアプリケーションに近づけ、インメモリ・データベースで問合せを処理 することで、Oracle In-Memory Database Cache のレスポンス時間が大幅に短縮しま す。Oracle データベース・サーバーから一部のデータ処理作業の負荷を軽減する ことで、集中管理やバックエンド・データベースの管理が妨げられることなく、 アプリケーション全体のスループットが大幅に改善します。 8. 参考資料 1. 『Oracle TimesTen 製品とテクノロジー』 Oracle ホワイト・ペーパー、2005 年 12 月 Oracle In-Memory Database Cache による Oracle データベースの迅速化 23 Oracle Corporation 発行「Using Oracle In-Memory Database Cache to Accelerate the Oracle Database」の翻訳版です。 Oracle In-Memory Database Cache による Oracle データベースの迅速化 2008 年 3 月 Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問い合わせ窓口： 電話： +1.650.506.7000 Fax: +1.650.506.7200 www.oracle.com Copyright © 2008, Oracle.All rights reserved. 本文書は情報提供のみを目的として提供されており、ここに記載される内容 は予告なく変更されることがあります。本文書は一切間違いがないことを保 証するものではなく、さらに、口述による明示または法律による黙示を問わ ず、特定の目的に対する商品性もしくは適合性についての黙示的な保証を含 み、いかなる他の保証や条件も提供するものではありません。オラクル社は 本文書に関するいかなる法的責任も明確に否認し、本文書によって直接的ま たは間接的に確立される契約義務はないものとします。本文書はオラクル社 の書面による許可を前もって得ることなく、いかなる目的のためにも、電子 または印刷を含むいかなる形式や手段によっても再作成または送信すること はできません。Oracle、JD Edwards、PeopleSoft、および Siebel は、米国 Oracle Corporation およびその子会社、関連会社の登録商標です。その他の名 称はそれぞれの会社の商標です。