JP2013008295A - 情報記録装置、情報記録方法およびプログラム - Google Patents

Abstract

【課題】本発明は、チャンクを検索や検索結果の返送の単位とするセンサ情報記録システムにおいて、チャンクの生成処理と１次データベース内のデータに対する検索を効率的に行える情報記録装置、情報記録方法およびプログラムを提供することを目的とする。
【解決手段】本発明に係る情報記録装置、情報記録方法およびプログラムは、属性名と属性値とを含む情報を１次データベースに一旦保持し、保持した情報について木構造をもつ索引を作成し、該索引における木構造の各部分木に含まれる情報を１つのチャンクとし、該情報を含むファイルを作成することとした。
【選択図】図１

Description

本発明は、情報記録装置、情報記録方法およびこれを実現するプログラムに関する。

センサなどのデータを記録し、記録したデータを検索可能とする、センサデータ向けの情報記録システムとして、ｕＴｕｐｌｅＳｐａｃｅなど、幾つかのセンサ情報記録システムがある（例えば、非特許文献１、非特許文献２及び非特許文献３を参照。）。

これら従来の代表的なセンサ情報記録システムは、センサからの１つ１つのデータをネットワーク経由で受け取り、該システム内にデータを蓄積する。また、該システムはアプリケーションからの検索要求をネットワーク経由で受信すると、蓄積したデータの中から検索条件に合致するものを検索し、ネットワーク経由で検索結果として返送する。

センサデータの一般的な特徴として、一つ一つのデータ量が小さく、また多種多様であり、データベースの構造（スキーマ、Ｓｃｈｅｍａ）を一意に定められないことが挙げられる。また、センサデータを活用する際の特徴として、データマイニング技術などを用いて、大量のデータを一括して処理する機会が多いことが挙げられる。

そのため、前記ｕＴｕｐｌｅＳｐａｃｅにおいては、センサデータなど、個々のデータ量が小さくデータ数の多いデータの検索結果を回答する際の処理を効率化するため、小さなデータを１つずつ扱うのではなく、複数のデータを一定量ずつひとまとめにし、まとめたかたまりをチャンク（ｃｈｕｎｋ）と呼び、該チャンクの単位で検索や検索結果の返送を行う。このため、前記ｕＴｕｐｌｅＳｐａｃｅではデータを１次データベース（ＤＢ）に一旦蓄積し、１次データベースに蓄積されたデータを一定量ひとまとめに取り出し、チャンクとして別ファイルに移し替えることで、チャンクの生成を行う。また当該別ファイルをチャンクファイルと呼ぶ。

一方、データベース技術の分野においては、多量のデータから目的のデータを高速に検索するために、ハッシュ関数を用いるもの、木構造などのデータ構造を利用するものなど、様々なインデキシング技術が考案されている。木構造を用いるものとしては、リレーショナルデータベース（ＲＤＢ）やファイルシステムなどに広く用いられているＢ木やその改良型であるＢ＋木やＢ＊木、さらには、センサデータのように多種多様なデータを扱うことを得意とするＵＢＩ木などがある（例えば、ＵＢＩ−ｔｒｅｅ、非特許文献４、非特許文献５を参照。）。

荒川 豊、他４名、「実世界データ共有機構ｕＴｕｐｌｅＳｐａｃｅにおける動的スケール化方式の評価」、電子情報通信学会 ＩＮ研究会報告、２００９年６月 中村 隆幸（Ｔａｋａｙｕｋｉ Ｎａｋａｍｕｒａ）、他５名、「ｕＴｕｐｌｅＳｐａｃｅ：Ａ Ｂｉ−Ｄｉｒｅｃｔｉｏｎａｌ Ｓｈａｒｅｄ Ｄａｔａ Ｓｐａｃｅ ｆｏｒ Ｗｉｄｅ−Ａｒｅａ Ｓｅｎｓｏｒ Ｎｅｔｗｏｒｋ」、２ｎｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｗｏｒｋｓｈｏｐ ｏｎ Ｓｅｎｓｏｒ Ｎｅｔｗｏｒｋｓ ａｎｄ Ａｍｂｉｅｎｔ Ｉｎｔｅｌｌｉｇｅｎｃｅ（ＳＥＮＡＭＩ ２００９）、２００９年１２月 中村 隆幸、他３名、「かたまり生成処理により効率化したセンサ情報蓄積システムの提案」、電子情報通信学会 総合大会、２０１０年３月 荒川 豊、他３名、「ＵＢＩ−ｔｒｅｅ：ユビキタスデータのためのインデキシング技術」、情報処理学会 全国大会、２０１０年３月 荒川 豊、他３名、「ユビキタスデータのためのインデキシング技術ＵＢＩ−ｔｒｅｅの改良」、電子情報通信学会 ＤＥ研究会報告、２０１０年８月

前記ｕＴｕｐｌｅＳｐａｃｅのように、チャンクを検索や検索結果の返送の単位とするセンサ情報記録システムにおいては、１つの検索要求に対して返送すべきチャンク数が少ない方が検索を高速に処理できる。つまり、検索条件に合致するデータが多数のチャンクにばらばらに存在するのではなく、同じチャンク内にまとまって存在する方が検索効率が良い。

検索条件に依存するが、検索においては、多くの場合、似たデータ、すなわち、同じ属性名をもつデータや近い属性値をもつデータは、同じ検索条件に合致しやすいため、１次データベースからチャンクとするデータ集合を取り出す際には、似たデータを取り出して１つのチャンクとすることが望まれる。また当該チャンク生成処理の処理効率が悪いのでは本末転倒であるから、当該チャンク生成処理は効率的に実施できる必要がある。さらに、検索要求に対して１次データベース内のデータに対しても効率的に検索処理を行う必要がある。

しかしながら、従来技術においては、効率的に似たデータを１次データベースから取り出してチャンクを生成し、同時に１次データベース内のデータに対する検索を効率的に実現する手法が確立されていないという課題があった。

本発明は、上記課題を考慮してなされたものであり、その目的は、チャンクを検索や検索結果の返送の単位とするセンサ情報記録システムにおいて、チャンクの生成処理と１次データベース内のデータに対する検索を効率的に行える情報記録装置、情報記録方法およびプログラムを提供することにある。

上記の課題を解決するために、本発明に係る情報記録装置、情報記録方法およびプログラムは、属性名と属性値とを含む情報を１次データベースに一旦保持し、保持した情報について木構造をもつ索引を作成し、該索引における木構造の各部分木に含まれる情報を１つのチャンクとし、該情報を含むファイルを作成することとした。

具体的には、本発明に係る情報記録装置は、属性名と属性値とを含む情報を保持する情報一次保持部と、前記情報一次保持部が保持する前記情報のうち、前記属性名または１つ以上の前記属性名に対応する前記属性値集合に対して木構造をもつ索引を作成する情報登録部と、前記情報登録部が作成した前記索引を用いて、木構造の部分木に含まれる前記情報を含むチャンクデータファイルを作成し、前記部分木に含まれる前記情報を前記情報一次保持部から削除し、前記部分木を前記索引から削除する情報切り出し部と、を備える。

具体的には、本発明に係る情報記録方法は、属性名と属性値とを含む情報を保持する情報一次保持手順と、前記情報一次保持手順で保持された前記情報のうち、前記属性名または１つ以上の前記属性名に対応する前記属性値集合に対して木構造をもつ索引を作成する情報登録手順と、前記情報登録手順で作成された前記索引を用いて、木構造の部分木に含まれる前記情報を含むチャンクデータファイルを作成し、前記部分木に含まれる前記情報を前記情報一次保持部から削除し、前記部分木を前記索引から削除する情報切り出し手順と、を行う。

本発明は、部分木に含まれる類似データを木構造内の枝を辿ることで簡単に集め、これらからチャンクデータファイルを生成することとした。本発明は、１次データベース内のデータの検索とチャンク生成を同じ木構造を用いることでチャンク生成処理と１次データベース内のデータの検索を効率的に行うことができる。

従って、本発明は、チャンクを検索や検索結果の返送の単位とするセンサ情報記録システムにおいて、チャンクの生成処理と１次データベース内のデータに対する検索を効率的に行える情報記録装置、情報記録方法およびプログラムを提供することができる。

本発明に係る情報記録装置の前記情報登録部は、同じ属性名を持つ情報を同じ部分木に集め、さらに、同じもしくは近い属性値をもつ情報を同じ部分木に集めることで前記索引を生成することを特徴とする。

本発明に係る情報記録方法の前記情報登録手順では、同じ属性名を持つ情報を同じ部分木に集め、さらに、同じもしくは近い属性値をもつ情報を同じ部分木に集めることで前記索引を生成することを特徴とする。

一般的に、木構造の索引においては、各部分木には、似たデータがそれぞれ集まるという性質がある。そのため、該索引の木構造の部分木に含まれるデータをまとめてチャンクとすることで、似たデータを１つのチャンクとすることが可能である。

本発明に係る情報記録装置は、検索すべき情報の条件を示す検索要求信号を受信する要求処理部と、情報検索部と、をさらに具備し、
前記情報切り出し部は、生成した前記チャンクデータファイルのファイル名と前記チャンクデータファイル内の前記情報に含まれる属性名と属性値範囲の一覧をチャンク索引情報として前記チャンクデータファイル毎に生成し、
前記情報検索部は、前記検索すべき情報の条件を満たす前記情報を前記情報一次保持部から読み出し、さらに前記検索すべき情報の条件を満たす前記チャンクデータファイルのファイル名を前記チャンク索引情報から読み出し、
前記要求処理部は、前記情報検索部が前記情報一次保持部から読み出した前記情報と、前記情報検索部が前記チャンク索引情報から読み出したファイル名と、を含む検索結果情報を送信することを特徴とする。

本発明に係る情報記録方法は、前記情報切り出し手順では、さらに、生成した前記チャンクデータファイルのファイル名と前記チャンクデータファイル内の前記情報に含まれる属性名と属性値範囲の一覧をチャンク索引情報として前記チャンクデータファイル毎に生成し、
検索すべき情報の条件を示す検索要求信号を受信する検索要求受信手順と、
前記検索すべき情報の条件を満たす前記情報を前記情報一次保持手順で保持されている前記情報から読み出し、さらに前記検索すべき情報の条件を満たす前記チャンクデータファイルのファイル名を前記情報切り出し手順で生成した前記チャンク索引情報から読み出す情報検索手順と、
前記情報検索手順で読み出した前記情報及び前記ファイル名を含む検索結果情報を送信する要求処理手順と、を行うことを特徴とする。

本発明は、チャンク索引情報を用いて、所望のデータが含まれるチャンクデータファイル名をチャンクデータファイル群から検索することを効率的に行うことができる。

また、本発明に係るプログラムは、コンピュータに、前記情報記録方法を実行させる。

本発明は、チャンクを検索や検索結果の返送の単位とするセンサ情報記録システムにおいて、チャンクの生成処理と１次データベース内のデータに対する検索を効率的に行える情報記録装置、情報記録方法およびプログラムを提供することができる。

本発明に係る情報記録装置の概略を示す構成図である。 本発明に係る情報記録装置に送信する登録要求のデータ構成を説明する図である。 本発明に係る情報記録装置の情報一次保持部が保持するセンサデータテーブルのデータ構造を説明する図である。 本発明に係る情報記録装置の情報索引保持部が保持するＵＢＩ−ｔｒｅｅによる索引のデータ構造を説明する図である。 本発明に係る情報記録装置の分散ファイルシステムが保持するチャンクデータファイルを説明する図である。 本発明に係る情報記録装置のチャンク索引保持部が保持するチャンクデータファイルに対して、ＵＢＩ−ｔｒｅｅによる索引について説明する図である。 本発明に係る情報記録装置の動作を説明する図である。 本発明に係る情報記録装置の情報索引保持部が保持する索引を説明する図である。 本発明に係る情報記録装置の情報一次保持部が保持するセンサデータテーブルのデータ構造を説明する図である。 本発明に係る情報記録装置に送信する検索要求のデータ構成を説明する図である。 本発明に係る情報記録装置が一括回答する場合の検索結果を説明する図である。 本発明に係る情報記録装置が一括回答しない場合の検索結果を説明する図である。 本発明に係る情報記録装置の動作を説明する図である。

図面を参照して本発明の実施形態を説明する。なお、本明細書及び図面において符号が同じ構成要素は、相互に同一のものを示すものとする。

図１は、本実施形態における情報記録装置１００の概略を示す構成図である。

同図において、情報記録装置１００は、要求処理部１０１と、情報登録部１０２と、情報一次保持部（情報保持部）１０３と、情報索引保持部１０４と、情報切り出し部１０５と、分散ファイルシステム１０６と、チャンク索引保持部１０７と、情報検索部１０８とを具備する。

また、情報記録装置１００と、ホスト１３０と、センサ１４０−１〜１４０−３とは、ネットワーク１２０に接続している。ホスト１３０は、分散ファイルシステム１３１と、アプリケーション部１３２とを具備する。なお、ネットワーク１２０に接続されるセンサの個数は、同図に示す３個に限らず、１個以上であればよい。

なお、本実施形態では、情報記録装置１００がセンサが計測したセンサデータを扱う場合について説明するが、情報記録装置１００が扱う情報は、センサデータに限らない。例えば、センサの特性や状態を示すメタデータ、あるいはセンサ以外、例えばＷｅｂやインターネットを経由して取得した情報であってもよい。

情報記録装置１００は、ネットワーク１２０を介して、センサ１４０−１〜１４０−３から登録要求を受信し、受信した登録要求に含まれるセンサデータを情報一次保持部１０３に保持する。

情報記録装置１００は、さらに、情報一次保持部１０３が保持するセンサデータに対し、ＵＢＩ−ｔｒｅｅによる索引を生成し、情報索引保持部１０４に保持する。

ＵＢＩ−ｔｒｅｅなどの木構造による索引は、１次データベース内のデータ集合の中のうち、同じ属性値、もしくは互いに近い属性値を持つデータを同じ部分木に集めることによって構築する。より詳細には、索引付け時に、データ挿入先として各部分木のうち最も属性種類の増加が少ない部分木を選び、データの挿入を行う。もしくは、最も属性値範囲の増加（広がり）が少ない部分木を選び、データの挿入を行う。

また情報記録装置１００は、情報索引保持部１０４に保持するＵＢＩ−ｔｒｅｅによる索引から、以下に詳述する手順によって部分木を選択し、選択した部分木に含まれるセンサデータをまとめたファイル（チャンクデータファイル）を生成し、生成したファイルを分散ファイルシステム１０６に保持させる。

情報記録装置１００は、さらに、生成したファイルに対し、ＵＢＩ−ｔｒｅｅによる索引を以下に詳述する手順によって生成し、チャンク索引保持部１０７に保持する。また、情報記録装置１００は、ネットワーク１２０を介して、ホスト１３０から検索要求を受信し、受信した検索要求に応じて以下に詳述する手順によって検索を行い、検索結果をホスト１３０に送信する。

なお、本実施形態では、情報索引保持部１０４やチャンク索引保持部１０７が保持する索引にＵＢＩ−ｔｒｅｅを用いる場合について説明するが、本発明の範囲はこれに限らず、Ｂ木やＢ＋木、Ｒ木など、他の木構造の索引を用いても良く、他の木構造の索引を用いた場合でも同様の効果が得られる。

要求処理部（要求通信部）１０１は、ネットワーク１２０に接続しており、ネットワーク１２０を介して、センサ１４０−１〜１４０−３から登録要求（登録要求信号）を受信し、ホスト１３０から検索要求（検索要求信号）を受信し、ホスト１３０に検索結果（検索結果信号）を送信する。

情報登録部１０２は、センサ１４０−１〜１４０−３から送信される登録要求からセンサデータを読み出し、情報一次保持部１０３に書き込み、さらに、情報索引保持部１０４が保持するＵＢＩ−ｔｒｅｅによる索引に当該センサデータの索引を加える。

情報一次保持部１０３は、情報登録部１０２が書き込むデータを保持する。

情報索引保持部１０４は、情報登録部１０２が生成するＵＢＩ−ｔｒｅｅによる索引を保持する。

なお本実施形態では、情報一次保持部１０３と情報索引保持部１０４を別に設けることとしたが、本発明の範囲はこれに限らず、単一の木構造によるデータ構造が、センサデータそのものとその索引とを両方保持することとしてもよい。例えば、木構造における各末端（リーフ）ノードに、各センサデータそのものも保持させることとし、木構造全体として全センサデータを保持するようにしてもよい。

情報切り出し部１０５は、情報索引保持部１０４が保持するＵＢＩ−ｔｒｅｅによる索引から、以下に詳述するように、予め定められた基準によりＵＢＩ−ｔｒｅｅに含まれる部分木を選択し、ファイルを生成し、当該部分木に含まれるセンサデータを情報一次保持部１０３から読み出し、当該ファイルに書き込み、当該ファイル（チャンクデータファイル）を分散ファイルシステム１０６に保持させる。

また、情報切り出し部１０５は、当該部分木をＵＢＩ−ｔｒｅｅから一気に削除し、また、読み出したセンサデータを情報一次保持部１０３から削除する。さらに、情報切り出し部１０５は、チャンク索引保持部１０７が保持するＵＢＩ−ｔｒｅｅによる索引に当該ファイルの索引を加える。部分木に含まれるデータをまとめてチャンクとすることで、チャンクとしたデータを当該索引から削除する処理を、部分木単位で行うことができるため、構造の索引が通常提供している削除手段を用いてデータを１つずつ削除する場合に比べ、効率的に実行することができる。

分散ファイルシステム１０６は、情報切り出し部１０５が生成したチャンクデータファイルを保持する。

チャンク索引保持部１０７は、分散ファイルシステム１０６が保持するチャンクデータファイルに対するＵＢＩ−ｔｒｅｅによる索引を保持する。

情報検索部１０８は、ホスト１３０から送信される検索要求が示す検索条件に合致するセンサデータを情報索引保持部１０４が保持する索引を用いて検索し、対応するセンサデータを情報一次保持部１０３から読み出し、また、当該検索条件に適合するチャンクデータファイルをチャンク索引保持部１０７が保持する索引を用いて検索し、対応するファイルを分散ファイルシステム１０６から読み出し、検索結果を生成する。

ホスト１３０は、アプリケーションを実行してサービスを提供するホストコンピュータであり、アプリケーション実行時に必要となったセンサデータを、情報記録装置１００に対して検索要求にて要求する。

分散ファイルシステム１３１は、情報記録装置１００の分散ファイルシステム１０６が保持するファイル（と同一のファイル）の送信を情報記録装置１００から受けて、送信を受けた当該ファイルを保持し、アプリケーション部１３２に対して、分散ファイルシステム１０６が保持するチャンクデータファイルを提供する。

センサ１４０−１〜１４０−３は、センサデータを生成し、生成したセンサデータを含む登録要求を情報記録装置１００に送信する。

ネットワーク１２０は、情報記録装置１００とホスト１３０とセンサ１４０−１〜１４０−３とに接続し、これら相互間のデータを伝送する。

次に、センサ１４０−１〜１４０−３が情報記録装置１００に送信する、登録要求のデータ構成について説明する。図２は、登録要求の例を示す図である。

同図に示すように、登録要求は、センサデータを含む。センサデータは、区切り記号「，」を挟んで相互に結合されたデータまたはメタデータを含む。データまたはメタデータは、区切り記号「＝」を挟んで結合された属性（属性名）と値（属性値）とを含む。

同図に示すセンサデータは、気温センサであるセンサ１４０−３が計測した気温を示すデータである。センサ１４０−３は、部屋Ｒ１〜Ｒ３を移動するロボットに搭載されており、情報記録装置１００に定期的にセンサデータを送信する。

図２の例では、「気温＝２４」がセンサ１４０−３の計測した計測データであり、「センサＩＤ＝３」と、「部屋＝Ｒ１」とがメタデータである。

計測データ「気温＝２４」は、計測データの属性「気温」と計測値（センサ１４０−３が計測した気温）「２４」と区切り記号「＝」とを含む。

同様に、メタデータの各々も、属性と、値と、区切り記号「＝」とを含む。「センサＩＤ」は、センサを識別する識別情報（Ｉｄｅｎｔｉｆｉｅｒ；ＩＤ）であり、「部屋」は、計測時にセンサが位置する部屋の名前を示す。

また、センサデータは、可読形式の１行のテキスト情報として表現されている。ここでいう可読形式とは、センサデータに含まれる区切り符号と、属性と、値とが、全て画面表示可能な文字符号のみを含むことをいう。例えば、図２の登録要求Ｆ１５０に含まれるセンサデータの文字列のうち、「セ」がシフトＪＩＳ２バイトコードの８３５ａ（１６進表記、以下同様。）で表記され、「ン」が８３９３で表記されるなど、センサデータは、画面表示可能なコードで示される文字符号（制御コードや未定義のコードを含まない文字符号）のみを含む。

なお、属性ないし値が、表示制御用の符号など、画面表示できない符号を含む場合、例えばバックスラッシュ等の、予め定められたエスケープ文字を前置することにより、画面表示できる文字符号に変換するようにしてもよい。

また、例えばセンサの計測値に区切り記号として用いられている符号「＝」が含まれる場合など、属性ないし値が、区切り符号を含む場合も、予め定められたエスケープ文字を前置することにより、属性ないし値の一部と区切り符号とを区別するようにしてもよい。

次に、情報一次保持部１０３が保持するセンサデータテーブルのデータ構造について説明する。図３は、センサデータテーブルの例を示す図である。

センサデータテーブルの各行は、センサから送信される登録要求に基づくセンサデータとなっている。なお、同図の例では、センサデータＬ１１〜１３およびＬ１７は、センサ１４０−１〜１４０−３のいずれかから送信される登録要求に基づくセンサデータであり、センサデータＬ１５は、湿度センサ（不図示）から送信される登録要求に基づくセンサデータであり、センサデータＬ１４、Ｌ１６、Ｌ１８、Ｌ１９は、物流追跡システムのセンサ（不図示）から送信される登録要求に基づくセンサデータである。このように、センサデータテーブルには、複数種類のセンサデータが混在する。

ここで、センサデータテーブルの各センサデータは、登録要求に含まれるセンサデータそのものであってもよいし、登録要求に含まれるセンサデータを加工したものであってもよい。図３の例では、センサデータテーブルの各行Ｌ１１〜Ｌ１９は、登録要求に含まれるセンサデータに、情報記録装置１００による当該登録要求の受信時刻を付加したセンサデータであり、受信時刻の古いセンサデータほど上側（行Ｌ１１の側）に位置している。例えば、情報登録部１０２が、登録要求から読み出されたセンサデータに対して受信時刻の付加等の加工を行った後に、情報一次保持部１０３に書き込むようにしてもよい。

次に、情報索引保持部１０４が保持するＵＢＩ−ｔｒｅｅによる索引のデータ構造について説明する。図４は、情報索引保持部１０４が保持するＵＢＩ−ｔｒｅｅによる索引の例を示す図である。

各ノードは２〜３個のエントリを保持する。ただし、ルートノードは、それより少ない数のエントリを保持する場合もある。エントリとは、下位のノードまたはデータＩＤ情報へのポインタと、当該下位のノードまたは当該データＩＤ情報に対応するデータに含まれる属性名と属性値範囲をセットにした情報のことを指す。

ここで、図４の例では、各ノードは２〜３個のエントリを保持することとしたが、必ずしも２〜３個でなくともよく、システム管理者等が別の数に設定してもよい。

図４において、ルートノードＮ１１は、２つのエントリを保持し、１つ目のエントリは、ノードＮ１２へのポインタ（木構造の枝として図示）と、ノードＮ１２よりも下位に保持しているデータＩＤ情報Ｎ１８〜２０に対応するデータに含まれる属性名と属性値範囲のセットを保持する。

具体的には、属性「時刻」に対応する属性値範囲は「２０１０／１０／０４ ０９：２３：１２〜２０１０／１０／０５ １０：１１：５２」、属性「センサＩＤ」に対応する属性値範囲は「１〜２２」、属性「部屋」に対応する属性値範囲は「Ｒ１〜Ｒ２」、属性「気温」に対応する属性値範囲は「２２〜２３」、属性「湿度」に対応する属性値範囲は「６０〜６２」である。

同様に、ノードＮ１２は、２つのエントリを保持し、１つ目のエントリは、ノードＮ１４へのポインタと、ノードＮ１４よりも下位に保持しているデータＩＤ情報Ｎ１８〜Ｎ２０に含まれる属性名と属性値範囲のセットを保持する。ノードＮ１４は、３つのエントリを保持し、それぞれデータＩＤ情報Ｎ１８〜Ｎ２０へのポインタと、それぞれ対応するデータに含まれる属性名と属性値範囲のセットを保持する。

ノードＮ１４が保持する、データＩＤ情報Ｎ１８〜Ｎ２０に対応するデータに含まれる属性名と属性値範囲は、煩雑となるため図示していない。ノードＮ１５、Ｎ１６、Ｎ１７についても同様の理由により図示していない。

ここで、データＩＤは、図３のセンサデータテーブルの各センサデータに含まれるデータＩＤと対応している。

図５は、分散ファイルシステム１０６が保持するチャンクデータファイルの例を示す図である。

チャンクデータファイルには、予め定められたファイル名生成規則に基づいて、ファイル名が付されている。図５の例では、固定の文字列「ＤＡＴ」と、通し番号「０８」と、チャンクデータファイルを示す拡張子「．ＣＮＫ」とを結合したファイル名「ＤＡＴ０８．ＣＮＫ」（Ｎ１１−０）が付されている。

また、図５のＮ１１−１は、チャンクメタデータである。チャンクメタデータは、当該チャンクデータファイルのメタデータであり、当該チャンクデータファイルに含まれるセンサデータ、すなわち、Ｌ１１、Ｌ１２、Ｌ１３、Ｌ１５、Ｌ１７に含まれる、属性名と、当該属性に対する属性値の範囲を示すものである。

例えば、属性「データＩＤ」について、センサデータＬ１１、Ｌ１２、Ｌ１３、Ｌ１５、Ｌ１７の属性値は、それぞれ１、２、３、５、７であるから、属性値範囲は「１〜７」となり、当該属性に対応するチャンクメタデータは「データＩＤ＝１〜７」となる。

次に、チャンク索引保持部１０７が保持する、チャンクデータファイルに対するＵＢＩ−ｔｒｅｅによる索引について説明する。

図６は、チャンクデータファイルに対するＵＢＩ−ｔｒｅｅによる索引の例を示す図である。ＵＢＩ−ｔｒｅｅのデータ構造は図４のものとほぼ同じであるが、各エントリが、下位のノードまたはチャンクデータファイル名情報へのポインタと、当該下位のノードまたは当該チャンクデータファイル名情報に対応するチャンクデータファイルのメタデータに含まれる属性名と属性値範囲をセットにした情報である点で異なる。

図６において、Ｎ５８〜Ｎ６５に示したのは、データＩＤ情報ではなくチャンクデータファイル名情報であり、Ｎ６１は、図５に示したチャンクデータファイルに対応するチャンクデータファイル名情報であり、値として「ＤＡＴ０８．ＣＮＫ」を保持する。

次に、情報記録装置１００における、センサデータを記録する処理手順について説明する。

図１において、要求処理部１０１が、センサ１４０−１〜１４０−３、あるいは図示していない他のセンサから、ネットワーク１２０を介して送信される登録要求を受信すると、要求処理部１０１は、登録要求に含まれるセンサデータを、情報一次保持部１０３に記録する。このとき、要求処理部１０１は、当該センサデータに対し、データＩＤ、すなわち、データに対する通し番号を生成し、当該通し番号を、属性「データＩＤ」に対する属性値としてセンサデータに付与する。また、要求処理部１０１は、当該登録要求の受信時刻を、属性「時刻」に対する属性値としてセンサデータに付与する。さらに、要求処理部１０１は、登録要求に含まれるセンサデータを、情報索引保持部１０４が保持する索引に加える。このとき、当該センサデータに付与したデータＩＤを含むデータＩＤ情報を、情報索引部１０４が保持する索引のリーフノードに挿入する。

図７は、情報記録装置１００が、相互に似たセンサデータの切り出しを行う処理手順を示すフローチャートである。

情報記録装置１００は、予め定められた一定時間が経過する毎に図７に示す処理を開始する。なお、情報記録装置１００が図７に示す処理を開始する契機は、予め定められた一定時間の経過に限らない。例えば、情報記録装置１００が登録要求を処理し、情報一次保持部１０３の保持するセンサデータ数が一定個数に達したときなど、予め定められた一定時間の経過以外の契機で、処理を開始するようにしてもよい。

情報記録装置１００が図７の処理を開始する時点では、情報一次保持部１０３は、例えば図３のようにセンサデータＬ１１〜Ｌ１９をセンサデータテーブル内に保持し、情報索引保持部１０４は、図４のようにＵＢＩ−ｔｒｅｅによる索引を保持している。

情報記録装置１００が図７の処理を開始すると、まず、情報切り出し部１０５が、情報索引保持部１０４が保持するＵＢＩ−ｔｒｅｅによる索引の中で、属性「時刻」について、最も古い属性値範囲の始点をもち、かつ、ルートノードから数えて２段目のノードとして、ノードＮ１２を発見し、当該ノードＮ１２をルートノードとする部分木を切り出す部分木に選択する。

具体的には、ルートノードから、属性「時刻」について、最も古い属性値範囲の始点をもつノードへ枝を１回辿ることで、当該ノードＮ１２を発見することができる。

ここで、Ｎ１２をルートノードとする部分木とは、ノードＮ１２、Ｎ１４、Ｎ１５、データＩＤ情報Ｎ１８，Ｎ１９、Ｎ２０、Ｎ２１、Ｎ２２から構成される、ＵＢＩ−ｔｒｅｅ全体の木構造のサブセットとなる木構造を指す。

さらに、情報切り出し部１０５は、当該部分木内を辿り、すなわち、ノード内の各エントリに含まれるポインタにより各ノードないし各データＩＤ情報にアクセスし、部分木が保持する全てのデータＩＤ情報、すなわち、Ｎ１８〜Ｎ２２を取得する（以上、手順Ｓ２４１）。

図４に示すように、Ｎ１２をルートノードとする部分木に含まれるデータＩＤに対応するセンサデータは、属性として「時刻」、「センサＩＤ」、「部屋」、「気温」、「湿度」のうちのいずれか４つを保持するのに対し、Ｎ１３をルートノードとする部分木に含まれるデータＩＤに対応するセンサデータは、属性として「時刻」、「物品番号」、「リーダＩＤ」を保持する。

このように、ＵＢＩ−ｔｒｅｅなどの木構造による索引は、索引付け対象であるデータ集合のうち同じ属性をもつデータがなるべく同じ部分木に集まるよう索引付けを行うため、同じ属性をもつデータが同じ部分木に集まるという特性をもつ。

また、図４に示すように、Ｎ１６をルートノードとする部分木に含まれるデータＩＤに対応するセンサデータが、属性「物品番号」、「リーダＩＤ」に対する属性値範囲としてそれぞれ「ＡＡ１〜ＡＡ４」、「１０１〜１０２」を保持するのに対し、Ｎ１７をルートノードとする部分木に含まれるデータＩＤに対応するセンサデータは、属性値範囲としてそれぞれ「ＡＢ３〜ＡＢ４」、「１０３」を保持している。

このように、ＵＢＩ−ｔｒｅｅなどの木構造による索引は、索引付け対象であるデータ集合のうち近い属性値をもつデータがなるべく同じ部分木に集まるよう索引付けを行うため、同じ属性をもつデータが同じ部分木に集まるだけでなく、近い属性値をもつデータが同じ部分木に集まるという特性をもつ。

つまり、手順Ｓ２４１において、部分木が保持するすべてのデータＩＤ情報を取得することにより、同じ属性をもち、かつ、近い属性値をもつ、相互に似たデータのデータＩＤ情報集合を取得することができる。

本実施形態では、時刻の古い順に、ルートノードから数えて２段目のノードをルートノードとする部分木を１つのチャンクに切り出す対象として選択することとしているが、本発明はこれに限らず、時刻の新しい順に部分木を選択してもよいし、時刻ではない別の属性の属性値の小さい順、あるいは大きい順に部分木を選択してもよい。

また２段目でなくともよい。また、１つのチャンクに切り出す対象として複数の部分木を選択してもよい。例えば図４において、ノードＮ１２をルートノードとする部分木と、ノードＮ１６をルートノードとする部分木を選択し、１つのチャンクに切り出してもよい。これにより、部分木の選択や当該部分木の切り出しの手間は大きくなるが、チャンクの大きさを揃えることが可能となる。

情報切り出し部１０５は、次に、情報一次保持部１０３から、手順Ｓ２４１で取得したデータＩＤ情報に対応するセンサデータ、すなわち、図３のＬ１１、Ｌ１２、Ｌ１３、Ｌ１５、Ｌ１７を読み出す（手順Ｓ２４２）。

さらに、情報切り出し部１０５は、読み出したセンサデータと、チャンクメタデータを含むチャンクデータファイルを生成し、予め定められたファイル名生成規則に従って、生成したチャンクデータファイルにファイル名を付す。

チャンクメタデータは、情報索引保持部１０４が保持するＵＢＩ−ｔｒｅｅによる索引において、手順Ｓ２４１において選択した部分木のルートノードＮ１２に対応する、Ｎ１２の親ノード１１のエントリに含まれる属性名と属性値範囲、すなわち、「時刻＝２０１０／１０／０２ ２１：２７：５１〜２０１０／１０／０５ １０：１１：５２、センサＩＤ＝１〜３３、部屋＝Ｒ１〜Ｒ２、気温＝１８〜２７、湿度＝５９〜６９」と一致するため、当該情報を情報索引保持部１０４から取得することで、当該チャンクメタデータを取得する。ただし、チャンクメタデータは、センサデータ集合から生成しても良い。

例えば、情報切り出し部１０５は、チャンクメタデータＮ１１−１と、センサデータＬ１１とＬ１２とＬ１３とＬ１５とＬ１７とを含む、図５のチャンクデータファイルを生成し、生成したチャンクデータファイルに、図５で説明したファイル名「ＤＡＴ０８．ＣＮＫ」を付与する。

情報切り出し部１０５は、ファイル名を付したチャンクデータファイルを、分散ファイルシステム１０６に出力し、分散ファイルシステム１０６は、このチャンクデータファイルを保持する（以上、手順Ｓ２４３）。

次に、情報切り出し部１０５は、生成したチャンクデータファイルのファイル名と、チャンクメタデータを、チャンク索引保持部１０７が保持するＵＢＩ−ｔｒｅｅによる索引に追加する。

図６は、追加後の、チャンク索引保持部１０７が保持するＵＢＩ−ｔｒｅｅによる索引の例である。追加されたファイル名情報Ｎ６１を、チャンクメタデータにより索引付けしている。

図が煩雑になるため図示していないが、図６において、ファイル名情報Ｎ６１に対応する、ノードＮ５５内のエントリが保持する属性名と属性値範囲は、当該チャンクメタデータと同じく、「時刻＝２０１０／１０／０２ ２１：２７：５１〜２０１０／１０／０５ １０：１１：５２、センサＩＤ＝１〜３３、部屋＝Ｒ１〜Ｒ２、気温＝１８〜２７、湿度＝５９〜６９」となる（以上、手順Ｓ２４４）。

さらに、情報切り出し部１０５は、手順Ｓ２４１で切り出すこととした部分木を、情報索引保持部１０４が保持するＵＢＩ−ｔｒｅｅによる索引から削除する（手順Ｓ２４５）。

例えば、情報切り出し部１０５は、情報索引保持部１０４が保持する図４の索引から、Ｎ１２をルートノードとする部分木を一気に削除する。すなわち、Ｎ１２に対応するＮ１１内のエントリと、Ｎ１２をルートノードとする部分木に含まれるノードとデータＩＤ情報の集合を全て一気に削除する。これにより、情報索引保持部１０４が保持する索引は、図８のようになる。

このとき、当該部分木に含まれるデータＩＤ情報を、ＵＢＩ−ｔｒｅｅを含む木構造を持つインデックスにおいて通常提供されている削除手段を用いて、１つ１つ順番に削除する場合に比べ、当該部分木を一気に削除する方法は、非常に効率的である。

なぜならば、多くのデータＩＤ情報を１つ１つ順番に削除する場合、１つのノードが保持するエントリ数の下限を下回った際に、当該ノードを削除し、保持していたエントリを他のノードに分配する処理が通常多数回発生するのに比べ、木構造全体を一気に削除する方法では当該処理の発生回数を小さく抑えることができるためである。

このように、部分木を単位としてチャンクに切り出すことで、チャンク切り出し処理を効率化することができる。

さらに、情報切り出し部１０５は、手順Ｓ２４２でチャンクデータファイルに含めたセンサデータを、情報一次保持部１０３のセンサデータテーブルから削除する（手順Ｓ２４６）。例えば、情報切り出し部１０５は、図３のセンサデータテーブルから、センサデータＬ１１とＬ１２とＬ１３とＬ１５とＬ１７とを削除する。これにより、センサデータテーブルは、図９のようになる。

その後、情報記録装置１００は、図７の処理を終了する。

以上の処理によって、情報一次保持部１０３の持つデータの個数は一定程度に少ない状態で維持され、一方、相互に似たデータのみが集まったチャンクデータファイルが、分散ファイルシステム１０６上に次々と生成される。その際、各チャンクデータファイルは、１行に１センサデータが記述された可読なテキストファイル形式にて生成される。また、それらチャンクデータファイルの索引が、チャンク索引保持部１０７に構築される。

次に、ホスト１３０が情報記録装置１００に送信する、検索要求のデータ構成について説明する。図１０は、検索要求の例を示す図である。

検索要求は、検索式と一括回答フラグとを含む。例えば、図１０の検索要求Ｆ１５１は、検索式Ｆ２７１と、一括回答フラグとを含む。検索式Ｆ２７１は、ホスト１３０が要求するセンサデータの条件を示す情報である。一括回答フラグは、後述する一括回答を行うか否かを示すフラグであり、「Ｙｅｓ」または「Ｎｏ」の値をとる。

図１０の検索要求Ｆ１５１は、ホスト１３０が、「物品番号＝ＡＡ１〜ＡＡ５」かつ「リーダＩＤ＝１０１」を満たすセンサデータを要求していることを示し、また、一括回答を行うことを示している。

次に、図１１および図１２を用いて、情報記録装置１００がホスト１３０に送信する、検索結果のデータ構成について説明する。

図１１は、一括回答を行う場合の検索結果の例を示す図である。

検索結果は、検索要求に対する回答であり、情報一次保持部１０３が保持するセンサデータのうち、検索要求が示す条件に合致するセンサデータを含む。ここで、検索要求が示す条件に「合致」するセンサデータとは、検索要求が示す条件の全てを満たすセンサデータをいう。

さらに、検索要求の一括回答フラグが「Ｙｅｓ」の場合は、検索結果は、分散ファイルシステム１０６が保持するチャンクデータファイルのうち、検索要求が示す条件に適合するファイルのファイル名を含む。一方、検索要求の一括回答フラグが「Ｎｏ」の場合は、検索結果は、分散ファイルシステム１０６が保持するチャンクデータファイルに含まれるセンサデータのうち、検索要求が示す条件に合致するセンサデータを含む。

ここで、検索要求が示す条件に「適合」するファイルとは、当該ファイルのチャンクメタデータが、検索要求の示す条件（検索式）に矛盾しないファイルをいう。検索要求の示す条件の全てについて、その属性が、チャンクメタデータに含まれ、かつ、その値が整合する（値が一致する。検索要求またはチャンクメタデータが値の範囲を示す場合は、少なくとも一部が重なる。）場合は、当該ファイルは当該検索要求に適合する。

一方、検索要求の示す条件のうち、いずれかの条件の属性が、チャンクメタデータに含まれない場合、あるいは、チャンクメタデータに含まれ、かつ、その値が整合しない（値が異なる。検索要求またはチャンクメタデータが値の範囲を示す場合は、重なる部分が無い。）場合は、当該ファイルは当該検索要求に適合しない。

図１１は、図１０の検索要求Ｆ１５１に対する検索結果Ｆ１５２の例を示しており、図９のセンサデータテーブルに含まれるセンサデータのうち、図１０の検索要求Ｆ１５１の示す条件「物品番号＝ＡＡ１〜ＡＡ５」かつ「リーダＩＤ＝１０１」を満たすセンサデータＬ１４を含む。

また、図１０の検索要求Ｆ１５１の一括回答フラグは「Ｙｅｓ」となっているので、図１１の検索結果Ｆ１５２は、分散ファイルシステム１０６が保持するチャンクファイルデータのうち、図１０の検索要求Ｆ１５１の示す条件「物品番号＝ＡＡ１〜ＡＡ５」かつ「リーダＩＤ＝１０１」に適合するチャンクデータファイルのファイル名「ＤＡＴ０３．ＣＮＫ」（図１１のファイル名Ｃ１１）を含む。

このように、一括回答とは、検索要求Ｆ１５１に対して、分散ファイルシステム１０６が保持する個々のセンサデータではなく、分散ファイルシステム１０６が保持するチャンクデータファイル名を回答することをいう。情報記録装置１００が、検索要求Ｆ１５１に適合するチャンクデータファイルのファイル名をホスト１３０に回答することにより、ホスト１３０は、条件に合致するセンサデータを、当該ファイル内を検索して取得できる。

図１２は、一括回答を行わない場合の検索結果の例を示す図である。

同図の検索結果Ｆ１５３は、図１１に示した一括回答を行う場合の検索結果Ｆ１５２と同様、図９のセンサデータテーブルに含まれるセンサデータのうち、図１０の検索要求Ｆ１５１の示す条件「物品番号＝ＡＡ１〜ＡＡ５」かつ「リーダＩＤ＝１０１」を満たすセンサデータＬ１４を含む。

一方、図１２の検索結果Ｆ１５３は、チャンクデータファイルのファイル名は含まず、図１０の検索要求Ｆ１５１が示す条件に適合するチャンクデータファイル（ＤＡＴ０３．ＣＮＫ）に含まれるセンサデータのうち、条件に合致するセンサデータＬ２０とＬ２１とＬ２２を含む。

図１３は、情報記録装置１００が、検索要求に対する検索結果を生成してホスト１３０に送信する処理手順を示すフローチャートである。

情報記録装置１００は、ホスト１３０から検索要求を受信すると、同図の処理を開始する。

情報記録装置１００が同図の処理を開始する時点では、分散ファイルシステム１０６は、互いに似たセンサデータを纏めたチャンクデータファイルを保持し、情報一次保持部１０３は、チャンクデータファイルのセンサデータを切り出した残りのセンサデータを保持している。

また、情報索引保持部１０４は、情報一次保持部１０３が保持するセンサデータの索引を保持している。

また、チャンク索引保持部１０７は、分散ファイルシステム１０６の保持するチャンクデータファイルの索引を保持している。

例えば、分散ファイルシステム１０６は、互いに似たセンサデータＬ１１とＬ１２とＬ１３とＬ１５とＬ１７とを纏めた図５のチャンクデータファイルを保持し、情報一次保持部１０３は、図９のように、残りのセンサデータＬ１４とＬ１６とＬ１８とＬ１９を保持している。また、情報索引保持部１０４は、図８のように、情報一次保持部１０３が保持するセンサデータの索引を保持している。また、チャンク索引保持部１０７は、図６のように、図５のチャンクデータファイルの索引として、ファイル名情報Ｎ６１とそれに対するエントリを保持している。

情報記録装置１００は、以下に説明する処理により、ホスト１３０からの検索要求に含まれる検索式に基づいて、情報一次保持部１０３が保持するセンサデータのうち、検索式に合致するセンサデータを含み、さらに、分散ファイルシステム１０６が保持するチャンクデータファイルのうち、検索式に適合するチャンクデータファイルのファイル名を含む検索結果を生成する。

例えば、情報記録装置１００は、図９のセンサデータのうち、図１０の検索要求Ｆ１５１の検索式Ｆ２７１に合致するセンサデータＬ１４を含み、さらに、検索式Ｆ２７１に適合する図６のチャンクデータファイルのファイル名「ＤＡＴ０３．ＣＮＫ」を含む、図１１の検索結果Ｆ１５２を生成する。

あるいは、情報記録装置１００は、情報一次保持部１０３が保持するセンサデータのうち、検索式に合致するセンサデータを含み、さらに、分散ファイルシステム１０６がチャンクデータファイル内に保持するセンサデータのうち、検索式に合致するセンサデータを含む検索結果を生成する。

例えば、情報記録装置１００は、図９のセンサデータのうち、検索式Ｆ２７１に合致するセンサデータＬ１４を含み、さらに、ファイル名「ＤＡＴ０３．ＣＮＫ」のチャンクデータファイル内のセンサデータのうち、検索式Ｆ２７１に合致するセンサデータＬ２０とＬ２１とＬ２２とを含む、図１２の検索結果Ｆ１５３を生成する。

以下、情報記録装置１００が行う図１３の処理について、より詳細に説明する。

要求処理部１０１が、ホスト１３０からネットワーク１２０を介して送信される検索要求を受信して、情報記録装置１００が図１３の処理を開始すると、要求処理部１０１は、受信した検索要求を情報検索部１０８に出力する。情報検索部１０８は、検索要求から検索式を読み出し、情報索引保持部１０４が保持する索引を検索して、検索式に合致するデータＩＤ情報を取得する。

例えば、情報検索部１０８は、図１０の検索要求Ｆ１５１から検索式Ｆ２７１（「物品番号＝ＡＡ１〜ＡＡ５、リーダＩＤ＝１０１」）を読み出し、図８の情報索引保持部１０４が保持する索引から、検索式２７１に合致するデータＩＤ情報を取得する。

具体的には、ルートノードから、検索式Ｆ２７１に合致する属性名と属性値範囲を保持するエントリに対応するノードを辿り、すなわち、Ｎ１１から、Ｎ１３、Ｎ１６、Ｎ１８と辿り、検索式Ｆ２７１に合致するデータＩＤ情報Ｎ１８を取得する（手順Ｓ２８１）。

情報検索部１０８は、取得したデータＩＤ情報に対応するセンサデータを、情報一次保持部１０３から読み出す。

具体的には、図９の情報一次保持部１０３のセンサデータテーブルから、図８の情報索引保持部１０４が保持する索引内のデータＩＤ情報Ｎ１８が示すデータＩＤ＝４に対応するセンサデータとして、センサデータＬ１４を読み出す。

さらに、情報検索部１０８は、読み出したセンサデータの各々をリストの１行とする回答リストを生成し、情報検索部１０８内部の回答リスト保持部（不図示）に一時的に保持しておく（手順Ｓ２８２）。

次に、情報検索部１０８は、チャンク索引保持部１０７が保持する索引を検索し、検索式に適合するファイル名情報を取得する。

例えば、情報検索部１０８は、図６のチャンク索引保持部１０７が保持する索引から、図１０の検索式Ｆ２７１に適合するファイル名情報を取得する。具体的には、手順Ｓ２８１と同様に、ルートノードから、検索式Ｆ２７１に合致する属性名と属性値範囲を保持するエントリに対応するノードを辿り、すなわち、Ｎ５１から、Ｎ５３、Ｎ５６、Ｎ６３と辿り、検索式Ｆ２７１に合致するファイル名情報Ｎ６３を取得する（手順Ｓ２８３）。

次に、情報検索部１０８は、検索要求の一括回答フラグの値が「Ｙｅｓ」か否かを判定する（手順Ｓ２８４）。

一括回答フラグが「Ｙｅｓ」であると判定した場合（手順Ｓ２８４：Ｙｅｓ）は、情報検索部１０８は、手順Ｓ２８３で取得したファイル名情報に含まれるファイル名を、情報検索部１０８内部に保持する回答リストに追加する。

例えば、図１０の検索要求Ｆ１５１の一括回答フラグは「Ｙｅｓ」であり、情報検索部１０８は、手順Ｓ２８３で取得したファイル名情報Ｎ６３に含まれるファイル名「ＤＡＴ０３．ＣＮＫ」を、回答リストに追加する（以上、手順Ｓ２８５）。

一方、一括回答フラグの値が「Ｎｏ」の場合（手順Ｓ２８４：Ｎｏ）、この一括回答フラグは、ホスト１３０がチャンクデータファイル名ではなく個々のセンサデータを含む検索結果を要求していることを示している。

そこで、情報検索部１０８は、手順Ｓ２８３で取得したファイル名情報に含まれるファイル名のそれぞれについて、以下の手順を実施する。

まず、分散ファイルシステム１０６からチャンクデータファイルを読み出し（手順Ｓ２８６）、読み出したチャンクデータファイルの各々を、１行１行検査することで検索式に合致するセンサデータを検索し（手順Ｓ２８７）、発見した検索式に合致するセンサデータを、情報検索部１０８内部に保持する回答リストに追加する。

例えば、情報検索部１０８は、手順Ｓ２８３で取得したファイル名情報Ｎ６３に含まれるファイル名「ＤＡＴ０３．ＣＮＫ」に基づいて、分散ファイルシステム１０６から図５のチャンクデータファイルを読み出す。そして、このチャンクデータファイルから、図１０の検索式Ｆ２７１「物品番号＝ＡＡ１〜ＡＡ５，リーダＩＤ＝１０１」に合致するセンサデータＬ２０とＬ２１とＬ２２とを読み出し、回答リストに追加する（以上、手順Ｓ２８８）。

そして、情報検索部１０８は、要求処理部１０１に、回答リストを出力する。要求処理部１０１は、情報検索部１０８から出力される回答リストを含む検索結果を生成し、ネットワーク１２０を介してホスト１３０に送信する。

例えば、一括回答フラグが「Ｙｅｓ」の場合、要求処理部１０１は、手順Ｓ２８１で読み出したセンサデータＬ１４と、手順Ｓ２８３で読み出したファイル名情報Ｎ６３とから構成される回答リストを含む、図１１の検索結果を送信する。

一方、一括回答フラグが「Ｎｏ」の場合、要求処理部１０１は、手順Ｓ２８１で読み出したセンサデータＬ１４と、手順Ｓ２８８で読み出したセンサデータＬ２０とＬ２１とＬ２２とから構成される回答リストを含む、図１２の検索結果を送信する（以上、手順Ｓ２８９）。

その後、情報記録装置１００は、図１３の処理を終了する。

情報記録装置１００から送信される検索結果をホスト１３０が受信すると、ホスト１３０のアプリケーション部１３２は、受信した検索結果を以下のように用いることができる。

まず、検索結果のうち、センサデータが記載されている行は、検索式に合致するセンサデータそのものを示しているので、アプリケーション部１３２は、そのままデータとして自らの処理（アプリケーション実行）に用いることができる。

例えば、図１１の検索結果Ｆ１５２の１行目のセンサデータＬ１４や、図１２の検索結果Ｆ１５３の１〜４行目のセンサデータＬ１４、Ｌ２０、Ｌ２１、Ｌ２２は、図１０の検索要求Ｆ１５１の検索式Ｆ２７１に合致するセンサデータそのものであり、アプリケーション部１３２は、これらをそのままデータとして用いることができる。

また、チャンクデータファイル名が記載されている行は、検索式に合致するセンサデータを含む可能性があるファイルのファイル名を示している。アプリケーション部１３２は、自らと同じくホスト１３０に含まれる分散ファイルシステム１３１から、このチャンクデータファイル名のファイルを読み出す。

一般に分散ファイルシステムは、ネットワークで接続された遠隔のコンピュータ上の情報を読み取る機能を提供するシステムである。本実施形態では、アプリケーション部１３２が分散ファイルシステム１３１からのファイルの読み出しを行うと、ホスト１３０と遠隔の情報記録装置１００上にある分散ファイルシステム１０６が、自身の保持するチャンクデータファイルを分散ファイルシステム１３１へと転送し、分散ファイルシステム１３１が、転送されたチャンクデータファイルをアプリケーション部１３２に読み取らせる。

アプリケーション部１３２は、図１３の手順Ｓ２８７と同様に、読み取ったチャンクデータファイル内を検索して、検索式Ｆ２７１に合致するデータを読み出し、読み出したデータを自らの処理に用いることができる。

あるいはアプリケーション部１３２が、テキストエディタやワープロ、あるいは、テキスト処理言語Ｐｅｒｌ、Ｒｕｂｙ、Ｐｙｔｈｏｎ等の、テキストファイルを取り扱う一般的なソフトウェアを用いて、分散ファイルシステム１３１を経由して読み出したチャンクデータファイルを直接表示するようにしてもよい。チャンクデータファイルの各センサデータは、テキスト形式で格納されているので、ユーザがデータを読み取り、編集等の処理を行うことができる。

なお、本実施例では、情報索引保持部１０４やチャンク索引保持部１０７が保持する索引は、ＵＢＩ−ｔｒｅｅによる索引であるものとした。しかしながら、本発明の範囲はこれに限らず、木構造の索引であれば、ＵＢＩ−ｔｒｅｅでなくとも良い。

例えば、Ｂ−ｔｒｅｅを用いてもよい。ＵＢＩ−ｔｒｅｅとは異なり、Ｂ−ｔｒｅｅは１次元の索引である、すなわち、１種類のみの属性に対する索引であるが、例えば次のようにすれば、情報索引保持部１０４やチャンク索引保持部１０７の索引として用いることができる。

まず、センサデータあるいはチャンクデータファイルの索引付け時には、各属性ごとに、Ｂ−ｔｒｅｅによる索引を生成する。また検索時には、検索式に含まれる各属性ごとに、対応するＢ−ｔｒｅｅによる索引を用いて検索を行い、複数の中間的な検索結果を取得し、さらに、これら中間的な検索結果のＡＮＤをとることで、最終的な検索結果を得ることができる。

ここで、ＡＮＤをとるとは、全ての中間的な検索結果に含まれるセンサデータのみを最終的な検索結果として選択することを意味する。

また、チャンクデータファイルにセンサデータを纏めて切り出す際には、まず、情報一次保持部１０３を参照し、最も過去のデータを読み出す。当該データに含まれる任意の属性について、情報索引保持部１０４が保持する、当該属性に対応するＢ−ｔｒｅｅによる索引を用いて、図７の手順Ｓ２４１と同様に、切り出す部分木を選択する。

部分木を選択する際には、例えば、当該データの当該属性の属性値を含むノードをルートノードから辿り、ルートノードから２段目のノードをルートノードとする部分木を選べばよい。その後は、図７の手順Ｓ２４２と同様に処理すればよい。

以上述べたように、本実施形態では、情報一次保持部から、チャンクデータファイルに纏める相互に似たセンサデータ集合を選択し、取り出し、さらに情報一次保持部から当該センサデータを削除する、という一連の処理を、木構造の索引を用いることによって高速に行うことができる。さらに同時に、検索要求に対し、情報一次保持部から、検索要求に含まれる検索式に合致するセンサデータを検索する処理を、木構造の索引を用いることによって高速に行うことができる。

一般に、索引は高速に検索を行うためのデータ構造であるが、特に、木構造の索引は、似たデータを同じ部分木に集めるという特徴を持つ。本発明はこの特徴を利用し、情報一次保持部に蓄積したセンサデータに対する高速な検索を実現するだけでなく、情報一次保持部に蓄積したセンサデータの中から、予め定められた簡単な規則に従って選んだ索引内の部分木に含まれるデータを、チャンクデータファイルに纏める似たデータとすることにより、チャンクデータファイルに纏めるデータを高速に選択することができる。

さらに、部分木単位で纏めることにより、当該索引から、纏めて切り出したセンサデータのための索引情報を削除することが、当該部分木を削除するだけで高速に実現できる。さらに、部分木単位で纏めることにより、生成するチャンクデータファイルのチャンクメタデータは当該部分木のルートノードの親ノードが保持する、当該部分木のルートノードに対応するエントリに含まれる属性名と属性値範囲と一致するため、当該エントリが含む情報を読み出すことにより、当該チャンクメタデータを高速に取得することができ、当該チャンクデータファイルの索引付けを高速に行うことができる。

なお、本実施形態においては、チャンクデータファイルの形式として、図５に示すように、単純にセンサデータを１行ずつ並べたものとしたが、本発明の範囲はこれに限定されるものではなく、例えば、情報索引保持部１０４から、部分木を切り出す際、当該部分木の構造をチャンクデータファイルに記載しても良い。

なお、本実施形態においては、センサデータ情報の符号化は、「属性＝値」の組の並び形式で表現される可読形式の１行のテキスト情報であるが、本発明の範囲はこれに限定されるものではなく、不可読形式を含む任意の情報符号化方式にも適用できる。また、例えばＸＭＬやＪＳＯＮ仕様等を用いて表現した、複数行からなる可読のテキスト情報に基づく情報符号化方式にも適用できる。

本実施形態においては、チャンクデータファイルは、分散ファイルシステム１０６上に作成されるが、本発明の範囲はこれに限定されるものではなく、ＯＳが一般に提供する通常のファイルシステム上にファイルとして作成してもよい。あるいは、一般にファイルという呼称では呼ばれないものではあるが、ＲＤＢＭＳやＸＭＬデータベースシステム等の情報記録システム上に情報レコードとして、チャンクデータファイルを作成することもできる。

あるいは、分散ファイルシステムとしてＯＳに内蔵されている機能であるＮＦＳやＣＩＦＳ（ＳＭＢ）等上にチャンクデータファイルを作成してもよい。

あるいは、ウェブ技術のＨＴＴＰおよびその拡張であるＷｅｂＤＡＶ等、クラウドと称される技術のＧＦＳやＨａｄｏｏｐ等、又は、キーバリューストアと呼ばれる技術のＤｙｎａｍｏやｍｅｍｃａｃｈｅｄ等上にチャンクデータファイルを作成してもよい。

なお、本発明の装置は、コンピュータとプログラムによっても実現でき、プログラムを記録媒体に記録することも、ネットワークを通じて提供することも可能である。

例えば、情報記録装置１００の全部または一部の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより各部の処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。

また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。

また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の保持装置のことをいう。

さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。

また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。

以上、この発明の実施形態を図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計変更等も含まれる。

１００：情報記録装置
１０１：要求処理部
１０２：情報登録部
１０３：情報一次保持部（情報保持部）
１０４：情報索引保持部
１０５：情報切り出し部
１０６：分散ファイルシステム
１０７：チャンク索引保持部
１０８：情報検索部
１２０：ネットワーク
１３０：ホスト
１３１：分散ファイルシステム
１３２：アプリケーション部
１４０−１〜１４０−３：センサ

Claims (7)

1. 属性名と属性値とを含む情報を保持する情報一次保持部と、
   前記情報一次保持部が保持する前記情報のうち、前記属性名または１つ以上の前記属性名に対応する前記属性値集合に対して木構造をもつ索引を作成する情報登録部と、
   前記情報登録部が作成した前記索引を用いて、木構造の部分木に含まれる前記情報を含むチャンクデータファイルを作成し、前記部分木に含まれる前記情報を前記情報一次保持部から削除し、前記部分木を前記索引から削除する情報切り出し部と、
   を備える情報記録装置。
2. 前記情報登録部は、同じ属性名を持つ情報を同じ部分木に集め、さらに、同じもしくは近い属性値をもつ情報を同じ部分木に集めることで前記索引を生成することを特徴とする請求項１に記載の情報記録装置。
3. 検索すべき情報の条件を示す検索要求信号を受信する要求処理部と、
   情報検索部と、
   をさらに具備し、
   前記情報切り出し部は、生成した前記チャンクデータファイルのファイル名と前記チャンクデータファイル内の前記情報に含まれる属性名と属性値範囲の一覧をチャンク索引情報として前記チャンクデータファイル毎に生成し、
   前記情報検索部は、前記検索すべき情報の条件を満たす前記情報を前記情報一次保持部から読み出し、さらに前記検索すべき情報の条件を満たす前記チャンクデータファイルのファイル名を前記チャンク索引情報から読み出し、
   前記要求処理部は、前記情報検索部が前記情報一次保持部から読み出した前記情報と、前記情報検索部が前記チャンク索引情報から読み出したファイル名と、を含む検索結果情報を送信する
   ことを特徴とする請求項１又は２に記載の情報記録装置。
4. 属性名と属性値とを含む情報を保持する情報一次保持手順と、
   前記情報一次保持手順で保持された前記情報のうち、前記属性名または１つ以上の前記属性名に対応する前記属性値集合に対して木構造をもつ索引を作成する情報登録手順と、
   前記情報登録手順で作成された前記索引を用いて、木構造の部分木に含まれる前記情報を含むチャンクデータファイルを作成し、前記部分木に含まれる前記情報を前記情報一次保持部から削除し、前記部分木を前記索引から削除する情報切り出し手順と、
   を行う情報記録方法。
5. 前記情報登録手順では、同じ属性名を持つ情報を同じ部分木に集め、さらに、同じもしくは近い属性値をもつ情報を同じ部分木に集めることで前記索引を生成することを特徴とする請求項４に記載の情報記録方法。
6. 前記情報切り出し手順では、さらに、生成した前記チャンクデータファイルのファイル名と前記チャンクデータファイル内の前記情報に含まれる属性名と属性値範囲の一覧をチャンク索引情報として前記チャンクデータファイル毎に生成し、
   検索すべき情報の条件を示す検索要求信号を受信する検索要求受信手順と、
   前記検索すべき情報の条件を満たす前記情報を前記情報一次保持手順で保持されている前記情報から読み出し、さらに前記検索すべき情報の条件を満たす前記チャンクデータファイルのファイル名を前記情報切り出し手順で生成した前記チャンク索引情報から読み出す情報検索手順と、
   前記情報検索手順で読み出した前記情報及び前記ファイル名を含む検索結果情報を送信する要求処理手順と、
   を行うことを特徴とする請求項４又は５に記載の情報記録方法。
7. コンピュータに、請求項４から６のいずれかに記載の情報記録方法を実行させるためのプログラム。

Images