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

分散処理装置、分散処理プログラムおよび分散処理方法 Download PDF

Info

Publication number
JP2011215924A
JP2011215924A JP2010083901A JP2010083901A JP2011215924A JP 2011215924 A JP2011215924 A JP 2011215924A JP 2010083901 A JP2010083901 A JP 2010083901A JP 2010083901 A JP2010083901 A JP 2010083901A JP 2011215924 A JP2011215924 A JP 2011215924A
Authority
JP
Japan
Prior art keywords
processing
nodes
attribute name
record
transaction
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.)
Granted
Application number
JP2010083901A
Other languages
English (en)
Other versions
JP5640432B2 (ja
Inventor
Ken Takahashi
謙 高橋
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2010083901A priority Critical patent/JP5640432B2/ja
Priority to US13/073,083 priority patent/US8560560B2/en
Publication of JP2011215924A publication Critical patent/JP2011215924A/ja
Application granted granted Critical
Publication of JP5640432B2 publication Critical patent/JP5640432B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F7/00Methods or arrangements for processing data by operating upon the order or content of the data handled
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2453Query optimisation
    • G06F16/24532Query optimisation of parallel queries
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computational Linguistics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

【課題】データベース内の同一レコードへの同時アクセスを抑制すること。
【解決手段】ネットワークシステム100において、分散処理装置101は、データベース110に対する処理をクライアント装置Cから受け付ける。分散処理装置101は、受け付けた処理群をノードN1〜Nnに分散処理させる際に、同じ属性名のレコードを処理対象とする処理同士を同一タイミングでノードN1〜Nnに割り当てないように調整する。これにより、データベース110内の同一レコードへの同時アクセスを防ぎ、データベース110に対するアクセスの排他制御にともなうロック解放待ちを減らして、ネットワークシステム100の性能劣化を回避する。
【選択図】図1

Description

この発明は、複数のノードに処理群を分散する分散処理装置、分散処理プログラムおよび分散処理方法に関する。
近年、クラウドコンピューティングなどにおいて、データベースへの処理要求を複数の要求元から行うシステムが普及している。要求元とする複数のクライアントから共通のサーバへの処理要求を受け付けるシステムの場合、受け付けた処理要求を実行する処理ノードも複数個用意されている。
ところが、複数の処理要求を単純に複数の処理ノードによって実行させるシステムを用意しても、処理要求からは処理ノードの実行状況を把握できず、特定の処理ノードにばかり処理要求が集中する可能性がある。そこで、複数のクライアントからの処理要求を一元的に受け付けるフォワードプロキシ装置を利用する技術が提供されている。
フォワードプロキシ装置は、受け付けた処理要求を複数の処理ノードに均等に振り分けて、負荷を分散する。また、フォワードプロキシ装置を用意することによって、クライアントなどの処理要求元が要求した処理をどの処理ノードで実行しているか把握させることによって、複製透過性や位置透過性を担保する(たとえば、下記特許文献1参照。)。
特許第2586219号明細書
従来のフォワードプロキシ装置の場合、受け付けた処理要求を処理ノードに振り分ける際、処理要求の個数が判断基準となっていた。たとえば、処理要求が振り分けられていない空き状態の処理ノードや、実行待ちの処理要求の数が他の処理ノードよりも少ない処理ノードに優先的に処理要求が割り振られる。
ところが、処理ノードに振り分けられた処理要求は、実際に処理ノードによって実行させた際に、共通のデータベースの中のいずれのレコードにアクセスするかについては考慮されていない。すなわち、異なる処理ノードによって実行された処理要求が、共有のデータベース内の同一のレコードにアクセスする可能性がある。同一のレコードへのアクセスが集中すると、一の処理ノードによって実行している処理要求が終了するまで、他の処理ノードはロック状態となる。この結果、他の処理ノードはロック状態から解放されるまで処理を実行できず、ロック状態の解放待ちによる処理性能の低下を招くという問題があった。
本発明は、上述した従来技術による問題点を解消するため、データベース内の同一レコードへの同時アクセスを抑制することができる分散処理装置、分散処理プログラムおよび分散処理方法を提供することを目的とする。
上述した課題を解決し、目的を達成するため、開示の分散処理装置は、複数のレコードを格納するデータベースに対する処理を並列に実行可能な複数のノードに、前記データベースに対する処理群を割り当てる分散処理装置であって、前記各レコードを特定するための属性名に基づいて、前記処理群から選ばれた第1の処理の処理要求に含まれる属性名とは異なる他の属性名のレコードを処理対象とする第2の処理を前記処理群から検索し、前記第2の処理が検索された場合、前記第1および第2の処理を前記複数のノードに実行させる実行対象に決定し、決定された実行対象を前記複数のノードに割り当てることを要件とする。
本分散処理装置、分散処理プログラムおよび分散処理方法によれば、データベース内の同一レコードへの同時アクセスを抑制することができるという効果を奏する。
本実施の形態にかかるネットワークシステムの一実施例を示すシステム構成図である。 分散処理装置のハードウェア構成を示すブロック図である。 本実施の形態にかかる分散処理装置の機能的構成を示すブロック図である。 本実施の形態にかかる分散処理装置の分散処理手順の一例を示すフローチャートである。 処理対象となるデータの一例を示すデータテーブルである。 本実施の形態にかかる分散処理装置を適用したフォワードプロキシ装置を示す説明図である。 各形式の電文およびスキーマ取得例を示す説明図である。 排他アイテム名の定義例を示すデータテーブルである。 トランザクション取得処理部の処理手順を示すフローチャートである。 排他アイテム追加処理部の処理手順を示すフローチャートである。 トラン・アイテムキャッシュテーブルの一例を示すデータテーブルである。 トラン・アイテムキャッシュテーブルへの排他アイテムビット列の追加例を示す説明図である。 検索処理部の処理手順を示すフローチャートである。 処理ノードごとの排他識別レジスタの設定例を示す説明図である。 排他識別レジスタ更新後のトラン・アイテムキャッシュテーブル削除例を示す説明図である。 格納処理部の処理手順を示すフローチャートである。 ディスパッチ処理部の処理手順を示すフローチャートである。
以下に添付図面を参照して、この発明にかかる分散処理装置、分散処理プログラムおよび分散処理方法の好適な実施の形態を詳細に説明する。
図1は、本実施の形態にかかるネットワークシステムの一実施例を示すシステム構成図である。図1において、ネットワークシステム100は、分散処理装置101と、クライアント装置Cと、複数のノードN1〜Nnと、データベース110と、を含む構成である。ネットワークシステム100において、分散処理装置101と、クライアント装置Cと、複数のノードN1〜Nnと、データベース110とは、有線または無線のネットワーク120を介して接続されている。
分散処理装置101は、データベース110に対する処理群を複数のノードN1〜Nnに割り当てる。クライアント装置Cは、データベース110に対する処理の処理要求を分散処理装置101に送信する。ノードN1〜Nnは、分散処理装置101から割り当てられた処理を実行するコンピュータである。また、ノードN1〜Nnは、データベース110に対する処理を並列に実行可能である。
ネットワークシステム100において、分散処理装置101は、データベース110に対する処理群をノードN1〜Nnに分散処理させる際に、同じ属性名のレコードを処理対象とする処理同士を同一タイミングでノードN1〜Nnに割り当てない。属性名とは、データベース110内のレコードを特定するための属性情報である。これにより、データベース110内の同一レコードへの同時アクセスを防ぎ、同一レコードに対するアクセスの排他制御にともなうロック解放待ちを減らして、ネットワークシステム100の性能劣化を回避する。
(分散処理装置101のハードウェア構成)
図2は、分散処理装置のハードウェア構成を示すブロック図である。図2において、分散処理装置101は、CPU(Central Processing Unit)201と、ROM(Read‐Only Memory)202と、RAM(Random Access Memory)203と、磁気ディスクドライブ204と、磁気ディスク205と、光ディスクドライブ206と、光ディスク207と、ディスプレイ208と、I/F(Interface)209と、キーボード210と、マウス211と、スキャナ212と、プリンタ213と、を備えている。また、各構成部はバス200によってそれぞれ接続されている。
ここで、CPU201は、分散処理装置101の全体の制御を司る。ROM202は、ブートプログラムや分散処理プログラムなどの各種プログラムを記憶している。RAM203は、CPU201のワークエリアとして使用される。磁気ディスクドライブ204は、CPU201の制御にしたがって磁気ディスク205に対するデータのリード/ライトを制御する。磁気ディスク205は、磁気ディスクドライブ204の制御で書き込まれたデータを記憶する。
光ディスクドライブ206は、CPU201の制御にしたがって光ディスク207に対するデータのリード/ライトを制御する。光ディスク207は、光ディスクドライブ206の制御で書き込まれたデータを記憶したり、光ディスク207に記憶されたデータをコンピュータに読み取らせたりする。
ディスプレイ208は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。このディスプレイ208は、たとえば、CRT、TFT液晶ディスプレイ、プラズマディスプレイなどを採用することができる。
I/F209は、通信回線を通じてLAN(Local Area Network)、WAN(Wide Area Network)、インターネットなどのネットワーク120に接続され、このネットワーク120を介して他の装置に接続される。そして、I/F209は、ネットワーク120と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。I/F209には、たとえばモデムやLANアダプタなどを採用することができる。
キーボード210は、文字、数字、各種指示などの入力のためのキーを備え、データの入力を行う。また、タッチパネル式の入力パッドやテンキーなどであってもよい。マウス211は、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などを行う。ポインティングデバイスとして同様に機能を備えるものであれば、トラックボールやジョイスティックなどであってもよい。
スキャナ212は、画像を光学的に読み取り、分散処理装置101内に画像データを取り込む。なお、スキャナ212は、OCR(Optical Character Reader)機能を持たせてもよい。また、プリンタ213は、画像データや文書データを印刷する。プリンタ213には、たとえば、レーザプリンタやインクジェットプリンタを採用することができる。なお、ここでは分散処理装置101のハードウェア構成について説明したが、図1に示したクライアント装置C、ノードN1〜Nnについても同様のハードウェア構成を備える。
(分散処理装置101の機能的構成)
つぎに、実施の形態にかかる分散処理装置101の機能的構成について説明する。図3は、本実施の形態にかかる分散処理装置の機能的構成を示すブロック図である。図3において、分散処理装置101は、受付部301と、検出部302と、生成部303と、選択部304と、検索部305と、決定部306と、割当部307と、を含む構成である。各機能部(受付部301〜割当部307)は、具体的には、たとえば、図2に示したROM202、RAM203、磁気ディスク205、光ディスク207などの記憶装置に記憶されたプログラムをCPU201に実行させることにより、または、I/F209により、その機能を実現する。なお、各機能部(受付部301〜割当部307)の処理結果は、たとえば、RAM203、磁気ディスク205、光ディスク207などの記憶装置に記憶される。
受付部301は、データベース110に対する処理を要求する処理要求をクライアント装置Cから受け付ける機能を有する。ここで、データベース110は、ノードN1〜Nnがアクセス可能な共有データベースである。データベース110に対する処理としては、たとえば、データベース110に格納されているレコードの更新処理、参照処理および書込処理などがある。
また、処理要求は、たとえば、データベース110に対する処理を要求する電文や順編成ファイルである。処理要求は、一つの処理を要求するものでもよく、また、トランザクションやバッチジョブのように複数の処理を要求するものでもよい。処理要求は、たとえば、XML(eXtensible Markup Language)等のスキーマ構造が定義済みの電文(データ)を用いて記述されている。たとえば、処理要求には、処理対象となるデータのほか、該データを含むレコードを特定するための属性名が含まれている。
属性名は、データベース110に格納されているレコードを特定するための属性情報である。属性名は、たとえば、レコードに含まれる各データの項目名(フィールド名)や、各レコードを含むファイル(テーブル)のファイル名(テーブル名)などである。一つのレコードを特定するための属性名として、たとえば、ファイル名と項目名の組み合わせを設定してもよく、また、複数の項目名を設定してもよい。
レコードを特定するための属性名は、たとえば、予め設定されてROM202、RAM203、磁気ディスク205、光ディスク207などの記憶装置に記憶されている。ただし、属性名は、データベース110に格納されている全レコードについて設定してもよく、また、ノードN1〜Nnからの同時アクセスを抑制したい特定のレコードについてのみ設定してもよい。
以下の説明では、データベース110内のレコードを「レコードR1〜Rm」と表記し、各レコードR1〜Rmを特定するための属性名を「属性名A1〜Am」と表記する。また、レコードR1〜Rmのうち任意のレコードを「レコードRj」と表記し、属性名A1〜Amのうち任意の属性名を「Aj」と表記する(j=1,2,…,m)。
検出部302は、受け付けた処理要求の中から属性名を検出する機能を有する。具体的には、たとえば、検出部302が、処理要求のデータ形式にしたがって、処理要求の中から属性名を表す文字列(たとえば、タグに囲まれた文字列)を検出する。処理要求のデータ形式としては、たとえば、XML要素形式やXML属性形式などがある。
生成部303は、検出された検出結果に基づいて、レコードRjを特定するための属性名Ajごとに、受け付けた処理要求に属性名Ajが含まれているか否かを示すビット列を生成する機能を有する。具体的には、たとえば、生成部303が、属性名Ajごとに、処理要求に属性名Ajが含まれている場合は「1」、属性名Ajが含まれていない場合は「0」を示すビット列を生成する。このため、予め設定された属性名Ajの総数がm個の場合、ビット列はmビットとなる。
一例として、「m=5」とし、受け付けた処理要求に属性名A3が含まれている場合を説明する。この場合、各属性名A1〜A5が処理要求に含まれているか否かを示すビット列は、属性名A1〜A5の順に「00100」となる。ビット列によれば、各処理要求に含まれている属性名Aj(上記例では属性名A3)を容易に特定することができる。
選択部304は、データベース110に対する処理群の中から第1の処理を選択する機能を有する。ここで、データベースに対する処理群とは、処理要求を受け付けた処理のうち未実行の処理の集合である。以下の説明では、データベース110に対する処理群を「処理群T1〜TK」と表記し、処理群T1〜TKのうち任意の処理を「処理Tk」と表記する(k=1,2,…,K)。
具体的には、たとえば、選択部304が、処理群T1〜TKのうち処理要求を受け付けた時刻が最も古い処理を第1の処理として選択してもよい。また、選択部304が、各処理T1〜TKに予め付与されている優先度が、処理群T1〜TKの中で最大となる処理Tkを第1の処理として選択することにしてもよい。
検索部305は、各レコードRjを特定するための属性名Ajに基づいて、選択された第1の処理の処理要求に含まれる属性名とは異なる他の属性名のレコードを処理対象とする第2の処理を処理群T1〜TKから検索する機能を有する。具体的には、たとえば、検索部305が、生成された処理Tkごとのビット列に基づいて、第1の処理の処理要求に含まれる属性名と同一の属性名を含まない処理を第2の処理として検索する。
一例として、第1の処理のビット列を「10000」とする。この場合、検索部305が、処理群T1〜TKの中から、少なくともビット列の1番目のビットが「0」となる処理Tkを第2の処理として検索する。この際、検索部305が、ビット列の1番目のビットが「0」となり、かつ、処理群T1〜TKのうち処理要求を受け付けた時刻が最も古い処理Tkを第2の処理として検索してもよい。
決定部306は、第2の処理が検索された場合、第1および第2の処理をノードN1〜Nnに実行させる実行対象に決定する機能を有する。ここで、第1および第2の処理は、処理要求に含まれる属性名が互いに異なるため、処理対象となるレコードが異なる。したがって、ノードN1〜Nnが第1および第2の処理を同時に実行したとしても、同一レコードに対するアクセスは発生しない。
また、検索部305は、決定された実行対象の処理要求に含まれる属性名とは異なる他の属性名のレコードを処理対象とする第3の処理を処理群T1〜TKから検索する。具体的には、たとえば、検索部305が、生成された処理Tkごとのビット列に基づいて、実行対象の処理要求に含まれる属性名と同一の属性名を含まない処理を第3の処理として検索する。また、検索部305による第3の処理を検索する検索処理は、たとえば、後述する決定部306によって決定される実行対象の処理数Xが、ノードN1〜Nnのノード数nとなるまで繰り返し実行される。すなわち、『X=n』の条件を満たすまで、ノード数nから上記第1および第2の処理の2つの処理数を除く、最大で(n−2)個の『第3の処理』が検索される。
一例として、実行対象として2つの処理が決定されており、各処理のビット列を「10000」および「01000」とする。この場合、検索部305が、処理群T1〜TKの中から、少なくともビット列の1番目のビットが「0」となり、かつ、2番目のビットが「0」となる処理Tkを第3の処理として検索する。この際、検索部305が、ビット列の1番目および2番目のビットが「0」となり、かつ、処理群T1〜TKのうち処理要求を受け付けた時刻が最も古い処理Tkを第3の処理として検索してもよい。
また、決定部306は、第3の処理が検索された場合、さらに、第3の処理を実行対象に決定することにしてもよい。また、決定部306は、割当先となるノードNiと対応付けて実行対象となる処理を決定することにしてもよい。
割当部307は、決定された実行対象をノードN1〜Nnに割り当てる機能を有する。具体的には、たとえば、割当部307が、決定された実行対象の処理の処理要求を割当先となるノードNiに送信する。この際、割当部307は、実行対象となる処理が複数存在する場合、実行対象となる各処理をそれぞれ異なるノードNiに振り分けて割り当てる。この結果、複数のノードN1〜Nnにおいて、実行対象の複数の処理が並列に実行されることになる。
また、割当部307は、上記検索部305によって第3の処理が検索されなかった場合、決定された実行対象をノードN1〜Nnに割り当てることにしてもよい。すなわち、既に決定された実行対象の処理と異なるレコードを処理対象とする処理が処理群T1〜TKの中に存在しないため、この時点で、割当部307が、決定された実行対象をノードN1〜Nnに割り当てる。
また、割当部307は、決定された実行対象の処理数Xが、ノードN1〜Nnのノード数nとなった場合、決定された実行対象をノードN1〜Nnに割り当てることにしてもよい。すなわち、これ以上、実行対象となる処理を決定しても割当先となるノードNiが存在しないため、この時点で、割当部307が、決定された実行対象をノードN1〜Nnに割り当てる。
(分散処理装置101の分散処理手順)
つぎに、本実施の形態にかかる分散処理装置101の分散処理手順について説明する。図4は、本実施の形態にかかる分散処理装置の分散処理手順の一例を示すフローチャートである。図4のフローチャートにおいて、まず、選択部304により、データベース110に対する処理群T1〜TKの中から第1の処理を選択する(ステップS401)。
つぎに、選択部304により、第1の処理が選択されたか否かを判断する(ステップS402)。ここで、第1の処理が選択された場合(ステップS402:Yes)、検索部305により、処理群T1〜TKの中から、第1の処理の処理要求に含まれる属性名とは異なる他の属性名のレコードを処理対象とする第2の処理を検索する(ステップS403)。
そして、検索部305により、第2の処理が検索されたか否かを判断する(ステップS404)。ここで、第2の処理が検索された場合(ステップS404:Yes)、決定部306により、第1および第2の処理をノードN1〜Nnに実行させる実行対象に決定する(ステップS405)。
つぎに、決定部306により、決定された実行対象の処理数XがノードN1〜Nnのノード数nとなったか否かを判断する(ステップS406)。ここで、処理数Xがノード数nとなっていない場合(ステップS406:No)、検索部305により、処理群T1〜TKの中から、決定された実行対象の処理要求に含まれる属性名とは異なる他の属性名のレコードを処理対象とする第3の処理を検索する(ステップS407)。
そして、検索部305により、第3の処理が検索されたか否かを判断する(ステップS408)。ここで、第3の処理が検索された場合(ステップS408:Yes)、決定部306により、さらに、第3の処理をノードN1〜Nnに実行させる実行対象に決定して(ステップS409)、ステップS406に戻る。
一方、第3の処理が検索されなかった場合(ステップS408:No)、割当部307により、ノードN1〜Nnに決定された実行対象を割り当てて(ステップS410)、ステップS401に戻る。また、ステップS404において、第2の処理が検索されなかった場合(ステップS404:No)、割当部307により、ノードN1〜Nnに決定された実行対象を割り当てて(ステップS410)、ステップS401に戻る。
また、ステップS406において、処理数Xがノード数nとなった場合(ステップS406:Yes)、割当部307により、ノードN1〜Nnに決定された実行対象を割り当てて(ステップS410)、ステップS401に戻る。
そして、ステップS402において、第1の処理が選択されなかった場合は(ステップS402:No)、本フローチャートによる一連の処理を終了する。すなわち、分散対象となる処理Tkが存在しないため、分散処理装置101による分散処理の実行を終了する。また、ステップS404において、第2の処理が検索されなかった場合(ステップS404:No)、決定部306により、第1の処理をノードN1〜Nnに実行させる実行対象に決定して(ステップS411)、ステップS410に移行する。
以上説明したように、本実施の形態にかかる分散処理装置101によれば、データベース110内の各レコードR1〜Rmを特定するための属性名A1〜Amに基づいて、処理対象のレコードが、第1の処理と異なる第2の処理を処理群T1〜TKから検索できる。また、分散処理装置101によれば、第2の処理が検索された場合、第1および第2の処理を実行対象に決定して、ノードN1〜Nnに割り当てることができる。これにより、同一レコードに対するアクセスの競合が発生しない第1および第2の処理を並列実行させることができる。
また、分散処理装置101によれば、処理対象のレコードが、決定された実行対象とは異なる第3の処理を処理群T1〜TKから検索して、さらに、第3の処理を実行対象に決定することができる。これにより、同一レコードに対するアクセスの競合が発生しない第3の処理をさらに並列実行させることができる。
また、分散処理装置101によれば、第3の処理が検索されなかった場合に、決定された実行対象を複数のノードN1〜Nnに割り当てることにしてもよい。これにより、処理対象のレコードが、既に決定された実行対象と異なる処理が存在しなくなった時点で、実行対象をノードN1〜Nnに割り当てることができる。これにより、ノードN1〜Nnに処理群T1〜TKを分散処理させる際の効率化を図ることができる。
また、分散処理装置101によれば、レコードRjを特定するための属性名Ajが含まれているか否かを示す処理要求ごとのビット列に基づいて、第2または第3の処理を検索することができる。これにより、各処理要求に含まれている属性名Ajを容易に特定でき、第2または第3の処理を検索する検索処理の効率化を図ることができる。
これらのことから、分散処理装置101によれば、処理群T1〜TKをノード群N1〜Nnに分散処理させる際に、同じ属性名のレコードを処理対象とする処理同士を同一タイミングで割り当てないことで、同一レコードへの同時アクセスを防ぐことができる。この結果、データベース110に対するアクセスの排他制御にともなうロック解放待ちを減らして、ネットワークシステム100のスループットを向上させることができる。
つぎに、本実施の形態にかかる分散処理装置101の実施例について説明する。ここでは、分散処理装置101をフォワードプロキシ装置600に適用した場合を例に挙げて、具体的なトランザクションデータの分散処理について説明する。
図5は、処理対象となるデータの一例を示すデータテーブルである。また、図6は、本実施の形態にかかる分散処理装置を適用したフォワードプロキシ装置を示す説明図である。フォワードプロキシ装置600(図6参照)では、図5のデータテーブル500に示すような、エンティティと属性とが設定されたトランザクションデータを取得して、各処理ノードに実行させる。すなわち、フォワードプロキシ装置600が扱うトランザクションデータの場合、データテーブル500が表している属性に基づいてデータベース内の1レコードが構成されていることを意味する。なお、トランザクションデータは、上述した処理の処理要求に相当する。
図6に例示したフォワードプロキシ装置600は、共通のデータベースへの処理を要求するトランザクションデータを一括して取得して、共通のデータベースへの並列処理が可能な各処理ノード、たとえば、後述する図14に示すような、「ア」、「イ」、「ウ」の各処理ノードへ振り分ける機能を有している。なお、処理ノード「ア」、「イ」、「ウ」は、上述したノードN1〜NnのいずれかのノードNiに相当する。
トランザクションデータとしては、たとえば、オンラインクライアントから入力された電文601や、バッチジョブのバッチファイルとして入力される順編成ファイル602などが挙げられる。フォワードプロキシ装置600は、共通のデータベースへの処理要求として、上述のようなトランザクションデータを取得すると、トランザクションデータを一旦装置内に格納する。そして、格納済みのトランザクションデータの中の未処理のトランザクションデータを各処理ノードに振り分けて、並列処理を実行させる。
特に、フォワードプロキシ装置600の場合、各処理ノードが並列処理を行う際に、同一のレコードが処理対象として設定されないようなトランザクションデータを抽出して、それぞれ実行させる処理ノードを振り分ける。すなわち、並列処理される各トランザクションデータは、処理対象となるレコードにそれぞれ排他性が保たれている。
フォワードプロキシ装置600によってトランザクションデータが振り分けられた各処理ノードであれば、並列処理を実行中に共通のデータベース内の同一のレコードへのアクセスが重複することはない。したがって、従来の負荷分散装置のような、同一のレコードへのアクセス集中によるロック状態の発生を防ぎ、いずれかの処理ノードが待機中となり処理効率を低下させるような事態を回避することができる。
具体的な構成について説明すると、フォワードプロキシ装置600は、上述した分散処理装置101を実現するための機能部として、トランザクション取得処理部610と、排他アイテム追加処理部620と、検索処理部630と、格納処理部640と、ディスパッチ処理部650とを備えている。
トランザクション取得処理部610は、分散処理装置101の受付部301に相当する。トランザクション取得処理部610を用意することによって、複数のレコードを格納するデータベースに対する処理を一括して受け付けることができる。また、排他アイテム追加処理部620は、分散処理装置101の検出部302および生成部303に相当する。排他アイテム追加処理部620によって、トランザクションデータごとに、アクセス先となるレコードを特定するための属性名を表すビット列を生成することができる。
また、検索処理部630は、分散処理装置101の選択部304および検索部305に相当する。フォワードプロキシ装置600では、任意のトランザクションデータもしくは、最も古いトランザクションデータを第1の処理として、他のトランザクションデータから第2の処理を検索する。また、格納処理部640は、分散処理装置101の決定部306に相当する。また、各処理ノードにおけるトランザクションデータの実行については、ディスパッチ処理部650によって制御される。なお、各機能部の詳細な処理内容については後述する。
また、フォワードプロキシ装置600には、各種データを記憶する記憶領域として、トラン・アイテムテーブル603と、振分前データテーブル604と、処理ノードごとのデータキュー605とが用意されている。各記憶領域の役割についても関連する機能部の説明に合わせて詳しく後述する。なお、トラン・アイテムテーブル603内には、高速アクセス可能なトラン・アイテムキャッシュテーブルおよび排他識別レジスタが用意されている。
<データ構成>
ここで、フォワードプロキシ装置600による負荷分散処理の説明に入る前に、フォワードプロキシ装置600に入力されるトランザクションデータのデータ構成について説明する。フォワードプロキシ装置600では、取得したトランザクションデータに含まれている情報に基づいて、トランザクションデータを処理する際にアクセスするレコードが特定される。上述したように、各処理ノードが共通のデータベースに対して並列処理を行う場合には、各処理ノードがそれぞれ処理を実行する際に、アクセスするレコードが重複しないようなトランザクションデータを振り分けなければならない。
そこで、フォワードプロキシ装置600は、取得したトランザクションデータの中から、処理実行時にアクセスするレコードを特定するための情報を参照して、予めどのレコードへアクセスが発生するかを表す情報を用意しておく。具体的には、フォワードプロキシ装置600は、取得したトランザクションのデータ形式に基づいて、データテーブル500(図5参照)に挙げられたエンティティのいずれのデータが処理対象となるかを特定する。そして、特定された処理対象となるデータに応じて、トランザクションデータを処理ノードによって実行する際に、アクセスされるレコードを特定することができる。
ここで、図7は、各形式の電文およびスキーマ取得例を示す説明図である。図7のデータ列700は、フォワードプロキシ装置600に入力される電文601の形式の具体例と、データ形式ごとの電文601の表示内容の仕様を意味するスキーマとを表している。図7のデータ列700では、電文601の形式として、(A)XML要素形式と、(B)XML属性形式と、(C)CSV(Comma Separated Values)形式とが挙げられている。いずれの形式の電文601も、学生構成テーブル学校ID“JO1234”のレコードについて、総数を“183”名に更新するための処理が記されている。
そして、図8は、排他アイテム名の定義例を示すデータテーブルである。フォワードプロキシ装置600の場合、図8のデータ列800に示したような排他アイテム名リストが設定されている。排他アイテム名リストは、「学生構成」、「教職員構成」、「収入」、「支出」などが、それぞれ排他アイテム名として設定されている。各トランザクションデータは、各排他アイテム名のどの属性を表すデータが含まれているかに応じて、処理実行時にアクセスするテーブルを特定する。
具体的には、属性と各排他アイテム名とが同列に設定されているデータテーブル810を利用して、トランザクションデータに含まれる属性から排他アイテム名を一意的に特定することができる。すなわち、フォワードプロキシ装置600が図7のデータ列700に示したような電文601を取得すると、電文601に含まれる属性から排他アイテム名を特定する。また、排他アイテム名は、「学生構成」、「教職員構成」など、実際の名称ではなく、少ないビット数で識別できるように、下記のように識別子を設定しておく。
学生構成に関する属性811 →排他アイテム名A
教職員構成に関する属性812→排他アイテム名B
収入に関する属性813 →排他アイテム名C
支出に関する属性814 →排他アイテム名D
その他の任意の属性 →排他アイテム名E
上述したように、同じ排他アイテム名に設定される属性のデータであれば同じレコードに格納されていることを意味する。したがって、たとえば、学生構成に関する属性811のいずれかが含まれた電文601であれば、上記のような設定が行われている場合には、電文601は排他アイテム名Aを処理対象とすると特定される。また、電文601によって排他アイテム名A,Cを処理対象とするといったように複数の排他アイテム名が設定されている場合、当然のことながら、1つのトランザクションデータによって複数のレコードにアクセスが行われる。
<トランザクション取得処理部>
図9は、トランザクション取得処理部の処理手順を示すフローチャートである。図9のフローチャートに示すように、トランザクション取得処理部610は、共通のデータベースを処理対象とするトランザクションデータを取得する機能を有する。トランザクション取得処理部610は、オンラインクライアントやバッチジョブからのトランザクションデータ(たとえば、電文601や順編成ファイル602)の入力をトリガに処理を開始する。
図9のように、トランザクション取得処理部610では、事前処理として、排他対象を抽出するためのキーワードである「排他アイテム名」が設定されているか否かを判断する(ステップS901)。ステップS901において、排他アイテム名が設定されていないと判断された場合(ステップS901:No)、トランザクション取得処理部610は、設計者や上位システムからの指示を受け付けて、排他アイテム名を設定する(ステップS902)。
なお、フォワードプロキシ装置600の場合、ステップS902では、「排他アイテム名」としてA,B,C,D,Eの5個が設定される。また、ステップS901において、排他アイテム名が設定されていると判断された場合(ステップS901:Yes)、そのままステップS903の処理に移行する。
そして、トランザクション取得処理部610は、実際にトランザクションデータを取得したか否かを判断する(ステップS903)。ステップS903では、トランザクションデータを取得するまで待機状態となる(ステップS903:Noのループ)。ステップS903において、トランザクションデータを取得したと判断されると(ステップS903:Yes)、トランザクション取得処理部601は、トランザクションデータの排他条件逐次をチェックするための準備として、「排他アイテムビット列」を作成する(ステップS904)。
さらに、トランザクション取得処理部601は、ステップS904によって作成した「排他アイテムビット列」を排他識別ハッシュ値にエンコードし(ステップS905)、トランザクションIDを採番する(ステップS906)。なお、トランザクションIDは、他のトランザクションデータとの区別し、なおかつ、トランザクション取得処理部610による取得順序を特定する必要があるため通し番号が振られる。
「排他アイテムビット列」は、トランザクションデータを実行する際にアクセスされる排他アイテム名(レコード単位)を表している。したがって、たとえば、排他アイテム名「A,B,C,D,E」に対応した排他アイテムビット列が「01011」であれば、ビットが立っている排他アイテム名B,D,Eを参照するトランザクションデータであることを意味する。
そして、生成された排他アイテムビット列「01011」は、排他識別ハッシュ値にエンコードされ、10進表示の「11」となる。なお、本実施例では排他識別ハッシュ値として10進数化したものを例示するが、16進など排他アイテムビット列に戻すことが可能な表現であればどのようなものを用いてもよい。
その後、トランザクション取得処理部610は、ステップS906によって採番されたトランザクションIDをキーとして、ステップS905によってエンコードされた排他識別ハッシュ値をトラン・アイテムテーブル603に追加する(ステップS907)。また、トランザクション取得処理部610は、トランザクションIDをキーに取得したデータ(処理内容に相当するトランザクションデータ)を、振分前データテーブル604に格納する(ステップS908)。
そして、トランザクション取得処理部610は、あらたなトランザクションデータを取得したことによって、トラン・アイテムテーブル603と振分前データテーブル604が更新されたことを排他アイテム追加処理部620に通知して(ステップS909)、一連の処理を終了する。
以上説明したように、トランザクション取得処理部610は、共通のデータベースへの処理を行うトランザクションデータを一括して取得して、各処理ノードへ振り分ける前、振分前データテーブル604に一時的に格納する。同時に、トランザクション取得処理部610は、後段の処理によって、各処理ノードによって並列処理する際に、同一のレコードへのアクセスが競合しないようなトランザクションデータを振り分けるための、振り分け基準となる排他アイテムビット列を作成する。
また、トランザクション取得処理部610は、トランザクションデータから作成した排他アイテムビット列を排他識別ハッシュ値にエンコードしてトラン・アイテムテーブル603に格納している。エンコードによって、トランザクションデータごとの排他アイテムビット列の格納に要する容量が大幅に削減される。したがって、フォワードプロキシ装置600にトランザクションデータが集中してもオーバーフローを起こすことなく、効率的に振り分けることができる。
<排他アイテム追加処理部>
図10は、排他アイテム追加処理部の処理手順を示すフローチャートである。排他アイテム追加処理部620は、トランザクション取得処理部610によってあらたに取得したトランザクションデータを各処理ノードによって実行させるトランザクションデータとして、排他アイテムビット列とともに、トラン・アイテムキャッシュテーブルに追加する機能を有する。
排他アイテム追加処理部620は、まず、トラン・アイテムテーブル603から1レコードを抽出する(ステップS1001)。なお、ステップS1001の抽出処理は、トランザクション取得処理部610によるトラン・アイテムテーブル603と振分前データテーブル604が更新された旨の通知指示を受けた時、もしくは、トラン・アイテムキャッシュテーブルに空きがある時に行われる。当然のことながら、トランザクション取得処理部610からの通知指示を受けた場合であっても、トラン・アイテムキャッシュテーブルに空きがなければ、空きが発生するまで待機状態となる。
図11−1は、トラン・アイテムキャッシュテーブルの一例を示すデータテーブルである。上述したように、トラン・アイテムテーブル603には、図11−1に示す高速アクセス可能なトラン・アイテムキャッシュテーブルが用意されている。トラン・アイテムキャッシュテーブルには、トランザクションIDごとに、トランザクションIDに該当するトランザクションデータについて作成された排他アイテムビット列が格納されている。
つぎに、排他アイテム追加処理部620は、ステップS1001によって抽出したレコードの排他識別ハッシュ値をデコードし、排他アイテムビット列を生成する(ステップS1002)。すなわち、ステップS1002の処理によって、トランザクションIDと紐付いていた排他識別ハッシュ値(10進表示)が、ステップS904(図9参照)によって作成された排他アイテムビット列(2進表示)に戻される。
さらに、排他アイテム追加処理部620は、トランザクションIDをキーとして、ステップS1002によって生成された排他アイテムビット列をトラン・アイテムキャッシュテーブルに追加する(ステップS1003)。
図11−2は、トラン・アイテムキャッシュテーブルへの排他アイテムビット列の追加例を示す説明図である。たとえば、ステップS1002によって、トランザクションID:20に紐付いた排他識別ハッシュ値から排他アイテムビット列が生成されたとする。すると、ステップS1003の処理によって、トラン・アイテムキャッシュテーブルに図11−2に示すような排他アイテムビット列1120が追加される。
図10の説明に戻り、ステップS1003の処理が完了すると、排他アイテム追加処理部620は、ステップS1003の処理によってトラン・アイテムキャッシュテーブルが更新されたことを検索処理部630に通知して(ステップS1004)、一連の処理を終了する。
以上説明したように、排他アイテム追加処理部620は、あらたに取得したトランザクションデータの排他アイテムビット列をトランザクションIDと共に、トラン・アイテムキャッシュテーブルに追加する。トラン・アイテムキャッシュテーブルに格納されることによって、あらたに取得したトランザクションデータが、各処理ノードへの振り分け対象となるトランザクションデータの一つとして登録されたことを意味する。
<検索処理部>
図12−1は、検索処理部の処理手順を示すフローチャートである。検索処理部630は、排他識別レジスタを利用して、トラン・アイテムキャッシュテーブルに格納されているトランザクションIDの中から、処理ノード「ア」、「イ」、「ウ」によって並列処理を実行させるトランザクションデータのトランザクションIDを検索する機能を有する。
検索処理部630は、排他識別レジスタに設定する排他アイテムビット列を設定するため、まず、各処理ノード「ア」、「イ」、「ウ」によって実行させるトランザクションデータの検索条件を決定する(ステップS1201)。検索条件は、トラン・アイテムキャッシュテーブルに格納されている排他アイテムビット列に応じて一意的に決定する。具体的には、下記の2つが検索条件となる。
1)排他識別レジスタに既に設定されている排他アイテムビット列と共通の排他アイテム名のビットが立っていない(「0」が設定されている)。
2)トラン・アイテムキャッシュテーブルに格納されている排他アイテムビット列の中でもっとも古い。
そして、検索処理部630は、トラン・アイテムキャッシュテーブルから、ステップS1201によって決定された検索条件に当てはまるレコードを検索する(ステップS1202)。その後、検索処理部630は、ステップS1202によって検索されたレコードを各処理ノードに対応した排他識別レジスタに設定する(ステップS1203)。検索処理部630は、ステップS1203による排他識別レジスタの設定後、設定されたレコードをトラン・アイテムキャッシュテーブルから削除する(ステップS1204)。
図12−2は、処理ノードごとの排他識別レジスタの設定例を示す説明図である。図12−2を用いて、ステップS1201〜S1204の処理について具体例を挙げて説明する。図12−2のように、排他識別レジスタは、処理ノードごとに用意されている。検索処理部630は、まず、検索条件に基づいて、処理ノード「ア」に対応する排他識別レジスタに排他アイテムビット列を設定する。排他識別レジスタは、処理ノード「ア」から順に設定を行うため、まず、各排他識別レジスタが未設定の状態から処理が開始される。
したがって、処理ノード「ア」に対応する排他識別レジスタの排他アイテムビット列は、他の排他レジスタの排他アイテムビット列を参照する必要はないため、必然的に、トラン・アイテムキャッシュテーブルに格納されている最も古い排他アイテムビット列が設定される。なお、トランザクション取得処理部610の説明にて述べたように、トランザクションIDは、通し番号が振られている。
すなわち、トランザクションIDの値が最小となる排他アイテムビット列が最も古い排他アイテムビット列となる。したがって、処理ノード「ア」に相当する排他識別レジスタには、トランザクションID:1に相当する排他アイテムビット列が設定される。そして、排他アイテムビット列が設定されると、ステップS1204の処理によって、設定されたレコード(トランザクションID:1に相当する排他アイテムビット列)はトラン・アイテムキャッシュテーブルから削除される。
つぎに、処理ノード「イ」に対応する排他識別レジスタには、トラン・アイテムキャッシュテーブルに格納されている排他アイテムビット列の中から、設定済みの排他識別レジスタの各ビットと競合しない排他アイテムビット列を設定する。したがって、検索処理部630は、上述した検索条件の1),2)から該当する排他アイテムビット列を検索する。すなわち、最も古く、かつ、排他アイテム名D,Eを含まない排他アイテムビット列が検索される。結果として、処理ノード「イ」に対応する排他識別レジスタには、トランザクションID:3に相当する排他アイテムビット列が設定される。
なお、図12−2に例示した1段目の排他識別レジスタの場合、トラン・アイテムキャッシュテーブルの中から処理ノード「ア」、「イ」に対応する排他識別レジスタと排他アイテム名が競合しない排他アイテムビット列を検索することができなかった。したがって、処理ノード「ウ」に関しては、排他アイテムビット列を設定なしとして処理を終了する。
しかしながら、つぎの処理ステップを表す2段目の排他識別レジスタの場合、それぞれ排他識別レジスタと排他アイテム名が競合しない排他アイテムビット列を検索することができたため、処理ノード「ア」、「イ」、「ウ」のすべての排他アイテムビット列を設定して処理を終了する。
図12−3は、排他識別レジスタ更新後のトラン・アイテムキャッシュテーブル削除例を示す説明図である。図12−3のように、処理ノード「ア」、「イ」に対応する排他識別レジスタに排他アイテムビット列が設定されると、トラン・アイテムキャッシュテーブルの中からトランザクションID:1,3のレコード1220が削除される。
図12−1の説明に戻り、ステップS1204の処理と並列して、検索処理部630は、ステップS1203によって排他識別レジスタの設定後、つぎに各処理ノード「ア」、「イ」、「ウ」によって実行するトランザクションIDと処理ノード名とを格納処理部640に通知する(ステップS1205)。最後に、検索処理部630は、ステップS1205の通知後、排他識別レジスタの処理ステップをインクリメントして、レジスタを初期化し(ステップS1206)、一連の処理を終了する。
以上説明したように、検索処理部630は、排他識別レジスタを利用して、排他アイテム名が重複しないトランザクションデータを各処理ノードによって並列処理させるように設定することができる。また、トランザクションデータと実行させる処理ノードを設定する際に、トランザクションIDが若い、すなわち、古いトランザクションデータを優先的に設定するため、トランザクションデータの待機時間を最小限に抑えることができる。
<格納処理部>
図13は、格納処理部の処理手順を示すフローチャートである。格納処理部640は、検索処理部630からの通知結果に基づいて、振分前データテーブル604に格納されたトランザクション(電文601や順編成ファイル602)をデータキュー605に格納する機能を有する。
格納処理部640は、検索処理部630からの通知によって、トランザクションIDが指定されたか否かを判断する(ステップS1301)。トランザクションIDが指定されるまで待機状態となる(ステップS1301:Noのループ)。その後、トランザクションIDが指定されると(ステップS1301:Yes)、格納処理部640は、まず、振分前データテーブル604に格納されているトランザクションデータの中から、検索処理部630による通知で指定されたトランザクションIDに該当するトランザクションデータを抽出する(ステップS1302)。
つぎに、格納処理部640は、ステップS1302によって抽出したトランザクションデータを、検索処理部630からの通知によって指定された処理ノード名のデータキュー605に格納する(ステップS1303)。すなわち、トランザクションID:1の処理ノードとして処理ノード「ア」が指定された場合には、トランザクションID:1に該当するトランザクションデータを処理ノード「ア」に対応するデータキュー605に格納する。
以上説明したように、格納処理部640では、検索処理部630によって検索されたトランザクションデータを各処理ノードによって実行させるための前処理が行われる。すなわち、格納処理部640では、並列実行させる処理として検索された各トランザクションデータを、実際に各処理ノードによって実行させるためのデータキュー605に振り分けることができる。
<ディスパッチ処理部>
図14は、ディスパッチ処理部の処理手順を示すフローチャートである。ディスパッチ処理部650では、データキュー605に格納されたトランザクションを対象となる処理ノードによって実行させるディスパッチ機能を有する。
ディスパッチ処理部650は、まず、データキュー605からつぎの処理ステップで実行するデータをすべて抽出する(ステップS1401)。したがって、処理ノード「ア」、処理ノード「イ」、処理ノード「ウ」に対応したデータキュー605のうち、つぎの処理ステップで実行するデータが格納されているデータキュー605から実際の処理に用いるデータ、すなわち、トランザクションデータを抽出する。
つぎに、ディスパッチ処理部650は、データキュー605から抽出したトランザクションデータを、各処理ノードにディスパッチする(ステップS1402)。最後に、ディスパッチ処理部650は、各処理ノードのデータキューにディスパッチされたデータを一旦保持させ、各処理ノードによる順次処理を可能にして(ステップS1403)、一連の処理を終了する。
以上説明したように、ディスパッチ処理部650によって、データキュー605に格納されたトランザクションデータを、共通のタイミングで、各処理ノードにディスパッチさせることができる。したがって、各処理ノードによる並列処理を実現することができる。
(本実施の形態にかかる分散処理方法の適用シーン)
以上説明したように、本実施の形態にかかる分散処理方法は、ニアリアルタイム性を求められるマスタ系データの更新処理において、特にその効果を発揮する。具体的には、たとえば、ホテル、乗り物、その他イベントなどのチケットのオンライン予約システムへの適用が挙げられる。
チケット予約システムの場合、人気の高い部屋や座席など同一のレコードへのアクセスが集中する。従来の負荷分散方法の場合、同一レコードへのアクセスの集中によって発生したロック状態がシステム全体に影響を及ぼしていた。すなわち、人気薄の部屋や座席などの予約に関しての処理要求も、アクセスの集中によるロック状態によって処理負荷以上の待機時間が発生する事態があった。
そこで、本実施の形態にかかる分散処理方法を適用することによって、アクセスの集中によるロック状態が回避される。また、人気薄の部屋や座席などの予約に関しての処理要求に関しては、アクセスが集中するレコードとの排他性が高いため、順次処理ノードに振り分けられる。したがって、ロック状態の回避によってシステム全体の処理性能を維持するとともに、人気薄の部屋や座席などの予約に関しての処理要求に関しては、待機時間の短縮が期待できる。
その他にも、複数の取引先からの処理要求を受け付けるオンラインの在庫引当システムに本実施の形態にかかる分散処理方法を適用してもよい。在庫引当システムの場合も、予約システムと同様に、人気商品とそれ以外の商品とでは、処理要求の頻度が異なる。したがって、人気商品への処理要求が集中してもロック状態を起こすことなくデータベースへの並列処理を実現することによって、システム全体の処理効率の向上が期待できる。
なお、本実施の形態で説明した分散処理方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本分散処理プログラムは、ハードディスク、フレキシブルディスク、CD−ROM、MO、DVD等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本分散処理プログラムは、インターネット等のネットワークを介して配布してもよい。
100 ネットワークシステム
101 分散処理装置
110 データベース
301 受付部
302 検出部
303 生成部
304 選択部
305 検索部
306 決定部
307 割当部
600 フォワードプロキシ装置
601 電文
602 順編成ファイル
603 トラン・アイテムテーブル
604 振分前データテーブル
605 データキュー
610 トランザクション取得処理部
620 排他アイテム追加処理部
630 検索処理部
640 格納処理部
650 ディスパッチ処理部
C クライアント装置
N1〜Nn ノード

Claims (7)

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

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2010083901A JP5640432B2 (ja) 2010-03-31 2010-03-31 分散処理装置、分散処理プログラムおよび分散処理方法
US13/073,083 US8560560B2 (en) 2010-03-31 2011-03-28 Device and method for distributed processing

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2010083901A JP5640432B2 (ja) 2010-03-31 2010-03-31 分散処理装置、分散処理プログラムおよび分散処理方法

Publications (2)

Publication Number Publication Date
JP2011215924A true JP2011215924A (ja) 2011-10-27
JP5640432B2 JP5640432B2 (ja) 2014-12-17

Family

ID=44710877

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010083901A Expired - Fee Related JP5640432B2 (ja) 2010-03-31 2010-03-31 分散処理装置、分散処理プログラムおよび分散処理方法

Country Status (2)

Country Link
US (1) US8560560B2 (ja)
JP (1) JP5640432B2 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014026321A (ja) * 2012-07-24 2014-02-06 Fujitsu Ltd ストレージ装置、情報処理装置、情報処理システム、アクセス制御方法、およびアクセス制御プログラム
JP2015045996A (ja) * 2013-08-28 2015-03-12 Kddi株式会社 分散クエリ処理装置、処理方法及び処理プログラム
JP2018200585A (ja) * 2017-05-29 2018-12-20 富士通株式会社 スケールイン管理プログラム、スケールイン管理装置及びスケールイン管理方法

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5625450B2 (ja) * 2010-03-31 2014-11-19 富士通株式会社 分散処理装置、分散処理プログラムおよび分散処理方法
EP2465605A3 (en) 2010-12-20 2014-04-30 Sachtleben Chemie GmbH Titania-supported hydrotreating catalysts
CN104850394B (zh) * 2015-04-17 2018-04-17 北京大学 分布式应用程序的管理方法和分布式系统
CN114911583A (zh) * 2022-04-27 2022-08-16 中信百信银行股份有限公司 信息处理的方法、装置及分布式系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006293852A (ja) * 2005-04-13 2006-10-26 Hitachi Ltd 情報処理装置、情報処理装置の制御方法、及びプログラム
JP2008102795A (ja) * 2006-10-19 2008-05-01 Fuji Xerox Co Ltd ファイル管理装置、システム及びプログラム
JP2010039948A (ja) * 2008-08-07 2010-02-18 Bank Of Tokyo-Mitsubishi Ufj Ltd データ処理装置及びプログラム

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2586219B2 (ja) 1990-12-20 1997-02-26 日本電気株式会社 高速媒体優先解放型排他方式
US7689560B2 (en) * 2000-10-13 2010-03-30 Miosoft Corporation Persistent data storage techniques
US6745198B1 (en) * 2001-06-11 2004-06-01 Ncr Corporation Parallel spatial join index
US7024414B2 (en) * 2001-08-06 2006-04-04 Sensage, Inc. Storage of row-column data
US6957215B2 (en) * 2001-12-10 2005-10-18 Hywire Ltd. Multi-dimensional associative search engine
US8131700B2 (en) * 2008-09-25 2012-03-06 Microsoft Corporation Transitioning clone data maps and synchronizing with a data query
US9171044B2 (en) * 2010-02-16 2015-10-27 Oracle International Corporation Method and system for parallelizing database requests

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006293852A (ja) * 2005-04-13 2006-10-26 Hitachi Ltd 情報処理装置、情報処理装置の制御方法、及びプログラム
JP2008102795A (ja) * 2006-10-19 2008-05-01 Fuji Xerox Co Ltd ファイル管理装置、システム及びプログラム
JP2010039948A (ja) * 2008-08-07 2010-02-18 Bank Of Tokyo-Mitsubishi Ufj Ltd データ処理装置及びプログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
渡辺 榮一, C/Sパワーシステムシリーズ オープンOLTPシステム入門, vol. 第1版, JPN6014000686, 7 December 1995 (1995-12-07), JP, pages 218 - 223, ISSN: 0002721555 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014026321A (ja) * 2012-07-24 2014-02-06 Fujitsu Ltd ストレージ装置、情報処理装置、情報処理システム、アクセス制御方法、およびアクセス制御プログラム
US9336093B2 (en) 2012-07-24 2016-05-10 Fujitsu Limited Information processing system and access control method
JP2015045996A (ja) * 2013-08-28 2015-03-12 Kddi株式会社 分散クエリ処理装置、処理方法及び処理プログラム
JP2018200585A (ja) * 2017-05-29 2018-12-20 富士通株式会社 スケールイン管理プログラム、スケールイン管理装置及びスケールイン管理方法

Also Published As

Publication number Publication date
US20110246510A1 (en) 2011-10-06
US8560560B2 (en) 2013-10-15
JP5640432B2 (ja) 2014-12-17

Similar Documents

Publication Publication Date Title
JP5640432B2 (ja) 分散処理装置、分散処理プログラムおよび分散処理方法
KR102198680B1 (ko) 확장 가능한 멀티-스테이지 데이터 처리 시스템들에서의 효율적인 데이터 캐싱 관리
US8438282B2 (en) Information processing system and load sharing method
US10417248B2 (en) Field extension in database system
US20200364246A1 (en) Relationship Retrieval in a Partitioned List of Records
JP6135509B2 (ja) 情報システム、その管理方法およびプログラム、データ処理方法およびプログラム、ならびに、データ構造
JP5844895B2 (ja) データの分散検索システム、データの分散検索方法及び管理計算機
US12088656B2 (en) Method and system for enforcing governance across multiple content repositories using a content broker
JP7174377B2 (ja) データベース管理システム、および、匿名加工処理方法
US20160378864A1 (en) Cloud-native documents integrated with legacy tools
CN111858151B (zh) 用于在备份操作期间优先处理关键数据对象存储的方法和系统
JP5625450B2 (ja) 分散処理装置、分散処理プログラムおよび分散処理方法
US20060136438A1 (en) Process server array for processing documents and document components and a method related thereto
JP5637501B2 (ja) 文書管理システム、及び文書管理方法
JP6402537B2 (ja) 更新処理プログラム、装置、及び方法
US6778978B1 (en) Determining a workbasket identification for an item in a data store
CN111782834A (zh) 图像检索的方法、装置、设备及计算机可读存储介质
JP2002157386A (ja) ワークフロー管理方法および装置並びにその処理プログラム並びにその処理プログラムを格納した記録媒体
JP6674871B2 (ja) 異種データベース管理装置、方法及びプログラム
US20090144256A1 (en) Workflow control in a resource hierarchy
JP5673224B2 (ja) 情報管理装置、情報管理方法、及びプログラム
Preston Development of a scalable online booking system for SME Car Rental Systems through the implementation of the MERN Stack
US11922328B1 (en) Generating machine-learning model for document extraction
US20230281214A1 (en) Actor-based information system
US8171017B2 (en) Book of business mechanism

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20130206

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20131225

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20140114

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: 20140930

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20141013

R150 Certificate of patent or registration of utility model

Ref document number: 5640432

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees