| Oracle TimesTen In-Memory Database概要
リリース7.0 E05163-01 |
|
 前へ |
 次へ |
この項では、総合的なデータ管理ソリューションの一部としてTimesTenを統合する方法を示す、いくつかのアプリケーションの使用例について説明します。
アプリケーションの使用例は次のとおりです。
携帯サービス・プロバイダNoWires Communicationsには、携帯の各通話時間と使用されたサービスの記録を保管する、利用状況計測アプリケーションがあります。たとえば、携帯利用者が通常の通話を行うと、通話時間に対して基本料金が適用されます。携帯利用者が、ローミング、Web閲覧、3方向通話などの特別な機能を利用すると、特別料金が追加されます。
利用状況計測アプリケーションでは、最大100,000の同時通話を効率的に監視し、各通話の利用データを収集し、請求書、報告書、監査などを生成する他のアプリケーションが使用する、中央データベースにデータを保存する必要があります。
現在の構成では、アプリケーション・データのすべてが、中央のディスク・ベースRDBMSのCalls表に保存されています。ただし、容量は増大し、会社のインフラストラクチャは近代化する必要があります。この会社では、満足できるパフォーマンスを得るために中央のRDBMSデータベースを拡張すると、接続とCalls表の記録が増えすぎると判断しました。さらに、RDBMSでは、利用状況計測アプリケーションが最大のパフォーマンスを得るために必要なリアルタイム更新を処理できません。
この会社は、TimesTenを使用して利用状況計測アプリケーションでただちに必要となる携帯利用者のデータを保存し、他のデータを中央RDBMSに格納することによって、パフォーマンスとスケールを改善できると判断します。この会社の解決方法は、利用状況計測アプリケーションの複数のインスタンスとTimesTenをサービス・エリア全域の個々のノードに分散させて、データの収集処理を集中させないというものです。各利用状況計測アプリケーションが、ODBCダイレクト・ドライバ接続を使用してそのローカルTimesTenデータベースに接続することで、最大のパフォーマンスが得られます。
市外局番で区別される、地理的に異なる位置で開始および終了する通話のリアルタイム処理を行うため、図2.1に示すように、個別の利用状況計測アプリケーションとTimesTenノードを組み合せて配置します。ローカル・ノードでは、通話ごとに通話の開始と終了について個別の記録を保存します。これは、あるノードで開始を検出した携帯の通話が、別のノードで終了を検出されることがあるためです。
この使用例の場合、TimesTenでは、比較的わずかなパフォーマンスの低下で、各表で数百万行を管理できるので、中央のRDBMSデータベースより優れたパフォーマンスが得られます。このため、各TimesTenノードは縦方向に拡張し、環境全体はTimesTenノードを追加するたびに横方向に拡張します。
収益に影響する、TimesTenに対するトランザクション（挿入/更新）は永続性を保つ必要があるため、ロギングが使用されます。データの可用性を保証するには、各TimesTenノードを、ホットスタンバイ・ノードにレプリケートします。
この会社は、各TimesTenノードで実行する、送信エージェントという特別なバックグラウンド・コンポーネントを実装します。図2.2に示すように、送信エージェントは、ODBCダイレクト・ドライバによってTimesTenに、またIPCによってリモートRDBMSデータベースにローカルに接続します。送信エージェントの目的は、レプリケーションのフェイルオーバーとリカバリの処理および統計情報の更新に加えて、TimesTenの記録を定期的に中央のRDBMSデータベースにアーカイブすることです。メイン・ノードで障害が発生すると、送信エージェントが、TimesTenスタンバイ・ノード上の冗長な利用状況計測アプリケーションに携帯利用者を移動します。
顧客が携帯の通話を開始、受信および終了するたびに、アプリケーションはアクティビティの記録をそのTimesTenのCalls表に挿入します。各通話記録には、タイムスタンプ、一意識別子、開始ホストのIPアドレスおよび使用されたサービスに関する情報が含まれます。
送信エージェントは、Calls表の最初の5000行を定期的に選択し、高速バッチ処理を使用して、それらを中央のRDBMSにアーカイブします（SQLのSELECT文の結果セットを最初のN行の値に制限して、通話のリアルタイム処理に及ぼす影響を小さくし、アーカイブするデータを管理可能なサイズに維持します）。送信エージェントは、通話記録が中央RDBMSに正常にアーカイブされたことを確認すると、それらをTimesTenから削除します。送信エージェントが通話をアーカイブする間隔は、通話の負荷と現在のデータベースのサイズによって動的に変化します。
金融サービス会社Beeman&Shusterは、リアルタイムの取引価格とニュースのサービスを自社のオンライン取引設備に追加します。リアルタイム取引価格サービスでただちに必要となるのは、大手のマーケット・データ・ベンダーの1社から入電するニュースを読み取ることと、会社の自動株式取引処理を管理する取引アプリケーションに対して、選択したデータのサブセットを使用可能にすることです。この会社の計画では、将来の拡張に適応できる十分な拡張性と柔軟性を備えたインフラストラクチャを構築して、リアルタイムの取引価格、ニュース、およびその他の取引サービスを顧客に提供していきます。
リアルタイム取引価格サービスには、NewsReaderの処理が含まれ、ニュース・ワイヤーから絶えずデータが供給されるリアルタイム・メッセージ・バスから入電するデータを読み取ります。各NewsReaderは、独立してバスからデータを読み取って別のTimesTenデータベースにデータを挿入する、バックアップのNewsReaderと対になっています。この方法では、メッセージ・バスを使用して、冗長性のために入電データを2つのTimesTenデータベースに分岐させています。この使用例では、メッセージ・バスのデータを分岐させる方が、TimesTenレプリケーションを使用するより効率的です。
各ペアでは、一方のNewsReaderが取引アプリケーションで株式データを使用可能にし、もう一方がホットスタンバイ・バックアップとして動作して、障害発生時にアプリケーションで使用されます。現在のロードでは、4組のNewsReaderのペアが必要ですが、将来的にはさらにNewsReaderのペアを追加して、Web、ポケットベル、携帯電話などを介してリアルタイム取引価格を他のタイプの顧客に配信できます。
図2.4に示すように、NewsReaderは、TimesTenデータベースのQuotes表の株価データを更新します。それよりも動的でない利益データは、Earnings表で更新されます。Quotes表およびEarnings表のStock列は、外部キー関係を介してリンクされています。
取引アプリケーションの目的は、50未満の株価収益率を持つ株式のみ追跡し、いくつかの内部ロジックを使用して、現在の株価と取引量を分析し、取引機能の別の部分を使用して取引を行うかどうか判断することです。取引アプリケーションでは、最大のパフォーマンスを得るために、関心のある株式の更新について、TimesTenトランザクション・ログAPI（XLA）を使用してTimesTenトランザクション・ログを監視する、イベント機能を実装します。
こうした更新に対して、できるかぎり高速なアクセスを実現するために、マテリアライズド・ビューPE_Alertsを作成します。このマテリアライズド・ビューには、Quotes表のPrice列とEarnings表のEarns列から株価収益率を計算するWHERE句があります。XLAイベント機能を使用して、マテリアライズド・ビューの価格更新についてトランザクション・ログを監視することによって、取引アプリケーションは取引基準に一致する株式のアラートのみを受信します。
Advance Call Centerでは、NoWires Communications用の顧客サービスを提供しています。
図2.5は、バックエンド・アプリケーションをホスティングする中央サーバーおよび顧客プロファイルを格納するOracleデータベースがコール・センター・システムに含まれていることを示しています。
大容量の同時顧客セッションを管理するために、コール・センターでは、米国の特定の市外局番または市外局番のグループに対してアプリケーション・サーバー・ノードが指定されています。各ノードに、TimesTenデータベースが含まれています。顧客がコール・センターに連絡すると、TimesTenのCache Connect to Oracleオプションを使用して、適切な顧客プロファイルがOracleデータベースからTimesTenデータベース内のキャッシュ・グループに透過的にロードされます。
顧客がコールを完了すると、顧客プロファイルへの変更がTimesTenからOracleにフラッシュされます。最低使用頻度（LRU）に基づいたエージングは、アクティブでない顧客プロファイルをTimesTenから削除するように構成されています。
すべての顧客データがOracleデータベースに格納されています。Oracleデータベースは、各TimesTenデータベースよりはるかに大規模であるため、TimesTenのリアルタイム・パフォーマンスが必要でなく、大容量のデータにアクセスする必要があるアプリケーションでアクセスすることをお薦めします。このようなアプリケーションには、請求書発行アプリケーション、データ・マイニング・アプリケーションなどがあります。
