JP5826114B2 - データ解凍装置、データ圧縮装置、データの解凍プログラム、データの圧縮プログラム、及び、圧縮データ配信システム - Google Patents

Description

開示される主題は、複数の固定長レコードの並びが圧縮されたデータを高速に解凍する技術に関するものである。

カーナビゲーションシステム（以下、カーナビとする）は、地図データを加工してユーザーに交通案内情報を提供するものである。この地図データの記憶媒体として従来はＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）を使用している機種が多かったが、近年はＳＤカードやＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の半導体素子メモリを用いた機種が主流になりつつある。

半導体素子メモリは、従来のＨＤＤと比較して、消費電力が少ない、耐衝撃性に優れている等の利点がある一方、容量あたりの単価が高いという欠点がある。そのため、従来と同程度の価格帯でユーザーにカーナビを提供するためには、使用する半導体素子メモリの容量を少なくする必要がある。これに対して、カーナビが動作するために必要なデータの内容は、記憶媒体がＨＤＤでも半導体素子メモリでも変わりはなく、また、新しい道路や施設の整備等によりデータベースのサイズは年々増加する傾向にあるため、カーナビに収録するデータのサイズを削減する技術が常に望まれている。この、データのサイズを削減する技術として、以下の技術が提案されている。

まず、データの内容を変えずにデータサイズを削減するために一般的に用いられる方法として、特許文献１に記載されているデータ圧縮技術がある。データ圧縮技術は、容易にデータサイズを削減することが可能であるため、特許文献１に記載の技術の他、多数の圧縮方法が提案され、広く実用に供されている。

また、データサイズを削減する別の技術として、特許文献２に記載の技術がある。この技術は、データが２次元のテーブル状の構造を有している場合に、テーブルの各列に着目して所定の手順で辞書を作成し、この辞書を利用することにより列単位で圧縮してデータサイズを削減するものである。なお、このように圧縮対象のデータが行と列からなる二次元の構造を有する場合、単純にデータ（バイト列）を先頭から行方向に処理するよりも、列単位でデータを圧縮したほうが圧縮率の向上を期待できることは一般に知られており、例えば非特許文献１等、多数の文献において言及されている。

また、データサイズを削減する別の技術として、特許文献３に記載の技術がある。この技術は、カーナビのアプリケーションがデータベースにアクセスする形態として、データベース内の特定の位置へのランダムアクセスと、比較的大きなデータを参照する際のシーケンシャルアクセスが混在することに着目して、圧縮対象データを所定のブロック単位に分割して圧縮した上で、目的のデータへのランダムアクセスを可能にしつつ、あるブロックを参照した際に後続のブロックをメモリに先読みすることで、シーケンシャルアクセス時の性能向上も図ったものである。

米国特許第４５５８３０２号明細書（第１５−２２頁、第２−３図） 米国特許第７７６９７２９Ｂ２号明細書（第２４−２５頁、第１０図） 特開２０１０−１６５１５１号公報（第４−５頁、第２図）

Ｂ．Ｒ．Ｉｙｅｒ、他１名 著，"Ｄａｔａ Ｃｏｍｐｒｅｓｓｉｏｎ Ｓｕｐｐｏｒｔ ｉｎ Ｄａｔａｂａｓｅｓ"，Ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ２０ｔｈ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｖｅｒｙ Ｌａｒｇｅ Ｄａｔａ Ｂａｓｅｓ（ＶＬＤＢ９４），（米国），１９９４，ｐ．６９５−７０４

しかしながら、上記の特許文献１、特許文献２、および特許文献３に記載の技術には、以下の問題がある。

まず、特許文献１等に記載のデータ圧縮技術は、データを参照する前に、圧縮されたデータを元に戻す処理（以下、解凍処理と記載する）が必要になる。この解凍処理には時間がかかるため、単純にデータを圧縮してしまうと、データを参照して各種のナビゲーションを行う際の性能が悪化するという問題がある。

また、特許文献２等に記載されているような、列方向にデータを圧縮する技術の場合、たしかに圧縮率は向上するが、データが列単位で圧縮されているため、１行のデータを取り出すためには全ての列を解凍しなければならないという性能上の問題がある。この問題は、二次元構造のデータを列方向に圧縮する際の本質的な問題であるが、特に次の特許文献３のように、使用するメモリのサイズが小さい場合に問題が顕著となる。

特許文献３に記載の技術は、あるブロックのデータを参照した際に後続のブロックをキャッシュメモリに先読みすることによりシーケンシャルアクセス時の性能向上を図るものであるが、この効果を期待できるのは、キャッシュメモリに記憶している内容が解凍処理の途中で置き換わらない場合に限定される。例えば、特許文献２に記載の技術のようにデータが列方向に圧縮されている場合、前述したように、１行のデータを取り出すためには全ての列を解凍する必要があり、この全ての列の解凍結果（すなわちデータの全体に相当する）を保持するために必要な領域のサイズはキャッシュメモリの容量を大幅に超過するため、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）が解凍結果を保持する領域を参照する際に、先読みした圧縮データはキャッシュメモリから削除されてしまう。その結果、圧縮データはキャッシュメモリからではなく主記憶装置やＨＤＤ等のより低速な記憶媒体から読み直されることになるため、先読みの効果は得られない。 以上述べたように、多数の固定長レコードの並びを含む大容量データの圧縮率を向上しつつ、解凍性能を向上することが求められている。

上記の課題を解決するため、本明細書では、複数の固定長レコードの並びを列方向に（複数レコードの同一列データを列毎に）圧縮する際、キャッシュメモリ容量等、解凍装置側の性能指標と１レコードのサイズに基づいて、１回の列方向圧縮において処理する行数を算出することにより、解凍装置の性能に合わせたデータ圧縮を行うことを最も主要な特徴とする技術が開示される。なお、以降では１列の幅を１バイトとして説明するが、本明細書で開示される技術は、列幅が1バイトより大きい場合にも応用可能である。

開示される具体的な例では、３２ＫＢのキャッシュメモリを有する解凍装置向けに、１レコードが１２バイトである固定長レコードの並びを圧縮する場合には、キャッシュメモリ３２ＫＢのうち半分の１６ＫＢを圧縮データ読み込み用として考え、この１６ＫＢに収まる最大のレコード数である１３６５レコード（＝６５５３６÷１２）を１回の列方向に圧縮する単位とする。これによって、圧縮データを解凍する際のキャッシュメモリの不要な更新が抑制され、解凍処理を高速に行うことが可能となる。

なお、上記は一例であり、１回の列方向圧縮を行うレコード数の算出方法としては、解凍装置のキャッシュメモリ容量の他、解凍装置が使用可能な主記憶装置の容量や、あるいは、解凍装置が通信ネットワークを介して圧縮データを受信する場合は、通信プロトコルによる１回の最大データ送信サイズを使用しても良い。

また、本明細書で開示される技術は、性能指標が異なる各種の解凍装置に対して通信ネットワークを介して配信サーバから圧縮データを配信するシステムにおいて、あらかじめ各解凍装置の性能に適合する複数の圧縮データを作成しておき、要求を行った解凍装置の性能に適合する圧縮データを選択して配信することを第二の特徴とする。例えば、データを閲覧する端末（本明細書で開示される解凍装置に相当）としては、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）の他に、携帯電話やスマートフォン等、性能が異なる各種の端末があり、これらの各端末においてそれぞれ解凍時間が最短となる圧縮データを配信することが可能となる。

なお、あらかじめ複数の圧縮データを作成しておくのではなく、あらかじめ作成された一種類の圧縮データを一旦解凍し、この解凍され復元されたデータを、圧縮データを要求する解凍装置固有の性能指標に応じて再圧縮して配信する構成としても良い。

以上の特徴を持つ技術として、本明細書では、複数の固定長レコードを含む圧縮対象データを圧縮するデータ圧縮装置であって、固定長レコードの１レコードのサイズと、データ解凍装置の仕様情報と、の入力を受け付ける単位サイズ設定部と、固定長レコードのサイズと、データ解凍装置の仕様情報と、に基づいて圧縮対象ブロックのサイズを決定し、各々の圧縮対象ブロックに含まれる複数の固定長レコードの同一列データを列毎に圧縮して圧縮列データを作成し、各々の圧縮列データを含む圧縮データを作成する列データ圧縮部と、を備えるデータ圧縮装置が開示される。

また、上記データ圧縮装置によって圧縮された複数の固定長レコードを含む圧縮データを解凍するデータ解凍装置として、圧縮データが、圧縮対象データが所定の圧縮対象ブロックサイズ単位で分割され、圧縮対象ブロック毎に圧縮された結果を含んだものであり、圧縮対象ブロックサイズが、固定長レコードのサイズと、当該データ解凍装置の仕様情報と、に基づいて決定されるものである場合に、固定長レコードのサイズと、データ解凍装置の仕様情報と、に基づいて圧縮対象ブロックのサイズを判定し、圧縮データから一以上の圧縮対象ブロックを取得し、圧縮対象ブロックに含まれる、複数の固定長レコードの同一列データを列毎に圧縮した結果である圧縮列データの各々を解凍し、複数の固定長レコードを復元する列データ解凍部と、を備えるデータ解凍装置が開示される。

開示される内容により、多数の固定長レコードの並びを含む大容量データの圧縮率を向上しつつ、解凍性能を向上することが可能となる。

ツリーデータ圧縮システムの全体構成を例示する図（実施例１）。 ツリーデータの１レコードの構造を例示する図（実施例１） 圧縮対象データ（元データ）を例示する図（実施例１） キャッシュメモリ１７０の構造を例示する説明図（実施例１）。 列方向圧縮時のキャッシュメモリの問題を例示する説明図（実施例１）。 圧縮データの構成を例示する図（実施例１）。 圧縮識別子の構成を例示する図（実施例１）。 列圧縮識別子の構成を例示する図（実施例１）。 圧縮定義ファイルの構成を例示する図（実施例１）。 圧縮データ作成画面を例示する図（実施例１）。 ブロックデータ圧縮部の動作を例示するフローチャート（実施例１）。 列データ圧縮部の動作を例示するフローチャート（実施例１）。 列方向圧縮処理の動作を例示するフローチャート（実施例１）。 アプリケーションソフトからの要求を例示する説明図（実施例１）。 ブロックデータ解凍部の動作を例示するフローチャート（実施例１）。 列データ解凍部の動作を例示するフローチャート（実施例１）。 列方向解凍処理の動作を例示するフローチャート（実施例１）。 キャッシュメモリ１７０の状態を例示する図（実施例１）。 走行履歴データ閲覧システムの全体構成を例示する図（実施例２）。 走行履歴データの１レコードの構造を例示する図（実施例２）。 圧縮対象データ（元データ）を例示する図（実施例２）。 記憶媒体の構成を例示する図（実施例２）。 圧縮データ（８ＫＢキャッシュ用）の構成を例示する図（実施例２）。 圧縮データ（１６ＫＢキャッシュ用）の構成を例示する図（実施例２）。 圧縮データ（３２ＫＢキャッシュ用）の構成を例示する図（実施例２）。 圧縮データ作成画面を例示する図（実施例２）。 ブロックデータ圧縮部の動作を例示するフローチャート（実施例２）。 各装置用の圧縮データ作成処理を例示するフローチャート（実施例２）。 圧縮データ送受信シーケンスを例示する図（実施例２）。 警告画面を例示する図（実施例２）。 別の形態の走行履歴データ閲覧システムの全体構成を例示する図（実施例３）。

以下、図１から図１８を用いて、実施例１のツリーデータ圧縮システムについて説明する。

実施例１は、カーナビに格納するデータベースにおいて多くの領域を占めている検索データ（以降、ツリーデータと呼ぶ）を圧縮し、カーナビのデータベースのサイズを削減するものである。実施例１においては、列方向データ解凍装置１００はカーナビに相当し、列方向データ圧縮装置２００は、カーナビの記憶媒体１５０に格納するデータを作成するための装置（パーソナルコンピューター等）に相当する。

図１は、実施例１のツリーデータ圧縮システムの機能構成を示したものである。本システムは、列方向データ解凍装置１００、列方向データ圧縮装置２００を含んで構成される。実施例１での圧縮対象であるツリーデータは、列方向データ圧縮装置２００において圧縮され、列方向データ解凍装置１００の記憶媒体１５０にコピーされる。列方向データ解凍装置１００では、アプリケーションソフトが、圧縮されたツリーデータを部分的に解凍しながら検索処理を実行する。

列方向データ解凍装置１００は、アプリケーションソフトを実行するアプリケーションソフト実行部１１０、ブロック単位で圧縮されたデータを解凍するブロックデータ解凍部１２０、列方向に圧縮されたデータを解凍する列データ解凍部１４０、圧縮データ５００を格納する記憶媒体１５０、主記憶装置１６０、およびキャッシュメモリ１７０を含んで構成される。

列方向データ圧縮装置２００は、圧縮定義ファイル７００を参照しながらブロック単位でデータを圧縮するブロックデータ圧縮部２２０、データ圧縮のパラメータを設定する単位サイズ設定部２３０、列方向にデータを圧縮する列データ圧縮部２４０、圧縮対象の元データ６００および圧縮データ５００を格納する記憶媒体２５０を含んで構成される。なお、実施例１とは直接の関係が無いため図示していないが、列方向データ圧縮装置２００においても、列方向データ解凍装置１００と同様、一連の処理を実行するための主記憶装置およびキャッシュメモリが存在する。

図１に示す各装置は、ＣＰＵと記憶装置とを備える一般的な計算機を用いて実現することができる。本実施例では、キャッシュメモリ１７０はＣＰＵの内部に備わり、主記憶装置１６０は半導体メモリで構成され、記憶媒体１５０はＨＤＤなどの磁気記録媒体や、主記憶装置１６０より低速で不揮発性のフラッシュメモリなどで構成されている、と想定している。

さらに、各装置を構成するそれぞれの処理部は、ＣＰＵが主記憶装置１６０や記憶媒体１５０に格納されているプログラムを実行することにより、上記計算機上に具現化される。各プログラムは、あらかじめ、上記計算機内の記憶装置に格納されていても良いし、必要なときに、入出力インタフェースと上記計算機が利用可能な媒体を介して、他の装置から上記記憶装置に導入されてもよい。媒体とは、たとえば、入出力インタフェースに着脱可能な記憶媒体、または通信媒体（すなわち有線、無線、光などのネットワーク、または当該ネットワークを伝搬する搬送波やディジタル信号）を指す。

図２は、圧縮対象のツリーデータのフォーマットおよびデータの例を示したものである。ツリーデータの１レコードは１２バイトで構成され、下位ノード（ツリーの子）のアドレス６０１（４バイト）、下位ノードのサイズ６０２（４バイト）、およびレコードの値６０３（４バイト）を格納している。図２に示すデータの例では、例えば１文字目が「Ａ」の場合、続く２文字目には「Ｂ」と「Ｄ」があり、「Ｂ」に続く３文字目には「Ｃ」「Ｅ」「Ｈ」が存在することを意味している。

このようなツリーデータは、一般的なカーナビが備えている目的地名称等を入力する画面（英数字等の各文字を示すボタンが画面に表示されている）において使用されるもので、「Ａ」が入力された時は「Ａ」で始まる名称の２番目の文字（すなわち「Ｂ」「Ｄ」等）のボタンは押下可能にするが他の文字は押下できないようにする等の制御を行い、ユーザーが検索を行い易くするためのデータである。

図３は、元データ６００に含まれるツリーデータの並びを１６進数で表記した例、および圧縮データ５００に含まれる列０２の圧縮データの例を記載したものである。ツリーデータの例は、理解し易いように、１レコードのサイズである１２バイト単位で改行して記載している。このようにデータが固定長レコードの並びで構成される場合、同一桁の値は特徴的なパターンを有することが多く、例えば列００および列０１の値は全て００になっている。列０２については、同じ値が複数連続しており、これをランレングス符号によって圧縮すると、０１、０１、０２、０４、０３、０６のようになる。この圧縮データの意味は、記号０１が１個、記号０２が４個、記号０３が６個連続するということを示している。なお、ランレングス符号は、記号と、その記号が連続する数を使ってデータを表現する圧縮方法であり、多数の文献で開示されているものである。

また、列０８および列０９は、ツリーデータの各ノードに対応する文字を、１文字が２バイトであるＵＮＩＣＯＤＥ（ＵＴＦ１６）で格納しており、１レコード目の「００４１」は文字「Ａ」に、２レコード目の「００４２」は文字「Ｂ」に対応する。使用する文字が英数字のみである場合、ＵＴＦ１６のコードでは、列０８（上位バイト）は全て００になる。

なお、図２および図３では、英数字による名称を持つ検索データの例を記載したが、本実施例は英数字を使用する場合に限るものではなく、日本語、ドイツ語、フランス語等、その他の言語の文字に対しても応用可能である。

ここで、本実施例の背景についての理解の一助とするため、このようにデータを列方向で圧縮する際の問題について図４および図５を用いて説明する。

図４は、近年、一般的に用いられている、セットアソシアティブと呼ばれる方式に基づいたキャッシュメモリ１７０の例を示したものである。一般的にキャッシュメモリ１７０は、一定サイズのデータ（これをラインと呼ぶ）を格納する複数の領域（これをエントリと呼ぶ）を含んで構成され、特にセットアソシアティブ方式とは、タグを用いて同一エントリに複数のラインを格納する方式である。同一エントリに格納できるラインの数をウェイ数と呼び、同一エントリに４つのラインを格納可能な場合を４ウェイセットアソシアティブ方式と呼ぶ。

図４は、１ラインサイズが３２バイトで、２５６エントリを有する、４ウェイセットアソシアティブ方式の例を記載したものであり、エントリとして仮想アドレスの第５ビット目から第１２ビット目に対応する８ビットを、タグとしてアドレスの第１３ビット目から第３１ビット目に対応する１９ビットを使用する方式の例である。図４の例では、ウェイ数（すなわち４個）の列を持つタグアレイ１７１とデータアレイ１７２を記載している。データアレイ１７２は、各エントリに格納している４つのラインを保持しているテーブルであり、タグアレイ１７１は、各エントリに対して、データアレイ１７２に格納されているデータがどのアドレスのものかを示すタグを格納するものである。

ここで、仮想アドレス（３２ビット値）０ｘ０００１２０４１に位置するデータへの参照が発生した場合を例に、キャッシュメモリ１７０の動作を説明する。まず、仮想アドレスの第５ビット目から第１２ビット目に格納されている８ビットの値からエントリを決定する（ステップＳ１７０１）。第５ビット目から第１２ビット目に格納されている値は２進数表現で００００００１０、すなわち１０進数の２であり、データがキャッシュメモリ１７０上にある場合はエントリ２に格納されていることを意味する。

次に、仮想アドレスの第１３ビット目から３１ビット目に格納されている１９ビット（タグ）を、タグアレイ１７１のエントリ２に含まれる４つのタグと比較する（ステップＳ１７０２）。例の場合、エントリ２、ウェイ３に同一のタグが格納されており、このことから、エントリ２のウェイ３に仮想アドレス０ｘ０００１２０４１を含むラインのデータが保持されていることが識別される。この状態がいわゆるキャッシュにヒットした状態であり、ＣＰＵは主記憶装置１６０にアクセスすることなく、高速なキャッシュメモリ１７０からの出力で処理を完了することができる（ステップＳ１７０３）。

一方で、タグアレイ１７１を参照した結果、仮想アドレスと一致するタグが見つからない場合がいわゆるキャッシュミスヒットであり、主記憶装置１６０からデータが読み込まれることになる。この場合、一般的に用いられる方式としては、エントリ２に含まれる４つのラインのうち、ＬＲＵ（Ｌｅａｓｔ Ｒｅｃｅｎｔｌｙ Ｕｓｅｄ）方式によって、最近最も参照されていないラインがキャッシュメモリ１７０から削除され、その場所に新たに主記憶装置１６０から読み込まれたラインが格納される。このようなラインの入れ替えが頻繁に発生すると、ＣＰＵによるデータへのアクセス性能が著しく低下することになる。

図５は、図４で示したキャッシュメモリ１７０に対して、１レコード１２バイトの固定長レコードの並びを列方向に参照した場合の問題の例を記載したものである。「＃ｎ」を含む四角形は１レコード（１２バイト）を意味するもので、ｎはレコードの参照順序である。黒い四角形は、列００（１バイト）の場所を示したものであり、各レコードの先頭に位置している。図には、１３６６番目のレコードを参照した時点でウェイ１およびウェイ２に保持されている内容を記載している。例えばウェイ１のエントリ０には、レコード＃１（１２バイト）、＃２（１２バイト）、およびレコード＃３の先頭８バイトが格納されている。続くエントリ１には、レコード＃３の続きである４バイト、レコード＃４（１２バイト）、＃５（１２バイト）、およびレコード＃６の先頭４バイトが格納されている。以降のエントリも同様である。

ここで、キャッシュメモリ１７０を構成する４ウェイのうち、元データを保持するのに使用できるウェイ数を２個とした場合、レコード＃１３６７の列００を参照した時点でキャッシュミスヒットとなり、ＬＲＵによって、エントリ０のウェイ１が、＃１３６７の列００を含むデータで置き換えられる。同様に、続く各エントリのデータも順次置き換えられていく。その後、各レコードの列００を参照する処理が終わり、列０１を参照する処理が開始される際、再びレコード＃１がキャッシュメモリ１７０に読み込まれる。すなわち、レコード＃１について言えば、列００（１バイト）が処理されたのち、１２バイトのうち残り１１バイトは何ら参照されることなくキャッシュメモリ１７０から削除され、
次に列０１の処理においても残り１０バイトは何ら参照されることなくキャッシュメモリ１７０から削除されており、キャッシュの利用効率が著しく悪いことになる。

なお、ウェイは４個あるため、実際はウェイ３およびウェイ４も使用されることになるが、ＣＰＵが参照するデータには、解凍された各レコードの他に、解凍する前の圧縮データや、圧縮解凍アルゴリズムが使用する作業領域があるため、解凍された各レコードの保持だけに全てのウェイを使用することは出来ない。また、仮に全てのウェイを使用できたとしても、格納できるレコード数が高々２倍になるだけであり、問題の本質的な解決にはならない。

以上の問題を踏まえて、以降、実施例１の詳細を説明する。

図６は、実施例１における圧縮データ５００のフォーマットを記載したものである（括弧内の数値は圧縮前のサイズを意味する）。圧縮データ５００は、元データを所定のサイズ（図では６４ＫＢ）のブロックに分割して圧縮を行ったもので、各ブロックの開始アドレスを示すインデックスデータ５０１、および圧縮対象である各ブロックの並びであるブロックデータの並び５０２を含んで構成される。

ブロックの詳細５０３は、各ブロックに含まれる圧縮対象データを記載したものであり、圧縮識別子、レコード長、サブブロックの並び、および余りデータで構成される。サブブロックは、上記で説明した問題が発生しないサブブロックサイズでブロックを分割して圧縮対象ブロックとしたものであり、図では各ブロックを１６３８０バイト（レコード数１３６５個に相当するサイズ）毎に分割した圧縮対象ブロックを圧縮したデータであり、余りデータは、サブブロックサイズ（ここでは１６３８０バイト）で割り切れない余りデータ（ここでは１６バイト）である。

サブブロックの詳細５０４は、各サブブロックに含まれるデータを記載したものであり、複数の列圧縮識別子および列圧縮データを含んで構成される。例えば列００圧縮データは、１３６５個のレコードにおける列００の値を圧縮したものであり、元のデータサイズは１３６５バイトである。

図７は、ブロックの詳細５０３に含まれる圧縮識別子１２２の値を記載したものである。圧縮識別子１２２は、各ブロックを圧縮する際の方式を示すもので、００（非圧縮）、０１（列方向圧縮）、０２（行方向圧縮）が定義される。００（非圧縮）は、圧縮対象のブロックに含まれるデータに何ら規則性がなく、圧縮してもサイズ削減効果を得られない場合に使用する識別子であり、０１（列方向圧縮）は列方向で圧縮した場合にサイズ削減効果を得られる場合に使用する識別子であり、０２（行方向圧縮）は行方向、すなわち通常どおりデータを先頭から１バイトずつ処理したほうがサイズ削減効果を得られる場合に使用する識別子である。

図８は、サブブロックの詳細５０４に含まれる列圧縮識別子１４２の値を記載したものである。列圧縮識別子１４２は、圧縮対象の各列を圧縮する際の方式を示すもので、００（非圧縮）、０１（ランレングス符号）、０２（固定長ビット符号）、０３（ハフマン符号）等を定義する。００（非圧縮）は、圧縮対象の列に含まれるデータに何ら規則性がなく、圧縮してもサイズ削減効果を得られない場合に使用する識別子であり、０１（ランレングス符号）は圧縮対象の列に含まれるデータに対してランレングス符号による圧縮を行うことによりサイズ削減効果を得られる場合に使用する識別子である。０２（固定長ビット符号）、０３（ハフマン符号）についても同様で、それぞれの方式によってサイズ削減効果を得られる場合に使用する識別子である。

なお、固定長ビット符号とは、例えば８ビットの記号を圧縮する際、元データに含まれる記号が高々１６個しか存在しない場合に、１６個を表現可能な４ビットの符号に置換して出力することによりデータサイズを削減する方式である。また、ハフマン符号とは、記号の出現確率を求めて最小冗長符号を出力することによりデータサイズを削減する方式である。実施例１は、各列の圧縮を行う際、最もサイズ削減効果が高い圧縮方法を選択して使用するものであり、一般的に使用されている技術をそのまま利用することを想定しているため、各圧縮方法の詳細については特に記載しない。

図９は、ブロックデータ圧縮部２２０がデータを圧縮する際に参照する圧縮定義ファイル７００について記載したものである。圧縮定義ファイル７００には、開始アドレス７０１、圧縮識別子７０２、レコード長７０３が記載されている。一般的に、カーナビのデータベースにおいて、１つのファイルに含まれるデータがすべて同一のサイズを有する固定長レコードの並びであることは稀であり、固定長レコードの並びの他に、何ら規則性が無いデータや、通常のテキストデータのように列方向の圧縮に適さないデータも含まれる。 図９は、アドレス０ｘ００００００００からは１レコード１２バイトである固定長レコードの並びが格納されており、同様に、アドレス０ｘ００１Ａ００００からは何ら規則性が無いデータが、アドレス０ｘ００１Ｂ００００からは１レコード８バイトである固定長レコードの並びが、アドレス０ｘ００３０００００からはテキストデータが、アドレス０ｘ００３１００００からは何ら規則性が無いデータが格納されている様子を示している。圧縮定義ファイルは、これらの格納状況を踏まえ、ブロックデータ圧縮部２２０がデータを圧縮する際、各ブロックに適用する圧縮方法を決定するために使用される。

以降、ツリーデータを圧縮してカーナビに格納し、カーナビにおいて圧縮されたツリーデータを参照する際の処理の流れに沿って、実施例１を説明する。

図１０は、列方向データ圧縮装置２００を用いてツリーデータを圧縮する際、単位サイズ設定部２３０が表示する単位サイズ設定画面２３１を示したものである。単位サイズ設定画面２３１には、対象ファイル２３２、圧縮定義ファイル２３３、ブロックサイズ２３４、および端末キャッシュ容量２３５を入力する欄が存在する。対象ファイル２３２は、記憶媒体２５０上で元データ６００が位置する場所を入力する欄、圧縮定義ファイル２３３は、記憶媒体２５０上で圧縮定義ファイル７００が位置する場所を入力する欄、ブロックサイズ２３４は図６に示した各ブロックのサイズ（圧縮前のサイズ）を入力する欄、端末キャッシュ容量２３５は、列方向データ解凍装置１００が備えるキャッシュメモリ１７０の容量を入力する欄である。これらのパラメータを入力し、ＯＫボタン２３９を押下することで圧縮処理が開始される。

図１１は、ＯＫボタン２３９が押下された後の、ブロックデータ圧縮部２２０の動作を示すフローチャートである。ブロックデータ圧縮部２２０は、まず、対象ファイル２３２に入力されたファイル（元データ）のサイズを取得する（ステップＳ２２０１）。

次に、ブロックサイズ２３４に入力されたブロックサイズをもとに、元データに含まれるブロック数を計算する（ステップＳ２２０２）。例えば、元データのサイズが６７５８８０９６バイト、ブロックサイズが６４ＫＢ（６５５３６バイト）の場合、ブロック数は、６７５８８０９６を６５５３６で割った値（小数点以下切り上げ）であり、１０３２になる。なお、１０３２番目のブロックのサイズは、６５５３６で割り切れない２０４８０バイトになる。

次に、ブロック毎に繰り返されるループ処理のカウンタ変数ｉを０に初期化する（ステップＳ２２０３）。

次に、変数ｉが、ステップＳ２２０２で求めたブロック数未満であるかどうかを判定する（ステップＳ２２０４）。変数ｉがブロック数未満である場合、インデックスデータ５０１に、ブロックデータの並び５０２における処理中のブロックの開始アドレス（オフセットデータ）を出力する（ステップＳ２２０５）。

次に、圧縮定義ファイル７００を参照して、処理中のブロックを圧縮する際に使用する圧縮識別子およびレコード長を取得する（ステップＳ２２０６）。これは、圧縮定義ファイルの各行を走査し、処理中のブロックのアドレスに対応する圧縮識別子およびレコード長を取得することにより行われる。

次に、ブロックデータの並び５０２に、取得した圧縮識別子およびレコード長を出力する（ステップＳ２２０７）。

次に、圧縮識別子に応じて処理を分岐させる（ステップＳ２２０８）。圧縮識別子が００（非圧縮）の場合、元データの内容（ブロック１からブロック１０３１の場合は６４ＫＢ、ブロック１０３２の場合は２０４８０バイト）をそのままブロックデータの並び５０２に出力する（ステップＳ２２０９）。圧縮識別子が０１（列方向圧縮）の場合、列方向の圧縮を行う（ステップＳ２２１０）。列方向圧縮の詳細については後述する。圧縮識別子が０２（行方向圧縮）の場合は、元データを行方向に圧縮（Ｚｌｉｂ等の公知の圧縮アルゴリズムを使用）して、圧縮データをブロックデータの並び５０２に出力する（ステップＳ２２１１）。以上の３ステップのいずれかが完了した後、カウンタ変数ｉを１加算して、ステップＳ２２０４に戻る（ステップＳ２２１２）。以上のステップＳ２２０４からステップＳ２２１２までの処理を全てのブロックに対して繰り返し、ステップＳ２２０４において変数ｉがブロック数に等しくなった時点で、データの圧縮処理を終了し、圧縮データ５００として記憶媒体２５０に格納する。

図１２は、図１１のステップＳ２２１０で実行される、列データ圧縮部２４０の動作を示すフローチャートである。列データ圧縮部２４０は、まず、端末キャッシュ容量２３５に入力されたキャッシュメモリ容量、および圧縮定義ファイルから取得されたレコード長をもとに、サブブロックサイズを計算する（ステップＳ２４０１）。例えば、キャッシュメモリ容量が３２ＫＢ、１レコードのサイズが１２バイトの場合、３２ＫＢのうち半分（１６ＫＢ）が解凍後のデータ保持に使用可能であると想定して、１６ＫＢに格納できる最大のレコード数のサイズがサブブロックサイズになる。すなわち、１６ＫＢ÷１２バイト＝１６３８０バイト（余り４バイト）がサブブロックサイズとなる。

次に、ブロックサイズ２３４に入力されたブロックサイズと、ステップＳ２４０２で求めたサブブロックサイズから、サブブロック数と余り領域のサイズを計算する（ステップＳ２４０２）。ブロックサイズが６５５３６バイト、サブブロックサイズが１６３８０バイトであるので、サブブロック数は４、余り領域のサイズは１６バイトとなる。

次に、サブブロック毎に繰り返されるループ処理のカウンタ変数ｊを０に初期化する（ステップＳ２４０３）。

次に、変数ｊがサブブロック数未満であるかどうかを判定する（ステップＳ２４０４）。変数ｊがサブブロック数未満である場合、レコードの各桁に対して繰り返されるループ処理のカウンタ変数ｋを０に初期化する（ステップＳ２４０５）。

次に、変数ｋがレコード長未満であるかどうかを判定する（ステップＳ２４０６）。変数ｋがレコード長未満である場合、列ｋの圧縮処理を行う（ステップＳ２４０８）。列ｋの圧縮処理については後述する。

次に、カウンタ変数ｋを１加算してステップＳ２４０６に戻る（ステップＳ２４０９）。

以上のステップＳ２４０６からステップＳ２４０９までの処理を全ての列に対して繰り返し、ステップＳ２４０６において変数ｋがレコード長に等しくなった時点で、カウンタ変数ｊを１加算して、ステップＳ２４０４に戻る（ステップＳ２４０７）。

以上の処理を各サブブロックに対して繰り返し、ステップＳ２４０４において変数ｊがサブブロック数に等しくなった時点で、残りの入力データ（すなわちステップＳ２４０２において算出した余り領域のサイズ分のデータ）を、ブロックデータの並び５０２にそのまま出力して、列データの圧縮処理を終了する（ステップＳ２４１０）。

図１３は、図１２のステップＳ２４０８で実行される、列ｋの圧縮処理を示すフローチャートである。まず、列ｋの圧縮に使用する列圧縮識別子を決定する（ステップＳ２４２１）。この処理は、列ｋに含まれる記号の出現頻度をカウントすることにより、００（非圧縮）、０１（ランレングス符号）、０２（固定長ビット符号）、０３（静的ハフマン符号）のどの方式を用いれば圧縮後のサイズが最も小さくなるかを計算することにより行う。

次に、圧縮処理に使用する変数ｎ、ｐＳｒｃ、ｐＤｅｓｔを初期化する（ステップＳ２４２２）。変数ｎは、処理済み入力データサイズ（バイト数）を示す変数であり、０に初期化する。変数ｐＳｒｃは、元データのアドレスを示す変数であり、列ｋのデータの先頭アドレスで初期化する。変数ｐＤｅｓｔは、圧縮データの出力先アドレスで初期化する。 次に、変数ｎが列ｋのサイズ（すなわち１３６５）未満であるかどうかを判定する（ステップＳ２４２３）。変数ｎが列ｋのサイズ未満である場合、変数ｐＳｒｃが示すアドレスに存在する１バイトを、列圧縮識別子が示す方式でエンコードし、変数ｐＳｒｃをレコード長だけ加算、および変数ｎを１加算する（ステップＳ２４２４）。エンコードされた結果が1バイト未満、かつ変数ｎが列ｋのサイズ未満である場合、ステップＳ２４２４に戻る。エンコードされた結果が１バイトになるか、または変数ｎが列ｋのサイズに等しい場合，ステップＳ２４２６へ進む（ステップＳ２４２５）。

ｐＳｒｃによって示される１バイト以上の記号が、１バイトにエンコードされた時点で、エンコードされた値（１バイト）をｐＤｅｓｔが示すアドレスに出力するとともに、ｐＤｅｓｔの値を１加算して、ステップＳ２４２３に戻る（ステップＳ２４２６）。以上のステップＳ２４２３からステップＳ２４２６までの処理を列ｋに含まれる記号の数だけ繰り返した結果、変数ｎの値が列ｋのサイズに等しくなった時点で、列ｋの圧縮処理を終了する。

以上の図１１から図１３を用いて説明したブロックデータ圧縮部２２０および列データ圧縮部２４０の動作によって、図６に示した圧縮データ５００が作成される。このようにして作成された圧縮データ５００は、列方向データ解凍装置１００の記憶媒体１５０にコピーされ、アプリケーションソフトによって使用される。

図１４は、実施例１における、アプリケーションソフト実行部１１０からブロックデータ解凍部１２０へ要求されるデータ取得要求の例を示したものである。この例では、アドレス０ｘ０００１００００から始まる１００ＫＢのデータを参照する様子を示している。以降、この要求に対する列方向データ解凍装置１００の動作に沿って説明する。

図１５は、アプリケーションソフト実行部１１０からデータ取得要求を受けた際の、ブロックデータ解凍部１２０の動作を示すフローチャートである。ブロックデータ解凍部１２０は、まず、要求されたアドレスおよび要求サイズをもとに、対象のブロック範囲を計算する（ステップＳ１２０１）。図１４に示した要求の場合、アドレス０ｘ０００１００００から始まる１００ＫＢを含むブロックであるブロック２からブロック３が対象ブロックの範囲となる。

次に、対象ブロックの範囲から１ブロック分の圧縮データを記憶媒体１５０から読み込み、主記憶装置１６０に格納する（ステップＳ１２０２）。この処理は、インデックスデータ５０１が示すブロック２の開始アドレス０ｘ００００１５２０から、ブロック２の終了アドレス（次のブロック３の開始アドレスから１を減算した値）である０ｘ００００５０４３までを読み込むことにより行われる。

次に、読み込まれたブロックの先頭から、圧縮識別子およびレコード長を取得する（ステップＳ１２０３）。

次に、取得した圧縮識別子に応じて処理を分岐する（ステップＳ１２０４）。圧縮識別子が００（非圧縮）の場合、主記憶装置１６０に格納したブロックデータをそのままアプリケーションソフトに渡す（ステップＳ１２０５）。圧縮識別子が０１（列方向圧縮）の場合、主記憶装置１６０に格納したブロックデータに対して列方向解凍処理を行う（ステップＳ１２０６）。列方向解凍処理の詳細は後述する。

圧縮識別子が０２（行方向圧縮）の場合、主記憶装置１６０に格納したブロックデータに対して行方向の解凍処理（Ｚｌｉｂ等の公知の圧縮アルゴリズムを使用）を行い、解凍し復元した結果を主記憶装置１６０に格納してアプリケーションソフトに渡す（ステップＳ１２０７）。

以上の３ステップのいずれかが実行されたのち、対象ブロックの範囲に含まれる全てのブロックの解凍処理が完了したかどうかを判定し、まだ解凍されていないブロックがある場合はステップＳ１２０２に戻る（ステップＳ１２０８）。

Ｓ１２０２に戻った後の処理は上記と同様であり、ブロック３のデータに対しては、インデックスデータ５０１の内容からブロック３の格納アドレス（０ｘ００００５０４４から０ｘ００００８２１２）を取得し、ブロック３のデータを読み込み、解凍処理を行う。以上の処理を繰り返した結果、ステップＳ１２０８において全てのブロックの解凍が完了したと判定された場合、ブロックデータの解凍処理を終了する。

図１６は、図１５のステップＳ１２０６で実行される、列データ解凍部１４０の動作を示すフローチャートである。列データ解凍部１４０は、まず、キャッシュメモリ１７０の容量から、サブブロックサイズを計算する（ステップＳ１４０１）。この計算処理は、列方向データ圧縮装置２００におけるサブブロックサイズの計算処理と同一の計算式によってなされる。すなわち、キャッシュメモリ容量が３２ＫＢ、１レコードのサイズが１２バイトの場合、３２ＫＢのうち半分（１６ＫＢ）が解凍後のデータ保持に使用可能であると想定して、１６ＫＢに格納できる最大のレコード数のサイズ（１６３８０バイト）がサブブロックサイズになる。

次に、処理中のブロックに含まれるサブブロック数および余りサイズを計算する（ステップＳ１４０２）。この計算処理も、列方向データ圧縮装置２００におけるサブブロック数の計算処理と同一であり、サブブロック数は４、余りサイズは１６バイトになる。

次に、各サブブロックに対して繰り返されるループ処理のカウンタ変数ｊを０に初期化する（ステップＳ１４０３）。

次に、変数ｊがサブブロック数未満であるかどうかを判定する（ステップＳ１４０４）。変数ｊがサブブロック数未満である場合、各列に対して繰り返されるループ処理のカウンタ変数ｋを０に初期化する（ステップＳ１４０５）。

次に、変数ｋがレコード長未満であるかどうかを判定する（ステップＳ１４０６）。変数ｋがレコード長未満である場合、列ｋのデータを解凍する（ステップＳ１４０８）。列ｋの解凍処理の詳細は後述する。

次に、カウンタ変数ｋを１加算して、ステップＳ１４０６に戻る（ステップＳ１４０９）。ステップＳ１４０６からステップＳ１４０９の処理を各列に対して繰り返した結果、変数ｋがレコード長に等しくなった場合は、カウンタ変数ｊを１加算して、ステップＳ１４０４に戻る（ステップＳ１４０７）。

以上の処理を各サブブロックに対して繰り返した結果、変数ｊの値がサブブロック数に等しくなった場合は、余り領域をそのままアプリケーションソフトに返却する（ステップＳ１４１０）。

図１７は、図１６のステップＳ１４０８において実行される、列ｋのデータの解凍処理を示すフローチャートである。まず、圧縮データの先頭から、列圧縮識別子を取得する（ステップＳ１４２１）。

次に、解凍処理に用いる変数ｎ、ｐＳｒｃ、ｐＤｅｓｔを初期化する（ステップＳ１４２２）。変数ｎは、出力したデータサイズ（バイト数）を示す変数であり、０に初期化される。変数ｐＳｒｃは、圧縮データの格納アドレスを示す変数であり、圧縮データの先頭アドレス、または、直前の列ｋ−１の解凍が終了した時点でのｐＳｒｃの値に初期化される。変数ｐＤｅｓｔは、列ｋの場合、解凍データ出力先の先頭アドレス＋ｋ（列幅が１バイトの場合）に初期化される。

次に、変数が列ｋのサイズ（すなわち１３６５）未満であるかどうかを判定する（ステップＳ１４２３）。

変数ｎが列ｋのサイズ未満である場合、変数ｐＳｒｃが示すアドレスに存在する１バイトを列圧縮識別子が示す方式でデコードし、変数ｐＳｒｃを１加算する（ステップＳ１４２４）。

通常、１バイトからは１以上のバイト数のデータがデコードされるため、変数ｐＤｅｓｔの位置にデコードされた１バイトを出力し、ｐＤｅｓｔの値をレコード長だけ加算するとともに、変数ｎを１加算する処理を繰り返す（ステップＳ１４２５）。

圧縮データ１バイトからデコードされる複数のバイトの出力が完了した後、ステップＳ１４２３に戻る（ステップＳ１４２６）。

以上のステップＳ１４２３からステップＳ１４２６までの処理を繰り返した結果、変数ｎの値が列ｋのサイズに等しくなった場合は、列ｋのデータの解凍処理を終了する。

以上の図１５から図１７で説明したブロックデータ解凍部１２０および列データ解凍部１４０の動作によって、アプリケーションソフト実行部から要求された位置にある圧縮データの解凍が行われる。

以上が、実施例１のツリーデータ圧縮システムにおけるデータ圧縮処理およびデータ解凍処理の流れである。なお、図１８は、実施例１による圧縮データの解凍処理における、キャッシュメモリ１７０の状態を示したものである。列００の参照によってレコード＃１からレコード＃１３６５までがキャッシュメモリ１７０に格納される状態は図５と同一であるが、レコード＃１３６５まで処理した後に、列０１の解凍処理を実行するため、キャッシュメモリ１７０上のエントリ０の内容は置き換わらない。すなわち、図１６および図１７に示した処理の実行において、キャッシュメモリ１７０の不要な更新が抑制されるため、圧縮されたデータを高速に解凍することが可能となる。

以下、図１９から図３０を用いて、実施例２の走行履歴データ閲覧システムについて説明する。実施例２は、カーナビの走行履歴データをセンタ装置に収集し、各種の端末から参照可能にするものである。走行履歴とは、カーナビの現在地の座標を１秒等の所定の時間毎に記録したデータであり、カーナビで不具合が発生した時の状況確認に役立つほか、近年では、ユーザーがセンタ装置にアップロードした走行履歴を用いて、地図上に走行経路を重畳描画して旅の思い出作りを支援するといったサービスも提供されている。

なお、走行履歴データを収集する方法としては、ＳＤカード等の外部記録媒体をカーナビに接続して出力する、携帯電話等の通信装置をカーナビに接続して通信ネットワーク経由でセンタ装置へアップロードする、ディーラーにおいて保守端末を用いてカーナビから取り出す等の方法が用いられているが、本実施例では、この走行履歴をセンタ装置に収集する方法については特に記載せず、センタ装置に走行履歴が収集されていることを前提に、圧縮された走行履歴を各種の端末に配信する方法について説明する。

以降、実施例１との差異を中心に実施例２を説明する。実施例２において、列方向データ解凍装置１００は走行履歴を閲覧する端末、列方向データ圧縮装置２００は、圧縮された走行履歴データを配信するセンタ装置に相当する。

図１９は、実施例２における走行履歴データ閲覧システムの全体構成図である。実施例２の全体構成図は、図１に示した実施例１の全体構成図と比較して、圧縮データ要求部１８０および圧縮データ選択部２８０が追加されている。また、記憶媒体２５０には複数の圧縮データ５１０から５３０が格納されている。また、実施例１で記載した圧縮定義ファイル７００は存在しない。これは、走行履歴データは８バイトの固定長レコードで構成されていることを想定しており、ブロック毎に圧縮方法を切り替える必要性が無いためである。

図２０は、走行履歴データのフォーマットおよびデータの例を示したものである。走行履歴データの１レコードは、Ｘ座標（４バイト）およびＹ座標（４バイト）によって構成される。走行履歴データは、車両が走行中に所定のサイクルで収集したＸＹ座標の並びによって構成されており、図では、例として１０地点の座標の並びを示している。

図２１は、元データ６１０に含まれる走行履歴データの並びを１６進数で表記した例、および圧縮データ５１０に含まれる列００の圧縮データの例を記載したものである。走行履歴データの例は、理解し易いように、１レコードのサイズである８バイト単位で改行して記載している。ここで着目すべき内容は、Ｘ座標およびＹ座標のそれぞれについて、４バイトを使用するほどの大きな数値が格納されることは滅多に無いため、上位バイトはほとんど０または１等の小さな値になっている点である。したがって、実施例１で記載したツリーデータと同様に、列方向にデータを圧縮することで圧縮率の向上を期待できる。

図２２は、記憶媒体２５０に格納される、圧縮データ５１０から５３０を示したものである。圧縮データ５１０はキャッシュメモリ容量が８ＫＢである列方向データ解凍装置用の圧縮データ、圧縮データ５２０はキャッシュメモリ容量が１６ＫＢである列方向データ解凍装置用の圧縮データ、圧縮データ５３０はキャッシュメモリ容量が３２ＫＢである列方向データ解凍装置用の圧縮データである。

図２３は、キャッシュメモリ容量が８ＫＢである列方向データ解凍装置用の圧縮データ５１０の詳細を示したものである（括弧内の数値は圧縮前のサイズを意味する）。キャッシュメモリ容量８ＫＢの半分である４ＫＢに格納可能なレコード数（１レコードのサイズは８バイト）は５１２レコードであり、したがってサブブロックのサイズは５１２レコード×８バイトである４０９６バイトになる。サブブロックに含まれる各列のサイズは、５１２バイトになる。

図２４は、キャッシュメモリ容量が１６ＫＢである列方向データ解凍装置用の圧縮データ５２０の詳細を示したものである（括弧内の数値は圧縮前のサイズを意味する）。キャッシュメモリ容量１６ＫＢの半分である８ＫＢに格納可能なレコード数（１レコードのサイズは８バイト）は１０２４レコードであり、したがってサブブロックのサイズは１０２４レコード×８バイトである８１９２バイトになる。サブブロックに含まれる各列のサイズは、１０２４バイトになる。

図２５は、キャッシュメモリ容量が３２ＫＢである列方向データ解凍装置用の圧縮データ５３０の詳細を示したものである（括弧内の数値は圧縮前のサイズを意味する）。キャッシュメモリ容量３２ＫＢの半分である１６ＫＢに格納可能なレコード数（１レコードのサイズは８バイト）は２０４８レコードであり、したがってサブブロックのサイズは２０４８レコード×８バイトである１６３８４バイトになる。サブブロックに含まれる各列のサイズは、２０４８バイトになる。

なお、圧縮データ５１０から５３０のいずれも、キャッシュメモリ容量がレコードサイズの倍数となっているため、図６に存在している余り領域は存在しない。

以降、走行履歴データを配信する流れに沿って、実施例２を説明する。

図２６は、列方向データ圧縮装置２００を用いて走行履歴データを圧縮する際、単位サイズ設定部２３０が表示する単位サイズ設定画面２３８を示したものである。単位サイズ設定画面２３８には、実施例１と同様に、対象ファイル２３２、ブロックサイズ２３４を入力する欄がある。実施例１との差異は、レコード長２３６およびサポートするキャッシュメモリ容量を指定するボタン２３７が追加されており、また、圧縮定義ファイル７００を入力する欄は存在しない点である。サポートするキャッシュメモリ容量を指定するボタン２３７は、走行履歴データを閲覧する列方向データ解凍装置のキャッシュメモリ容量を指定するものであり、例では、キャッシュメモリ１７０のサイズが、それぞれ８ＫＢ、１６ＫＢ、および３２ＫＢである複数の端末用の圧縮データを作成する設定を示している。 図２７は、単位サイズ設定画面２３８においてＯＫボタン２３９が押下された後の、ブロックデータ圧縮部２２０の動作を示すフローチャートである。ブロックデータ圧縮部２２０は、まず、単位サイズ設定画面２３８に入力された、サポートするキャッシュメモリ容量の種別を取得する（ステップＳ２２２１）。

次に、指定されたすべてのキャッシュメモリ容量の種別分の圧縮データを作成したかどうかを判定し（ステップＳ２２２２）、作成が完了していない場合は、未作成である圧縮データを作成する（ステップＳ２２２３）。ステップＳ２２２３において実行される圧縮データ作成の流れは、実施例１の図１１に示した内容と同一である。

以上の動作によって、キャッシュメモリ１７０の容量が異なる各列方向データ解凍装置用の圧縮データが作成される。

図２８は、アプリケーションソフト実行部１１０からデータを要求された時の、ブロックデータ解凍部１２０の動作を示すフローチャートである。図２８は、実施例１の図１５とほぼ同様であるが、一連の処理の開始の前に圧縮データ取得処理初期化を行う点と（ステップＳ１８１０）、１ブロック分のデータを取得する処理が通信ネットワーク経由になっている点が異なる（ステップＳ１８２０）。

図２９は、図２８のステップＳ１８１０およびステップＳ１８２０において実行される、圧縮データ要求部１８０と圧縮データ選択部２８０の間における、圧縮データ取得処理初期化と、１ブロック分のデータを受信する処理の流れを示したものである。ステップＳ１８１０においては、まず、圧縮データ要求部１８０から圧縮データ選択部２８０へ、対象ファイルの名称が送信される（ステップＳ１８１１）。これを受けて、圧縮データ選択部２８０から圧縮データ要求部１８０へ、対象ファイルについてサポートしているキャッシュメモリ容量が通知される（ステップＳ１８１２）。実施例２の場合、対象ファイルについて、８ＫＢ、１６ＫＢ、および３２ＫＢのキャッシュメモリ容量を有する列方向データ解凍装置向けの圧縮データを送信可能であることが通知される。これを受けて、圧縮データ要求部１８０から圧縮データ選択部２８０へ、キャッシュメモリ１７０の容量が通知される（ステップＳ１８１３）。これを受けて、圧縮データ選択部２８０から圧縮データ要求部１８０へ、指定された圧縮データを送信可能な状態になったことが通知される（ステップＳ１８１４）。

なお、ステップＳ１８１２において、圧縮データ選択部２８０から通知されたキャッシュメモリ容量の中に、キャッシュメモリ１７０の容量と合致するものがなければ、圧縮データ要求部１８０は警告を表示する。図３０は、この警告を表示するアプリケーションソフト実行画面１１１の例を示したものであり、受信した圧縮データがこの列方向データ解凍装置にとって最適なものではないことをユーザーに伝えるメッセージ１１２を記載したものである。実施例２では、このような場合でも解凍性能が低下するだけで解凍処理自体を続行することは可能のため、圧縮データ要求部１８０はそのまま処理を続行することを想定しているが、ここで処理を停止するとしても良い。

図２９のステップＳ１８２１以降は、図２８のステップＳ１８２０における、１ブロック分の圧縮データを送受信する流れを示したものであり、まず、圧縮データ要求部１８０から圧縮データ選択部２８０へ、必要なブロックの番号が送信される（ステップＳ１８２１）。これを受けて、圧縮データ選択部２８０から圧縮データ要求部１８０へ、指定されたブロック番号に対応するブロックの圧縮データが送信される（ステップＳ１８２２）。圧縮データ要求部１８０は、受信したブロックをブロックデータ解凍部１２０に渡し、実施例１と同様の手順で解凍処理が行った上で、解凍したデータをアプリケーションソフトに渡す。以降のブロックについても同様である。

以上が、実施例２の走行履歴データ閲覧システムにおけるデータ圧縮処理およびデータ解凍処理の流れである。このように、性能が異なる各種の端末向けにあらかじめ複数の圧縮データを用意しておくことで、各端末にとって最も高速にデータを閲覧可能となる圧縮データを提供することが可能となる。

以下、図３１を用いて、実施例２とは別の形態の走行履歴データ閲覧システムについて説明する。

図３１は、実施例３における走行履歴データ閲覧システムの全体構成図である。実施例３の全体構成図は、図１９に示した実施例２の全体構成図と比較して、ブロックデータ再圧縮部２９１、列データ再圧縮部２９２、ブロックデータ解凍部２９３、列データ解凍部２９４、主記憶装置２６０、キャッシュメモリ２７０が追加されている。また、記憶媒体２５０に格納する圧縮データは、圧縮データ５４０の１つである。また、圧縮データ選択部２８０は存在しない。

以降、走行履歴データを圧縮して配信する際の処理の流れに沿って、実施例３を説明する。

実施例３における走行履歴データの圧縮処理は、実施例２と基本的に同様である。ただし、作成される圧縮データは、圧縮データ５４０の１つであり、このデータは、列方向データ圧縮装置２００自身が備えるキャッシュメモリ２７０にとってもっとも解凍性能が高い圧縮データである。すなわち、仮にキャッシュメモリ２７０の容量が３２ＫＢであるなら、圧縮データ５４０の内容は図２５に示した圧縮データと同様である。

また、列方向データ圧縮装置２００と列方向データ解凍装置１００の間の通信シーケンスについても、実施例２の図２９と同様である。ただし、実施例３における列方向データ圧縮装置２００では、列方向データ解凍装置１００からの要求に対して、まず、列方向データ解凍装置１００のキャッシュメモリ１７０の容量が、キャッシュメモリ２７０の容量に一致するかを調べる。

容量が一致すれば、圧縮データ５４０を送信し、一致しなければ、ブロックデータ解凍部２９３、および列データ解凍部２９４において圧縮データ５４０は解凍され、次に、ブロックデータ再圧縮部２９１、および列データ再圧縮部２９２において、列方向データ解凍装置１００からの要求内容に従ってデータが再圧縮されて送信される。

ブロックデータ解凍部２９３の動作は、図１５に示した列方向データ解凍装置１００でのブロックデータ解凍処理と同様であり、列データ解凍部２９４の動作は、図１６に示した列方向データ解凍装置１００での列データ解凍処理と同様である。ブロックデータ再圧縮部２９１の動作は、図１１に示したブロックデータ圧縮処理と同様であり、列データ再圧縮部２９２の動作は、図１２に示した列データ圧縮処理と同様である。

以上の構成とすることにより、実施例３においては、実施例２のような複数の圧縮データを保持する必要がなく単一の圧縮データを保持すればよい。

なお、このような構成とする場合、圧縮データを一旦解凍して再圧縮する処理が加わるため、列方向データ圧縮装置２００における処理時間が増加するが、これを削減するために、列データ解凍部２９４、および列データ再圧縮部２９２における圧縮解凍処理を、複数の処理装置を用いて列毎に並列に実行する構成としても良い。

１００：列方向データ解凍装置
１１０：アプリケーションソフト実行部
１２０：ブロックデータ解凍部（列方向データ解凍装置）
１４０：列データ解凍部（列方向データ解凍装置）
１５０：記憶媒体（列方向データ解凍装置）
１６０：主記憶装置（列方向データ解凍装置）
１７０：キャッシュメモリ（列方向データ解凍装置）
１８０：圧縮データ要求部
２００：列方向データ圧縮装置
２２０：ブロックデータ圧縮部
２３０：単位サイズ設定部
２４０：列データ圧縮部
２５０：記憶媒体（列方向データ圧縮装置）
２６０：主記憶装置（列方向データ圧縮装置）
２７０：キャッシュメモリ（列方向データ圧縮装置）
２８０：圧縮データ選択部
２９１：ブロックデータ再圧縮部
２９２：列データ再圧縮部
２９３：ブロックデータ解凍部（列方向データ圧縮装置）
２９４：列データ解凍部（列方向データ圧縮装置）
３００：通信ネットワーク
５００：圧縮データ（実施例１）
５１０：圧縮データ（実施例２、８ＫＢキャッシュ用）
５２０：圧縮データ（実施例２、１６ＫＢキャッシュ用）
５３０：圧縮データ（実施例２、３２ＫＢキャッシュ用）
５４０：圧縮データ（実施例３）
６００：元データ（実施例１）
６１０：元データ（実施例２および実施例３）
７００：圧縮定義ファイル

Claims (17)

1. 圧縮された複数の固定長レコードを含む圧縮データを解凍するデータ解凍装置であって、
   前記圧縮データは、圧縮対象データが所定の圧縮対象ブロックサイズ単位で分割され、前記圧縮対象ブロック毎に圧縮された結果を含んだものであり、
   前記圧縮対象ブロックサイズは、前記固定長レコードのサイズと、当該データ解凍装置の仕様情報と、に基づいて決定されるものであり、
   前記固定長レコードのサイズと、前記データ解凍装置の仕様情報と、に基づいて前記圧縮対象ブロックのサイズを判定し、
   前記圧縮データから一以上の圧縮対象ブロックを取得し、
   前記圧縮対象ブロックに含まれる、前記複数の固定長レコードの同一列データを列毎に圧縮した結果である圧縮列データの各々を解凍し、前記複数の固定長レコードを復元する列データ解凍部と、を備える
   ことを特徴とするデータ解凍装置。
2. 請求項１に記載のデータ解凍装置であって、
   さらに、ソフトウェアを実行するソフトウェア実行部を備え、
   前記圧縮データは、前記圧縮対象ブロック毎に圧縮された結果であるサブブロックを一つ以上含んだブロックを一つ以上含んだものであり、
   前記ソフトウェアが要求するデータを含む一つ以上の前記ブロック各々の解凍を制御するブロックデータ解凍制御部を含む
   ことを特徴とするデータ解凍装置。
3. 請求項１または２に記載のデータ解凍装置であって、
   前記データ解凍装置の仕様情報とは、データ解凍装置が備えるキャッシュメモリの容量であり、
   前記圧縮対象ブロックのサイズは、前記キャッシュメモリの容量に所定の比率を乗算した値を超えない、前記固定長レコードのサイズの最大の倍数である
   ことを特徴とするデータ解凍装置。
4. 請求項３に記載のデータ解凍装置であって、
   前記キャッシュメモリの容量に乗じる所定の比率とは０．５である
   ことを特徴とするデータ解凍装置。
5. 請求項２に記載のデータ解凍装置であって、
   前記データ解凍装置の仕様情報とは、前記ソフトウェアが前記圧縮対象ブロックの解凍データを保持するために確保している主記憶装置の容量であり、
   前記圧縮対象ブロックのサイズは、前記主記憶装置の容量を超えない、前記固定長レコードのサイズの最大の倍数である
   ことを特徴とするデータ解凍装置。
6. 請求項１または２に記載のデータ解凍装置であって、
   前記データ解凍装置の仕様情報とは、データ解凍装置が備える通信装置が一度に送信可能なデータの最大サイズであり、
   前記圧縮対象ブロックのサイズは、前記一度に送信可能なデータの最大サイズを超えない、前記固定長レコードのサイズの最大の倍数である
   ことを特徴とするデータ解凍装置。
7. 請求項１から６のいずれか一項に記載のデータ解凍装置であって、
   通信網を介してデータ圧縮装置に、圧縮データの名称と、前記データ解凍装置の仕様情報を送信し、前記データ圧縮装置から、前記通知した情報に適合する圧縮データを受信する圧縮データ要求部を備える
   ことを特徴とするデータ解凍装置。
8. 請求項７に記載のデータ解凍装置であって、
   前記圧縮データ要求部は、前記データ圧縮装置から、適合する圧縮データが存在しないことを通知された場合に、適合する圧縮データが存在しないことを示す警告画面を表示する
   ことを特徴とするデータ解凍装置。
9. 複数の固定長レコードを含む圧縮対象データを圧縮するデータ圧縮装置であって、
   前記固定長レコードの１レコードのサイズと、データ解凍装置の仕様情報と、の入力を受け付ける単位サイズ設定部と、
   前記固定長レコードのサイズと、前記データ解凍装置の仕様情報と、に基づいて圧縮対象ブロックのサイズを決定し、各々の前記圧縮対象ブロックに含まれる複数の前記固定長レコードの同一列データを列毎に圧縮して圧縮列データを作成し、各々の前記圧縮列データを含む圧縮データを作成する列データ圧縮部と、を備える
   ことを特徴とするデータ圧縮装置。
10. 請求項９に記載のデータ圧縮装置であって、
    前記データ解凍装置の仕様情報とは、データ解凍装置が備える解凍装置キャッシュメモリの容量であり、
    前記圧縮対象ブロックのサイズは、前記解凍装置キャッシュメモリの容量に所定の比率を乗算した値を超えない、前記固定長レコードのサイズの最大の倍数であることを特徴とするデータ圧縮装置。
11. 請求項１０に記載のデータ圧縮装置であって、
    前記解凍装置キャッシュメモリの容量に乗じる所定の比率とは０．５である
    ことを特徴とするデータ圧縮装置。
12. 請求項９から１１のいずれか一項に記載のデータ圧縮装置であって、
    前記圧縮対象データを所定サイズの大きさのブロックに分割し、前記ブロック各々の圧縮を制御するブロックデータ圧縮部を備え、 前記ブロックデータ圧縮部は、前記圧縮対象データの各部分で異なる固定長レコードのレコード長を記載した圧縮定義ファイルを参照して、各々の前記ブロックの圧縮方法を決定し、
    前記列データ圧縮部は、前記ブロックデータ圧縮部が圧縮方法を列圧縮と決定した前記ブロックを前記圧縮対象データとする
    ことを特徴とするデータ圧縮装置。
13. 請求項９から１２のいずれか一項に記載のデータ圧縮装置であって、
    前記単位サイズ設定部に入力された複数の前記仕様情報に基づき、前記列データ圧縮部が一つの前記圧縮対象データから作成した複数の前記圧縮データを記憶媒体に格納し、
    さらに、通信網を介してデータ解凍装置から、前記データ解凍装置の仕様情報を受信し、受信した前記仕様情報に適合する前記圧縮データを選択して前記データ解凍装置に送信する圧縮データ選択部を備えることを特徴とするデータ圧縮装置。
14. 請求項９から１３のいずれか一項に記載のデータ圧縮装置であって
    一つの前記圧縮対象データから作成された一つの圧縮データを記憶媒体に格納し、通信網を介してデータ解凍装置から受信した当該データ解凍装置の仕様情報が、前記圧縮データを作成する際に参照した仕様情報と異なっている場合に、前記圧縮データを解凍する解凍部と、
    前記解凍部が出力する解凍されたデータを前記圧縮対象データとして、前記データ解凍装置から受信した前記データ解凍装置の仕様情報に基づき、再圧縮された前記圧縮データを、前記データ解凍装置へ送信するブロックデータ再圧縮部と、
    を備えることを特徴とするデータ圧縮装置。
15. コンピューターを、圧縮された複数の固定長レコードを含む圧縮データを解凍するデータ解凍装置として機能させるためのプログラムであって、
    前記圧縮データは、圧縮対象データが所定の圧縮対象ブロックサイズ単位で分割され、前記圧縮対象ブロック毎に圧縮された結果を含んだものであり、
    前記圧縮対象ブロックサイズは、前記固定長レコードのサイズと、当該データ解凍装置の仕様情報と、に基づいて決定されるものであり、
    前記固定長レコードのサイズと、前記データ解凍装置の仕様情報と、に基づいて前記圧縮対象ブロックのサイズを判定するステップと、
    前記圧縮データから一以上の圧縮対象ブロックを取得するステップと、
    前記圧縮対象ブロックに含まれる、前記複数の固定長レコードの同一列データを列毎に圧縮した結果である圧縮列データの各々を解凍し、前記複数の固定長レコードを復元するステップと、
    を前記コンピューターに実行させる
    ことを特徴とするプログラム。
16. コンピューターを、複数の固定長レコードを含む圧縮対象データを圧縮するデータ圧縮装置として機能させるためのプログラムであって、
    前記コンピューターはユーザーからの命令を受け付けるインターフェース装置を備えており、
    前記インターフェース装置を介して、前記固定長レコードの１レコードのサイズと、データ解凍装置の仕様情報と、の入力を受け付けるステップと、
    前記固定長レコードのサイズと、前記データ解凍装置の仕様情報と、に基づいて圧縮対象ブロックのサイズを決定するステップと、
    前記圧縮対象データを一以上の前記圧縮対象ブロックに分割するステップと、
    各々の前記圧縮対象ブロックに含まれる複数の前記固定長レコードの同一列データを列毎に圧縮して圧縮列データを作成するステップと、
    各々前記圧縮列データを含む圧縮データを作成するステップと、を前記コンピューターに実行させる
    ことを特徴とするプログラム。
17. 圧縮された複数の固定長レコードを含む圧縮データを生成するデータ圧縮装置と前記圧縮データを解凍するデータ解凍装置が通信網を介して接続される圧縮データ配信システムであって、
    前記圧縮データは、圧縮対象データが所定の圧縮対象ブロックサイズ単位で分割され、前記圧縮対象ブロック毎に圧縮された結果を含んだものであり、
    前記圧縮対象ブロックサイズは、前記固定長レコードのサイズと、当該データ解凍装置の仕様情報と、に基づいて決定されるものであり、
    前記データ圧縮装置は、
    前記固定長レコードの１レコードのサイズと、データ解凍装置の仕様情報と、の入力を受け付ける単位サイズ設定部と、
    前記固定長レコードのサイズと、前記データ解凍装置の仕様情報と、に基づいて前記圧縮対象ブロックのサイズを決定し、前記圧縮対象データを一以上の前記圧縮対象ブロックに分割し、各々の前記圧縮対象ブロックに含まれる複数の前記固定長レコードの同一列データを列毎に圧縮して圧縮列データを作成し、各々の前記圧縮列データを含む圧縮データを作成する列データ圧縮部と、を備え、
    前記データ解凍装置は、
    前記固定長レコードのサイズと、前記データ解凍装置の仕様情報と、に基づいて前記圧縮対象ブロックのサイズを判定し、
    前記圧縮データから一以上の圧縮対象ブロックを取得し、
    前記圧縮対象ブロックに含まれる、前記複数の固定長レコードの同一列データを列毎に圧縮した結果である圧縮列データの各々を解凍し、前記複数の固定長レコードを復元する列データ解凍部と、を備える
    ことを特徴とする圧縮データ配信システム。

Images