JP5782937B2 - タグ管理装置、タグ管理システムおよびタグ管理プログラム - Google Patents

Description

本発明は、タグ管理装置およびタグ管理プログラムに関する。

従来、データに対してタグ付けをして蓄積するタグ検索システムがある。タグ検索システムでは、蓄積したデータを検索する場合に、タグを使って条件を指定してデータを検索する。このようなタグ検索システムを用いた技術としては、タグと文書データとを対応付けて管理する構造化文書などが知られている。

構造化文書のタグを検索する場合に、複数のタグを合成して１つのタグにすることで、メモリ量の圧縮や木構造のノード数を減少させて、タグ検索の処理の速度を向上させる技術が知られている。また、構造化文書の文章データを所定量ずつ連続的に読み込みながら検索を行い、タグ検索とタグの中のキーワードを切り替えながら検索する技術も知られている。

構造化文書以外にも、ＨＴＭＬ（Hyper Text Markup Language）ブラウザで表示中の画面においてタグ指定があった場合に、画面からタグを検索し、検索したタグに該当するデータを表示するタグ検索システムなども知られている。

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

しかしながら、従来技術では、センサデータやライフログのように逐次データが追加される、タグ付けされた大規模なデータを検索する場合には、ランダムアクセスが発生し、検索性能が劣化するという問題がある。

一般的には、サーバ等は、メモリ上で大規模なタグ付きデータを保持できないので、ディスク上でＤＢＭＳ（Data Base Management System）等を用いて保持することになる。そして、サーバ等は、指定されたタグに対応するデータを大規模なタグ付きデータから検索する場合、ランダムアクセスを用いてデータを検索する。このため、検索要求が大量に発生した場合に、ディスクのランダムアクセスが大量に発生し、検索結果を応答するまでにかかる時間が長くなる。

１つの側面では、検索性能を向上させるタグ管理装置およびタグ管理プログラムを提供することを目的とする。

第１の案では、タグ管理装置は、受信したデータに、受信した順番が識別可能となるような単調増加または単調減少な数もしくは辞書順に並んだ文字列などのソート不要な識別子を付与する付与部を有する。また、タグ管理装置は、前記受信したデータに付与されたタグに対応する第１記憶部に、前記付与部によって付与される識別子を順に記憶させる第１記憶制御部を有する。また、タグ管理装置は、前記受信したデータと前記付与部によって付与される識別子とを対応付けて第２記憶部に順に記憶させる第２記憶制御部を有する。また、タグ管理装置は、検索対象のタグに対応する記憶部が前記第１記憶部である場合に、前記第１記憶部に記憶される情報と前記第２記憶部に記憶される情報とを内部結合または外部結合させて、前記検索対象のタグに対応付けられたデータを検索する検索部を有する。

検索性能を向上させることができる。

図１は、実施例１に係るシステムの全体構成例を示す図である。 図２は、実施例２に係るクライアント端末の構成を示す機能ブロック図である。 図３は、クライアント端末がタグ管理サーバに送信するメッセージの例を示す図である。 図４は、実施例２に係るタグ管理サーバの構成を示す機能ブロック図である。 図５は、タグテーブルの例を示す図である。 図６は、データテーブルに記憶される情報の例を示す図である。 図７は、検索処理を説明する図である。 図８は、実施例２に係るタグ管理サーバが実行する蓄積処理の流れを示すフローチャートである。 図９は、実施例２に係るタグ管理サーバが実行する検索処理の流れを示すフローチャートである。 図１０は、実施例３に係るシステムの全体構成例を示す図である。 図１１は、実施例３に係るタグ管理サーバの構成を示す機能ブロック図である。 図１２は、実施例３に係るタグ管理サーバが実行する蓄積処理の流れを示すフローチャートである。 図１３は、実施例３に係るタグ管理サーバが実行する検索処理の流れを示すフローチャートである。 図１４は、タグ管理プログラムを実行するコンピュータのハードウェア構成例を示す図である。

以下に、本願の開示するタグ管理装置およびタグ管理プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。

図１は、実施例１に係るシステムの全体構成例を示す図である。図１に示すシステムは、クライアント端末１、クライアント端末２、クライアント端末３、タグ管理サーバ１０がネットワーク５を介して相互に通信可能に接続される。このシステムは、各クライアント端末がタグ管理サーバ１０にタグ付きのデータを送信し、タグ管理サーバ１０がタグ付きのデータを管理する。なお、ここで例示した装置の数等はあくまで例示であり、これに限定されるものではない。

クライアント端末１、クライアント端末２、クライアント端末３は、タグ管理サーバ１０にデータの書き込みを要求したり、データの検索を要求したりするコンピュータ装置である。例を挙げると、各クライアント端末は、演算処理等によって得られたデータにタグを付加したメッセージを生成し、生成したメッセージをタグ管理サーバ１０に送信する。また、各クライアント端末は、外部装置から受信したライフログなどのデータにタグを付加したメッセージを生成し、生成したメッセージをタグ管理サーバ１０に送信する。外部装置の例としては、車両に搭載されて交通情報をクライアント端末に送信する装置や、温度や湿度を計測してクライアント端末に送信する装置などがある。

タグ管理サーバ１０は、第１記憶部１１と第２記憶部１２と付与部１３と第１記憶制御部１４と第２記憶制御部１５と検索部１６とを有し、これらによって各クライアント端末から受信したデータを管理するサーバ装置である。

付与部１３は、クライアント端末１−３から受信したデータに、受信した順番が識別可能となるような単調増加または単調減少な数もしくは辞書順に並んだ文字列などのソート不要な識別子を付与する。第１記憶制御部１４は、受信したデータに付与されたタグに対応する第１記憶部１１に、付与部１３によって付与される識別子を順に記憶させる。第２記憶制御部１５は、受信したデータと付与部１３によって付与される識別子とを対応付けて第２記憶部１２に順に記憶させる。このときどちらのテーブルも、追加する識別子はテーブルの最後に追加する。検索部１６は、検索対象のタグに対応する記憶部が第１記憶部１１である場合に、第１記憶部１１に記憶される情報と第２記憶部１２に記憶される情報とを内部結合または外部結合させて、検索対象のタグに対応付けられたデータを検索する。

このように、タグ管理サーバ１０は、受信した順番が識別可能となるような単調増加または単調減少な数もしくは辞書順に並んだ文字列などのソート不要な識別子を付加して、受信したデータのタグと付与した識別子とを受信順で記憶する。また、タグ管理サーバ１０は、受信したデータに識別子を対応付けて、受信した順でデータを記憶する。このため、タグ管理サーバ１０は、検索対象のタグがクライアント等によって指定された場合に、検索対象のタグに対応するタグテーブルとデータテーブルとを、識別子の一致を条件としたジョインの手法を用いてデータを特定することができる。このときジョインの手法としてソートマージジョインの手法を用いる場合、テーブルは単調増加な識別子を追記のみで構成しているので、識別子でソート済みである。よって、ソートマージジョインにおけるソートの段階を省略し、マージの段階のみでデータを特定することができる。その結果ソートの段階で発生しうるランダムアクセスを全て抑止できる。したがって、タグ管理サーバ１０は、データが大規模になってハードディスク等でデータを記憶する場合でも、ランダムアクセスの発生を抑制することができるので、検索性能を向上させることができる。

次に、実施例１で説明したクライアント端末１−３およびタグ管理サーバ１０の構成、処理の流れ等を説明する。なお、図１に示したクライアント端末は同様の構成を有するので、ここでは、クライアント端末２０として説明する。また、タグ管理サーバ１０は、実施例１で有する機能以外についても説明するので、実施例２ではタグ管理サーバ３０として説明する。

［クライアント端末の構成］
図２は、実施例２に係るクライアント端末の構成を示す機能ブロック図である。図２に示すように、クライアント端末２０は、ネットワークインタフェース２１と、記憶部２２と、制御部２３とを有する。なお、クライアント端末２０が有する制御部はこれらに限定されるものではなく、例えば、マウスなどの入力部、ディスプレイなどの表示部、記憶媒体からデータを読み出す記憶媒体読取装置等を有していてもよい。

ネットワークインタフェース２１は、他の装置の通信を制御するＮＩＣ（Network Interface Card）などである。ネットワークインタフェース２１は、外部装置からセンサデータやライブログなどの各種データを受信し、タグ管理サーバ１０にメッセージを送信する。記憶部２２は、制御部２３が実行するプログラムやデータ等を記憶する記憶装置であり、例えば半導体メモリ素子やハードディスクなどの記憶装置である。

制御部２３は、ＯＳ（Operating System）などを実行してクライアント端末２０の全体的な制御を司る処理部であり、例えばＣＰＵ（Central Processing Unit）などの電子回路である。制御部２３は、データ生成エンジン２４とタグ付加エンジン２５とを有し、これらによってメッセージをタグ管理サーバ３０に送信する。

データ生成エンジン２４は、送信対象となるデータを生成する処理部である。例えば、データ生成エンジン２４は、アプリケーション等を実行してデータを生成し、生成したデータをタグ付加エンジン２５に出力する。また、データ生成エンジン２４は、外部装置からデータを受信した場合には、受信したデータをタグ付加エンジン２５に出力する。

タグ付加エンジン２５は、データ生成エンジン２４から受け付けたデータに付与するタグを決定し、決定したタグをデータに付与したメッセージを生成してタグ管理サーバ３０に送信する処理部である。タグ付加エンジン２５は、クライアントの固有番号やセンサーの設置場所などの固定タグを付与してもよく、データの中身を参照してデータの中身を特定する情報を動的に選択してタグとして付加してもよい。

図３は、クライアント端末がタグ管理サーバに送信するメッセージの例を示す図である。この例では、クライアント端末が渋滞情報などの交通情報を送信する例で説明する。図３に示すように、クライアント端末が送信するメッセージは、「タグ、データ」が対応付けられている。この「タグ」は、タグ付加エンジン２５が付加したタグを示し（複数あってもよい）、「データ」は、データ生成エンジン２４がタグ付加エンジン２５に送信したデータを示す。データは、例えばＧＰＳ（Global Positioning System）の出力で、緯度・経度・時刻・高度であるが、図３においては、簡略化のためイベントとして記述している。

図３の場合、「イベントＡ」にはタグとして「曜日時間：月曜９時−１０時」と「場所：Ａ県Ｂ市Ｃ町」が付加されていることを示す。また、「イベントＢ」にはタグとして「曜日時間：火曜１２時−１３時」と「場所：Ａ県Ｅ市Ｆ区」と「道路：混雑」とが付加されていることを示す。

［タグ管理サーバの構成］
図４は、実施例２に係るタグ管理サーバの構成を示す機能ブロック図である。図４に示すように、タグ管理サーバ３０は、ネットワークインタフェース３１と、メモリ３２、データストア３３と、制御部３４とを有する。なお、タグ管理サーバ３０が有する制御部はこれらに限定されるものではなく、例えば、マウスなどの入力部、ディスプレイなどの表示部、記憶媒体からデータを読み出す記憶媒体読取装置等を有していてもよい。

ネットワークインタフェース３１は、他の装置の通信を制御するＮＩＣなどである。ネットワークインタフェース３１は、各クライアント端末からメッセージを受信し、メッセージに含まれるデータの蓄積結果を示す応答を送信する。また、ネットワークインタフェース３１は、各クライアント端末から検索要求を受信し、その応答を送信する。

メモリ３２は、制御部３４が実行するプログラムやデータ等を記憶する記憶装置であり、バッファ３２ａを有する。バッファ３２ａは、クライアント端末から受信したデータをデータストア３３に格納する前に、一時的に格納する記憶領域である。

データストア３３は、ＣＳＶ形式など追記型でデータを保持するデータストアであり、タグテーブル３３ａ−１からタグテーブル３３ａ−ｎ（ｎは自然数）とデータテーブル３３ｂを有する。なお、このデータストア３３は、例えばハードディスクなどの記憶装置に設けられる。

タグテーブル３３ａ−１からタグテーブル３３ａ−ｎは、タグごとに設けられるテーブルであり、動的に生成される。図５は、タグテーブルの例を示す図である。図５に示すように、１つのタグテーブルは「ｋｅｙ、Ｖａｌｕｅ」を有する。つまり、タグテーブルは、ＫＶＳ（キーバリューストア）と同様の方式で管理される。「Ｋｅｙ」は、制御部３４によって生成されたＩＤであり、「Ｖａｌｕｅ」は、ＫＶＳを構成するためのダミーデータである。タグテーブルは、ＫＶＳの方式にこだわらずＲＤＢ（Relational DataBase）の表形式のような形で管理してもよい。

図５の場合、タグとして「曜日時間：火曜１２−１３時」、「曜日時間：月曜９−１０時」、「場所：Ａ県Ｅ市Ｆ区」、「場所：Ａ県Ｂ市Ｃ町」、「道路：混雑」が存在し、これらのタグ各々に対応したタグテーブルが形成されている。

例を挙げると、タグテーブル３３ａ−１が「曜日時間：火曜１２−１３時」のタグテーブルであり、タグテーブル３３ａ−２が「曜日時間：月曜９−１０時」のタグテーブルである。また、タグテーブル３３ａ−３が「場所：Ａ県Ｅ市Ｆ区」のタグテーブルであり、タグテーブル３３ａ−４が「場所：Ａ県Ｂ市Ｃ町」のタグテーブルであり、タグテーブル３３ａ−５が「道路：混雑」のタグテーブルである。

「曜日時間：火曜１２−１３時」のタグテーブルで説明すると、このタグテーブルには、「Ｋｅｙ、Ｖａｌｕｅ」として「00003879、True」と「00037192、True」が対応付けて記憶される。ここで記憶される順番は、データが受信された順番すなわちＩＤが付与された順番で記憶される。つまり、次に新たなＩＤ「01234567」を格納する場合には、「00037192、True」の後ろすなわち末尾に格納される。なお、ここで示したＩＤやタグの形式は、あくまで例示であり、これに限定されるものではない。

データテーブル３３ｂは、クライアント端末から受信されたデータとＩＤ付与部３６によって付与されたＩＤとを対応付けて記憶するテーブルである。図６は、データテーブルに記憶される情報の例を示す図である。図６に示すように、データテーブル３３ｂは、「Ｋｅｙ」と「Ｖａｌｕｅ」で構成される。すなわち、データテーブル３３ｂは、タグテーブルと同様の形式で管理される。

図６に示す「Ｋｅｙ」は、ＩＤ付与部３６によって付与されたＩＤであり、「Ｖａｌｕｅ」は、クライアント端末から受信したメッセージに含まれるデータである。図６は、「Ｋｅｙ＝00000001」にデータ「イベントＡ」が対応付けられており、「Ｋｅｙ＝00003879」にデータ「イベントＢ」が対応付けられていることを示す。ここで記憶される順番は、データが受信された順番すなわちＩＤが付与された順番で記憶される。なお、ここで示したＩＤやタグの形式は、あくまで例示であり、これに限定されるものではない。

制御部３４は、ＯＳなどを実行してタグ管理サーバ３０の全体的な制御を司る処理部であり、例えばＣＰＵなどの電子回路である。この制御部３４は、要求判定部３５とＩＤ付与部３６とタグ格納部３７とデータ格納部３８と検索エンジン３９とを有し、これらによってタグの蓄積や検索を実行する。

要求判定部３５は、クライアント端末１０から受信した情報の種別を判定する処理部である。例えば、要求判定部３５は、クライアント端末１０からデータ蓄積要求メッセージを受信した場合に、受信したデータ蓄積要求メッセージをＩＤ付与部３６に出力する。また、要求判定部３５は、クライアント端末１０から検索要求を受信した場合には、受信した検索要求を検索エンジン３９に出力する。

また、要求判定部３５は、受信したメッセージ内にイベント情報とタグが存在する場合には蓄積要求と判定してＩＤ付与部３６に出力し、受信したメッセージ内にタグしか存在しない場合には検索要求と判定して検索エンジン３９に出力することもできる。

ＩＤ付与部３６は、受信したメッセージに、受信した順番に連番となるＩＤを付与する処理部である。ＩＤ付与部３６は、ＩＤを付与したメッセージをタグ格納部３７とデータ格納部３８とに出力する。例えば、ＩＤ付与部３６は、「時刻＋シリアル番号」を「ＩＤ」として生成する。「時刻」は、メッセージを受信した時刻であり、パケットのヘッダ等から取得できる。「ＩＤ」は、到着順に単純増加なカウンタ値である。また、ＩＤ付与部３６は、時刻が繰り上がった場合には、シリアル番号をリセットする。

一般的なＯＳは、ミリ秒単位の精度で時刻を得られるので、これを利用することもできる。一例を挙げると、ＩＤ付与部３６は、ＵＮＩＸ（登録商標）時刻1313009112（２０１１年８月１０日２０時４５分１２秒）に５番目に受け付けたメッセージに対して、「13130091120005」をＩＤとして割り振る。そして、ＩＤ付与部３６は、時刻が２０１１年８月１０日２０時４６分に繰り上がった場合には、シリアル番号を０にリセットして、以降のＩＤを生成する。

タグ格納部３７は、受信したメッセージに付与されたタグに対応するタグテーブルに、ＩＤ付与部３６によって付与されたＩＤを追加する。そして、タグ格納部３７は、タグテーブルへのＩＤ格納を完了したことを制御部３４やデータ格納部３８に通知する。ここで、タグ格納部３７が、「ＩＤ＝00003879」が付与されたメッセージ「タグ＝曜日時間：火曜１２−１３時、場所：Ａ県Ｅ市Ｆ区、道路：混雑、データ＝イベントＢ」を、ＩＤ付与部３６から受信した例で説明する。

この場合、タグ格納部３７は、受信したメッセージからタグとして、「曜日時間：火曜１２−１３時」と「場所：Ａ県Ｅ市Ｆ区」と「道路：混雑」とを抽出する。同様に、タグ格納部３７は、メッセージに付与される「ＩＤ＝00003879」を抽出する。そして、タグ格納部３７は、タグ「曜日時間：火曜１２−１３時」に対応するタグテーブルがデータストア３３上に存在するか否かを判定する。存在する場合には、タグ格納部３７は、当該タグテーブルの末尾のレコードを特定し、特定したレコードの次のレコードとして「Ｋｅｙ＝00003879、Ｖａｌｕｅ＝True」を追記する。存在しない場合には、タグ格納部３７は、タグ「曜日時間：火曜１２−１３時」に対応するタグテーブルをデータストア３３に新たに生成し、生成したタグテーブルの先頭に「Ｋｅｙ＝00003879、Ｖａｌｕｅ＝True」を格納する。

同様に、タグ格納部３７は、タグ「場所：Ａ県Ｅ市Ｆ区」に対応するタグテーブルがデータストア３３上に存在するか否かを判定する。存在する場合には、タグ格納部３７は、当該タグテーブルの末尾のレコードを特定し、特定したレコードの次のレコードとして「Ｋｅｙ＝00003879、Ｖａｌｕｅ＝True」を追記する。存在しない場合には、タグ格納部３７は、タグ「場所：Ａ県Ｅ市Ｆ区」に対応するタグテーブルをデータストア３３に新たに生成し、生成したタグテーブルの先頭に「Ｋｅｙ＝00003879、Ｖａｌｕｅ＝True」を格納する。

同様に、タグ格納部３７は、タグ「道路：混雑」に対応するタグテーブルがデータストア３３上に存在するか否かを判定する。存在する場合には、タグ格納部３７は、当該タグテーブルの末尾のレコードを特定し、特定したレコードの次のレコードとして「Ｋｅｙ＝00003879、Ｖａｌｕｅ＝True」を追記する。存在しない場合には、タグ格納部３７は、タグ「道路：混雑」に対応するタグテーブルをデータストア３３に新たに生成し、生成したタグテーブルの先頭に「Ｋｅｙ＝00003879、Ｖａｌｕｅ＝True」を格納する。

つまり、タグ格納部３７は、各タグテーブルの末尾に新たなレコードを追記する。したがって、各タグテーブルのレコードは、先頭から末尾まで「Ｋｅｙ」の昇順で整列することになる。

図４に戻り、データ格納部３８は、受信したメッセージとＩＤ付与部３６によって付与されたＩＤとを対応付けてデータテーブル３３ｂに追加する。そして、データ格納部３８は、データテーブル３３ｂへの格納が完了したことを制御部３４やタグ格納部３７に通知する。なお、制御部３４は、タグ格納部３７とデータ格納部３８の処理がともに終了した場合に、メッセージを送信した送信元のクライアント端末１０にデータを蓄積したことを示す応答を送信する。

ここで、上述した例をと同様の例で説明する。データ格納部３８は、「ＩＤ＝00003879」が付与されたメッセージ「タグ＝曜日時間：火曜１２−１３時、場所：Ａ県Ｅ市Ｆ区、道路：混雑、データ＝イベントＢ」を、ＩＤ付与部３６から受信する。続いて、データ格納部３８は、受信した情報から「データ＝イベントＢ」と「ＩＤ＝00003879」とを抽出する。そして、データ格納部３８は、データテーブル３３ｂを参照して末尾のレコードを特定し、特定した末尾のレコードの次のレコードとして「Ｋｅｙ＝00003879、Ｖａｌｕｅ＝イベントＢ」を追記する。つまり、データテーブル３３ｂの最後尾に新たなレコードが追加されることになるので、データテーブル３３ｂのレコードは、先頭から末尾まで「Ｋｅｙ」の昇順で整列することになる。

検索エンジン３９は、検索対象のタグに対応するタグテーブル３３ａ−１から３３ａ−ｎとデータテーブル３３ｂとを突き合わせて、検索対象のタグに対応付けられたデータを検索する処理部である。例えば、検索エンジン３９が、「タグ＝曜日時間：火曜１２−１３時かつ場所：Ａ県Ｅ市Ｆ区かつ道路：混雑」に対応するデータを検索する検索要求を受信したとする。図７は、検索処理を説明する図である。

この場合、検索エンジン３９は、図７に示すように、「曜日時間：火曜１２−１３時」に対応するタグテーブルと、「場所：Ａ県Ｅ市Ｆ区」に対応するタグテーブルと、「道路：混雑」に対応するタグテーブルとを用いてソートマージジョイン処理を実行する。このとき、検索エンジン３９は、各タグテーブルが上述したように既にソートされている状態なので、マージ処理のみを実行する。具体的には、検索エンジン３９は、ソートマージジョイン処理によって、上記３つのタグテーブルに共通する「Ｋｅｙ」として「00003879」を抽出する。続いて、検索エンジン３９は、データテーブル３３ｂを参照し、抽出した「00003879」を「Ｋｅｙ」とする「Ｖａｌｕｅ」として「イベントＢ」を特定する。その後、検索エンジン３９は、特定した「イベントＢ」を検索結果としてクライアント端末に応答する。

検索エンジン３９は、検索要求として受信されたタグの条件がＡＮＤ条件の場合には、該当する各タグテーブルに対してソートマージジョイン処理のインナージョイン（内部結合）を実行する。例えば、検索エンジン３９は、タグＡかつタグＢに該当するデータを検索する場合にはインナージョインを実行することで、各タグテーブルに共通して記憶される「Ｋｅｙ」を抽出することができる。この場合、検索エンジンは、該当する各タグテーブルだけでなく、データテーブル３３ｂを含めてソートマージジョイン処理のインナージョインを実行してデータを検索してもよい。

また、検索エンジン３９は、検索要求として受信されたタグの条件がＯＲ条件の場合には、該当する各タグテーブルに対してソートマージジョイン処理のアウタージョイン（外部結合）を実行する。例えば、検索エンジン３９は、タグＡまたはタグＢに該当するデータを検索する場合にはアウタージョインを実行することで、各タグテーブルのいずれかに記憶される「Ｋｅｙ」を抽出することができる。この場合、検索エンジン３９は、該当する各タグテーブルに対するソートマージジョイン処理で得られた結果と、データテーブル３３ｂとを用いて、ソートマージジョイン処理のインナージョインを実行してデータを検索する。

［処理の流れ］
次に、タグ管理サーバ３０が実行する処理の流れについて説明する。なお、クライアント端末が実行する処理は、データ生成処理、タグ付け処理などの一般的な処理なので詳細な説明は省略する。

（蓄積処理の流れ）
図８は、実施例２に係るタグ管理サーバが実行する蓄積処理の流れを示すフローチャートである。図８に示すように、タグ管理サーバ３０の要求判定部３５がメッセージを受信したと判定した場合（Ｓ１０１肯定）、ＩＤ付与部３６は、受信時刻等を用いて、受信されたメッセージにＩＤを生成して付与する（Ｓ１０２）。

続いて、タグ格納部３７は、受信されたメッセージから、当該メッセージに含まれるタグを抽出する（Ｓ１０３）。そして、タグ格納部３７は、抽出したタグを１つ選択し（Ｓ１０４）、選択したタグに対応するタグテーブルがデータストア３３に存在するか否かを判定する（Ｓ１０５）。

そして、タグ格納部３７は、選択したタグに対応するタグテーブルが存在する場合（Ｓ１０５肯定）、「Ｋｅｙ＝ＩＤ付与部３６が生成したＩＤ、Ｖａｌｕｅ＝Ｔｒｕｅ」とするレコードを、当該タグテーブルの末尾に追記する（Ｓ１０６）。

一方、タグ格納部３７は、選択したタグに対応するタグテーブルが存在しない場合（Ｓ１０５否定）、選択したタグに対応するタグテーブルをデータストア３３上に新たに生成する（Ｓ１０７）。そして、タグ格納部３７は、「Ｋｅｙ＝ＩＤ付与部３６が生成したＩＤ、Ｖａｌｕｅ＝Ｔｒｕｅ」とするレコードを、生成したタグテーブルの先頭に追記する（Ｓ１０８）。

その後、タグ格納部３７は、抽出したタグが他にも存在すると判定した場合には（Ｓ１０９肯定）、Ｓ１０４に戻って以降の処理を繰り返す。

一方、データ格納部３８は、タグ格納部３７は他にタグが存在しないと判定した場合（Ｓ１０９否定）、受信されたメッセージからデータを抽出してＳ１１０を実行する。すなわち、データ格納部３８は、「Ｋｅｙ＝ＩＤ付与部３６が生成したＩＤ、Ｖａｌｕｅ＝抽出したデータ」とするレコードを、データテーブル３３ｂの末尾に追記する（Ｓ１１０）。

その後、制御部３４は、受信したメッセージをデータストア３３に蓄積したことを示す蓄積完了を、メッセージ送信元のクライアント端末１０に応答する（Ｓ１１１）。なお、上記フローでは、Ｓ１０３からＳ１０９を実行した後にＳ１１０を実行する例を説明したが、これに限定されるものではなく、先にＳ１１０を実行してもよく、並行して実行してもよい。

（検索処理の流れ）
図９は、実施例２に係るタグ管理サーバが実行する検索処理の流れを示すフローチャートである。図９に示すように、タグ管理サーバ３０の要求判定部３５が検索要求を受信したと判定した場合（Ｓ２０１肯定）、検索エンジン３９は、検索要求に含まれるタグを抽出する（Ｓ２０２）。

続いて、検索エンジン３９は、抽出したタグに対応するタグテーブルをデータストア３３から特定し（Ｓ２０３）、特定したタグテーブルを用いてソートマージジョイン処理を実行する（Ｓ２０４）。一例を挙げると、検索エンジン３９は、抽出したタグテーブルに共通して記憶される「ＩＤ（Ｋｅｙ）」を特定する。

そして、検索エンジン３９は、ソートマージジョイン処理によって得られた「ＩＤ」に対応する「データ（Ｖａｌｕｅ）」をデータテーブル３３ｂから検索する（Ｓ２０５）。その後、検索エンジン３９は、検索して得られた「データ」を検索結果として、検索要求元のクライアント端末１０に応答する（Ｓ２０６）。

このように、タグ管理サーバ３０は、タグおよびデータを異なるデータストア３３を用いてＫＶＳ形式で保存することができる。また、タグ管理サーバ３０は、ＩＤで昇順に整列させた状態で、各テーブルにレコードを追加することができる。したがって、タグ管理サーバ３０は、データが大規模になってハードディスク等でデータを記憶する場合でも、ランダムアクセスの発生を抑制することができるので、検索性能を向上させることができる。また、ソートマージジョイン処理を実行してデータを検索する場合でも、ソート処理を実行することなく、ジョイン処理を実行することができるので、処理を高速化することができる。

実施例２では、タグ管理サーバが１台の場合を例にして説明したが、これに限定されるものではなく、複数のタグ管理サーバを用いることもできる。そこで、実施例３では、複数台のタグ管理サーバを用いる例を説明する。なお、実施例３では、複数台のタグ管理サーバを有するシステムの全体構成、タグ管理サーバの構成、処理の流れを説明する。クライアント端末は、実施例２等と同様の構成を有するので詳細な説明は省略する。

［システムの全体構成］
図１０は、実施例３に係るシステムの全体構成例を示す図である。図１０に示すシステムは、クライアント端末１、クライアント端末２、クライアント端末３、タグ管理サーバ５０、タグ管理サーバ６０、タグ管理サーバ７０がネットワークを介して相互に通信可能に接続される。

このシステムは、クライアント端末１−３が、いずれかのタグ管理サーバにタグ付きのデータを送信する。そして、データを受信したタグ管理サーバが、データを蓄積するタグ管理サーバを決定し、決定されたタグ管理サーバが、データを蓄積する。なお、クライアント端末１−３がはじめにアクセスするタグ管理サーバは、システムを構成するタグ管理サーバのうちのいずれでもよいし、アクセスごとに毎回異なってもよい。

また、クライアント端末１−３が、いずれかのタグ管理サーバに検索要求を送信する。そして、検索要求を受信したタグ管理サーバが、自装置を含む全タグ管理サーバに検索要求を転送する。その後、検索要求を転送したタグ管理サーバが、各タグ管理サーバから検索結果を受信して集約し、その結果を検索結果としてクライアント端末１−３に応答する。

なお、ここで例示した装置の数等はあくまで例示であり、これに限定されるものではない。また、実施例３では、クライアント端末からはじめにデータや検索要求を受信するタグ管理サーバを「レセプタ」を呼ぶ場合がある。

［タグ管理サーバの構成］
次に、図１０に示した各タグ管理サーバの構成を説明する。図１０に示したタグ管理サーバ５０、タグ管理サーバ６０、タグ管理サーバ７０は同様の構成を有するので、ここでは、タグ管理サーバ５０について説明する。図１１は、実施例３に係るタグ管理サーバの構成を示す機能ブロック図である。また、ここでは、クライアント端末１がデータ蓄積要求メッセージまたは検索要求をタグ管理サーバ５０に送信したものとする。

図１１に示すように、タグ管理サーバ５０は、ネットワークインタフェース３１と、メモリ３２、データストア３３と、制御部５１とを有する。なお、タグ管理サーバ５０が有する制御部はこれらに限定されるものではなく、例えば、マウスなどの入力部、ディスプレイなどの表示部、記憶媒体からデータを読み出す記憶媒体読取装置等を有していてもよい。また、ネットワークインタフェース３１、メモリ３２、データストア３３は、実施例２と同様の機能を有するので、詳細な説明は省略する。

制御部５１は、ＯＳなどを実行してタグ管理サーバ５０の全体的な制御を司る処理部であり、例えばＣＰＵなどの電子回路である。この制御部５１は、要求判定部５２とＩＤ付与部５３と担当決定部５４と蓄積指示部５４ａとタグ格納部５４ｂとデータ格納部５４ｃと検索集約エンジン５５と検索エンジン５６とを有し、これらによってタグの蓄積や検索を実行する。

要求判定部５２は、実施例２で説明した要求判定部３５と同様の処理を実行する処理部であり、クライアント端末１から受信した情報の種別を判定する処理部である。例えば、要求判定部５２は、クライアント端末１からメッセージを受信した場合に、受信したメッセージをＩＤ付与部に出力する。また、要求判定部５２は、クライアント端末１から検索要求を受信した場合には、受信した検索要求を検索エンジン５６に出力する。

また、要求判定部５２は、レセプタからメッセージおよびＩＤを受信した場合、受信したメッセージおよびＩＤをタグ格納部５４ａとデータ格納部５４ｂに出力する。また、要求判定部５２は、レセプタから検索要求を受信した場合、当該検索要求を検索エンジン５６に出力する。

ＩＤ付与部５３は、実施例２で説明したＩＤ付与部３６と同様の処理を実行する処理部であり、受信したメッセージに、受信した順番に連番となるＩＤを付与する処理部である。ＩＤ付与部５３は、ＩＤを付与したメッセージを蓄積指示部５４ａに出力する。例えば、ＩＤ付与部５３は、「時刻＋サーバ名＋シリアル番号」を「ＩＤ」として生成する。

一例を挙げると、サーバ名がＺであるタグ管理サーバのＩＤ付与部５３は、ＵＮＩＸ（登録商標）時刻1313009112（２０１１年８月１０日２０時４５分１２秒）に５番目に受け付けたメッセージに対して、「1313009112Z0005」をＩＤとして割り振る。そして、ＩＤ付与部５３は、時刻が２０１１年８月１０日２０時４６分に繰り上がった場合には、シリアル番号を０にリセットして、以降のＩＤを生成する。

担当決定部５４は、クライアント端末から送信されたメッセージの格納先となるタグ管理サーバを、シャーディングによって決定する処理部である。具体的には、担当決定部５４は、Ｃｈｏｒｄなどのアルゴリズムや分散ハッシュテーブル（DHT：Distributed Hash Table）などの手法を用いて決定する。

一例を挙げると、各タグ管理サーバは、自装置が担当するハッシュ値または自装置が担当するハッシュ値の範囲をハードディスク等に記憶するとともに、他の装置が担当するハッシュ値またはハッシュ値の範囲をハードディスク等に記憶する。このような状態で、担当決定部５４は、ＩＤ付与部５３が付与したＩＤのハッシュ値を算出する。そして、担当決定部５４は、算出したハッシュ値がどのタグ管理サーバの担当範囲かを特定し、特定したタグ管理サーバを、蓄積処理を担当するサーバと決定する。そして、担当決定部５４は、受信したメッセージおよびＩＤと、決定したタグ管理サーバの情報とを蓄積指示部５４ａに通知する。なお、担当決定部５４が使用するハッシュ関数等は、一般的なＤＨＴで使用されるハッシュ関数を用いる。

蓄積指示部５４ａは、担当決定部５４が決定したタグ管理サーバに対して、クライアント端末が送信したメッセージやＩＤ付与部５３が付与したＩＤを送信する処理部である。例えば、蓄積指示部５４ａは、担当決定部５４からタグ管理サーバ７０のホスト名やＩＰ（Internet Protocol）アドレス等を受信した場合、担当決定部５４から受信したメッセージおよびＩＤをタグ管理サーバ７０に送信する。また、蓄積指示部５４ａは、担当決定部５４から自装置が担当であることを通知された場合、担当決定部５４から受信したメッセージおよびＩＤをタグ格納部５４ｂとデータ格納部５４ｃとに送信する。

タグ格納部５４ｂは、要求判定部５２または蓄積指示部５４ａからメッセージおよびＩＤを受信した場合には、タグの蓄積を実行する。すなわち、タグ格納部５４ｂは、レセプタや担当決定部５４によって自装置が蓄積担当と決定された場合に、タグの蓄積を実行する。なお、具体的な処理は、実施例２と同様の処理なので、詳細な説明は省略する。

データ格納部５４ｃは、要求判定部５２または蓄積指示部５４ａからメッセージおよびＩＤを受信した場合には、データの蓄積を実行する。すなわち、データ格納部５４ｃは、レセプタや担当決定部５４によって自装置が蓄積担当と決定された場合に、データの蓄積を実行する。なお、具体的な処理は、実施例２と同様の処理なので、詳細な説明は省略する。

検索集約エンジン５５は、クライアント端末１から送信された検索要求を他のタグ管理サーバに転送し、各タグ管理サーバから受信した検索結果を集約してクライアント端末１に応答する処理部である。例えば、検索集約エンジン５５は、要求判定部５２がクライアント端末１から検索要求を受信した場合に、当該検索要求を他のタグ管理サーバおよび自装置の検索エンジン５６に送信する。その後、検索集約エンジン５５は、検索要求の送信先である各タグ管理サーバから検索結果を受信する。そして、検索集約エンジン５５は、受信した各検索結果をマージして、検索要求の送信元のクライアント端末１に応答する。

検索エンジン５６は、要求判定部５２または検索集約エンジン５５から検索要求が通知された場合に、実施例２と同様の検索処理を実行する処理部である。例えば、検索エンジン５６は、要求判定部５２から検索要求が通知された場合、すなわちレセプタから送信された検索要求を受信した場合、検索処理を実行し、その結果をレセプタに応答する。また、検索エンジン５６は、検索集約エンジン５５から検索要求が通知された場合、検索処理を実行し、その結果を検索集約エンジン５５に応答する。

［処理の流れ］
次に、タグ管理サーバが実行する処理の流れについて説明する。なお、タグ管理サーバ５０からタグ管理サーバ７０は同様の処理を実行するので、ここでは、タグ管理サーバ５０を例にして説明する。つまり、タグ管理サーバ５０がレセプタや他の装置として処理を実行する場合について説明する。また、クライアント端末が実行する処理は、データ生成処理、タグ付け処理などの一般的な処理なので詳細な説明は省略する。

（蓄積処理の流れ）
図１２は、実施例３に係るタグ管理サーバが実行する蓄積処理の流れを示すフローチャートである。図１２に示すように、タグ管理サーバ５０の要求判定部５２は、メッセージを受信した場合（Ｓ３０１肯定）、メッセージをレセプタから受信したか否かを判定する（Ｓ３０２）。なお、要求判定部５２は、メッセージにＩＤが付与されている場合に、レセプタから受信したと判定することができる。

そして、ＩＤ付与部５３は、要求判定部５２がレセプタでなくクライアント端末１から受信したと判定した場合（Ｓ３０２否定）、受信されたメッセージにＩＤを付与する（Ｓ３０３）。続いて、担当決定部５４は、ＩＤ付与部５３が付与したＩＤのハッシュ値を算出し、算出したハッシュ値に基づいてメッセージを蓄積する担当ノードを決定する（Ｓ３０４）。

その後、蓄積指示部５４ａは、担当決定部５４が決定した担当ノードに対して、クライアント端末１から受信したメッセージとＩＤ付与部５３が付与したＩＤとを送信する（Ｓ３０５）。なお、蓄積指示部５４ａは、担当決定部５４によって自装置が担当ノードと決定された場合には、メッセージとＩＤとをタグ格納部５４ｂとデータ格納部５４ｃとに出力する。この場合、タグ格納部５４ｂとデータ格納部５４ｃとは、実施例２と同様に、タグの格納やデータの格納を実行する。

蓄積指示部５４ａは、メッセージとＩＤとを送信した担当ノードから蓄積処理が完了したことを示す応答を受信した場合（Ｓ３０６肯定）、メッセージの送信元のクライアント端末に当該応答を送信する（Ｓ３０７）。なお、蓄積指示部５４ａは、メッセージとＩＤとをタグ格納部５４ｂとデータ格納部５４ｃとに出力した場合、上記応答をタグ格納部５４ｂとデータ格納部５４ｃとから受信する。

一方、要求判定部５２がクライアント端末１でなくレセプタから受信したと判定した場合（Ｓ３０２肯定）、タグ格納部５４ｂまたはデータ格納部５４ｃは、Ｓ３０９からＳ３１７を実行する。なお、Ｓ３０９からＳ３１７の処理は、実施例２で説明したＳ１０３からＳ１１１と同様の処理なので、詳細な説明は省略する。なお、実施例２と異なる点は、蓄積完了の応答先がクライアント端末ではなくレセプタとなる点である。

（検索処理の流れ）
図１３は、実施例３に係るタグ管理サーバが実行する検索処理の流れを示すフローチャートである。図１３に示すように、タグ管理サーバ５０の要求判定部５２は、検索要求を受信した場合（Ｓ４０１肯定）、検索要求をレセプタから受信したか否かを判定する（Ｓ４０２）。

そして、検索エンジン５６は、要求判定部５２がクライアント端末１ではなくレセプタから受信したと判定した場合（Ｓ４０２肯定）、Ｓ４０３からＳ４０７を実行する。なお、Ｓ４０３からＳ４０７の処理は、実施例２で説明したＳ２０２からＳ２０６と同様の処理なので、詳細な説明は省略する。なお、実施例２と異なる点は、検索結果の応答を送信する先がクライアント端末１ではなくレセプタとなる点である。

一方、検索集約エンジン５５は、要求判定部５２がレセプタではなくクライアント端末から受信したと判定した場合（Ｓ４０２否定）、自ノードを含む全ノードに、受信された検索要求を転送する（Ｓ４０８）。つまり、検索集約エンジン５５は、全ノードに加えて自装置の検索エンジン５６にも検索要求を出力する。

その後、検索エンジン５６は、上述したＳ４０３からＳ４０７と同様の処理を実行して、検索要求に含まれるタグに対応するデータを検索して、その結果を検索集約エンジン５５に出力する。

その後、検索集約エンジン５５は、検索要求の転送先である全ノードおよび自装置の検索エンジン５６から検索結果を受信した場合（Ｓ４０９肯定）、検索結果を集約してクライアント端末に応答する（Ｓ４１０）。

このように、ネットワークで結合された複数のサーバで、それぞれがデータの書き込みを受け付ける。受け付けたサーバが、各自単調増加なＩＤを振る。ＩＤは全体で重複しないよう、また系全体でも極力単調増加になるように生成される。ＩＤに基づきシャーディングを行いデータの担当サーバを決定する。また、実施例３では、データ蓄積時には、データを受け付けサーバから担当サーバに転送するときに通信が発生する。また、実施例３では、シャーディングによりデータがきれいに分割配置されているので、検索処理時には通信せずに、最後に各サーバの検索結果を集約するときにのみ通信が発生する。このように、通信の発生回数を減少させることができる。したがって、ランダムアクセスを抑止することにより、性能向上が見込める以外にも、ＩＤの振り方とシャーディング手法を工夫して通信を極力抑えることができ、スケーラビリティを保持できる。

さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下に異なる実施例を説明する。

（ランダムアクセス）
上記実施例では、データストアに格納されるデータの数に関係なく、ソートマージジョイン処理を実行してデータを検索する例について説明したが、これに限定されるものではない。例えば、格納されているデータ数が所定値よりも少ない場合には、ランダムアクセスを実行してデータを検索し、格納されているデータ数が所定値以上である場合には、上記実施例の手法を用いてデータを検索するようにしてもよい。

データの格納数が少ない状態では、ランダムアクセスが発生した場合でもアクセスできる範囲が小さいために、ランダムアクセスの方が早く検索処理の実行することができる。なお、所定値は、ディスクの回転数等によって決定することができ、１００件、もしくは全データ数の千分の一など管理者等によって予め指定することもできる。

（データ本体を保持）
上記実施例では、タグ管理サーバは、ＩＤとダミーデータとを対応付けてタグテーブルに格納する例を説明したが、これに限定されるものではない。例えば、タグ管理サーバは、タグテーブルに格納されるデータ数が１００件など少ない場合には、タグテーブルにデータそのものを格納してもよい。または、データのうち頻繁に使用する部分つまりデータのサブセットをタグテーブルに格納してもよい。詳しくは、タグ管理サーバは、データ数が所定値になるまで、「ＩＤ、データ」を各タグテーブルに格納する。なお、ここで格納されるデータとは、例えばデータのサブネットなどである。この場合、タグ管理サーバは、データテーブルを検索せずにタグテーブルだけで、検索対象のタグに対応するデータを検索することができるので、検索処理をより高速化することができる。

（バッファの利用）
例えば、ＩＤの振り方や、データの転送にかかる時間の影響で、担当サーバにメッセージとＩＤとが到着する順序が、ＩＤの単調増加にならず、順序が逆転する場合もあるが、この順序逆転をメモリ上のバッファで吸収することができる。具体的には、タグ管理サーバは、クライアント端末またはレセプタからメッセージおよびＩＤを受信した場合に、一度メモリ上のバッファに格納する。なお、バッファは、タグテーブルごとに有していてもよく、その場合には、タグテーブルが新たに生成された場合には、メモリ上に新たなバッファ領域を設けることになる。

そして、タグ管理サーバは、バッファ上のメッセージをＩＤでソートしてから、該当するタグテーブルに格納する。このようにすることで、連続してメッセージを受信した場合やＩＤの順番通りにメッセージを受信できなかった場合でも、タグテーブル等にソートされた状態でＩＤ等を格納することができる。また、ＩＤの振り方とデータの転送時間から、データが遅れて到着しうる時間を算出することができるので、この時間とデータの最大スループットからバッファすべきデータのサイズを決定することもできる。

（データ格納位置）
上記実施例では、タグテーブルやデータテーブルの末尾に新たなレコードを格納することで、ＩＤで昇順にソートされたテーブルを生成する例について説明したが、これに限定されるものではない。例えば、タグ管理サーバは、新たなレコードを各テーブルの先頭に格納してもよい。この結果、タグ管理サーバは、ＩＤで降順にソートされたテーブルを生成することができるので、上記実施例と同様の検索処理を実行することができる。

（識別子）
上記実施例では、受信した順番が識別可能となるような単調増加な識別子を付与する場合について説明したが、これに限定されるものではない。例えば、受信した順番が識別可能となるような単調減少な数もしくは辞書順に並んだ文字列などのソート不要な識別子を付与することもできる。つまり、タグ管理サーバは、受信された順番でタグテーブルやデータテーブルにレコードをした際に、各テーブルに記憶される情報が識別子でソートされた状態になるような識別子を付与する。

（システム）
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともできる。あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

（プログラム）
ところで、上記の実施例で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータシステムで実行することによって実現することができる。そこで、以下では、上記の実施例と同様の機能を有するプログラムを実行するコンピュータシステムの一例を説明する。

図１４は、タグ管理プログラムを実行するコンピュータのハードウェア構成例を示す図である。図１４に示すように、コンピュータ１００は、ＣＰＵ１０２、入力装置１０３、出力装置１０４、通信インタフェース１０５、媒体読み取り装置１０６、ＨＤＤ（Hard Disk Drive）１０７、ＲＡＭ（Random Access Memory）１０８を有する。また、図１４に示した各部は、バス１０１で相互に接続される。

入力装置１０３は、マウスやキーボードであり、出力装置１０４は、ディスプレイなどであり、通信インタフェース１０５は、ＮＩＣなどのインタフェースである。ＨＤＤ１０７は、タグ管理プログラム１０７ａとともに、図５や図６に示した各テーブル等を記憶する。記録媒体の例としてＨＤＤ１０７を例に挙げたが、ＲＯＭ（Read Only Memory）、ＲＡＭ、ＣＤ−ＲＯＭ等の他のコンピュータ読み取り可能な記録媒体に各種プログラムを格納しておき、コンピュータに読み取らせることとしてもよい。なお、記録媒体を遠隔地に配置し、コンピュータが、その記憶媒体にアクセスすることでプログラムを取得して利用してもよい。また、その際、取得したプログラムをそのコンピュータ自身の記録媒体に格納して用いてもよい。

ＣＰＵ１０２は、タグ管理プログラム１０７ａを読み出してＲＡＭ１０８に展開することで、図４や図１１等で説明した各機能を実行するタグ管理プロセス１０８ａを動作させる。すなわち、タグ管理プロセス１０８ａは、図４に記載した要求判定部３５、ＩＤ付与部３６、タグ格納部３７、データ格納部３８、検索エンジン３９と同様の機能を実行する。また、タグ管理プロセス１０８ａは、図１１に記載した要求判定部５２、ＩＤ付与部５３、担当決定部５４、蓄積指示部５４ａ、タグ格納部５４ｂ、データ格納部５４ｃ、検索集約エンジン５５、検索エンジン５６と同様の機能を実行する。このようにコンピュータ１００は、プログラムを読み出して実行することでタグ管理方法を実行する情報処理装置として動作する。

また、コンピュータ１００は、媒体読取装置１０６によって記録媒体からタグ管理プログラムを読み出し、読み出されたタグ管理プログラムを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、コンピュータ１００によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。

１、２、３、２０ クライアント端末
１０、３０、５０ タグ管理サーバ
１１ 第１記憶部
１２ 第２記憶部
１３ 付与部
１４ 第１記憶制御部
１５ 第２記憶制御部
１６ 検索部
２１ ネットワークインタフェース
２２ 記憶部
２３ 制御部
２４ データ生成エンジン
２５ タグ付加エンジン
３１ ネットワークインタフェース
３２ メモリ
３２ａ バッファ
３３ データストア
３３ａ−１、３３ａ−ｎ タグテーブル
３３ｂ データテーブル
３４、５１ 制御部
３５、５２ 要求判定部
３６、５３ ＩＤ付与部
３７、５４ｂ タグ格納部
３８、５４ｃ データ格納部
３９、５６ 検索エンジン
５４ 担当決定部
５４ａ 蓄積指示部
５５ 検索集約エンジン

Claims (13)

1. タグとデータを有するメッセージを受信し、受信したメッセージに、受信した順番が識別可能となるような単調増加または単調減少な数もしくは辞書順に並んだ文字列のいずれかを用いたソート不要な識別子を付与する付与部と、
   前記受信したメッセージに含まれるタグに対応する第１記憶部が存在する場合は、前記付与部によって付与される識別子を順に記憶させ、前記受信したメッセージに含まれるタグに対応する第１記憶部が存在しない場合は、前記タグに対応する第１記憶部を生成し、生成した第１記憶部に、前記付与部によって付与される識別子を順に記憶させる第１記憶制御部と、
   前記受信したメッセージに含まれるデータと前記付与部によって付与される識別子とを対応付けて第２記憶部に順に記憶させる第２記憶制御部と、
   検索対象のタグに対応する前記第１記憶部に記憶される情報と前記第２記憶部に記憶される情報とを内部結合または外部結合させて、前記検索対象のタグに対応付けられたデータを検索する検索部と
   を有することを特徴とするタグ管理装置。
2. 前記第１記憶制御部は、前記受信したメッセージが所定値未満の場合には、前記受信したメッセージに含まれるデータに付与されたタグに対応する第１記憶部に、前記付与部によって付与される識別子に対応付けて前記データを記憶させることを特徴とする請求項１に記載のタグ管理装置。
3. 前記検索部は、前記第２記憶部に記憶されるデータの数が所定値未満の場合には、前記検索対象のタグに対応する前記第１記憶部にランダムアクセスして前記検索対象のタグに対応付けられる識別子を特定し、特定した識別子に対応するデータを前記第２記憶部から検索することを特徴とする請求項１に記載のタグ管理装置。
4. 前記付与部は、複数のタグとデータとを有するメッセージを受信し、受信したメッセージに前記識別子を付与し、
   前記第１記憶制御部は、受信したメッセージに含まれる前記複数のタグのそれぞれに対応する全第１記憶部に、前記付与部によって付与された識別子のみを順に記憶させ、
   前記検索部は、複数のタグで構成された検索要求を受信し、前記検索要求の各タグがＡＮＤ条件で構成される場合は、各タグに対応する各第１記憶部に共通に記憶される前記識別子を特定する内部結合を実行し、前記検索要求の各タグがＯＲ条件で構成される場合は、各タグに対応する各第１記憶部のいずれかに記憶される前記識別子を特定する外部結合を実行し、特定された識別子に対応付けられる前記データを前記第２記憶部から検索することを特徴とする請求項１に記載のタグ管理装置。
5. クライアント端末から受信したデータを蓄積する複数のタグ管理装置を有するタグ管理システムであって、
   前記複数のタグ管理装置各々は、
   タグとデータを有するメッセージを前記クライアント端末から受信し、受信したメッセージに、受信した順番が識別可能となるような単調増加または単調減少な数もしくは辞書順に並んだ文字列のいずれかを用いたソート不要な識別子を付与する付与部と、
   前記付与部によって付与される識別子を用いて算出した値に基づいて、前記データの蓄積を担当するノードを決定する担当決定部と、
   前記担当決定部によって決定されたノードに前記データと前記識別子とを転送する転送部と、
   前記担当決定部によって自装置が蓄積を担当するノードと決定された場合、または、他のタグ管理装置から前記データと前記識別子とを受信した場合、前記受信したデータに付与されたタグに対応する第１記憶部が存在する場合は、前記識別子を順に記憶させ、前記受信したメッセージに含まれるタグに対応する第１記憶部が存在しない場合は、前記タグに対応する第１記憶部を生成し、生成した第１記憶部に、前記付与部によって付与される識別子を順に記憶させる第１記憶制御部と、
   前記担当決定部によって自装置が蓄積を担当するノードと決定された場合、または、他のタグ管理装置から前記データと前記識別子とを受信した場合、前記データと前記識別子とを対応付けて第２記憶部に順に記憶させる第２記憶制御部と、
   を有することを特徴とするタグ管理システム。
6. 前記クライアント端末から少なくとも１つのタグを含む検索要求を受信した場合に、自装置を含む各タグ管理装置に前記検索要求を転送する転送部と、
   前記検索要求に含まれるタグに対応する前記第１記憶部に記憶される情報と前記第２記憶部に記憶される情報とを内部結合または外部結合させて、前記検索要求に含まれるタグに対応付けられたデータを検索する検索部と、
   前記検索部による検索結果と前記各タグ管理装置から受信した検索結果とを集約して、前記クライアント端末に応答する応答部とをさらに有することを特徴とする請求項５に記載のタグ管理システム。
7. 前記第１記憶制御部は、前記第１記憶部に前記識別子を追加する前に、メモリ上に確保したバッファで前記他のタグ管理装置から受信したデータと識別子との組をソートし、ソートした順で前記第１記憶部に格納することを特徴とする請求項５に記載のタグ管理システム。
8. 前記第２記憶制御部は、前記第２記憶部に前記データと前記識別子とを対応付けて追加する前に、メモリ上に確保したバッファで前記他のタグ管理装置から受信したデータと識別子との組をソートし、ソートした順で前記第１記憶部に格納することを特徴とする請求項５に記載のタグ管理システム。
9. 前記付与部は、複数のタグとデータとを有するメッセージを受信し、受信したメッセージに前記識別子を付与し、
   前記第１記憶制御部は、受信したメッセージに含まれる前記複数のタグのそれぞれに対応する全第１記憶部に、前記付与部によって付与された識別子のみを順に記憶させ、
   前記転送部は、複数のタグで構成された検索要求を受信し、受信した前記検索要求を前記各タグ管理装置に転送し、
   前記検索部は、前記検索要求の各タグがＡＮＤ条件で構成される場合は、各タグに対応する各第１記憶部に共通に記憶される前記識別子を特定する内部結合を実行し、前記検索要求の各タグがＯＲ条件で構成される場合は、各タグに対応する各第１記憶部のいずれかに記憶される前記識別子を特定する外部結合を実行し、特定された識別子に対応付けられる前記データを前記第２記憶部から検索することを特徴とする請求項６に記載のタグ管理システム。
10. コンピュータに、
    タグとデータを有するメッセージを受信し、受信したメッセージに、受信した順番が識別可能となるような単調増加または単調減少な数もしくは辞書順に並んだ文字列のいずれかを用いたソート不要な識別子を付与し、
    前記受信したメッセージに含まれるタグに対応する第１記憶部が存在する場合は、前記識別子を順に記憶させ、前記受信したメッセージに含まれるタグに対応する第１記憶部が存在しない場合は、前記タグに対応する第１記憶部を生成し、生成した第１記憶部に、前記識別子を順に記憶させ、
    前記受信したメッセージに含まれるデータと前記付与した識別子とを対応付けて第２記憶部に順に記憶させ、
    検索対象のタグに対応する前記第１記憶部に記憶される情報と前記第２記憶部に記憶される情報とを内部結合または外部結合させて、前記検索対象のタグに対応付けられたデータを検索する
    各処理を実行させることを特徴とするタグ管理プログラム。
11. 前記付与する処理は、複数のタグとデータとを有するメッセージを受信し、受信したメッセージに前記識別子を付与し、
    前記第１記憶部に記憶させる処理は、受信したメッセージに含まれる前記複数のタグのそれぞれに対応する全第１記憶部に、前記識別子のみを順に記憶させ、
    前記検索する処理は、複数のタグで構成された検索要求を受信し、前記検索要求の各タグがＡＮＤ条件で構成される場合は、各タグに対応する各第１記憶部に共通に記憶される前記識別子を特定する内部結合を実行し、前記検索要求の各タグがＯＲ条件で構成される場合は、各タグに対応する各第１記憶部のいずれかに記憶される前記識別子を特定する外部結合を実行し、特定された識別子に対応付けられる前記データを前記第２記憶部から検索することを特徴とする請求項１０に記載のタグ管理プログラム。
12. コンピュータに、
    タグとデータを有するメッセージをクライアント端末から受信し、受信したメッセージに、受信した順番が識別可能となるような単調増加または単調減少な数もしくは辞書順に並んだ文字列のいずれかを用いたソート不要な識別子を付与し、
    前記付与した識別子を用いて算出した値に基づいて、前記データの蓄積を担当するノードを決定し、
    前記決定したノードに前記データと前記識別子とを転送し、
    前記コンピュータが蓄積を担当するノードと決定された場合、または、他のノードから前記データと前記識別子とを受信した場合、前記受信したデータに付与されたタグに対応する第１記憶部が存在する場合は、前記識別子を順に記憶させ、前記受信したメッセージに含まれるタグに対応する第１記憶部が存在しない場合は、前記タグに対応する第１記憶部を生成し、生成した第１記憶部に、前記識別子を順に記憶させ、
    前記コンピュータが蓄積を担当するノードと決定された場合、または、他のノードから前記データと前記識別子とを受信した場合、前記データと前記識別子とを対応付けて第２記憶部に順に記憶させる、
    各処理を実行させることを特徴とするタグ管理プログラム。
13. 前記付与する処理は、複数のタグとデータとを有するメッセージを受信し、受信したメッセージに前記識別子を付与し、
    前記第１記憶部に記憶させる処理は、受信したメッセージに含まれる前記複数のタグのそれぞれに対応する全第１記憶部に、前記識別子のみを順に記憶させ、
    前記コンピュータに、
    複数のタグで構成された検索要求を受信し、前記検索要求の各タグがＡＮＤ条件で構成される場合は、各タグに対応する各第１記憶部に共通に記憶される前記識別子を特定する内部結合を実行し、前記検索要求の各タグがＯＲ条件で構成される場合は、各タグに対応する各第１記憶部のいずれかに記憶される前記識別子を特定する外部結合を実行し、特定された識別子に対応付けられる前記データを前記第２記憶部から検索する処理をさらに実行させることを特徴とする請求項１２に記載のタグ管理プログラム。

Images