JP2011159326A - 極めて拡張性の高い同期データキャッシュ方法及びシステム - Google Patents

Abstract

【課題】
データベース管理システムなどの基礎をなす持続性のあるデータベースと同期しながら、極めて拡張性の高いデータキャッシュ技法を提供する。
【解決手段】
本発明では、データは、アカウントごとになどの適切な線に沿って領域化され、その結果、データキャッシュは、主に一意の情報を格納し、そのデータキャッシュを維持するために必要な無効メッセージだけを受信する。
【選択図】 図１

Description

関連出願
本願は、２０００年７月７日に提出され、参照してここに組み込まれている米国特許出願番号第６０／２１６，８８３号の利点を主張する。

発明の分野
本発明はキャッシュに関し、更に詳細には、領域化したデータ及び無効トリガを用いて、拡張性の高い同期データキャッシュ方法及びシステムに関する。

発明の背景
オンライントランザクション処理には、ネットワークを介した、株式取引や電子マネーによる支払いなどのトランザクションを実施するためのシステムがある。オンライントランザクションをサポートするための１つの共通したアーキテクチャは、ネットワークを経由してサーバと通信するコンピュータ側にいるユーザを有している。ユーザがサーバにトランザクションに対する要求を送信すると、サーバは要求を実行し、構成によってはユーザに確認を戻す。トランザクションを処理するために、サーバはユーザのアカウントやその要求を処理できる製品におけるデータにアクセスする。サーバは、データベース等の持続性のあるデータソースからこのようなデータを検索してよい。

このようなシステムに、多くのユーザが追加されるにつれて、増加する要求数を処理するために、更なるサーバを追加することとなる。しかしながら、これらのサーバが要求を実行させるために同じデータソースにアクセスしなければならない場合、他のサーバがデータソースにアクセスしている際には、他のサーバは待機しなければならないので、遅延が生じることがある。システムが拡大し、サーバが追加されるに従い、遅延はいっそう大きくなり、システム性能は悪化する。トランザクションあたりに要する時間が増加するにつれ、ユーザはいらだつようになり、オンライントランザクション処理システムの使用をやめてしまう可能性がある。

この問題に対する１つの共通した解決策は、データソースからのデータの一時的なコピーを格納するためにデータキャッシュを利用することである。複数のサーバが使用される場合、各々がデータソースから検索されたデータのキャッシュを維持できる。要求を処理するためには、サーバはまず要求されたデータがないか、そのデータキャッシュを検索する。要求されたデータがキャッシュの中で発見されると、サーバはデータソースにアクセスしなくてもその要求を処理できる。要求されたデータがキャッシュ内で発見されない場合にだけ、サーバは共用データソースにアクセスしなければならない。要求されたデータがデータソースから一度検索されると、サーバは将来の使用に備えて、データキャッシュの中にそのデータを格納する。ＣＯＲＢＡ及びＥｎｔｅｒｐｒｉｓｅ ＪａｖａＢｅａｎｓ（ＥＪＢ）は、このような分散トランザクション処理システムを実現する周知のアーキテクチャである。

上述のように、データキャッシュ方式を追加したとしても、従来のオンライントランザクションシステムは安定性と遅延の問題がある。システムが非常に大規模に成長し、多くのサーバを利用するにつれ、それらのサーバが、データキャッシュ内で発見されないデータを取得するため、データソースにアクセスしなければならないので遅延が発生する。更に、データキャッシュ方式の成功はデータキャッシュに格納されるデータの精度に依存する。データソース内でデータ項目が変更するときに、サーバが要求を処理するために、古い（期限切れ）のデータを使用すると、その変更を各データキャッシュに伝達する際の遅延がエラーを引き起こすこととなる。

発明の要約
従って、データソースの規模が大きくなるにつれ性能が劣化しないように、極めて拡張性の高いデータキャッシュを実現することが望まれる。また、データソース内のデータとキャッシュ内に存在するデータに食い違いがないようにデータソースと同期するデータキャッシュを提供することも望まれる。本発明における方法及びシステムは、データベース管理システムのような、持続性のあるデータソースと同期しながら極めて拡張性の高いデータキャッシュ技法を提供する。本発明では、データは、例えばアカウントによって領域化され、その結果、データキャッシュは主に一意の情報を格納し、そのデータキャッシュを維持するために必要な無効メッセージだけを受信する。

本発明の態様に従って、ユーザの代わりにトランザクションを処理するためにシステムが実現される。このシステムは、要求ディストリビュータを介してユーザからアカウント番号を含むクエリーを受信し、結果を判断するためにそのクエリーを処理し、要求ディストリビュータを介してユーザに結果を返す、少なくとも１つのアプリケーションサーバを有する。システムは、更に、テーブルの中に、アカウント番号に対応するアカウントデータを格納するために構成された少なくとも１つのデータストアを有する。そのシステムは、更に、アカウント番号に対応するキャッシュ領域を維持し、上述の少なくとも１つのアプリケーションサーバにより処理されるクエリーに対して、キャッシュ領域内で結果を検索する、少なくとも１つのデータキャッシュを有する。キャッシュ領域の中で結果が発見されない場合は、データキャッシュはデータストアから結果を取得し、キャッシュ領域の中に結果を格納し、結果をアプリケーションサーバに返す。

本発明に従って、データ処理方法は、それぞれがアカウント番号で特定されるキャッシュ領域群を維持する。値を含むクエリーが受信されると、そのクエリーに対応する、ある特定のキャッシュ領域が、クエリーの値と、その群の中の各キャッシュ領域を特定するために使用されるアカウント番号との関係性に基づいて、キャッシュ領域群の中から特定される。そのクエリーに対する結果は、上述の判断に基づいて行われる。本発明の更なる特徴は、以下の説明の中で部分的に述べられ、説明から部分的に明らかとなるか、あるいは本発明の実施により分かる。上述の概要と以下の詳細な説明の両方とも、例示的且つ説明的にすぎず、本発明を制限するものではない。

本明細書に記載され、又、本明細書の一部を構成する添付図面は、本発明のいくつかの実施形態を示し、説明とともに、本発明の原理を説明するものである。

図１は、本発明におけるシステム及び方法を実施するためのシステムの全体的なブロック図の一例である。 図２は、本発明におけるシステム及び方法を実施するためのシステムの詳細なブロック図の一例である。 図３は、本発明におけるデータソースの詳細なブロック図である。 図４は、本発明におけるサンプルアカウントテーブルを示す。 図５は、本発明におけるサンプルマスタテーブルを示す。 図６は、本発明におけるデータキャッシュを更に詳細に示すブロック図である。 図７Ａは、本発明におけるデータキャッシュ方式を使用するクエリー処理のフローチャート図である。 図７Ｂは、本発明におけるデータキャッシュ方式を使用するクエリー処理のフローチャート図である。 図８は、本発明の一実施形態におけるデータソース内のマスタデータが変更する際にデータキャッシュを更新するためのプロセスを示したフローチャート図である。 図９は、本発明の一実施形態におけるデータソース内のアカウントデータが本変更する際に、データキャッシュを更新するためのプロセスを示したフローチャート図である。 図１０は、データソース内の変更に対するキャッシュを無効にするためのプロセスを示したフローチャート図である。

詳細な説明
本発明における以下の実施形態の説明は、添付図面を参照する。該当する場合、さまざまな図面の同じ参照番号は、同じ要素または類似要素を示す。

図１は、本発明を実施するためのシステムの全体的なブロック図の一例である。図示されるように、複数のユーザ１０２がネットワーク１０６を介してトランザクション処理システム１０４と通信するためにコンピュータを使用する。ネットワーク１０６は、インターネット、ＷＡＮ（広域ネットワーク）、またはＬＡＮ（ローカルエリアネットワーク）等の任意の種類の通信媒体であってよい。ユーザ１０２は、トランザクション処理システム１０４にトランザクション要求を送信可能である。株式取引や電子マネーによる支払いを含む、任意の種類のトランザクションが本発明の原理によって処理できる。この要求を処理するために、トランザクション処理システム１０４は、持続性のあるデータソース１０８に格納されるデータにアクセスする。図１には３人のユーザ１０２が示されているが、任意の数のユーザが、本発明におけるトランザクション処理システム１０４と通信可能である。同様に、複数のデータソース１０８が使用されてもよい。

図２は、本発明を実施するためのシステムの詳細なブロック図の一例である。トランザクション処理システム１０４は、ユーザ２０２からの要求を処理するためのいくつかの構成要素を有している。これらの構成要素は、要求ディストリビュータ２０４、１台または複数台のアプリケーションサーバ２０６、１つまたは複数のデータキャッシュ２０８、及び１つのデータソース１０８である。

要求ディストリビュータ２０４は、ユーザ２０２から要求を受信し、処理のためにその要求をアプリケーションサーバに割り当てる。要求ディストリビュータ２０４は、要求の結果をユーザ２０２に返すこともできる。複数のアプリケーションサーバが使用される場合には、要求ディストリビュータ２０４は、公知の分散技法を使用して複数台のアプリケーションサーバの間で要求を分散することによって、負荷バランシングを実行する。更に、要求ディストリビュータ２０４が、アプリケーションサーバが適切に機能していないと判断する場合、要求ディストリビュータ２０４は、他のアプリケーションサーバに要求を送り直してよい。要求ディストリビュータ２０４の機能が、プロキシサーバによって実行されてもよい。更に、ユーザ２０２とトランザクション処理システム１０４間の他の通信方法が、本発明に於いて使用されてもよい。

トランザクション処理システム１０４は、データソース１０８からのデータを用いて、ユーザの要求を処理するためにアプリケーションサーバ２０６を使用する。性能を向上させるために、アプリケーションサーバ２０６は、直接的にデータソース１０８にアクセスしなくても、１つまたは複数のデータキャッシュ２０８にアクセスし、データを取得できる。このプロセスは、図７Ａと図７Ｂに詳細に後述する。１つまたは複数のデータソース、１つまたは複数のデータキャッシュ、及び１台または複数台のアプリケーションサーバが、本発明に於いて使用されても良い。

図３は、本発明における、データソースの詳細なブロック図である。データソース１０８は、ユーザからの要求を処理するために必要なデータを格納する。例えば、オンライン株式取引システムや他のトランザクションシステムでは、一般的に、ユーザは、そのユーザに一意であるアカウント番号（アカウント番号は、口座番号、顧客番号、課金番号等を含む）を有する。本発明の１つの実施形態では、データストア１０８はその一意のアカウント番号に基づいて、独自のアカウントテーブル３０２の中に各アカウントのデータを格納する。製品やサービスに関係するデータなどの全てのアカウントに該当するデータは、マスタテーブル１０４に格納される。１つのアカウントテーブル３０２と１つのマスタテーブル３０４が図３に示されているが、複数のアカウントテーブル及び／またはマスタテーブルが、本発明に於いて使用出来る。

データソース１０８は、全ての実行中のデータキャッシュのテーブル３０８、及びアカウントを実行中のデータキャッシュと関連づける関連リスト３１０も含む。これらは、後述するように、データキャッシュ２０６との同期を維持するために使用される。

本発明の１つの実施形態では、一人のアカウントについてのデータは、１つのアカウントテーブルの中に格納され、１つのデータキャッシュの中にキャッシュされる。この実施形態を実現するために、関連リスト３１０は、各アカウントテーブルのリストを、そのアカウントテーブルからのデータのコピーを格納するデータキャッシュ２０８に対するリファレンスとともに格納する。それから、関連リスト３１０は、アカウントテーブル中のデータが変更すると、適切なデータキャッシュに通知するために用いられる。関連リスト３１０は、アカウントがデータキャッシュに割り当てられるたびに、要求ディストリビュータ２０４によって更新できる。この割り当ては、ユーザがシステムにログオンすると開始し、ユーザがシステムをログアウトするまで続行される。関連リスト３１０は、図７Ａと図７Ｂで後述するように、クエリーをどのキャッシュに送るのかを決定するために要求ディストリビュータ２０４によってアクセスされる。

テーブル３０８は、トランザクション処理システム１０４内で実行中である全てのデータキャッシュに対するリファレンスを有する。マスタテーブル中のデータが変更されると、それは全てのアカウントに影響を及ぼす可能性があるため、このような変更はテーブル３０８に一覧表示される全てのデータキャッシュ２０８に伝達できる。テーブル３０８は、新しいデータキャッシュが追加されるたびに、トランザクション処理システム２０８によって更新できる。このようにしてデータを格納すると、本発明は、例えばアカウント番号ごとにデータを領域化できるトランザクションシステムで特に役に立つ。

本発明の１つの実施形態では、データソース１０８は、アカウント番号などのセレクタキーのロックを動作可能にするセレクタロックテーブルを有する。セレクタキーはセレクタロックテーブルを使用してロックされるが、そのセレクタキーに対応するデータに変更を加えることはできない。

データソース１０８は、トランザクション処理システム１０４などのクライアントプロセスと通信するために、プロセス間通信チャネル３０６を用いる。プロセス間通信チャネル３０６は、例えば、Ｏｒａｃｌｅ（登録商標）ＤＭＢＳ−ＰＩＰＥ、Ｊａｖａ（登録商標）ＲＭＩ、またはデータソース１０８とデータキャッシュ２０８間での確実な情報の転送を実現する任意の他の技法を使用して実現できる。データソース１０８の追加機能は、リレーショナル方式でデータを格納することと、コミットされたデータを読み取ることと、プライマリーキーのクエリーを処理することと、必要に応じて行またはテーブルをロックすることと、データが変更するときにイベントを生成することとを有しても良い。これらは、数多くのデータベース管理システムの公知の機能である。従って、データソース１０８は、Ｊａｖａ（登録商標） Ｄａｔａｂａｓｅ Ｃｏｎｎｅｃｔｉｖｉｔｙ（ＪＤＢＣ）、ＳＱＬ、及びＯｒａｃｌｅ（登録商標）Ｄａｔａｂａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ（ＤＢＭＳ）などの利用可能なソフトウェアを使用して実現できる。説明を容易にするために、本説明では、データソース１０８をこれらの特徴を持つデータベースとして扱う。ただし、これらの機能を実現する確立されたプロトコルに準拠するリモートサーバなどの、任意の持続性のあるデータソースが本発明を実施するには十分である。

図４は、本発明における、サンプルアカウントテーブル４０２を示す。サンプルアカウントテーブル４０２に格納されるデータは、各行がプライマリーキーで特定される行で編成される。各プライマリーキーに対応するのは、レコードデータと行ロックである。アカウントテーブルの中では、プライマリーキーと、その対応するレコードデータは、以下のように定義されても良い。すなわち、プライマリーキー＝アカウント番号、レコードデータ＝現在残高、銀行支店番号である。行ロックが動作可能とされると、行の中の情報に変更を加えることはできない。他の実施形態では、テーブルロックや別個のロックテーブルが使用できるか、あるいは行ロックは完全に省略できる。レコードデータは、サンプルアカウントテーブル４０２に対応するデータセットを特定するセレクタキーも有する。例えば、アカウントに基づくシステムでは、セレクタキーがアカウント番号となる場合がある。他の実施形態では、テーブルがプライマリーキーを有していなくても良い。このような実施形態では、データソース１０８内の行を特定するために、データソースに特殊な識別子を使用できる。

図５は、本発明における、サンプルマスタテーブルを示す。サンプルマスタテーブル５０２に格納されるデータは、プライマリーキーによって行で編成される。各プライマリーキーに対応するのはレコードデータである。マスタテーブルでは、プライマリーキー及びそれに対応するレコードデータは、以下のように定義されても良い。すなわち、プライマリーキー＝製品ＳＫＵ（在庫維持単位数）、レコードデータ＝製品名、製造メーカ識別子である。サンプルマスタテーブルは、テーブルロックを有する。テーブルロックが動作可能とされると、テーブルの中の情報に変更を加えることはできない。他の実施形態では、このロックは、行ロック、別個のロックテーブを使用して実現できるか、あるいは完全に省略できる。レコードデータは、サンプルマスタテーブル５０２に対応するデータセットを特定するセレクタキーを有する。アカウントに基づくシステムでは、マスタデータは、全てのアカウントに当てはまるデータである場合がある。従って、マスタデータにとっては、セレクタキーは、データが全てのアカウントに当てはまることを示すための１または０などの公知の数である場合がある。

図６は、データキャッシュを詳細に示すブロック図である。データキャッシュ６０２は、１つまたは複数の領域に分割される。本発明の１つの実施形態では、各領域は、データソース１０８に格納されるアカウントテーブルに相当する。この実施形態では、単一のデータキャッシュは、多くのアカウントをサポートすることができ、システムが追加アカウントをサポートする必要があるときには、追加のデータキャッシュを追加できる。データキャッシュ６０２の中の各領域は、その領域内のデータセットを特定するセレクタキー６０４を有する。例えば、ユーザのアカウントに対応するデータが領域に格納される場合、セレクタキーはアカウント番号となっても良い。セレクタキー６０４に加えて、データキャッシュの各領域は２つのサブキャッシュを有する。すなわち、Ｉｍｐｌキャッシュ８０６とＥｎｕｍキャッシュ６０８である。これらのサブキャッシュは、データソース１０８から検索されるデータのコピーを格納する。

Ｉｍｐｌキャッシュ６０６内のエントリは、プライマリーキー６１０と対応するレコードデータ６１２を有する。Ｉｍｐｌキャッシュ６０６は、データソース１０８にアクセスしなくてもデータアイテムに対する要求を容易にするために使用できる。例えば、ユーザが自分の口座残高の要求を送信すると、その要求を処理するアプリケーションサーバは、プライマリーキー「アカウント番号（口座番号）」で、適切なＩｍｐｌキャッシュ６０６から検索をし、対応するレコードデータ（例えば、現在残高、銀行支店番号）を返す。クエリーの処理は、図７Ａと図７Ｂに詳述する。

Ｅｎｕｍキャッシュ６０８内のエントリは、クエリー６１４及びそのクエリーを満たすレコードが対応するリスト６１６を有する。Ｅｎｕｍキャッシュ６０８は、データソース１０８にアクセスしなくても、より複雑なクエリーを容易にするために使用できる。例えば、ユーザが、自分の最も最近の株式購入のリストに対する要求を送信すると、その要求を処理するアプリケーションサーバは、クエリー「最新の株式購入」を、適切なＥｎｕｍキャッシュ６０８から検索し、そのクエリーを満たすレコードが対応するリストを返す。クエリーの処理は、図７Ａと図７Ｂに詳述する。

図７Ａと図７Ｂは、本発明における、データキャッシュ方式を使用してクエリーを処理するためのフローチャート図を示す。プロセスは、アプリケーションサーバ２０６が、ユーザ２０２からセレクタキーを含むクエリーを受信すると開始する（ステップ７０２）。このクエリーは、要求ディストリビュータ２０４によって、アプリケーションサーバ２０６に送信される。１つの実施形態では、要求ディストリビュータ２０４は、各アカウントが割り当てられているアプリケーションサーバ及び／またはデータキャッシュのレコードを維持する。従って、要求ディストリビュータ２０４はクエリーを受信すると、要求ディストリビュータ２０４は、適切なアプリケーションサーバ及び／またはデータキャッシュにクエリーを送信する。他にも、要求ディストリビュータ２０４及びアプリケーションサーバ２０６は、データストア１０８内の関連リスト３１０にアクセス可能である。クエリーを処理するために、アプリケーションサーバ２０６はクエリーからのセレクタキーを使用し、必要な情報を、どのデータキャッシュが格納している可能性があるのか、すなわちこのセレクタキーによって特定されるデータのサブセットを、どのデータキャッシュが格納しているのかを判断する。アカウントに基づく実施では、セレクタキーがユーザのアカウント番号となっても良く、アプリケーションサーバ２０６は、ユーザのアカウントのデータを、どのデータキャッシュ領域が格納するのかを判断するために、アカウント番号を使用する。そのデータキャッシュ内では、アプリケーションサーバ２０６が、クエリーからの、セレクタキーを含む領域内で１つまたは複数の検索を実行する。

クエリー処理を開始する前に、セレクタキーについてセレクタロックを獲得する（ステップ７０３）。セレクタロックが入手できない場合、すなわち、他のプロセスがセレクタキーをロックしている場合は、クエリーはデータソースを使用して処理することができ、結果はキャッシュされない。このようにして、クエリーは、キャッシュが利用できなくても処理することができる。

セレクタロックを獲得すると（ステップ７０３）、アプリケーションサーバ２０６は、セレクタキー（ステップ７０４）を含むキャッシュ領域内で、Ｅｎｕｍキャッシュ内のクエリーを検索する。クエリーを満たすレコードのリストがＥｎｕｍキャッシュ内に存在する場合には（ステップ７０６）、アプリケーションサーバ２０６はレコードのそのリストをユーザに返す（ステップ７０８）。存在しない場合は、アプリケーションサーバ２０６はデータソース１０８にクエリーを送信する（ステップ７１０）。データソース１０８は、公知のデータベースツールを使用してクエリーを処理し、クエリーの結果を示す１つまたは複数のプライマリーキーを返す（ステップ７１２）。

従って、この処理を完了するためには、アプリケーションサーバ２０６は、１つまたは複数のプライマリーキーの各々に対応するレコードデータを取得しなければならない。これを行うために、アプリケーションサーバ２０６は、(依然としてセレクタキーを含むキャッシュ領域内の)Ｉｍｐｌキャッシュで、次のプライマリーキーを検索する（ステップ７１４）。次のプライマリーキーがＩｍｐｌキャッシュ内で発見されると、アプリケーションサーバ２０６は、対応するレコードデータを、Ｉｍｐｌキャッシュからクエリーの結果に追加する（ステップ７１６）。次のプライマリーキーが発見されない場合、アプリケーションサーバ２０６は、データソース１０８から、対応するレコードデータを取得する（ステップ７１８）。データソースは、公知のデータベースツールを使用して検索要求を処理し、次のプライマリーキーに対応するレコードデータを返す。その後、アプリケーションサーバ２０６は、次のプライマリーキー及びその対応するレコードデータをＩｍｐｌキャッシュの中に格納し（ステップ７２０）、レコードデータをクエリーの結果（ステップ７１６）に追加する。このようにして、Ｉｍｐｌキャッシュは、将来のクエリーの処理を改良するために更新される。

ステップ７１２に於いて、データソース１０８によって複数のプライマリーキーが返されると、各プライマリーキーに対応するレコードデータが取得され、クエリーの結果に追加されるまで、プロセスを繰り返す（ステップ７２２）。次に、アプリケーションサーバ２０６は、クエリーを含むエントリ及びクエリーの結果をＥｎｕｍキャッシュに追加し（ステップ７２４）、ユーザ２０２にクエリーの結果を返す（ステップ７２６）。このようにして、Ｅｎｕｍキャッシュは、将来のクエリーの処理を改良するために更新される。最後に、セレクタロックが解放される（ステップ７２７）。

上述したように、データソース１０８及びデータキャッシュ２０８内でのアカウントに従ったデータの領域化により、アプリケーションサーバ２０６は、基礎をなすデータについての知識がなくても非常に迅速にクエリーを処理することができる。このデータ領域化の他の利点は、データストア１０８内に格納されるデータに対するあらゆる変更が、図８、図９及び図１０に関して後述するように、シームレス且つ効率的にデータキャッシュ２０８と共用されるように、データキャッシュ２０８をデータソース１０８と同期させることである。他の利点としては、データソースに対する変更が、図８に関して後述するように、データキャッシュから削除される項目の数を最小にするという点である。

図８は、データソース１０８内のマスタデータが変更するときに、データキャッシュを更新するためのプロセスを示すフローチャート図である。このプロセスは、あるプロセスが、マスタテーブル内のプライマリーキーに対応する行でマスタデータ（すなわち、全てのアカウントに影響を及ぼすデータ）を変更しようとするときに開始する（ステップ８０２）。これは、例えば、システム管理者がトランザクション処理システムに新製品を付加するときに発生する可能性がある。データソース１０８は、変更する行を含むテーブルをロックし（ステップ８０４）、変更する行からセレクタキーを検索する（ステップ８０６）。ロックが使用できない場合、データソースは、ロックが使用できるようになるまで待機するか、あるいはトランザクションを打ち切ることができる。上述したように、マスタデータのセレクタキーは、例えば、データが全てのアカウントに影響を及ぼすことを示すために、０または−１などの予め定められた番号であってよい。

変更をデータキャッシュ２０８に警告するために、データストア１０８は、全ての実行中のデータキャッシュのテーブル３０８内に一覧表示される全てのデータキャッシュに無効メッセージを送信する（ステップ８０８）。この無効メッセージは、変更している行のプライマリーキー、セレクタキー、及び行の変更の種類（すなわち、追加、変更、または削除）を有している。データストア１０８は、プロセス間通信チャネル３０６を介してデータキャッシュに無効メッセージを送信する。データストア１０８は、各データキャッシュから応答を受信するために、予め定められた時間待機する（ステップ８１０）。データキャッシュの全てが無事に応答すると（ステップ８１２）、キャッシュを無効にし、データストア１０８は、変更可能とするためにテーブルをアンロックする（ステップ８１４）。データキャッシュの全てが無事に応答しない場合には、トランザクションを打ち切る（ステップ８１６）。例えば、データキャッシュがクラッシュした場合に、データキャッシュは無事に応答できない。

図９は、データソース１０８内のアカウントデータが変更するときに、データキャッシュを更新するためのプロセスを示すフローチャート図である。このプロセスは、あるプロセスが、アカウントテーブル内のプライマリーキーに対応する行の中のアカウントデータを変更しようとするときに開始する（ステップ９０２）。これは、例えば、株式取引が実行されるとき、または電子マネーによる支払いが素早く処理されたときに発生する可能性がある。データソース１０８は、変更している行をロックし（ステップ９０４）、変更している行からセレクタキーを検索する（ステップ９０６）。ロックが使用できない場合、データソース１０８は、ロックが使用できるようになるまで待機するか、あるいはトランザクションを打ち切る。行がロックされると、他のプロセスは行の中のデータを修正することはできない。データソース１０８は、関連リスト３１０を使用して、どのデータキャッシュがセレクタキーに対応するのか（すなわち、どのデータキャッシュがこのアカウントのためのデータを格納するのか）を判断する。

適切なデータキャッシュに変更を警告するため、データストア１０８は、判断されたデータキャッシュに無効メッセージを送信する（ステップ９１０）。無効メッセージは、プライマリーキー、セレクタキー、及び変更の種類（すなわち、追加、変更、または削除）を有する。データストア１０８は、プロセス間通信チャネル３０６を介してデータキャッシュに無効メッセージを送信する。データストア１０８は、データキャッシュから応答を受信するために、予め定められた時間待機する（ステップ９１２）。データキャッシュが無事に応答すると（ステップ９１４）、キャッシュは無効にされ、データストア１０８が、変更可能とするために行をアンロックする（ステップ９１６）。データキャッシュが無事に応答しない場合には、トランザクションを打ち切る（ステップ９１８）。例えば、データキャッシュがクラッシュすると、データキャッシュは無事に応答できない。

図１０は、データソースの変更に対してキャッシュを無効にするプロセスを示したフローチャート図である。このプロセスは、無効メッセージがデータキャッシュによって受信されると開始する（ステップ１００２）。上述したように、無効メッセージは、基礎をなすデータソースの中のデータが変更した旨を示す。無効メッセージはプライマリーキー、セレクタキーを有する。変更の種類が削除または更新のどちらかである場合には（ステップ１００４）、プライマリーキーに対応する、基礎をなすレコードデータが変更され、データキャッシュはこのデータの全ての古い（期限切れの）コピーを削除する。これを実行するために、セレクタキーに対応するデータキャッシュの領域の中では、プライマリーキーを含む全てのエントリが削除される（ステップ１００６）。これにより、プライマリーキーを含む、それ以降の要求で古いレコードデータが検索されないこととなる。更に、いったん基礎をなすレコードデータが変更されると、格納されるクエリーの結果が影響を受ける可能性がある。従って、セレクタキーに対応するキャッシュ領域内の全ての格納されるクエリーの結果が削除される。これを行うためには、セレクタキーに対応するデータキャッシュの領域内のＥｎｕｍキャッシュから、全てのエントリが削除される（ステップ１０１０）。

変更の種類が挿入である場合には（ステップ１００８）、Ｉｍｐｌキャッシュ内の公知のレコードデータを変更する必要はないが、格納されているクエリーの結果は正確であると信頼できなくなる。従って、セレクタキーに対応するキャッシュ領域内の全ての格納されるクエリー結果は削除される。これを行うために、セレクタキーに対応するデータキャッシュの領域内のＥｎｕｍキャッシュから、全てのエントリが削除される（ステップ１０１０）。

ここに説明したように、本発明は、データサイズが極端に大きくなるにつれ、性能は劣化しないことを意味する、極めて拡張性の高いデータをキャッシュに入れるための技法を実現する。更に、上述の方法を使用して、データキャッシュは、基礎をなすデータソースと同期し、その結果データがコミットされるときと、それが最初にキャッシュ内で入手可能になるときの間に遅延はない。

この技法は、ユーザごとのアカウント情報及びユーザ全体の製品情報がおもに分離できる、オンライン株式取引システムなどの高負荷（高容量）トランザクションシステムで特に役立つ。しかしながら、本発明は、容易に領域化されないデータを格納するためのシステムでもその効果を発揮する。

本発明の実施形態の上述の説明は、図解及び説明の為に示している。それは全ての例ではなく、ここで開示した実施形態に限定するものではない。変型やバリエーションは、上述の記載から可能であり、あるいは本発明の実施から得られる。本発明の追加の変型やバリエーションは、例えば、説明した実施形態ではソフトウェアを含むが、本発明は、ハードウェアとソフトウェアの組み合わせ、あるいはハードウェアだけで実現されてもよい。本発明は、オブジェクト指向型と非オブジェクト指向型の両方のプログラミングシステムにより実現可能である。

更に、当業者は他の構成により、本発明を実現可能である。例えば、データキャッシュは、性能向上を実現する為に、アプリケーションサーバと組み合わせることができる。他の実施形態では、無効メッセージは、アカウントデータが変更するのか、マスタデータが変更するのかに関係なく、全てのデータキャッシュに一斉送信できても良い。この場合、データのアカウントに特殊な領域かを用いることは必要ない場合もある。他の実施形態は、同時複数領域化方式を用いることも可能である。

更に、本発明の態様はメモリに格納されると説明したが、これらの態様が、ハードディスク、磁気ディスク、またはＣＤ−ＲＯＭのような二次格納装置などの他の種類のコンピュータ読取可能な媒体、インターネットや他の搬送媒体からの搬送波、あるいは他の形式のＲＡＭまたはＲＯＭに格納できる。発明の範囲は、クレーム及びその同等物により定義される。

Claims (31)

1. 各領域がアカウントに対応する複数の領域のあるデータキャッシュを使用してアカウント情報を処理する方法であって、
   前記方法は、
   ユーザからクエリー及びアカウント番号を受信するステップと、
   アカウント番号に対応するキャッシュ領域において、第１サブキャッシュでクエリーを検索するステップと、
   第１サブキャッシュでクエリーが発見されない場合には処理Ａを行うステップと、
   第１サブキャッシュでクエリーが発見されない場合には第１サブキャッシュ内のクエリーとともに格納されるレコードデータをユーザに返すステップと、
   からなり、
   前記処理Ａは、
   データストアにクエリーを送信し、
   データストアからクエリーに対する少なくとも１つのプライマリーキーを受信し、
   少なくとも１つのプライマリーキーの各々について、
   キャッシュ領域内の第２サブキャッシュでプライマリーキー及び対応するレコードデータを検索し、第２サブキャッシュでプライマリーキーが発見されない場合には、データストアからプライマリーキーに対応するレコードデータを取得し第２サブキャッシュにレコードデータ及びプライマリーキーを格納し、プライマリーキーに対応するレコードデータをユーザに返し、第１サブキャッシュに、クエリーとともにプライマリーキー及び対応するレコードデータを格納する、
   ことを特徴とする方法。
2. データストア内のマスタデータが変更した場合のデータキャッシュを更新するための方法であって、
   前記方法は、
   データストア内のマスタデータを変更するための、プライマリーキー及び変更の種類を含む要求を受信するステップと、
   データストア内のテーブルにプライマリーキーを含む行を配置するステップと、
   行からセレクタキーを検索するステップと、
   行を含むテーブルをロックするステップと、
   実行中のキャッシュサーバのテーブルに一覧表示される各キャッシュサーバにメッセージを送信するステップと、
   各キャッシュサーバから肯定応答が受信されると、行を含むテーブルをアンロックし、要求を承認するステップと、
   からなることを特徴とする方法。
3. メッセージがプライマリーキー、セレクタキー、及び変更の種類を含む
   ことを特徴とする請求項２に記載の方法。
4. 各キャッシュサーバから応答を受信するために、予め定められた時間待機すること
   をさらに備えることを特徴とする請求項２に記載の方法。
5. セレクタキーがアカウント番号である
   ことを特徴とする請求項２に記載の方法。
6. トランザクションを処理するための、データストアを備えるシステムであって、
   前記データストアは、メモリと、プログラムを実行するように構成されたプロセッサとを備え、
   前記メモリは、複数のアカウントに該当するマスタデータを含む複数のテーブルと、方法を実行するプログラムとを格納するように構成され、
   前記方法は、
   プライマリーキー及び変更の種類を含む、データストア内のマスタデータを変更するための要求を受信し、
   データストア内のテーブルにプライマリーキーを含む行を配置し、
   行からセレクタキーを検索し、
   行を含んだテーブルをロックし、
   実行中のキャッシュサーバのテーブルに一覧表示される各キャッシュサーバにメッセージを送信し、
   各キャッシュサーバからの肯定応答受信時に行を含むテーブルをアンロックする、
   ことを特徴とするシステム。
7. メッセージがプライマリーキー、セレクタキー、及び変更の種類を含む
   ことを特徴とする請求項６に記載のシステム。
8. 方法が、各キャッシュサーバから応答を受信するために、予め定められた時間待機する
   ことを更に備えることを特徴とする請求項６に記載のシステム。
9. セレクタキーがアカウント番号である
   ことを特徴とする請求項６に記載のシステム。
10. データストア内のアカウントデータが変更した場合のデータキャッシュを更新するための方法であって、
    前記方法は、
    格納されているアカウントデータを変更するための、プライマリーキーと変更の種類を含む要求を受信するステップと、
    データストア内のテーブルにプライマリーキーを含む行を配置するステップと、
    行からセレクタキーを検索するステップと、
    行をロックするステップと、
    セレクタキーに対応するデータキャッシュを決定するステップと、
    プライマリーキー、セレクタキー、及び変更の種類を含むメッセージを、決定されたデータキャッシュに送信するステップと、
    決定されたサーバから肯定の応答が受信されると、行をアンロックし、要求を承認するステップと、
    を備えることを特徴とする方法。
11. 決定されたサーバから応答を受信するために、予め定められた時間待機することをさらに備える
    ことを特徴とする請求項１０に記載の方法。
12. 変更の種類がデータストアからレコードを削除することである
    ことを特徴とする請求項１０に記載の方法。
13. 変更の種類がデータストアのレコードを更新することである
    ことを特徴とする請求項１０に記載の方法。
14. 変更の種類がデータストアにレコードを追加することである
    ことを特徴とする請求項１０に記載の方法。
15. トランザクションを処理するための、データストアを備えるシステムであって、
    前記データストアは、メモリと、プログラムを実行するように構成されたプロセッサとを備え、
    前記メモリは、各テーブルがアカウントに対応する複数のテーブルと、方法を実行するプログラムとを格納するように構成され、
    前記方法は、
    格納されているアカウントデータを変更するための、プライマリーキー及び変更の種類を含む要求を受信し、
    データストア内のテーブルの中にプライマリーキーを含む行を配置し、
    行からセレクタキーを検索し、
    行をロックし、
    セレクタキーに対応するデータキャッシュを決定し、
    プライマリーキー、セレクタキー、及び変更の種類を含むメッセージを決定されたデータキャッシュに送信し、
    決定されたサーバからの肯定応答の受信時に行をアンロックする、
    ことを特徴とするシステム。
16. 方法が、決定されたサーバから応答を受信するために、予め定められた時間待機すること
    をさらに備えることを特徴とする請求項１５に記載のシステム。
17. 変更の種類がデータストアからレコードを削除することである
    ことを特徴とする請求項１５に記載のシステム。
18. 変更の種類がデータストアのレコードを更新することである
    ことを特徴とする請求項１５に記載のシステム。
19. 変更の種類がデータストアにレコードを追加することである
    ことを特徴とする請求項１５に記載のシステム。
20. 各領域がアカウントに対応する複数の領域を有するデータキャッシュであって、
    前記データキャッシュは、
    少なくとも１つのクエリーを、少なくとも１つのクエリーに対する結果とともに格納するように構成され、アカウント番号に対応する領域内の第１サブキャッシュと、
    プライマリーキーを含む少なくとも１つのエントリを、プライマリーキーに対応するレコードデータとともに格納するように構成され、アカウント番号に対応する領域内の第２サブキャッシュと、
    プロセッサとからなり、
    前記プロセッサは、
    アカウント番号、ターゲットプライマリーキー、及び変更の種類を含むメッセージを受信し、
    アカウント番号に対応する領域において、変更の種類が削除である場合にターゲットプライマリーキーを含む第２サブキャッシュからエントリを削除し、変更の種類が更新である場合に、ターゲットプライマリーキーを含む第２サブキャッシュからエントリを削除し、第１サブキャッシュのコンテンツを削除する、
    ことを特徴とするデータキャッシュ。
21. プロセッサが、
    エントリが第１サブキャッシュから削除された後に、成功メッセージを送信するようにさらに構成される
    ことを特徴とする請求項２０に記載のデータキャッシュ。
22. プロセッサが、
    エントリが第２サブキャッシュから削除された後に、成功メッセージを送信するようにさらに構成される
    ことを特徴とする請求項２０に記載のデータキャッシュ。
23. プロセッサが、
    エントリが第１サブキャッシュから削除され、エントリが第２サブキャッシュから削除された後に、成功メッセージを送信するようにさらに構成される
    ことを特徴とする請求項２０に記載のデータキャッシュ。
24. データストア内のデータが変更した場合にデータキャッシュを更新するための方法であって、
    前記方法は、
    アカウント番号に対応する領域内の第１サブキャッシュに、少なくとも１つのクエリーを、少なくとも１つのクエリーに対応する結果とともに格納するステップと、
    アカウント番号に対応するキャッシュ領域内の第２サブキャッシュに、プライマリーキーを含む少なくとも１つのエントリを、プライマリーキーに対応するレコードデータとともに格納するステップと、
    アカウント番号、ターゲットプライマリーキー、及び変更の種類を含むメッセージを受信するステップと、
    アカウント番号に対応する領域において、変更の種類が削除である場合にターゲットプライマリーキーを含む第２サブキャッシュからエントリを削除し、変更の種類が更新である場合にターゲットプライマリーキーを含む第２サブキャッシュからエントリを削除し、第１サブキャッシュのコンテンツを削除するステップと、
    を備えることを特徴とする方法。
25. エントリが第１サブキャッシュから削除された後に成功メッセージを送信することをさらに備える
    ことを特徴とする請求項２４に記載の方法。
26. エントリが第２サブキャッシュから削除された後に成功メッセージを送信することをさらに備える
    ことを特徴とする請求項２４に記載の方法。
27. エントリが第１サブキャッシュから削除され、エントリが第２サブキャッシュから削除された後に、成功メッセージを送信することをさらに備える
    ことを特徴とする請求項２４に記載の方法。
28. データストア内のマスタデータが変更した場合にデータキャッシュを更新するための方法であって、
    前記方法は、
    データストア内のマスタデータを変更するための、プライマリーキー及び変更の種類を含む要求を受信するステップと、
    データストア内のデータ構造にプライマリーキーを含むエントリからセレクタキーを検索するステップと、
    エントリを含むデータ構造をロックするステップと、
    実行中のキャッシュサーバ群で特定される各キャッシュサーバにメッセージを送信するステップと、
    各キャッシュサーバからの肯定応答受信時に、エントリを含むデータ構造をアンロックし、要求を承認するステップと、
    を備えることを特徴とする方法。
29. メッセージがプライマリーキー、セレクタキー、及び変更の種類を含む
    ことを特徴とする請求項２８に記載の方法。
30. 各キャッシュサーバから応答を受信するために、予め定められた時間待機することをさらに備える
    ことを特徴とする請求項２８に記載の方法。
31. セレクタキーがアカウント番号である
    ことを特徴とする請求項２８に記載の方法。

Images