JP5640432B2 - 分散処理装置、分散処理プログラムおよび分散処理方法 - Google Patents

Description

この発明は、複数のノードに処理群を分散する分散処理装置、分散処理プログラムおよび分散処理方法に関する。

近年、クラウドコンピューティングなどにおいて、データベースへの処理要求を複数の要求元から行うシステムが普及している。要求元とする複数のクライアントから共通のサーバへの処理要求を受け付けるシステムの場合、受け付けた処理要求を実行する処理ノードも複数個用意されている。

ところが、複数の処理要求を単純に複数の処理ノードによって実行させるシステムを用意しても、処理要求からは処理ノードの実行状況を把握できず、特定の処理ノードにばかり処理要求が集中する可能性がある。そこで、複数のクライアントからの処理要求を一元的に受け付けるフォワードプロキシ装置を利用する技術が提供されている。

フォワードプロキシ装置は、受け付けた処理要求を複数の処理ノードに均等に振り分けて、負荷を分散する。また、フォワードプロキシ装置を用意することによって、クライアントなどの処理要求元が要求した処理をどの処理ノードで実行しているか把握させることによって、複製透過性や位置透過性を担保する（たとえば、下記特許文献１参照。）。

特許第２５８６２１９号明細書

従来のフォワードプロキシ装置の場合、受け付けた処理要求を処理ノードに振り分ける際、処理要求の個数が判断基準となっていた。たとえば、処理要求が振り分けられていない空き状態の処理ノードや、実行待ちの処理要求の数が他の処理ノードよりも少ない処理ノードに優先的に処理要求が割り振られる。

ところが、処理ノードに振り分けられた処理要求は、実際に処理ノードによって実行させた際に、共通のデータベースの中のいずれのレコードにアクセスするかについては考慮されていない。すなわち、異なる処理ノードによって実行された処理要求が、共有のデータベース内の同一のレコードにアクセスする可能性がある。同一のレコードへのアクセスが集中すると、一の処理ノードによって実行している処理要求が終了するまで、他の処理ノードはロック状態となる。この結果、他の処理ノードはロック状態から解放されるまで処理を実行できず、ロック状態の解放待ちによる処理性能の低下を招くという問題があった。

本発明は、上述した従来技術による問題点を解消するため、データベース内の同一レコードへの同時アクセスを抑制することができる分散処理装置、分散処理プログラムおよび分散処理方法を提供することを目的とする。

上述した課題を解決し、目的を達成するため、開示の分散処理装置は、複数のレコードを格納するデータベースに対する処理を並列に実行可能な複数のノードに、前記データベースに対する処理群を割り当てる分散処理装置であって、前記各レコードを特定するための属性名に基づいて、前記処理群から選ばれた第１の処理の処理要求に含まれる属性名とは異なる他の属性名のレコードを処理対象とする第２の処理を前記処理群から検索し、前記第２の処理が検索された場合、前記第１および第２の処理を前記複数のノードに実行させる実行対象に決定し、決定された実行対象を前記複数のノードに割り当てることを要件とする。

本分散処理装置、分散処理プログラムおよび分散処理方法によれば、データベース内の同一レコードへの同時アクセスを抑制することができるという効果を奏する。

本実施の形態にかかるネットワークシステムの一実施例を示すシステム構成図である。 分散処理装置のハードウェア構成を示すブロック図である。 本実施の形態にかかる分散処理装置の機能的構成を示すブロック図である。 本実施の形態にかかる分散処理装置の分散処理手順の一例を示すフローチャートである。 処理対象となるデータの一例を示すデータテーブルである。 本実施の形態にかかる分散処理装置を適用したフォワードプロキシ装置を示す説明図である。 各形式の電文およびスキーマ取得例を示す説明図である。 排他アイテム名の定義例を示すデータテーブルである。 トランザクション取得処理部の処理手順を示すフローチャートである。 排他アイテム追加処理部の処理手順を示すフローチャートである。 トラン・アイテムキャッシュテーブルの一例を示すデータテーブルである。 トラン・アイテムキャッシュテーブルへの排他アイテムビット列の追加例を示す説明図である。 検索処理部の処理手順を示すフローチャートである。 処理ノードごとの排他識別レジスタの設定例を示す説明図である。 排他識別レジスタ更新後のトラン・アイテムキャッシュテーブル削除例を示す説明図である。 格納処理部の処理手順を示すフローチャートである。 ディスパッチ処理部の処理手順を示すフローチャートである。

以下に添付図面を参照して、この発明にかかる分散処理装置、分散処理プログラムおよび分散処理方法の好適な実施の形態を詳細に説明する。

図１は、本実施の形態にかかるネットワークシステムの一実施例を示すシステム構成図である。図１において、ネットワークシステム１００は、分散処理装置１０１と、クライアント装置Ｃと、複数のノードＮ１〜Ｎｎと、データベース１１０と、を含む構成である。ネットワークシステム１００において、分散処理装置１０１と、クライアント装置Ｃと、複数のノードＮ１〜Ｎｎと、データベース１１０とは、有線または無線のネットワーク１２０を介して接続されている。

分散処理装置１０１は、データベース１１０に対する処理群を複数のノードＮ１〜Ｎｎに割り当てる。クライアント装置Ｃは、データベース１１０に対する処理の処理要求を分散処理装置１０１に送信する。ノードＮ１〜Ｎｎは、分散処理装置１０１から割り当てられた処理を実行するコンピュータである。また、ノードＮ１〜Ｎｎは、データベース１１０に対する処理を並列に実行可能である。

ネットワークシステム１００において、分散処理装置１０１は、データベース１１０に対する処理群をノードＮ１〜Ｎｎに分散処理させる際に、同じ属性名のレコードを処理対象とする処理同士を同一タイミングでノードＮ１〜Ｎｎに割り当てない。属性名とは、データベース１１０内のレコードを特定するための属性情報である。これにより、データベース１１０内の同一レコードへの同時アクセスを防ぎ、同一レコードに対するアクセスの排他制御にともなうロック解放待ちを減らして、ネットワークシステム１００の性能劣化を回避する。

（分散処理装置１０１のハードウェア構成）
図２は、分散処理装置のハードウェア構成を示すブロック図である。図２において、分散処理装置１０１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１と、ＲＯＭ（Ｒｅａｄ‐Ｏｎｌｙ Ｍｅｍｏｒｙ）２０２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０３と、磁気ディスクドライブ２０４と、磁気ディスク２０５と、光ディスクドライブ２０６と、光ディスク２０７と、ディスプレイ２０８と、Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）２０９と、キーボード２１０と、マウス２１１と、スキャナ２１２と、プリンタ２１３と、を備えている。また、各構成部はバス２００によってそれぞれ接続されている。

ここで、ＣＰＵ２０１は、分散処理装置１０１の全体の制御を司る。ＲＯＭ２０２は、ブートプログラムや分散処理プログラムなどの各種プログラムを記憶している。ＲＡＭ２０３は、ＣＰＵ２０１のワークエリアとして使用される。磁気ディスクドライブ２０４は、ＣＰＵ２０１の制御にしたがって磁気ディスク２０５に対するデータのリード／ライトを制御する。磁気ディスク２０５は、磁気ディスクドライブ２０４の制御で書き込まれたデータを記憶する。

光ディスクドライブ２０６は、ＣＰＵ２０１の制御にしたがって光ディスク２０７に対するデータのリード／ライトを制御する。光ディスク２０７は、光ディスクドライブ２０６の制御で書き込まれたデータを記憶したり、光ディスク２０７に記憶されたデータをコンピュータに読み取らせたりする。

ディスプレイ２０８は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。このディスプレイ２０８は、たとえば、ＣＲＴ、ＴＦＴ液晶ディスプレイ、プラズマディスプレイなどを採用することができる。

Ｉ／Ｆ２０９は、通信回線を通じてＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットなどのネットワーク１２０に接続され、このネットワーク１２０を介して他の装置に接続される。そして、Ｉ／Ｆ２０９は、ネットワーク１２０と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。Ｉ／Ｆ２０９には、たとえばモデムやＬＡＮアダプタなどを採用することができる。

キーボード２１０は、文字、数字、各種指示などの入力のためのキーを備え、データの入力を行う。また、タッチパネル式の入力パッドやテンキーなどであってもよい。マウス２１１は、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などを行う。ポインティングデバイスとして同様に機能を備えるものであれば、トラックボールやジョイスティックなどであってもよい。

スキャナ２１２は、画像を光学的に読み取り、分散処理装置１０１内に画像データを取り込む。なお、スキャナ２１２は、ＯＣＲ（Ｏｐｔｉｃａｌ Ｃｈａｒａｃｔｅｒ Ｒｅａｄｅｒ）機能を持たせてもよい。また、プリンタ２１３は、画像データや文書データを印刷する。プリンタ２１３には、たとえば、レーザプリンタやインクジェットプリンタを採用することができる。なお、ここでは分散処理装置１０１のハードウェア構成について説明したが、図１に示したクライアント装置Ｃ、ノードＮ１〜Ｎｎについても同様のハードウェア構成を備える。

（分散処理装置１０１の機能的構成）
つぎに、実施の形態にかかる分散処理装置１０１の機能的構成について説明する。図３は、本実施の形態にかかる分散処理装置の機能的構成を示すブロック図である。図３において、分散処理装置１０１は、受付部３０１と、検出部３０２と、生成部３０３と、選択部３０４と、検索部３０５と、決定部３０６と、割当部３０７と、を含む構成である。各機能部（受付部３０１〜割当部３０７）は、具体的には、たとえば、図２に示したＲＯＭ２０２、ＲＡＭ２０３、磁気ディスク２０５、光ディスク２０７などの記憶装置に記憶されたプログラムをＣＰＵ２０１に実行させることにより、または、Ｉ／Ｆ２０９により、その機能を実現する。なお、各機能部（受付部３０１〜割当部３０７）の処理結果は、たとえば、ＲＡＭ２０３、磁気ディスク２０５、光ディスク２０７などの記憶装置に記憶される。

受付部３０１は、データベース１１０に対する処理を要求する処理要求をクライアント装置Ｃから受け付ける機能を有する。ここで、データベース１１０は、ノードＮ１〜Ｎｎがアクセス可能な共有データベースである。データベース１１０に対する処理としては、たとえば、データベース１１０に格納されているレコードの更新処理、参照処理および書込処理などがある。

また、処理要求は、たとえば、データベース１１０に対する処理を要求する電文や順編成ファイルである。処理要求は、一つの処理を要求するものでもよく、また、トランザクションやバッチジョブのように複数の処理を要求するものでもよい。処理要求は、たとえば、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）等のスキーマ構造が定義済みの電文（データ）を用いて記述されている。たとえば、処理要求には、処理対象となるデータのほか、該データを含むレコードを特定するための属性名が含まれている。

属性名は、データベース１１０に格納されているレコードを特定するための属性情報である。属性名は、たとえば、レコードに含まれる各データの項目名（フィールド名）や、各レコードを含むファイル（テーブル）のファイル名（テーブル名）などである。一つのレコードを特定するための属性名として、たとえば、ファイル名と項目名の組み合わせを設定してもよく、また、複数の項目名を設定してもよい。

レコードを特定するための属性名は、たとえば、予め設定されてＲＯＭ２０２、ＲＡＭ２０３、磁気ディスク２０５、光ディスク２０７などの記憶装置に記憶されている。ただし、属性名は、データベース１１０に格納されている全レコードについて設定してもよく、また、ノードＮ１〜Ｎｎからの同時アクセスを抑制したい特定のレコードについてのみ設定してもよい。

以下の説明では、データベース１１０内のレコードを「レコードＲ１〜Ｒｍ」と表記し、各レコードＲ１〜Ｒｍを特定するための属性名を「属性名Ａ１〜Ａｍ」と表記する。また、レコードＲ１〜Ｒｍのうち任意のレコードを「レコードＲｊ」と表記し、属性名Ａ１〜Ａｍのうち任意の属性名を「Ａｊ」と表記する（ｊ＝１，２，…，ｍ）。

検出部３０２は、受け付けた処理要求の中から属性名を検出する機能を有する。具体的には、たとえば、検出部３０２が、処理要求のデータ形式にしたがって、処理要求の中から属性名を表す文字列（たとえば、タグに囲まれた文字列）を検出する。処理要求のデータ形式としては、たとえば、ＸＭＬ要素形式やＸＭＬ属性形式などがある。

生成部３０３は、検出された検出結果に基づいて、レコードＲｊを特定するための属性名Ａｊごとに、受け付けた処理要求に属性名Ａｊが含まれているか否かを示すビット列を生成する機能を有する。具体的には、たとえば、生成部３０３が、属性名Ａｊごとに、処理要求に属性名Ａｊが含まれている場合は「１」、属性名Ａｊが含まれていない場合は「０」を示すビット列を生成する。このため、予め設定された属性名Ａｊの総数がｍ個の場合、ビット列はｍビットとなる。

一例として、「ｍ＝５」とし、受け付けた処理要求に属性名Ａ３が含まれている場合を説明する。この場合、各属性名Ａ１〜Ａ５が処理要求に含まれているか否かを示すビット列は、属性名Ａ１〜Ａ５の順に「００１００」となる。ビット列によれば、各処理要求に含まれている属性名Ａｊ（上記例では属性名Ａ３）を容易に特定することができる。

選択部３０４は、データベース１１０に対する処理群の中から第１の処理を選択する機能を有する。ここで、データベースに対する処理群とは、処理要求を受け付けた処理のうち未実行の処理の集合である。以下の説明では、データベース１１０に対する処理群を「処理群Ｔ１〜ＴＫ」と表記し、処理群Ｔ１〜ＴＫのうち任意の処理を「処理Ｔｋ」と表記する（ｋ＝１，２，…，Ｋ）。

具体的には、たとえば、選択部３０４が、処理群Ｔ１〜ＴＫのうち処理要求を受け付けた時刻が最も古い処理を第１の処理として選択してもよい。また、選択部３０４が、各処理Ｔ１〜ＴＫに予め付与されている優先度が、処理群Ｔ１〜ＴＫの中で最大となる処理Ｔｋを第１の処理として選択することにしてもよい。

検索部３０５は、各レコードＲｊを特定するための属性名Ａｊに基づいて、選択された第１の処理の処理要求に含まれる属性名とは異なる他の属性名のレコードを処理対象とする第２の処理を処理群Ｔ１〜ＴＫから検索する機能を有する。具体的には、たとえば、検索部３０５が、生成された処理Ｔｋごとのビット列に基づいて、第１の処理の処理要求に含まれる属性名と同一の属性名を含まない処理を第２の処理として検索する。

一例として、第１の処理のビット列を「１００００」とする。この場合、検索部３０５が、処理群Ｔ１〜ＴＫの中から、少なくともビット列の１番目のビットが「０」となる処理Ｔｋを第２の処理として検索する。この際、検索部３０５が、ビット列の１番目のビットが「０」となり、かつ、処理群Ｔ１〜ＴＫのうち処理要求を受け付けた時刻が最も古い処理Ｔｋを第２の処理として検索してもよい。

決定部３０６は、第２の処理が検索された場合、第１および第２の処理をノードＮ１〜Ｎｎに実行させる実行対象に決定する機能を有する。ここで、第１および第２の処理は、処理要求に含まれる属性名が互いに異なるため、処理対象となるレコードが異なる。したがって、ノードＮ１〜Ｎｎが第１および第２の処理を同時に実行したとしても、同一レコードに対するアクセスは発生しない。

また、検索部３０５は、決定された実行対象の処理要求に含まれる属性名とは異なる他の属性名のレコードを処理対象とする第３の処理を処理群Ｔ１〜ＴＫから検索する。具体的には、たとえば、検索部３０５が、生成された処理Ｔｋごとのビット列に基づいて、実行対象の処理要求に含まれる属性名と同一の属性名を含まない処理を第３の処理として検索する。また、検索部３０５による第３の処理を検索する検索処理は、たとえば、後述する決定部３０６によって決定される実行対象の処理数Ｘが、ノードＮ１〜Ｎｎのノード数ｎとなるまで繰り返し実行される。すなわち、『Ｘ＝ｎ』の条件を満たすまで、ノード数ｎから上記第１および第２の処理の２つの処理数を除く、最大で（ｎ−２）個の『第３の処理』が検索される。

一例として、実行対象として２つの処理が決定されており、各処理のビット列を「１００００」および「０１０００」とする。この場合、検索部３０５が、処理群Ｔ１〜ＴＫの中から、少なくともビット列の１番目のビットが「０」となり、かつ、２番目のビットが「０」となる処理Ｔｋを第３の処理として検索する。この際、検索部３０５が、ビット列の１番目および２番目のビットが「０」となり、かつ、処理群Ｔ１〜ＴＫのうち処理要求を受け付けた時刻が最も古い処理Ｔｋを第３の処理として検索してもよい。

また、決定部３０６は、第３の処理が検索された場合、さらに、第３の処理を実行対象に決定することにしてもよい。また、決定部３０６は、割当先となるノードＮｉと対応付けて実行対象となる処理を決定することにしてもよい。

割当部３０７は、決定された実行対象をノードＮ１〜Ｎｎに割り当てる機能を有する。具体的には、たとえば、割当部３０７が、決定された実行対象の処理の処理要求を割当先となるノードＮｉに送信する。この際、割当部３０７は、実行対象となる処理が複数存在する場合、実行対象となる各処理をそれぞれ異なるノードＮｉに振り分けて割り当てる。この結果、複数のノードＮ１〜Ｎｎにおいて、実行対象の複数の処理が並列に実行されることになる。

また、割当部３０７は、上記検索部３０５によって第３の処理が検索されなかった場合、決定された実行対象をノードＮ１〜Ｎｎに割り当てることにしてもよい。すなわち、既に決定された実行対象の処理と異なるレコードを処理対象とする処理が処理群Ｔ１〜ＴＫの中に存在しないため、この時点で、割当部３０７が、決定された実行対象をノードＮ１〜Ｎｎに割り当てる。

また、割当部３０７は、決定された実行対象の処理数Ｘが、ノードＮ１〜Ｎｎのノード数ｎとなった場合、決定された実行対象をノードＮ１〜Ｎｎに割り当てることにしてもよい。すなわち、これ以上、実行対象となる処理を決定しても割当先となるノードＮｉが存在しないため、この時点で、割当部３０７が、決定された実行対象をノードＮ１〜Ｎｎに割り当てる。

（分散処理装置１０１の分散処理手順）
つぎに、本実施の形態にかかる分散処理装置１０１の分散処理手順について説明する。図４は、本実施の形態にかかる分散処理装置の分散処理手順の一例を示すフローチャートである。図４のフローチャートにおいて、まず、選択部３０４により、データベース１１０に対する処理群Ｔ１〜ＴＫの中から第１の処理を選択する（ステップＳ４０１）。

つぎに、選択部３０４により、第１の処理が選択されたか否かを判断する（ステップＳ４０２）。ここで、第１の処理が選択された場合（ステップＳ４０２：Ｙｅｓ）、検索部３０５により、処理群Ｔ１〜ＴＫの中から、第１の処理の処理要求に含まれる属性名とは異なる他の属性名のレコードを処理対象とする第２の処理を検索する（ステップＳ４０３）。

そして、検索部３０５により、第２の処理が検索されたか否かを判断する（ステップＳ４０４）。ここで、第２の処理が検索された場合（ステップＳ４０４：Ｙｅｓ）、決定部３０６により、第１および第２の処理をノードＮ１〜Ｎｎに実行させる実行対象に決定する（ステップＳ４０５）。

つぎに、決定部３０６により、決定された実行対象の処理数ＸがノードＮ１〜Ｎｎのノード数ｎとなったか否かを判断する（ステップＳ４０６）。ここで、処理数Ｘがノード数ｎとなっていない場合（ステップＳ４０６：Ｎｏ）、検索部３０５により、処理群Ｔ１〜ＴＫの中から、決定された実行対象の処理要求に含まれる属性名とは異なる他の属性名のレコードを処理対象とする第３の処理を検索する（ステップＳ４０７）。

そして、検索部３０５により、第３の処理が検索されたか否かを判断する（ステップＳ４０８）。ここで、第３の処理が検索された場合（ステップＳ４０８：Ｙｅｓ）、決定部３０６により、さらに、第３の処理をノードＮ１〜Ｎｎに実行させる実行対象に決定して（ステップＳ４０９）、ステップＳ４０６に戻る。

一方、第３の処理が検索されなかった場合（ステップＳ４０８：Ｎｏ）、割当部３０７により、ノードＮ１〜Ｎｎに決定された実行対象を割り当てて（ステップＳ４１０）、ステップＳ４０１に戻る。また、ステップＳ４０４において、第２の処理が検索されなかった場合（ステップＳ４０４：Ｎｏ）、割当部３０７により、ノードＮ１〜Ｎｎに決定された実行対象を割り当てて（ステップＳ４１０）、ステップＳ４０１に戻る。

また、ステップＳ４０６において、処理数Ｘがノード数ｎとなった場合（ステップＳ４０６：Ｙｅｓ）、割当部３０７により、ノードＮ１〜Ｎｎに決定された実行対象を割り当てて（ステップＳ４１０）、ステップＳ４０１に戻る。

そして、ステップＳ４０２において、第１の処理が選択されなかった場合は（ステップＳ４０２：Ｎｏ）、本フローチャートによる一連の処理を終了する。すなわち、分散対象となる処理Ｔｋが存在しないため、分散処理装置１０１による分散処理の実行を終了する。また、ステップＳ４０４において、第２の処理が検索されなかった場合（ステップＳ４０４：Ｎｏ）、決定部３０６により、第１の処理をノードＮ１〜Ｎｎに実行させる実行対象に決定して（ステップＳ４１１）、ステップＳ４１０に移行する。

以上説明したように、本実施の形態にかかる分散処理装置１０１によれば、データベース１１０内の各レコードＲ１〜Ｒｍを特定するための属性名Ａ１〜Ａｍに基づいて、処理対象のレコードが、第１の処理と異なる第２の処理を処理群Ｔ１〜ＴＫから検索できる。また、分散処理装置１０１によれば、第２の処理が検索された場合、第１および第２の処理を実行対象に決定して、ノードＮ１〜Ｎｎに割り当てることができる。これにより、同一レコードに対するアクセスの競合が発生しない第１および第２の処理を並列実行させることができる。

また、分散処理装置１０１によれば、処理対象のレコードが、決定された実行対象とは異なる第３の処理を処理群Ｔ１〜ＴＫから検索して、さらに、第３の処理を実行対象に決定することができる。これにより、同一レコードに対するアクセスの競合が発生しない第３の処理をさらに並列実行させることができる。

また、分散処理装置１０１によれば、第３の処理が検索されなかった場合に、決定された実行対象を複数のノードＮ１〜Ｎｎに割り当てることにしてもよい。これにより、処理対象のレコードが、既に決定された実行対象と異なる処理が存在しなくなった時点で、実行対象をノードＮ１〜Ｎｎに割り当てることができる。これにより、ノードＮ１〜Ｎｎに処理群Ｔ１〜ＴＫを分散処理させる際の効率化を図ることができる。

また、分散処理装置１０１によれば、レコードＲｊを特定するための属性名Ａｊが含まれているか否かを示す処理要求ごとのビット列に基づいて、第２または第３の処理を検索することができる。これにより、各処理要求に含まれている属性名Ａｊを容易に特定でき、第２または第３の処理を検索する検索処理の効率化を図ることができる。

これらのことから、分散処理装置１０１によれば、処理群Ｔ１〜ＴＫをノード群Ｎ１〜Ｎｎに分散処理させる際に、同じ属性名のレコードを処理対象とする処理同士を同一タイミングで割り当てないことで、同一レコードへの同時アクセスを防ぐことができる。この結果、データベース１１０に対するアクセスの排他制御にともなうロック解放待ちを減らして、ネットワークシステム１００のスループットを向上させることができる。

つぎに、本実施の形態にかかる分散処理装置１０１の実施例について説明する。ここでは、分散処理装置１０１をフォワードプロキシ装置６００に適用した場合を例に挙げて、具体的なトランザクションデータの分散処理について説明する。

図５は、処理対象となるデータの一例を示すデータテーブルである。また、図６は、本実施の形態にかかる分散処理装置を適用したフォワードプロキシ装置を示す説明図である。フォワードプロキシ装置６００（図６参照）では、図５のデータテーブル５００に示すような、エンティティと属性とが設定されたトランザクションデータを取得して、各処理ノードに実行させる。すなわち、フォワードプロキシ装置６００が扱うトランザクションデータの場合、データテーブル５００が表している属性に基づいてデータベース内の１レコードが構成されていることを意味する。なお、トランザクションデータは、上述した処理の処理要求に相当する。

図６に例示したフォワードプロキシ装置６００は、共通のデータベースへの処理を要求するトランザクションデータを一括して取得して、共通のデータベースへの並列処理が可能な各処理ノード、たとえば、後述する図１４に示すような、「ア」、「イ」、「ウ」の各処理ノードへ振り分ける機能を有している。なお、処理ノード「ア」、「イ」、「ウ」は、上述したノードＮ１〜ＮｎのいずれかのノードＮｉに相当する。

トランザクションデータとしては、たとえば、オンラインクライアントから入力された電文６０１や、バッチジョブのバッチファイルとして入力される順編成ファイル６０２などが挙げられる。フォワードプロキシ装置６００は、共通のデータベースへの処理要求として、上述のようなトランザクションデータを取得すると、トランザクションデータを一旦装置内に格納する。そして、格納済みのトランザクションデータの中の未処理のトランザクションデータを各処理ノードに振り分けて、並列処理を実行させる。

特に、フォワードプロキシ装置６００の場合、各処理ノードが並列処理を行う際に、同一のレコードが処理対象として設定されないようなトランザクションデータを抽出して、それぞれ実行させる処理ノードを振り分ける。すなわち、並列処理される各トランザクションデータは、処理対象となるレコードにそれぞれ排他性が保たれている。

フォワードプロキシ装置６００によってトランザクションデータが振り分けられた各処理ノードであれば、並列処理を実行中に共通のデータベース内の同一のレコードへのアクセスが重複することはない。したがって、従来の負荷分散装置のような、同一のレコードへのアクセス集中によるロック状態の発生を防ぎ、いずれかの処理ノードが待機中となり処理効率を低下させるような事態を回避することができる。

具体的な構成について説明すると、フォワードプロキシ装置６００は、上述した分散処理装置１０１を実現するための機能部として、トランザクション取得処理部６１０と、排他アイテム追加処理部６２０と、検索処理部６３０と、格納処理部６４０と、ディスパッチ処理部６５０とを備えている。

トランザクション取得処理部６１０は、分散処理装置１０１の受付部３０１に相当する。トランザクション取得処理部６１０を用意することによって、複数のレコードを格納するデータベースに対する処理を一括して受け付けることができる。また、排他アイテム追加処理部６２０は、分散処理装置１０１の検出部３０２および生成部３０３に相当する。排他アイテム追加処理部６２０によって、トランザクションデータごとに、アクセス先となるレコードを特定するための属性名を表すビット列を生成することができる。

また、検索処理部６３０は、分散処理装置１０１の選択部３０４および検索部３０５に相当する。フォワードプロキシ装置６００では、任意のトランザクションデータもしくは、最も古いトランザクションデータを第１の処理として、他のトランザクションデータから第２の処理を検索する。また、格納処理部６４０は、分散処理装置１０１の決定部３０６に相当する。また、各処理ノードにおけるトランザクションデータの実行については、ディスパッチ処理部６５０によって制御される。なお、各機能部の詳細な処理内容については後述する。

また、フォワードプロキシ装置６００には、各種データを記憶する記憶領域として、トラン・アイテムテーブル６０３と、振分前データテーブル６０４と、処理ノードごとのデータキュー６０５とが用意されている。各記憶領域の役割についても関連する機能部の説明に合わせて詳しく後述する。なお、トラン・アイテムテーブル６０３内には、高速アクセス可能なトラン・アイテムキャッシュテーブルおよび排他識別レジスタが用意されている。

＜データ構成＞
ここで、フォワードプロキシ装置６００による負荷分散処理の説明に入る前に、フォワードプロキシ装置６００に入力されるトランザクションデータのデータ構成について説明する。フォワードプロキシ装置６００では、取得したトランザクションデータに含まれている情報に基づいて、トランザクションデータを処理する際にアクセスするレコードが特定される。上述したように、各処理ノードが共通のデータベースに対して並列処理を行う場合には、各処理ノードがそれぞれ処理を実行する際に、アクセスするレコードが重複しないようなトランザクションデータを振り分けなければならない。

そこで、フォワードプロキシ装置６００は、取得したトランザクションデータの中から、処理実行時にアクセスするレコードを特定するための情報を参照して、予めどのレコードへアクセスが発生するかを表す情報を用意しておく。具体的には、フォワードプロキシ装置６００は、取得したトランザクションのデータ形式に基づいて、データテーブル５００（図５参照）に挙げられたエンティティのいずれのデータが処理対象となるかを特定する。そして、特定された処理対象となるデータに応じて、トランザクションデータを処理ノードによって実行する際に、アクセスされるレコードを特定することができる。

ここで、図７は、各形式の電文およびスキーマ取得例を示す説明図である。図７のデータ列７００は、フォワードプロキシ装置６００に入力される電文６０１の形式の具体例と、データ形式ごとの電文６０１の表示内容の仕様を意味するスキーマとを表している。図７のデータ列７００では、電文６０１の形式として、（Ａ）ＸＭＬ要素形式と、（Ｂ）ＸＭＬ属性形式と、（Ｃ）ＣＳＶ（Ｃｏｍｍａ Ｓｅｐａｒａｔｅｄ Ｖａｌｕｅｓ）形式とが挙げられている。いずれの形式の電文６０１も、学生構成テーブル学校ＩＤ“ＪＯ１２３４”のレコードについて、総数を“１８３”名に更新するための処理が記されている。

そして、図８は、排他アイテム名の定義例を示すデータテーブルである。フォワードプロキシ装置６００の場合、図８のデータ列８００に示したような排他アイテム名リストが設定されている。排他アイテム名リストは、「学生構成」、「教職員構成」、「収入」、「支出」などが、それぞれ排他アイテム名として設定されている。各トランザクションデータは、各排他アイテム名のどの属性を表すデータが含まれているかに応じて、処理実行時にアクセスするテーブルを特定する。

具体的には、属性と各排他アイテム名とが同列に設定されているデータテーブル８１０を利用して、トランザクションデータに含まれる属性から排他アイテム名を一意的に特定することができる。すなわち、フォワードプロキシ装置６００が図７のデータ列７００に示したような電文６０１を取得すると、電文６０１に含まれる属性から排他アイテム名を特定する。また、排他アイテム名は、「学生構成」、「教職員構成」など、実際の名称ではなく、少ないビット数で識別できるように、下記のように識別子を設定しておく。

学生構成に関する属性８１１ →排他アイテム名Ａ
教職員構成に関する属性８１２→排他アイテム名Ｂ
収入に関する属性８１３ →排他アイテム名Ｃ
支出に関する属性８１４ →排他アイテム名Ｄ
その他の任意の属性 →排他アイテム名Ｅ

上述したように、同じ排他アイテム名に設定される属性のデータであれば同じレコードに格納されていることを意味する。したがって、たとえば、学生構成に関する属性８１１のいずれかが含まれた電文６０１であれば、上記のような設定が行われている場合には、電文６０１は排他アイテム名Ａを処理対象とすると特定される。また、電文６０１によって排他アイテム名Ａ，Ｃを処理対象とするといったように複数の排他アイテム名が設定されている場合、当然のことながら、１つのトランザクションデータによって複数のレコードにアクセスが行われる。

＜トランザクション取得処理部＞
図９は、トランザクション取得処理部の処理手順を示すフローチャートである。図９のフローチャートに示すように、トランザクション取得処理部６１０は、共通のデータベースを処理対象とするトランザクションデータを取得する機能を有する。トランザクション取得処理部６１０は、オンラインクライアントやバッチジョブからのトランザクションデータ（たとえば、電文６０１や順編成ファイル６０２）の入力をトリガに処理を開始する。

図９のように、トランザクション取得処理部６１０では、事前処理として、排他対象を抽出するためのキーワードである「排他アイテム名」が設定されているか否かを判断する（ステップＳ９０１）。ステップＳ９０１において、排他アイテム名が設定されていないと判断された場合（ステップＳ９０１：Ｎｏ）、トランザクション取得処理部６１０は、設計者や上位システムからの指示を受け付けて、排他アイテム名を設定する（ステップＳ９０２）。

なお、フォワードプロキシ装置６００の場合、ステップＳ９０２では、「排他アイテム名」としてＡ，Ｂ，Ｃ，Ｄ，Ｅの５個が設定される。また、ステップＳ９０１において、排他アイテム名が設定されていると判断された場合（ステップＳ９０１：Ｙｅｓ）、そのままステップＳ９０３の処理に移行する。

そして、トランザクション取得処理部６１０は、実際にトランザクションデータを取得したか否かを判断する（ステップＳ９０３）。ステップＳ９０３では、トランザクションデータを取得するまで待機状態となる（ステップＳ９０３：Ｎｏのループ）。ステップＳ９０３において、トランザクションデータを取得したと判断されると（ステップＳ９０３：Ｙｅｓ）、トランザクション取得処理部６０１は、トランザクションデータの排他条件逐次をチェックするための準備として、「排他アイテムビット列」を作成する（ステップＳ９０４）。

さらに、トランザクション取得処理部６０１は、ステップＳ９０４によって作成した「排他アイテムビット列」を排他識別ハッシュ値にエンコードし（ステップＳ９０５）、トランザクションＩＤを採番する（ステップＳ９０６）。なお、トランザクションＩＤは、他のトランザクションデータとの区別し、なおかつ、トランザクション取得処理部６１０による取得順序を特定する必要があるため通し番号が振られる。

「排他アイテムビット列」は、トランザクションデータを実行する際にアクセスされる排他アイテム名（レコード単位）を表している。したがって、たとえば、排他アイテム名「Ａ，Ｂ，Ｃ，Ｄ，Ｅ」に対応した排他アイテムビット列が「０１０１１」であれば、ビットが立っている排他アイテム名Ｂ，Ｄ，Ｅを参照するトランザクションデータであることを意味する。

そして、生成された排他アイテムビット列「０１０１１」は、排他識別ハッシュ値にエンコードされ、１０進表示の「１１」となる。なお、本実施例では排他識別ハッシュ値として１０進数化したものを例示するが、１６進など排他アイテムビット列に戻すことが可能な表現であればどのようなものを用いてもよい。

その後、トランザクション取得処理部６１０は、ステップＳ９０６によって採番されたトランザクションＩＤをキーとして、ステップＳ９０５によってエンコードされた排他識別ハッシュ値をトラン・アイテムテーブル６０３に追加する（ステップＳ９０７）。また、トランザクション取得処理部６１０は、トランザクションＩＤをキーに取得したデータ（処理内容に相当するトランザクションデータ）を、振分前データテーブル６０４に格納する（ステップＳ９０８）。

そして、トランザクション取得処理部６１０は、あらたなトランザクションデータを取得したことによって、トラン・アイテムテーブル６０３と振分前データテーブル６０４が更新されたことを排他アイテム追加処理部６２０に通知して（ステップＳ９０９）、一連の処理を終了する。

以上説明したように、トランザクション取得処理部６１０は、共通のデータベースへの処理を行うトランザクションデータを一括して取得して、各処理ノードへ振り分ける前、振分前データテーブル６０４に一時的に格納する。同時に、トランザクション取得処理部６１０は、後段の処理によって、各処理ノードによって並列処理する際に、同一のレコードへのアクセスが競合しないようなトランザクションデータを振り分けるための、振り分け基準となる排他アイテムビット列を作成する。

また、トランザクション取得処理部６１０は、トランザクションデータから作成した排他アイテムビット列を排他識別ハッシュ値にエンコードしてトラン・アイテムテーブル６０３に格納している。エンコードによって、トランザクションデータごとの排他アイテムビット列の格納に要する容量が大幅に削減される。したがって、フォワードプロキシ装置６００にトランザクションデータが集中してもオーバーフローを起こすことなく、効率的に振り分けることができる。

＜排他アイテム追加処理部＞
図１０は、排他アイテム追加処理部の処理手順を示すフローチャートである。排他アイテム追加処理部６２０は、トランザクション取得処理部６１０によってあらたに取得したトランザクションデータを各処理ノードによって実行させるトランザクションデータとして、排他アイテムビット列とともに、トラン・アイテムキャッシュテーブルに追加する機能を有する。

排他アイテム追加処理部６２０は、まず、トラン・アイテムテーブル６０３から１レコードを抽出する（ステップＳ１００１）。なお、ステップＳ１００１の抽出処理は、トランザクション取得処理部６１０によるトラン・アイテムテーブル６０３と振分前データテーブル６０４が更新された旨の通知指示を受けた時、もしくは、トラン・アイテムキャッシュテーブルに空きがある時に行われる。当然のことながら、トランザクション取得処理部６１０からの通知指示を受けた場合であっても、トラン・アイテムキャッシュテーブルに空きがなければ、空きが発生するまで待機状態となる。

図１１−１は、トラン・アイテムキャッシュテーブルの一例を示すデータテーブルである。上述したように、トラン・アイテムテーブル６０３には、図１１−１に示す高速アクセス可能なトラン・アイテムキャッシュテーブルが用意されている。トラン・アイテムキャッシュテーブルには、トランザクションＩＤごとに、トランザクションＩＤに該当するトランザクションデータについて作成された排他アイテムビット列が格納されている。

つぎに、排他アイテム追加処理部６２０は、ステップＳ１００１によって抽出したレコードの排他識別ハッシュ値をデコードし、排他アイテムビット列を生成する（ステップＳ１００２）。すなわち、ステップＳ１００２の処理によって、トランザクションＩＤと紐付いていた排他識別ハッシュ値（１０進表示）が、ステップＳ９０４（図９参照）によって作成された排他アイテムビット列（２進表示）に戻される。

さらに、排他アイテム追加処理部６２０は、トランザクションＩＤをキーとして、ステップＳ１００２によって生成された排他アイテムビット列をトラン・アイテムキャッシュテーブルに追加する（ステップＳ１００３）。

図１１−２は、トラン・アイテムキャッシュテーブルへの排他アイテムビット列の追加例を示す説明図である。たとえば、ステップＳ１００２によって、トランザクションＩＤ：２０に紐付いた排他識別ハッシュ値から排他アイテムビット列が生成されたとする。すると、ステップＳ１００３の処理によって、トラン・アイテムキャッシュテーブルに図１１−２に示すような排他アイテムビット列１１２０が追加される。

図１０の説明に戻り、ステップＳ１００３の処理が完了すると、排他アイテム追加処理部６２０は、ステップＳ１００３の処理によってトラン・アイテムキャッシュテーブルが更新されたことを検索処理部６３０に通知して（ステップＳ１００４）、一連の処理を終了する。

以上説明したように、排他アイテム追加処理部６２０は、あらたに取得したトランザクションデータの排他アイテムビット列をトランザクションＩＤと共に、トラン・アイテムキャッシュテーブルに追加する。トラン・アイテムキャッシュテーブルに格納されることによって、あらたに取得したトランザクションデータが、各処理ノードへの振り分け対象となるトランザクションデータの一つとして登録されたことを意味する。

＜検索処理部＞
図１２−１は、検索処理部の処理手順を示すフローチャートである。検索処理部６３０は、排他識別レジスタを利用して、トラン・アイテムキャッシュテーブルに格納されているトランザクションＩＤの中から、処理ノード「ア」、「イ」、「ウ」によって並列処理を実行させるトランザクションデータのトランザクションＩＤを検索する機能を有する。

検索処理部６３０は、排他識別レジスタに設定する排他アイテムビット列を設定するため、まず、各処理ノード「ア」、「イ」、「ウ」によって実行させるトランザクションデータの検索条件を決定する（ステップＳ１２０１）。検索条件は、トラン・アイテムキャッシュテーブルに格納されている排他アイテムビット列に応じて一意的に決定する。具体的には、下記の２つが検索条件となる。
１）排他識別レジスタに既に設定されている排他アイテムビット列と共通の排他アイテム名のビットが立っていない（「０」が設定されている）。
２）トラン・アイテムキャッシュテーブルに格納されている排他アイテムビット列の中でもっとも古い。

そして、検索処理部６３０は、トラン・アイテムキャッシュテーブルから、ステップＳ１２０１によって決定された検索条件に当てはまるレコードを検索する（ステップＳ１２０２）。その後、検索処理部６３０は、ステップＳ１２０２によって検索されたレコードを各処理ノードに対応した排他識別レジスタに設定する（ステップＳ１２０３）。検索処理部６３０は、ステップＳ１２０３による排他識別レジスタの設定後、設定されたレコードをトラン・アイテムキャッシュテーブルから削除する（ステップＳ１２０４）。

図１２−２は、処理ノードごとの排他識別レジスタの設定例を示す説明図である。図１２−２を用いて、ステップＳ１２０１〜Ｓ１２０４の処理について具体例を挙げて説明する。図１２−２のように、排他識別レジスタは、処理ノードごとに用意されている。検索処理部６３０は、まず、検索条件に基づいて、処理ノード「ア」に対応する排他識別レジスタに排他アイテムビット列を設定する。排他識別レジスタは、処理ノード「ア」から順に設定を行うため、まず、各排他識別レジスタが未設定の状態から処理が開始される。

したがって、処理ノード「ア」に対応する排他識別レジスタの排他アイテムビット列は、他の排他レジスタの排他アイテムビット列を参照する必要はないため、必然的に、トラン・アイテムキャッシュテーブルに格納されている最も古い排他アイテムビット列が設定される。なお、トランザクション取得処理部６１０の説明にて述べたように、トランザクションＩＤは、通し番号が振られている。

すなわち、トランザクションＩＤの値が最小となる排他アイテムビット列が最も古い排他アイテムビット列となる。したがって、処理ノード「ア」に相当する排他識別レジスタには、トランザクションＩＤ：１に相当する排他アイテムビット列が設定される。そして、排他アイテムビット列が設定されると、ステップＳ１２０４の処理によって、設定されたレコード（トランザクションＩＤ：１に相当する排他アイテムビット列）はトラン・アイテムキャッシュテーブルから削除される。

つぎに、処理ノード「イ」に対応する排他識別レジスタには、トラン・アイテムキャッシュテーブルに格納されている排他アイテムビット列の中から、設定済みの排他識別レジスタの各ビットと競合しない排他アイテムビット列を設定する。したがって、検索処理部６３０は、上述した検索条件の１），２）から該当する排他アイテムビット列を検索する。すなわち、最も古く、かつ、排他アイテム名Ｄ，Ｅを含まない排他アイテムビット列が検索される。結果として、処理ノード「イ」に対応する排他識別レジスタには、トランザクションＩＤ：３に相当する排他アイテムビット列が設定される。

なお、図１２−２に例示した１段目の排他識別レジスタの場合、トラン・アイテムキャッシュテーブルの中から処理ノード「ア」、「イ」に対応する排他識別レジスタと排他アイテム名が競合しない排他アイテムビット列を検索することができなかった。したがって、処理ノード「ウ」に関しては、排他アイテムビット列を設定なしとして処理を終了する。

しかしながら、つぎの処理ステップを表す２段目の排他識別レジスタの場合、それぞれ排他識別レジスタと排他アイテム名が競合しない排他アイテムビット列を検索することができたため、処理ノード「ア」、「イ」、「ウ」のすべての排他アイテムビット列を設定して処理を終了する。

図１２−３は、排他識別レジスタ更新後のトラン・アイテムキャッシュテーブル削除例を示す説明図である。図１２−３のように、処理ノード「ア」、「イ」に対応する排他識別レジスタに排他アイテムビット列が設定されると、トラン・アイテムキャッシュテーブルの中からトランザクションＩＤ：１，３のレコード１２２０が削除される。

図１２−１の説明に戻り、ステップＳ１２０４の処理と並列して、検索処理部６３０は、ステップＳ１２０３によって排他識別レジスタの設定後、つぎに各処理ノード「ア」、「イ」、「ウ」によって実行するトランザクションＩＤと処理ノード名とを格納処理部６４０に通知する（ステップＳ１２０５）。最後に、検索処理部６３０は、ステップＳ１２０５の通知後、排他識別レジスタの処理ステップをインクリメントして、レジスタを初期化し（ステップＳ１２０６）、一連の処理を終了する。

以上説明したように、検索処理部６３０は、排他識別レジスタを利用して、排他アイテム名が重複しないトランザクションデータを各処理ノードによって並列処理させるように設定することができる。また、トランザクションデータと実行させる処理ノードを設定する際に、トランザクションＩＤが若い、すなわち、古いトランザクションデータを優先的に設定するため、トランザクションデータの待機時間を最小限に抑えることができる。

＜格納処理部＞
図１３は、格納処理部の処理手順を示すフローチャートである。格納処理部６４０は、検索処理部６３０からの通知結果に基づいて、振分前データテーブル６０４に格納されたトランザクション（電文６０１や順編成ファイル６０２）をデータキュー６０５に格納する機能を有する。

格納処理部６４０は、検索処理部６３０からの通知によって、トランザクションＩＤが指定されたか否かを判断する（ステップＳ１３０１）。トランザクションＩＤが指定されるまで待機状態となる（ステップＳ１３０１：Ｎｏのループ）。その後、トランザクションＩＤが指定されると（ステップＳ１３０１：Ｙｅｓ）、格納処理部６４０は、まず、振分前データテーブル６０４に格納されているトランザクションデータの中から、検索処理部６３０による通知で指定されたトランザクションＩＤに該当するトランザクションデータを抽出する（ステップＳ１３０２）。

つぎに、格納処理部６４０は、ステップＳ１３０２によって抽出したトランザクションデータを、検索処理部６３０からの通知によって指定された処理ノード名のデータキュー６０５に格納する（ステップＳ１３０３）。すなわち、トランザクションＩＤ：１の処理ノードとして処理ノード「ア」が指定された場合には、トランザクションＩＤ：１に該当するトランザクションデータを処理ノード「ア」に対応するデータキュー６０５に格納する。

以上説明したように、格納処理部６４０では、検索処理部６３０によって検索されたトランザクションデータを各処理ノードによって実行させるための前処理が行われる。すなわち、格納処理部６４０では、並列実行させる処理として検索された各トランザクションデータを、実際に各処理ノードによって実行させるためのデータキュー６０５に振り分けることができる。

＜ディスパッチ処理部＞
図１４は、ディスパッチ処理部の処理手順を示すフローチャートである。ディスパッチ処理部６５０では、データキュー６０５に格納されたトランザクションを対象となる処理ノードによって実行させるディスパッチ機能を有する。

ディスパッチ処理部６５０は、まず、データキュー６０５からつぎの処理ステップで実行するデータをすべて抽出する（ステップＳ１４０１）。したがって、処理ノード「ア」、処理ノード「イ」、処理ノード「ウ」に対応したデータキュー６０５のうち、つぎの処理ステップで実行するデータが格納されているデータキュー６０５から実際の処理に用いるデータ、すなわち、トランザクションデータを抽出する。

つぎに、ディスパッチ処理部６５０は、データキュー６０５から抽出したトランザクションデータを、各処理ノードにディスパッチする（ステップＳ１４０２）。最後に、ディスパッチ処理部６５０は、各処理ノードのデータキューにディスパッチされたデータを一旦保持させ、各処理ノードによる順次処理を可能にして（ステップＳ１４０３）、一連の処理を終了する。

以上説明したように、ディスパッチ処理部６５０によって、データキュー６０５に格納されたトランザクションデータを、共通のタイミングで、各処理ノードにディスパッチさせることができる。したがって、各処理ノードによる並列処理を実現することができる。

（本実施の形態にかかる分散処理方法の適用シーン）
以上説明したように、本実施の形態にかかる分散処理方法は、ニアリアルタイム性を求められるマスタ系データの更新処理において、特にその効果を発揮する。具体的には、たとえば、ホテル、乗り物、その他イベントなどのチケットのオンライン予約システムへの適用が挙げられる。

チケット予約システムの場合、人気の高い部屋や座席など同一のレコードへのアクセスが集中する。従来の負荷分散方法の場合、同一レコードへのアクセスの集中によって発生したロック状態がシステム全体に影響を及ぼしていた。すなわち、人気薄の部屋や座席などの予約に関しての処理要求も、アクセスの集中によるロック状態によって処理負荷以上の待機時間が発生する事態があった。

そこで、本実施の形態にかかる分散処理方法を適用することによって、アクセスの集中によるロック状態が回避される。また、人気薄の部屋や座席などの予約に関しての処理要求に関しては、アクセスが集中するレコードとの排他性が高いため、順次処理ノードに振り分けられる。したがって、ロック状態の回避によってシステム全体の処理性能を維持するとともに、人気薄の部屋や座席などの予約に関しての処理要求に関しては、待機時間の短縮が期待できる。

その他にも、複数の取引先からの処理要求を受け付けるオンラインの在庫引当システムに本実施の形態にかかる分散処理方法を適用してもよい。在庫引当システムの場合も、予約システムと同様に、人気商品とそれ以外の商品とでは、処理要求の頻度が異なる。したがって、人気商品への処理要求が集中してもロック状態を起こすことなくデータベースへの並列処理を実現することによって、システム全体の処理効率の向上が期待できる。

なお、本実施の形態で説明した分散処理方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本分散処理プログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本分散処理プログラムは、インターネット等のネットワークを介して配布してもよい。

１００ ネットワークシステム
１０１ 分散処理装置
１１０ データベース
３０１ 受付部
３０２ 検出部
３０３ 生成部
３０４ 選択部
３０５ 検索部
３０６ 決定部
３０７ 割当部
６００ フォワードプロキシ装置
６０１ 電文
６０２ 順編成ファイル
６０３ トラン・アイテムテーブル
６０４ 振分前データテーブル
６０５ データキュー
６１０ トランザクション取得処理部
６２０ 排他アイテム追加処理部
６３０ 検索処理部
６４０ 格納処理部
６５０ ディスパッチ処理部
Ｃ クライアント装置
Ｎ１〜Ｎｎ ノード

Claims (7)

1. 複数のレコードを格納するデータベースに対する処理を並列に実行可能な複数のノードに、前記データベースに対する処理群を割り当てる分散処理装置であって、
   前記各レコードを特定するための属性名に基づいて、前記処理群から選ばれた第１の処理の処理要求に含まれる属性名とは異なる他の属性名のレコードを処理対象とする第２の処理を前記処理群から検索する検索手段と、
   前記検索手段によって前記第２の処理が検索された場合、前記第１および第２の処理を前記複数のノードに実行させる実行対象に決定する決定手段と、
   前記決定手段によって決定された実行対象を前記複数のノードに割り当てる割当手段と、
   を備えることを特徴とする分散処理装置。
2. 前記検索手段は、
   さらに、前記決定手段によって決定された実行対象の処理要求に含まれる属性名とは異なる他の属性名のレコードを処理対象とする第３の処理を前記処理群から検索し、
   前記決定手段は、
   前記検索手段によって前記第３の処理が検索された場合、さらに、前記第３の処理を前記実行対象に決定することを特徴とする請求項１に記載の分散処理装置。
3. 前記割当手段は、
   前記検索手段によって前記第３の処理が検索されなかった場合、前記決定手段によって決定された実行対象を前記複数のノードに割り当てることを特徴とする請求項２に記載の分散処理装置。
4. 前記データベースに対する処理の処理要求を受け付ける受付手段と、
   前記各レコードを特定するための属性名ごとに、前記受付手段によって受け付けた処理要求に当該属性名が含まれているか否かを示すビット列を生成する生成手段と、をさらに備え、
   前記検索手段は、
   前記生成手段によって生成された前記処理要求ごとのビット列に基づいて、前記第１の処理の処理要求に含まれる属性名が含まれているか否かを示すビットの値が前記第１の処理の処理要求とは異なる処理を前記第２の処理として前記処理群から検索することを特徴とする請求項２または３に記載の分散処理装置。
5. 前記検索手段は、
   前記処理要求ごとのビット列に基づいて、前記実行対象の処理要求に含まれる属性名が含まれているか否かを示すビットの値が前記実行対象の処理要求とは異なる処理を前記第３の処理として前記処理群から検索することを特徴とする請求項４に記載の分散処理装置。
6. 複数のレコードを格納するデータベースに対する処理を並列に実行可能な複数のノードに、前記データベースに対する処理群を割り当てるコンピュータを、
   前記各レコードを特定するための属性名に基づいて、前記処理群から選ばれた第１の処理の処理要求に含まれる属性名とは異なる他の属性名のレコードを処理対象とする第２の処理を前記処理群から検索する検索手段、
   前記検索手段によって前記第２の処理が検索された場合、前記第１および第２の処理を前記複数のノードに実行させる実行対象に決定する決定手段、
   前記決定手段によって決定された実行対象を前記複数のノードに割り当てる割当手段、
   として機能させることを特徴とする分散処理プログラム。
7. 複数のレコードを格納するデータベースに対する処理を並列に実行可能な複数のノードに、前記データベースに対する処理群を割り当てるコンピュータが、
   前記各レコードを特定するための属性名に基づいて、前記処理群から選ばれた第１の処理の処理要求に含まれる属性名とは異なる他の属性名のレコードを処理対象とする第２の処理を前記処理群から検索する検索工程と、
   前記検索工程によって前記第２の処理が検索された場合、前記第１および第２の処理を前記複数のノードに実行させる実行対象に決定する決定工程と、
   前記決定工程によって決定された実行対象を前記複数のノードに割り当てる割当工程と、
   を実行することを特徴とする分散処理方法。

Images