特許 6046523 インメモリ型分散データベース、データ分散方法及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6046523

(24)【登録日】2016年11月25日

(45)【発行日】2016年12月14日

(54)【発明の名称】インメモリ型分散データベース、データ分散方法及びプログラム

(51)【国際特許分類】

   G06F 12/00 20060101AFI20161206BHJP

   G06F 13/10 20060101ALI20161206BHJP

【ＦＩ】

   G06F12/00 545A

   G06F13/10 340A

【請求項の数】8

【全頁数】11

(21)【出願番号】特願2013-44074(P2013-44074)

(22)【出願日】2013年3月6日

(65)【公開番号】特開2014-174597(P2014-174597A)

(43)【公開日】2014年9月22日

【審査請求日】2015年8月27日

(73)【特許権者】

【識別番号】000208891

【氏名又は名称】ＫＤＤＩ株式会社

(74)【代理人】

【識別番号】100092772

【弁理士】

【氏名又は名称】阪本 清孝

(74)【代理人】

【識別番号】100119688

【弁理士】

【氏名又は名称】田邉 壽二

(72)【発明者】

【氏名】西谷 明彦

【審査官】 田中 幸雄

(56)【参考文献】

【文献】 国際公開第２０１２／０１７５２９（ＷＯ，Ａ１）

【文献】 特開２０１２−１９０３７７（ＪＰ，Ａ）

【文献】 特開２００３−３０８２３３（ＪＰ，Ａ）

【文献】 特開２０１１−１８６８１０（ＪＰ，Ａ）

【文献】 特開２００４−８６７２１（ＪＰ，Ａ）

【文献】 特開２００６−７９３８９（ＪＰ，Ａ）

【文献】 特開２００３−１４０８３８（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １２／００

Ｇ０６Ｆ １３／１０

(57)【特許請求の範囲】

【請求項1】

データを複数のノードに分散して記憶するに際し、前記各ノードのメモリの利用状況を一元的に管理するリソース監視サーバと、
ユーザアプリケーションからの入出力命令を前記ノードに転送する場合に前記リソース監視サーバの情報を参照し、書き込むデータに対する空きメモリ容量が少ないノードを避けて命令を転送する分散ＤＢルータと、を有するインメモリ型分散データベースにおいて、
前記各ノードは、前記分散ＤＢルータからの入出力命令を受信した時点で、書き込むデータに対する空きメモリ容量が指定された閾値以下の場合は、前記入出力命令を他のノードに転送する転送手段を備えたことを特徴とするインメモリ型分散データベース。

【請求項2】

前記転送手段は、前記閾値を超える空きメモリ容量があるノードを選択する転送先決定手段を備える請求項１に記載のインメモリ型分散データベース。

【請求項3】

前記分散ＤＢルータ内にキャッシュを構成し、ノードのメモリ使用量超過が解消されるまで入出力命令を前記キャッシュにて保持する請求項１に記載のインメモリ型分散データベース。

【請求項4】

ドキュメントの属性と重視するか否かの対応関係は運用者が予め定め、
前記分散ＤＢルータ内に構成されたキャッシュは、前記ユーザアプリケーションからの重要度の属性を重視するドキュメントの入力命令に対して、
信頼性の高いサーバ機器で構成されたノードへの書き込みを行う
ことで前記重視に応じた処理応答を行う請求項３に記載のインメモリ型分散データベース。

【請求項5】

ドキュメントの属性と重視するか否かの対応関係は運用者が予め定め、
前記分散ＤＢルータ内に構成されたキャッシュは、前記ユーザアプリケーションからの応答性能の属性を重視するドキュメントの入力命令に対して、
ノードへの書き込みが実施される前に前記ユーザアプリケーションへのレスポンスを返す処理を行う
ことで前記重視に応じた処理応答を行う請求項３に記載のインメモリ型分散データベース。

【請求項6】

ドキュメントの属性と重視するか否かの対応関係は運用者が予め定め、
前記分散ＤＢルータ内に構成されたキャッシュは、前記ユーザアプリケーションからの優先度の属性を重視するドキュメントの入力命令に対して、
処理待ちキューにおいて処理順番を優先させる処理を行う
ことで前記重視に応じた処理応答を行う請求項３に記載のインメモリ型分散データベース。

【請求項7】

データを複数のノードに分散して記憶するに際し、前記各ノードのメモリの利用状況を一元的に管理するリソース監視サーバと、
ユーザアプリケーションからの入出力命令を前記ノードに転送する場合に前記リソース監視サーバの情報を参照し、書き込むデータに対する空きメモリ容量が少ないノードを避けて命令を転送する分散ＤＢルータと、を有するインメモリ型分散データベースのデータ分散方法において、
前記分散ＤＢルータからの入出力命令を前記各ノードが受信した時点で、書き込むデータに対する空きメモリ容量が指定された閾値以下の場合は、前記入出力命令を他のノードに転送する手順を備えたことを特徴とするデータ分散方法。

【請求項8】

データを複数のノードに分散して記憶するに際し、前記各ノードのメモリの利用状況を一元的に管理するリソース監視サーバと、
ユーザアプリケーションからの入出力命令を前記ノードに転送する場合に前記リソース監視サーバの情報を参照し、書き込むデータに対する空きメモリ容量が少ないノードを避けて命令を転送する分散ＤＢルータと、を有するインメモリ型分散データベースのデータ分散プログラムにおいて、
前記分散ＤＢルータからの入出力命令を前記各ノードが受信した時点で、書き込むデータに対する空きメモリ容量が指定された閾値以下の場合は、前記入出力命令を他のノードに転送する手順をコンピュータに実行させるデータ分散プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、データを複数のノードに分散して記憶して管理するインメモリ型分散データベースに関し、特に、各ノードに対するデータの負荷分散を工夫したインメモリ型分散データベース、データ分散方法及びプログラムに関する。

【背景技術】

【0002】

近年の情報システムにおいては、取り扱うデータが激増することにより、サーバ１台で処理することが困難となっている。そのため、大容量データを保存し、高速に処理するために、複数のノードに対してデータを分散させて管理するインメモリ型分散データベースが普及してきている。
インメモリ型分散データベース（例えば、MongoDB）は、ハードディスクでデータを管理するデータベースシステムに対比して高速なデータの入出力を実現するため、主にメインメモリ上でデータを管理するよう設計されたものである。
すなわち、インメモリ型分散データベースは、データを複数のノードに分散して記憶するに際し、各ノードのメモリの利用状況を一元的に管理するリソース監視サーバと、各ノードとユーザアプリケーションとの間に位置しユーザアプリケーションからの入出力命令をノードに転送する場合にリソース監視サーバの情報を参照し、書き込むデータに対する空きメモリ容量が少ないノードを避けて命令を転送する分散ＤＢルータを有して構成されている。

【0003】

インメモリ型分散データベースを使用した管理制御システムでは、例えば特許文献１及び特許文献２に記載されるように、各ノードのリソース状況を監視し、リソースに対するアクションの実行の可否を判断する手法が提案されている。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２０１２−０８９１０９号公報

【特許文献2】特許第４８１１８３０号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

しかしながら、上述したインメモリ型データベースによれば、データを書き込む先のノードのメモリに空きが無い場合には、ハードディスクにデータが書き込まれるので、例えば高負荷なデータの入力命令によりノードのメモリから書込みデータがオーバーフローしてディスクI/Oが発生した場合には、応答性能が極端に劣化するという課題が存在した。

【0006】

本発明は上記実情に鑑みて提案されたもので、データを複数のノードに分散して記憶して管理するシステムにおいて、応答性能が極端に劣化する状況を回避可能となるようノードに対するデータの負荷分散を行う機能を備えたインメモリ型分散データベースを提供することを目的としている。

【課題を解決するための手段】

【0007】

上記目的を達成するため本発明は、データを複数のノードに分散して記憶して管理する場合に、各ノードのメモリの利用状況を一元的に管理するリソース監視サーバからの情報のみならず、必要に応じてノード間転送を可能とした構成に特徴を有する。

【0008】

すなわち、請求項１の発明は、データを複数のノードに分散して記憶するに際し、前記各ノードのメモリの利用状況を一元的に管理するリソース監視サーバと、ユーザアプリケーションからの入出力命令を前記ノードに転送する場合に前記リソース監視サーバの情報を参照し、書き込むデータに対する空きメモリ容量が少ないノードを避けて命令を転送する分散ＤＢルータと、を有するインメモリ型分散データベースにおいて、次の構成を含むことを特徴としている。
前記各ノードは、前記分散ＤＢルータからの入出力命令を受信した時点で、書き込むデータに対する空きメモリ容量が指定された閾値以下の場合は、前記入出力命令を他のノードに転送する転送手段を備える。

【0009】

請求項２の発明は、請求項１のインメモリ型分散データベースにおいて、前記転送手段は、前記閾値を超える空きメモリ容量があるノードを選択する転送先決定手段を備えることを特徴としている。

【0010】

請求項３の発明は、請求項１のインメモリ型分散データベースにおいて、前記分散ＤＢルータ内にキャッシュを構成し、ノードのメモリ使用量超過が解消されるまで入出力命令を前記キャッシュにて保持することを特徴としている。

【0011】

請求項４の発明は、請求項３のインメモリ型分散データベースにおいて、
ドキュメントの属性と重視するか否かの対応関係は運用者が予め定め、
前記分散ＤＢルータ内に構成されたキャッシュは、前記ユーザアプリケーションからの重要度の属性を重視するドキュメントの入力命令に対して、
信頼性の高いサーバ機器で構成されたノードへの書き込みを行う
ことで前記重視に応じた処理応答を行うことを特徴としている。
請求項５の発明は、請求項３のインメモリ型分散データベースにおいて、
ドキュメントの属性と重視するか否かの対応関係は運用者が予め定め、
前記分散ＤＢルータ内に構成されたキャッシュは、前記ユーザアプリケーションからの応答性能の属性を重視するドキュメントの入力命令に対して、
ノードへの書き込みが実施される前に前記ユーザアプリケーションへのレスポンスを返す処理を行う
ことで前記重視に応じた処理応答を行うことを特徴としている。
請求項６の発明は、請求項３のインメモリ型分散データベースにおいて、
ドキュメントの属性と重視するか否かの対応関係は運用者が予め定め、
前記分散ＤＢルータ内に構成されたキャッシュは、前記ユーザアプリケーションからの応答性能の属性を重視するドキュメントの入力命令に対して、
処理待ちキューにおいて処理順番を優先させる処理を行う
ことで前記重視に応じた処理応答を行うことを特徴としている。

【0012】

請求項７の発明は、データを複数のノードに分散して記憶するに際し、前記各ノードのメモリの利用状況を一元的に管理するリソース監視サーバと、ユーザアプリケーションからの入出力命令を前記ノードに転送する場合に前記リソース監視サーバの情報を参照し、書き込むデータに対する空きメモリ容量が少ないノードを避けて命令を転送する分散ＤＢルータと、を有するインメモリ型分散データベースのデータ分散方法において、
前記分散ＤＢルータからの入出力命令を前記各ノードが受信した時点で、書き込むデータに対する空きメモリ容量が指定された閾値以下の場合は、前記入出力命令を他のノードに転送する手順を備えたことを特徴としている。

【0013】

請求項８の発明は、データを複数のノードに分散して記憶するに際し、前記各ノードのメモリの利用状況を一元的に管理するリソース監視サーバと、
ユーザアプリケーションからの入出力命令を前記ノードに転送する場合に前記リソース監視サーバの情報を参照し、書き込むデータに対する空きメモリ容量が少ないノードを避けて命令を転送する分散ＤＢルータと、を有するインメモリ型分散データベースのデータ分散プログラムにおいて、
前記分散ＤＢルータからの入出力命令を前記各ノードが受信した時点で、書き込むデータに対する空きメモリ容量が指定された閾値以下の場合は、前記入出力命令を他のノードに転送する手順をコンピュータに実行させることを特徴としている。

【発明の効果】

【0014】

本発明によれば、各ノードに転送手段を設け、ユーザアプリケーションからの入出力命令を他のノードに転送可能とすることにより、ノードのメモリから書込みデータがオーバーフローすることを防止でき、ディスクI/Oの発生による応答性能が極端に劣化するという現象を回避できる。
また、分散ＤＢルータ内のキャッシュで入出力命令を保持することにより、データごとに、信頼性、応答性能、優先度等のレベルに応じた取り扱いが可能となる。

【図面の簡単な説明】

【0015】

【図1】本発明のインメモリ型分散データベースの全体構成を示すモデル図である。

【図2】インメモリ型分散データベースの分散ＤＢルータがデータ転送先を選定する場合の手順を示すフローチャート図である。

【図3】インメモリ型分散データベースのノードがノード間データ転送を行う場合の手順を示すフローチャート図である。

【図4】ノード間データ転送を行う場合の転送先決定処理の手順を示すフローチャート図である。

【図5】インメモリ型分散データベースの分散ＤＢルータがデータ転送先を選定する場合のタイミングチャート図である。

【図6】インメモリ型分散データベースの分散ＤＢルータがキャッシュしたデータの転送先を選定する場合のタイミングチャート図である。

【発明を実施するための形態】

【0016】

本発明のインメモリ型分散データベースの実施形態の一例について、図面を参照しながら説明する。
本発明のインメモリ型分散データベースは、ユーザアプリケーション１と、ユーザアプリケーション１からのデータを分散させて管理する複数のノード２と、各ノード２のメモリの利用状況を一元的に管理するリソース監視サーバ３と、ユーザアプリケーション１からの入出力命令を各ノード２に転送する分散ＤＢルータ４とにより構築されている。

【0017】

ユーザアプリケーション１は、例えばユーザからのアクセスに対して、ドキュメント（ノードのデータベースに入力するデータの単位）の生成時に分散ＤＢルータ４を介してデータを各ノード２へ分散させて管理する。ドキュメントには、重要度、応答性能、優先度等の属性データが付与され、この属性データに基づいて分散ＤＢルータ４が処理応答を行うようになっている。例えば、分散ＤＢルータ４は、重要度の高い属性を持つドキュメントについては信頼性の高いサーバ機器で構成されたノード２に書き込み、その処理が終了するまで待つ。「信頼性の高いサーバ機器」とは、ディスクの信頼性(MTBF)等の情報から、予め運用者により定義される。

【0018】

各ノード２、リソース監視サーバ３及び分散ＤＢルータ４は、オペレーティングシステム(OS)を含む基本プログラムやメモリ、プログラムを実行するCPU等コンピュータが有する主要な構成を備え、データ分散プログラムがインストールされることでデータ分散方法を備えたシステムとしてのインメモリ型分散データベースが構築されている。

【0019】

また、分散ＤＢルータ４は、通常はノード２への書き込み完了後にユーザアプリケーション１へ応答を返すが、応答性能の高い属性を持つドキュメントについては、ノード２への書き込みが実施される前（分散ＤＢルータ４内のキャッシュ４aへ保存後）にレスポンスを返す。これにより、応答性能が向上する。また、分散ＤＢルータ４は、優先度の高い属性を持つドキュメントについては、処理待ちのキュー（処理待ちのドキュメントがスタックされているバッファ）において処理順番を優先させる。加えて、ユーザアプリケーション１からの要求は分散ＤＢルータ４を介されるが、分散ＤＢルータ４にキャッシュされているドキュメントと同じデータへのアクセスがユーザアプリケーション１から要求された場合、対象ドキュメントは分散ＤＢルータ４内のキャッシュ４ａから取得される。

【0020】

各ノード２は、コンピュータが有する主要な構成を備えた一般的なサーバで形成され、メモリ２ａと、データベース２ｂと、転送手段２ｃを備えている。この転送手段２ｃは、分散ＤＢルータ４からの入出力命令を受信した時点で、書き込むデータに対する空きメモリ容量が指定された閾値以下の場合は、入出力命令を他のノード２に転送する。
また、転送手段２ｃは、閾値を超える空きメモリ容量を有するノード２を選択する転送先決定手段を備えている。この転送先決定手段は、各ノード２にリソース問合せを順次行い、応答を受信することでメモリ空きが有る他のノード２を選択する。これにより、ノード２が分散ＤＢルータ４からの入出力命令を受信した際、当該ノード２において、書き込むデータに対する空きメモリ容量が、運用者が指定した閾値以下である場合は、選択された他のノード２（リソースに空きがあるノード）に入出力命令を転送する。
各ノード２に存在するデータベース２ｂは、そのノード２に渡ってきたドキュメントをハードディスクに保管するためのものである。すなわち、オンメモリに存在するドキュメントを非同期にハードディスク上に保管することが行われる。これにより、仮にノード２の電源がＯＦＦになりメモリ２ａ上のデータが消えたとしても、このデータベース２ｂからメモリ２ａ上にデータを復旧させることができる。

【0021】

リソース監視サーバ３は、分散ＤＢルータ４及び各ノード２との間でデータの送受信が行われることで、データを複数のノード２に分散して記憶するに際し、各ノード２のメモリ２ａの利用状況を一元的に管理する。すなわち、リソース監視サーバ３は、定期的な監視トラフィックを行うことで、各ノード２のリソース使用量についてのリソース監視（一元管理）を行うとともに、分散ＤＢルータ４からの要求に応じてリソース情報を送信する。
各ノード２におけるメモリ２ａの使用量のチェックは、ノード側から自発的に通知する方法でも良い。この場合、リソース監視サーバ３における定期的な監視トラフィックを削減することができる。
また、リソース監視サーバ３は、いずれかのノード２のメモリの利用状況が、運用者が指定した閾値を超えた場合には、運用者にアラームを通知する。

【0022】

分散ＤＢルータ４は、各ノード２とユーザアプリケーション１との間に位置し、ユーザアプリケーション１からの入出力命令をノード２に転送する場合に、リソース監視サーバ３の情報を参照し、書き込むデータに対する空きメモリ容量が少ないノードを避けて命令を転送する。また、分散ＤＢルータ４は、内部にキャッシュ４ａを構成し、ノード２のメモリ使用量超過が解消されるまで入出力命令をキャッシュ４ａにて保持するようになっている（分散ＤＢルータ４内のキャッシュ４ａを一時的な共有メモリとして利用する）。

【0023】

また、分散ＤＢルータ４内に構成されたキャッシュ４ａにより、ユーザアプリケーション１からの応答性能重視のドキュメントの入力命令に対して処理応答を行うようになっている。
また、書き込むドキュメントを分散ＤＢルータ４にてキューイングし、優先度の高い属性を持つドキュメントは優先的に処理することが行われる。

【0024】

次に、上述したインメモリ型分散データベースを使用してデータを管理する手順について、図２〜図６を参照して説明する。
先ず、分散ＤＢルータ４によりデータ転送先のノードを選定する場合の処理手順について説明する（図２）。
分散ＤＢルータ４がユーザアプリケーション１から書込みデータを受信した場合（ステップ１１）、リソース監視サーバ３に対してリソース問合せ発行を行い、リソース監視サーバ３からの応答を受信する（ステップ１２）。リソース監視サーバ３では、定期的に各ノード２のメモリ２ａの利用状況を一元的に管理しているので、「空きリソース有」のノード２を把握することができる。
リソース監視サーバ３からの情報が「空きリソース有」の場合（ステップ１３）、空きリソース有のノード２に対して書込みデータの送信が行われる（ステップ１４）。

【0025】

リソース監視サーバ３からの情報が「空きリソース無」の場合（ステップ１３）、書込みデータを分散ＤＢルータ４のキャッシュ４ａに蓄積するとともに、その旨をユーザアプリケーション１へ応答する（ステップ１５）。
そして時間を置いて、ステップ１２及びステップ１３と同様のリソース問合せ発行及び応答受信（ステップ１６）及び空きリソースの有無の判断（ステップ１７）を繰り返して行い、「空きリソース有」が存在した場合（ステップ１７）、「空きリソース有」のノード２に対して書込みデータの送信を行う（ステップ１４）。

【0026】

次に、ステップ１４の分散ＤＢルータ４から「空きリソース有」のノード２に対して書込みデータの送信が行われ以降の当該ノード２での処理手順について、図３を参照して説明する。
ノード２が、分散ＤＢルータ４からの書込みデータを受信すると（ステップ２１）、自らのメモリ２ａの空きの有無のチェックを行い（ステップ２２）、空きメモリの有無を判断する（ステップ２３）。
空きメモリ有の場合、ノード２のメモリ２ａに対してデータ書込みが行われる（ステップ２４）。

【0027】

空きメモリ無しの場合、リソース監視サーバ３への通知を行い（ステップ２５）、リソース問合せ発行を行う（ステップ２６）。分散ＤＢルータ４からは、「空きリソース有」のノード２に対して書込みデータの送信が行われるので、ノード２の空きメモリは通常「有り」の状態であることが多いが、リソース監視サーバ３へ各ノード２からリソース情報が報告された時期によっては、その後の処理状況により、「空きリソース有」とされたノード２のメモリ２ａの空きがなくなるような場合も考えられる。

【0028】

ノード２では、リソース問合せ応答を受信し、転送先決定処理が行われる（ステップ２７）。
すなわち、図４及び図５に示すように、分散ＤＢルータ４から「空きリソース有」のノード２（ノードＡ）に対して書込みデータの送信５１が行われ、リソース問合せ応答受信及び転送先決定処理が開始された場合（ステップ３１）、各ノード２（ノードＢ，Ｃ）に対して順次リソースチェック５２が行われ、各ノード２（ノードＢ，Ｃ，…）からは順次リソースチェック応答５３を受信する（図５）。
転送先を決定するノード２（ノードＡ）では、各ノード２からの応答を受けるための応答時間が経過しているかどうかを判断する（ステップ３２）。
応答時間経過前であれば、リソース問合せ応答を受信し（ステップ３３）、リソース問合せ応答があったメモリ空き有（ステップ３４）のノード２（ノードＣ）を転送先として決定する。

【0029】

転送先ノードが決定された場合は（ステップ２８）、転送先ノード（ノードＣ）へ書込みデータの転送５４が行われ（ステップ２９）、分散ＤＢルータ４へ書込み応答５５が行われる（ステップ３０）。
メモリ空き有のノードでない場合は（ステップ３４）、リソース監視サーバ３への通知を行い（ステップ３５）、応答時間経過が経過するまで、リソース問合せ応答を受信し（ステップ３３）、メモリ空き有（ステップ３４）のノードを転送先として決定する作業が繰り返される。

【0030】

ステップ３２で応答時間経過が経過した場合は、転送先決定処理を終了する。
また、転送先ノードが無い場合は（ステップ２８）は、転送先決定を行うノード２にデータ書込みが行われる（ステップ２４）。すなわち、ノード２のあるノードから他のノードにドキュメントを転送しようとした場合、転送先も無い（他のノードもメモリの空きが無い）場合は、しかたなくノード２のハードディスクにデータを書込むという手段が取られる。

【0031】

次に、図２において、ノード２のメモリ２ａに空きがない時に（ステップ１３）、書込みデータを分散ＤＢルータ４のキャッシュに蓄積する場合において、応答性能重視のデータに関する処理について図６を参照して説明する。
ユーザアプリケーション１からの書込みデータの送信６１を分散ＤＢルータ４が受信し、リソース監視サーバ３に対してリソース問合せ発行６２を行い、リソース監視サーバ３から空きリソース無し（ノードのメモリに空きが無い）とのリソース応答６３を受信した場合、書込みデータを分散ＤＢルータ４内のキャッシュ４ａに蓄積し、リソース監視サーバ３に対してはキャッシュ処理通知６４を行い、アプリケーション１へは書込み応答６５を行う。
そして、リソース管理サーバ３とノード２との定期的な応答処理後に、ステップ１６及びステップ１７で空きリソースが見つかった場合、リソース管理サーバ３は分散ＤＢルータ４にリソース空き通知６６を行い、これを受けた分散ＤＢルータ４がキャッシュ４ａに蓄積されている書込みデータをノードへ転送６７する。

【0032】

上述したインメモリ型分散データベースによれば、各ノード２に転送手段２ｃを設け、リソース監視サーバ３からの情報により選定したノード２の空きメモリが少ないような場合においても、選定したノード２がユーザアプリケーション１からの入出力命令を他のノード２に転送（ノード間データ転送）可能とすることができる。その結果、ノード２のメモリ２ａから書込みデータがオーバーフローすることをより確実に防止でき、ディスクI/Oの発生による応答性能が極端に劣化するという現象を回避することができる。
また、分散ＤＢルータ４内にキャッシュ４ａを構成し、キャッシュ４ａで入出力命令を保持制御することにより、データごとに、信頼性、応答性能、優先度等のレベルに応じた応答処理を行うことが可能となる。

【符号の説明】

【0033】

１…ユーザアプリケーション、 ２…ノード、 ２a…メモリ、 ２ｃ…転送手段、 ３…リソース監視サーバ、 ４…分散ＤＢルータ ４a…キャッシュ。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】