受信したデータに、受信した順番が識別可能となるような単調増加または単調減少な数もしくは辞書順に並んだ文字列などのソート不要な識別子を付与する付与部と、前記受信したデータに付与されたタグに対応する第1記憶部に、前記付与部によって付与される識別子を順に記憶させる第1記憶制御部と、前記受信したデータと前記付与部によって付与される識別子とを対応付けて第2記憶部に順に記憶させる第2記憶制御部と、検索対象のタグに対応する記憶部が前記第1記憶部である場合に、前記第1記憶部に記憶される情報と前記第2記憶部に記憶される情報とを内部結合または外部結合させて、前記検索対象のタグに対応付けられたデータを検索する検索部とを有することを特徴とするタグ管理装置。前記第1記憶制御部は、前記受信したデータが所定値未満の場合には、前記受信したデータに付与されたタグに対応する第1記憶部に、前記付与部によって付与される識別子に対応付けて前記データを記憶させることを特徴とする請求項1に記載のタグ管理装置。前記検索部は、前記受信したデータが所定値未満の場合には、前記検索対象のタグに対応する前記第1記憶部にランダムアクセスして前記検索対象のタグに対応付けられる識別子を特定し、特定した識別子に対応するデータを前記第2記憶部から検索することを特徴とする請求項1に記載のタグ管理装置。クライアント端末から受信したデータを蓄積する複数のタグ管理装置を有するタグ管理システムであって、前記複数のタグ管理装置各々は、前記クライアント端末から受信したデータに、受信した順番が識別可能となるような単調増加または単調減少な数もしくは辞書順に並んだ文字列などのソート不要な識別子を付与する付与部と、前記付与部によって付与される識別子を用いて算出した値に基づいて、前記データの蓄積を担当するノードを決定する担当決定部と、前記担当決定部によって決定されたノードに前記データと前記識別子とを転送する転送部と、前記担当決定部によって自装置が蓄積を担当するノードと決定された場合、または、他のタグ管理装置から前記データと前記識別子とを受信した場合、前記受信したデータに付与されたタグに対応する第1記憶部に、前記識別子を順に記憶させる第1記憶制御部と、前記担当決定部によって自装置が蓄積を担当するノードと決定された場合、または、他のタグ管理装置から前記データと前記識別子とを受信した場合、前記データと前記識別子とを対応付けて第2記憶部に順に記憶させる第2記憶制御部と、を有することを特徴とするタグ管理装置。前記クライアント端末から少なくとも1つのタグを含む検索要求を受信した場合に、自装置を含む各タグ管理装置に前記検索要求を転送する転送部と、前記検索要求に含まれるタグに対応する記憶部が前記第1記憶部である場合に、前記第1記憶部に記憶される情報と前記第2記憶部に記憶される情報とを内部結合または外部結合させて、前記検索要求に含まれるタグに対応付けられたデータを検索する検索部と、前記検索部による検索結果と前記各タグ管理装置から受信した検索結果とを集約して、前記クライアント端末に応答する応答部とをさらに有することを特徴とする請求項4に記載のタグ管理装置。前記第1記憶制御部は、前記第1記憶部に前記識別子を追加する前に、メモリ上に確保したバッファで前記他のタグ管理装置から受信したデータと識別子との組をソートし、ソートした順で前記第1記憶部に格納することを特徴とする請求項4に記載のタグ管理装置。前記第2記憶制御部は、前記第2記憶部に前記データと前記識別子とを対応付けて追加する前に、メモリ上に確保したバッファで前記他のタグ管理装置から受信したデータと識別子との組をソートし、ソートした順で前記第1記憶部に格納することを特徴とする請求項4に記載のタグ管理装置。コンピュータに、受信したデータに、受信した順番が識別可能となるような単調増加または単調減少な数もしくは辞書順に並んだ文字列などのソート不要な識別子を付与し、前記受信したデータに付与されたタグに対応する第1記憶部に、前記付与した識別子を順に記憶させ、前記受信したデータと前記付与した識別子とを対応付けて第2記憶部に順に記憶させ、検索対象のタグに対応する記憶部が前記第1記憶部である場合に、前記第1記憶部に記憶される情報と前記第2記憶部に記憶される情報とを内部結合または外部結合させて、前記検索対象のタグに対応付けられたデータを検索する各処理を実行させることを特徴とするタグ管理プログラム。コンピュータに、クライアント端末から受信したデータに、受信した順番が識別可能となるような単調増加または単調減少な数もしくは辞書順に並んだ文字列などのソート不要な識別子を付与し、前記付与した識別子を用いて算出した値に基づいて、前記データの蓄積を担当するノードを決定し、前記決定したノードに前記データと前記識別子とを転送し、自装置が蓄積を担当するノードと決定された場合、または、他のノードから前記データと前記識別子とを受信した場合、前記受信したデータに付与されたタグに対応する第1記憶部に、前記識別子を順に記憶させ、前記自装置が蓄積を担当するノードと決定された場合、または、他のノードから前記データと前記識別子とを受信した場合、前記データと前記識別子とを対応付けて第2記憶部に順に記憶させる、各処理を実行させることを特徴とするタグ管理プログラム。しかしながら、従来技術では、センサデータやライフログのように逐次データが追加される、タグ付けされた大規模なデータを検索する場合には、ランダムアクセスが発生し、検索性能が劣化するという問題がある。一般的には、サーバ等は、メモリ上で大規模なタグ付きデータを保持できないので、ディスク上でDBMSDataBaseManagementSystem等を用いて保持することになる。そして、サーバ等は、指定されたタグに対応するデータを大規模なタグ付きデータから検索する場合、ランダムアクセスを用いてデータを検索する。このため、検索要求が大量に発生した場合に、ディスクのランダムアクセスが大量に発生し、検索結果を応答するまでにかかる時間が長くなる。1つの側面では、検索性能を向上させるタグ管理装置およびタグ管理プログラムを提供することを目的とする。第1の案では、タグ管理装置は、受信したデータに、受信した順番が識別可能となるような単調増加または単調減少な数もしくは辞書順に並んだ文字列などのソート不要な識別子を付与する付与部を有する。また、タグ管理装置は、前記受信したデータに付与されたタグに対応する第1記憶部に、前記付与部によって付与される識別子を順に記憶させる第1記憶制御部を有する。また、タグ管理装置は、前記受信したデータと前記付与部によって付与される識別子とを対応付けて第2記憶部に順に記憶させる第2記憶制御部を有する。また、タグ管理装置は、検索対象のタグに対応する記憶部が前記第1記憶部である場合に、前記第1記憶部に記憶される情報と前記第2記憶部に記憶される情報とを内部結合または外部結合させて、前記検索対象のタグに対応付けられたデータを検索する検索部を有する。検索性能を向上させることができる。以下に、本願の開示するタグ管理装置およびタグ管理プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。図1は、実施例1に係るシステムの全体構成例を示す図である。図1に示すシステムは、クライアント端末1、クライアント端末2、クライアント端末3、タグ管理サーバ10がネットワーク5を介して相互に通信可能に接続される。このシステムは、各クライアント端末がタグ管理サーバ10にタグ付きのデータを送信し、タグ管理サーバ10がタグ付きのデータを管理する。なお、ここで例示した装置の数等はあくまで例示であり、これに限定されるものではない。クライアント端末1、クライアント端末2、クライアント端末3は、タグ管理サーバ10にデータの書き込みを要求したり、データの検索を要求したりするコンピュータ装置である。例を挙げると、各クライアント端末は、演算処理等によって得られたデータにタグを付加したメッセージを生成し、生成したメッセージをタグ管理サーバ10に送信する。また、各クライアント端末は、外部装置から受信したライフログなどのデータにタグを付加したメッセージを生成し、生成したメッセージをタグ管理サーバ10に送信する。外部装置の例としては、車両に搭載されて交通情報をクライアント端末に送信する装置や、温度や湿度を計測してクライアント端末に送信する装置などがある。タグ管理サーバ10は、第1記憶部11と第2記憶部12と付与部13と第1記憶制御部14と第2記憶制御部15と検索部16とを有し、これらによって各クライアント端末から受信したデータを管理するサーバ装置である。付与部13は、クライアント端末1-3から受信したデータに、受信した順番が識別可能となるような単調増加または単調減少な数もしくは辞書順に並んだ文字列などのソート不要な識別子を付与する。第1記憶制御部14は、受信したデータに付与されたタグに対応する第1記憶部11に、付与部13によって付与される識別子を順に記憶させる。第2記憶制御部15は、受信したデータと付与部13によって付与される識別子とを対応付けて第2記憶部12に順に記憶させる。このときどちらのテーブルも、追加する識別子はテーブルの最後に追加する。検索部16は、検索対象のタグに対応する記憶部が第1記憶部11である場合に、第1記憶部11に記憶される情報と第2記憶部12に記憶される情報とを内部結合または外部結合させて、検索対象のタグに対応付けられたデータを検索する。このように、タグ管理サーバ10は、受信した順番が識別可能となるような単調増加または単調減少な数もしくは辞書順に並んだ文字列などのソート不要な識別子を付加して、受信したデータのタグと付与した識別子とを受信順で記憶する。また、タグ管理サーバ10は、受信したデータに識別子を対応付けて、受信した順でデータを記憶する。このため、タグ管理サーバ10は、検索対象のタグがクライアント等によって指定された場合に、検索対象のタグに対応するタグテーブルとデータテーブルとを、識別子の一致を条件としたジョインの手法を用いてデータを特定することができる。このときジョインの手法としてソートマージジョインの手法を用いる場合、テーブルは単調増加な識別子を追記のみで構成しているので、識別子でソート済みである。よって、ソートマージジョインにおけるソートの段階を省略し、マージの段階のみでデータを特定することができる。その結果ソートの段階で発生しうるランダムアクセスを全て抑止できる。したがって、タグ管理サーバ10は、データが大規模になってハードディスク等でデータを記憶する場合でも、ランダムアクセスの発生を抑制することができるので、検索性能を向上させることができる。次に、実施例1で説明したクライアント端末1-3およびタグ管理サーバ10の構成、処理の流れ等を説明する。なお、図1に示したクライアント端末は同様の構成を有するので、ここでは、クライアント端末20として説明する。また、タグ管理サーバ10は、実施例1で有する機能以外についても説明するので、実施例2ではタグ管理サーバ30として説明する。[クライアント端末の構成]図2は、実施例2に係るクライアント端末の構成を示す機能ブロック図である。図2に示すように、クライアント端末20は、ネットワークインタフェース21と、記憶部22と、制御部23とを有する。なお、クライアント端末20が有する制御部はこれらに限定されるものではなく、例えば、マウスなどの入力部、ディスプレイなどの表示部、記憶媒体からデータを読み出す記憶媒体読取装置等を有していてもよい。ネットワークインタフェース21は、他の装置の通信を制御するNICNetworkInterfaceCardなどである。ネットワークインタフェース21は、外部装置からセンサデータやライブログなどの各種データを受信し、タグ管理サーバ10にメッセージを送信する。記憶部22は、制御部23が実行するプログラムやデータ等を記憶する記憶装置であり、例えば半導体メモリ素子やハードディスクなどの記憶装置である。制御部23は、OSOperatingSystemなどを実行してクライアント端末20の全体的な制御を司る処理部であり、例えばCPUCentralProcessingUnitなどの電子回路である。制御部23は、データ生成エンジン24とタグ付加エンジン25とを有し、これらによってメッセージをタグ管理サーバ30に送信する。データ生成エンジン24は、送信対象となるデータを生成する処理部である。例えば、データ生成エンジン24は、アプリケーション等を実行してデータを生成し、生成したデータをタグ付加エンジン25に出力する。また、データ生成エンジン24は、外部装置からデータを受信した場合には、受信したデータをタグ付加エンジン25に出力する。タグ付加エンジン25は、データ生成エンジン24から受け付けたデータに付与するタグを決定し、決定したタグをデータに付与したメッセージを生成してタグ管理サーバ30に送信する処理部である。タグ付加エンジン25は、クライアントの固有番号やセンサーの設置場所などの固定タグを付与してもよく、データの中身を参照してデータの中身を特定する情報を動的に選択してタグとして付加してもよい。図3は、クライアント端末がタグ管理サーバに送信するメッセージの例を示す図である。この例では、クライアント端末が渋滞情報などの交通情報を送信する例で説明する。図3に示すように、クライアント端末が送信するメッセージは、タグ、データが対応付けられている。このタグは、タグ付加エンジン25が付加したタグを示し複数あってもよい、データは、データ生成エンジン24がタグ付加エンジン25に送信したデータを示す。データは、例えばGPSGlobalPositioningSystemの出力で、緯度経度時刻高度であるが、図3においては、簡略化のためイベントとして記述している。図3の場合、イベントAにはタグとして曜日時間:月曜9時-10時と場所:A県B市C町が付加されていることを示す。また、イベントBにはタグとして曜日時間:火曜12時-13時と場所:A県E市F区と道路:混雑とが付加されていることを示す。[タグ管理サーバの構成]図4は、実施例2に係るタグ管理サーバの構成を示す機能ブロック図である。図4に示すように、タグ管理サーバ30は、ネットワークインタフェース31と、メモリ32、データストア33と、制御部34とを有する。なお、タグ管理サーバ30が有する制御部はこれらに限定されるものではなく、例えば、マウスなどの入力部、ディスプレイなどの表示部、記憶媒体からデータを読み出す記憶媒体読取装置等を有していてもよい。ネットワークインタフェース31は、他の装置の通信を制御するNICなどである。ネットワークインタフェース31は、各クライアント端末からメッセージを受信し、メッセージに含まれるデータの蓄積結果を示す応答を送信する。また、ネットワークインタフェース31は、各クライアント端末から検索要求を受信し、その応答を送信する。メモリ32は、制御部34が実行するプログラムやデータ等を記憶する記憶装置であり、バッファ32aを有する。バッファ32aは、クライアント端末から受信したデータをデータストア33に格納する前に、一時的に格納する記憶領域である。データストア33は、CSV形式など追記型でデータを保持するデータストアであり、タグテーブル33a-1からタグテーブル33a-nnは自然数とデータテーブル33bを有する。なお、このデータストア33は、例えばハードディスクなどの記憶装置に設けられる。タグテーブル33a-1からタグテーブル33a-nは、タグごとに設けられるテーブルであり、動的に生成される。図5は、タグテーブルの例を示す図である。図5に示すように、1つのタグテーブルはkey、Valueを有する。つまり、タグテーブルは、KVSキーバリューストアと同様の方式で管理される。Keyは、制御部34によって生成されたIDであり、Valueは、KVSを構成するためのダミーデータである。タグテーブルは、KVSの方式にこだわらずRDBRelationalDataBaseの表形式のような形で管理してもよい。図5の場合、タグとして曜日時間:火曜12-13時、曜日時間:月曜9-10時、場所:A県E市F区、場所:A県B市C町、道路:混雑が存在し、これらのタグ各々に対応したタグテーブルが形成されている。例を挙げると、タグテーブル33a-1が曜日時間:火曜12-13時のタグテーブルであり、タグテーブル33a-2が曜日時間:月曜9-10時のタグテーブルである。また、タグテーブル33a-3が場所:A県E市F区のタグテーブルであり、タグテーブル33a-4が場所:A県B市C町のタグテーブルであり、タグテーブル33a-5が道路:混雑のタグテーブルである。曜日時間:火曜12-13時のタグテーブルで説明すると、このタグテーブルには、Key、Valueとして00003879、Trueと00037192、Trueが対応付けて記憶される。ここで記憶される順番は、データが受信された順番すなわちIDが付与された順番で記憶される。つまり、次に新たなID01234567を格納する場合には、00037192、Trueの後ろすなわち末尾に格納される。なお、ここで示したIDやタグの形式は、あくまで例示であり、これに限定されるものではない。データテーブル33bは、クライアント端末から受信されたデータとID付与部36によって付与されたIDとを対応付けて記憶するテーブルである。図6は、データテーブルに記憶される情報の例を示す図である。図6に示すように、データテーブル33bは、KeyとValueで構成される。すなわち、データテーブル33bは、タグテーブルと同様の形式で管理される。図6に示すKeyは、ID付与部36によって付与されたIDであり、Valueは、クライアント端末から受信したメッセージに含まれるデータである。図6は、Key=00000001にデータイベントAが対応付けられており、Key=00003879にデータイベントBが対応付けられていることを示す。ここで記憶される順番は、データが受信された順番すなわちIDが付与された順番で記憶される。なお、ここで示したIDやタグの形式は、あくまで例示であり、これに限定されるものではない。制御部34は、OSなどを実行してタグ管理サーバ30の全体的な制御を司る処理部であり、例えばCPUなどの電子回路である。この制御部34は、要求判定部35とID付与部36とタグ格納部37とデータ格納部38と検索エンジン39とを有し、これらによってタグの蓄積や検索を実行する。要求判定部35は、クライアント端末10から受信した情報の種別を判定する処理部である。例えば、要求判定部35は、クライアント端末10からデータ蓄積要求メッセージを受信した場合に、受信したデータ蓄積要求メッセージをID付与部36に出力する。また、要求判定部35は、クライアント端末10から検索要求を受信した場合には、受信した検索要求を検索エンジン39に出力する。また、要求判定部35は、受信したメッセージ内にイベント情報とタグが存在する場合には蓄積要求と判定してID付与部36に出力し、受信したメッセージ内にタグしか存在しない場合には検索要求と判定して検索エンジン39に出力することもできる。ID付与部36は、受信したメッセージに、受信した順番に連番となるIDを付与する処理部である。ID付与部36は、IDを付与したメッセージをタグ格納部37とデータ格納部38とに出力する。例えば、ID付与部36は、時刻シリアル番号をIDとして生成する。時刻は、メッセージを受信した時刻であり、パケットのヘッダ等から取得できる。IDは、到着順に単純増加なカウンタ値である。また、ID付与部36は、時刻が繰り上がった場合には、シリアル番号をリセットする。一般的なOSは、ミリ秒単位の精度で時刻を得られるので、これを利用することもできる。一例を挙げると、ID付与部36は、UNIX登録商標時刻13130091122011年8月10日20時45分12秒に5番目に受け付けたメッセージに対して、13130091120005をIDとして割り振る。そして、ID付与部36は、時刻が2011年8月10日20時46分に繰り上がった場合には、シリアル番号を0にリセットして、以降のIDを生成する。タグ格納部37は、受信したメッセージに付与されたタグに対応するタグテーブルに、ID付与部36によって付与されたIDを追加する。そして、タグ格納部37は、タグテーブルへのID格納を完了したことを制御部34やデータ格納部38に通知する。ここで、タグ格納部37が、ID=00003879が付与されたメッセージタグ=曜日時間:火曜12-13時、場所:A県E市F区、道路:混雑、データ=イベントBを、ID付与部36から受信した例で説明する。この場合、タグ格納部37は、受信したメッセージからタグとして、曜日時間:火曜12-13時と場所:A県E市F区と道路:混雑とを抽出する。同様に、タグ格納部37は、メッセージに付与されるID=00003879を抽出する。そして、タグ格納部37は、タグ曜日時間:火曜12-13時に対応するタグテーブルがデータストア33上に存在するか否かを判定する。存在する場合には、タグ格納部37は、当該タグテーブルの末尾のレコードを特定し、特定したレコードの次のレコードとしてKey=00003879、Value=Trueを追記する。存在しない場合には、タグ格納部37は、タグ曜日時間:火曜12-13時に対応するタグテーブルをデータストア33に新たに生成し、生成したタグテーブルの先頭にKey=00003879、Value=Trueを格納する。同様に、タグ格納部37は、タグ場所:A県E市F区に対応するタグテーブルがデータストア33上に存在するか否かを判定する。存在する場合には、タグ格納部37は、当該タグテーブルの末尾のレコードを特定し、特定したレコードの次のレコードとしてKey=00003879、Value=Trueを追記する。存在しない場合には、タグ格納部37は、タグ場所:A県E市F区に対応するタグテーブルをデータストア33に新たに生成し、生成したタグテーブルの先頭にKey=00003879、Value=Trueを格納する。同様に、タグ格納部37は、タグ道路:混雑に対応するタグテーブルがデータストア33上に存在するか否かを判定する。存在する場合には、タグ格納部37は、当該タグテーブルの末尾のレコードを特定し、特定したレコードの次のレコードとしてKey=00003879、Value=Trueを追記する。存在しない場合には、タグ格納部37は、タグ道路:混雑に対応するタグテーブルをデータストア33に新たに生成し、生成したタグテーブルの先頭にKey=00003879、Value=Trueを格納する。つまり、タグ格納部37は、各タグテーブルの末尾に新たなレコードを追記する。したがって、各タグテーブルのレコードは、先頭から末尾までKeyの昇順で整列することになる。図4に戻り、データ格納部38は、受信したメッセージとID付与部36によって付与されたIDとを対応付けてデータテーブル33bに追加する。そして、データ格納部38は、データテーブル33bへの格納が完了したことを制御部34やタグ格納部37に通知する。なお、制御部34は、タグ格納部37とデータ格納部38の処理がともに終了した場合に、メッセージを送信した送信元のクライアント端末10にデータを蓄積したことを示す応答を送信する。ここで、上述した例をと同様の例で説明する。データ格納部38は、ID=00003879が付与されたメッセージタグ=曜日時間:火曜12-13時、場所:A県E市F区、道路:混雑、データ=イベントBを、ID付与部36から受信する。続いて、データ格納部38は、受信した情報からデータ=イベントBとID=00003879とを抽出する。そして、データ格納部38は、データテーブル33bを参照して末尾のレコードを特定し、特定した末尾のレコードの次のレコードとしてKey=00003879、Value=イベントBを追記する。つまり、データテーブル33bの最後尾に新たなレコードが追加されることになるので、データテーブル33bのレコードは、先頭から末尾までKeyの昇順で整列することになる。検索エンジン39は、検索対象のタグに対応するタグテーブル33a-1から33a-nとデータテーブル33bとを突き合わせて、検索対象のタグに対応付けられたデータを検索する処理部である。例えば、検索エンジン39が、タグ=曜日時間:火曜12-13時かつ場所:A県E市F区かつ道路:混雑に対応するデータを検索する検索要求を受信したとする。図7は、検索処理を説明する図である。この場合、検索エンジン39は、図7に示すように、曜日時間:火曜12-13時に対応するタグテーブルと、場所:A県E市F区に対応するタグテーブルと、道路:混雑に対応するタグテーブルとを用いてソートマージジョイン処理を実行する。このとき、検索エンジン39は、各タグテーブルが上述したように既にソートされている状態なので、マージ処理のみを実行する。具体的には、検索エンジン39は、ソートマージジョイン処理によって、上記3つのタグテーブルに共通するKeyとして00003879を抽出する。続いて、検索エンジン39は、データテーブル33bを参照し、抽出した00003879をKeyとするValueとしてイベントBを特定する。その後、検索エンジン39は、特定したイベントBを検索結果としてクライアント端末に応答する。検索エンジン39は、検索要求として受信されたタグの条件がAND条件の場合には、該当する各タグテーブルに対してソートマージジョイン処理のインナージョイン内部結合を実行する。例えば、検索エンジン39は、タグAかつタグBに該当するデータを検索する場合にはインナージョインを実行することで、各タグテーブルに共通して記憶されるKeyを抽出することができる。この場合、検索エンジンは、該当する各タグテーブルだけでなく、データテーブル33bを含めてソートマージジョイン処理のインナージョインを実行してデータを検索してもよい。また、検索エンジン39は、検索要求として受信されたタグの条件がOR条件の場合には、該当する各タグテーブルに対してソートマージジョイン処理のアウタージョイン外部結合を実行する。例えば、検索エンジン39は、タグAまたはタグBに該当するデータを検索する場合にはアウタージョインを実行することで、各タグテーブルのいずれかに記憶されるKeyを抽出することができる。この場合、検索エンジン39は、該当する各タグテーブルに対するソートマージジョイン処理で得られた結果と、データテーブル33bとを用いて、ソートマージジョイン処理のインナージョインを実行してデータを検索する。[処理の流れ]次に、タグ管理サーバ30が実行する処理の流れについて説明する。なお、クライアント端末が実行する処理は、データ生成処理、タグ付け処理などの一般的な処理なので詳細な説明は省略する。蓄積処理の流れ図8は、実施例2に係るタグ管理サーバが実行する蓄積処理の流れを示すフローチャートである。図8に示すように、タグ管理サーバ30の要求判定部35がメッセージを受信したと判定した場合S101肯定、ID付与部36は、受信時刻等を用いて、受信されたメッセージにIDを生成して付与するS102。続いて、タグ格納部37は、受信されたメッセージから、当該メッセージに含まれるタグを抽出するS103。そして、タグ格納部37は、抽出したタグを1つ選択しS104、選択したタグに対応するタグテーブルがデータストア33に存在するか否かを判定するS105。そして、タグ格納部37は、選択したタグに対応するタグテーブルが存在する場合S105肯定、Key=ID付与部36が生成したID、Value=Trueとするレコードを、当該タグテーブルの末尾に追記するS106。一方、タグ格納部37は、選択したタグに対応するタグテーブルが存在しない場合S105否定、選択したタグに対応するタグテーブルをデータストア33上に新たに生成するS107。そして、タグ格納部37は、Key=ID付与部36が生成したID、Value=Trueとするレコードを、生成したタグテーブルの先頭に追記するS108。その後、タグ格納部37は、抽出したタグが他にも存在すると判定した場合にはS109肯定、S104に戻って以降の処理を繰り返す。一方、データ格納部38は、タグ格納部37は他にタグが存在しないと判定した場合S109否定、受信されたメッセージからデータを抽出してS110を実行する。すなわち、データ格納部38は、Key=ID付与部36が生成したID、Value=抽出したデータとするレコードを、データテーブル33bの末尾に追記するS110。その後、制御部34は、受信したメッセージをデータストア33に蓄積したことを示す蓄積完了を、メッセージ送信元のクライアント端末10に応答するS111。なお、上記フローでは、S103からS109を実行した後にS110を実行する例を説明したが、これに限定されるものではなく、先にS110を実行してもよく、並行して実行してもよい。検索処理の流れ図9は、実施例2に係るタグ管理サーバが実行する検索処理の流れを示すフローチャートである。図9に示すように、タグ管理サーバ30の要求判定部35が検索要求を受信したと判定した場合S201肯定、検索エンジン39は、検索要求に含まれるタグを抽出するS202。続いて、検索エンジン39は、抽出したタグに対応するタグテーブルをデータストア33から特定しS203、特定したタグテーブルを用いてソートマージジョイン処理を実行するS204。一例を挙げると、検索エンジン39は、抽出したタグテーブルに共通して記憶されるIDKeyを特定する。そして、検索エンジン39は、ソートマージジョイン処理によって得られたIDに対応するデータValueをデータテーブル33bから検索するS205。その後、検索エンジン39は、検索して得られたデータを検索結果として、検索要求元のクライアント端末10に応答するS206。このように、タグ管理サーバ30は、タグおよびデータを異なるデータストア33を用いてKVS形式で保存することができる。また、タグ管理サーバ30は、IDで昇順に整列させた状態で、各テーブルにレコードを追加することができる。したがって、タグ管理サーバ30は、データが大規模になってハードディスク等でデータを記憶する場合でも、ランダムアクセスの発生を抑制することができるので、検索性能を向上させることができる。また、ソートマージジョイン処理を実行してデータを検索する場合でも、ソート処理を実行することなく、ジョイン処理を実行することができるので、処理を高速化することができる。実施例2では、タグ管理サーバが1台の場合を例にして説明したが、これに限定されるものではなく、複数のタグ管理サーバを用いることもできる。そこで、実施例3では、複数台のタグ管理サーバを用いる例を説明する。なお、実施例3では、複数台のタグ管理サーバを有するシステムの全体構成、タグ管理サーバの構成、処理の流れを説明する。クライアント端末は、実施例2等と同様の構成を有するので詳細な説明は省略する。[システムの全体構成]図10は、実施例3に係るシステムの全体構成例を示す図である。図10に示すシステムは、クライアント端末1、クライアント端末2、クライアント端末3、タグ管理サーバ50、タグ管理サーバ60、タグ管理サーバ70がネットワークを介して相互に通信可能に接続される。このシステムは、クライアント端末1-3が、いずれかのタグ管理サーバにタグ付きのデータを送信する。そして、データを受信したタグ管理サーバが、データを蓄積するタグ管理サーバを決定し、決定されたタグ管理サーバが、データを蓄積する。なお、クライアント端末1-3がはじめにアクセスするタグ管理サーバは、システムを構成するタグ管理サーバのうちのいずれでもよいし、アクセスごとに毎回異なってもよい。また、クライアント端末1-3が、いずれかのタグ管理サーバに検索要求を送信する。そして、検索要求を受信したタグ管理サーバが、自装置を含む全タグ管理サーバに検索要求を転送する。その後、検索要求を転送したタグ管理サーバが、各タグ管理サーバから検索結果を受信して集約し、その結果を検索結果としてクライアント端末1-3に応答する。なお、ここで例示した装置の数等はあくまで例示であり、これに限定されるものではない。また、実施例3では、クライアント端末からはじめにデータや検索要求を受信するタグ管理サーバをレセプタを呼ぶ場合がある。[タグ管理サーバの構成]次に、図10に示した各タグ管理サーバの構成を説明する。図10に示したタグ管理サーバ50、タグ管理サーバ60、タグ管理サーバ70は同様の構成を有するので、ここでは、タグ管理サーバ50について説明する。図11は、実施例3に係るタグ管理サーバの構成を示す機能ブロック図である。また、ここでは、クライアント端末1がデータ蓄積要求メッセージまたは検索要求をタグ管理サーバ50に送信したものとする。図11に示すように、タグ管理サーバ50は、ネットワークインタフェース31と、メモリ32、データストア33と、制御部51とを有する。なお、タグ管理サーバ50が有する制御部はこれらに限定されるものではなく、例えば、マウスなどの入力部、ディスプレイなどの表示部、記憶媒体からデータを読み出す記憶媒体読取装置等を有していてもよい。また、ネットワークインタフェース31、メモリ32、データストア33は、実施例2と同様の機能を有するので、詳細な説明は省略する。制御部51は、OSなどを実行してタグ管理サーバ50の全体的な制御を司る処理部であり、例えばCPUなどの電子回路である。この制御部51は、要求判定部52とID付与部53と担当決定部54と蓄積指示部54aとタグ格納部54bとデータ格納部54cと検索集約エンジン55と検索エンジン56とを有し、これらによってタグの蓄積や検索を実行する。要求判定部52は、実施例2で説明した要求判定部35と同様の処理を実行する処理部であり、クライアント端末1から受信した情報の種別を判定する処理部である。例えば、要求判定部52は、クライアント端末1からメッセージを受信した場合に、受信したメッセージをID付与部に出力する。また、要求判定部52は、クライアント端末1から検索要求を受信した場合には、受信した検索要求を検索エンジン56に出力する。また、要求判定部52は、レセプタからメッセージおよびIDを受信した場合、受信したメッセージおよびIDをタグ格納部54aとデータ格納部54bに出力する。また、要求判定部52は、レセプタから検索要求を受信した場合、当該検索要求を検索エンジン56に出力する。ID付与部53は、実施例2で説明したID付与部36と同様の処理を実行する処理部であり、受信したメッセージに、受信した順番に連番となるIDを付与する処理部である。ID付与部53は、IDを付与したメッセージを蓄積指示部54aに出力する。例えば、ID付与部53は、時刻サーバ名シリアル番号をIDとして生成する。一例を挙げると、サーバ名がZであるタグ管理サーバのID付与部53は、UNIX登録商標時刻13130091122011年8月10日20時45分12秒に5番目に受け付けたメッセージに対して、1313009112Z0005をIDとして割り振る。そして、ID付与部53は、時刻が2011年8月10日20時46分に繰り上がった場合には、シリアル番号を0にリセットして、以降のIDを生成する。担当決定部54は、クライアント端末から送信されたメッセージの格納先となるタグ管理サーバを、シャーディングによって決定する処理部である。具体的には、担当決定部54は、Chordなどのアルゴリズムや分散ハッシュテーブルDHT:DistributedHashTableなどの手法を用いて決定する。一例を挙げると、各タグ管理サーバは、自装置が担当するハッシュ値または自装置が担当するハッシュ値の範囲をハードディスク等に記憶するとともに、他の装置が担当するハッシュ値またはハッシュ値の範囲をハードディスク等に記憶する。このような状態で、担当決定部54は、ID付与部53が付与したIDのハッシュ値を算出する。そして、担当決定部54は、算出したハッシュ値がどのタグ管理サーバの担当範囲かを特定し、特定したタグ管理サーバを、蓄積処理を担当するサーバと決定する。そして、担当決定部54は、受信したメッセージおよびIDと、決定したタグ管理サーバの情報とを蓄積指示部54aに通知する。なお、担当決定部54が使用するハッシュ関数等は、一般的なDHTで使用されるハッシュ関数を用いる。蓄積指示部54aは、担当決定部54が決定したタグ管理サーバに対して、クライアント端末が送信したメッセージやID付与部53が付与したIDを送信する処理部である。例えば、蓄積指示部54aは、担当決定部54からタグ管理サーバ70のホスト名やIPInternetProtocolアドレス等を受信した場合、担当決定部54から受信したメッセージおよびIDをタグ管理サーバ70に送信する。また、蓄積指示部54aは、担当決定部54から自装置が担当であることを通知された場合、担当決定部54から受信したメッセージおよびIDをタグ格納部54bとデータ格納部54cとに送信する。タグ格納部54bは、要求判定部52または蓄積指示部54aからメッセージおよびIDを受信した場合には、タグの蓄積を実行する。すなわち、タグ格納部54bは、レセプタや担当決定部54によって自装置が蓄積担当と決定された場合に、タグの蓄積を実行する。なお、具体的な処理は、実施例2と同様の処理なので、詳細な説明は省略する。データ格納部54cは、要求判定部52または蓄積指示部54aからメッセージおよびIDを受信した場合には、データの蓄積を実行する。すなわち、データ格納部54cは、レセプタや担当決定部54によって自装置が蓄積担当と決定された場合に、データの蓄積を実行する。なお、具体的な処理は、実施例2と同様の処理なので、詳細な説明は省略する。検索集約エンジン55は、クライアント端末1から送信された検索要求を他のタグ管理サーバに転送し、各タグ管理サーバから受信した検索結果を集約してクライアント端末1に応答する処理部である。例えば、検索集約エンジン55は、要求判定部52がクライアント端末1から検索要求を受信した場合に、当該検索要求を他のタグ管理サーバおよび自装置の検索エンジン56に送信する。その後、検索集約エンジン55は、検索要求の送信先である各タグ管理サーバから検索結果を受信する。そして、検索集約エンジン55は、受信した各検索結果をマージして、検索要求の送信元のクライアント端末1に応答する。検索エンジン56は、要求判定部52または検索集約エンジン55から検索要求が通知された場合に、実施例2と同様の検索処理を実行する処理部である。例えば、検索エンジン56は、要求判定部52から検索要求が通知された場合、すなわちレセプタから送信された検索要求を受信した場合、検索処理を実行し、その結果をレセプタに応答する。また、検索エンジン56は、検索集約エンジン55から検索要求が通知された場合、検索処理を実行し、その結果を検索集約エンジン55に応答する。[処理の流れ]次に、タグ管理サーバが実行する処理の流れについて説明する。なお、タグ管理サーバ50からタグ管理サーバ70は同様の処理を実行するので、ここでは、タグ管理サーバ50を例にして説明する。つまり、タグ管理サーバ50がレセプタや他の装置として処理を実行する場合について説明する。また、クライアント端末が実行する処理は、データ生成処理、タグ付け処理などの一般的な処理なので詳細な説明は省略する。蓄積処理の流れ図12は、実施例3に係るタグ管理サーバが実行する蓄積処理の流れを示すフローチャートである。図12に示すように、タグ管理サーバ50の要求判定部52は、メッセージを受信した場合S301肯定、メッセージをレセプタから受信したか否かを判定するS302。なお、要求判定部52は、メッセージにIDが付与されている場合に、レセプタから受信したと判定することができる。そして、ID付与部53は、要求判定部52がレセプタでなくクライアント端末1から受信したと判定した場合S302否定、受信されたメッセージにIDを付与するS303。続いて、担当決定部54は、ID付与部53が付与したIDのハッシュ値を算出し、算出したハッシュ値に基づいてメッセージを蓄積する担当ノードを決定するS304。その後、蓄積指示部54aは、担当決定部54が決定した担当ノードに対して、クライアント端末1から受信したメッセージとID付与部53が付与したIDとを送信するS305。なお、蓄積指示部54aは、担当決定部54によって自装置が担当ノードと決定された場合には、メッセージとIDとをタグ格納部54bとデータ格納部54cとに出力する。この場合、タグ格納部54bとデータ格納部54cとは、実施例2と同様に、タグの格納やデータの格納を実行する。蓄積指示部54aは、メッセージとIDとを送信した担当ノードから蓄積処理が完了したことを示す応答を受信した場合S306肯定、メッセージの送信元のクライアント端末に当該応答を送信するS307。なお、蓄積指示部54aは、メッセージとIDとをタグ格納部54bとデータ格納部54cとに出力した場合、上記応答をタグ格納部54bとデータ格納部54cとから受信する。一方、要求判定部52がクライアント端末1でなくレセプタから受信したと判定した場合S302肯定、タグ格納部54bまたはデータ格納部54cは、S309からS317を実行する。なお、S309からS317の処理は、実施例2で説明したS103からS111と同様の処理なので、詳細な説明は省略する。なお、実施例2と異なる点は、蓄積完了の応答先がクライアント端末ではなくレセプタとなる点である。検索処理の流れ図13は、実施例3に係るタグ管理サーバが実行する検索処理の流れを示すフローチャートである。図13に示すように、タグ管理サーバ50の要求判定部52は、検索要求を受信した場合S401肯定、検索要求をレセプタから受信したか否かを判定するS402。そして、検索エンジン56は、要求判定部52がクライアント端末1ではなくレセプタから受信したと判定した場合S402肯定、S403からS407を実行する。なお、S403からS407の処理は、実施例2で説明したS202からS206と同様の処理なので、詳細な説明は省略する。なお、実施例2と異なる点は、検索結果の応答を送信する先がクライアント端末1ではなくレセプタとなる点である。一方、検索集約エンジン55は、要求判定部52がレセプタではなくクライアント端末から受信したと判定した場合S402否定、自ノードを含む全ノードに、受信された検索要求を転送するS408。つまり、検索集約エンジン55は、全ノードに加えて自装置の検索エンジン56にも検索要求を出力する。その後、検索エンジン56は、上述したS403からS407と同様の処理を実行して、検索要求に含まれるタグに対応するデータを検索して、その結果を検索集約エンジン55に出力する。その後、検索集約エンジン55は、検索要求の転送先である全ノードおよび自装置の検索エンジン56から検索結果を受信した場合S409肯定、検索結果を集約してクライアント端末に応答するS410。このように、ネットワークで結合された複数のサーバで、それぞれがデータの書き込みを受け付ける。受け付けたサーバが、各自単調増加なIDを振る。IDは全体で重複しないよう、また系全体でも極力単調増加になるように生成される。IDに基づきシャーディングを行いデータの担当サーバを決定する。また、実施例3では、データ蓄積時には、データを受け付けサーバから担当サーバに転送するときに通信が発生する。また、実施例3では、シャーディングによりデータがきれいに分割配置されているので、検索処理時には通信せずに、最後に各サーバの検索結果を集約するときにのみ通信が発生する。このように、通信の発生回数を減少させることができる。したがって、ランダムアクセスを抑止することにより、性能向上が見込める以外にも、IDの振り方とシャーディング手法を工夫して通信を極力抑えることができ、スケーラビリティを保持できる。さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下に異なる実施例を説明する。ランダムアクセス上記実施例では、データストアに格納されるデータの数に関係なく、ソートマージジョイン処理を実行してデータを検索する例について説明したが、これに限定されるものではない。例えば、格納されているデータ数が所定値よりも少ない場合には、ランダムアクセスを実行してデータを検索し、格納されているデータ数が所定値以上である場合には、上記実施例の手法を用いてデータを検索するようにしてもよい。データの格納数が少ない状態では、ランダムアクセスが発生した場合でもアクセスできる範囲が小さいために、ランダムアクセスの方が早く検索処理の実行することができる。なお、所定値は、ディスクの回転数等によって決定することができ、100件、もしくは全データ数の千分の一など管理者等によって予め指定することもできる。データ本体を保持上記実施例では、タグ管理サーバは、IDとダミーデータとを対応付けてタグテーブルに格納する例を説明したが、これに限定されるものではない。例えば、タグ管理サーバは、タグテーブルに格納されるデータ数が100件など少ない場合には、タグテーブルにデータそのものを格納してもよい。または、データのうち頻繁に使用する部分つまりデータのサブセットをタグテーブルに格納してもよい。詳しくは、タグ管理サーバは、データ数が所定値になるまで、ID、データを各タグテーブルに格納する。なお、ここで格納されるデータとは、例えばデータのサブネットなどである。この場合、タグ管理サーバは、データテーブルを検索せずにタグテーブルだけで、検索対象のタグに対応するデータを検索することができるので、検索処理をより高速化することができる。バッファの利用例えば、IDの振り方や、データの転送にかかる時間の影響で、担当サーバにメッセージとIDとが到着する順序が、IDの単調増加にならず、順序が逆転する場合もあるが、この順序逆転をメモリ上のバッファで吸収することができる。具体的には、タグ管理サーバは、クライアント端末またはレセプタからメッセージおよびIDを受信した場合に、一度メモリ上のバッファに格納する。なお、バッファは、タグテーブルごとに有していてもよく、その場合には、タグテーブルが新たに生成された場合には、メモリ上に新たなバッファ領域を設けることになる。そして、タグ管理サーバは、バッファ上のメッセージをIDでソートしてから、該当するタグテーブルに格納する。このようにすることで、連続してメッセージを受信した場合やIDの順番通りにメッセージを受信できなかった場合でも、タグテーブル等にソートされた状態でID等を格納することができる。また、IDの振り方とデータの転送時間から、データが遅れて到着しうる時間を算出することができるので、この時間とデータの最大スループットからバッファすべきデータのサイズを決定することもできる。データ格納位置上記実施例では、タグテーブルやデータテーブルの末尾に新たなレコードを格納することで、IDで昇順にソートされたテーブルを生成する例について説明したが、これに限定されるものではない。例えば、タグ管理サーバは、新たなレコードを各テーブルの先頭に格納してもよい。この結果、タグ管理サーバは、IDで降順にソートされたテーブルを生成することができるので、上記実施例と同様の検索処理を実行することができる。識別子上記実施例では、受信した順番が識別可能となるような単調増加な識別子を付与する場合について説明したが、これに限定されるものではない。例えば、受信した順番が識別可能となるような単調減少な数もしくは辞書順に並んだ文字列などのソート不要な識別子を付与することもできる。つまり、タグ管理サーバは、受信された順番でタグテーブルやデータテーブルにレコードをした際に、各テーブルに記憶される情報が識別子でソートされた状態になるような識別子を付与する。システムまた、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともできる。あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、CPUおよび当該CPUにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。プログラムところで、上記の実施例で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータシステムで実行することによって実現することができる。そこで、以下では、上記の実施例と同様の機能を有するプログラムを実行するコンピュータシステムの一例を説明する。図14は、タグ管理プログラムを実行するコンピュータのハードウェア構成例を示す図である。図14に示すように、コンピュータ100は、CPU102、入力装置103、出力装置104、通信インタフェース105、媒体読み取り装置106、HDDHardDiskDrive107、RAMRandomAccessMemory108を有する。また、図14に示した各部は、バス101で相互に接続される。入力装置103は、マウスやキーボードであり、出力装置104は、ディスプレイなどであり、通信インタフェース105は、NICなどのインタフェースである。HDD107は、タグ管理プログラム107aとともに、図5や図6に示した各テーブル等を記憶する。記録媒体の例としてHDD107を例に挙げたが、ROMReadOnlyMemory、RAM、CD-ROM等の他のコンピュータ読み取り可能な記録媒体に各種プログラムを格納しておき、コンピュータに読み取らせることとしてもよい。なお、記録媒体を遠隔地に配置し、コンピュータが、その記憶媒体にアクセスすることでプログラムを取得して利用してもよい。また、その際、取得したプログラムをそのコンピュータ自身の記録媒体に格納して用いてもよい。CPU102は、タグ管理プログラム107aを読み出してRAM108に展開することで、図4や図11等で説明した各機能を実行するタグ管理プロセス108aを動作させる。すなわち、タグ管理プロセス108aは、図4に記載した要求判定部35、ID付与部36、タグ格納部37、データ格納部38、検索エンジン39と同様の機能を実行する。また、タグ管理プロセス108aは、図11に記載した要求判定部52、ID付与部53、担当決定部54、蓄積指示部54a、タグ格納部54b、データ格納部54c、検索集約エンジン55、検索エンジン56と同様の機能を実行する。このようにコンピュータ100は、プログラムを読み出して実行することでタグ管理方法を実行する情報処理装置として動作する。また、コンピュータ100は、媒体読取装置106によって記録媒体からタグ管理プログラムを読み出し、読み出されたタグ管理プログラムを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、コンピュータ100によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。