(57)【特許請求の範囲】
【請求項１】
レコードを最小単位として連続して入力されるデータを、論理ブロックを単位として逐次蓄積する二次記憶装置と、
前記レコードの特定の値をキー値としてスパースインデックス（ｓｐａｒｓｅ  ｉｎｄｅｘ）による索引付けを行い、一の論理ブロックが受け持つキー値の範囲に含まれる前記キー値を持つ前記レコードが他の論理ブロックにある場合には、前記一の論理ブロックから前記他の論理ブロックへのオフセット数をビット列で表現して圧縮したオフセットデータをオフセットファイルとして前記二次記憶装置に記録させるシステム制御手段と、
を備え、
前記システム制御手段は、
前記オフセットデータを、コード長記憶部、圧縮回数記憶部、圧縮位置及び圧縮ビット数記憶部からなるヘッダ部、並びにコード部で構成し、
前記コード部において、前記オフセット数と等しいビット位置のビットを「１」とし、
前記コード部のビット列が予め設定したしきい値以上同一のビットが連続する連続ビット部を含む場合に、前記連続ビット部のビット数を数え上げ、前記連続ビット部の先頭の位置及び前記連続ビット部のビット数をそれぞれ前記圧縮位置及び圧縮ビット数記憶部に記録し、
前記連続ビット部の先頭のビットを残して前記連続ビット部の他のビットを削除し、
ビット削除後の前記コード部で利用されているビット数を前記コード長記憶部に記録し、
前記圧縮位置及び圧縮ビット数記憶部の個数を前記圧縮回数記憶部に記録する
オフセット圧縮部を有することを特徴とするデータ蓄積装置。
【請求項２】
レコードを最小単位として連続して入力されるデータを、論理ブロックを単位として二次記憶装置に逐次蓄積する際に、
前記レコードの特定の値をキー値としてスパースインデックス（ｓｐａｒｓｅ  ｉｎｄｅｘ）による索引付けを行い、一の論理ブロックが受け持つキー値の範囲に含まれる前記キー値を持つ前記レコードが他の論理ブロックにある場合には、前記一の論理ブロックから前記他の論理ブロックへのオフセット数をビット列で表現して圧縮したオフセットデータをオフセットファイルとして前記二次記憶装置に記録させるシステム制御手順を行い、
前記システム制御手順では、
前記オフセットデータを、コード長記憶部、圧縮回数記憶部、圧縮位置及び圧縮ビット数記憶部からなるヘッダ部、並びにコード部で構成し、
前記コード部において、前記オフセット数と等しいビット位置のビットを「１」とし、
前記コード部のビット列が予め設定したしきい値以上同一のビットが連続する連続ビット部を含む場合に、前記連続ビット部のビット数を数え上げ、前記連続ビット部の先頭の位置及び前記連続ビット部のビット数をそれぞれ前記圧縮位置及び圧縮ビット数記憶部に記録し、
前記連続ビット部の先頭のビットを残して前記連続ビット部の他のビットを削除し、
ビット削除後の前記コード部で利用されているビット数を前記コード長記憶部に記録し、
前記圧縮位置及び圧縮ビット数記憶部の個数を前記圧縮回数記憶部に記録する
ことを特徴とするデータ蓄積方法。
【請求項３】
コンピュータに、請求項２に記載のデータ蓄積方法の前記システム制御手順を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、二次記憶装置へデータを蓄積するデータ蓄積装置、データ蓄積方法、及びそのプログラムに関するものである。
【背景技術】
【０００２】
二次記憶装置へのデータ蓄積方法では、レコードといういくつかの情報を１つにまとめたデータを、データを格納する際の最小単位として扱っている。また、二次記憶装置への最小アクセス単位として物理ブロックがあり、これをシステム上で仮想的に扱えるようにしたものを論理ブロックと呼ぶ。ファイルは複数の論理ブロックから成り立ち、論理ブロックは複数のレコードを含むことが多い。
【０００３】
また、特定のレコードを効率的に検索するために、索引が用いられている。索引はレコードが持つ任意の属性の値について作成することができる。このときこの索引を作成する任意の属性の値のことをキー値と呼ぶ。この索引付け方法のうち、範囲検索を行える方法として、デンスインデックス（ｄｅｎｓｅ  ｉｎｄｅｘ）とスパースインデックス（ｓｐａｒｓｅ  ｉｎｄｅｘ）がある（例えば、非特許文献１を参照。）。ｄｅｎｓｅ  ｉｎｄｅｘはデータの入力順に左右されず、入力された全てのレコードについて索引を作成する。これに対しｓｐａｒｓｅ  ｉｎｄｅｘではデータの入力順を利用して、入力されたレコードのうち一部のレコードについてのみ索引を作成する。索引が作成されないレコードに関しては、入力順がキー値についてソートされているという前提の元で探索を行う。このため、ｓｐａｒｓｅ  ｉｎｄｅｘはデータの入力順がキー値についてソートされているときに限り使うことのできる方法である。
【０００４】
一方、センサネットワークを通じて集められる大量の時系列センサデータなどを時刻をキー値として範囲検索可能な形でリアルタイムに二次記憶装置へ蓄積しようとする場合、データ書き込みの高速性が求められる。従来の索引付け方法のうちｄｅｎｓｅ  ｉｎｄｅｘを用いる場合、入力される各レコードに索引を作成する必要があるため、データ書き込み時のコストがｓｐａｒｓｅ  ｉｎｄｅｘに比べて高く、データ書き込み速度がデータの発生に追いつかない恐れがある。一方で、ｓｐａｒｓｅ  ｉｎｄｅｘを用いるためには入力されるデータがキー値（この場合、時刻）についてソートされた状態で入力される必要がある。しかし、センサネットワークを通じて集められる大量の時系列データはネットワークの遅延やセンサ等データソース側の接続断などによって、時刻データの入力順が時刻のとおりに一定ではなく、順序逆転することが考えられる。このため、時刻をキー値とすると、キー値によっておおよそ整列しているが、部分的に遅延による順序逆転が起きているデータとなるためｓｐａｒｓｅ  ｉｎｄｅｘを用いることができない。
【０００５】
この問題に対して、ｓｐａｒｓｅ  ｉｎｄｅｘ  に、新たなオフセットデータというビットマップで順序逆転したデータの格納位置を表すデータを加え、データの順序逆転に対応する方法が提案されている（例えば、非特許文献２参照。）。本方法では、ビットマップを用い、オフセット数に対応したビット番号のビットを１にすることで、オフセット数を表現することで、遅延データの位置を指し示し、高速な索引付けと順序逆転データへの対応を両立している。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】Ａｂｒａｈａｍ  Ｓｉｌｂｅｒｓｃｈａｔｚ，  Ｈｅｎｒｙ  Ｆ．Ｋｏｒｔｈ，  Ｓ．Ｓｕｄａｒｓｈａｎ，“Ｄａｔａｂａｓｅ  Ｓｙｓｔｅｍ  Ｃｏｎｃｅｐｔｓ  Ｆｉｆｔｈ  Ｅｄｉｔｉｏｎ”，  ｐｐ．４８３−４８５，  ＭｃＧｒａｗ−Ｈｉｌｌ（２００６）．
【非特許文献２】Ｔ．Ｙａｍａｚａｋｉ，  Ｔ．Ｉｎｏｕｅ，  Ｈ．Ｓａｔｏ，  Ｎ．Ｔａｋａｈａｓｈｉ，  Ｊ．Ｔａｋａｇｉ，  Ｍ．Ｍｉｎａｍｉ，“Ｅｆｆｉｃｉｅｎｔｌｙ  ｉｎｄｅｘｉｎｇ  ｗｉｔｈ  ｏｆｆｓｅｔ  ｂｉｔｍａｐｓ  ｆｏｒ  ｈｕｇｅ  ｓｅｔｓ  ｏｆ  ｓｌｉｇｈｔｌｙ  ｄｉｓｏｒｄｅｒｅｄ  ｓｅｎｓｏｒ  ｄａｔａ”，  ＡＰＳＩＴＴ２０１０，  ２０１０．
【非特許文献３】Ｈ．Ｗｉｌｌｉａｍｓ  ａｎｄ  Ｊ．Ｚｏｂｅｌ，“Ｃｏｍｐｒｅｓｓｉｎｇ  ｉｎｔｅｇｅｒｓ  ｆｏｒ  ｆａｓｔ  ｆｉｌｅ  ａｃｃｅｓｓ”，  Ｃｏｍｐｕｔｅｒ  Ｊｏｕｒｎａｌ，  ４２（３）：１９３−２０１，１９９９．
【非特許文献４】Ｖｏ  Ｎｇｏｃ  Ａｎｈ，  Ａｌｉｓｔａｉｒ  Ｍｏｆｆａｔ：“Ｉｎｖｅｒｔｅｄ  Ｉｎｄｅｘ  Ｃｏｍｐｒｅｓｓｉｏｎ  ｕｓｉｎｇ  Ｗｏｒｄ−Ａｌｉｇｎｅｄ  Ｂｉｎａｒｙ  Ｃｏｄｅｓ”，  Ｉｎｆｏｒｍａｔｉｏｎ  Ｒｅｔｒｉｅｖａｌ，  ８（１）：１５１−１６６，２００５．
【発明の概要】
【発明が解決しようとする課題】
【０００７】
従来のデータの順序逆転に高速に対応する方法では、ビットマップを用い、オフセット数に対応したビット番号のビットを１にすることで、オフセット数を表現する方法をとっている。しかし、この場合、連続して発生する小さな遅延を効率的に表現することは可能だが、センサ等データソース側の接続断などにより発生する突発的な大きな遅延に対しては、そのオフセット数と同じ数のビット数という多くのビット数が必要となり、空間効率が悪いという課題があった。
【０００８】
そこで、前記課題を解決するために、本発明は、データを二次記憶装置へ蓄積する際に、キー値についてデータの順序がある程度逆転して入力されたとしても逐次書き込みファイルに近い速度を維持することが可能、キー値による完全一致検索が可能、範囲検索による効率的なデータの読み込みが可能、且つ突発的な大きな遅延によりデータ順序が大きく逆転したとしても、これを空間効率良く表現可能なデータ構造を実現できるデータ蓄積装置、データ蓄積方法、及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
上記課題の解決のため、本発明は、レコードの特定の値をキー値としてｓｐａｒｓｅ  ｉｎｄｅｘによる索引付けを行い、一の論理ブロックが受け持つキー値の範囲に含まれるキー値のレコードが他の論理ブロックにある場合には、一の論理ブロックから別の論理ブロックへのオフセット数をビット列で表現して圧縮したオフセットデータをオフセットファイルとして二次記憶装置に記録させることとした。
【００１０】
具体的には、本発明に係るデータ蓄積装置は、レコードを最小単位として連続して入力されるデータを、論理ブロックを単位として逐次蓄積する二次記憶装置と、前記レコードの特定の値をキー値としてスパースインデックス（ｓｐａｒｓｅ  ｉｎｄｅｘ）による索引付けを行い、一の論理ブロックが受け持つキー値の範囲に含まれる前記キー値を持つ前記レコードが他の論理ブロックにある場合には、前記一の論理ブロックから前記他の論理ブロックへのオフセット数をビット列で表現して圧縮したオフセットデータをオフセットファイルとして前記二次記憶装置に記録させるシステム制御手段と、を備える。
【００１１】
具体的には、本発明に係るデータ蓄積方法は、レコードを最小単位として連続して入力されるデータを、論理ブロックを単位として二次記憶装置に逐次蓄積する際に、前記レコードの特定の値をキー値としてスパースインデックス（ｓｐａｒｓｅ  ｉｎｄｅｘ）による索引付けを行い、一の論理ブロックが受け持つキー値の範囲に含まれる前記キー値を持つ前記レコードが他の論理ブロックにある場合には、前記一の論理ブロックから前記他の論理ブロックへのオフセット数をビット列で表現して圧縮したオフセットデータをオフセットファイルとして前記二次記憶装置に記録させるシステム制御手順を行う。
【００１２】
本発明に係るデータ蓄積装置及びデータ蓄積方法は、ｓｐａｒｓｅ  ｉｎｄｅｘとオフセットデータを組み合わせているため、順序逆転したデータに対して検索可能となる。さらに、オフセットデータを圧縮することでネットワークの接続断による突発的な大きな遅延をより効率的に表現できる。
【００１３】
従って、本発明は、データを二次記憶装置へ蓄積する際に、キー値についてデータの順序がある程度逆転して入力されたとしても逐次書き込みファイルに近い速度を維持することが可能、キー値による完全一致検索が可能、範囲検索による効率的なデータの読み込みが可能、且つ突発的な大きな遅延によりデータ順序が大きく逆転したとしても、これを空間効率良く表現可能なデータ構造を実現できるデータ蓄積装置及びデータ蓄積方法を提供することができる。
【００１４】
オフセットデータの圧縮には、以下の３つの手法がある。
【００１５】
（１）Ｒｕｎ  Ｌｅｎｇｔｈ圧縮
Ｒｕｎ  Ｌｅｎｇｔｈ圧縮は、ある値が一定以上の個数連続して現れた場合に、これをそのまま表現する代わりに、連続したビットの個数を表して圧縮する手法である。
【００１６】
本データ蓄積装置の前記システム制御手段は、前記オフセットデータを、コード長記憶部、圧縮回数記憶部、圧縮位置及び圧縮ビット数記憶部、並びにコード部で構成し、前記コード部において、前記オフセット数と等しいビット位置のビットを「１」とし、前記コード部のビット列が予め設定したしきい値以上同一のビットが連続する連続ビット部を含む場合に、前記連続ビット部のビット数を数え上げ、前記連続ビット部の先頭の位置と前記連続ビット部のビット数を前記圧縮位置及び圧縮ビット数記憶部に記録し、前記連続ビット部の先頭のビットを残して前記連続ビット部の他のビットを削除するオフセット圧縮部を有することを特徴とする。
【００１７】
本データ蓄積方法の前記システム制御手順は、前記オフセットデータを、コード長記憶部、圧縮回数記憶部、圧縮位置及び圧縮ビット数記憶部、並びにコード部で構成し、前記コード部において、前記オフセット数と等しいビット位置のビットを「１」とし、前記コード部のビット列が予め設定したしきい値以上同一のビットが連続する連続ビット部を含む場合に、前記連続ビット部のビット数を数え上げ、前記連続ビット部の先頭の位置と前記連続ビット部のビット数を前記圧縮位置及び圧縮ビット数記憶部に記録し、前記連続ビット部の先頭のビットを残して前記連続ビット部の他のビットを削除することを特徴とする。
【００１８】
本圧縮方法では、ビットマップを用いたオフセット表現方法へ応用するに際して、オフセットデータの構造として、コード長記憶部、圧縮回数記憶部、圧縮位置および圧縮ビット数記憶部、並びにコード部を用意する。
【００１９】
このとき、コード部では、前記提案方法と同様にビットマップを用いて、オフセット数と等しいビット番号のビットを１にすることで、オフセット数を表現するが、０もしくは１のビットが、あらかじめ定めた一定数以上連続する場合、これをＲｕｎ  Ｌｅｎｇｔｈ圧縮する。このとき、圧縮に際して、圧縮したビットの位置および連続したビットの個数を表現する必要があるが、これを圧縮位置および圧縮ビット数記憶部に格納する。この圧縮位置および圧縮ビット数記憶部は、Ｒｕｎ  Ｌｅｎｇｔｈ圧縮を行った回数分の個数だけ、都度準備する。この圧縮を行った回数は、圧縮回数記憶部に記憶する。また、コード部に格納されたビットマップのサイズをコード長記憶部に格納する。
【００２０】
本データ構造を用いることで、ビットマップによる表現を行いつつも、Ｒｕｎ  Ｌｅｎｇｔｈ圧縮可能な場合はこれを行うことにより、より効率的なオフセット表現が可能となる。また、圧縮位置および圧縮ビット数部分をコード部と分離させているため、新たなオフセットの追加が、コード部を参照して全てのオフセットをデコードすることなく行え、効率的なオフセット追加処理が可能となる。
【００２１】
（２）Ｓｉｍｐｌｅ９
４バイト（３２ビット）を１つの符号として扱い、１つの符号に、できるだけ多くの整数値を詰め込もうとする方法で、整数値の大きさに合わせて、使用するビット数を１〜２８ビットに変化させる手法である（例えば、非特許文献４を参照。）。
【００２２】
本データ蓄積装置の前記システム制御手段は、一の論理ブロックが受け持つ前記キー値の範囲に含まれる前記キー値を持つ前記レコードが他の複数の論理ブロックにある場合、前記一の論理ブロックから前記他の複数の論理ブロックへの前記オフセット数をそれぞれ求め、前記他の複数の論理ブロックのうち最もブロック位置が近い論理ブロック同士について、求めた前記オフセット数からそれぞれの論理ブロックへのオフセット数の差を求め、これを差分オフセット数とし、前記オフセットデータを、ヘッダ部並びにコード部で構成し、前記コード部に、単数の前記オフセット数もしくは複数の前記差分オフセット数を前記オフセット数もしくは前記差分オフセット数に応じたビット数で表現したオフセットビット列、及び前記オフセットビット列のビット数を記載した一定ビット数の符号ヘッダ、で形成される符号を格納し、前記ヘッダ部に、前記符号の個数及び前記オフセット数の個数を表示するオフセット圧縮部を有することを特徴とする。
【００２３】
本データ蓄積方法の前記システム制御手順は、一の論理ブロックが受け持つ前記キー値の範囲に含まれる前記キー値を持つ前記レコードが他の複数の論理ブロックにある場合、前記一の論理ブロックから前記他の複数の論理ブロックへの前記オフセット数をそれぞれ求め、前記他の複数の論理ブロックのうち最もブロック位置が近い論理ブロック同士について、求めた前記オフセット数からそれぞれの論理ブロックへのオフセット数の差を求め、これを差分オフセット数とし、前記オフセットデータを、ヘッダ部並びにコード部で構成し、前記コード部に、単数の前記オフセット数もしくは複数の前記差分オフセット数を前記オフセット数もしくは前記差分オフセット数に応じたビット数で表現したオフセットビット列、及び前記オフセットビット列のビット数を記載した一定ビット数の符号ヘッダ、で形成される符号を格納し、前記ヘッダ部に、前記符号の個数及び前記オフセット数の個数を表示することを特徴とする。
【００２４】
本圧縮方法をオフセットデータへ応用するに際して、オフセットデータの構造として、ヘッダ部とコード部を用意する。このとき、コード部はＳｉｍｐｌｅ９で圧縮された整数値列を格納し、ヘッダ部はＳｉｍｐｌｅ９で圧縮された整数値の個数とＳｉｍｐｌｅ９の符号の個数とを格納する。本データ構造を用いることで、Ｓｉｍｐｌｅ９の符号の伸長時に、このヘッダ部のデータを用いることで余分なデータの処理が抑えられ、効率的な処理が可能となる。
【００２５】
（３）Ｖａｒｉａｂｌｅ  Ｂｙｔｅ  Ｃｏｄｅ
通常４バイトで表す整数値を、整数値の大きさに合わせて使用するバイト数を１〜４バイトに変化させる方法である（例えば、非特許文献３を参照。）。
【００２６】
本データ蓄積装置の前記システム制御手段は、前記オフセットデータを複数のバイトで構成し、前記オフセット数に応じたバイト数で前記オフセット数を表現する際に、前記オフセット数を表現する各バイトの一定数のビットをヘッダとし、前記オフセット数を表現したバイト数を前記ヘッダで表示するオフセット圧縮部を有することを特徴とする。
【００２７】
本データ蓄積方法の前記システム制御手順は、前記オフセットデータを複数のバイトで構成し、前記オフセット数に応じたバイト数で前記オフセット数を表現する際に、前記オフセット数を表現する各バイトの一定数のビットをヘッダとし、前記オフセット数を表現したバイト数を前記ヘッダで表示することを特徴とする。
【００２８】
また、本発明に係るプログラムは、コンピュータに、前記データ蓄積方法の前記システム制御手順を実行させる。
【発明の効果】
【００２９】
本発明は、データを二次記憶装置へ蓄積する際に、キー値についてデータの順序がある程度逆転して入力されたとしても逐次書き込みファイルに近い速度を維持することが可能、キー値による完全一致検索が可能、範囲検索による効率的なデータの読み込みが可能、且つ突発的な大きな遅延によりデータ順序が大きく逆転したとしても、これを空間効率良く表現可能なデータ構造を実現できるデータ蓄積装置、データ蓄積方法、及びプログラムを提供することができる。
【図面の簡単な説明】
【００３０】
【図１】本発明に係るデータ蓄積装置の構成を説明する図である。
【図２】本発明に係るデータ蓄積装置のデータ構造を説明する図である。
【図３】本発明に係るデータ蓄積装置の動作を説明する図である。
【図４】本発明に係るデータ蓄積装置の動作を説明する図である。
【図５】本発明に係るデータ蓄積装置の動作を説明する図である。
【図６】本発明に係るデータ蓄積装置の動作を説明する図である。
【図７】本発明に係るデータ蓄積装置の動作を説明する図である。
【図８】本発明に係るデータ蓄積装置の動作を説明する図である。
【図９】本発明に係るデータ蓄積装置の動作を説明する図である。
【図１０】本発明に係るデータ蓄積装置のデータ構造を説明する図である。
【図１１】本発明に係るデータ蓄積装置の動作を説明する図である。
【図１２】本発明に係るデータ蓄積装置の動作を説明する図である。
【図１３】本発明に係るデータ蓄積装置の動作を説明する図である。
【図１４】本発明に係るデータ蓄積装置の動作を説明する図である。
【図１５】本発明に係るデータ蓄積装置の動作を説明する図である。
【図１６】本発明に係るデータ蓄積装置の動作を説明する図である。
【図１７】本発明に係るデータ蓄積装置の動作を説明する図である。
【図１８】本発明に係るデータ蓄積装置の動作を説明する図である。
【図１９】本発明に係るデータ蓄積装置のデータ構造を説明する図である。
【図２０】本発明に係るデータ蓄積装置の動作を説明する図である。
【図２１】本発明に係るデータ蓄積装置の動作を説明する図である。
【図２２】本発明に係るデータ蓄積装置の動作を説明する図である。
【図２３】本発明に係るデータ蓄積装置の動作を説明する図である。
【図２４】本発明に係るデータ蓄積装置の動作を説明する図である。
【図２５】本発明に係るデータ蓄積装置の動作を説明する図である。
【図２６】本発明に係るデータ蓄積装置の動作を説明する図である。
【図２７】本発明に係るデータ蓄積装置の動作を説明する図である。
【図２８】本発明に係るデータ蓄積装置の効果を説明する図である。
【図２９】本発明に係るデータ蓄積装置の効果を説明する図である。
【図３０】本発明に係るデータ蓄積装置の効果を説明する図である。
【図３１】本発明に係るデータ蓄積装置の効果を説明する図である。
【発明を実施するための形態】
【００３１】
以下、具体的に実施形態を示して本発明を詳細に説明するが、本願の発明は以下の記載に限定して解釈されない。なお、本明細書及び図面において符号が同じ構成要素は、相互に同一のものを示すものとする。
【００３２】
（実施形態１）
実施形態１はオフセット数の表現にＶａｒｉａｂｌｅ  Ｂｙｔｅ  Ｃｏｄｅを用いる形態である。
【００３３】
図１は、実施形態１のデータ蓄積装置１０の構成を説明する図である。データ蓄積装置１０は、システム制御部３００、インタフェース１１０、バッファメモリ１２０、二次記憶装置３３０を備える。インタフェース１１０はバッファメモリ１２０と、バッファメモリ１２０はインタフェース１１０と二次記憶装置３３０とそれぞれデータのやり取りを行う。システム制御部３００は、インタフェース１１０の入力データについて、それが書き込み要求なのか読み出し要求なのかを解析する。システム制御部３００は、バッファメモリ１２０に対して入出力データをバッファさせるためのメモリ管理を行う。システム制御部３００は、二次記憶装置に対してデータ入力におけるファイルへのデータ書き込みなどのファイル操作を行う。二次記憶装置内には索引ファイル３３１とデータファイル３３２とオフセットファイル３３３の３つのファイルが存在する。
【００３４】
図２は、データ蓄積装置１０のデータ構造を説明する図である。データファイル３３２の各論理ブロックは入力されたレコードから構成される。
【００３５】
オフセットファイル３３３における各レコードであるオフセットデータは、固定長Ｗビットのデータである。各オフセットデータは、ファイル上での位置を用いて、データファイルの各論理ブロックに一対一で対応している。オフセットデータは圧縮したオフセット数値列を格納するコード部のみから構成される。オフセット数値列の圧縮はＶａｒｉａｂｌｅ  Ｂｙｔｅ  Ｃｏｄｅを用いて行う。
【００３６】
図３及び図４はデータ蓄積装置１０におけるデータ追加処理を示すフローチャートである。
【００３７】
データ追加処理では、まず入力レコードをバッファメモリ上に蓄積する（ステップＳ７０１）。入力レコードが論理ブロックサイズ分だけ蓄積されるまで入力レコードをバッファメモリに蓄積し続ける（ステップＳ７０２）。
【００３８】
入力レコードがバッファメモリ内に論理ブロックサイズ分だけ蓄積されたならば、バッファメモリ内のレコードをキー値について昇順にソートする（ステップＳ７０３）。その後、バッファメモリ内のレコードを、データファイルの末尾に論理ブロック分書き込む（ステップＳ７０４）。この書き込んだ論理ブロックをＢ１とする。また、オフセットデータの初期値として全ビットを０にしたビット列を、オフセットファイルに書き込む（ステップＳ７０５）。
【００３９】
次に、索引ファイルを参照して索引ファイル内の最大のキー値を探し、その値を今書き込んだ論理ブロックであるＢ１が扱うキー値の下限値Ｌとして一時的に記憶する（ステップＳ７０６）。その後、書き込んだ論理ブロック内で最大のキー値を持つ末尾のレコードに対して索引を作成し、索引ファイルを更新する（ステップＳ７０７）。
【００４０】
さらに、バッファメモリ内のレコードを参照し（ステップＳ７０８）、先頭のレコードから順にレコードのキー値が下限値Ｌ以下となるレコードを探す（ステップＳ７０９）。参照したレコードが下限値Ｌよりも大きい場合、そこで探索を終了し、書き込み処理を終了する。参照したレコードが下限値Ｌ以下の場合、索引ファイルを調べそのキー値以上でもっとも値が小さいキー値を探す（ステップＳ７１０）。ここで、探索したキー値が指す論理ブロックであるＢ２がすでに更新済みであれば（ステップＳ７１１）、その論理ブロックＢ２の更新処理は取りやめ、バッファメモリ上で次のレコードがあれば、次のレコードを参照し、同様の処理を行う（ステップＳ７２０、ステップＳ７２１）。なければ、そこで探索終了とし、書き込み処理を終了する。探索したキー値が指す論理ブロックＢ２が更新済みでなければ、その論理ブロックＢ２を読み込む（ステップＳ７１２、ステップＳ７１３）。
【００４１】
次に、読み込んだ論理ブロックＢ２と書き込んだ論理ブロックＢ１とのブロック位置を比較し、論理ブロック数がいくつ離れているかを計算し、これをオフセットＸとする（ステップＳ７１４）。このオフセットＸと、論理ブロックＢ２に対応したオフセットデータを入力として（ステップＳ７１５）、「オフセットデータ更新」処理を行う（ステップＳ７１６）。本処理については後述するが、これにより、オフセットデータにオフセットＸを追加して更新したオフセットデータを得ることができる。この更新したオフセットデータにより、元のオフセットデータを更新し、オフセットファイルを更新する（ステップＳ７１９）。
【００４２】
バッファメモリ上の次のレコードがあれば、それを参照し、同様の処理を行う（ステップＳ７２０、ステップＳ７２１）。次のレコードがなければ、データ追加処理を終了する。
【００４３】
図５は、図４のオフセットデータ更新処理Ｓ７１６を説明するフローチャートである。
【００４４】
オフセットデータ更新処理Ｓ７１６では、入力として、オフセットデータとオフセットを受け取る。例として、オフセットデータとして“１０，１１，１２”の整数値列をＶａｒｉａｂｌｅ  Ｂｙｔｅ  Ｃｏｄｅで圧縮したもの、オフセットとして１２９が入力されたとする。このとき、ループ（ステップＳ８１２）に入り、オフセットの１２９を２進数で表現するのに、どれだけのビット数が必要かのチェックを行う（ステップＳ８１３）。このとき、１２９は規定値の一つである１２８よりも大きく、１６３８４よりも小さいため、ビット数１４で表現できることがわかる。この１４ビットで１２９を表現し（００００００１００００００１）このビット列をＰとする（ステップＳ８１５）。Ｐについて、先頭から順にビット７つごとに、ヘッダとして１ビットを追加し、１バイトひとまとまりで扱う。このため、Ｐは（０００００００１  ０００００００１）となる。さらに、その１バイトが数値を表現する最下位バイトだった場合、ヘッダの１ビットを１とする（ステップＳ８１６）。このため、Ｐは（０００００００１  １００００００１）となる。これをオフセットデータの末尾に追加し（ステップＳ８１７）、オフセットデータを“１０，１１，１２，１２９”を圧縮したものとする。このとき、オフセットデータを表すのに必要なビット長が、あらかじめオフセットデータについて設定した固定ビット長Ｗ以下であれば（ステップＳ８１８）、更新したオフセットデータを出力して更新処理を終了する（ステップＳ８１９）。Ｗ以上であった場合、追加したオフセットの１２９は格納不可であるため（ステップＳ８１４）、エラーを出力してオフセットデータを更新せずに処理を終了する。
【００４５】
図６は、データ蓄積装置のキー値によるデータの完全一致検索処理を説明するフローチャートである。
【００４６】
まず、探索したいキー値Ｘが入力される（ステップＳ９１１）。索引ファイルから探索キー値Ｘ以上でもっとも値が小さいキー値Ａを捜し、その値Ａが指すレコードを含む論理ブロックＤ１を読み込む（ステップＳ９１２）。次に、読み込んだ論理ブロックＤ１内のレコード部から二分探索を用いて探索キー値Ｘを持つレコードを探す（ステップＳ９１３）。
【００４７】
このとき、探索キー値Ｘを持つレコードが見つかったのであれば（ステップＳ９１４）、探索キー値Ｘを持つレコードを出力して終了する（ステップＳ９２１）。探索キー値Ｘを持つレコードが見つからなかった場合、別の論理ブロックにあるレコードを調べるため、読み込んだ論理ブロックＤ１に対応したオフセットデータをオフセットファイルから読み込む（ステップＳ９１５）。その後、読み込んだオフセットデータを入力として、「オフセットデータ参照」処理を行う（ステップＳ９１６）。本処理の詳細は後述するが、これにより、オフセット整数値列Ｆを得ることができる。そのあと、オフセット整数値列Ｆの要素すべてについて（ステップＳ９１７）、その要素が示すオフセット数をＧとして、論理ブロックＤ１のＧブロック先の論理ブロックＤ２を読み込み（ステップＳ９１８）、Ｄ２が探索キー値Ｘを持つかどうかを二分探索を用いてチェックする（ステップＳ９１９）。探索キー値Ｘを持つレコードが見つかれば（ステップＳ９２０）、そのレコードを出力し、処理を終了する（ステップＳ９２１）。もし、オフセット整数値列Ｆのすべての要素をチェックしても探索キー値Ｘを持つレコードが見つからなければ、該当レコードは無しと出力し、処理を終了する（ステップＳ９２２）。
【００４８】
図７は、図６のオフセットデータ参照処理Ｓ９１６を説明するフローチャートである。
【００４９】
オフセットデータ参照処理Ｓ９１６では、入力としてオフセットデータを受け取る。例として、“１０，１１，１２，１２９”の整数値列を圧縮したものが入力されたオフセットデータだとする。このオフセットデータを元の整数値列に戻す処理を行う。先頭から順に１バイトずつ読み込み（ステップＳ９５３）、バイトのヘッダ先頭１ビットが１かどうかを確認する（ステップＳ９５４）。このとき、先頭１ビットが０であれば（ステップＳ９５４）、続く次の１バイトも同数値を表現するためのバイトとみなし（ステップＳ９５５）、それをチェックする（ステップＳ９５３）。先頭１ビットが１であれば（ステップＳ９５４）、そこまで読み込んできたバイトをまとめて１つの整数値を表現しているとみなし、各バイトの先頭１ビットのヘッダを削除する処理を行う（ステップＳ９５７）。例ではこのとき、オフセットデータが（１０００１０１０  １０００１０１１  １０００１１００  ０００００００１  １００００００１）となっているので、１バイトの数値が３個“１０，１１，１２”、２バイトの数値が１個“１２９”であることがわかる。このようにしてすべてのバイトを１０進数に変換し（ステップＳ９５８）、これを出力して処理を終了する。
【００５０】
図８及び図９はデータ蓄積装置１０のキー値による範囲検索処理を示すフローチャートである。
【００５１】
まず、入力として下限キー値以上、上限キー値未満という検索条件が与えられるとする（ステップＳ１１０１）。索引ファイルから下限キー値以上でもっとも値が小さいキー値を捜してその値が指すレコードを含む論理ブロックをデータファイルから読み込む（ステップＳ１１０２）。続いて、読み込んだ論理ブロックに対応したオフセットデータを、オフセットファイルから読み込む（ステップＳ１１０３）。この読み込んだオフセットデータを入力として、「オフセットデータ参照」処理を行い（ステップＳ９１６）、出力として、オフセット整数値列Ｆを得る。このオフセット整数値列Ｆの各要素に、読み込んだ論理ブロックのブロック位置を加算し、これらをブロック位置集合Ｕとして一時的に記録する（ステップＳ１１０５）。
【００５２】
次に、論理ブロックのレコード部の先頭のレコードから順番にレコードのキー値が下限キー値以上かどうか調べていく（ステップＳ１１０７）。下限キー値以上のレコードが見つかったら、まず論理ブロック内で最大のキー値を持つ末尾のレコードを参照し、そのキー値が上限キー値以上かどうかを調べる（ステップＳ１１０９）。このとき、上限キー値以上でなければ、この論理ブロックの現在参照しているレコードから末尾のレコードまでのすべてのレコードは検索条件を満たすとして、検索条件を満たすレコード集合Ｒに追加する（ステップＳ１１１６）。その後、データファイル内に次の論理ブロックがあれば（ステップＳ１１１７）それを読み込み同様の処理を行う（ステップＳ１１１８）。論理ブロックがなければ、そこで検索終了となり、レコード集合Ｒを出力して終了する（ステップＳ１１２５）。
【００５３】
末尾のレコードのキー値が上限キー値以上だった場合（ステップＳ１１０９）は、参照しているレコードから末尾のレコードまで順番にキー値が上限値未満かどうかの比較を行っていく（ステップＳ１１１０）。もし参照しているレコードのキー値が上限キー値未満であれば、そのレコードを検索条件を満たすレコード集合Ｒに追加する（ステップＳ１１１１）。上限キー値未満でないレコードを見つけたら、次はオフセットデータが指している論理ブロックのレコードについて検索を行う（ステップＳ１１１３）。
【００５４】
ブロック位置集合Ｕが持つ全てのブロック位置の論理ブロックを参照し（ステップＳ１１１４）、そのうちのまだ探索していないブロックのレコードから下限キー値以上、上限キー値未満になるレコードを順番に見つけ、検索条件を満たすレコード集合Ｒに追加していく（ステップＳ１１２３）。ブロック位置集合Ｕが持つ全てのアドレスが指す論理ブロックの探索が終わったら、検索終了となり、レコード集合Ｒを出力して終了する（ステップＳ１１２５）。
【００５５】
データ蓄積装置１０の利点は、より効率的に大きなデータ到着遅延を表すオフセットに対応可能であることである。従来は、オフセットの表現にビット番号を使用しているため、オフセットデータのビット列長であるＷが、記録可能な最大のオフセットとなる。一方、データ蓄積装置１０は、最大２８ビットを用いて１つの数値を表すことができるため、より効率的に大きなオフセットを示すことが可能である。上記例において、オフセットとして“１０，１１，１２，１２９”を格納するが、従来では１２９ビットが必要になるのと比べ、データ蓄積装置１０は、４０ビットで格納することができる。このため、突発的な要因で発生する怖れのある大きな到着遅延に効率的に対応することができる。
【００５６】
（実施形態２）
実施形態２は、オフセットの表現にＳｉｍｐｌｅ９で圧縮した整数値を用いる形態である。実施形態２のデータ蓄積装置の構成は図１のデータ蓄積装置１０と同様である。
【００５７】
図１０は、実施形態２のデータ蓄積装置のデータ構造を説明する図である。
【００５８】
オフセットファイル３３３’における各レコードであるオフセットデータは、固定長Ｗビットのデータである。ファイル上での位置を用いて、データファイルの各論理ブロックに一対一で対応している。オフセットデータは圧縮したオフセット数値列を格納するコード部と、コード部に格納したオフセット数値列の要素数およびコード部の４バイトの符号の数を表すヘッダ部から構成される。オフセット数値列の圧縮はＳｉｍｐｌｅ９を用いて行う。Ｓｉｍｐｌｅ９は１つの整数値を通常４バイト（３２ビット）で表現するところを、その大きさに合わせて１〜２８ビットで表現してデータを圧縮する。
【００５９】
図１１及び図１２は実施形態２のデータ蓄積装置におけるデータ追加処理を示すフローチャートである。図３及び図４のフローチャートとの違いはオフセットデータ更新処理がステップＳ７１６’である点である。
【００６０】
図１３は、実施形態２におけるオフセットデータ更新処理Ｓ７１６’を説明するフローチャートである。
【００６１】
オフセットデータ更新処理Ｓ７１６’では、入力としてオフセットとオフセットデータを受け取る。例として、入力されるオフセットデータは“１０，１１，１２”の数値列をエンコードしたもの、オフセットは１２９だとする。
【００６２】
オフセットデータ更新処理Ｓ７１６’では、オフセットデータのＳｉｍｐｌｅ９のデコード（ステップＳ８３１）、デコードしたオフセットデータへのオフセットの追加（ステップＳ８３２）、オフセットデータのＳｉｍｐｌｅ９へのエンコード（ステップＳ８３３）という順で処理が行われる。
【００６３】
本例では、まずＳｉｍｐｌｅ９でエンコード済みの“１０，１１，１２”をデコードし、デコードした数値列に１２９を追加し、“１０，１１，１２，１２９”の数値列をＳｉｍｐｌｅ９でエンコードして、そのエンコードしたビット列が固定長Ｗビットに収まるかどうかを判定し（ステップＳ８３４）、収まっていたのであれば、更新したオフセットデータを出力して処理を終了する。
【００６４】
図１４は、図１３のＳｉｍｐｌｅ９エンコード処理（ステップＳ８３３）を説明するフローチャートである。
【００６５】
Ｓｉｍｐｌｅ９エンコード処理Ｓ８３３では、入力として、非負の整数値列を受け取る。エンコード処理では、まず、入力された整数値列の要素順に、要素とその１つ後の要素との差を計算し（ステップＳ１００４）、記録していく（ステップＳ１００３〜ステップＳ１００５）。例として挙げた“１０，１１，１２，１２９”の数値列は、計算後、“１０，１，１，１１７”となる。この計算後の数値列に対して、Ｓｉｍｐｌｅ９によるエンコードを行っていく。先頭から数値列の要素をチェックして行き、数値が何ビットで表現できるかどうかをチェックする（ステップＳ１０１１〜ステップＳ１０１３）。“１０，１，１，１１７”をエンコードする場合、最初の３要素である“１０，１，１”は４ビットでエンコード可能だが、その後に続く１１７はエンコードに７ビットが必要なので、これらの数値列のエンコードは全て７ビット用いて行う。このとき、ビット列のヘッダとして、４ビットのヘッダ（０１０１）を付加することで、続く２８ビットが７ビット単位で数値を表現することを示す（ステップＳ１０１２）。続く２８ビットは、“１０，１，１，１１７”をそれぞれ７ビットで表し、ビット列（０００１０１０  ００００００１  ００００００１  １１１０１０１）を得る。この結果“１０，１，１，１１７”をエンコードした３２ビットの符号は（０１０１  ０００１０１０  ００００００１  ００００００１  １１１０１０１）となり、これをＳｉｍｐｌｅ９の１つの符号として記録する（ステップＳ１０１８）。最後にオフセットデータのヘッダ部にエンコードした数値の数Ｎ＝４とＳｉｍｐｌｅ９の符号の個数Ｔ＝１を記入し（ステップＳ１０２０）、オフセットデータを出力し処理を終了する。
【００６６】
図１５は、図１３のＳｉｍｐｌｅ９デコード処理（ステップＳ８３１）を示すフローチャートである。
【００６７】
Ｓｉｍｐｌｅ９デコード処理Ｓ８３１では、入力としてオフセットデータを受け取る。例として、入力されるオフセットデータは“１０，１１，１２，１２９”の数値列をエンコードした（０１０１  ０００１０１０  ００００００１  ００００００１  １１１０１０１）とする。まず、オフセットデータのヘッダ部を参照して、３２ビットのＳｉｍｐｌｅ９符号の個数Ｔ＝１とエンコードされた整数値の合計Ｎ＝４を取得する（ステップＳ１０３１）。その後、Ｔ個のすべてのＳｉｍｐｌｅ９符号について先頭から順に復号処理を行っていく（ステップＳ１０３３〜ステップＳ１０３８）。復号処理では、各符号のヘッダである上位４ビットを参照することで、そのあとに続く２８ビットを何ビットずつに区切って１０進数の整数値に変換すればよいのかを得る。本例の（０１０１  ０００１０１０  ００００００１  ００００００１  １１１０１０１）では、先頭４ビットが（０１０１）であり、これは続く２８ビットを７ビットずつに区切ることを示すので、（０００１０１０，００００００１，００００００１，１１１０１０１）を１０進数に変換した数列“１０，１，１，１１７”が得られる。さらに、この得られた数列に対して、先頭から順番に、要素とその一つ前の要素との和を計算し、その和を新しい要素として、数列の更新を行う（ステップＳ１０４１）。これを数列の末尾の要素まで繰り返す（ステップＳ１０４０〜ステップＳ１０４２）。本例では、“１０，１，１，１１７”であるので、ここから計算し得られる数列は“１０，１１，１２，１２９”となる。Ｓｉｍｐｌｅ９デコード処理Ｓ８３１は、この数列をデコード結果として出力し、処理を終了する。
【００６８】
図１６は実施形態２のデータ蓄積装置におけるキー値による完全一致検索処理を説明するフローチャートである。
【００６９】
完全一致検索処理は、図６で説明した実施形態１の完全一致検索処理と同様の処理を行っているが、図６のオフセットデータ参照処理Ｓ９１６がＳｉｍｐｌｅ９デコード処理Ｓ８３１となる点が異なる。
【００７０】
図１７及び図１８は実施形態２のデータ蓄積装置におけるキー値による範囲検索処理を説明するフローチャートである。
【００７１】
範囲検索処理は、図８及び図９で説明した実施形態１の範囲検索処理と同様の処理を行っているが、オフセットデータ参照処理Ｓ１１０４がＳｉｍｐｌｅ９デコード処理Ｓ８３１となる点が異なる。
【００７２】
実施形態２のデータ蓄積装置の利点は、実施形態１のデータ蓄積装置１０と同様に大きなオフセットを効率的に表現できるだけでなく、さらに小さなオフセットに対しても最小で１ビットで表現でき、小さいオフセットも効率良く表現できる点である。実施例で挙げた例では、オフセットとして、“１０，１１，１２，１２９”を格納するが、従来の方法では、１２９ビットが必要になるのと比べ、実施形態２では、３２ビットにヘッダ分のビット数、例えば３２ビット、を加えた６４ビットで格納することができる。
【００７３】
（実施形態３）
実施の形態３は、オフセットの表現にビット番号を用い、０もしくは１のビットが連続した場合にＲｕｎ  Ｌｅｎｇｔｈ圧縮を用いる方法である。実施形態３のデータ蓄積装置の構成は図１のデータ蓄積装置１０と同様である。
【００７４】
図１９は、実施形態３のデータ蓄積装置のデータ構造を説明する図である。
【００７５】
オフセットファイル３３３”における各レコードであるオフセットデータは、固定長Ｗビットのデータである。ファイル上での位置を用いて、データファイルの各論理ブロックに一対一で対応している。オフセットデータは、１つのコード長記憶部、１つの圧縮回数記憶部、複数の圧縮位置および圧縮ビット数記憶部、１つのコード部で構成される。コード長記憶部は、コード部で利用されているビット数を保持する。圧縮回数記憶部は、続く圧縮位置および圧縮ビット数記憶部の個数を保持する。圧縮位置および圧縮ビット数記憶部は、続くコード部において、圧縮が行われているビット位置とそこで圧縮されたビット数を保持する。コード部では圧縮処理後のビット列が保持される。
【００７６】
コード部のビット列において、１となるビットのビット位置が基本的にデータの遅れブロック数を示す。ただし、このとき、コード部において、ビットの１もしくは０が、しきい値ｋ個以上続く場合には、これをＲｕｎ  Ｌｅｎｇｔｈ圧縮する。このとき、圧縮位置および圧縮ビット数記憶部として、Ｒｕｎ  Ｌｅｎｇｔｈ圧縮を開始した位置と、圧縮したビット数を記入したものを作成し、オフセットデータに追加する。この追加した圧縮位置および圧縮ビット数記憶部の個数は、圧縮回数記憶部に記入し随時加算していく。
【００７７】
図２０及び図２１は実施形態３のデータ蓄積装置におけるデータ追加処理を示すフローチャートである。図３及び図４のフローチャートとの違いはオフセットデータ更新処理がステップＳ７１６”である点である。
【００７８】
図２２は実施形態３のオフセットデータ更新処理Ｓ７１６”を説明するフローチャートである。
【００７９】
オフセットデータ更新処理Ｓ７１６”では、入力としてオフセットデータＸと追加するオフセットＹを受け取る。例として、入力するオフセットデータＸは“１０，１１，１２”の数値列をオフセットデータ圧縮処理によって圧縮したもの、追加するオフセットＹは１２９だとする。
【００８０】
オフセット更新処理Ｓ７１６”では、まず、圧縮回数記憶部を参照し、圧縮位置および圧縮ビット数記憶部の個数Ｍを得る（ステップＳ８５１）。次に、Ｍ個の圧縮位置および圧縮ビット数記憶部を読み込み、Ｍ個の圧縮位置Ｐ［１．．Ｍ］と圧縮ビット数Ｓ［１．．Ｍ］を記憶する（ステップＳ８５２）。次に、Ｍ個の圧縮ビット数Ｓ［１．．Ｍ］  をすべて足し合わせ、これに最後の分割位置Ｐ［Ｍ］を足すことで、オフセットデータが記録する圧縮部分を伸長した場合の末尾のビット位置を得、この値をＬａｓｔ＿Ｐとする（ステップＳ８５３〜ステップＳ８５７、ステップＳ８６０）。次に、追加するオフセットＹとＬａｓｔ＿Ｐの値を比較し、ＹとＬａｓｔ＿Ｐを１増加させた値が等しければ（ステップＳ８５８）、Ｍ番目の圧縮ビット数が１増えたとみなし、圧縮ビット数Ｓ［Ｍ］を１増加させる（ステップＳ８５９）。ＹとＬａｓｔ＿Ｐを１増加させた値が等しくなければ、オフセットデータＸのコード部において、ＹからＬａｓｔ＿Ｐを引いた値の位置のビットを１にする（ステップＳ８６１）。また、コード長記憶部Ｎの値をＹからＬａｓｔ＿Ｐを引いたものとして更新する（ステップＳ８６２）。このようにして更新されたオフセットデータＸをオフセット圧縮処理（ステップＳ８６３）に入力し、その結果出力として、圧縮されたオフセットデータＺを得る。その後、オフセットデータＺがあらかじめ決められた固定長Ｗビットに収まるかどうかを判定し（ステップＳ８６４）、オフセットデータ更新処理を終了する。
【００８１】
例では、オフセットデータは“１０，１１，１２”をオフセット圧縮処理によって圧縮したものであり、これをビット列で表すと１０番目、１１番目、１２番目のビットが１となったビット列（００００００００  ０１１１）となる。これにオフセットである“１２９”を加えた場合、これをビット列で表せば、“１２”と“１２９”との間には、１１６個の０が存在することになる。この１１６個の０ビットをＲｕｎ  Ｌｅｎｇｔｈ圧縮すると、圧縮回数は１、圧縮位置と圧縮ビット数はそれぞれ“１３，１１５”となり、コード部のビット列は（００００００００  ０１１１０１）となる。また、別の例として、“１１，１２，１３，・・・，９８，９９，１００”と数字が連続しているオフセットデータがあるとし、これに新たなオフセット１０１を加えるとする。このデータはＲｕｎ  Ｌｅｎｇｔｈ圧縮により、圧縮位置と圧縮ビット数が“１１，８９”、コード部が（００００００００  ００１）となる。これにオフセット１０１を追加する場合、最後の数値よりも１だけ大きいので、圧縮ビット数のみを更新して、圧縮位置と圧縮ビット数を“１１，９０”とすれば、オフセット１０１を加えたこととなる。
【００８２】
図２３は、図２２のオフセットデータ圧縮処理Ｓ８６３を説明するフローチャートである。
【００８３】
オフセットデータ圧縮処理Ｓ８６３では、入力としてオフセットデータを受ける。このオフセットデータに対して、圧縮可能な部分を探索し、Ｒｕｎ  Ｌｅｎｇｔｈ圧縮を行っていく。まず、オフセットデータのコード長記憶部、圧縮回数記憶部をそれぞれ参照し、コード部のビット数Ｎと圧縮位置および圧縮ビット数記憶部の個数Ｍを得る（ステップＳ１０５１、ステップＳ１０５２）。次に、Ｍが０よりも大きいかどうかの判定を行う（ステップＳ１０５５）。Ｍが０よりも大きい場合、オフセットデータに対して圧縮が行われているため、すでに圧縮が行われている部分をスキップするため、ｉ＝Ｐ［Ｍ］＋１とし（ステップＳ１０５６）、圧縮が行われた末尾のビットの次のビットから圧縮可能な部分の探索を始める。Ｍが０以下である場合、オフセットデータに対して圧縮が行われていないため、ｉ＝１とし、コード部の先頭のビットから圧縮可能な部分の探索を始める（ステップＳ１０５７）。圧縮可能な部分の探索には、ｉを１ずつ増加させながら（ステップＳ１０５８）、Ｘ［ｉ］とＸ［ｉ−１］の比較を行うことで（ステップＳ１０５９）、０もしくは１のビットが連続しているかどうかを判定し、連続していれば、ｃｏｕｎｔｅｒを１ずつ増加することで、連続した数を数え上げていく（ステップＳ１０６０）。Ｘ［ｉ］とＸ［ｉ−１］が異なる場合、０もしくは１のビットの連続が途切れたとみなし、連続したビットの数を示すｃｏｕｎｔｅｒがしきい値Ｋを超えるかどうかにより（ステップＳ１０６８）、これを圧縮するかどうかの判定を行う。ｃｏｕｎｔｅｒがＫ以上であれば、圧縮処理を行う。圧縮処理では、まず、圧縮回数を示すＭを１増加させる（ステップＳ１０６９）。次に、圧縮ビット数を示すＳ［Ｍ］をｃｏｕｎｔｅｒとする（ステップＳ１０７０）。続いて、圧縮位置を示すＰ［Ｍ］は、ｉから１を引き、さらにｃｏｕｎｔｅｒ  を引いた値とする（ステップＳ１０７１）。次に、圧縮したビット数の分だけビットを前に詰める処理を行う（ステップＳ１０７３〜ステップＳ１０７６）。さらに、コード部の有効なビットの長さを示すＮも圧縮にあわせてｃｏｕｎｔｅｒだけ減らす（ステップＳ１０７７）。最後に、現在チェックしているビットの位置を示すｉをｉ＝Ｐ［Ｍ］＋１とし、圧縮が行われたビットの次のビットの位置とする（ステップＳ１０７８）。
【００８４】
一方、０もしくは１のビットが連続したまま、すべてのコード部のビットの末尾まで到達した場合にも、その連続した数がしきい値Ｋを超えて入れば、圧縮処理を行う（ステップＳ１０６２）。この圧縮処理では、まず、圧縮回数を示すＭを１増加させ（ステップＳ１０６３）、圧縮ビット数を示すＳ［Ｍ］をｃｏｕｎｔｅｒとするが（ステップＳ１０６４）、圧縮位置を示すＰ［Ｍ］は、ｉからｃｏｕｎｔｅｒを引いた値とする（ステップＳ１０６５）。次に、コード部の有効なビットの長さを示すＮも圧縮に合わせてｃｏｕｎｔｅｒだけ減らす（ステップＳ１０６６）。最後に、Ｎ，Ｍ，Ｐ，Ｓ，Ｘをそれぞれオフセットデータのコード長記憶部、圧縮回数記憶部、圧縮位置および圧縮ビット数記憶部、コード部に反映し、オフセットデータを更新する（ステップＳ１０６７）。更新したオフセットデータを出力して、圧縮処理を終了する。
【００８５】
例として、図２２で示したオフセットデータ更新処理Ｓ７１６”において、オフセットデータＸが“１０，１１，１２”の数値列をオフセットデータ圧縮処理によって圧縮したもの、追加するオフセットＹが１２９、しきい値Ｋが３２である場合を考える。オフセットデータＸはコード長Ｎ＝１２、圧縮回数Ｍ＝０、コード部が（０００００００００１１１）となったデータである。Ｍ＝０であり、圧縮位置および圧縮ビット数記憶部は存在しないため、Ｐ［１］＝０、Ｓ［１］＝０とする。このため、Ｓｕｍ＿ＳおよびＬａｓｔ＿Ｐも０となる。Ｙは１２９であり、これはＬａｓｔ＿Ｐに１加えたものと等しくないため、オフセットデータＸのコード部の１２９番目のビットを１にし、間のビットは０で埋める。Ｎも同様に１２９とし、オフセットデータＸを更新する。次に、更新したオフセットデータＸを入力として、図２３に示すオフセットデータ圧縮処理Ｓ８６３を行う。
【００８６】
オフセットデータ圧縮処理Ｓ８６３では、まず、コード長記憶部、圧縮回数記憶部を参照し、コード長Ｎ＝１２９，圧縮回数Ｍ＝０を得る。また、Ｍ＝０であり、圧縮位置および圧縮ビット数記憶部が存在しないため、Ｐ［１］＝０、Ｓ［１］＝０とする。コード部を読み込み、これをＸ［１．．．１２９］とする。Ｍ＝０であるので、ｉ＝１とし、Ｘの先頭ビットから同じビットが連続しているかどうかのチェックを行う。Ｘは、（０００００００００１１１０００・・・０００１）であるので、最初の９ビットは０が連続している。しかし、９個の連続ビットでは、ｃｏｕｎｔｅｒは８となり、しきい値Ｋの３２を超えないため、圧縮は行われない。続く（１１１）についても同様に３ビットのみの連続で、ｃｏｕｎｔｅｒは２となり、しきい値Ｋよりも小さいため、圧縮を行わない。続く０は１１６ビット連続しており、ｃｏｕｎｔｅｒは１１５となり、しきい値Ｋよりも大きいため、圧縮を行う。まず、圧縮回数であるＭを１増加させ、Ｍ＝１とする。次に、Ｓ［Ｍ］にｃｏｕｎｔｅｒの値を代入し、Ｓ［Ｍ］＝１１５とする。また、Ｐ［Ｍ］については、ｉ＝１２９から１とｃｏｕｎｔｅｒ＝１１５を引いた値となり、１３となる。続いて、圧縮したビットの数だけ、圧縮した位置よりも後方のビットを前に詰める処理を行う。その後、コード長Ｎ＝１２９から圧縮した分であるｃｏｕｎｔｅｒ＝１１５だけ減らし、Ｎ＝１４とする。最後に、次にチェックするビットの位置であるｉを圧縮したビットの次の位置であるＰ［Ｍ］＋１＝１４とし、ｃｏｕｎｔｅｒを０にセットしてループへ戻る。この時点で、ｉはＮよりも小さくなくなったので、ループを抜け、コード長Ｎ＝１４、圧縮回数Ｍ＝１、圧縮位置Ｐ［１］＝１３、圧縮ビット数Ｓ［１］＝１１５、Ｘ＝（０００００００００１１１０１）をオフセットデータに反映させてこれを更新し、出力して処理を終了し、図２２のオフセットデータ更新処理Ｓ７１６”に戻る。
【００８７】
ここで、得られたオフセットデータＺがあらかじめ決められたオフセットデータの固定長であるＷを超えるかどうかを判定し、越えなければ、オフセットデータ更新を終了する。もし、越えてしまうのであれば、オフセットＹは格納不可だったとして、その旨を出力する。その際、オフセットデータ更新は行われず、更新前のオフセットデータのままとする。
【００８８】
図２４は実施形態３のデータ蓄積装置におけるキー値による完全一致検索処理を説明するフローチャートである。
【００８９】
完全一致検索処理では、図６で説明した実施形態１の完全一致検索処理と同様の処理を行っていくが、図６のオフセットデータ参照処理Ｓ９１６がオフセットデータ参照処理Ｓ９１６”となる。
【００９０】
図２５は、図２４のオフセットデータ参照処理Ｓ９１６”を説明するフローチャートである。
【００９１】
オフセットデータ参照処理では、入力としてオフセットデータを受ける。まず、オフセットデータの圧縮回数記憶部を参照し、圧縮位置および圧縮ビット数記憶部の個数Ｍを得る（ステップＳ９６０）。続いて、Ｍ個の圧縮位置および圧縮ビット数記憶部を読み込み、圧縮位置Ｐ［１．．Ｍ］と、圧縮ビット数Ｓ［１．．Ｍ］を得る（ステップＳ９６１）。次に、オフセットデータのコード長記憶部を参照し、コード長Ｎを得（ステップＳ９６２）、オフセットデータのコード部の各ビットをＸ［１．．Ｎ］に記憶する（ステップＳ９６３）。次に、オフセットを整数列として一時的に記憶する領域を用意して、これをＦとする（ステップＳ９６４）。ｉをビット位置を示すカウンタ、ｊを圧縮位置および圧縮ビット数記憶部の位置を示すカウンタ、ｓｋｉｐを圧縮したビット数の合計として、処理を進めていく（ステップＳ９６５）。まず、Ｐ［ｊ］をｉと比較し、Ｘ［ｉ］が圧縮されたビットかどうかの確認を行う（ステップＳ９６６）。Ｘ［ｉ］が圧縮されたビットでなければ、そのビットが０か１かを確認する（ステップＳ９７３）。もし１であれば、それが示すオフセットをｉとｓｋｉｐを足し合わせることで求め（ステップＳ９７４）、これをＦに記憶する（ステップＳ９７５）。もし０であれば（ステップＳ９７３）、これはオフセットを示さないので計算を行わない。この後、ｉとＮを比較し（ステップＳ９７１）、ｉがＮよりも小さければ、ｉを１増やし（ステップＳ９７２）、ｉとＰ［ｊ］の比較へ戻る。ｉがＮ以上であれば、Ｆを出力して終了する。
【００９２】
Ｘ［ｉ］が圧縮されたビットである場合も同様に、そのビットが０か１かを確認する（ステップＳ９６７）。もし、１であれば、Ｘ［ｉ］が示すオフセットすべてを求めるため、ｃｏｕｎｔｅｒ＝０とし（ステップＳ９７６）、ｏｆｆｓｅｔ＝ｉ＋ｓｋｉｐ＋ｃｏｕｎｔｅｒとして、オフセットを計算し（ステップＳ９７７）、Ｆに記憶する（ステップＳ９７８）。これを、ｃｏｕｎｔｅｒがＳ［ｊ］と等しくなるまで、１ずつ増加させて繰り返すことで（ステップＳ９７９、ステップＳ９８０）、Ｘ［ｉ］が示す全てのオフセットをＦに記憶する。その後、ｓｋｉｐにＳ［ｉ］を加算してｓｋｉｐを更新する（ステップＳ９６８）。Ｘ［ｉ］が０の場合は、オフセットの計算および記憶は行わず、ｓｋｉｐの更新のみを行う（ステップＳ９６８）。ｓｋｉｐの更新を行ったら、ｊとＭを比較し（ステップＳ９６９）、ｊがＭよりも小さければｊを１増やす（ステップＳ９７０）。その後、先のｉとＮの比較に移り（ステップＳ９７１）、同様の処理を行う。
【００９３】
例として、図２５で示したオフセットデータ参照処理Ｓ９１６”において、入力するオフセットデータを先の図２２で示したオフセットデータ更新処理Ｓ７１６”によって圧縮した“１０，１１，１２，１２９”とした場合を考える。このとき、Ｍ＝１，Ｐ［１］＝１３，Ｓ［１］＝１１５，Ｎ＝１４，Ｘ＝（０００００００００１１１０１）となる。
【００９４】
ｉ＝１からｉ＝９では、Ｐ［１］＝１３，かつＸ［ｉ］＝０となるため、オフセット整数列のＦは更新されない。ｉ＝１０，１１，１２では、Ｘ［ｉ］＝１であるので、ｏｆｆｓｅｔを計算しＦに記憶し、Ｆ＝“１０，１１，１２”となる。ｉ＝１３のときｉ＝Ｐ［１］＝１３であるため、Ｘ［１３］が圧縮されたビットであることがわかる。このとき、Ｘ［１３］＝０なので、ｓｋｉｐの更新のみを行い、ｓｋｉｐ＝１１５となる。ｊ＝１，Ｍ＝１であるので、ｊは更新せず、ｉのみ１増加させｉ＝１４とする。Ｘ［１４］＝１であるので、ｏｆｆｓｅｔをｏｆｆｓｅｔ＝ｉ＋ｓｋｉｐと計算し、ｏｆｆｓｅｔ＝１２９を得、Ｆを更新し、Ｆ＝“１０，１１，１２，１２９”となる。ｉ＝Ｎ＝１４となったため、Ｆを出力し、これでオフセットデータ参照処理を終了する。
【００９５】
図２６及び図２７は実施形態３のデータ蓄積装置におけるキー値による範囲検索処理を説明するフローチャートである。
【００９６】
範囲検索処理は、図８及び図９で示した実施形態１の範囲検索処理と同様の処理を行っていくが、オフセットデータ参照処理Ｓ１１０４が図２５で説明したオフセットデータ参照処理Ｓ９１６”となる点が異なる。
【００９７】
実施形態３のデータ蓄積装置は、データ到着遅延が連続して発生するようなデータに特化した方法を採用している。データソース側の回線切断などにより、出力バッファに溜まったデータが回線復旧後にまとめて送られてくる場合など、大きなオフセットの値が連続して続く場合に効率的にオフセットを表現することができる。実施例で挙げた例では、オフセットとして、“１０，１１，１２，１２９”を格納するが、従来の方法では、１２９ビットが必要になるのと比べ、実施形態３では、コード長記憶部のサイズＨ１を１６ビット、圧縮回数記憶部のサイズＨ２を８ビット、圧縮位置及び圧縮ビット数記憶部のサイズＨ３を３２ビットとすると、コード部は１４ビットのため、合計７０ビットで格納することができる。
【００９８】
（圧縮の効果）
次に、本発明の各圧縮方法によるビット効率向上の例をグラフで示す。以下の例では、Ｓｉｍｐｌｅ９のオフセットデータにおけるヘッダ部の大きさを３２ビット、Ｒｕｎ  Ｌｅｎｇｔｈ圧縮のオフセットデータにおけるコード長記憶部の大きさを１６ビット、圧縮回数記憶部の大きさを８ビット、圧縮位置および圧縮ビット数記憶部のサイズを３２ビットとして計算を行っている。
【００９９】
図２８は、あるオフセット数をオフセットデータに格納する場合に、必要となるビット数の圧縮方法による違いを示すグラフである。従来の方式であるＢｉｔｍａｐと、本実施形態の各方式であるＶａｒｉａｂｌｅ  Ｂｙｔｅ  Ｃｏｄｅ、Ｓｉｍｐｌｅ９、Ｒｕｎ  Ｌｅｎｇｔｈ圧縮について比較を行っている。横軸は表現するオフセット数、縦軸は横軸に対応するオフセット数を格納するために必要なビット数を、それぞれ対数軸で表している。グラフより、本実施形態の各方式は、従来の方式であるＢｉｔｍａｐに比べて、必要となるビット数の増加が、オフセット数の増加に対して、よりゆるやかであることが確認できる。
【０１００】
図２９はある範囲で連続しているオフセット数をオフセットデータに格納する場合に、必要なビット数の圧縮方法による違いを示すグラフである。従来の方式であるＢｉｔｍａｐと、本実施形態の各方式であるＶａｒｉａｂｌｅ  Ｂｙｔｅ  Ｃｏｄｅ、Ｓｉｍｐｌｅ９、Ｒｕｎ  Ｌｅｎｇｔｈ圧縮について比較を行っている。横軸は連続したオフセット数の範囲を示しており、“１−１０”は“１，２，３，４，５，６，７，８，９，１０”のオフセット数値列を表している。縦軸は横軸で示されたオフセット数値列をオフセットデータに格納するために必要となるビット数を対数軸で示している。グラフより、オフセット数が連続して並ぶ場合、従来の方法であるＢｉｔｍａｐのビット効率が良いことがわかるが、Ｒｕｎ  Ｌｅｎｇｔｈは“１−７０”以上の場合にＢｉｔｍａｐを超えるビット効率を持つことがわかる。
【０１０１】
図３０は、１から１０の連続したオフセット数値列に加えて、１００、２００、３００、４００、５００、６００、７００、８００のいずれかのオフセット数をオフセットデータとして格納する場合に、必要となるビット数の圧縮方法による違いを示すグラフである。従来の方式であるＢｉｔｍａｐと、本実施形態の各方式であるＶａｒｉａｂｌｅ  Ｂｙｔｅ  Ｃｏｄｅ、Ｓｉｍｐｌｅ９、Ｒｕｎ  Ｌｅｎｇｔｈ圧縮について比較を行っている。横軸は加えて格納するオフセット数を示し、縦軸は横軸で示されたオフセット数を加えた場合に、これをオフセットデータとして格納するために必要となるビット数を示している。グラフより、従来の方法であるＢｉｔｍａｐでは、必要となるビット数が追加して格納するオフセット数の大きさに対応して線形に増加していることに対して、本実施形態の各方式ではほぼ必要となるビット数に変化がなく、高いビット効率でオフセット数を格納できていることがわかる。
【０１０２】
図３１は１から６４の連続したオフセット数値列に加えて、１００、２００、３００、４００、５００、６００、７００、８００のいずれかのオフセット数をオフセットデータとして格納する場合に、必要となるビット数の圧縮方法による違いを示すグラフである。従来の方式であるＢｉｔｍａｐと、本実施形態の各方式であるＶａｒｉａｂｌｅ  Ｂｙｔｅ  Ｃｏｄｅ、Ｓｉｍｐｌｅ９、Ｒｕｎ  Ｌｅｎｇｔｈ圧縮について比較を行っている。横軸は加えて格納するオフセット数を示し、縦軸は横軸で示されたオフセット数を加えた場合に、これをオフセットデータとして格納するために必要となるビット数を示している。グラフより、従来の方法であるＢｉｔｍａｐでは、必要となるビット数が追加して格納するオフセット数の大きさに対応して線形に増加していることに対して、本実施形態の各方式では必要となるビット数にほぼ変化がなく、特に、Ｒｕｎ  Ｌｅｎｇｔｈ圧縮がどのようなオフセット数値列を加えた場合でも、Ｂｉｔｍａｐ以上のビット効率を持つことがわかる。
【０１０３】
（他の実施形態）
上述した各データ蓄積装置はコンピュータとプログラムによっても実現できる。上述した各データ蓄積装置の動作をコンピュータで実行可能なプログラムとし、これをコンピュータが読み取り可能な記録媒体に記録することも、ネットワークを通してコンピュータに提供することも可能である。
【符号の説明】
【０１０４】
１０：データ蓄積装置
１１０：インタフェース
１２０：バッファメモリ
３００：システム制御部
３０１：入力データ解析部
３０２：メモリ管理部
３０３：ファイル操作部
３０４：オフセット圧縮部
３３０：二次記憶装置
３３１：索引ファイル
３３２：データファイル
３３３、３３３’、３３３”：オフセットファイル
【図１】
0005639011.tif 000002
【図２】
0005639011.tif 000003
【図３】
0005639011.tif 000004
【図４】
0005639011.tif 000005
【図５】
0005639011.tif 000006
【図６】
0005639011.tif 000007
【図７】
0005639011.tif 000008
【図８】
0005639011.tif 000009
【図９】
0005639011.tif 000010
【図１０】
0005639011.tif 000011
【図１１】
0005639011.tif 000012
【図１２】
0005639011.tif 000013
【図１３】
0005639011.tif 000014
【図１４】
0005639011.tif 000015
【図１５】
0005639011.tif 000016
【図１６】
0005639011.tif 000017
【図１７】
0005639011.tif 000018
【図１８】
0005639011.tif 000019
【図１９】
0005639011.tif 000020
【図２０】
0005639011.tif 000021
【図２１】
0005639011.tif 000022
【図２２】
0005639011.tif 000023
【図２３】
0005639011.tif 000024
【図２４】
0005639011.tif 000025
【図２５】
0005639011.tif 000026
【図２６】
0005639011.tif 000027
【図２７】
0005639011.tif 000028
【図２８】
0005639011.tif 000029
【図２９】
0005639011.tif 000030
【図３０】
0005639011.tif 000031
【図３１】
0005639011.tif 000032