JP5661355B2 - 分散キャッシュシステム - Google Patents

Description

本発明は、データベースの内容を複数のサーバ上のキャッシュに展開してアクセス効率を向上させる分散キャッシュの技術に関し、特に、各キャッシュサーバに保持するデータがパーティション化された分散キャッシュシステムに適用して有効な技術に関するものである。

データベースに保持するデータ量が増加し続ける中、近年では、大量のデータを保存する手段としてキー・バリュー型データストアなども注目されている。これらのデータを大量に保持するデータベースに対してネットワークを介して多数のユーザからのアクセスが行われるようなシステムでは、データベースへのアクセスが集中してボトルネックとなることを回避するとともに、並列処理により検索の性能を向上させるため、分散データベースや分散キャッシュの仕組みが多用される。

分散キャッシュの基本的な仕組みとしては、クライアントからの要求に応じて各キャッシュサーバがデータベースから読み出したレコードをメモリのような記憶装置上にキャッシングする機能や、複数のキャッシュサーバ間での連携を管理する機能（キャッシュ間の整合の維持や、どのキャッシュにどのレコードが保持されているか等の管理）、キャッシュ内のレコードに加えられた変更をデータベースに書き戻す機能などがある。これらの仕組みは、主にデータベース管理ソフトウェアを製造販売するベンダー等から提供されるミドルウェアなどによって実現されている。

分散キャッシュシステムの構成としては、大きく分けて一般的に、複数のキャッシュサーバが同じ内容のデータを保持するキャッシュを有して可用性を向上させるレプリケーション型と、各キャッシュサーバがそれぞれ重複しない異なる内容のデータをキャッシュに保持して拡張性を向上させデータの大容量化に対応するパーティション型がある。ベンダー等から提供される分散キャッシュシステムを実現するミドルウェアでは、これらの構成を選択的に利用することができるものもある。

パーティション型の分散キャッシュシステムに係る技術としては、例えば、特開平１１−２２４２１９号公報（特許文献１）には、１台の分散制御装置によってｎ台のキャッシュ装置を制御する分散キャッシュ制御方法において、分散制御装置が、クライアントからの要求を受け取り、要求内に記載されている要求資源識別情報のハッシュ値を算出し、分散管理情報を用いて、ハッシュ値に対応したキャッシュ装置を選択し、選択されたキャッシュ装置へ要求を送信し、キャッシュ装置から受信した応答をクライアントに送信する技術が記載されている。

また例えば、特開２００２−２５１３１３号公報（特許文献２）には、１つ以上のキャッシュサーバが夫々保持しているデータの情報を格納すると共に、データ照会要求に係るデータを格納しているキャッシュサーバを検索する親キャッシュサーバと、外部ネットワークからのデータを格納すると共に、そのデータの情報を前記親キャッシュサーバに送信する１以上の子キャッシュサーバとを有し、内部ネットワークからのデータ取得要求に係るデータを有している子キャッシュサーバがあれば、その子キャッシュサーバから前記データ取得要求に係るデータを取得する一方、データ取得要求に係るデータを有している子キャッシュサーバがなければ、外部ネットワークからデータ取得要求に係るデータを取得する分散キャッシュサーバシステムが記載されている。

上記のような分散キャッシュシステムでは、一般的にクライアント等からのアクセスに対してデータベースから読み出したレコードをキャッシングするものであるため、必ずしも該当のレコードがキャッシュヒットするとは限らず、キャッシュミスする場合もある。ここで例えば、データベースに保持するデータが更新頻度が少ない静的な特性を有するものである場合などでは、あらかじめデータベースの全てのデータをキャッシュ上に展開しておくことが行われる。これによりキャッシュミスを排除し、アクセスの効率を大きく向上させることができる。

この場合、データベースのデータ量に比して十分な容量のキャッシュが必要となるため、分散キャッシュシステムの構成としてレプリケーション型を利用することはコスト上困難であり、通常はパーティション型が利用される。この場合、複数のキャッシュサーバ全体でのキャッシュの総容量がデータベースのデータ量に比して十分であればよい。

特開平１１−２２４２１９号公報 特開２００２−２５１３１３号公報

上述したようなパーティション型の分散キャッシュシステムにおいて、あらかじめデータベースの全てのデータを分散キャッシュに展開しておく構成をとる場合、従来は、各キャッシュサーバにデータベースから読み込むレコードの値の範囲（例えば“「あ行」のレコード”など）をそれぞれルールとして割り当てておき、そのルールに従って各キャッシュサーバがデータベースからレコードを読み込んでキャッシュ上に展開する方式がとられていた。

しかしながら、この方式では、データベースに保持するレコードの値の分布状況に応じて、各キャッシュサーバがデータベースから読み込むレコードの量、およびキャッシュに保持するデータ量に不均衡が生じる場合がある。すなわち、キャッシュサーバによってリソースの使用量に不均衡が生じる場合がある。また、各キャッシュサーバがデータベースから読み込んだレコードの配置を複数のキャッシュサーバ間で調整してデータ量を均一化するような構成をとる場合は、読み込んだレコードを他のキャッシュサーバに転送するための内部トラフィックが増えることになる。

また、レコードの値の範囲に基づく分散数（例えば「あ行」〜「わ行」で分散させる場合は１０）とキャッシュサーバの台数が一致しない場合（運用中にキャッシュサーバの台数が増減した場合なども含む）の処置を決定するのが複雑で困難となる。また、データベースに保持するデータの内容によってはレコードの値の範囲毎のデータ量の分布状況や傾向を設計時に把握することができず、どのような値の範囲で分散させれば効率的かを判断するのが困難な場合もある。

そこで本発明の目的は、データベースに保持する全てのデータを分散キャッシュ上に展開し、各キャッシュサーバに保持するデータがパーティション化された分散キャッシュシステムにおいて、データベースに保持するレコードの値の分布等に影響されずにリソースの使用量を平準化することができ、キャッシュサーバの台数の増減にも柔軟に対応可能で、内部トラフィックを低減させることができる分散キャッシュシステムを提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態による分散キャッシュシステムは、ネットワークに接続されたデータベースサーバと複数のキャッシュサーバとからなり、前記データベースサーバ上のデータベースに保持するデータの一部をそれぞれ重複せずに前記各キャッシュサーバ上のキャッシュに格納することで、前記各キャッシュサーバ全体として前記データベースに保持する全てのデータを前記キャッシュに展開するパーティション型の分散キャッシュシステムであって、以下の特徴を有するものである。

すなわち、分散キャッシュシステムにおいて、前記各キャッシュサーバ上の前記キャッシュ上には、データを保持するための論理的な領域である１つ以上のバケットが定義され、前記各バケットには、当該分散キャッシュシステム内でユニークなＩＤが割り振られており、前記データベースに保持するデータの各レコードには、それぞれ前記バケットのＩＤの範囲に属する値が分類番号として割り振られており、前記キャッシュサーバは、前記データベースから、自身の前記キャッシュ上に定義されている前記バケットのＩＤに一致する前記分類番号を有するレコードのみを読み込んで、対応する前記バケットに格納するロード部を有することを特徴とするものである。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

本発明の代表的な実施の形態によれば、データベースに保持する全てのデータを分散キャッシュ上に展開し、各キャッシュサーバに保持するデータがパーティション化された分散キャッシュシステムにおいて、データベースに保持するレコードの値の分布等に影響されずにリソースの使用量を平準化することができ、キャッシュサーバの台数の増減にも柔軟に対応可能で、分散キャッシュシステムの内部トラフィックを低減させることが可能となる。

本発明の一実施の形態における、キャッシュへのデータのロード方法の例について概要を示した図である。 本発明の一実施の形態である、分散キャッシュシステムの構成例について概要を示した図である。 本発明の一実施の形態における、データベースの更新内容をキャッシュに反映させる方法の例について概要を示した図である。 本発明の一実施の形態における、データベースにおけるデータの更新を効率的にキャッシュに反映させるためのキャッシュサーバの構成例について概要を示した図である。 本発明の一実施の形態における、フィード部および処理部の処理の例を示したフローチャートである。 従来の分散キャッシュシステムにおける、キャッシュへのデータのロード方法の例について概要を示した図である。 従来の分散キャッシュシステムにおける、キャッシュへのデータのロード方法の別の例について概要を示した図である。 従来の分散キャッシュシステムにおける、データベースの更新内容をキャッシュに反映させる方法の例について概要を示した図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。

本発明の一実施の形態である分散キャッシュシステムは、データベースに保持する全てのデータを分散キャッシュ上に展開し、各キャッシュサーバに保持するデータがパーティション化された分散キャッシュシステムである。各キャッシュサーバは、自身のキャッシュ内において定義された、レコードを保持するための論理的な領域（入れ物；本明細書において「バケット」と称する）の構成に応じて、自身が読み込むべきレコードのみをデータベースから読み込んでキャッシュに保持する。これにより、後述するように、データベースに保持するレコードの値の分布等に影響されずにリソースの使用量を平準化することができ、キャッシュサーバの台数の増減にも柔軟に対応可能で、内部トラフィックを低減させることが可能となる。

さらに本実施の形態では、処理効率をより向上させるなどの観点から、クライアント側からのレコード（キャッシュデータ）の変更を許可しないようにして、キャッシュ内のレコードを読み取り専用とする。一方、データベースに保持する元データは他のシステム等により更新される場合があるため、この更新を遅滞なくキャッシュ内のレコードに反映させるための仕組みも有する。

＜システム構成＞
図２は、本発明の一実施の形態である分散キャッシュシステムの構成例について概要を示した図である。分散キャッシュシステム１は、データベース（ＤＢ）サーバ１００と複数台のキャッシュサーバ２００とからなり、これらが図示しないネットワークによって相互に接続される構成を有する。本発明は、ネットワークとしてインターネットを介して相互に接続される外部ネットワークが用いられる場合にも適用可能であるが、以下、ネットワークとしてＬＡＮ（Local Area Network）等の内部ネットワークを用いる場合を例として説明する。

ＤＢサーバ１００は、コンピュータシステムによって構成されるサーバ機器であり、図示しないＯＳ（Operating System）やデータベース管理ソフトウェアを有してデータベース（ＤＢ）１１０を保持・管理する。ＤＢ１１０のデータは、他のシステムから、もしくは管理者等の手動により変更される。

キャッシュサーバ２００は、コンピュータシステムによって構成されるサーバ機器であり、例えば、メモリやハードディスクなどの記憶装置上に構成されるキャッシュ２１０、ソフトウェアプログラムによって実装されるロード部２２０、およびＯＳ（図示しない）や分散キャッシュ管理部２３０などのミドルウェアを有する。

キャッシュサーバ２００は複数台によって構成され（図２の例ではキャッシュサーバａ〜ｎ（２００ａ〜ｎ））、各キャッシュサーバ２００は、ＤＢ１１０のデータをそれぞれ重複せずにキャッシュ２１０に読み込むことで、全体としてパーティション型の分散キャッシュシステム１を実現する。すなわち、図示しないクライアント端末等からのＤＢサーバ１００へのアクセス要求を受け付けて、分散キャッシュ管理部２３０の機能により、該当のデータを保持するキャッシュサーバ２００のキャッシュ２１０からデータを効率よく取得してクライアント端末に応答する。

キャッシュ２１０は、ＤＢ１１０から読み込んだデータをキャッシュする記憶装置であり、キャッシュ２１０上にはさらにデータを分類して保持する論理的な領域（入れ物）であるバケット２１１を１つ以上有する（図２の例ではキャッシュサーバａ（２００ａ）はバケットａ〜ｃ（２１１ａ〜ｃ）を有する）。ロード部２２０は、対象のキャッシュサーバ２００が読み込むべきレコードのみをＤＢ１１０から読み込んで、該当するバケット２１１に格納することで、データをキャッシュ２１０（バケット２１１）にロードする。ロード部２２０によるデータのロード方法の詳細については後述する。

分散キャッシュ管理部２３０は、分散キャッシュの基本的な仕組みを提供する製品等のミドルウェアであり、例えば、どのキャッシュサーバ２００（キャッシュ２１０）にどのレコードが保持されているか等を管理し、クライアント端末からのアクセス要求を受けた際に、該当のレコードを保持するキャッシュサーバ２００を特定してレコードを取得したりなどの機能を有する。なお、このような機能を有する管理サーバ等の機器を別途有し、クライアント端末はまず当該管理サーバにアクセスして該当のレコードを保持するキャッシュサーバ２００を特定する構成とすることも可能である。

＜キャッシュへのデータのロード＞
以下では、分散キャッシュシステムにおけるデータベースから各キャッシュサーバ上のキャッシュへのデータのロード方法について説明する。なお、本明細書においては「ロード」とはデータを読み込みキャッシュに保持させることを意味するものとする。ここでは、本発明の特徴を分かり易くするために、従来の技術と比較して説明する。図６は、従来の分散キャッシュシステムにおける、キャッシュへのデータのロード方法の例について概要を示した図である。

図６の例では、ＤＢ１１０の内容をキャッシュサーバａ〜ｊ（２００ａ〜ｊ）の１０台で分担して読み込んでキャッシュ２１０にそれぞれ保持する場合を示している。従来は、各キャッシュサーバ２００に対して予めＤＢ１１０から読み込む値の範囲を割り当てておき、そのルールに従って該当のレコードを所定のタイミングで読み込んでいる。例えば、ＤＢ１１０上に顧客名のリストが保持されている場合、キャッシュサーバａ（２００ａ）は先頭が「あ」行のレコード、キャッシュサーバｂ（２００ｂ）は先頭が「か」行のレコード、…のように分担して該当するレコードを読み込んで、キャッシュ２１０に保持する。

この方法をとった場合、ＤＢ１１０に保持するレコードの値の分布状況に応じて、各キャッシュサーバ２００がＤＢ１１０から読み込むデータ量、およびキャッシュ２１０に保持するデータ量に不均衡が生じる場合がある（例えば、「か」行や「わ」行が割り当てられたキャッシュサーバｂ（２００ｂ）やキャッシュサーバｊ（２００ｊ）が読み込んで保持するデータ量が少ない等）。すなわち、キャッシュサーバ２００によってリソースの使用量に不均衡が生じる場合がある。

また、ＤＢ１１０のレコードの値の範囲に基づく分散数とキャッシュサーバ２００の台数が一致しない場合の処置を決定するのが複雑で困難となる。例えば、「さ」行が割り当てられていたキャッシュサーバｃ（２００ｃ）が障害によりダウンした場合、「さ」行のレコードをどのキャッシュサーバ２００が読み込んで保持するのかを決定して、割り当てのルールを再設定する必要があるが、整合性を確保するためには考慮しなければならない点が多く複雑である。

また、図６の例ではＤＢ１１０のレコードを「あ」行、「か」行、「さ」行、…「わ」行の１０分割にして、１０台のキャッシュサーバａ〜ｊ（２００ａ〜ｊ）に分散して保持しているが、キャッシュサーバ２００の台数が１１台以上ある場合（運用中にキャッシュサーバ２００を追加した場合なども含む）にはどのように分散させるかのルールを決定するのが困難である。

また、図６の例ではＤＢ１１０に顧客名のリストが保持されている場合であるが、例えば、顧客の趣味に関するデータが保持されているような場合、具体的にどのようなレコードが保持されるのかが不明である。従って、レコードの値の範囲毎のデータ量の分布状況や傾向を設計時に把握することができず、どのような値の範囲で分散させれば効率的かを判断するのが困難な場合もある。

図７は、従来の分散キャッシュシステムにおける、キャッシュへのデータのロード方法の別の例について概要を示した図である。図７の例では、図６の例と同様に、ＤＢ１１０の内容をキャッシュサーバａ〜ｊ（２００ａ〜ｊ）の１０台で分担して読み込んでキャッシュ２１０にそれぞれ保持する場合を示している。ここではさらに、各キャッシュサーバ２００がＤＢ１１０から読み込んだレコードの配置を他の複数のキャッシュサーバ２００間で調整してデータ量の均一化を可能とするような構成をとっている。

レコードの配置の均一化を可能とするため、各キャッシュサーバ２００は、例えば、キャッシュ２１０内に図２に示したものと同様な論理的な領域であるバケット２１１を１つ以上有する。各バケット２１１には、分散キャッシュシステム内でユニークなＩＤが割り振られており、ロード部２２０は、読み込んだレコードの値に応じて対応するバケット２１１にレコードを格納する。例えば、各バケット２１１には１から開始する整数からなる連番によりＩＤが割り振られており、ロード部２２０は、読み込んだレコードのキーのハッシュ値とバケット２１１の総数との剰余を算出し（値は必ず０〜バケット２１１の数−１の範囲となる）、その値＋１と同じＩＤのバケット２１１にレコードを格納する。該当のバケット２１１が他のキャッシュサーバ２００にあるときはレコードを転送して格納する。

この方法の場合、バケット２１１の所在場所をキャッシュサーバ２００間で移動させることにより、各キャッシュサーバ２００で保持するデータ量を均一化することが可能である。しかし、ロード部２２０がどのキャッシュサーバ２００にどのバケット２１１があるかという配置を把握しておく必要があり、バケット２１１を移動させることで当該情報も更新する必要があるなど、運用が煩雑となる。また、ロード部２２０が読み込んだレコードを他のキャッシュサーバ２００に転送するための内部トラフィックが増えることになる。

そこで上記のような課題を解消するため、本実施の形態では、キャッシュサーバ２００のロード部２２０が自身のキャッシュ２１０に保持すべきレコードのみをＤＢ１１０から読み込む構成をとる。図１は、本実施の形態の分散キャッシュシステム１における、キャッシュ２１０へのデータのロード方法の例について概要を示した図である。

図１の例では、図７の例と同様にレコードの配置の均一化を可能とするため、各キャッシュサーバ２００は、キャッシュ２１０内に、キャッシュサーバ２００全体としてＤＢ１１０の全データを保持するのに十分な数および容量となるバケット２１１を１つ以上有する。各バケット２１１には分散キャッシュシステム１内でユニークなＩＤが割り振られており、ロード部２２０は、読み込んだレコードの値に応じて対応するバケット２１１にレコードを格納する。ここでは例えば、１から開始する整数からなる連番によりＩＤが割り振られる。

このとき、ＤＢ１１０上の各レコードには、図示するように、バケット２１１のＩＤの範囲に属する値を分類番号１１１として割り振っておく。図１の例では、１〜バケット２１１のＩＤの範囲（バケット２１１の総数の範囲）の整数値を割り振る。具体的には例えば、各レコードのキーのハッシュ値とバケット２１１のＩＤの最大値（バケット２１１の総数）との剰余を算出し、これに１を加算した値を分類番号１１１として割り振るようにする。これにより、各レコードにバケット２１１のＩＤの値の範囲の整数値を割り振ることができる。

各キャッシュサーバ２００は、自身のキャッシュ２１０に有するバケット２１１のＩＤの値に一致する分類番号１１１を有するレコードのみを読み込んで、対応するＩＤのバケット２１１にレコードを格納する。例えば、キャッシュサーバａ（２００ａ）のロード部２２０は、キャッシュ２１０に有するバケット２１１のＩＤが“１”と“５”なので、ＤＢ１１０から分類番号１１１が“１”と“５”のレコードのみを読み込み、分類番号１１１が“１”のレコードはＩＤが“１”のバケット２１１に、分類番号１１１が“５”のレコードはＩＤが“５”のバケット２１１にそれぞれ格納する。

これにより、上述した図６や図７に示した構成における課題点を解消することができる。すなわち、各キャッシュサーバ２００が自身が読み込むべきレコードのみをＤＢ１１０から読み込むことになるため、読み込んだレコードをキャッシュ２１０に格納する際に他のキャッシュサーバ２００へのレコードの転送を行う必要がなく、内部トラフィックの増加を抑制することができる。また、例えばキャッシュサーバ２００の台数が増減した場合でも、バケット２１１の配置を各キャッシュサーバ２００間で調整するだけでよい。各キャッシュサーバ２００は、相変わらず自身が有するバケット２１１のＩＤに対応するレコードのみを読み込めばよく、対応は容易である。

また、個々のバケット２１１の大きさは均一である必要はないが、全体としてＤＢ１１０のデータを保持するのに十分な数のバケット２１１を用意し、キャッシュサーバ２００間で配置を調整することで、キャッシュサーバ２００におけるデータ量の配分を均一化することができる。各バケット２１１のサイズおよび格納されているデータ量についてはキャッシュサーバ２００が把握することができるため、データ量の配分が均一化されるような適切な配置を算出してバケット２１１の配置を変更する処理を自動で行うようにすることも可能である。

また、図１に示すような構成をとる場合、図６や図７に示した構成におけるような、各キャッシュサーバ２００がＤＢ１１０から読み込むレコードの分散数と、キャッシュサーバ２００の台数との不一致という状態は生じない。また、ＤＢ１１０内に保持するレコードの値の範囲や特性に関わらず、キーのハッシュ値とバケット２１１の総数との剰余をとることで、どのような値のレコードに対しても一定範囲の値を割り当てて分類することができる。

＜データベース更新のキャッシュへの反映＞
本実施の形態では、処理効率をより向上させるなどの観点から、クライアント側からのレコード（キャッシュデータ）の変更を許可しないようにして、キャッシュ２１０内のレコードを読み取り専用とする。その場合でも、ＤＢ１１０のデータが他のシステムから、もしくは管理者等の手動により変更される。

以下では、ＤＢ１１０に保持する元データが他のシステム等により更新された場合に、当該更新を遅滞なくキャッシュ２１０内のデータに反映させる方法について説明する。ここでは、本発明の特徴を分かり易くするために、従来の技術と比較して説明する。図８は、従来の分散キャッシュシステムにおける、データベースの更新内容をキャッシュに反映させる方法の例について概要を示した図である。

従来は、各キャッシュサーバ２００がＤＢ１１０内で更新されているレコードを把握可能とするため、例えば、図８に示すように、ＤＢ１１０内の各テーブルにレコードの更新時のタイムスタンプの情報を保持する更新日時１１２のカラムを追加していた。ここで各キャッシュサーバ２００は、所定の間隔で定期的にＤＢ１１０にアクセスして各テーブルの更新日時の情報をチェックし、前回のチェック時点以降に更新されたレコードを検出していた。

しかし、この手法ではどのテーブルにどれだけ更新されたレコードがあるかが不明なので、各キャッシュサーバ２００はＤＢ１１０の全てのレコードについて更新日時の情報をチェックする必要がある。従って、ＤＢ１１０内のテーブル数やレコード数が多い場合は当該チェック処理の負荷が高くなり、ＤＢ１１０のレコードの更新内容を遅滞なくキャッシュサーバ２００に反映させることが困難となる場合があった。そこで、本実施の形態では、ＤＢ１１０のレコードに対する更新内容を記録するためのテーブルを別途有する構成としている。図３は、本実施の形態における、データベースの更新内容をキャッシュに反映させる方法の例について概要を示した図である。

図３の例では、各テーブルに対する更新内容を記録するためのログテーブル１２０を有する。ログテーブル１２０に対しては、例えば、各テーブルのレコードが更新された際にデータベース管理ソフトウェアによって生成される更新トリガ等を利用して、ＤＢサーバ１００上の図示しないプログラム等により、図３に示すように更新内容（追加、削除、変更等）を示す更新レコードを追加する。このとき、各レコードは、上述した分類番号１１１についても保持するカラムを有する。

ここで、各キャッシュサーバ２００のロード部２２０は、ＤＢ１１０のログテーブル１２０にアクセスし、更新レコードが新たに追加されているか否かを更新日時等によりチェックし、追加されている場合は該当する更新レコードを読み込んで、更新内容をキャッシュ２１０の内容に反映させる。更新レコードを読み込む際に分類番号１１１を参照することで、自身が読み込むべき更新レコードのみを読み込むようにすることができる。ロード部２２０はキャッシュサーバ２００に予め設定された所定の間隔で定期的にログテーブル１２０にアクセスしてもよいし、更新トリガ等を利用して更新があったタイミングでログテーブル１２０にアクセスしてもよいが、以下ではロード部が定期的にログテーブルにアクセスする場合について説明する。

読み込んでキャッシュ２１０への反映が完了した更新レコードについては、ログテーブル１２０から削除するようにしてもよい。この場合は、ロード部２２０がログテーブル１２０にアクセスした際に、ログテーブル１２０に存在する更新レコードを新たに追加された更新レコードと判断することができ、更新日時等のチェックは不要となる。

このように、各テーブル単位ではなく全てのテーブルで共通のログテーブル１２０を有することにより、ＤＢ１１０においてテーブル数やレコード数が増大しても、各キャッシュサーバ２００がチェックする対象とするのはログテーブル１２０だけでよく、チェック処理の負荷を大きく低減させることが可能となる。

なお、ログテーブル１２０に更新レコードが追加されるタイミングが、各テーブルに対する更新処理が行われた時点であり、その後にトランザクションが完了してコミットされるという場合も生じ得る。この場合は、ログテーブル１２０のレコードの整合性を考慮して、各キャッシュサーバ２００のロード部２２０は、トランザクションが完了してコミットされたタイミングの順でログテーブル１２０から更新レコードを読み込むものとする。

ログテーブル１２０から更新レコードを読み込んだロード部２２０は、その更新内容をキャッシュ２１０の内容に反映させる。すなわち、対応するバケット２１１内のレコードを、更新レコードの更新内容に基づいて更新する。このとき、同一のレコードに対してＤＢ１１０において複数回の更新が行われている場合は、整合性を維持するため、更新の順序に従って時系列でキャッシュ２１０の内容を更新する必要がある。一方、異なるレコードに対する更新については、可能な限り並列的な処理を行い、反映させるまでのタイムラグを極力小さくする必要がある。

そこで、本実施の形態では、ＤＢ１１０におけるデータの更新をキャッシュサーバ２００において効率的にキャッシュ２１０に反映させる手段を有する。図４は、ＤＢ１１０におけるデータの更新を効率的にキャッシュ２１０に反映させるためのキャッシュサーバ２００の構成例について概要を示した図である。

キャッシュサーバ２００におけるロード部２２０は、フィード部２２１と複数の処理部２２３とを有する。フィード部２２１および処理部２２３はそれぞれ、データの授受を行うためのキューとしてフィードキュー２２２および処理キュー２２４を有する。また、各処理部２２３から共通してアクセス可能なメモリ領域や変数等からなる共通作業領域２２５を有する。フィード部２２１は、ＤＢ１１０のログテーブル１２０から自身が読み込むべき更新レコードを読み込むスレッドである。処理部２２３は、フィード部２２１がＤＢ１１０のログテーブル１２０から読み込んだ更新レコードを並列的に処理してキャッシュ２１０の対応するバケット２１１に反映させるスレッドである。

図５は、ロード部２２０におけるフィード部２２１および処理部２２３の処理の例を示したフローチャートである。フィード部２２１は、処理を開始すると、ＤＢ１１０のログテーブル１２０の内容をチェックし（Ｓ１１）、新たに追加された更新レコードのうち、自身が読み込むべき更新レコード（分類番号１１１の値がキャッシュ２１０内のバケット２２１のＩＤの値と同じもの）があるかを判定する（Ｓ１２）。読み込むべき更新レコードがある場合は、それを読み込んで、フィードキュー２２２に挿入する（Ｓ１３）。その後、予め定められた所定の時間スリープし（Ｓ１４）、ステップＳ１１に戻って一連の処理を繰り返す。なお、更新があったタイミングでロード部２２０がログテーブル１２０にアクセスする場合、スリープ時間は更新を知らせる信号を受けるまでとされる。

一方、各処理部２２３は、処理を開始すると、まず自身の処理キュー２２４をチェックし（Ｓ２１）、更新レコードがあるかを判定する（Ｓ２２）。更新レコードがある場合は、そこから１件取得し、その内容に基づいてキャッシュ２１０への反映処理を行う（Ｓ２３）。すなわち、取得した更新レコードの分類番号１１１の値と同じＩＤのバケット２２１の内容に、取得した更新レコードの内容を反映させる。なお、この反映処理の最中、共通作業領域２２５に自身が処理中のレコードを特定することが可能な情報を記録しておく。

ステップＳ２２において自身の処理キュー２２４に更新レコードがなく空である場合は、フィードキュー２２２から更新レコードを１件取得する（Ｓ２４）。ここで共通作業領域２２５をチェックし、取得した更新レコードに対応するレコードに対して他の処理部２２３で現在反映処理が行われているかを判定する（Ｓ２５）。他の処理部２２３で現在反映処理が行われている場合は、当該更新レコードを対象の処理部２２３の処理キュー２２４に挿入し（Ｓ２６）、ステップＳ２４に戻って、再度フィードキュー２２２から更新レコードを１件取得する。ステップＳ２５においてフィードキュー２２２から取得した更新レコードに対応するレコードが他のいずれの処理部２２３においても反映処理が行われていない場合は、当該更新レコードの内容に基づいてキャッシュ２１０に対する反映処理を行う（Ｓ２７）。その後、ステップＳ２１に戻って、一連の処理を繰り返す。

なお、各キャッシュサーバ２００のキャッシュ２１０にＤＢ１１０の全データを初期ロードする際に、上記の更新データを反映する方法を利用することも可能である。例えば、ＤＢサーバ１００上で、図示しないプログラム等によりＤＢ１１０の各テーブルのデータ全体を読み込み、その内容で新たに各テーブルにレコードを追加したものとして、対応する処理内容からなる更新レコードをログテーブル１２０に書き込むなどの対応をとることができる。この場合、初期ロード時も含めてログテーブル１２０からデータを取得してキャッシュ２１０にデータを格納することになるため、各テーブルのレコードには分類番号１１１を割り振らず、ログテーブル１２０に更新レコードを追加する際に割り振るようにしてもよい。

以上に説明したように、本発明の一実施の形態である分散キャッシュシステムによれば、ＤＢ１１０に保持する全てのデータを各キャッシュサーバ２００のキャッシュ２１０上に展開し、データがパーティション化された分散キャッシュシステム１を実現することができる。

各キャッシュサーバ２００は、自身のキャッシュ２１０内において定義されたバケット２１１の構成に応じて、自身が読み込むべきレコードのみをＤＢ１１０から読み込んでキャッシュ２１０に保持する。これにより、ＤＢ１１０に保持するレコードの値の分布等に影響されずに各キャッシュサーバ２００間でリソースの使用量を平準化することができる。また、キャッシュサーバ２００の台数の増減にも柔軟に対応可能で、内部トラフィックを低減させることが可能となる。

さらに本実施の形態では、ＤＢ１１０内の各テーブルに保持するレコードが他のシステム等により更新された場合にその更新内容を示す更新レコードを保持するための、各テーブルで共通のログテーブル１２０を有する。これにより、ＤＢ１１０のテーブル数やレコード数が増えた場合でも、更新内容を遅滞なく各キャッシュサーバ２００のキャッシュ２１０に反映させることが可能となる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

本発明は、各キャッシュサーバに保持するデータがパーティション化された分散キャッシュシステムに利用可能である。

１…分散キャッシュシステム、
１００…データベース（ＤＢ）サーバ、１１０…データベース（ＤＢ）、１１１…分類番号、１１２…更新日時、１２０…ログテーブル、
２００…キャッシュサーバ、２１０…キャッシュ、２１１…バケット、２２０…ロード部、２２１…フィード部、２２２…フィードキュー、２２３…処理部、２２４…処理キュー、２２５…共通作業領域、２３０…分散キャッシュ管理部。

Claims (3)

1. ネットワークに接続されたデータベースサーバと複数のキャッシュサーバとからなり、前記データベースサーバ上のデータベースに保持するデータの一部をそれぞれ重複せずに前記各キャッシュサーバ上のキャッシュに格納することで、前記各キャッシュサーバ全体として前記データベースに保持する全てのデータを前記キャッシュに展開するパーティション型の分散キャッシュシステムであって、
   前記各キャッシュサーバ上の前記キャッシュ上には、データを保持するための論理的な領域である１つ以上のバケットが定義され、前記各バケットには、当該分散キャッシュシステム内でユニークなＩＤが割り振られており、
   前記データベースに保持するデータの各レコードには、それぞれ前記各バケットのＩＤのうちのいずれか１つに該当する値が分類番号として割り振られており、
   前記キャッシュサーバは、前記データベースから、自身の前記キャッシュ上に定義されている前記バケットのＩＤに一致する前記分類番号を有するレコードのみを読み込んで、対応する前記バケットに格納するロード部を有し、
   前記データベースは、前記データベース上の各テーブルに対する外部からの更新があった際に、前記データベースサーバ上のプログラムにより、当該更新内容を示し前記分類番号を含む更新レコードを追加して記録するログテーブルを有し、
   前記キャッシュサーバの前記ロード部は、前記ログテーブルから、前記キャッシュ上に定義されている前記バケットのＩＤに一致する前記分類番号を有する更新レコードを読み込み、当該更新レコードの内容を対応する前記バケットの内容に反映させることを特徴とする分散キャッシュシステム。
2. 請求項１に記載の分散キャッシュシステムにおいて、
   前記ロード部は、前記ログテーブルから更新レコードを読み込んでフィードキューに挿入するフィード部と、
   前記フィードキューから更新レコードを取得し、当該更新レコードの前記分類番号に対応するＩＤを有する前記バケットの内容に当該更新レコードの内容を反映させる反映処理を並列的に行う複数の処理部とを有することを特徴とする分散キャッシュシステム。
3. 請求項２に記載の分散キャッシュシステムにおいて、
   前記ロード部の前記各処理部は、それぞれ処理キューを有し、前記フィードキューもしくは前記処理キューから更新レコードを取得して前記反映処理を行う際に、当該更新レコードが他の処理部において現在前記反映処理を行っているレコードと同一のレコードを対象とするものである場合は、当該更新レコードを、当該他の処理部の前記処理キューに挿入することを特徴とする分散キャッシュシステム。

Images