JPWO2016016944A1 - データベース管理システム及びデータベース管理方法 - Google Patents

Abstract

データベース管理システム（ＤＢＭＳ）は、時刻を示す情報とレコードを対応づけて格納するデータベースから、対応付けられた情報が示す時刻から所定期間が経過したレコードを削除するようになっている。ＤＢＭＳは、所定期間に関わらずにレコードをデータベースに残す期間を示す残存条件を受け付け、残存条件に基づいて、データベースのレコードを、所定期間が経過した後もデータベースに残すよう制御する。

Description

本発明は、概して、データベースを管理する技術に関する。

アクセス頻度が高いファイル又は新しいファイルをＦＣ（Ｆｉｂｒｅ Ｃｈａｎｎｅｌ）ディスクに配置し、アクセス頻度が低いファイル又は古いファイルをＳＡＴＡ（Ｓｅｒｉａｌ ＡＴＡ）ディスクに配置する技術が知られている（特許文献１）。

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

時系列データの分析等において、ユーザ（例えば分析者）が指定する検索条件を満たす時系列データを検索することが行われる。検索条件としては、１つの長い期間が指定されることもあれば、離散した複数の短い期間が指定されることもある。

時系列データは、時々刻々と増加し続けるデータである。時系列データを少なくとも低速の記憶デバイスに格納する際（例えばアーカイブの際）には、一定時間毎の複数の時系列データを１つのファイルとし、ファイル単位で、時系列データを格納することが考えられる。

また、時系列データは時々刻々と増加し続けるので、時系列データの格納においては、新しい時系列データを高速の記憶デバイスに格納しつつ、高速の記憶デバイスにおいて古くなった時系列データを高速記憶デバイスから削除することが短期間で頻繁に行われることも考えられる。

このため、或る時点での検索では、適合する時系列データが高速の記憶デバイスに存在していたが故にその時系列データへのアクセスが速いが、一定時間後の同じ検索では、適合する時系列データが高速の記憶デバイスに無く低速の記憶デバイスにあるが故にその時系列データへのアクセスが遅いことがあり得る。

特許文献１の技術を単に適用しても、上記の問題を解決することは困難である。なぜなら、古いファイルが高速記憶デバイスに残らないことには変わりがなく、また、検索において実際にアクセスされる時系列データがわからない（例えば、連続した多数の時系列データがアクセスされることもあれば、大きく離散した時系列データがアクセスされることもある）ためである。

この種の問題は、検索に限らず、指定された条件を満たす時系列データにアクセスするケースについても発生し得る。また、この種の問題は、時系列データ以外のデータにアクセスするケースについても発生し得る。

データベース管理システム（ＤＢＭＳ）は、時刻を示す情報とレコードを対応づけて格納するデータベースから、対応付けられた情報が示す時刻から所定期間が経過したレコードを削除するようになっている。ＤＢＭＳは、所定期間に関わらずにレコードをデータベースに残す期間を示す残存条件を受け付け、残存条件に基づいて、データベースのレコードを、所定期間が経過した後もデータベースに残すよう制御する。

データに高速にアクセスできる可能性が向上する。

実施例に係る計算機システムのハードウェア構成の一例を示す。 計算機システムの機能構成の一例を示す。 センサデータの保存期間と配置場所との関係の一例を示す。 ＣＳＶファイルの一例を示す。 ＤＢの構成例を示す。 配置管理テーブルの構成例を示す。 インポート処理部の処理例のフローチャートを示す。 ロード機能部の処理例のフローチャートを示す。 ＳＱＬパーサの処理例のフローチャートを示す。 ＤＢエンジンの処理例のフローチャートを示す。 データ制御部の処理例のフローチャートを示す。 外部データアクセス部の処理例のフローチャートを示す。 センサデータ監視ＧＵＩの一例を示す。 受付部が提供する残存条件指定ＧＵＩの一例を示す。 残存条件管理テーブルの構成例を示す。 データ制御部の別の処理例のフローチャートを示す。

以下、一実施例を説明する。なお、以下の説明では、「×××管理テーブル」等の表現にて管理される情報を説明することがあるが、これら情報はテーブル以外のデータ構造で管理されてもよい。そのため、データ構造に依存しないことを示すために「×××管理テーブル」を「×××管理情報」と呼ぶことができる。また、各要素の識別情報として、「ＩＤ」又は「名前」が使用されるが、他種の識別情報が使用されてよい。また、プログラムは、プロセッサによって実行されることで定められた処理をメモリ及び通信ポート（通信Ｉ／Ｆ）を用いながら行うため、プログラムを実行することにより行われる処理を、プロセッサを主語とした説明としてもよい。また、プログラムの一部または全ては、専用ハードウェアによって実現されてもよい。また、各種プログラムは、プログラム配布サーバや、計算機が読み取り可能な記憶媒体によって各計算機にインストールされてもよい。

図１は、実施例に係る計算機システムのハードウェア構成の一例を示す。

計算機システム１は、クライアント装置１１と、ＤＢ（データベース）サーバ１２と、ストレージ装置１３と、ファイルシステム１１９とを有する。クライアント装置１１とＤＢサーバ１２間、及び、ＤＢサーバ１２及びファイルシステム１１９間は、第１の通信ネットワーク（例えば、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）又はインターネット）で接続されてよい。ＤＢサーバ１２とストレージ装置１３間は、第１の通信ネットワークより高速の第２の通信ネットワーク（例えばＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ））で接続されてよい。ＤＢサーバ１２とストレージ装置１３間が、ＤＢサーバ１２とストレージ装置１３の各々の内部において行われる通信のプロトコル（例えばＰＣＩｅ）と同じプロトコルで通信されてよい。クライアント装置１１、ＤＢサーバ１２、ストレージ装置１３及びファイルシステム１１９のうちの少なくとも１つが、それぞれ、複数存在し得る。

ストレージ装置１３は、複数（又は１つ）の記憶デバイス３２と、複数の記憶デバイス３２に対するデータのＩ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）を制御するストレージコントローラ３１とを有する。記憶デバイス３２は、典型的には不揮発性の記憶デバイスであり、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）又はＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）でよい。ストレージコントローラ３１は、複数の記憶デバイス３２を制御して、ＤＢサーバ１２に論理的な記憶領域（論理ボリューム）を提供する。ストレージコントローラ３１は、複数の記憶デバイス３２を制御して、ＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙｓ ｏｆ Ｉｎｅｘｐｅｎｓｉｖｅ （ｏｒ Ｉｎｄｅｐｅｎｄｅｎｔ） Ｄｉｓｋｓ）グループを構成してもよい。

ＤＢサーバ１２は、計算機（例えば１以上の物理計算機の集合）の一例であり、メモリ２２と、記憶デバイス２５と、ＦＥ−Ｉ／Ｆ２３と、ＢＥ−Ｉ／Ｆ２４と、それらに接続されたプロセッサ２１とを有する。プロセッサ２１は、１以上のプロセッサ（例えばマイクロプロセッサ）であり、メモリ２２からコンピュータプログラムを読み出して実行することにより、１又は複数の機能を実現する。メモリ２２は、１以上のメモリであり、コンピュータプログラム及びデータを記憶する。メモリは、揮発性又は不揮発性のメモリであり、一例として、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＦｅＲＡＭ（Ｆｅｒｒｏｅｌｅｃｔｒｉｃ ＲＡＭ）及びＭＲＡＭ（Ｍａｇｎｅｔｏｒｅｓｉｓｔｉｖｅ ＲＡＭ）のうちの少なくとも１つがある。記憶デバイス２５は、１以上の記憶デバイス（例えば不揮発性の記憶デバイス）であり、記憶デバイスの一例としては、ＨＤＤ又はＳＳＤでよい。ＦＥ−Ｉ／Ｆ２３は、フロントエンドの装置に接続されるインターフェイスデバイスであり、ＤＢサーバ１２とクライアント装置１１との間のデータ送受信を制御する。ＢＥ−Ｉ／Ｆ２４は、バックエンドの装置に接続されるインターフェイスデバイスであり、ＤＢサーバ１２とストレージ装置１３との間のデータ送受信を制御する。プロセッサ２１、メモリ２２、ＦＥ−Ｉ／Ｆ２３及びＢＥ−Ｉ／Ｆ２４をまとめて「サーバコントローラ」と呼ぶこともできる。

クライアント装置１１は、ＤＢサーバ１２に対して、クエリ（例えば検索クエリ）を送信し、ＤＢサーバ１２からクエリ処理結果を受信してよい。クライアント装置１１は、クエリ送信元の一例である。

ファイルシステム１１９は、ＤＢサーバ１２から独立したファイルサーバ（ストレージ）であるが、ＤＢサーバ１２に設けられたファイルシステム（例えば、ファイルシステム空間と、ファイルシステム空間に対するファイルのＩ／Ｏを制御するファイルシステム制御）でもよい。ファイルシステム１１９は、１以上のファイルを格納する。

図２は、計算機システム１の機能構成の一例を示す。

まず、図２を参照して、計算機システム１の概要を説明する。

計算機システム１において、ＤＢサーバ１２は、センサ１０１から出力される時系列データを、キャッシュ領域１０２に一時的に保存し、時系列データ群単位で、時系列データを、ＤＢ１１７及びファイルシステム１１９の少なくともＤＢ１１７に格納する。本実施例では、ＤＢサーバ１２は、キャッシュ領域１０２内の時系列データ群をＤＢ１１７及びファイルシステム１１９の両方に格納する。ＤＢ１１７には、時系列データ群に対応するレコード群が追加される。ファイルシステム１１９には、時系列データ群を有するファイルが格納される。時系列データ群は、２以上の時系列データの集合であり、その２以上の時系列データは、例えば、周期の間に蓄積された時系列データである。従って、全ての時系列データ群が同じ数の時系列データを有するわけではない。ＤＢサーバ１２は、時系列データ群毎に時刻区間及び配置場所等を配置管理テーブル１２０に登録する。

ＤＢサーバ１２は、レコード時刻から所定期間（例えば２年間）を経過したそのレコードを、ＤＢ１１７から削除するようになっている。「レコード時刻」は、レコードに対応付けられた情報が表す時刻であり、例えば、そのレコードがＤＢ１１７に格納されたときの時刻、又は、そのレコードに記録されている時刻である。レコードには、そのレコードに対応する時系列データが有する全てのデータ要素（少なくとも時刻及び計測値）が記録される。また、「所定期間」は、予め定められた期間であり、例えば、デフォルトの期間である。

また、ＤＢサーバ１２は、クエリ条件（クエリで指定された条件）を満たすデータがＤＢ１１７に無ければ、ファイルシステム１１９から、クエリ条件を満たすデータを含んだファイルである対象ファイルに基づく表から、クエリ条件を満たすデータを取得し、取得したデータを、クエリ送信元（例えばアプリケーション１０７）に返す。「対象ファイルに基づく表」とは、対象ファイルが有する時系列データ群を含んだ一時的な表であってもよいし、その一時的な表を基に更新されたＤＢ１１７（ＤＢ１１７内の表）でもよい。

時系列データの検索において、ユーザは様々な部分のデータを取得する。この時、ＤＢ１１７のようなデータベースよりも、ファイルシステム１１９の方が、アクセス性能が低い（例えばレスポンスタイムが長い）。このため、アクセス対象データ（クエリ条件を満たすデータ）は、なるべく、ＤＢ１１７に存在することが望ましい。一方で、上述したように、ＤＢ１１７から、レコードが、そのレコードのレコード時刻から所定期間経過すると削除される。

そこで、ＤＢサーバ１２は、レコードの残存条件の指定を受け付ける。残存条件は、時系列データに関する複数の属性であり少なくとも時刻を含んだ複数の属性のうちの１以上の属性と、その１以上の属性の各々についての値とにより定義されてよい。時刻以外の属性は、ユーザ所望の属性とすることができる。残存条件は、例えば、少なくとも残存期間を含んでよい。「残存期間」とは、上記所定期間（例えばデフォルトの期間）に関わらずにレコードをＤＢ１１７に残す期間である。残存期間は、所定期間より長くても短くてもよい。ＤＢサーバ１２は、残存条件を、例えば、ＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）のようなユーザインターフェイスを通じて受け付ける。計算機システム１は、受け付けた残存条件を残存条件管理テーブル１２８に登録する。ＤＢサーバ１２は、レコード時刻から所定期間を経過したレコードが、残存条件を満たすレコードであれば、そのレコードをＤＢ１１７に残す。例えば、ＤＢサーバ１２は、レコード時刻から所定期間を経過しても、そのレコード時刻が対応付けられたレコードをＤＢ１１７に残す。これにより、アクセス対象のデータ（例えばクエリで指定されている条件を満たすデータ）を含んだレコードがＤＢ１１７に存在している可能性が高くなり、故に、時系列データに高速にアクセスできる可能性が向上する。

また、ＤＢサーバ１２は、所定のデータ単位（例えば、時系列データ群単位、レコード単位）でレコードのアクセス頻度を管理し、アクセス頻度が高い（例えばアクセス頻度が所定の閾値を超えた）レコードも、そのレコード時刻から所定期間を経過してもＤＢ１１７に残すことができる。これにより、頻繁にアクセスされるデータを含んだレコードがＤＢ１１７に存在している可能性が高くなり、故に、時系列データに高速にアクセスできる可能性が向上する。

以下、図２を参照して、本実施例を詳細に説明する。

計算機システム１が、キャッシュ領域１０２、インポート処理部１０３、ロード機能部１０４、ＤＢ１１７、ファイルシステム１１９、ＤＢＭＳ１０９、ＳＱＬ Ｉ／Ｆ１０８、アプリケーションプログラム（以下、アプリケーション）１０７、配置管理テーブル１２０、残存条件管理テーブル１２８、ＳＱＬパーサ１１１、ＤＢエンジン１１０、受付部１２６、データ制御部１１２、表関数Ｉ／Ｆ１１３及び外部データアクセス部１１４を有する。

本実施例では、ＤＢサーバ１２が、キャッシュ領域１０２、インポート処理部１０３、ロード機能部１０４、ＤＢＭＳ１０９、ＳＱＬ Ｉ／Ｆ１０８、配置管理テーブル１２０、残存条件管理テーブル１２８、ＳＱＬパーサ１１１、ＤＢエンジン１１０、受付部１２６、データ制御部１１２、表関数Ｉ／Ｆ１１３及び外部データアクセス部１１４を有する。しかし、それらのうち、キャッシュ領域１０２、インポート処理部１０３、ロード機能部１０４、ＳＱＬ Ｉ／Ｆ１０８、配置管理テーブル１２０、残存条件管理テーブル１２８、表関数Ｉ／Ｆ１１３及び外部データアクセス部１１４のうちの少なくとも１つが、ＤＢサーバ１２以外の装置に存在してもよい。例えば、配置管理テーブル１２０及び残存条件管理テーブル１２８は、いずれも、ＤＢＭＳ１０９が参照可能であればよい。

また、図示の例によれば、ＤＢＭＳ１０９が、ＳＱＬパーサ１１１、ＤＢエンジン１１０、受付部１２６、データ制御部１１２、表関数Ｉ／Ｆ１１３及び外部データアクセス部１１４を有する。しかし、受付部１２６、表関数Ｉ／Ｆ１１３及び外部データアクセス部１１４のうちの少なくとも１つが、ＤＢＭＳ１０９の外に存在してもよい。

また、インポート処理部１０３及びロード機能部１０４は、１つの要素に統合されてもよいし、より多くの要素に分割されてもよい。例えば、格納部の一例が、インポート処理部１０３及びロード機能部１０４である。また、ＳＱＬパーサ１１１、ＤＢエンジン１１０及びデータ制御部１１２は、１つの要素に統合されてもよいし、より多くの要素に分割されてもよい。例えば、制御部の一例が、ＳＱＬパーサ１１１、ＤＢエンジン１１０及びデータ制御部１１２である。制御部は、更に、表関数Ｉ／Ｆ１１３及び外部データアクセス部１１４を含んでもよい。

また、本実施例において、インポート処理部１０３、ロード機能部１０４、ＳＱＬ Ｉ／Ｆ１０８、アプリケーション１０７、ＳＱＬパーサ１１１、ＤＢエンジン１１０、受付部１２６、データ制御部１１２、表関数Ｉ／Ｆ１１３及び外部データアクセス部１１４のうちの少なくとも１つは、プロセッサがコンピュータプログラムを実行することにより実現される機能でよい。

キャッシュ領域１０２には、複数（又は１つ）のセンサ１０１のそれぞれから送信されたセンサデータ１５１が格納される。センサデータ１５１は、本実施例での時系列データである。センサデータ１５１は、複数の属性（時刻を含む）にそれぞれ対応した複数の値を含む。属性が、時刻であれば、値は、年月日時分秒のような所定の単位で表現された値（時刻としての値）である。属性が、センサＩＤ（センサの識別子）であれば、値は、数字及びアルファベット等で表現された値（センサＩＤとしての値）である。属性が、メトリック（有効電力、無効電力等）であれば、値は、メトリックに対応した値（計測された有効電力値、無効電力値等）である。センサ１０１は、時系列データソースの一例であり、電力系統に関する様々な状況を計測するための装置であってよい。センサ１０１は、電力系統の或る地点における或る時刻（又は時間）の有効電力値、無効電力値、電力位相及び周波数などを計測してよい。各センサ１０１から、センサデータ１５１が時々刻々と（ストリーム的に）送信され、送信されたセンサデータがキャッシュ領域１０２に蓄積される。キャッシュ領域１０２は、メモリ２２上に構成されてもよいし、記憶デバイス２５上に構成されてもよいし、ＤＢサーバ１２以外の装置に設けられてもよい。

インポート処理部１０３は、キャッシュ領域１０２からセンサデータ群を取得し、取得したセンサデータ群を含んだファイルを作成する。例えば、インポート処理部１０３は、キャッシュ領域１０２から５分間分のセンサデータの集合としてセンサデータ群を取得し、これらを含む１つの（つまり５分間分のセンサデータを含んだ）ファイルを作成してよい。インポート処理部１０３は、ファイルとして、ＤＢ１１７にセンサデータを登録するためのベースとなるＣＳＶファイル１０５（第１種のファイルの一例）と、ファイルシステム１１９に登録されるセンサデータを含んだ圧縮ファイル１０６（第２種のファイルの一例）とを含む。圧縮ファイル１０６は、ＣＳＶファイル１０５の圧縮ファイルでもよい。圧縮方式の一例としては、ｇｚｉｐ及びｂｚｉｐ２などがある。インポート処理部１０３は、ＣＳＶファイル１０５及び圧縮ファイル１０６を、ロード機能部１０４へ渡す。なお、インポート処理部１０３は、センサデータ群を取得した場合、そのセンサデータ群をキャッシュ領域１０２から削除してよい。これにより、キャッシュ領域１０２に、新たなセンサデータを蓄積可能な領域を増やすことができる。また、インポート処理部１０３は、直接的に又は間接的に（例えばデータ制御部１１２を介して）、配置管理テーブル１２０に、キャッシュ領域１０２内のセンサデータ群の配置場所として「キャッシュ領域」を登録してよい。配置管理テーブル１２０の詳細については後述する。また、以下の説明では、ＣＳＶファイル１０５に含まれているデータであって、１つのセンサデータに対応するデータを、「計測エントリ」と言う。ＣＳＶファイル１０５は、センサデータ群に対応する計測エントリ群（２以上の計測エントリの集合）を含む。

ロード機能部１０４は、インポート処理部１０３から渡されたＣＳＶファイル１０５に含まれる計測エントリ群に対応した計測レコード群をＤＢ１１７に登録する。「計測レコード」とは、計測エントリが含むデータを含んだレコードである。また、ロード機能部１０４は、インポート処理部１０３から渡された圧縮ファイル１０６をファイルシステム１１９に格納する。本実施例では、同一のセンサデータ群についてＣＳＶファイル１０５と圧縮ファイル１０６の両方が作成され、ＣＳＶファイル１０５に対応した計測レコード群がＤＢ１１７に登録され、圧縮ファイル１０６がファイルシステム１１９に格納される。しかし、格納は、その例に限られない。例えば、センサデータ群に対応したＣＳＶファイル１０５のみが作成されそのＣＳＶファイル１０５に対応した計測レコード群がＤＢ１１７に追加され、計測レコード群がＤＢ１１７から削除される場合に、削除される計測レコード群がファイル化されてファイルシステム１１９に移動されてもよい。言い換えれば、格納は、キャッシュ領域１０２から出力されたセンサデータがＤＢ１１７とファイルシステム１１９のうちの少なくとも一方に存在するようになっていればよい。以下、センサデータ群に対応した計測レコード群がＤＢ１１７に格納されることを、「センサデータ群がＤＢ１１７に格納される」、のように省略し、センサデータ群に対応した圧縮ファイル１０６がファイルシステム１１９に格納されることを、「センサデータ群がファイルシステム１１９に格納される」、のように省略することがある。ファイルシステム１１９のファイル管理の一例としては、ＦＡＴ３２及びｅｘｔ３などがある。

ロード機能部１０４は、センサデータ群をＤＢ１１７に格納した場合、配置管理テーブル１２０に、そのセンサデータ群の配置場所として「ＤＢ」を登録してよい。ロード機能部１０４は、センサデータ群をファイルシステム１１９に格納した場合、配置管理テーブル１２０に、そのセンサデータ群の配置場所として「ファイルシステム」を登録してよい。なお、同一のセンサデータ群がＤＢ１１７及びファイルシステム１１９の両方に格納された場合には、そのセンサデータ群の配置場所として「ＤＢ」（つまり、アクセス性能の高い方の格納先）が登録されてよい。

ＳＱＬ Ｉ／Ｆ１０８は、アプリケーション１０７に対してＳＱＬ（Structured Query Language）を利用するためのＩ／Ｆを提供する。例えば、アプリケーション１０７の検索要求は、ＳＱＬ Ｉ／Ｆ１０８によってＳＱＬクエリ（ＳＱＬで表現されたクエリ）に変換され、ＤＢＭＳ１０９に送信されてよい。以下、ＳＱＬクエリを、単に「クエリ」ということがある。

ＤＢＭＳ１０９は、ＤＢ１１７を管理する。ＤＢＭＳ１０９は、残存条件管理テーブル１２８、配置管理テーブル１２０、及び、ファイルシステム１１９の圧縮ファイルのうちの少なくとも１つを制御してもよい。ＤＢＭＳ１０９は、ＤＢエンジン１１０と、データ制御部１１２と、表関数Ｉ／Ｆ１１３と、外部データアクセス部１１４とを有する。ＤＢエンジン１１０は、ＳＱＬパーサ１１１を有してよい。

ＳＱＬパーサ１１１は、ＳＱＬを構文解析し、ＤＢエンジン１１０にその解析したＳＱＬクエリを実行させる。ＳＱＬパーサ１１１は、そのＳＱＬクエリに表関数が含まれている場合、その表関数を、データ制御部１１２に実行させてよい。

ＤＢエンジン１１０は、ＳＱＬパーサ１１１によって構文解析されたＳＱＬクエリを実行する。例えば、ＤＢエンジン１１０は、ＤＢ１１７のレコードの検索、追加、削除及び変更などを行う。

データ制御部１１２は、計測レコードのレコード時刻からの期間が所定期間（例えば２年）経過した場合にその計測レコードをＤＢ１１７から削除する。時々刻々と増加する全てのセンサデータの計測レコードをＤＢ１１７に格納しておくことは困難だからである。このとき、データ制御部１１２は、残存条件を満たす計測レコードについては、その計測レコードのレコード時刻からの期間が所定期間経過しても削除しないでよい。また、データ制御部１１２は、アクセス頻度の高い（例えば、単位時間当たりのアクセス回数が所定の閾値以上）計測レコードについては、所定期間経過しても削除しないでよい。頻繁にアクセスされる計測レコードは、ＤＢ１１７に残しておいた方が検索速度が向上するためである。

データ制御部１１２は、配置管理テーブル１２０を作成したり更新したりする。データ制御部１１２は、配置管理テーブル１２０から検索条件を満たす管理レコードを検索してよい。検索条件は、クエリ条件（クエリで指定された条件）の一例である。データ制御部１１２は、配置管理テーブル１２０に、管理レコードを追加したり、条件を満たす管理レコードを削除したり、条件を満たす管理レコードにおける指定された値を変更したりしてよい。データ制御部１１２は、配置管理テーブル１２０に対して、新たなカラムを追加したり、既存のカラムを削除したりしてよい。データ制御部１１２は、カラムの追加、削除又は変更の要求を、ユーザからユーザインターフェイスを通じて受け付けることができ、その要求に応答して、カラムの追加、削除又は変更を行うことができる。カラムを追加、削除又は変更するということは、ＤＢ１１７及び配置管理テーブル１２０での管理対象の計測属性を追加、削除又は変更することと同義である。

データ制御部１１２は、ＤＢ１１７とファイルシステム１１９とを連携させることができる。例えば、データ制御部１１２は、検索条件（検索クエリで指定された検索条件）を満たす計測レコードがＤＢ１１７に無い場合、例えば、配置管理テーブル１２０を基に、外部データアクセス部１１４を通じて、検索条件を満たすデータを含んだ圧縮ファイルをファイルシステム１１９から取得する。データ制御部１１２は、取得された圧縮ファイルが有するセンサデータ群に対応したレコード群を格納した一時表を作成する。データ制御部１１２は、その一時表内のレコード群を、ＤＢ１１７に格納してよい。ＤＢエンジン１１０は、検索条件を満たす計測レコードをＤＢ１１７から検索し、該当する計測レコードが無い場合に、データ制御部１１２を通じて、検索条件を満たすデータを取得することができる。すなわち、データ制御部１１２よって、ＤＢ１１７及びファイルシステム１１９をシームレスに検索することができる。データ制御部１１２は、配置管理テーブル１２０を基に、検索条件に適合するデータの配置場所（キャッシュ領域１０２、ＤＢ１１７及びファイルシステム１１９の何れに存在するか）を知ることができる。データ制御部１１２は、ＤＢ１１７とファイルシステム１１９に加えて、キャッシュ領域１０２も検索範囲としてもよい。

表関数Ｉ／Ｆ１１３は、データ制御部１１２が、外部データアクセス部１１４を利用するためのＩ／Ｆである。データ制御部１１２は、表関数Ｉ／Ｆ１１３を介して外部データアクセス部１１４の外部関数を呼び出し、ファイルシステム１１９又はキャッシュ領域１０２にアクセスしてよい。

外部データアクセス部１１４は、ファイルシステム１１９に格納されている圧縮ファイル１０６、及びキャッシュ領域１０２に格納されているセンサデータ群に、アクセスする。

配置管理テーブル１２０は、センサデータ群毎に管理レコードを有する。管理レコードは、その管理レコードに対応したセンサデータ群がＤＢ１１７、ファイルシステム１１９及びキャッシュ領域１０２の何れに配置されているかを表す。配置管理テーブル１２０の詳細については後述する（図６参照）。

図３は、センサデータの保存期間と配置場所との関係の一例を示す。

キャッシュ領域１０２には、センサ１０１から送信されたセンサデータが格納される。インポート処理部１０３が、５分間ごとに、キャッシュ領域１０２に蓄積されているセンサデータ群が取得される。言い換えれば、センサデータがキャッシュ領域１０２に残存できる期間は最大５分である。５分間分のセンサデータの集合であるセンサデータ群が、ＤＢ１１７及びファイルシステム１１９の両方に格納される。

ＤＢ１１７には、センサデータ群が格納されてから２年経過すると、そのセンサデータ群が削除される。ただし、そのセンサデータ群のうち、所定の条件を満たすセンサデータ（例えば、残存条件を満たすセンサデータ、又は、アクセス頻度が高いセンサデータ）が、ＤＢ１１７に残る。センサデータ（計測レコード）の削除は、センサデータ群単位でもよいし、センサデータ単位でもよい。

ファイルシステム１１９には、センサデータ群が圧縮ファイル１０６として格納される。ファイルシステム１１９には、図示のように、センサデータ群がずっと保存されていてよい。本実施例では、図示の通り、キャッシュ領域１０２内のセンサデータ群（５分間分のセンサデータ）がＤＢ１１７及びファイルシステム１１９の両方に格納されるが、センサデータ群は、まず、ＤＢ１１７に格納され、センサデータ群が格納されてから２年経過後に、そのセンサデータ群のうち所定の条件を満たすセンサデータ以外のセンサデータが、ＤＢ１１７からファイルシステム１１９に移動されてもよい。また、上述したように、ＤＢ１１７とファイルシステム１１９の両方に（重複して）格納されているセンサデータについては、配置場所が「ＤＢ」とされる。ＤＢ１１７の方がファイルシステム１１９よりもアクセス性能が高く、故に、ＤＢ１１７を優先的に検索範囲とするためである。

以下の説明では、センサデータがＤＢ１１７に保存される上記所定期間（２年）を、「ＤＢ保存期間」ということがある。

図４は、ＣＳＶファイル１０５の一例を示す。

ＣＳＶファイル１０５は、センサデータ群（５分間分のセンサデータ）に対応した計測エントリ群（２以上の計測エントリ）を有する。ＣＳＶファイル１０５において、１行が１つの計測エントリであってよい。そして、１つの計測エントリを構成する各値は、カンマなどで区切られてよい。

例えば、図４に示すＣＳＶファイル１０５において、１行目の計測エントリ５１０の１番目の値は、計測値が計測された時刻（「計測時刻」という）を表す。２番目の値は、計測時刻において計測された有効電力値を表す。３番目の値は、計測時刻において計測された無効電力値を表す。

ＣＳＶファイル１０５のファイル名には、センサデータに関する属性（「計測属性」という）が含まれてよい。計測属性の一例として、センサＩＤ及びメトリックＩＤがあってよい。センサＩＤは、センサデータを計測したセンサ１０１を識別するための情報である。メトリックＩＤは、センサデータのメトリック（計測値の種類）を識別するための情報である。メトリックＩＤと計測値との関係は、予め設定されてよい。例えば、メトリックＩＤ「ｍｅｔ１」は、有効電力値及び無効電力値のメトリックを表すものと予め設定されてよい。

図４に示すＣＳＶファイル名「Ｉｔｅｍ１＿ｍｅｔ１＿０００．ｃｓｖ」において、「Ｉｔｅｍ１」はセンサＩＤを表し、「ｍｅｔ１」はメトリックＩＤを表す。また、「０００」はファイルの連番を表す。

図５は、ＤＢ１１７の構成例を示す。

ＤＢ１１７には、計測レコード群が２年間保存され、保存期間が２年を超えた計測エントリは順次削除される。計測レコードの構成要素として（言い換えれば、センサデータの構成要素として）、センサデータに関する複数の計測属性にそれぞれ対応した複数の値、例えば、計測時刻６０１と、センサＩＤ６０２と、有効電力値６０３と、無効電力値６０４とを有する。

計測時刻６０１は、計測値（有効電力値及び無効電力値）が計測された時刻を表す。計測時刻６０１は、センサデータがキャッシュ領域１０２に格納された時刻であってもよい。センサＩＤ６０２は、計測レコードに対応したセンサデータを出力した（センサデータ内の計測値を計測した）センサ１０１を識別する情報である。有効電力値６０３は、センサＩＤ６０２に対応するセンサ１０１が計測時刻に計測した有効電力値（ｋＷ）である。無効電力値６０４は、センサＩＤ６０２に対応するセンサ１０１が計測時刻に計測した無効電力値（ｋＷ）である。

なお、ＤＢ１１７は、ストレージ装置１３に存在してもよいし、ＤＢサーバ１２内のメモリ２２に存在してもよい（インメモリ）。

図６は、配置管理テーブル１２０の構成例を示す。

配置管理テーブル１２０は、センサデータ群毎に管理レコードを有し、各管理レコードが、先頭の計測時刻９０１と、最後尾の計測時刻９０２と、センサＩＤ９０３と、メトリックＩＤ９０４と、ファイル名９０５と、配置場所９０６とを有する。

先頭の計測時刻９０１は、対応するセンサデータ群の先頭のセンサデータが有する計測時刻を表す。最後の計測時刻９０２は、対応するセンサデータ群の最後尾の計測時刻を表す。センサデータ群は、２以上の時系列データの集合であるので、そのセンサデータ群に対応する圧縮ファイル（ファイル名９０５の示す圧縮ファイル）には、先頭の計測時刻９０１から最後尾の計測時刻９０２までのセンサデータ群が含まれる。

センサＩＤ９０３は、対応するセンサデータ群の各々のセンサデータを出力したセンサ１０１を識別する情報である。メトリックＩＤ９０４は、対応するセンサデータ群の各々のセンサデータ内の計測値のメトリックを識別するための情報である。ファイル名９０５は、対応するセンサデータ群の圧縮ファイルのファイル名を表す。

配置場所９０６は、対応するセンサデータ群が何れの場所に配置されているかを表す。例えば、配置場所９０６が「ファイルシステム」の場合、センサデータ群は、ファイルシステム１１９に配置されていることを表す。配置場所９０６が「ＤＢ」の場合、センサデータ群は、少なくともＤＢ１１７に配置されていることを表す。配置場所９０６が「キャッシュ領域」の場合、センサデータ群（先頭の計測時刻９０１が表す時刻のセンサデータ及びその時刻以降のセンサデータ）がキャッシュ領域１０２に配置されていることを表し、且つ、そのセンサデータ群が未だインポート処理部１０３によってキャッシュ領域１０２から取得されていないことも表す。配置場所９０６を基に、ＤＢ１１７及びファイルシステム１１９だけでなくキャッシュ領域１０２からもセンサデータの取得が可能となる。

図３のように、センサデータ群が２年間ＤＢ１１７に保存される場合、最後尾の計測時刻９０２から２年以下のセンサデータ群に対応した管理レコードの配置場所９０６は「ＤＢ」となり、最後尾の計測時刻９０２から２年を経過したセンサデータ群に対応した管理レコードの配置場所９０６は「ファイルシステム」となる。最後尾の計測時刻９０２から２年を経過したセンサデータ群は、ＤＢ１１７から削除され、ファイルシステム１１９にのみ存在するためである。

圧縮ファイルに対応したセンサデータ群のうち、センサデータ群の内の一部が、アクセス頻度の高い場合、データ制御部１１２は、圧縮ファイルを、アクセス頻度の高い一部のセンサデータ群（１以上のセンサデータ）に対応した第１圧縮ファイル（第１ファイルの一例）と、それ以外のセンサデータ群（１以上のセンサデータ）に対応した１以上の第２圧縮ファイル（第２ファイルの一例）とに分割して、第１圧縮ファイル及び１以上の第２圧縮ファイルのそれぞれについて管理レコードを生成してよい。例えば、時刻区間「００：０５：００．０００〜００：０９：５９．９９９」のセンサデータ群に対応した圧縮ファイルが、３つの圧縮ファイルに分割されてよい（３つの圧縮ファイルにそれぞれ対応した管理レコード９１０ｂ〜９１０ｄを参照）。具体的には、例えば、そのセンサデータ群のうち、時刻区間「００：０６：００．０００〜００：０６：５９．９９９」のセンサデータ群のアクセス頻度が高かった場合、データ制御部１１２は、１つの圧縮ファイルを、時刻区間「００：０６：００．０００〜００：０６：５９．９９９」のセンサデータ群に対応した第１圧縮ファイルと、それ以外のセンサデータ群に対応した２つの第２圧縮ファイル（「００：０５：００．０００〜００：０５：５９．９９９」のセンサデータ群に対応した圧縮ファイルと、「００：０７：００．０００〜００：０９：５９．９９９」のセンサデータ群に対応した圧縮ファイル）とに分割する。そして、データ制御部１１２は、第１圧縮ファイルに対応したセンサデータ群を、ＤＢ１１７からの削除対象から除外する。これにより、アクセス対象のデータがＤＢ１１７に存在する可能性が高くなるだけでなく、５分間分のセンサデータ群の全てをＤＢ１１７に残す場合と比較して、ＤＢ１１７を効率的に使用することができる。データ制御部１１２は、ファイルシステム１１９の圧縮ファイルに含まれる或る時刻区間のセンサデータ群のアクセス頻度が高い場合、その時刻区間のセンサデータ群に対応した計測レコード群をＤＢ１１７に追加してもよい。この場合、データ制御部１１２は、配置管理テーブル１２０において、ＤＢ１１７に追加したセンサデータ群（計測レコード群）の配置場所を「ＤＢ」に更新する。

なお、所定のデータ単位（例えば、センサデータ群単位、計測レコード単位）で管理されるアクセス頻度は、配置管理テーブル１２０で管理されてもよいし、配置管理テーブル１２０とは別の管理テーブル等でデータ制御部１１２により管理されてもよい。

図１４は、受付部１２６が提供する残存条件指定ＧＵＩの一例を示す。

残存条件指定ＧＵＩ３０００は、ユーザインターフェイスの一例であり、受付部１２６により、ＤＢサーバ１２に接続されている表示コンソールに提供される。表示コンソールは、表示デバイス（図示せず）でもよいし、表示デバイスを有する外部の装置（例えば、表示デバイスを有するクライアント装置１１、又は、表示デバイスを有する管理計算機（図示せず））でもよい。ユーザは、残存条件指定ＧＵＩ３０００に、残存条件を入力できる。残存条件は、残存期間を含む。本実施例で言うユーザは、クライアント装置１１等で実行されるアプリケーション１０７のユーザでもよいし、ＤＢＭＳ１０９のユーザ（例えば管理者）でもよい。

残存条件指定ＧＵＩ３０００は、センサデータに関する複数の計測属性の各々について、選択するか否かを指定するための選択ツール（例えばチェックボックス）３００１と、属性名称３００２と、計測属性についての値の入力ツール３００３を有する。入力ツールは、図示のように、テキストの入力欄でもよいし、プルダウンメニューのようなボックスであってもよい。ユーザは、所望の計測属性に対応したチェックボックス３００１にチェックマークを記入し（つまり計測属性を選択し）、選択した計測属性についての値を入力ツール３００３に入力する。また、残存条件指定ＧＵＩ３０００は、残存期間の入力ツール３００５を有する。「残存期間」とは、ＤＢ１１７にセンサデータが残る期間であり、固定値としてのＤＢ保存期間と異なり、可変値である。ユーザは、所望の残存条件を満たすセンサデータの残存期間を入力ツール３００５に入力することができる。残存期間の入力は必須でなくてよい。残存期間が入力されなかった場合は、残存期間は、デフォルトの残存期間（例えば、ＤＢ保存期間（２年）と所定の期間の合計）になってよい。残存期間の入力は、ＤＢ保存期間との差分（例えば、プラス１年、マイナス３か月）の入力でもよい。つまり、残存期間は、ＤＢ保存期間との差分で定義されてもよい。

複数の計測属性の各々についてのＧＵＩ部品３００１、３００３及び３００５を使用して入力された情報、すなわち、１以上の属性／値セット（選択された計測属性とその計測属性についての値とのセット）と残存期間とが残存条件である。なお、残存条件は、１以上の属性／値セットと残存期間のうちの一方のみ（例えば残存期間のみ）であってもよい。

図１５は、残存条件管理テーブル１２８の構成例を示す。

残存条件管理テーブル１２８は、入力された残存条件毎に、残存期間４００１及び属性条件４００２を有する。残存期間４００１及び属性条件４００２は、受付部１２６により登録された情報である。

残存期間４００１は、図１４のＵＩ３００に入力された残存期間（又はユーザにより予め指定されたデフォルトの残存期間）である。属性条件４００２は、図１４のＵＩに入力された１以上の属性／値セットである。なお、図１４に示すように、計測属性の名称３００２として、メトリック名／センサ名が表示されるが、メトリック名／センサ名にメトリックＩＤ／センサＩＤがそれぞれ関連付けられていて、属性条件４００２には、メトリック名／センサ名に代えて又は加えてメトリックＩＤ／センサＩＤが含まれてよい。

また、図１５に示すように、残存期間としてＤＢ保存期間よりも短い期間をユーザは入力することができる。これにより、残存条件を満たすセンサデータに対応したレコードを、ＤＢ保存期間が経過するよりも早い段階でＤＢ１１７から削除することができる。

以上のように、残存条件に関連付けられる残存期間を指定できるので、ＤＢ１１７に残すレコードをよりきめ細かく指定できる。

図７は、インポート処理部１０３の処理例のフローチャートを示す。

インポート処理部１０３は、タイマーをリセットする（Ｓ３０１）。インポート処理部１０３は、タイマーをリセットしてからの経過時間が５分以上か否かを判定する（Ｓ３０２）。

経過時間が５分未満の場合（Ｓ３０２：ＮＯ）、インポート処理部１０３は、現時点でキャッシュ領域１０２に存在するセンサデータ群に関する計測属性値（計測属性についての値）を取得する（Ｓ３１０）。

インポート処理部１０３は、その取得したセンサデータの計測属性値をデータ制御部１１２へ渡す（Ｓ３１１）。例えば、インポート処理部１０３は、図６の配置管理テーブル１２０の管理レコード９１０ｆに示すように、時刻区間「００：１５：００．０００〜現時点」、センサＩＤ「Ｉｔｅｍ１」及びメトリックＩＤ「ｍｅｔ１」をデータ制御部１１２に渡し、データ制御部１１２が、時刻区間「００：１５：００．０００〜（Ｎｕｌｌ）」、センサＩＤ「Ｉｔｅｍ１」、メトリックＩＤ「ｍｅｔ１」、ファイル名（Ｎｕｌｌ）及び配置場所「キャッシュ領域」を管理レコード９１０ｆに登録する。データ制御部１１２は、センサデータ群の計測属性値の送付元がインポート処理部１０３であれば、そのセンサデータ群の配置場所がキャッシュ領域１０２であると判断できる。インポート処理部１０３が、配置場所として「キャッシュ領域」をデータ制御部１１２へ通知してもよい。

経過時間が５分以上の場合（Ｓ３０２：ＹＥＳ）、インポート処理部１０３は、キャッシュ領域１０２から、センサデータ群（５分間分のセンサデータ）を取得する（Ｓ３０３）。インポート処理部１０３は、そのセンサデータ群を表すＣＳＶファイルを生成する（Ｓ３０４）。インポート処理部１０３は、その生成したＣＳＶファイルから圧縮ファイル（例えば、ｇｚｉｐファイル）を生成する（Ｓ３０５）。インポート処理部１０３は、ロード機能部１０４に、生成したＣＳＶファイル及び圧縮ファイルを渡す（Ｓ３０６）。インポート処理部１０３は、キャッシュ領域１０２から、Ｓ３０３で取得したセンサデータ群を削除する。

以上の処理により、時刻の経過と共にキャッシュ領域１０２に蓄積されるセンサデータが、所定の周期で、センサデータ群単位で、ロード機能部１０４に送られ、且つ、キャッシュ領域１０２から削除される。

図８は、ロード機能部１０４の処理例のフローチャートを示す。

ロード機能部１０４は、インポート処理部１０３からのファイルがＣＳＶファイルと圧縮ファイルの何れであるかを判定する（Ｓ４０２）。

ファイルがＣＳＶファイルの場合（Ｓ４０２：ＣＳＶファイル）、ロード機能部１０４は、ＣＳＶファイルに基づきセンサデータ群に対応する計測レコード群をＤＢ１１７へ格納する（Ｓ４０３）。ロード機能部１０４は、ＤＢ１１７に格納した計測レコード群（センサデータ群）の計測属性値を取得する（Ｓ４０４）。ロード機能部１０４は、データ制御部１１２に、その取得した計測属性値、配置場所「ＤＢ」、及び、対応する圧縮ファイルのファイル名をデータ制御部１１２に渡す（Ｓ４０５）。データ制御部１１２により、ＤＢ１１７に格納されたセンサデータ群についての管理レコードが配置管理テーブル１２０に追加される（例えば図６の管理レコード９１０ｅ）。なお、データ制御部１１２は、例えば圧縮ファイルのファイル名と同じファイル名が管理テーブルに登録されていて、配置場所が「ファイルシステム」であれば、その配置場所を「ＤＢ」に更新する。

ファイルが圧縮ファイルの場合（Ｓ４０２：圧縮ファイル）、ロード機能部１０４は、圧縮ファイルをファイルシステム１１９へ格納する（Ｓ４０６）。ロード機能部１０４は、その圧縮ファイルに含まれるセンサデータ群の計測属性値を取得する（Ｓ４０７）。ロード機能部１０４は、データ制御部１１２に、その取得した計測属性値、配置場所「ファイルシステム」、及び、格納した圧縮ファイルのファイル名をデータ制御部１１２に渡す（Ｓ４０８）。データ制御部１１２により、ファイルシステム１１９に格納されたセンサデータ群についての管理レコードが配置管理テーブル１２０に追加される。しかし、ここで、例えば圧縮ファイルのファイル名と同じファイル名が管理テーブルに登録されていれば、配置場所が「ＤＢ」であれば、管理テーブルの追加はスキップされる。

以上の処理により、センサデータ群が、ＤＢ１１７及びファイルシステム１１９に格納される。なお、図８において、例えばＳ４０７及びＳ４０８は無くてもよい。Ｓ４０４及びＳ４０５により、キャッシュ領域１０２からのセンサデータ群に対応し配置管理テーブル１２０に追加される管理レコードと計測属性値が重複するからである。

図９は、ＳＱＬパーサ１１１の処理例のフローチャートを示す。

ＳＱＬパーサ１１１は、アプリケーション１０７からＳＱＬ Ｉ／Ｆ１０８を通じてＳＱＬクエリを受信し（Ｓ７０１）、そのクエリに、外部へのアクセスを必要とする表関数が含まれているか否かを判定する（Ｓ７０２）。表関数が含まれていない場合（Ｓ７０１：ＮＯ）、ＳＱＬパーサ１１１は、そのＳＱＬクエリをＤＢエンジン１１０に渡し（Ｓ７０３）、表関数が含まれている場合（Ｓ７０１：ＹＥＳ）、そのＳＱＬクエリをデータ制御部１１２に渡す（Ｓ７０４）。ＳＱＬパーサ１１１は、ＳＱＬクエリの実行結果をＤＢエンジン１１０又はデータ制御部１１２から受けて、実行結果をアプリケーション１０７に返す（Ｓ７０５）。

以上の処理により、表関数を含まないＳＱＬクエリはＤＢエンジン１１０で処理され、表関数を含むＳＱＬクエリはデータ制御部１１２で処理される。

なお、Ｓ７０２では、ＳＱＬクエリが表関数を含むか否かに代えて又は加えて、配置管理テーブル１２０を基に、クエリ条件（ＳＱＬクエリで指定されている条件）を満たすデータの配置場所が「ＤＢ」であるか否かが判断されてもよい。配置場所が「ＤＢ」の場合、Ｓ７０３が行われ、配置場所が「ファイルシステム」又は「キャッシュ領域」の場合、Ｓ７０４が行われる。

また、Ｓ７０２無しに、Ｓ７０３が行われてよい。すなわち、ＳＱＬクエリが必ずＤＢエンジン１１０に渡されてもよい。ＤＢエンジン１１０からエラーが戻って来た場合（例えば、ＳＱＬクエリの実行結果がエラーを表す場合）、Ｓ７０４が行われてよい。

図１０は、ＤＢエンジン１１０の処理例のフローチャートを示す。

ＤＢエンジン１１０は、ＳＱＬパーサ１１１又はデータ制御部１１２から、ＳＱＬクエリを受信し（Ｓ１１０１）、ＤＢ１１７に対して、受信したＳＱＬクエリを実行する（Ｓ１１０２）。例えば、クエリが検索クエリの場合、ＤＢエンジン１１０は、ＤＢ１１７から、そのクエリで指定されている検索条件を満たすデータを抽出する。ＤＢエンジン１１０は、ＳＱＬクエリの実行結果（例えば抽出されたデータを含む）をＤＢエンジン１１０の呼び出し元（本実施例ではＳＱＬパーサ１１１又はデータ制御部１１２）に返す（Ｓ１１０３）。

以上の処理により、ＤＢエンジン１１０は、ＳＱＬクエリの実行結果（検索結果など）を、ＤＢエンジン１１０の呼び出し元に返すことができる。

図１１は、データ制御部１１２の処理例のフローチャートを示す。

データ制御部１１２が、情報ユニットを受ける（Ｓ８０１）。情報ユニットは、インポート処理部１０３又はロード機能部１０４からの計測属性値等であることもあれば、ＳＱＬパーサ１１１からのクエリであることもある。

情報ユニットがクエリではない場合（計測属性値等の場合）（Ｓ８０２：ＮＯ）、データ制御部１１２は、受けた計測属性等を配置管理テーブル１２０の管理レコードに格納する（Ｓ８６０）。ここで、データ制御部１１２は、配置管理テーブル１２０に、受信した計測属性値等と重複する管理レコードが存在し、受信した計測属性値等における配置場所が「ＤＢ」であり、且つ、その重複する管理レコードにおける配置場所９０６が「ファイルシステム」の場合、その配置場所９０６を「ファイルシステム」から「ＤＢ」に更新してよい。

以上の処理により、データ制御部１１２は、インポート処理部１０３又はロード機能部１０４からの計測属性値等を配置管理テーブル１２０に格納する。

情報ユニットがクエリの場合（Ｓ８０２：ＮＯ）について説明する。データ制御部１１２は、クエリが検索クエリであるか否かを判定する（Ｓ８０３）。

クエリが検索クエリ以外の場合（例えば、レコードの更新又は削除等の場合）（Ｓ８０３：ＮＯ）、データ制御部１１２は、そのクエリに基づき処理を実行する（Ｓ８６０）。例えば、クエリが、そのクエリで指定された条件を満たすデータを含んだレコードをＤＢ１１７から削除するものである場合、データ制御部１１２は、そのレコードについて、配置場所９０６を「ＤＢ」から「ファイルシステム」に変更し、そのレコードをＤＢ１１７から削除する。また、例えば、クエリがＤＢ１１７に新たな計測属性を追加するものであった場合、データ制御部１１２は、ＤＢ１１７にその新たな計測属性に係るカラムを追加し、配置管理テーブル１２０にも、その新たな計測属性に係るカラムを追加する。

クエリが検索クエリの場合（Ｓ８０３：ＹＥＳ）、データ制御部１１２は、配置管理テーブル１２０から、検索条件の１つとして指定されている時刻を含んだ時刻区間に対応する管理レコードを特定し、その管理レコードにおける配置場所９０６を参照する（Ｓ８０４）。そして、データ制御部１１２は、その配置場所９０６が「ＤＢ」であるか否かを判定する（Ｓ８０５）。

配置場所９０６が「ＤＢ」である場合（Ｓ８０５：ＹＥＳ）、データ制御部１１２は、ＤＢエンジン１１０にＳＱＬクエリを渡し、実行結果をＤＢエンジンから受けて、その実行結果をＳＱＬパーサ１１１に返す（Ｓ８２０）。

配置場所９０６が「ＤＢ」でない場合（Ｓ８０５：ＮＯ）、データ制御部１１２は、Ｓ８０６を行う。例えば、配置場所９０６が「ファイルシステム」の場合、データ制御部１１２は、検索条件を満たすセンサデータを含んだセンサデータ群に対応する管理レコードのファイル名９０５から、圧縮ファイルのファイル名を取得し、取得したファイル名を外部データアクセス部１１４に渡す。また、例えば、配置場所９０６が「キャッシュ領域」の場合、データ制御部１１２は、検索条件を外部データアクセス部１１４に渡す。データ制御部１１２は、実行結果（例えば、渡したファイル名又は検索条件に対応するセンサデータを含む）を、外部データアクセス部１１４から受け、その実行結果を、ＳＱＬパーサ１１１に返す。データ制御部１１２は、実行結果中のセンサデータ（検索結果としてのセンサデータ）をＤＢ１１７へ登録する必要があるか否かを判定する（Ｓ８０７）。例えば、そのセンサデータを含んだファイルがファイルシステム１１９から所定頻度以上取得された場合、データ制御部１１２は、そのファイルが表すセンサデータ群のうちの少なくとも検索条件を満たすセンサデータをＤＢ１１７へ登録する必要があると判定してもよい。

Ｓ８０７の判定結果が肯定の場合（Ｓ８０７：ＹＥＳ）、データ制御部１１２は、一時表内の少なくとも検索条件を満たすセンサデータをＤＢ１１７に格納する（Ｓ８０８）。そして、データ制御部１１２は、ＤＢ１１７に登録したセンサデータについて、配置場所９０６を、「ファイルシステム」から「ＤＢ」に変更する（Ｓ８０９）。

以上の処理により、データ制御部１１２が、データの配置場所に応じて外部データアクセス部１１４及びＤＢ１１０を使い分けることができ、このため、ＳＱＬパーサ１１１及びＤＢエンジン１１０が、データの配置場所を意識しなくてよい。

図１２は、外部データアクセス部１１４の処理例のフローチャートを示す。

外部データアクセス部１１４は、取得対象の情報を受信する（Ｓ１００１）。取得対象の情報は、圧縮ファイルのファイル名、又は、センサデータの検索条件である。外部データアクセス部１１４は、ファイル名に対応した圧縮ファイルをファイルシステム１１９から取得する、又は、検索条件を満たすセンサデータをキャッシュ領域１０２から取得する（Ｓ１００２）。外部データアクセス部１１４は、その取得した圧縮ファイルが有するセンサデータ群、又は、取得したセンサデータを、一時表に格納する（Ｓ１００３）。一時表は、予めデータ制御部１１２等により生成されてもよいし、Ｓ１００３において外部データアクセス部１１４により生成されてもよい。外部データアクセス部１１４は、データを一時表に格納したことを、外部データアクセス部１１４の呼び出し元に返すことができる。

以上の処理により、ファイルシステム１１９又はキャッシュ領域１０２からファイル又はセンサデータが取得し、そのファイル内のセンサデータ又は取得されたセンサデータを一時表に格納することができる。一時表内のセンサデータは、図１１のＳ８０８でＤＢ１１７に格納される。

図１６は、データ制御部１１２の別の処理例のフローチャートを示す。

この処理例は、ＤＢ１１７からのレコードの削除制御であり、例えば、個々の計測レコードについて繰り返し（例えば定期的に）行われる。以下、１つの計測レコードを例に取り、図１６に示す処理を説明する。

データ制御部１１２は、計測レコードのレコード時刻からの経過期間がＤＢ保存期間に達しているか否かを判定する（Ｓ１６０１）。

Ｓ１６０１の判定結果が肯定の場合（Ｓ１６０１：ＹＥＳ）、データ制御部１１２は、計測レコードが所定条件を満たすか否かを判定する（Ｓ１６０２）。「所定条件」とは、経過期間がＤＢ保存期間に達していてもＤＢ１１７に計測レコードが残るための条件であり、例えば、残存条件、又は、アクセス頻度が所定閾値以上、である。

Ｓ１６０２の判定結果が否定の場合（Ｓ１６０２：ＮＯ）、ＤＢ保存期間の満了に伴い計測レコードが削除される。すなわち、データ制御部１１２は、計測レコードをＤＢ１１７から削除し、その計測レコードについて、配置場所９０６を「ＤＢ」から「ファイルシステム」に変更する（Ｓ１６０５）。

Ｓ１６０２の判定結果が肯定の場合（Ｓ１６０２：ＹＥＳ）、データ制御部１１２は、計測レコードのレコード時刻からの経過期間が残存期間に達しているか否かを判定する（Ｓ１６０３）。ここでいう残存期間は、残存条件が示す残存期間（例えば、計測レコードが満たしている属性条件に対応した残存期間）である。

Ｓ１６０３の判定結果が否定の場合（Ｓ１６０３：ＮＯ）、データ制御部１１２は、計測レコードをＤＢ１１７に残す（つまり、計測レコードをＤＢ１１７から削除しない）。

Ｓ１６０３の判定結果が肯定の場合（Ｓ１６０３：ＹＥＳ）、残存期間の満了に伴い、計測レコードが削除される。すなわち、Ｓ１６０５が行われる。

Ｓ１６０１の判定結果が否定の場合（Ｓ１６０１：ＮＯ）、データ制御部１１２は、計測レコードがいずれかの残存条件を満たしており、且つ、その残存条件に対応した残存期間に、経過期間が達しているか否かを判定する（Ｓ１６０４）。ＤＢ保存期間よりも短い期間が残存期間として指定されていることがあり得るためである。

Ｓ１６０４の判定結果が肯定の場合（Ｓ１６０４：ＹＥＳ）、残存期間の満了に伴い、計測レコードが削除される。すなわち、Ｓ１６０５が行われる。

Ｓ１６０４の判定結果が否定の場合（Ｓ１６０４：ＮＯ）、ＤＢ保存期間（及び削除期間）が満了していないため、データ制御部１１２は、計測レコードをＤＢ１１７に残す（つまり、計測レコードをＤＢ１１７から削除しない）。

以上の処理により、計測レコードを削除するか残すかが制御される。

図１４は、センサデータ監視ＧＵＩの一例を示す。

センサデータ監視ＧＵＩ２０００は、センサデータ監視アプリケーションにより表示されるＧＵＩであってセンサデータの監視（例えば分析等）のためのＧＵＩである。センサデータ監視アプリケーションは、上述のアプリケーション１０７の一例である。ＧＵＩ２０００は、第１選択領域２００１と、第２選択領域２００２と、計測値表示領域２００３とを有する。

第１選択領域２００１には、例えば、計測属性のリストが表示される。第２選択領域２００２には、第１選択領域２００１から選択された計測属性に適合するセンサデータ群が表示される。計測値表示領域２００３には、第２選択領域２００２から選択されたセンサデータ群に基づく計測値が表示される。例えば、図１４に示すように、第１選択領域２００１からセンサＩＤ「Ｉｔｅｍ２」が選択されると、第２選択領域２００２に、センサＩＤ「Ｉｔｅｍ２」に対応するセンサデータ群が表示される。そして、第２選択領域２００２から、メトリックＩＤ「１」に対応するセンサデータが選択されると、計測値表示領域２００３に、センサＩＤ「Ｉｔｅｍ２」及びメトリックＩＤ「１」に対応する計測値が時系列で表示（例えば折れ線グラフで表示）される。このような操作において、適宜、センサデータ監視アプリケーションが、検索要求等の要求を送信し、その要求が、ＳＱＬクエリとなってＳＱＬパーサ１１１に入力される。

上述した実施例は、本発明の説明のための例示であり、本発明の範囲をその実施例にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施することができる。

例えば、時系列データは、センサデータに限らず、センサデータ以外の種類の時系列データを採用することができる。また、時系列データに代えて、他種のデータについても、本発明が適用されてもよい。

また、例えば、残存期間は、ゼロを示してもよい。つまり、残存条件は、ＤＢ１１７に保存しないレコードの残存条件にもなり得る。この場合、制御部（例えばデータ制御部１１２）は、残存条件に基づいて、レコード（例えば、残存期間がゼロの属性条件に該当するレコード）をＤＢ１１７から削除する、又は、レコード（例えば、残存期間がゼロの属性条件に該当するレコード）をＤＢ１１７に格納しない。後者の場合、例えば、制御部（例えばデータ制御部１１２）は、ＣＳＶファイル１０５のうち、残存期間がゼロの属性条件に該当する計測エントリについては、その計測エントリ中のデータを含んだ計測レコードをＤＢ１１７に格納しない（例えばそのようなレコードを生成しない）。

また、例えば、残存条件（例えば残存期間）は、キャッシュ領域にデータが保存される期間を含んでよい。つまり、受付部１２６は、残存条件（例えば残存期間）として、ＤＢ１１７についての残存条件に加えて、キャッシュ領域１０２についての残存条件を受け付け、ＤＢ１１７についての残存条件に加えて、キャッシュ領域１０２についての残存条件も、残存条件管理テーブル１２８に登録してよい。制御部（例えばデータ制御部１１２）は、キャッシュ領域１０２についての残存条件（残存条件管理テーブル１２８に登録されている残存条件）に基づいて、キャッシュ領域１０２へ保存されたデータを計測レコードとしてＤＢ１１７に格納し、ＤＢ１１７に格納されたデータをキャッシュ領域１０２から削除してよい。つまり、この変形例によれば、５分毎にセンサデータ群が生成されキャッシュ領域１０２から削除されることに代えて又は加えて、残存条件に基づき５分単位とは異なる時点にセンサデータをＤＢ１１７に格納しキャッシュ領域１０２から削除することができる。なお、制御部（例えばデータ制御部１１２）は、クエリ（アプリケーション１０７からのアクセス要求の一例）を受け付けたとき、クエリ条件を満たすセンサデータ（アクセス対象レコードに対応するデータの一例）がキャッシュ領域１０２にある場合、キャッシュ領域１０２に格納されているアクセス対象データ（クエリ条件を満たすセンサデータ）をアクセスするようアプリケーション１０７へ指示する、又は、クエリ条件を満たすセンサデータをキャッシュ領域１０２から取得してアプリケーション１０７に提供してもよい。前者の場合、制御部は、例えば、アクセス対象データの位置のアドレスをアプリケーション１０７に提供し、アプリケーション１０７が、そのアドレスが示す位置にあるアクセス対象データ（つまりキャッシュ領域１０２内のデータ）をＤＢＭＳ１０９非経由（又は経由）で取得してよい。

また、例えば、ＤＢＭＳ１０９が、格納部（例えばインポート処理部１０３及びロード機能部１０４）を有してもよい。

１：計算機システム １２： ＤＢサーバ １０９：ＤＢＭＳ １１７：ＤＢ １１９：ファイルシステム １２０：配置管理テーブル １２８：残存条件管理テーブル

Claims (14)

1. 時刻を示す情報とレコードを対応づけて格納するデータベースから、対応付けられた情報が示す時刻から所定期間が経過したレコードを削除するデータベース管理システムにおいて、
   前記所定期間に関わらずにレコードを前記データベースに残す期間を示す残存条件を受け付ける受付部と、
   受付部が受け付けた残存条件に基づいて、前記データベースのレコードを、前記所定期間が経過した後も前記データベースに残すよう制御する制御部と
   を備えることを特徴とするデータベース管理システム。
2. 請求項１に記載のデータベース管理システムにおいて、
   前記制御部は、実行されたアプリケーションプログラムがアクセスするレコードであるアクセス対象レコードが前記データベースになかったとき、前記データベースに格納されるレコードのうち少なくとも削除されるレコードの内容を含んだファイルが格納されるファイルシステムから、前記アクセス対象レコードに対応するファイルを特定し、前記特定したファイルを基に前記アクセス対象レコードを前記データベースに追加する
   ことを特徴とするデータベース管理システム。
3. 請求項２に記載のデータベース管理システムにおいて、
   前記受付部は、前記アプリケーションプログラムがアクセスしたレコードの残存条件を受け付け、
   前記制御部は、前記受け付けた残存条件で指定された期間に基づいて、前記ファイルシステムから前記データベースへ追加されたレコードの削除を行う
   ことを特徴とするデータベース管理システム。
4. 請求項２に記載のデータベース管理システムにおいて、
   前記受付部は、前記データベースに保存しないレコードの残存条件を受け付け、
   前記制御部は、前記受け付けた残存条件に基づいて、前記レコードを前記データベースから削除する又は前記レコードを前記データベースに格納しない
   ことを特徴とするデータベース管理システム。
5. 請求項３に記載のデータベース管理システムにおいて、
   前記残存条件で指定された期間は、受け取ったデータが保存されるキャッシュ領域に保存される期間も含み、
   前記制御部は、前記残存条件で指定された期間に基づいて、受け取ったデータが保存されるキャッシュ領域へ保存されたデータを、前記データベースのレコードとして前記データベースに保存し、前記データベースに保存されたデータを前記キャッシュ領域から削除する
   ことを特徴とするデータベース管理システム。
6. 請求項５に記載のデータベース管理システムにおいて、
   前記制御部は、前記アプリケーションプログラムから前記アクセス対象レコードのアクセス要求を受け付けたとき、前記アクセス対象レコードに対応するデータが前記キャッシュ領域にある場合、前記キャッシュ領域に格納されたデータをアクセスするよう前記アプリケーションプログラムへ指示する、又は、前記アクセス対象レコードに対応するデータを前記キャッシュ領域から取得して前記アプリケーションプログラムに提供する
   ことを特徴とするデータベース管理システム。
7. 請求項１に記載のデータベース管理システムにおいて、
   前記データベースに格納される複数のレコードは、複数の時系列データに対応した複数のレコードであり、
   前記制御部は、クエリで指定された条件であるクエリ条件を満たすデータが前記データベースに無ければ、２以上の時系列データに対応した１以上のファイルを記憶するファイルシステムから取得されたファイルであり前記クエリ条件を満たすデータを含んだファイルである対象ファイルに基づく表から、前記クエリ条件を満たすデータを取得し、
   前記残存条件は、時系列データに関する複数の属性であり少なくとも時刻を含んだ複数の属性のうちの１以上の属性と前記１以上の属性の各々についての値である、
   ことを特徴とするデータベース管理システム。
8. 請求項７に記載のデータベース管理システムにおいて、
   前記制御部は、配置管理情報と前記残存条件に基づいて、レコードの時刻から前記所定期間を経過したそのレコードを特定し、特定したレコードを削除するか残すかを制御し、
   前記配置管理情報は、時系列データ群の時刻区間と、その時系列データ群に関する１以上の属性の各々についての値と、その時系列データ群が配置されている配置場所とを、時系列データ群毎に保持する情報である
   ことを特徴とするデータベース管理システム。
9. 請求項８に記載のデータベース管理システムにおいて、
   前記制御部は、
   前記対象ファイルを、前記クエリ条件を満たすデータを含んだ１以上の時系列データの第１ファイルと、その１以上の時系列データ以外の時系列データのファイルである１以上の第２ファイルとに分割し、
   前記対象ファイルが表す２以上の時系列データのうちの、前記第１ファイルが表す前記１以上の時系列データ、に対応した１以上のレコードを前記データベースに追加し、
   前記配置管理情報に、前記第１ファイルとしての時系列データ群の配置場所が前記データベースであることを登録する
   ことを特徴とするデータベース管理システム。
10. 請求項８に記載のデータベース管理システムにおいて、
    １以上の時系列データソースからの時系列データがキャッシュ領域に蓄積され前記キャッシュ領域に蓄積された２以上の時系列データに対応した２以上のレコードが格納部により前記データベースに格納されるようになっており、
    前記制御部は、
    前記キャッシュ領域に蓄積されているが前記データベースにも前記ファイルシステムにも格納されていない２以上の時系列データの集合である時系列データ群について、配置場所が前記キャッシュ領域であることを前記格納部から受け、
    前記配置管理情報に、その時系列データ群の配置場所が前記キャッシュ領域であることを登録する
    ことを特徴とするデータベース管理システム。
11. 請求項１に記載のデータベース管理システムにおいて、
    前記制御部は、所定頻度以上の頻度でアクセスされたレコードについては、そのレコードに対応した時刻から前記所定期間を経過しても、前記データベースに残す
    ことを特徴とするデータベース管理システム。
12. 請求項１に記載のデータベース管理システムにおいて、
    前記受付部は、前記残存条件を、ユーザインターフェイスを通じて受け付ける
    ことを特徴とするデータベース管理システム。
13. 時刻を示す情報とレコードを対応づけて格納するデータベースから、対応付けられた情報が示す時刻から所定期間が経過したレコードを削除する計算機であって、
    前記データベースを有するストレージ装置に接続されるインターフェイスデバイスと、
    前記インターフェイスデバイスに接続されたプロセッサと
    を備え、
    前記プロセッサは、
    前記所定期間に関わらずにレコードを前記データベースに残す期間を示す残存条件を受け付け、
    前記残存条件に基づいて、前記データベースのレコードを、前記所定期間が経過した後も前記データベースに残すよう制御する
    ことを特徴とする計算機。
14. 時刻を示す情報とレコードを対応づけて格納するデータベースから、対応付けられた情報が示す時刻から所定期間が経過したレコードを削除するデータベース管理方法において、
    前記所定期間に関わらずにレコードを前記データベースに残す期間を示す残存条件を受け付け、
    前記残存条件に基づいて、前記データベースのレコードを、前記所定期間が経過した後も前記データベースに残すよう制御する
    ことを特徴とするデータベース管理方法。
    
    

Images