| Oracle® In-Memory Database Cache概要 リリース11.2.1 B56058-02 |
|
 前へ |
 次へ |
この章では、TimesTenおよびIMDB Cacheを使用して、データにリアルタイムでアクセスする必要があるアプリケーションを使用可能にする方法について説明します。内容は次のとおりです。
TimesTenは、次の目的で使用できます。
リアルタイム・アプリケーションのプライマリ・データベース。TimesTenデータベースには、アプリケーションが必要とするすべてのデータが存在します。
アーキテクチャのパフォーマンスを重視するポイントを促進するためのデータ・ユーティリティ。たとえば、TimesTenをメッセージのリポジトリとして使用することで、メッセージ・キューイング・システムに永続性とトランザクション機能を提供できます。
新規アプリケーション作成時の基盤となる、複数のデータソースのデータ統合ポイント。たとえば、ある組織で大量の情報を複数のデータソースに保存していたとしても、日常業務にかかわる情報は一部のみの場合があります。適切なアーキテクチャとは、関連情報を複数の異なるデータソースから1つのTimesTenデータベースに移動して、アプリケーションでただちに必要になるデータの中央リポジトリが用意されたアーキテクチャです。
IMDB Cacheは、次の目的で使用できます。
Oracle Databaseのようなディスク・ベースのRDBMSと連携した総合的なワークフローでの特定のタスク用のリアルタイム・データ・マネージャ。たとえば、通話料請求アプリケーションでは、顧客、請求書の送付先住所、クレジット情報などはOracle Databaseに保存し、最新の通話記録はIMDB Cacheデータベースに収集および保存することが可能です。また、すべての通話記録のアーカイブをOracle Databaseに保管することもできます。このように、リアルタイム・アクセスが必要な情報はIMDB Cacheデータベースに保存し、長期の分析、監査、アーカイブに必要な情報はOracle Databaseに保存します。
読取り専用キャッシュ。Oracleデータは、IMDB Cacheの読取り専用キャッシュ・グループにキャッシュできます。読取りキャッシュ・グループは、Oracle表を更新すると、自動的にリフレッシュされます。読取り専用キャッシュ・グループによって、参照表やサブスクライバ・プロファイルなどの参照データへの高速アクセスが実現します。
更新可能なキャッシュ。Oracleデータは、IMDB Cacheの更新可能なキャッシュ・グループにキャッシュできます。キャッシュ・グループでのトランザクションは、関連Oracle表に同期または非同期でコミットできます。
分散キャッシュ。Oracleデータは、スケーラビリティを保持するために、異なるマシンで実行されているIMDB Cacheの複数のインストールにキャッシュできます。レコードのロードおよびエージングが自動的に実行される動的分散キャッシュを構成できます。
この項では、データ管理ソリューションの一部としてTimesTenを統合する方法を示す、アプリケーションの使用例について説明します。
アプリケーションの使用例は、リアルタイム取引価格サービス・アプリケーションです。これは、TimesTenを使用して、プログラム売買アプリケーションがアクセスするデータ・フィードの株式取引価格を保存します。取引価格データはデータ・フィードから収集し、リアルタイム・メッセージ・バスで発行されます。データはメッセージ・バスから読み取られると、TimesTenに保存され、プログラム売買アプリケーションによってアクセスされます。
金融サービス会社が、リアルタイムの取引価格とニュースのサービスを自社のオンライン取引設備に追加します。リアルタイム取引価格サービスは、大手マーケット・データ・ベンダーから入電するニュースを読み取り、会社の自動株式取引処理を管理する取引アプリケーションに対して、データのサブセットを使用可能にします。この会社は、将来の拡張に適応できるインフラストラクチャを構築して、リアルタイムの取引価格、ニュース、およびその他の取引サービスを顧客に提供していく予定です。
リアルタイム取引価格サービスには、NewsReaderの処理が含まれ、ニュース・ワイヤーから絶えずデータが供給されるリアルタイム・メッセージ・バスから入電するデータを読み取ります。各NewsReaderは、独立してバスからデータを読み取って別のTimesTenデータベースにデータを挿入する、バックアップのNewsReaderと対になっています。この方法では、メッセージ・バスを使用して、冗長性のために入電データを2つのTimesTenデータベースに分岐させています。この使用例では、メッセージ・バスのデータを分岐させる方が、TimesTenレプリケーションを使用するより効率的です。
一方のNewsReaderは取引アプリケーションで株式データを使用可能にし、もう一方はホットスタンバイ・バックアップとして動作して、障害発生時にアプリケーションで使用されます。現在のロードでは、4組のNewsReaderのペアが必要ですが、将来的にはさらにNewsReaderのペアを追加して、Webや携帯電話を介してリアルタイム取引価格を他のタイプの顧客に配信できます。
図2-1に、メッセージ・バスからデータを取得してNewsReadersに入力するための構成を示します。
図2-2に示すように、NewsReaderは、TimesTenデータベースのQuotes表の株価データを更新します。それよりも動的でない利益データは、Earnings表で更新されます。Quotes表およびEarnings表のStock列は、外部キー関係を介してリンクされています。
取引アプリケーションの目的は、50未満の株価収益率を持つ株式のみ追跡し、内部ロジックを使用して、現在の株価と取引量を分析し、取引機能の別の部分を使用して取引を行うかどうか判断することです。取引アプリケーションでは、最大のパフォーマンスを得るために、関心のある株式の更新について、TimesTenトランザクション・ログAPI(XLA)を使用してTimesTenトランザクション・ログを監視する、イベント機能を実装します。
こうした更新に対して、できるかぎり高速なアクセスを実現するために、マテリアライズド・ビューPE_Alertsを作成します。このマテリアライズド・ビューには、Quotes表のPrice列とEarnings表のEarns列から株価収益率を計算するWHERE句があります。XLAイベント機能を使用して、マテリアライズド・ビューの価格更新についてトランザクション・ログを監視することによって、取引アプリケーションは取引基準に一致する株式のアラートのみを受信します。
この項では、IMDB Cacheの使用方法を示す使用例について説明します。
コール・センター・アプリケーション: IMDB Cacheをアプリケーション層のキャッシュとして使用して、Oracle Databaseで保持されている顧客プロファイルを保持します。
携帯利用者の利用状況計測アプリケーション: IMDB Cacheを使用して、携帯利用者の利用状況の計測データを保存します。計測データは、サービス・エリア全体に分散した複数のTimesTenノードから収集され、中央の通話料金請求アプリケーションが使用する、中央のOracle Databaseで保管されます。
Advance Call Centerでは、Wireless Communications用の顧客サービスを提供しています。
図2-3は、バックエンド・アプリケーションをホスティングする中央サーバーおよび顧客プロファイルを格納するOracle Databaseがコール・センター・システムに含まれることを示しています。
大量の同時顧客セッションを管理するために、コール・センターではすでに複数のアプリケーション・サーバー・ノードをデプロイしており、顧客ベースの増加に応じて定期的に追加のノードをデプロイします。各ノードに、IMDB Cacheデータベースが含まれます。顧客がコール・センターに連絡すると、顧客は利用可能なアプリケーション・サーバー・ノードに自動的にルーティングされ、適切な顧客プロファイルがOracle Databaseからキャッシュ・データベースに動的にロードされます。
顧客がコールを完了すると、顧客プロファイルへの変更がIMDB CacheデータベースからOracle Databaseにフラッシュされます。最低使用頻度(LRU)に基づいたエージングは、アクティブでない顧客プロファイルをIMDB Cacheデータベースから削除するように構成されています。
同じ顧客が最初のコール後すぐにコール・センターに再び連絡し、別のアプリケーション・サーバー・ノードに接続された場合、顧客プロファイルは最新のコピーの保存場所に応じて、Oracle Databaseまたは最初のIMDB Cacheノードから新しいノードに動的にロードされます。IMDB Cacheでは、最新のコピーの保存場所が特定され、peer-to-peer通信を使用してグリッドの他のIMDB Cacheデータベースとの間で情報が交換されます。また、ここでは、グリッド内の同じデータに対する同時更新が管理されます。
すべての顧客データがOracle Databaseに格納されています。Oracle Databaseは、IMDB Cacheデータベースを組み合せたものよりもはるかに大規模であるため、IMDB Cacheのリアルタイム・パフォーマンスが必要でなく、大容量のデータにアクセスする必要があるアプリケーションでアクセスすることをお薦めします。このようなアプリケーションには、請求書発行アプリケーションやデータ・マイニング・アプリケーションなどがあります。
顧客ベースが増加し、同時にサービスを提供できる顧客数を増やす必要性が高まると、コール・センターでは、追加のアプリケーション・サーバー・ノードをデプロイすることになります。IMDB Cacheグリッド内の実行中のリクエストを中断することなく、グリッドに新しいIMDB Cacheメンバーを追加できます。また、個々のノードで障害が発生したり、個々のノードを除外した場合でも、グリッドの他のノードで処理が中断されることはありません。
Wireless Communicationsには、携帯の各通話時間と使用されたサービスの記録を保管する、利用状況計測アプリケーションがあります。たとえば、携帯利用者が通常の通話を行うと、通話時間に対して基本料金が適用されます。携帯利用者がローミングなどの特別な機能を利用すると、特別料金が追加されます。
利用状況計測アプリケーションでは、最大100,000の同時通話を効率的に監視し、各通話の利用データを収集し、請求書、報告書、監査などを生成する他のアプリケーションが使用する、中央データベースにデータを保存する必要があります。
この会社は、IMDB Cacheデータベースを使用して、利用状況計測アプリケーションでただちに必要となる携帯利用者のデータを保存し、その他のデータをOracle Databaseに保存します。また、利用状況計測アプリケーションおよびIMDB Cacheの複数のインストールを、サービス・エリア全域の個々のノードに分散させます。各利用状況計測アプリケーションが、ODBCダイレクト・ドライバ接続を使用してそのローカルIMDB Cacheデータベースに接続することで、最大のパフォーマンスが得られます。
図2-4に構成を示します。
市外局番で区別される、地理的に異なる位置で開始および終了する通話のリアルタイム処理を行うため、利用状況計測アプリケーションおよびIMDB Cacheを各ノードにデプロイします。ローカル・ノードでは、通話ごとに通話の開始と終了について個別の記録を保存します。これは、あるノードで開始を検出した携帯の通話が、別のノードで終了を検出されることがあるためです。
収益に影響するトランザクション(挿入および更新)には、永続性が必要となります。データの可用性を確保するには、各IMDB Cacheデータベースをスタンバイ・データベースにレプリケートします。
顧客が携帯の通話を開始、受信および終了するたびに、アプリケーションはアクティビティの記録をIMDB CacheデータベースのCalls表に挿入します。各通話記録には、タイムスタンプ、一意識別子、開始ホストのIPアドレスおよび使用されたサービスに関する情報が含まれます。
IMDB Cacheプロセスによって、Calls表の行が定期的にOracle Databaseにアーカイブされます。通話記録は、Oracle Databaseに正常に保管されると、時間ベースのエージング処理によってIMDB Cacheデータベースから削除されます。
