JP5132359B2

JP5132359B2 - データ分散処理システム及び方法

Info

Publication number: JP5132359B2
Application number: JP2008046529A
Authority: JP
Inventors: 豊荒川; 裕也南; 淳山本; 真人松尾
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2008-02-27
Filing date: 2008-02-27
Publication date: 2013-01-30
Anticipated expiration: 2028-02-27
Also published as: JP2009205389A

Description

本発明は、分散配置されたアプリケーションで、ネットワークを介してデータを共有するためのデータ転送機構として用いて好適なデータ分散処理システム及び方法に関するものである。

ユビキタスアプリケーションでは、遍在するセンサやアクチュエータなどの各種デバイス群と、センサデータサーバやアクチュエータ制御サーバなど計算機群が、互いにデータをやり取りすることでサービスを提供する。このようなユビキタスアプリケーションは、各々のデバイスと計算機上に配置された各アプリケーションプログラムが並列的に処理を行なう分散プログラムとして開発・運用される。

この際、デバイス群は多種大量に存在し、デバイス自体が随時追加・更改される。また移動体に設置されたデバイスは、その位置や収容されるNW（ネットワーク）が変更になったり、また必ずしも常時通信できるとは限らない。一方で、新たなサービスの開発とともに、デバイスと通信する計算機も随時追加・変更されうる。

このようなダイナミックに変化しうるユビキタス環境でのアプリケーション開発・運用においては、データをやりとりする相手の通信アドレスや状態（NWへの接続状況や存在そのもの）を意識せずにプログラミング・実行できる環境が必要となる。この環境を実現する方法として、並列プログラミングの概念Linda（非特許文献１）で提案されたTuple空間（Tuple Space；タプル空間）の利用が有効である（非特許文献２）。

Tuple Spaceは概念上の共有メモリであり、そこにデータ（Tuple；タプル）を書込み／読出しすることで、アプリケーションプログラム同士で通信を行なう。たとえて言うならば、掲示板の役目を果たす。送信側アプリケーションプログラムはデータを掲示板に書込む。一方、受信側アプリケーションプログラムは、必要とするデータの条件を指定して掲示板を検索し、条件にマッチしたデータを読込む。この掲示板を介した間接通信により、アプリケーションプログラムは、送受信するデータの掲示板（Tuple Space）への読書きだけで、通信相手を意識することなく通信できるようになる。このようにデータ送受信を単純化できるため、環境変化に関係なく、それぞれのアプリケーションプログラムを独立に開発・運用することが可能になる。

このとき、受信側アプリケーションプログラムがどのデータ（Tuple）を読み出すかを指定する条件には、いくつか考えられる。典型的には、Tupleには複数のデータ要素を含ませ、そのデータ要素数を条件としたり、データ要素の一部を指定し、そのデータ要素を含むことを条件としたりする。Rinda（非特許文献３）と呼ばれるTuple Spaceの１種では、データ要素の範囲を指定し、その範囲内にデータ要素が含まれることを条件とする、すなわちデータの範囲検索をすることもできる。

ここでTuple Spaceの特徴について説明する。上述したように、Lindaにおけるデータ管理の実体はTupleSpaceと呼ばれており、分散システム開発に適した分散メモリに似た協調機構を提供する。アプリケーションは、送受信データをTupleとして記述し、TupleSpaceへ書き込んだり、TupleSpaceからTupleを読み込んだりすることで通信を行なう。TupleSpaceは以下の特徴を持つ。

A）宛先ではなく送受信データの内容に基づくPublish／Subscribe型の通信（特定の種類のメッセージを受け取りたい側（Subscriber）とメッセージを送りたい側（Publisher）とが非同期で行う通信）。
B）TupleSpaceへ書き込まれたデータの保存。

この機構を採用することによりアプリケーション開発・運用の観点からは次の1）および2）のメリットがある。
1）間接通信のため、互いに相手の存在や状態（実行中か否か）を意識することなく、アプリケーション同士でデータ共有が可能。
・pull（プル）型のデータ蓄積・検索やpush（プッシュ）型のデータ共有・通知が同一機構で実現できる。
・通信断やアプリケーションが動作する端末の追加／変更にも強い。

2）個々のアプリケーションの処理が独立しており、機能追加が容易。
・様々なアプリケーションが自由に構築可能となるため、開発環境として適している。
・用途に応じてアプリケーションを追加することで、ミドルウェアとしての機能拡張が可能。

一方、ネットワーク上の無数のリソース（計算機、データ）をアクセス可能とするための、名前解決に供する技術が存在する。

インターネットの世界で代表的な名前解決機構（リゾルバ）としては、DNS（Domain Name System）がある。このシステムは、メールアドレスやURL（Uniform Resource Locator）に含まれるFQDN（Fully Qualified Domain Name）を「名前」として与えると、対応するIPアドレスを回答する。これによりユーザは、FQDNで示された計算機にアクセス可能となる。DNSは、FQDNを構成するドメインが階層化されていることを利用し、リゾルバの構成も階層化している。このため、システムの規模が増大しても、比較的効率的に名前解決を実行できるが、名前空間が階層構成でない場合は、適用に問題が生じる。

これに対し、一般的な（階層構成でない）名前空間を対象にした名前解決を、水平分散させたリゾルバ構成により大規模化しても効率的に動作させる機構として、CAN（Content Addressable Network）と称されている研究結果（非特許文献４）及びChordと称されている研究結果（非特許文献５）などが存在する。これらはStructured P2P（構造型Peer to Peer）なシステムと呼ばれ、近年盛んに研究されているため様々な亜種が発表されている。これらの多くの機構は、名前をハッシュ関数によりハッシュキーに変換することで名前空間の分割及び名前解決の分散処理を機械的に行う（ハッシュ関数により分散するこうしたシステムはDHT（Distributed Hash Table）と呼ばれる）。このDHTによれば、たとえばある特定の名前に対応するアドレスを取得することはできるが、ある範囲の名前に対応するアドレスを取得することは困難である。ハッシュ関数によって名前を変換すると、ある名前のハッシュキーと、たとえばそれと１文字異なる名前のハッシュキーとは、大きく異なる値を持つことになる。すなわち、ある範囲の名前に対応するアドレスを保持するコンピュータが乱数的に分散することになり、効率的な範囲検索ができくなるのである。

さらに、Skip Graphs（非特許文献６）やSkip Net（非特許文献７）と呼ばれる研究成果は、Structured P2Pなシステムの１つであるが、ハッシュ関数を使わず、名前そのものを整列し、分散管理を行う。これにより、名前の範囲を指定し、その範囲にある名前を持つリソースを発見・アクセスすることが可能である。名前の範囲検索が可能な名前解決機構と言える。すなわち、Skip Graphsなどでは、名前をハッシュ変換しないため、名前すなわち検索キーの順番が保たれるので、範囲検索を実現することが可能となる。しかしながら、このシステムは、単一の検索キーを用いることを前提としているため、複数の検索キーを用いた多次元の検索を行うことが困難である。

また古くからデータベースのインデックスとして使われているB-tree（木構造のインデックスツリー（索引木）により検索を高速化するアルゴリズムの１つ）を分散化し、分散データベースを構築するという研究成果（非特許文献８）も報告されている。こうした技術によっても、分散したリゾルバ群による、名前の範囲検索が可能な名前解決機構を構築することができると考えられる。
D. Geernter, "Generative Communication in Linda," ACM Transactions on Programming Language and Systems, Vol. 7, No. 1, January 1985, Pages 80-112. 増井俊之, 塚田浩二, ""全世界プログラミング", 情報処理学会, 2006年夏のプログラミングシンポジウム, September 2006 Masatoshi SEKI, "8章 Rinda", [online], 2004-10-03, [平成20年2月20日検索], インターネット<URL: http://www2a.biglobe.ne.jp/seki/ruby/d208.html> S.Ratnasamy, P. Francis, M. Handley, R. Karp, and S. Shenker, "A scalable content-addressable network,"In Proc. of ACM SIGCOMM '01, Aug. 2001. I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, and H. Balakrishnan, "Chord: A scalable peer-to-peer lookup service for internet applications, "In Proc. of the ACM SIGCOMM 2001, Aug. 2001. James Aspnes, Gauri Shah, "Skip Graphs,"SODA, Jan. 2003, pp. 384-393 Nicholas J.A.Harvey, Michael B.Jones, Stefan Saroiu, Marvin Theimer, and Alec Wolman, "SkipNet: A scalable over lay network with practical locality properties,"In Proceedings of USITS, USENIX., 2003 Theodore Johnson and Adrian Colbrook, "A Distributed, Replicated, Data-Balanced Search StruCture," In International Journal of High Speed Computing, volume 6, pages 475-500, 1994.

Tuple Spaceを用いた通信では、概念的には１つのTuple Spaceに全てのデータが存在することとなる。ユビキタス環境においては、デバイスや流通するデータの量が膨大となるため、このTuple Spaceの実装には高いスケール性（利用者や仕事の増大に適応できる能力・度合い）が必要となる。高いスケール性を実現するには、ネットワーク上に分散した多数のサーバ群を使ってTuple Spaceを構築することとなるが、その際、どのように分散制御を行うかが問題となる。

単純には、全てのサーバにTupleを複製して書込み、検索（読出し）はどれか１つのサーバに対してだけ行えば良いこととする分散方式や、逆にTupleはどれか１つのサーバにだけ書込み、検索を全サーバに対して行うという分散方式が考えられる。しかしながら、いずれもTupleの書込みないしは検索が全サーバに及ぶため、サーバ１台あたりの性能によりシステム全体の処理量の上限が制限されてしまう。すなわち、十分にスケール性があるとは言えない。

そこで通常、こうした分散制御においては、Tupleの名前、もしくは名前に準じる情報により、Tupleの書込み・検索両方をどのサーバが担うかを決定する（振り分ける）仕組みを導入することとなる。これは一種の名前解決機構と言うこともできる。TupleにID（識別子）があり、IDによって書込み先サーバを決定する場合には、検索時にも、まずTupleのIDを指定して検索すべきサーバを決定することとなる。

このとき、IDの例のように、書込み時のTupleの名前と、検索時のTupleの名前が完全に一致する場合（完全一致検索）は、DNSやDHTを使ったサーバ振り分けが可能であるが、範囲検索を行うとなると書込み時のTupleの名前（１つの値）と、検索時の名前（値の範囲）が異なるため、DNSやDHTでは正しく名前解決することができない。範囲検索を行う場合には、Skip Graphsや分散化B-treeなどの技術を用いる必要がある。

しかしながら、SkipGraphsにせよ分散化B-treeにせよ、１次元の範囲検索にしか対応できない。例えば、身の周りのあらゆる場所にデバイスが設置されたユビキタス環境では、デバイスを時間や空間と対応付けて識別する場合がある。そのため、時間や空間といった３次元あるいは４次元の情報が重要となり、Tuple Spaceを適用する場合には、Tupleにそうした多次元の情報を含ませ、それらの範囲を指定した検索を行いたいといった状況が発生し得る。

こうした要求に応えるには、Skip Graphsや分散化B-treeをその次元数分だけ複数設け、書込み時にはその全てに書き込み、検索時にはその全てから検索し、サーバ間通信を行って得られた結果をマージ（AND（アンド）をとる。すなわち共通して得られたTupleを最終的な検索結果として抽出する）する、という手法が考えられるが、１次元の場合に比べ、記憶容量としての負荷も、ネットワーク負荷も、次元数倍、あるいはそれ以上となってしまう。

本発明は、上記の事情に鑑みてなされたものであり、データ分散処理システムにおけるスケール性のある多次元検索を、従来よりも少ないリソース量（計算リソース、通信リソース、記憶リソース、消費電力等）で実現することができるデータ分散処理システム及び方法を提供することを目的とする。

上記課題を解決するため、請求項１に記載の発明は、タプルが記憶されているタプル空間としてのタプル記憶部を有し、識別情報で識別されているタプル装置と、前記タプル空間に対して、タプルの書き込み又は読み出しの少なくとも一方を行うユーザ端末と、タプルの複数のデータ要素の一部が検索キーとして前記識別情報と関連付けて記憶されている検索情報記憶部を有し、ユーザ端末からの問い合わせに対して、タプルの複数のデータ要素の一部を検索キーとする検索を前記検索情報記憶部に対し２段階に分けて行って、識別情報を検索結果として返す検索装置と、を有し、前記検索装置が、前記ユーザ端末からの問い合わせに対して、１段目の検索で、指定された条件のうち、データ要素１次元分の範囲検索条件を用いて検索し、２段目の検索で、前記指定された条件のうち、残部の検索条件を用いて検索し、それぞれの検索で得られた識別情報を検索結果として返し、前記ユーザ端末が、前記検索装置からの識別情報のそれぞれに該当する各タプル装置に対してタプルの検索要求を送信し、前記各タプル装置が、前記ユーザ端末からのタプルの検索要求の受信に応じて、前記タプル記憶部に対して、タプルの１又は複数の要素に対する範囲検索を実行する、ことを特徴とする。

請求項２に記載の発明は、前記検索装置を複数のサーバ装置に分散して構成し、前記サーバ装置と前記タプル装置とを１対１に対応させ、前記ユーザ端末が、さらに、前記検索装置からの識別情報に該当するタプル装置に対してタプルの書き込み要求を送信し、前記タプル装置が、さらに、前記ユーザ端末からのタプルの書き込み要求の受信に応じて、前記タプル記憶部に対して、タプルの書き込みを実行し、新しい完全一致条件を持つタプルを登録する際には、前記検索情報記憶部のうち、当該完全一致条件についての行を保持する前記サーバ装置が決定した時点で、当該サーバ装置に対応するタプル装置の識別情報を対応づけることを特徴とする。

請求項３に記載の発明は、前記検索装置が、前記１段目の検索で、前記データ要素１次元分の範囲検索条件を用いて検索する際に、SkipGraphsにより検索する、ことを特徴とする。

請求項４に記載の発明は、前記検索装置が、前記１段目の検索で、前記データ要素１次元分の範囲検索条件に加えて、前記指定された条件のうち、他の範囲検索条件あるいは完全一致条件を用いて検索する、ことを特徴とする。

請求項５に記載の発明は、前記検索情報記憶部に記憶されている検索キーが疑似乱数化されていることを特徴とする。

請求項６に記載の発明は、前記タプルが、オブジェクト指向のメッセージングを行うためのデータ要素を含むものであり、前記検索情報記憶部において前記検索キーとなるタプルのデータ要素が、そのオブジェクト指向のメッセージングにおけるオブジェクト名若しくはメソッド名又はその両方に対応するものであることを特徴とする。

請求項７に記載の発明は、タプルが記憶されているタプル空間としてのタプル記憶部を有し、識別情報で識別されているタプル装置と、前記タプル空間に対して、タプルの書き込み又は読み出しの少なくとも一方を行うユーザ端末と、タプルの複数のデータ要素の一部が検索キーとして前記識別情報と関連付けて記憶されている検索情報記憶部を有し、ユーザ端末からの問い合わせに対して、タプルの複数のデータ要素の一部を検索キーとする検索を前記検索情報記憶部に対し２段階に分けて行って、識別情報を検索結果として返す検索装置と、を備えるシステムにおいて、前記検索装置が、前記ユーザ端末からの問い合わせに対して、１段目の検索で、指定された条件のうち、データ要素１次元分の範囲検索条件を用いて検索し、２段目の検索で、前記指定された条件のうち、残部の検索条件を用いて検索し、それぞれの検索で得られた識別情報を検索結果として返し、前記ユーザ端末が、前記検索装置からの識別情報のそれぞれに該当する各タプル装置に対してタプルの検索要求を送信し、前記各タプル装置が、前記ユーザ端末からのタプルの検索要求の受信に応じて、前記タプル記憶部に対して、タプルの１又は複数の要素に対する範囲検索を実行する、ことを特徴とする。

請求項８に記載の発明は、前記検索装置を複数のサーバ装置に分散して構成し、前記サーバ装置と前記タプル装置とを１対１に対応させ、前記ユーザ端末が、さらに、前記検索装置からの識別情報に該当するタプル装置に対してタプルの書き込み要求を送信し、前記タプル装置が、さらに、前記ユーザ端末からのタプルの書き込み要求の受信に応じて、前記タプル記憶部に対して、タプルの書き込みを実行し、新しい完全一致条件を持つタプルを登録する際には、前記検索情報記憶部のうち、当該完全一致条件についての行を保持する前記サーバ装置が決定した時点で、当該サーバ装置に対応するタプル装置の識別情報を対応づけることを特徴とする。

本発明によれば、多次元の範囲検索を１つのサーバ（タプル装置）内に閉じて行うことができるので、複数サーバでの検索、サーバ間通信を伴う結果のマージ処理を不要とし、通信量や読出し処理、記憶容量の節約にもなる。また、ユーザ端末からのタプルの書き込み要求に対して、当該タプルに対する検索装置による検索結果によって特定されたタプル装置において当該タプルが登録されるようにすることで、さらに登録時にもタプルを１つのサーバに書き込めばよいだけとなるため、通信量や書込み処理、記憶容量の節約にもなる。すなわち、本発明によれば、スケール性のある多次元検索を、従来よりも少ないリソース量（計算リソース、通信リソース、記憶リソース、消費電力等）で実現可能である。なお、多次元の範囲検索は、従来のデータベース技術で行うように、R-treeなどの多次元木や、複数のB-treeインデックスを利用することで高速に検索可能である。

以下、図面を参照して、本発明によるデータ分散処理システムの実施の形態について説明する。図１は、本発明によるデータ分散処理システムの実施の形態のシステム構成図であり、ユビキタスネットワーク上で実現される掲示板型双方向通信モデルとしてのデータ分散処理システム１０のシステム構成を示している。このデータ分散処理システム１０では、複数のデータ要素から構成される書き込みTupleと、読み出し（検索）Tupleをマッチングさせることで間接通信が行われる。データ分散処理システム１０は、IPアドレスなどの所定の識別情報で識別されているTupleサーバ３０１〜３０３などの複数のサーバ（コンピュータ）にタプル空間としての共有メモリ（タプル記憶部）を有している。このデータ分散処理システム１０には、Tuple（タプル）の書き込み又は読み出しの少なくとも一方を行う複数のTupleSpaceユーザ端末１０１（ただし図１では１台のみ図示）、タプルの複数のデータ要素の一部が検索キーとしてTupleサーバ３０１〜３０３などの識別情報と関連付けて記憶されているDBなどの所定の検索情報記憶部を有し、TupleSpaceユーザ端末１０１からの問い合わせに対して、タプルの複数のデータ要素の一部を検索キーとする完全一致検索をその検索情報記憶部に対して行ってTupleサーバ３０１〜３０３のいずれかを特定する識別情報を検索結果として返すものであってDHTを形成する複数のDHTサーバ２０１〜２０４からなるDHTサーバ群２００、及びTupleSpaceユーザ端末１０１からの問い合わせに対して、Tupleの複数のデータ要素に対する多次元検索を行うものであって、かつ、登録されたTupleを保持するTupleサーバ３０１〜３０３からなるTupleサーバ群が備えられている。ここで、DHTサーバ群２００は、TupleSpaceユーザ端末１０１からの問い合わせに対して、Tupleの複数のデータ要素の一部を検索キーとする完全一致検索を行って、Tupleサーバ３０１〜３０３のいずれかを特定する情報を検索結果として返すものであるが、DHTサーバ群２００ではその検索キーがハッシュ関数により疑似乱数化され、複数のコンピュータ（DHTサーバ２０１〜２０４）に分散してその検索キーが管理されている。

なお、上述したように本実施の形態においては、Tupleサーバ３０１〜３０３それぞれが、タプルが記憶されているタプル空間としてのタプル記憶部を有しており、このTupleサーバ３０１〜３０３が有するタプル記憶部により、データ分散処理システム１０におけるTupleSpaceが構成されている。また、Tupleサーバ３０１〜３０３が、それぞれ、自装置が有するタプル記憶部に対して、タプルの検索またはタプルの書き込みを実行する。

本実施の形態のデータ分散処理システムでは、データ分散処理システム１０に保存されている複数のTupleから所望のTupleを検索するあるいは書込む際の検索を２段階に分けることを特徴としている。そして、１段目で、指定された条件のうち、完全一致条件部分のみ、あるいは１次元分のみの範囲検索条件を用いて（この１次元分のみの範囲検索については本実施形態の変形例として後述する）検索する。次に、２段目で、指定された条件のうちのすべての（あるいは１段目の残部の）１または多数の要素による範囲検索を行う。これにより１または多次元の範囲検索するサーバの決定、すなわち検索キーと対応する値の階層的な分散管理を行う。既存の名前解決技術により、この１段目の検索を実現し、サーバが決定した後、そのサーバ内で、残りの検索条件を含め、多次元の範囲検索を行う。

例えば、検索条件が「下記６つを満たすこと」であった場合を考える。
（１）データ要素が５個のTupleであること。
（２）「アプリケーションオブジェクト名」のデータ要素の値が「温度センサ」であるTupleであること。
（３）「メソッド名」のデータ要素の値が「定期計測」であるTupleであること。
（４）「場所」のデータ要素の値が「北緯30.00〜30.50, 東経135.10〜135.80」（単位：度）の範囲にあるTupleであること。
（５）「時間」のデータ要素の値が「2007/12/12 00:00〜2007/12/12 23:59」（単位：年／月／日時：分）の範囲にあるTupleであること。
（６）「温度」のデータ要素を持つTupleであること。

この場合、（１）、（２）、（３）、（６）は完全一致条件であり、（４）、（５）は範囲条件であると言える。特に、アプリケーションオブジェクト名やメソッド名などはTupleの登録時も検索時も必ず指定されるものと想定されるため、（２）、（３）の条件でサーバ振り分けを行うこととする。つまり、例えば「アプリケーションオブジェクト名＝温度センサ、メソッド名＝定期計測」という文字列を検索キーとし、その検索キーに対応して振り分けられているTupleサーバ群（Tupleサーバ３０１〜３０３）内の特定のサーバのIPアドレスをその検索キーに対応する値としてDHTサーバ群２００に登録しておく。

Tuple検索時には、アプリケーションオブジェクト名とメソッド名を検索キーとしてDHTサーバ群２００に検索要求を行い、対応サーバのIPアドレスを取得し、当該サーバ内でTuple検索を行う。Tuple書込み時にも同様に、Tupleに含まれるアプリケーションオブジェクト名とメソッド名を検索キーとしてDHTサーバ群２００に検索要求を行い、対応サーバのIPアドレスを取得してから、当該サーバへTuple書込みを行う。

ここで図２のフローを参照しながら、図１のデータ分散処理システム内の処理の流れについて説明する。実際の検索処理に先立って、まず、完全一致条件とそれに合致するTupleを保持するTupleサーバ（Tupleサーバ３０１〜３０３のいずれか）のIPアドレスをDHT内の所定の検索情報記憶部に登録しておく。この場合、DHTには、「アプリケーションオブジェクト名＝温度センサ、メソッド名＝定期計測」という文字列をハッシュ変換したハッシュキーと、その値としてのTupleサーバ３０１のIPアドレス「12.34.56.78」が登録されているものとする。また、Tupleサーバ３０１には、「アプリケーションオブジェクト名＝温度センサ、メソッド名＝定期計測」の完全一致部分に対応する１または複数のTuple ID（タプル識別子；図１では「12345」を例示）を格納したテーブルや、緯度、経度、時間などの他のデータ要素に分類されたTuple IDを格納したテーブルが保持されているとともに、Tuple ID「12345」などの各テーブルに格納されているTuple IDと、そのデータとが対応づけて登録されているテーブルが保持されている。

Tuple登録時、TupleSpaceユーザ端末１０１はまずDHT（DHTサーバ群２００）（＝検索情報記憶部）に対し、当該Tupleの完全一致条件を検索キーとして検索要求を送信し、TupleサーバIPアドレス（＝識別子）を取得する（図２（ａ）のＳ１１）。ここでは、一例として、「アプリケーションオブジェクト名＝温度センサ、メソッド名＝定期計測」を検索キーとして検索要求が出され、Tupleサーバ３０１のIPアドレス「12.34.56.78」が取得されたとする。

次にTupleSpaceユーザ端末１０１は、IPアドレス（＝識別子）で指定されたTupleサーバへ、Tuple書込み要求を行う（Ｓ１２）。上記の例ではTupleSpaceユーザ端末１０１によってIPアドレス「12.34.56.78」のTupleサーバ３０１へ「アプリケーションオブジェクト名＝温度センサ、メソッド名＝定期計測」をデータとして含むTupleの書き込み要求が送信される。Tupleサーバ３０１は、TupleSpaceユーザ端末１０１からのタプルの書き込み要求の受信に応じて、所定のタプル記憶部に対して、タプルの書き込みを実行する。

Tuple検索時にも同様に、TupleSpaceユーザ端末１０１は、まず検索したいTupleの完全一致条件を検索キーとしてDHT（DHTサーバ群２００）（＝検索情報記憶部）へ問合せ（図２（ｂ）のＳ２１）、得られたIPアドレス（＝識別子）をもとにTupleサーバへ範囲検索を行う検索要求を送信する（Ｓ２２）。この場合、「アプリケーションオブジェクト名＝温度センサ、メソッド名＝定期計測」を検索キーとしてDHTサーバ群２００に問い合わせが行われ、その結果としてTupleサーバ３０１のIPアドレス「12.34.56.78」が返されたとすると、TupleSpaceユーザ端末１０１からは、Tupleサーバ３０１に対してたとえば上記検索条件（１）〜（６）を検索キーとしてそれに一致するTupleの検索要求が行われることになる。

そして検索要求の受信に応じて、Tupleサーバでは、所定のタプル記憶部に対してタプルの複数の要素に対する範囲検索が実行される。たとえば検索条件（１）〜（６）を検索キーとしてそれに合致するTupleが検索され、条件に合致したTupleが見つかった場合にはそのTupleがTupleSpaceユーザ端末１０１へ送られることになる（Ｓ２３）。上述したように検索条件（１）、（２）、（３）、（６）は完全一致条件であり、（４）、（５）は範囲条件であるから、（１）、（２）、（３）、（６）の各条件に完全に一致し、（４）の「場所」のデータ要素と（５）の「時間」のデータ要素に関して指定された範囲に該当する複数のTupleが含まれ得ることになる。

Tupleサーバ３０１〜３０３内での検索は、図１に示すように、TupleにIDを付け、リレーショナルモデルにて、データ要素毎にテーブルを作成することでTupleを格納するタプル記憶部に対して行うことができる。ただし、テーブル構造はこれに限るものではない。XML（Extensible Markup Language）やオブジェクト指向言語におけるオブジェクトの形式で表現することも考えられる。格納先としてはRDB（リレーショナルデータベース）だけでなくXML・DB（データベース）やオブジェクト指向DBに格納したり、メモリ上に置くこともかんがえられる。検索のために、インデックスを利用して高速化することもできる。このように、Tupleサーバ３０１〜３０３内での格納・検索は従来技術により実現できる。

上記の例にて、例えばもし「時間」のデータ要素と値、あるいはその範囲が登録時にも検索時にも指定される状況であれば、（２）、（３）に加え（５）の条件をサーバ振り分けに用いることもできる。つまり、例えば、「アプリケーションオブジェクト名＝温度センサ、メソッド名＝定期計測、時間＝2007/12/12 13:40」をキー、それに対応するサーバのIPアドレスを値としてSkipGraphsなどの一次元の範囲検索が可能な分散管理システムに（DHTサーバ群２００に代えて）登録しておく。すなわち、この場合、DHTサーバ群２００に代えて、TupleSpaceユーザ端末１０１からの問い合わせに対して、Tupleの複数のデータ要素のうちから１次元分（１要素分）のみの範囲検索を行って、Tupleサーバ３０１〜３０３のいずれかを特定する情報を検索結果として返す１または複数のサーバからなるサーバ群（SkipGraphs）を設けておく。そして、Tuple検索時には、「アプリケーションオブジェクト名＝温度センサ、メソッド名＝定期計測、時間=2007/12/12 00:00」という文字列を始点、「アプリケーションオブジェクト名＝温度センサ、メソッド名＝定期計測、時間＝2007/12/12 23:59」という文字列を終点とした検索キーなどにより、SkipGraphsへ検索要求を行い、対応サーバ（Tupleサーバ３０１〜３０３など）のIPアドレスを取得し、当該サーバ内でTuple検索を行えばよい。

また、DHT（DHTサーバ群２００）における完全一致条件とTupleサーバIPアドレスとの対応付け方法は上記のものに限らず、次のような方法も考えられる。
（ａ）新しい完全一致条件（DHTが持つ表にないことで分かる）を持つTupleを登録する際、Tupleサーバのうち最も処理負荷や記憶負荷が低いもののIPアドレスと対応づける。
（ｂ）DHTサーバとTupleサーバを１対１に対応させ、新しい完全一致条件を持つTupleを登録する際、DHTが保持する表のうち、当該完全一致条件についての行を保持するDHTサーバが決定した時点で、そのDHTサーバに対応するTupleサーバのIPアドレスを対応づける。特に２つ目の方式（ｂ）は、１段目の検索にSkipGraphsなどを使う場合に有用で、１段目の検索結果となるIPアドレスの数（＝２段目で検索要求しなければならない数）が少なくなる効果がある。

本実施の形態によれば、多次元の範囲検索をTupleサーバ３０１〜３０３などの１つ、もしくは数台の限られたサーバ内だけで行うことにより、次元毎の複数サーバでの検索、サーバ間通信を伴う結果のマージ処理を不要、もしくは最小限に抑え、さらに登録時にもTupleを１つのサーバに書き込めばよいだけとなるため、通信量や書込み処理、記憶容量の節約にもなる。すなわち、スケール性のある多次元検索を、従来よりも少ないリソース量（計算リソース、通信リソース、記憶リソース、消費電力等）で実現可能である。なお、多次元の範囲検索は、従来のデータベース技術で行うように、R-treeなどの多次元木や、複数のB-treeインデックスを利用することで高速に検索可能である。

本発明のポイントをまとめると次のようになる。本発明のポイントは、検索を２段にわけることと、またその１段目の検索で２段目の検索サーバを１つ、もしくは数台の検索サーバーに限定できるような構成にすることである。ここで、１段目：完全一致条件部のみ、あるいは１次元分のみの範囲検索条件とし、２段目：残りの多次元検索としている。

また、本発明においては、その構成が利用者にとって無理のないものにし得ることが特徴であるということができる。すなわち、サーバ振り分けのための１段目の検索に用いる情報は、登録時にも検索時にも必ず指定しなければならないものとなり、登録するTuple、検索するTupleに制約を加えてしまうものとなる。しかしながら、例えばオブジェクト指向のメッセージングを行う場合には、相手や自分のオブジェクト名、あるいはその送受信を行うメソッド名が必ず指定されると期待される。そうした必ず指定される情報により１段目の検索を実現することにより、利用者にも無理なく、処理を分散させ、スケールさせることができる。すなわち、Tupleが、オブジェクト指向のメッセージングを行うためのデータ要素を含むものである場合には、利用者にとって無理がないようにして、DHT（DHTサーバ群２００）が完全一致検索を行う際に検索キーとするTupleのデータ要素をそのオブジェクト指向のメッセージングにおけるオブジェクト名もしくはメソッド名またはその両方に対応するものであるようにすることができる。

なお、１段目の検索に用いる情報としては、データ要素１つに限る必要はない。利用者に無理のない範囲で、複数のデータ要素の組合せを用いることにより、キーがより多様となり、より分散させられることとなる。

なお、本発明の実施の形態は上記に限定されず、各端末、サーバの数を増やしたり、減らしたりすることが可能である。また、各サーバが備える情報をさらに分散して管理したりすることも可能である。また、各端末やサーバはコンピュータ及びその周辺装置と、そのコンピュータで実行されるプログラムとから実現することができ、そのプログラムは、コンピュータ読み取り可能な記録媒体や通信回線を介して配布することが可能である。

本発明のデータ分散処理システムの実施の形態を示すシステム図である。図１の構成における処理の流れを説明するためのフローチャートであり、（ａ）がTuple登録時、（ｂ）がTuple検索時の処理のフローである。

符号の説明

１０データ分散処理システム
１０１ TupleSpaceユーザ端末（ユーザ端末）
２００ DHTサーバ群（検索装置）
２０１〜２０４ DHTサーバ
３０１〜３０３ Tupleサーバ（タプル装置）

Claims

タプルが記憶されているタプル空間としてのタプル記憶部を有し、識別情報で識別されているタプル装置と、
前記タプル空間に対して、タプルの書き込み又は読み出しの少なくとも一方を行うユーザ端末と、
タプルの複数のデータ要素の一部が検索キーとして前記識別情報と関連付けて記憶されている検索情報記憶部を有し、ユーザ端末からの問い合わせに対して、タプルの複数のデータ要素の一部を検索キーとする検索を前記検索情報記憶部に対し２段階に分けて行って、識別情報を検索結果として返す検索装置と、
を有し、
前記検索装置が、
前記ユーザ端末からの問い合わせに対して、１段目の検索で、指定された条件のうち、データ要素１次元分の範囲検索条件を用いて検索し、２段目の検索で、前記指定された条件のうち、残部の検索条件を用いて検索し、それぞれの検索で得られた識別情報を検索結果として返し、
前記ユーザ端末が、
前記検索装置からの識別情報のそれぞれに該当する各タプル装置に対してタプルの検索要求を送信し、
前記各タプル装置が、
前記ユーザ端末からのタプルの検索要求の受信に応じて、前記タプル記憶部に対して、タプルの１又は複数の要素に対する範囲検索を実行する、
ことを特徴とするデータ分散処理システム。
前記検索装置を複数のサーバ装置に分散して構成し、前記サーバ装置と前記タプル装置とを１対１に対応させ、
前記ユーザ端末が、さらに、
前記検索装置からの識別情報に該当するタプル装置に対してタプルの書き込み要求を送信し、
前記タプル装置が、さらに、
前記ユーザ端末からのタプルの書き込み要求の受信に応じて、前記タプル記憶部に対して、タプルの書き込みを実行し、
新しい完全一致条件を持つタプルを登録する際には、前記検索情報記憶部のうち、当該完全一致条件についての行を保持する前記サーバ装置が決定した時点で、当該サーバ装置に対応するタプル装置の識別情報を対応づける
ことを特徴とする請求項１に記載のデータ分散処理システム。
前記検索装置が、
前記１段目の検索で、前記データ要素１次元分の範囲検索条件を用いて検索する際に、SkipGraphsにより検索する、
ことを特徴とする請求項１または請求項２に記載のデータ分散処理システム。
前記検索装置が、
前記１段目の検索で、前記データ要素１次元分の範囲検索条件に加えて、前記指定された条件のうち、他の範囲検索条件あるいは完全一致条件を用いて検索する、
ことを特徴とする請求項１から３のいずれか１項に記載のデータ分散処理システム。
前記検索情報記憶部に記憶されている検索キーが疑似乱数化されている
ことを特徴とする請求項１から４のいずれか１項に記載のデータ分散処理システム。
前記タプルが、オブジェクト指向のメッセージングを行うためのデータ要素を含むものであり、
前記検索情報記憶部において前記検索キーとなるタプルのデータ要素が、そのオブジェクト指向のメッセージングにおけるオブジェクト名若しくはメソッド名又はその両方に対応するものである
ことを特徴とする請求項１から５のいずれか１項に記載のデータ分散処理システム。
タプルが記憶されているタプル空間としてのタプル記憶部を有し、識別情報で識別されているタプル装置と、
前記タプル空間に対して、タプルの書き込み又は読み出しの少なくとも一方を行うユーザ端末と、
タプルの複数のデータ要素の一部が検索キーとして前記識別情報と関連付けて記憶されている検索情報記憶部を有し、ユーザ端末からの問い合わせに対して、タプルの複数のデータ要素の一部を検索キーとする検索を前記検索情報記憶部に対し２段階に分けて行って、識別情報を検索結果として返す検索装置と、
を備えるシステムにおいて、
前記検索装置が、
前記ユーザ端末からの問い合わせに対して、１段目の検索で、指定された条件のうち、データ要素１次元分の範囲検索条件を用いて検索し、２段目の検索で、前記指定された条件のうち、残部の検索条件を用いて検索し、それぞれの検索で得られた識別情報を検索結果として返し、
前記ユーザ端末が、
前記検索装置からの識別情報のそれぞれに該当する各タプル装置に対してタプルの検索要求を送信し、
前記各タプル装置が、
前記ユーザ端末からのタプルの検索要求の受信に応じて、前記タプル記憶部に対して、タプルの１又は複数の要素に対する範囲検索を実行する、
ことを特徴とするデータ分散処理方法。
前記検索装置を複数のサーバ装置に分散して構成し、前記サーバ装置と前記タプル装置とを１対１に対応させ、
前記ユーザ端末が、さらに、
前記検索装置からの識別情報に該当するタプル装置に対してタプルの書き込み要求を送信し、
前記タプル装置が、さらに、
前記ユーザ端末からのタプルの書き込み要求の受信に応じて、前記タプル記憶部に対して、タプルの書き込みを実行し、
新しい完全一致条件を持つタプルを登録する際には、前記検索情報記憶部のうち、当該完全一致条件についての行を保持する前記サーバ装置が決定した時点で、当該サーバ装置に対応するタプル装置の識別情報を対応づける
ことを特徴とする請求項７に記載のデータ分散処理方法。