JP4306152B2 - クラスタ化したアプリケーションサーバおよびデータベース構造を持つWebシステム - Google Patents
クラスタ化したアプリケーションサーバおよびデータベース構造を持つWebシステム Download PDFInfo
- Publication number
- JP4306152B2 JP4306152B2 JP2001192189A JP2001192189A JP4306152B2 JP 4306152 B2 JP4306152 B2 JP 4306152B2 JP 2001192189 A JP2001192189 A JP 2001192189A JP 2001192189 A JP2001192189 A JP 2001192189A JP 4306152 B2 JP4306152 B2 JP 4306152B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- database
- cache
- cache database
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 238000000034 method Methods 0.000 claims description 108
- 230000008569 process Effects 0.000 claims description 78
- 238000012545 processing Methods 0.000 claims description 49
- 238000007726 management method Methods 0.000 claims description 30
- 238000013523 data management Methods 0.000 claims description 24
- 230000000903 blocking effect Effects 0.000 claims description 14
- 238000003672 processing method Methods 0.000 claims description 12
- 230000007246 mechanism Effects 0.000 claims description 10
- 238000006243 chemical reaction Methods 0.000 claims description 9
- 238000012217 deletion Methods 0.000 claims description 8
- 230000037430 deletion Effects 0.000 claims description 8
- 238000012546 transfer Methods 0.000 claims description 6
- 238000010586 diagram Methods 0.000 description 8
- 230000008521 reorganization Effects 0.000 description 5
- 238000010276 construction Methods 0.000 description 4
- 238000013507 mapping Methods 0.000 description 4
- 230000008859 change Effects 0.000 description 3
- 238000004891 communication Methods 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 238000005192 partition Methods 0.000 description 2
- 208000009989 Posterior Leukoencephalopathy Syndrome Diseases 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 238000006731 degradation reaction Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/957—Browsing optimisation, e.g. caching or content distillation
- G06F16/9574—Browsing optimisation, e.g. caching or content distillation of access to content, e.g. by caching
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99932—Access augmentation or optimizing
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99938—Concurrency, e.g. lock management in shared database
Landscapes
- Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【発明の属する技術分野】
本発明は、アプリケーションサーバのクラスタ化方法、およびデータベースサーバのデータをキャッシュするキャッシュデータベースクラスタの構成方法、およびこれら方法を用いて構成されたWebシステムに関する。
【0002】
【従来の技術】
Web環境でのシステム構築では、大規模構成での性能確保、およびシステム負荷の急激な変動に柔軟に対応できる運用性向上という2つの観点から、スケーラビリティの確保が重要な課題となっている。特に近年、多数のユーザが実時間処理に近いシステムレスポンスを要求する大規模なECサイトや、ユーザごとにカスタマイズされたページを動的に生成するポータルサイトが盛んに構築されつつある。これらのシステムではデータベースに対するアクセス数が従来よりも著しく増加することが予想され、スケーラビリティの確保はますます重要な課題となっている。
Webシステムの構築では現在、図3に示すようにWebサーバ(304、305)−アプリケーションサーバ(307)−データベースサーバ(309)の3階層構成が用いられるのが普通である。クライアントからの該Webシステム利用セッションの例を図3を用いて説明する。クライアント計算機301、302(以下、クライアント)はネットワーク303を介して前記Webサーバにリクエストを発行する。該リクエストを受け付けたWebサーバは、ネットワーク306を介して、該リクエストを前記アプリケーションサーバに転送する。アプリケーションサーバでは前記リクエストを処理するアプリケーションを実行して処理結果を生成し、該処理結果をWebサーバに返す。Webサーバはアプリケーションサーバより受け取った処理結果を埋め込んだWebページを作成してクライアントに返し、1回のセッションが終了する。さらに、前記アプリケーションが前記データベースサーバ中のデータベース(311)へのアクセスを必要とする場合、アプリケーションサーバはネットワーク308を介してデータベースサーバ309にアクセスし、データベースサーバ内のデータベースシステム310を介してデータベース311内のデータを取得もしくは更新する。
図3のシステム構成で示す通り、WebシステムではWebサーバをクラスタシステムで構成することが多い。例えば図3ではWebサーバ1(304)からWebサーバL(305)のL個のクラスタが用いられている。Webサーバのクラスタ化は、主にクライアントの増加等の負荷増大に対応するスケーラビリティ確保の目的で行われる。Webサーバのクラスタ化が容易な理由として、クライアントとWebサーバ間の通信で用いられるHypertext Transfer Protocol(以下、HTTP)が状態を保持しない(stateless)ことがあげられる。HTTPが状態を持たないということは、クライアントとWebサーバ間の通信は通信が行われる毎に新たなセッションとすればよいため、そのセッションをクラスタ中の任意のWebサーバに割り当てればよいことを意味する。すなわち、ユーザの増加等の負荷増大に対して、ラックマウントタイプの薄型のサーバを順次追加してシステムを増強するというような対応が可能となる。
これに対してアプリケーションサーバは、アプリケーションが状態(state)を持つため、単純にサーバ(ハードウェア)をクラスタ化してもうまくいかなかった。具体例を挙げてその理由を説明する。負荷を分散させるために複数のアプリケーションサーバで同一のアプリケーションを実行させた環境を想定する。Webシステムではユーザとのインタラクションによって処理を進めるのが普通である。例えば、Webサイトで本を購入する処理を考えた場合、(1)最初に本を検索し、次に(2)検索した中から購入する本を決定し、(3)購入した本の送付先を入力し、(4)最後にクレジットカード等で決済を行う。この論理的なセッション(以下論理セッションと呼ぶ)である購入処理(1)〜(4)が1つのアプリケーションとして実現されているとすると、該アプリケーションは(1)〜(4)のそれぞれのフェーズでクライアント−Webブラウザ間のHTTPプロトコルを用いたWebセッション(以下、Webセッションと呼ぶ)を伴う。
アプリケーションサーバが1つだけの場合には、例えWebサーバがクラスタ化され、複数であったとしてもアプリケーションサーバ中に(1)〜(4)の論理セッションの状態を保存することにより処理を継続できる。例えば、特開平11−149449には、データベースサーバで、処理を行う際にセッションIDを付与してその処理状態を保持し、継続が必要な処理に対してはクライアントにセッションIDを転送し、クライアントからのリクエストにセッションIDが含まれている場合には保持した状態から処理を継続する方法が開示されている。該方法ではセッションを実行するスレッドを停止することによって状態を保持し、リクエストによって該スレッドの実行を再開することで処理を継続する。しかしながら該方法を用いた場合にも、アプリケーションを継続実行するサーバの変更は困難である。なぜならば、前記(1)〜(4)の各Webセッションが異なるWebサーバに割り当てられ、該Webサーバから前回処理を行っていたアプリケーションサーバと異なるサーバにリクエストが転送された場合に、前回までの論理セッション状態を得ることができず、該論理セッションを継続することができないためである。
データベースサーバに関してはデータの一貫性確保のため、通常1つのデータベース管理システムで全データを集中管理する。このため、アプリケーションサーバと同様にクラスタ化によるスケーラビリティ向上は困難であった。文献"Oracle 9i Application Server Database cache"には、アプリケーションサーの性能向上のための方法を開示している。該方法では、データベースサーバ中のデータをテーブル単位でWebサーバにキャッシュし、必要に応じて該キャッシュデータを利用してデータベースサーバへのアクセスを回避する。これにより、データベースサーバの負荷を削減し、スケーラビリティを向上させる。しかしながら、該方法では更新処理が発生した場合にはキャッシュでは処理が行えず、結局データベースサーバでの処理が必要となり性能が低下する。また、通常データベースサーバ上のテーブルはそのサイズが非常に大きいため、Webサーバで通常用いられる安価なクラスタサーバを用いた場合にはテーブル単位のキャッシングは不可能な場面も多い。
【0003】
【発明が解決しようとする課題】
大規模構成のWebシステム構築においては、アプリケーションサーバおよびデータベースサーバのスケーラビリティの確保が困難であり、ユーザの増加、システム負荷の急激な増加への対応が課題となっていた。
さらに、スケーラビリティの確保が困難であることに起因して、Webシステムの性能を確保するために、処理のボトルネックとなるアプリケーションサーバやデータベースサーバに高価な高多重SMPサーバを用いる必要があり、が不可能となっていた。
本発明の一つの目的は、システムのスケーラビリティを高め、ひいては要求される規模の大小によらず性能を確保が容易なWebシステムを提供するにある。
本発明の具体的な目的は、アプリケーションサーバのクラスタ化を可能とする方法を提供することである。
本発明の別の具体的な目的は、データベースサーバのクラスタ化されたキャッシュ(以下、キャッシュデータベースクラスタと呼ぶ)を提供することである。
さらに別の具体的な目的は、アプリケーションサーバやデータベースサーバに効果な項多重SMPサーバではなくクラスタを用い、ストパフォーマンスの高いWebシステム構築方法を提供することである。
【0004】
【課題を解決するための手段】
前記の目的を達成するための本発明の代表的構成を以下に列挙する。
まず、本発明ではアプリケーションの論理セッション状態を必要に応じてクラスタ化したキャッシュデータベースに保存し、該セッション状態をキャッシュデータベースから読み出す機構を提供する。本機構を利用することにより、前記アプリケーションの処理を異なるクラスタサーバ上で動作する該アプリケーションで継続実行することができ、アプリケーションサーバのクラスタ化が可能となる。また、本発明ではクラスタサーバ上に更新が可能なキャッシュデータベースクラスタを作成し、データベースサーバの負荷を削減する。該更新処理の整合性を確保するために、必要に応じてデータベースサーバと同期させる機構を提供する。キャッシュデータベースクラスタ内のキャッシュデータベースは、テーブルを部分的にキャッシュすることも可能であり、キャッシュの空き容量に応じて最適なキャッシングを実現する。本機構により、更新処理時のデータベースサーバへのアクセスも削減でき、データベースサーバのスケーラビリティを高めることができる。
また、前記アプリケーションサーバのクラスタ化方法、前記キャッシュデータベースクラスタ構成方法に加えて、本発明ではキャッシュデータベースクラスタに対するキャッシュデータベースの自動追加機構を提供する。本機構を用いることにより、容易にコストパフォーマンスが高く、しかもスケーラビリティが高いクラスタシステムが構築できる。
【0005】
【発明の実施の形態】
本発明を適用した好適なWebシステムの実施形態を図1に示す。図1ではクライアント計算機1(101)〜クライアント計算機K(102)がネットワーク103を介してWebサーバ1(104)〜WebサーバL(105)に接続されている。Webサーバはさらに、ネットワーク109を介してアプリケーションサーバ1(107)〜アプリケーションサーバM(108)に接続されている。また、前記アプリケーションサーバはネットワーク109を介してキャッシュデータベースクラスタ110に接続されている。
キャッシュデータベースクラスタは複数のキャッシュデータベースサーバで構成される。例えば、図1では前記キャッシュデータベースクラスタにはキャッシュデータベースサーバ1(111)〜キャッシュデータベースサーバN(113)のN個のクラスタサーバが含まれている。それぞれのキャッシュデータベースサーバは、内部にキャッシュデータベース(112、118)を含む。キャッシュデータベースサーバの内部構成に関しては後述する。
さらに、前記キャッシュデータベースクラスタはネットワーク117を介してデータベースサーバ1(114)〜データベースサーバO(120)に接続されている。該データベースサーバはその内部に、元データを管理するデータベース116、120を含む。データベースサーバの内部構成に関しても後述する。
ネットワーク103、106、109、および117はイーサネット、光ファイバ等で接続されるローカルエリアネットワーク(LAN)、もしくはLANよりも低速なインターネットを含んだワイドエリアネットワーク(WAN)でも差し支えない。クライアント計算機は、(株)日立製作所のHitachi FLORAなどのパーソナルコンピュータ、(株)日立製作所のHitachi 9000VワークステーションシリーズJ6000などの任意のコンピュータシステム、(株)日立製作所のPersonaなどの携帯端末、もしくは問合せインタフェースを持つ携帯電話でも差し支えない。また、前記Webサーバ、前記アプリケーションサーバ、前記キャッシュデータベースサーバは(株)日立製作所のHitachi 9000VワークステーションシリーズJ6000などの任意のワークステーション、(株)日立製作所のHitachi 9000V A500などの省スペースローエンドサーバで差し支えない。前記データベースサーバは(株)日立製作所のHitachi 9000VハイエンドサーバVT850もしくはミッドレンジサーバN4000で差し支えない。
以下では、図1の構成のWebシステムにおける、(1)アプリケーションサーバクラスタ化方法、(2)キャッシュデータベースクラスタ構成方法および利用方法を説明する。(2)に関してはさらに、(i)キャッシュデータベースクラスタを用いた問合せ処理方法、(ii)データベースサーバでのトランザクション処理方法、そして(iii)キャッシュデータベース追加処理方法の順に例に基づいて説明する。
なお、Webシステムにおいては、ユーザはクライアント計算機上で稼動する専用プログラム、もしくはMicrosoft社のInternet ExplorerやNetscape社のNetscape CommunicatorなどのWebブラウザを利用してシステムに対して問合せを発行し、該問合せに対する結果を取得するのが普通である。そのため、厳密には問合せの発行元および最終結果取得先はユーザとなるが、以降の説明では簡単のため、問合せの発行元、最終結果の取得先をクライアントと考える。本単純化は、本発明の本質には影響を及ぼさない。
最初にアプリケーションサーバクラスタ化方法を説明する。本発明の好適な実施例では、図1で示すようにクライアントから発行された問合せはWebサーバで受け付けられ、処理に必要なアプリケーションを実行するアプリケーションサーバに転送される。従来の技術で述べた通り、通常アプリケーションは状態を保持するため、任意のアプリケーションサーバ上で稼動するアプリケーションに処理を割り当てても該処理を継続できず、Webシステムでのアプリケーションサーバのクラスタ化は困難であった。そこで、本実施例では論理セッションの状態をキャッシュデータベースクラスタ110中のいずれかのキャッシュデータベース(112、118)に保存し、該保存状態をアプリケーションで読み出す機構を提供することにより、任意のアプリケーションサーバ上のアプリケーションで処理の継続を可能とする。以下では、アプリケーションのキャッシュデータベースへの状態保存方法、および該保存状態を用いた論理セッション継続処理の詳細を説明する。
アプリケーションサーバ1(107)上で稼動するアプリケーションが論理セッション状態を保存する処理を説明する。処理の流れを示すフローチャートを図14に示す。最初に、状態を保存しようとするアプリケーションは、状態を保存するキャッシュデータベースを決定する(ステップ1402)。該キャッシュデータベースの決定方法としては、例えばシステム内でユニークな値となるセッションIDにハッシュ関数を適用して保存先のキャッシュデータベースを決定すればよい。システム内でユニークな値となるセッションIDの生成方法としては、例えばWebサーバの固有IDと該Webサーバ内で生成したユニークなIDの連結を行えばよい。
本の購入セッションの例で説明したように、論理セッション内には複数のHTTPセッションが含まれる。クラスタ化したWebサーバで、論理セッション毎にユニークなセッションIDを付与するためには、(1)クライアントからのリクエストにセッションIDが含まれていない場合には前述のユニークなセッションIDを生成し、論理セッションの途中でクライアントとHTTPセッションを行う際には、前記セッションIDを付与した値を返す。(2)クライアントからリクエストにセッションIDが含まれている場合には、該セッションIDを用いる、という方法を用いればよい。
状態保存先キャッシュデータベースの決定後、アプリケーションの状態をキャッシュデータベースに書き込む(ステップ1403)。キャッシュデータベースでの状態書き込み、および該状態の読み出し処理は、図2に示すキャッシュデータベースサーバ内のセッション管理部(207)が行い、書き込まれるデータはセッション管理テーブル222として保持される。該セッション管理テーブルは、キャッシュデータベース112内にデータベーステーブルとして保持しても、もしくはキャッシュデータベースサーバのメモリ上に保持しても、もしくはキャッシュデータベースサーバ上のファイルとして保持するのでも差し支えない。
セッション管理テーブルの例を図16に示す。保持する情報はセッションID、継続対象のアプリケーション名とその継続チェックポイント、および継続時に利用する変数とその値の組である。例えばセッションIDが10021の論理セッションに関しては、そのアプリケーション名がcustomer_management、セッションの進行状況を表すチェックポイントが15、該チェックポイントで保存すべき変数はc_idおよびc_nameで、その値はそれぞれ、10、"Itaru Nishizawa"である。状態の書き込み後、アプリケーションはクライアントに現在のセッションIDを返し(ステップ1404)、論理セッション状態保存処理を終了する(ステップ1405)。
次に、キャッシュデータベースに保存された論理セッション状態を利用してアプリケーションを継続するための方法を図15のフローチャートを用いて説明する。アプリケーションサーバはWebサーバからリクエストを受け付けると、該リクエストにセッションIDが含まれているか否かをチェックする。セッションIDが含まれている場合、該セッションIDから論理セッション状態を書き込んだ場合と同様の方法でキャッシュデータベースを特定し(ステップ1508)、該キャッシュデータベース中の論理セッション状態を検索する(ステップ1502)。キャッシュデータベース中に論理セッションの状態が保存されていなかった場合(ステップ1503でNoが選択された場合)、継続処理はアボートする(ステップ1508)。論理セッションの状態が保存されていた場合(ステップ1503でYesが選択された場合)には、キャッシュデータベースから該論理セッション状態を読み出す(ステップ1504)。例えば、セッションIDとして10021が指定されたとすると、図16のセッション管理テーブルの検索により、アプリケーションcustomer_managementがチェックポイント15で停止しており、該チェックポイントでの変数とその値がc_id=10、c_name="Itaru Nishizawa"であることがわかる。状態読み出し後、キャッシュデータベースから該論理セッション状態を削除する(ステップ1505)。そして読み出した状態を利用してアプリケーションセッション(論理セッション)を継続する(ステップ1506)。
以上で、キャッシュデータベースへの状態保存し、該保存データ読み出し機構を利用したアプリケーションの処理継続方法を説明した。該方法によって、アプリケーションサーバのクラスタ化が可能となり、アプリケーションサーバのスケーラビリティが向上する。
次に、データベースサーバのスケーラビリティを向上させるためのキャッシュデータベースクラスタの構成方法、およびその利用方法について説明する。
最初にキャッシュデータベースクラスタを用いた問合せ処理方法を説明する。前述した通り、キャッシュデータベースクラスタ中の各キャッシュデータベースは、アプリケーションからのデータベースサーバへのアクセスの際にデータをキャッシュし、データベースサーバへのアクセスを削減することによって、システム全体のスケーラビリティを向上させる。
図1の構成のWebシステムでは、アプリケーションサーバは所望のデータを取得するためにキャッシュデータベースクラスタ110にアクセスする。該アプリケーションが該キャッシュデータベースクラスタ中のどのキャッシュデータベースにアクセスするかを決定するための方法としては、例えば図17に示すような、アプリケーションで利用するデータと該データを格納するキャッシュデータベースの組合せを記述する、アプリケーション−キャッシュデータベースマッピングテーブルをアプリケーションサーバに保持し(121、122)、該テーブルを参照すればよい。例えば、図17の該テーブルの参照により、アプリケーションcustomer_managementが参照するテーブルc_addressのc_id=100のデータを参照するためには、キャッシュデータベースサーバのキャッシュデータベース1を参照すればよいことがわかる。本発明のキャッシュデータベースクラスタでは、各キャッシュデータベースへ格納されるデータ自体は頻繁に更新されるが、キャッシュされるべきデータの範囲の変更は頻繁には行われない。そのため、該テーブルの更新は後述するキャッシュデータベース再編成処理時に実行するので差し支えない。
アクセス対象となるキャッシュデータベースを決定した後の、キャッシュデータベースサーバでの問合せ処理ステップを図2、および図4のフローチャートを用いて説明する。但し、以下の例ではアプリケーションがアクセス対象のキャッシュデータベースとして、キャッシュデータベース1を選択したと仮定する。アプリケーションサーバより転送された問合せは、キャッシュデータベースサーバ1(111)のネットワークインタフェース部202を介して、キャッシュ利用可否判定部(203)に送られる。該キャッシュ利用可否判定部では、キャッシュデータベース内に所望のデータが存在するか否かを、格納データ管理テーブル223を用いてチェックする。該格納データ管理テーブルの具体例を図5に示す。格納データ管理テーブル223には、キャッシュデータベース1で管理されるキャッシュデータに関する情報が格納されている。データベースサーバ名(502)およびデータベース名(503)は、キャッシング対象のデータベースサーバ名と該データベースサーバ中のデータベース名を、テーブル名および属性名(504)はキャッシュ対象のテーブル名と属性名を、分割キー(505)は該テーブルをキャッシュデータベースクラスタ間で分割格納する際の分割キーを、キャッシュ対象データ条件(506)はキャッシュ対象となるデータの条件を、キャッシュ済みデータ条件(507)は前記キャッシュ対象データ条件を満たし、かつ実際にキャッシュデータベース1にキャッシュされているデータの範囲を、リフレッシュポリシー(508)はキャッシュデータのリフレッシュを行う際の置き換えポリシーを、そして更新可否(509)は、キャッシュデータベース1上でキャッシュデータに関する更新の可否を表している。例えば、格納データ管理テーブル203の1行目のレコードは、キャッシュデータベース1のキャッシングの対象が、データベースサーバ1のCustomerデータベース中のc_addressテーブルのc_id、c_name、c_address、c_phoneの4つの属性からなり、かつ1<=c_id<100000の条件を満たすレコードであること、また現在は該キャッシング対象のうち1<=c_id<50000の条件を満たすレコードが実際にキャッシングされていること、そして該キャッシングデータをリフレッシュする際のポリシーがLRUで、該データのキャッシュデータベース1上での更新は可であることを示している。該格納データ管理テーブルにおいて、キャッシュ済みデータ条件は範囲指定の条件で示されているが、格納データを表すビットマップを用いる実現も可能である。
図4に戻って、キャッシュデータベース内にデータが存在する場合(ステップ402でYesが選択された場合)には、アプリケーションからデータベースサーバ向けの発行された問合せをキャッシュデータベース中のデータを参照するように変換する(ステップ403)。キャッシュデータベース内に存在するデータで、与えられた問合せを処理可能か否かの判定は、問合せと前記キャッシュ済みデータ条件を比較することによって行うことができる。判定のための方法としては、例えばJeffrey D.Ullman著、"PRINCIPLES OFDATABASE AND KNOWLEDGE−BASE SYSTEMS"、VOLUME II,COMPUTER SCIENCE PRESS,ISBN 0−7167−8162−X,第14章"Optimization for Conjunctive Queries"(文献4)に開示されている、Query Equivalence、Query Containmentと呼ばれる方式を用いることにより、条件間の同値関係および包含関係を調べることができる。該方式を用いて前記キャッシュ済みデータ条件と問合せの条件の関係を判定し、キャッシュ済みデータ条件が問合せ条件を包含する、もしくは等しい場合にはキャッシュ内のデータを用いて問合せが処理可能と判定できる。該問合せが参照処理のみを含む場合(ステップ404でNoが選択された場合)には、キャッシュデータベースより結果を取得し、アプリケーションに返して(ステップ405)、問合せ処理を終了する(ステップ406)。前記問合せ変換処理は図2における問合せ変換部204で、キャッシュデータベースに対する問合せ発行および結果取得は、問合せ発行部205で発行した問合せをデータ検索・更新部206がキャッシュデータベース112中のキャッシュ済みデータ210を検索し、その値を取得することで実行する。
前記問合せがデータベースに対するデータ更新、データ削除、データ追加のいずれかの処理(データベースの標準問合せ言語SQLではUPDATE,INSERT,DELETEに相当する)を含む場合(ステップ404でYesが選択された場合)には、キャッシュデータベース更新処理を実行し(ステップ407)、更新処理結果のステータスをアプリケーションに返して(ステップ408)、キャッシュデータベースサーバでの問合せ処理を終了する(ステップ406)。前記キャッシュデータベース更新処理を図7のフローチャートを用いて説明する。先に述べた通り、本発明で想定するデータベースの更新処理はデータ更新、データ削除、もしくはデータ追加のいずれかである。もし更新処理がデータ更新の場合(ステップ702でYes、ステップ703でNoが選択された場合)、更新データサイズが更新前の元データサイズと等しいかそれよりも小さいかをチェックする(ステップ704)。もし更新データサイズが元データサイズと等しいかそれよりも小さい場合(ステップ704でYesが選択された場合、キャッシュデータベースに更新後の値を保存することができるため、更新内容をキャッシュデータベースログ(但し図7および図8では単にログと表す)に記録し(ステップ713)、キャッシュデータベースのデータを更新し(ステップ714)、図5の格納データ管理テーブルのキャッシュ済みデータ条件(507)のエントリが存在する場合にはその値を更新して(ステップ708)、キャッシュデータベース更新処理を終了する(ステップ709)。前記更新内容を記録したキャッシュデータベースログ211は、図2のキャッシュデータベース112中に保持され、キャッシュデータベースに対する更新の履歴を全て管理する。該キャッシュデータベースログ管理機構は、例えば(株)日立製作所のHiRDBなどの汎用DBMS製品を用いて実現することができる。
図7のステップ704に戻り、更新データサイズが更新前の元データサイズよりも大きい場合(ステップ704でNoが選択された場合)には、キャッシュスロット確保処理を実行し(ステップ705)、更新内容を前記キャッシュデータベースログに記録し(ステップ706)、キャッシュデータベースのデータを更新し(ステップ707)、前記格納データ管理テーブルのキャッシュ済みデータ条件(図5の507)のエントリが存在する場合にはその値を更新して(ステップ708)、キャッシュデータベース更新処理を終了する(ステップ709)。キャッシュスロット確保処理に関しては後述する。
更新処理がデータ削除の場合(ステップ702、703でともにYesが選択された場合)、更新内容を前記キャッシュデータベースログに記録し(ステップ711)、キャッシュデータベースから該当するデータを削除して(ステップ712)、前記格納データ管理テーブルのキャッシュ済みデータ条件(図5の507)のエントリが存在する場合にはその値を更新して(ステップ708)、キャッシュデータベース更新処理を終了する(ステップ709)。
最後に、更新処理がデータ追加の場合(ステップ702でNoが選択された場合)、追加のための領域が存在するか否かをチェックする(ステップ710)。追加のための領域が存在する場合(ステップ710でYesが選択された場合)には、更新内容を前記キャッシュデータベースログに記録し(ステップ716)、キャッシュデータベースにデータを追加して(ステップ717)、前記格納データ管理テーブルのキャッシュ済みデータ条件(507)のエントリが存在する場合にはその値を更新して(ステップ708)、キャッシュデータベース更新処理を終了する(ステップ709)。追加のための領域が存在しない場合(ステップ710でNoが選択された場合)には、キャッシュスロット確保処理を実行し(ステップ715)、更新内容を前記キャッシュデータベースログに記録し(716)、キャッシュデータベースにデータを追加して(ステップ717)、前記格納データ管理テーブルのキャッシュ済みデータ条件(507)のエントリが存在する場合にはその値を更新して(ステップ708)、キャッシュデータベース更新処理を終了する(ステップ709)。
前記キャッシュスロット確保処理を図8のフローチャートを用いて説明する。キャッシュスロット確保処理とは、キャッシュデータベースに新たなデータをキャッシュするための領域が不足している場合に、該データをキャッシュするための空き領域を作成するための処理である。最初に新しいデータをキャッシュするために必要な領域のサイズを計算し、現在キャッシュ中にあるデータのうち、キャッシュから削除するデータ(以下、書き戻し対象データと呼ぶ)を決定する(ステップ802)。該決定は、図2の格納データ管理テーブル223を用いてキャッシュ管理部208が行う。図5の格納データ管理テーブルの具体例を用いて、書き戻し対象データの決定方法を説明する。前記格納データ管理テーブルには、リフレッシュポリシー(507)のエントリが存在する。書き戻し対象データの決定は、該エントリのポリシーに従って実行する。例えば、テーブルc_addressのキャッシュデータ中から1つのレコードを削除したい場合、該テーブルのリフレッシュポリシーはLRUであるので、キャッシュ中のデータのうち、最も参照された日時が古いものを削除対象として選択する。
書き戻し対象データを決定した後、該書き戻し対象データに関するエントリが前記キャッシュデータベースログ中に存在するか否かをチェックする(ステップ803)。キャッシュデータベースログ中にエントリが存在するということは、該書き戻し対象データがキャッシュ上で更新されていることを示しており、該書き戻し対象データをキャッシュデータベースから削除する際には、該変更をデータベースサーバに反映する必要がある。よって、キャッシュデータベースログ中にエントリが存在する場合(ステップ803でYesが選択された場合)には、該書き戻し対象データおよび該データに関するキャッシュデータベースログをデータベースサーバにコミットする(ステップ804)。書き戻し対象データの変更の有無をキャッシュデータベースログの解析により判定するコストを削減するためには、レコードの更新の有無を判定するビットマップを準備し、ビットマップのチェックで更新を確認した場合のみキャッシュデータベースログを解析する実現例が考えられる。
図8に戻り、前記コミットが成功した場合(ステップ805でYesが選択された場合)には、キャッシュデータベースから書き戻し対象データを削除し(ステップ806)、キャッシュスロット確保処理を終了する(ステップ807)。データベースサーバへのコミットが失敗した場合(ステップ805でNoが選択された場合)には、書き戻し対象として他のデータを選択してリトライするか否かを選択する(ステップ808)。リトライする場合(ステップ808でYesが選択された場合)にはステップ802に戻り、前述の処理を繰り返す。リトライしない場合(ステップ808でNoが選択された場合)には、キャッシュスロット確保処理をアボートする(ステップ809)。
再び図4のキャッシュデータベースサーバでの問合せ処理のステップ402に戻って、キャッシュデータベース内にデータが存在しない場合(ステップ402でNoが選択された場合)には、データベースサーバ向けに問合せを変換(ステップ413)、転送し(ステップ409)、該問合せに対する結果を取得して(ステップ410)、アプリケーションに該取得した値を返す(ステップ411)。前記問合せ変換、および転送処理はそれぞれ、図2の問合せ変換部204および問合せ発行部205、ネットワークインタフェース部202で実行される。ステップ413のサーバ向けの問合せ変換に関して、図5の格納データ管理テーブルを用いて具体例を説明する。キャッシュデータベース1に対してアプリケーションから、図18の1801に示す問合せが発行された場合を考える。該問合せは顧客ID(c_id)が60000の顧客の氏名(c_name)を求めることに相当する。図5の1行目のレコードのキャッシュ済みデータ条件(507)が示す通り、該顧客氏名はキャッシュデータベース中にはなく、データベースサーバへの転送が必要となる。データベースサーバ114では、前記キャッシュデータベースサーバから転送された問合せをネットワークインタフェース部で受け付け、データ管理・検査部218がデータベース118を検索し、格納されている元データ221から問合せの条件を満足するレコードを取り出し、キャッシュデータベースサーバに返す。
しかしながら、問合せ1801をそのままデータベースサーバに転送して結果を取得すると、取得結果はc_nameのみを含むことになり、図5のキャッシュしているテーブルおよび属性名を示す「テーブル名および属性名」のエントリ(504)のエントリとして必要な他の3つの属性(c_id,c_address,c_phone)の値を含まず、そのままではキャッシングが不可能である。そこで、問合せ1801はデータベースサーバに転送される前に、1802に示すようにキャッシングに必要な他の属性も含む形に変換される。
問合せ処理は、該変換後の問合せによって取得したレコードを用いて、キャッシュデータベースリフレッシュ処理を実行して(ステップ412)、終了する(ステップ406)。該リフレッシュ処理とは、問合せ処理の結果取得したレコードを必要に応じてキャッシュデータベースに反映する処理である。該キャッシュデータベースリフレッシュ処理を図6のフローチャートを用いて説明する。最初にキャッシュデータベース内に新たにデータベースサーバより取得したデータを格納するための空き領域が存在するか否かをチェックする(ステップ602)。空き領域がある場合(ステップ602でYesが選択された場合)には、該空き領域にデータをキャッシュし(ステップ606)、キャッシュデータベースリフレッシュ処理を終了する(ステップ607)。キャッシュデータベース内に空き領域が存在しない場合(ステップ602でNoが選択された場合)には、新たにデータベースサーバより取得したデータと、キャッシュ中に存在するデータに対して前記リフレッシュポリシーに従った置き換え可否判定を行う(ステップ603)。該リフレッシュポリシーとは、図5の格納データ管理テーブルの508に示すように、キャッシュの置き換えポリシーを指定する項目であり、(1)使用された日時が最も古いデータを置き換え対象とするLRU、(2)キャッシュ中の利用頻度の小さいデータを置き換える利用頻度、(3)そしてキャッシュ中のデータにユーザ指定の優先度を付与し置き換え対象を決定する優先度指定、そして(4)データベースサーバの書き戻しが必要ないデータを置き換え対象とする書き戻し削減などがその例である。該リフレッシュポリシーに従って置き換え可否判定を行った結果、データベースサーバから取得したデータでキャッシュデータを置き換える場合(ステップ604でYesが選択された場合)には、前記キャッシュスロット確保処理(ステップ605)を実行し、空き領域にデータをキャッシュして(ステップ606)、キャッシュデータベースリフレッシュ処理を終了する(ステップ607)。リフレッシュポリシーに従って置き換え可否判定を行った結果、データベースサーバから取得したデータでキャッシュデータを置き換えないと判定された場合(ステップ604でNoが選択された場合)には、キャッシュの置き換えを行うことなくキャッシュデータベースリフレッシュ処理を終了する(ステップ607)。
以上で、キャッシュデータベースクラスタを用いた問合せ処理方法の説明を終了する。なお、本実現例では問合せをキャッシュされたデータで処理するか否かの判定を、図5のキャッシュ済みデータ条件(507)に基づいて行った。しかしながら、アプリケーションの種類によっては、前記キャッシュ済みデータ条件(507)のかわりにキャッシュ対象データ条件(506)を用いて判定を行い、実際にキャッシュデータベースに検索を行って値が取得できない場合に、改めてデータベースサーバに問合せを発行するという実施形態も可能である。本実施形態では、キャッシュ済みデータ条件のメンテナンスコストを削減できるというメリットがある。
次は、データベースサーバ側でのトランザクション処理方法を図9のフローチャートを用いて説明する。該トランザクション処理は図2に示すデータベースサーバ114のトランザクション管理部217が同図のキャッシュデータベース管理部216が保持するキャッシュデータベース管理テーブル219の情報を用いて実行する。該キャッシュデータベース管理テーブルの具体例を図10に示す。キャッシュデータベース管理テーブル219はキャッシュデータベースサーバ名(1002)、データベースサーバ内データベース名(1003)、テーブル名および属性名(1004)、分割キー(1005)、キャッシュ対象データ条件(1006)、キャッシュ済みデータ条件(1007)、更新可否(1008)、および稼動状態(1009)を含む。該テーブルの1行目のレコードを用いてその意味を説明する。該レコードは、データベースサーバ中のデータベースCustomerに含まれるテーブルc_addressのc_idが1<=c_id<100000の条件を満たすレコードの属性c_id,c_name,c_address,c_phoneをキャッシュデータベースサーバ1中のキャッシュデータベース1にキャッシュすること,そして実際には現在1<=c_id<50000を満たす前記のレコードがキャッシュされており,キャッシュデータベースは稼動中であること、そしてキャッシュでの更新が可であることを表している。なお、前記キャッシュ済みデータ条件に関しては、図10の#1および#2のレコードが示すようにその範囲を指定しても、もしくは#3のようにキャッシュ済みレコードのIDを保持するビットマップを指定してもよい。さらに、該キャッシュ済みデータ条件に関しては、データベースサーバ側でキャッシュ済みレコードを記録せず、そのエントリを空(NULL)としておくことも可能である。この場合、本発明ではキャッシュ済みデータ条件に関する判定処理をキャッシュ対象データ条件で置き換えて行う。これにより、データベースサーバ側ではキャッシュデータベース側で実際にキャッシングを行っているデータよりも多くのデータがキャッシュデータベース側に存在すると認識することとなり、トランザクション処理が実行できる場合が少なくなるが、キャッシュデータベース側のキャッシュが更新される毎に該キャッシュデータベース管理テーブルを更新する必要がなくなるというメリットがある。
図9に戻って、キャッシュデータベース管理テーブルから、トランザクションで参照するデータの範囲と該テーブルの"キャッシュ済みデータ条件"(該エントリがNULLの場合には"キャッシュ対象データ条件"を用いる)に重なりのあるレコードを抽出する(ステップ902)。例えば、キャッシュ管理テーブルが図10に示す通りであるとし、データベースサーバのトランザクションが、「顧客IDが10の顧客の電話番号を変更する」であったとする。この時、該トランザクションはc_addressテーブルのc_id=10のレコードを参照、更新する。この場合、該トランザクションと重なりのあるキャッシュデータベースサーバはキャッシュデータベースサーバ1となる。
次にステップ903でステップ902の結果抽出されたレコードをチェックする。抽出レコードが1つもない場合(ステップ903でYesが選択された場合)には、サーバのトランザクションで参照もしくは更新しようとするテーブルのキャッシュがどのキャッシュデータベースにも存在しないため、トランザクション処理を実行し(ステップ906)、終了する(ステップ907)。ステップ902の結果抽出されたレコードが存在する場合(ステップ903でNoが選択された場合)、トランザクションが参照処理のみを含むか否か(ステップ904)および抽出レコードの更新可否欄に1つでもYesが存在するか否か(ステップ905)をチェックする。トランザクションが参照処理のみをふくみ、かつ抽出レコードの更新可否欄が全てNoの場合(ステップ904でYes、ステップ905でNoが選択された場合)には、トランザクションが参照するデータはキャッシュデータベース側でも更新されていないことが保証されるため、トランザクションを実行し(ステップ906)、処理を終了する(ステップ907)。
トランザクションが更新処理を含む場合、もしくは抽出レコードの更新可否欄にYesが含まれる場合(ステップ904でNoが選択されるか、もしくはステップ904とステップ905の両方でYesが選択された場合)には、キャッシュデータベース上にキャッシュしているデータをデータベースサーバ上で更新してしまう、もしくはキャッシュデータベースサーバ上での更新をデータベースサーバ上で無視してしまうという不整合が発生するため、これを避けるために抽出レコードの"キャッシュデータベース名"に含まれる前キャッシュデータベースの同期・閉塞処理を実行し(ステップ908)、該同期・閉塞処理が成功した場合(ステップ909でYesが選択された場合)には、トランザクションを実行し(ステップ906)、処理を終了する(ステップ907)。該同期・閉塞処理が失敗した場合(ステップ909でNoが選択された場合)には、トランザクションをアボートする(ステップ910)。
前記キャッシュデータベースの同期・閉塞処理を図11のフローチャートを用いて説明する。ここではi番目のキャッシュデータベースiでのデータベースサーバjに関する同期・閉塞処理を説明する。但し、図11のフローチャートではスペースの都合で、「データベースjに関する」という文は省略している。最初にキャッシュデータベースiで、データベースサーバj中のキャッシュデータにアクセスするトランザクション(以下ではデータベースサーバjに関するトランザクションと呼ぶ)の受付を停止する(ステップ1102)。データベースサーバjに関する全てのトランザクションが終了した後(ステップ1103でYesが選択された場合)、キャッシュデータベース内の格納データ管理テーブル中の"データベースサーバ名"がデータベースサーバjで、かつその"更新可否"欄に少なくとも1つYesが存在するか否かをチェックする。Yesが1つも存在しない場合(ステップ1104でNoが選択された場合)には、キャッシュデータベースiではデータベースサーバjに関する更新処理が行われないため、データベースサーバjに関するキャッシュデータベース中のデータを削除して(ステップ1107)、同期・閉塞処理を終了する(ステップ1108)。前記"更新可否"エントリ欄に少なくとも1つYesが存在する場合(ステップ1104でYesが選択された場合)、該"更新可否"エントリ欄がYesの全テーブルに関して、キャッシュデータベース上での更新をデータベースサーバjに反映する。該反映処理は、更新後のデータイメージだけでなく、更新履歴であるキャッシュデータベースログに関しても行う(ステップ1105)。該反映処理が成功した場合(ステップ1106でYesが選択された場合)、キャッシュデータベース中のデータベースサーバjに関するデータを削除して(ステップ1107)、同期・閉塞処理を終了する(ステップ1108)。前記反映処理が失敗した場合(ステップ1106でNoが選択された場合)には、同期・閉塞処理はアボートする(ステップ1109)。なお、本実施形態ではデータベースサーバjに関するトランザクションのみを停止したが、トランザクションを選択的に停止できない場合には、キャッシュデータベースiで全てのトランザクションを停止せざるを得ない。この場合にはデータベースサーバj以外のキャッシュデータを一時的に利用できなくなるという制限が発生するが、本発明が適用可能であることはいうまでもない。
以上で、データベースサーバでのトランザクション処理方法の説明を終了する。最後に、キャッシュデータベース追加処理方法を説明する。
キャッシュデータベースクラスタに新たなサーバを追加する場合、図13に示す通り、サーバをクラスタに追加し(1302)、キャッシュデータベース再編成処理を実行すればよい(1303)。
該キャッシュデータベース再編成処理を図12のフローチャートを用いて説明する。最初に全キャッシュデータベースに対し、同期・閉塞処理を実行する(ステップ1206)。該同期・閉塞処理が失敗した場合(ステップ1202でNoが選択された場合)、キャッシュデータベース再編成処理はアボートする(ステップ1205)。前記同期・閉塞処理が成功した場合(ステップ1202でYesが選択された場合)には、キャッシュデータベース管理テーブルおよびアプリケーション−キャッシュデータベースマッピングテーブルを再構成し(ステップ1203およびステップ1207)、キャッシュデータベース再編成処理を終了する(ステップ1204)。
【0006】
【発明の効果】
本発明を用いることにより、アプリケーションサーバのクラスタ化、および更新が可能なキャッシュデータベースクラスタの構成が可能となり、スケーラビリティの高いWebシステムが実現できる。さらに、高多重のSMPサーバではなく、安価なクラスタサーバを用いてシステム構築が可能となり、システムのコストパフォーマンスが向上する。
【図面の簡単な説明】
【図1】本発明におけるアプリケーションサーバのクラスタ化、キャッシュデータベースクラスタを備えたWebシステムの構成を示す図。
【図2】データベースサーバとキャッシュデータベースサーバの構成を示す図。
【図3】従来方式での標準的なWebシステムの構成を示す図。
【図4】キャッシュデータベースサーバでの問合せ処理ステップを示すフローチャート。
【図5】キャッシュデータベースサーバの格納データ管理テーブルの例を示す図。
【図6】キャッシュデータベースのリフレッシュ処理ステップを示すフローチャート。
【図7】キャッシュデータベースの更新処理ステップを示すフローチャート。
【図8】キャッシュデータベースのキャッシュスロット確保処理ステップを示すフローチャート。
【図9】データベースサーバでのトランザクションステップを示すフローチャート。
【図10】データベースサーバのキャッシュデータベース管理テーブルの例を示す図。
【図11】キャッシュデータベースの同期・閉塞処理ステップを示すフローチャート。
【図12】キャッシュデータベースの再編成処理ステップを示すフローチャート。
【図13】キャッシュデータベースの追加処理ステップを示すフローチャート。
【図14】アプリケーションのセッション状態保存処理ステップを示すフローチャート。
【図15】アプリケーションのセッション継続処理ステップを示すフローチャート。
【図16】キャッシュデータベースサーバのセッション管理テーブルの例を示す図。
【図17】アプリケーションサーバのアプリケーション−キャッシュデータベースマッピングテーブルの例を示す図。
【図18】サーバ向け問合せ変換の例を示す図。
【符号の説明】
121,122…アプリケーション−キャッシュデータベースマッピングテーブル,
210…キャッシュ済みデータ,
211…キャッシュデータベースログ,
219…キャッシュデータベース管理テーブル,
221…データベースサーバ中の元データ,
222…セッション管理テーブル,
223…格納データ管理テーブル。
Claims (6)
- クライアント計算機システムからの要求を受け付け、自システム内もしくは他の計算機システムに処理を転送して結果を取得し、該結果を前記クライアントに対する結果として返すWebサーバ計算機システム(以下,Webサーバ)とネットワークで接続され、該Webサーバから転送された要求を処理するアプリケーションを実行する、少なくとも1個のアプリケーションサーバ計算機システム(以下、アプリケーションサーバ)と、
該アプリケーションサーバとネットワークで接続され、前記アプリケーションが処理に必要とするデータを管理し、該アプリケーションからの要求に従って、データを参照・更新するデータベースを含む少なくとも1個のデータベースサーバ計算機(以下、データベースサーバ)と、
前記アプリケーションサーバと前記データベースサーバにネットワークで接続され、該データベースサーバのデータの一部をキャッシュし、該アプリケーションサーバからの該データベースサーバへの要求のうち、自システムで処理可能な要求を処理し、処理が不可能な要求はデータベースサーバに転送するキャッシュデータベースを備える少なくとも1個のキャッシュデータベースサーバ計算機(以下、キャッシュデータベースサーバ)を含み、
前記キャッシュデータベースサーバは、
前記キャッシュデータベース上でのデータの更新の可否を指定するカラムを有するデータ管理テーブルと、
前記データ管理テーブルの前記カラムの指定値に応じてキャッシュデータベース上でのデータの更新可否を決定する機構とを有することを特徴とするWebシステム。 - 前記データ管理テーブルは前記キャッシュデータベースに実際にキャッシュされているデータを特定する第1の条件を格納し、
前記キャッシュデータベースサーバは、前記キャッシュデータベースサーバは、前記実際にキャッシュされているデータを特定する第1の条件と、アプリケーションから転送された問合せ中の第2の条件を比較し、第1の条件が第2の条件を包含する場合には、前記問合せをキャッシュデータベース中のデータを用いて処理するように書き換える問合せ変換部と、
該変換された問合せを前記キャッシュデータベースに対して発行する問合せ発行部と、
該発行された問合せを受け付け、キャッシュデータベース中のデータを検索・更新するデータ検索・更新部と、
前記第1の条件が前記第2の条件を包含しない場合には、前記アプリケーションから転送された問合せを、前記格納データ管理テーブル中に指定されているキャッシュするデータの形式で必要なデータを全て取得するように変換する問合せ変換部と、
該変換された問合せをデータベースサーバに対して発行する問合せ発行部と、
を有することを特徴とする請求項1に記載のWebシステム。 - 前記データベースサーバは、
(1)自データベースで管理するデータと、(2)該データをキャッシュするキャッシュデータベース名もしくは該キャッシュデータベースを識別するIDと、(3)該キャッシュデータベースでキャッシュされるデータの範囲を指定するキャッシュ対象データ条件と、(4)キャッシュ先のキャッシュデータベースでのキャッシュデータの更新可否と、(5)該キャッシュデータベースの稼動状況と、(6)キャッシュデータベースにキャッシュ済みのデータの範囲とを格納するキャッシュデータベース管理テーブル、および
該キャッシュデータベース管理テーブル中のデータに基づきトランザクション処理を行うトランザクション管理部、
を有することを特徴とする請求項1に記載のWebシステム。 - 前記トランザクション管理部は、
データベースサーバで実行すべきトランザクションが参照するデータの範囲を示す第1の条件と、前記キャッシュデータベース管理テーブル中のキャッシュ対象条件である第2の条件を比較し、
前記第1の条件と前記第2の条件に共通部分が存在しない場合、もしくはトランザクションが参照処理のみからなり、かつ前記第1の条件と共通部分を持つ前記第2の条件が含まれるテーブル中のレコードのキャッシュデータベースでの更新可否欄が全て更新否の場合には、キャッシュデータベースの同期・閉塞処理を行わずにトランザクションを実行し、
それ以外の場合には、前記第1の条件1と共通部分を持つ前記第2の条件が含まれるキャッシュデータベース管理テーブル中のキャッシュデータベース名に含まれる全てのキャッシュデータベースの同期・閉塞処理を行ってからトランザクションを実行することを特徴とする請求項3に記載のWebシステム。 - 少なくとも1個のアプリケーションサーバと、該アプリケーションサーバ上のアプリケーションが処理に必要とするデータを管理し、該アプリケーションからの要求に従ってデータを更新・参照するデータベースを含む少なくとも1個のデータベースサーバとに接続して用いられ、前記データベースのデータの一部をキャッシュするキャッシュデータベースを管理するキャッシュデータベースサーバで実行される問合せ処理方法であり、
前記キャッシュデータベースにキャッシュするデータ形式、および該キャッシュデータベースに実際にキャッシュされているデータを特定する第1の条件を格納データ管理テーブルに格納し、
前記アプリケーションサーバから転送された問合せ中の第2の条件を前記第1の条件と比較し、
前記第1の条件が前記第2の条件を包含する場合は、前記問合せを前記キャッシュデータベースのデータを用いて処理するうに変換し、かつ変換した問合せを前記キャッシュデータベースに発行し、
前記第1の条件が前記第2の条件を包含しない場合は、前記転送された問合せを、前記格納テーブル中に指定されているキャッシュするデータ形式で必要なデータを全て要求する問合せに変換し、
変換した問合せを前記データベースサーバに再転送することを特徴とするキャッシュデータベースサーバの問合せ処理方法。 - 請求項5に記載の問合せ処理方法において、前記キャッシュデータベースに発行する問合せの処理に伴う該キャッシュデータベースの更新処理の手順として、
更新処理実行のための十分な領域が前記キャッシュデータベース上に存在する場合には、キャッシュデータベースへの更新履歴をキャッシュデータベースログに記録して、キャッシュデータベース上でのみデータの更新を行い、
前記キャッシュデータベース上で空き領域が不足した場合には、必要な領域を確保するためにキャッシュ上から削除するデータを決定し、
該削除対象データがキャッシュ上で更新されていた場合のみ、該削除対象データの更新履歴をおよび更新データをサーバへコミットし、
該コミット処理が成功した場合に該削除対象データをキャッシュデータベースより削除し、
該削除対象データの削除処理によって生成された空き領域を利用して更新処理を実行する、
との手順を更に有することを特徴とするキャッシュデータベースの問合せ処理方法。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001192189A JP4306152B2 (ja) | 2001-06-26 | 2001-06-26 | クラスタ化したアプリケーションサーバおよびデータベース構造を持つWebシステム |
US10/075,263 US6820085B2 (en) | 2001-06-26 | 2002-02-15 | Web system having clustered application servers and clustered databases |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001192189A JP4306152B2 (ja) | 2001-06-26 | 2001-06-26 | クラスタ化したアプリケーションサーバおよびデータベース構造を持つWebシステム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2003006036A JP2003006036A (ja) | 2003-01-10 |
JP4306152B2 true JP4306152B2 (ja) | 2009-07-29 |
Family
ID=19030679
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2001192189A Expired - Fee Related JP4306152B2 (ja) | 2001-06-26 | 2001-06-26 | クラスタ化したアプリケーションサーバおよびデータベース構造を持つWebシステム |
Country Status (2)
Country | Link |
---|---|
US (1) | US6820085B2 (ja) |
JP (1) | JP4306152B2 (ja) |
Families Citing this family (84)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7188145B2 (en) | 2001-01-12 | 2007-03-06 | Epicrealm Licensing Llc | Method and system for dynamic distributed data caching |
US7035911B2 (en) | 2001-01-12 | 2006-04-25 | Epicrealm, Licensing Llc | Method and system for community data caching |
US8095687B1 (en) * | 2001-03-26 | 2012-01-10 | Microsoft Corporation | Systems and methods for managing state in a cluster of servers |
US6981029B1 (en) | 2001-07-17 | 2005-12-27 | Cisco Technology, Inc. | System and method for processing a request for information in a network |
US7200720B1 (en) * | 2001-12-28 | 2007-04-03 | Oracle International Corporation | System and method for efficiently performing memory intensive computations including a bidirectional synchronization mechanism for maintaining consistency of data |
US7444410B1 (en) * | 2002-02-15 | 2008-10-28 | Oracle International Corporation | Application platform execution environment |
GB2389431A (en) * | 2002-06-07 | 2003-12-10 | Hewlett Packard Co | An arrangement for delivering resources over a network in which a demand director server is aware of the content of resource servers |
US6941310B2 (en) * | 2002-07-17 | 2005-09-06 | Oracle International Corp. | System and method for caching data for a mobile application |
US6826661B2 (en) * | 2002-08-30 | 2004-11-30 | Veritas Operating Corporation | Methods and systems for storage architectures |
US8527636B2 (en) * | 2002-12-02 | 2013-09-03 | Sap Aktiengesellschaft | Session-return enabling stateful web applications |
US20040215747A1 (en) * | 2003-04-11 | 2004-10-28 | Jonathan Maron | System and method for a configuration repository |
US7089235B2 (en) * | 2003-04-17 | 2006-08-08 | International Business Machines Corporation | Method for restricting queryable data in an abstract database |
US7398359B1 (en) * | 2003-04-30 | 2008-07-08 | Silicon Graphics, Inc. | System and method for performing memory operations in a computing system |
US7664847B2 (en) | 2003-08-14 | 2010-02-16 | Oracle International Corporation | Managing workload by service |
US7747717B2 (en) * | 2003-08-14 | 2010-06-29 | Oracle International Corporation | Fast application notification in a clustered computing system |
US20060064400A1 (en) | 2004-09-21 | 2006-03-23 | Oracle International Corporation, A California Corporation | Methods, systems and software for identifying and managing database work |
US7290015B1 (en) | 2003-10-02 | 2007-10-30 | Progress Software Corporation | High availability via data services |
US8244880B2 (en) | 2003-10-22 | 2012-08-14 | International Business Machines Corporation | Connection management method, system, and program product |
EP1683032A4 (en) * | 2003-10-22 | 2010-03-03 | Ibm | METHOD, SYSTEM, AND PROGRAM PRODUCT FOR CONNECTION MANAGEMENT |
US8095658B2 (en) * | 2004-05-07 | 2012-01-10 | International Business Machines Corporation | Method and system for externalizing session management using a reverse proxy server |
JP4495783B2 (ja) * | 2004-06-25 | 2010-07-07 | 株式会社野村総合研究所 | データベース利用システム |
US8676922B1 (en) | 2004-06-30 | 2014-03-18 | Google Inc. | Automatic proxy setting modification |
US8224964B1 (en) | 2004-06-30 | 2012-07-17 | Google Inc. | System and method of accessing a document efficiently through multi-tier web caching |
US7437364B1 (en) * | 2004-06-30 | 2008-10-14 | Google Inc. | System and method of accessing a document efficiently through multi-tier web caching |
US7328222B2 (en) * | 2004-08-26 | 2008-02-05 | Oracle International Corporation | Method and apparatus for preserving data coherency in a database by generating a command object that includes instructions for writing a data record to a local cache |
JP2006163596A (ja) * | 2004-12-03 | 2006-06-22 | Internatl Business Mach Corp <Ibm> | 情報処理システム、制御方法、及びプログラム |
US20060155759A1 (en) * | 2004-12-29 | 2006-07-13 | Yahoo! Inc. | Scalable cache layer for accessing blog content |
JP4615344B2 (ja) * | 2005-03-24 | 2011-01-19 | 株式会社日立製作所 | データ処理システム及びデータベースの管理方法 |
US20060230263A1 (en) * | 2005-04-12 | 2006-10-12 | International Business Machines Corporation | Method and apparatus to guarantee configuration settings in remote data processing systems |
US7454408B2 (en) * | 2005-06-10 | 2008-11-18 | Microsoft Corporation | System and method for optimized distributed file transfer |
US8924441B2 (en) * | 2005-09-06 | 2014-12-30 | Teradata Us, Inc. | Method of performing snap imaging using data temperature for making anticipatory copies |
US7512707B1 (en) * | 2005-11-03 | 2009-03-31 | Adobe Systems Incorporated | Load balancing of server clusters |
US7747627B1 (en) * | 2005-12-09 | 2010-06-29 | Cisco Technology, Inc. | Method and system for file retrieval using image virtual file system |
US20070150600A1 (en) * | 2005-12-22 | 2007-06-28 | International Business Machines Corporation | Method and apparatus for collecting data for characterizing HTTP session workloads |
US8209305B2 (en) * | 2006-04-19 | 2012-06-26 | Microsoft Corporation | Incremental update scheme for hyperlink database |
US8392366B2 (en) | 2006-08-29 | 2013-03-05 | Microsoft Corporation | Changing number of machines running distributed hyperlink database |
US8627402B2 (en) | 2006-09-19 | 2014-01-07 | The Invention Science Fund I, Llc | Evaluation systems and methods for coordinating software agents |
US20080068381A1 (en) * | 2006-09-19 | 2008-03-20 | Searete Llc, A Limited Liability Corporation Of The State Of Delaware | Using network access port linkages for data structure update decisions |
US7797412B2 (en) * | 2006-10-25 | 2010-09-14 | Oracle America Inc. | Method and system for managing server configuration data |
JP4763587B2 (ja) * | 2006-12-11 | 2011-08-31 | 株式会社ソニー・コンピュータエンタテインメント | キャッシュサーバ、キャッシュサーバの制御方法、プログラム及び情報記憶媒体 |
US8812651B1 (en) | 2007-02-15 | 2014-08-19 | Google Inc. | Systems and methods for client cache awareness |
US8332497B1 (en) * | 2007-02-20 | 2012-12-11 | Netapp, Inc. | Generic resynchronization between persistent management store and dynamic configuration |
US8713186B2 (en) * | 2007-03-13 | 2014-04-29 | Oracle International Corporation | Server-side connection resource pooling |
ATE501484T1 (de) * | 2007-05-07 | 2011-03-15 | Software Ag | Verfahren und server zur synchronisierung einer vielzahl von auf eine datenbank zugreifenden clients |
JP2008287660A (ja) * | 2007-05-21 | 2008-11-27 | Hitachi Ltd | キャッシュサーバ、キャッシュ管理方法、およびキャッシュ管理プログラム |
US8468977B2 (en) * | 2007-08-07 | 2013-06-25 | The Kong Company, Llc | Pet toy with noise making instrument |
US8150970B1 (en) | 2007-10-12 | 2012-04-03 | Adobe Systems Incorporated | Work load distribution among server processes |
US10354255B2 (en) * | 2008-01-09 | 2019-07-16 | Microsoft Technology Licensing, Llc | Client access license tracking mechanism |
US8229969B1 (en) | 2008-03-04 | 2012-07-24 | Open Invention Network Llc | Maintaining web session data spanning multiple application servers in a session database |
US8412542B2 (en) * | 2008-04-25 | 2013-04-02 | Peoplechart Corporation | Scoring system for monitoring or measuring adherence in medical treatment |
JP5483561B2 (ja) * | 2010-02-25 | 2014-05-07 | 楽天株式会社 | ストレージ装置、サーバ装置、ストレージシステム、データベース装置、データの提供方法、及び、プログラム |
CN101895550B (zh) * | 2010-07-16 | 2012-12-26 | 刘季伟 | 一种应用于互联网网站的兼容动静态内容的缓冲加速方法 |
US8424093B2 (en) | 2010-11-01 | 2013-04-16 | Kaspersky Lab Zao | System and method for updating antivirus cache |
US7962959B1 (en) | 2010-12-01 | 2011-06-14 | Kaspersky Lab Zao | Computer resource optimization during malware detection using antivirus cache |
US8977599B2 (en) * | 2010-11-11 | 2015-03-10 | Verizon Patent And Licensing Inc. | Method and system for testing client-server applications |
EP2453368B1 (en) * | 2010-11-12 | 2017-05-31 | Accenture Global Services Limited | Custom web services data link layer |
US8832111B2 (en) * | 2010-12-30 | 2014-09-09 | Facebook, Inc. | Distributed cache for graph data |
US10853306B2 (en) | 2011-08-02 | 2020-12-01 | Ajay JADHAV | Cloud-based distributed persistence and cache data model |
US10936591B2 (en) | 2012-05-15 | 2021-03-02 | Microsoft Technology Licensing, Llc | Idempotent command execution |
US10776383B2 (en) * | 2012-05-31 | 2020-09-15 | International Business Machines Corporation | Automatic replication of ambiguous data based on a point system |
US8965921B2 (en) * | 2012-06-06 | 2015-02-24 | Rackspace Us, Inc. | Data management and indexing across a distributed database |
US9239868B2 (en) | 2012-06-19 | 2016-01-19 | Microsoft Technology Licensing, Llc | Virtual session management and reestablishment |
US9251194B2 (en) | 2012-07-26 | 2016-02-02 | Microsoft Technology Licensing, Llc | Automatic data request recovery after session failure |
US8898109B2 (en) | 2012-07-27 | 2014-11-25 | Microsoft Corporation | Automatic transaction retry after session failure |
US9235464B2 (en) | 2012-10-16 | 2016-01-12 | Microsoft Technology Licensing, Llc | Smart error recovery for database applications |
TWI505682B (zh) | 2012-11-01 | 2015-10-21 | Ind Tech Res Inst | 一種具高度適應性交談管理機制之遠端管理系統 |
US20140244800A1 (en) * | 2013-02-28 | 2014-08-28 | Sitecore A/S | Method for collecting online analytics data using server clusters |
US10044799B2 (en) * | 2013-05-28 | 2018-08-07 | International Business Machines Corporation | Implementing synchronization of state information betweeen instances of an application as well as between different applications in an efficient, scalable manner |
US9854035B2 (en) | 2013-05-28 | 2017-12-26 | International Business Machines Corporation | Maintaining state synchronization of an application between computing devices as well as maintaining state synchronization of common information between different applications without requiring periodic synchronization |
WO2014192213A1 (ja) * | 2013-05-31 | 2014-12-04 | 日本電気株式会社 | 分散処理システム |
US9632803B2 (en) | 2013-12-05 | 2017-04-25 | Red Hat, Inc. | Managing configuration states in an application server |
US9183148B2 (en) * | 2013-12-12 | 2015-11-10 | International Business Machines Corporation | Efficient distributed cache consistency |
US20160125029A1 (en) * | 2014-10-31 | 2016-05-05 | InsightSoftware.com International | Intelligent caching for enterprise resource planning reporting |
US10313256B2 (en) * | 2015-05-21 | 2019-06-04 | Intel Corporation | Apparatus and methods for adaptive data compression |
US10474653B2 (en) | 2016-09-30 | 2019-11-12 | Oracle International Corporation | Flexible in-memory column store placement |
CN106407452A (zh) * | 2016-09-30 | 2017-02-15 | 郑州云海信息技术有限公司 | 一种访问服务端数据的方法及装置 |
CN107832401B (zh) * | 2017-11-01 | 2021-07-16 | 郑州云海信息技术有限公司 | 数据库数据访问方法、系统、装置及计算机可读存储介质 |
CN110109953B (zh) | 2018-01-19 | 2023-12-19 | 阿里巴巴集团控股有限公司 | 一种数据查询方法、装置及设备 |
US10805421B2 (en) * | 2018-04-03 | 2020-10-13 | Citrix Systems, Inc. | Data caching for cloud services |
US11914590B1 (en) * | 2018-10-31 | 2024-02-27 | Amazon Technologies, Inc. | Database request router improving server cache utilization |
CN109656956B (zh) * | 2018-12-14 | 2023-06-09 | 浪潮软件集团有限公司 | 一种实现业务系统数据集中式缓存的方法及装置 |
CN110473540B (zh) * | 2019-08-29 | 2022-05-31 | 京东方科技集团股份有限公司 | 语音交互方法及系统、终端设备、计算机设备及介质 |
FR3110723B1 (fr) * | 2020-05-21 | 2022-05-13 | Amadeus | Mise à jour de session de base de données asynchrone |
US11429585B2 (en) * | 2020-12-01 | 2022-08-30 | Walmart Apollo, Llc | Systems and methods for managing concurrent data requests |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH11149449A (ja) | 1997-11-18 | 1999-06-02 | Nec Corp | データベースセッション管理方法及びその装置と処理を記録した記録媒体 |
US6363387B1 (en) * | 1998-10-20 | 2002-03-26 | Sybase, Inc. | Database system providing methodology for enhancing concurrency using row update bit and deferred locking |
US6487547B1 (en) * | 1999-01-29 | 2002-11-26 | Oracle Corporation | Database appliance comprising hardware and software bundle configured for specific database applications |
US6738775B2 (en) * | 1999-11-30 | 2004-05-18 | Base One International Corp. | Database communication system and method for communicating with a database |
US6571259B1 (en) * | 2000-09-26 | 2003-05-27 | Emc Corporation | Preallocation of file system cache blocks in a data storage system |
-
2001
- 2001-06-26 JP JP2001192189A patent/JP4306152B2/ja not_active Expired - Fee Related
-
2002
- 2002-02-15 US US10/075,263 patent/US6820085B2/en not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
JP2003006036A (ja) | 2003-01-10 |
US20020198883A1 (en) | 2002-12-26 |
US6820085B2 (en) | 2004-11-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4306152B2 (ja) | クラスタ化したアプリケーションサーバおよびデータベース構造を持つWebシステム | |
US10642840B1 (en) | Filtered hash table generation for performing hash joins | |
US9946735B2 (en) | Index structure navigation using page versions for read-only nodes | |
US10803047B2 (en) | Accessing data entities | |
US10838935B2 (en) | Automating the logging of table changes in a database | |
Amiri et al. | DBProxy: A dynamic data cache for Web applications | |
US7831772B2 (en) | System and methodology providing multiple heterogeneous buffer caches | |
US6564218B1 (en) | Method of checking the validity of a set of digital information, and a method and an apparatus for retrieving digital information from an information source | |
US9305056B1 (en) | Results cache invalidation | |
US6678700B1 (en) | System of and method for transparent management of data objects in containers across distributed heterogenous resources | |
KR101315330B1 (ko) | 대용량 데이터베이스와 인터페이스하기 위한 다 계층소프트웨어 시스템에서 캐쉬 콘텐츠의 일관성을 유지하는시스템 및 방법 | |
CA2491731C (en) | System and method for caching data for a mobile application | |
JPH10222407A (ja) | プロセスオーバーヘッド及びデータベースサーバからの冗長な検索を減少するように同じプロセスにおける多数のデータベーストランザクションを処理する方法 | |
JP2002542542A (ja) | 問合せ可能なダイナミック・キャッシュを有するウェブサーバ | |
EP0864129A1 (en) | Database access | |
US10990571B1 (en) | Online reordering of database table columns | |
US20040172459A1 (en) | Multi-tier business layer architecture for information systems | |
US11256695B1 (en) | Hybrid query execution engine using transaction and analytical engines | |
US11341163B1 (en) | Multi-level replication filtering for a distributed database | |
CN106557562A (zh) | 一种单机数据库数据的查询方法及装置 | |
Amiri et al. | A self-managing data cache for edge-of-network web applications | |
US7660785B1 (en) | Techniques for managing interactions between applications and a data store | |
Lv et al. | Research and Application on Distributed Multi-Level Cache Architecture | |
Nwe | Data Replication in Aircraft Components Database System using Distributed Database System | |
JPH0713840A (ja) | 並列データアクセスシステムにおける排他制御方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060320 |
|
RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20060418 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090106 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090309 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090414 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090427 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120515 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120515 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130515 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130515 Year of fee payment: 4 |
|
LAPS | Cancellation because of no payment of annual fees |