特許第5826114号(P5826114)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ クラリオン株式会社の特許一覧
特許5826114データ解凍装置、データ圧縮装置、データの解凍プログラム、データの圧縮プログラム、及び、圧縮データ配信システム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】5826114
(24)【登録日】2015年10月23日
(45)【発行日】2015年12月2日
(54)【発明の名称】データ解凍装置、データ圧縮装置、データの解凍プログラム、データの圧縮プログラム、及び、圧縮データ配信システム
(51)【国際特許分類】
   G06F 12/00 20060101AFI20151112BHJP
【FI】
   G06F12/00 511A
   G06F12/00 514M
【請求項の数】17
【全頁数】30
(21)【出願番号】特願2012-119180(P2012-119180)
(22)【出願日】2012年5月25日
(65)【公開番号】特開2013-246598(P2013-246598A)
(43)【公開日】2013年12月9日
【審査請求日】2014年7月18日
(73)【特許権者】
【識別番号】000001487
【氏名又は名称】クラリオン株式会社
(74)【代理人】
【識別番号】100100310
【弁理士】
【氏名又は名称】井上 学
(74)【代理人】
【識別番号】100098660
【弁理士】
【氏名又は名称】戸田 裕二
(74)【代理人】
【識別番号】100091720
【弁理士】
【氏名又は名称】岩崎 重美
(72)【発明者】
【氏名】関口 隆昭
(72)【発明者】
【氏名】永井 靖
(72)【発明者】
【氏名】長船 辰昭
(72)【発明者】
【氏名】福永 良一
(72)【発明者】
【氏名】大久保 貴博
(72)【発明者】
【氏名】今井 大貴
【審査官】 加内 慎也
(56)【参考文献】
【文献】 特開2001−204001(JP,A)
【文献】 特開2006−276981(JP,A)
【文献】 特開2013−051667(JP,A)
【文献】 特表2011−530234(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 12/00
(57)【特許請求の範囲】
【請求項1】
圧縮された複数の固定長レコードを含む圧縮データを解凍するデータ解凍装置であって、
前記圧縮データは、圧縮対象データが所定の圧縮対象ブロックサイズ単位で分割され、前記圧縮対象ブロック毎に圧縮された結果を含んだものであり、
前記圧縮対象ブロックサイズは、前記固定長レコードのサイズと、当該データ解凍装置の仕様情報と、に基づいて決定されるものであり、
前記固定長レコードのサイズと、前記データ解凍装置の仕様情報と、に基づいて前記圧縮対象ブロックのサイズを判定し、
前記圧縮データから一以上の圧縮対象ブロックを取得し、
前記圧縮対象ブロックに含まれる、前記複数の固定長レコードの同一列データを列毎に圧縮した結果である圧縮列データの各々を解凍し、前記複数の固定長レコードを復元する列データ解凍部と、を備える
ことを特徴とするデータ解凍装置。
【請求項2】
請求項1に記載のデータ解凍装置であって、
さらに、ソフトウェアを実行するソフトウェア実行部を備え、
前記圧縮データは、前記圧縮対象ブロック毎に圧縮された結果であるサブブロックを一つ以上含んだブロックを一つ以上含んだものであり、
前記ソフトウェアが要求するデータを含む一つ以上の前記ブロック各々の解凍を制御するブロックデータ解凍制御部を含む
ことを特徴とするデータ解凍装置。
【請求項3】
請求項1または2に記載のデータ解凍装置であって、
前記データ解凍装置の仕様情報とは、データ解凍装置が備えるキャッシュメモリの容量であり、
前記圧縮対象ブロックのサイズは、前記キャッシュメモリの容量に所定の比率を乗算した値を超えない、前記固定長レコードのサイズの最大の倍数である
ことを特徴とするデータ解凍装置。
【請求項4】
請求項3に記載のデータ解凍装置であって、
前記キャッシュメモリの容量に乗じる所定の比率とは0.5である
ことを特徴とするデータ解凍装置。
【請求項5】
請求項に記載のデータ解凍装置であって、
前記データ解凍装置の仕様情報とは、前記ソフトウェアが前記圧縮対象ブロックの解凍データを保持するために確保している主記憶装置の容量であり、
前記圧縮対象ブロックのサイズは、前記主記憶装置の容量を超えない、前記固定長レコードのサイズの最大の倍数である
ことを特徴とするデータ解凍装置。
【請求項6】
請求項1または2に記載のデータ解凍装置であって、
前記データ解凍装置の仕様情報とは、データ解凍装置が備える通信装置が一度に送信可能なデータの最大サイズであり、
前記圧縮対象ブロックのサイズは、前記一度に送信可能なデータの最大サイズを超えない、前記固定長レコードのサイズの最大の倍数である
ことを特徴とするデータ解凍装置。
【請求項7】
請求項1から6のいずれか一項に記載のデータ解凍装置であって、
通信網を介してデータ圧縮装置に、圧縮データの名称と、前記データ解凍装置の仕様情報を送信し、前記データ圧縮装置から、前記通知した情報に適合する圧縮データを受信する圧縮データ要求部を備える
ことを特徴とするデータ解凍装置。
【請求項8】
請求項7に記載のデータ解凍装置であって、
前記圧縮データ要求部は、前記データ圧縮装置から、適合する圧縮データが存在しないことを通知された場合に、適合する圧縮データが存在しないことを示す警告画面を表示する
ことを特徴とするデータ解凍装置。
【請求項9】
複数の固定長レコードを含む圧縮対象データを圧縮するデータ圧縮装置であって、
前記固定長レコードの1レコードのサイズと、データ解凍装置の仕様情報と、の入力を受け付ける単位サイズ設定部と、
前記固定長レコードのサイズと、前記データ解凍装置の仕様情報と、に基づいて圧縮対象ブロックのサイズを決定し、各々の前記圧縮対象ブロックに含まれる複数の前記固定長レコードの同一列データを列毎に圧縮して圧縮列データを作成し、各々の前記圧縮列データを含む圧縮データを作成する列データ圧縮部と、を備える
ことを特徴とするデータ圧縮装置。
【請求項10】
請求項9に記載のデータ圧縮装置であって、
前記データ解凍装置の仕様情報とは、データ解凍装置が備える解凍装置キャッシュメモリの容量であり、
前記圧縮対象ブロックのサイズは、前記解凍装置キャッシュメモリの容量に所定の比率を乗算した値を超えない、前記固定長レコードのサイズの最大の倍数であることを特徴とするデータ圧縮装置。
【請求項11】
請求項10に記載のデータ圧縮装置であって、
前記解凍装置キャッシュメモリの容量に乗じる所定の比率とは0.5である
ことを特徴とするデータ圧縮装置。
【請求項12】
請求項9から11のいずれか一項に記載のデータ圧縮装置であって、
前記圧縮対象データを所定サイズの大きさのブロックに分割し、前記ブロック各々の圧縮を制御するブロックデータ圧縮部を備え、 前記ブロックデータ圧縮部は、前記圧縮対象データの各部分で異なる固定長レコードのレコード長を記載した圧縮定義ファイルを参照して、各々の前記ブロックの圧縮方法を決定し、
前記列データ圧縮部は、前記ブロックデータ圧縮部が圧縮方法を列圧縮と決定した前記ブロックを前記圧縮対象データとする
ことを特徴とするデータ圧縮装置。
【請求項13】
請求項9から12のいずれか一項に記載のデータ圧縮装置であって、
前記単位サイズ設定部に入力された複数の前記仕様情報に基づき、前記列データ圧縮部が一つの前記圧縮対象データから作成した複数の前記圧縮データを記憶媒体に格納し、
さらに、通信網を介してデータ解凍装置から、前記データ解凍装置の仕様情報を受信し、受信した前記仕様情報に適合する前記圧縮データを選択して前記データ解凍装置に送信する圧縮データ選択部を備えることを特徴とするデータ圧縮装置。
【請求項14】
請求項9から13のいずれか一項に記載のデータ圧縮装置であって
一つの前記圧縮対象データから作成された一つの圧縮データを記憶媒体に格納し、通信網を介してデータ解凍装置から受信した当該データ解凍装置の仕様情報が、前記圧縮データを作成する際に参照した仕様情報と異なっている場合に、前記圧縮データを解凍する解凍部と、
前記解凍部が出力する解凍されたデータを前記圧縮対象データとして、前記データ解凍装置から受信した前記データ解凍装置の仕様情報に基づき、再圧縮された前記圧縮データを、前記データ解凍装置へ送信するブロックデータ再圧縮部と、
を備えることを特徴とするデータ圧縮装置。
【請求項15】
コンピューターを、圧縮された複数の固定長レコードを含む圧縮データを解凍するデータ解凍装置として機能させるためのプログラムであって、
前記圧縮データは、圧縮対象データが所定の圧縮対象ブロックサイズ単位で分割され、前記圧縮対象ブロック毎に圧縮された結果を含んだものであり、
前記圧縮対象ブロックサイズは、前記固定長レコードのサイズと、当該データ解凍装置の仕様情報と、に基づいて決定されるものであり、
前記固定長レコードのサイズと、前記データ解凍装置の仕様情報と、に基づいて前記圧縮対象ブロックのサイズを判定するステップと、
前記圧縮データから一以上の圧縮対象ブロックを取得するステップと、
前記圧縮対象ブロックに含まれる、前記複数の固定長レコードの同一列データを列毎に圧縮した結果である圧縮列データの各々を解凍し、前記複数の固定長レコードを復元するステップと、
を前記コンピューターに実行させる
ことを特徴とするプログラム。
【請求項16】
コンピューターを、複数の固定長レコードを含む圧縮対象データを圧縮するデータ圧縮装置として機能させるためのプログラムであって、
前記コンピューターはーザーからの命令を受け付けるインターフェース装置を備えており、
前記インターフェース装置を介して、前記固定長レコードの1レコードのサイズと、データ解凍装置の仕様情報と、の入力を受け付けるステップと、
前記固定長レコードのサイズと、前記データ解凍装置の仕様情報と、に基づいて圧縮対象ブロックのサイズを決定するステップと、
前記圧縮対象データを一以上の前記圧縮対象ブロックに分割するステップと、
各々の前記圧縮対象ブロックに含まれる複数の前記固定長レコードの同一列データを列毎に圧縮して圧縮列データを作成するステップと、
各々前記圧縮列データを含む圧縮データを作成するステップと、を前記コンピューターに実行させる
ことを特徴とするプログラム。
【請求項17】
圧縮された複数の固定長レコードを含む圧縮データを生成するデータ圧縮装置と前記圧縮データを解凍するデータ解凍装置が通信網を介して接続される圧縮データ配信システムであって、
前記圧縮データは、圧縮対象データが所定の圧縮対象ブロックサイズ単位で分割され、前記圧縮対象ブロック毎に圧縮された結果を含んだものであり、
前記圧縮対象ブロックサイズは、前記固定長レコードのサイズと、当該データ解凍装置の仕様情報と、に基づいて決定されるものであり、
前記データ圧縮装置は、
前記固定長レコードの1レコードのサイズと、データ解凍装置の仕様情報と、の入力を受け付ける単位サイズ設定部と、
前記固定長レコードのサイズと、前記データ解凍装置の仕様情報と、に基づいて前記圧縮対象ブロックのサイズを決定し、前記圧縮対象データを一以上の前記圧縮対象ブロックに分割し、各々の前記圧縮対象ブロックに含まれる複数の前記固定長レコードの同一列データを列毎に圧縮して圧縮列データを作成し、各々の前記圧縮列データを含む圧縮データを作成する列データ圧縮部と、を備え、
前記データ解凍装置は、
前記固定長レコードのサイズと、前記データ解凍装置の仕様情報と、に基づいて前記圧縮対象ブロックのサイズを判定し、
前記圧縮データから一以上の圧縮対象ブロックを取得し、
前記圧縮対象ブロックに含まれる、前記複数の固定長レコードの同一列データを列毎に圧縮した結果である圧縮列データの各々を解凍し、前記複数の固定長レコードを復元する列データ解凍部と、を備える
ことを特徴とする圧縮データ配信システム。
【発明の詳細な説明】
【技術分野】
【0001】
開示される主題は、複数の固定長レコードの並びが圧縮されたデータを高速に解凍する技術に関するものである。
【背景技術】
【0002】
カーナビゲーションシステム(以下、カーナビとする)は、地図データを加工してユーザーに交通案内情報を提供するものである。この地図データの記憶媒体として従来はHDD(Hard Disk Drive)を使用している機種が多かったが、近年はSDカードやSSD(Solid State Drive)等の半導体素子メモリを用いた機種が主流になりつつある。
【0003】
半導体素子メモリは、従来のHDDと比較して、消費電力が少ない、耐衝撃性に優れている等の利点がある一方、容量あたりの単価が高いという欠点がある。そのため、従来と同程度の価格帯でユーザーにカーナビを提供するためには、使用する半導体素子メモリの容量を少なくする必要がある。これに対して、カーナビが動作するために必要なデータの内容は、記憶媒体がHDDでも半導体素子メモリでも変わりはなく、また、新しい道路や施設の整備等によりデータベースのサイズは年々増加する傾向にあるため、カーナビに収録するデータのサイズを削減する技術が常に望まれている。この、データのサイズを削減する技術として、以下の技術が提案されている。
【0004】
まず、データの内容を変えずにデータサイズを削減するために一般的に用いられる方法として、特許文献1に記載されているデータ圧縮技術がある。データ圧縮技術は、容易にデータサイズを削減することが可能であるため、特許文献1に記載の技術の他、多数の圧縮方法が提案され、広く実用に供されている。
【0005】
また、データサイズを削減する別の技術として、特許文献2に記載の技術がある。この技術は、データが2次元のテーブル状の構造を有している場合に、テーブルの各列に着目して所定の手順で辞書を作成し、この辞書を利用することにより列単位で圧縮してデータサイズを削減するものである。なお、このように圧縮対象のデータが行と列からなる二次元の構造を有する場合、単純にデータ(バイト列)を先頭から行方向に処理するよりも、列単位でデータを圧縮したほうが圧縮率の向上を期待できることは一般に知られており、例えば非特許文献1等、多数の文献において言及されている。
【0006】
また、データサイズを削減する別の技術として、特許文献3に記載の技術がある。この技術は、カーナビのアプリケーションがデータベースにアクセスする形態として、データベース内の特定の位置へのランダムアクセスと、比較的大きなデータを参照する際のシーケンシャルアクセスが混在することに着目して、圧縮対象データを所定のブロック単位に分割して圧縮した上で、目的のデータへのランダムアクセスを可能にしつつ、あるブロックを参照した際に後続のブロックをメモリに先読みすることで、シーケンシャルアクセス時の性能向上も図ったものである。
【先行技術文献】
【特許文献】
【0007】
【特許文献1】米国特許第4558302号明細書(第15−22頁、第2−3図)
【特許文献2】米国特許第7769729B2号明細書(第24−25頁、第10図)
【特許文献3】特開2010−165151号公報(第4−5頁、第2図)
【非特許文献】
【0008】
【非特許文献1】B.R.Iyer、他1名 著,“Data Compression Support in Databases”,In Proceedings of the 20th International Conference on Very Large Data Bases(VLDB94),(米国),1994,p.695−704
【発明の概要】
【発明が解決しようとする課題】
【0009】
しかしながら、上記の特許文献1、特許文献2、および特許文献3に記載の技術には、以下の問題がある。
【0010】
まず、特許文献1等に記載のデータ圧縮技術は、データを参照する前に、圧縮されたデータを元に戻す処理(以下、解凍処理と記載する)が必要になる。この解凍処理には時間がかかるため、単純にデータを圧縮してしまうと、データを参照して各種のナビゲーションを行う際の性能が悪化するという問題がある。
【0011】
また、特許文献2等に記載されているような、列方向にデータを圧縮する技術の場合、たしかに圧縮率は向上するが、データが列単位で圧縮されているため、1行のデータを取り出すためには全ての列を解凍しなければならないという性能上の問題がある。この問題は、二次元構造のデータを列方向に圧縮する際の本質的な問題であるが、特に次の特許文献3のように、使用するメモリのサイズが小さい場合に問題が顕著となる。
【0012】
特許文献3に記載の技術は、あるブロックのデータを参照した際に後続のブロックをキャッシュメモリに先読みすることによりシーケンシャルアクセス時の性能向上を図るものであるが、この効果を期待できるのは、キャッシュメモリに記憶している内容が解凍処理の途中で置き換わらない場合に限定される。例えば、特許文献2に記載の技術のようにデータが列方向に圧縮されている場合、前述したように、1行のデータを取り出すためには全ての列を解凍する必要があり、この全ての列の解凍結果(すなわちデータの全体に相当する)を保持するために必要な領域のサイズはキャッシュメモリの容量を大幅に超過するため、CPU(Central Processing Unit)が解凍結果を保持する領域を参照する際に、先読みした圧縮データはキャッシュメモリから削除されてしまう。その結果、圧縮データはキャッシュメモリからではなく主記憶装置やHDD等のより低速な記憶媒体から読み直されることになるため、先読みの効果は得られない。 以上述べたように、多数の固定長レコードの並びを含む大容量データの圧縮率を向上しつつ、解凍性能を向上することが求められている。
【課題を解決するための手段】
【0013】
上記の課題を解決するため、本明細書では、複数の固定長レコードの並びを列方向に(複数レコードの同一列データを列毎に)圧縮する際、キャッシュメモリ容量等、解凍装置側の性能指標と1レコードのサイズに基づいて、1回の列方向圧縮において処理する行数を算出することにより、解凍装置の性能に合わせたデータ圧縮を行うことを最も主要な特徴とする技術が開示される。なお、以降では1列の幅を1バイトとして説明するが、本明細書で開示される技術は、列幅が1バイトより大きい場合にも応用可能である。
【0014】
開示される具体的な例では、32KBのキャッシュメモリを有する解凍装置向けに、1レコードが12バイトである固定長レコードの並びを圧縮する場合には、キャッシュメモリ32KBのうち半分の16KBを圧縮データ読み込み用として考え、この16KBに収まる最大のレコード数である1365レコード(=65536÷12)を1回の列方向に圧縮する単位とする。これによって、圧縮データを解凍する際のキャッシュメモリの不要な更新が抑制され、解凍処理を高速に行うことが可能となる。
【0015】
なお、上記は一例であり、1回の列方向圧縮を行うレコード数の算出方法としては、解凍装置のキャッシュメモリ容量の他、解凍装置が使用可能な主記憶装置の容量や、あるいは、解凍装置が通信ネットワークを介して圧縮データを受信する場合は、通信プロトコルによる1回の最大データ送信サイズを使用しても良い。
【0016】
また、本明細書で開示される技術は、性能指標が異なる各種の解凍装置に対して通信ネットワークを介して配信サーバから圧縮データを配信するシステムにおいて、あらかじめ各解凍装置の性能に適合する複数の圧縮データを作成しておき、要求を行った解凍装置の性能に適合する圧縮データを選択して配信することを第二の特徴とする。例えば、データを閲覧する端末(本明細書で開示される解凍装置に相当)としては、PC(Personal Computer)の他に、携帯電話やスマートフォン等、性能が異なる各種の端末があり、これらの各端末においてそれぞれ解凍時間が最短となる圧縮データを配信することが可能となる。
【0017】
なお、あらかじめ複数の圧縮データを作成しておくのではなく、あらかじめ作成された一種類の圧縮データを一旦解凍し、この解凍され復元されたデータを、圧縮データを要求する解凍装置固有の性能指標に応じて再圧縮して配信する構成としても良い。
【0018】
以上の特徴を持つ技術として、本明細書では、複数の固定長レコードを含む圧縮対象データを圧縮するデータ圧縮装置であって、固定長レコードの1レコードのサイズと、データ解凍装置の仕様情報と、の入力を受け付ける単位サイズ設定部と、固定長レコードのサイズと、データ解凍装置の仕様情報と、に基づいて圧縮対象ブロックのサイズを決定し、各々の圧縮対象ブロックに含まれる複数の固定長レコードの同一列データを列毎に圧縮して圧縮列データを作成し、各々の圧縮列データを含む圧縮データを作成する列データ圧縮部と、を備えるデータ圧縮装置が開示される。
【0019】
また、上記データ圧縮装置によって圧縮された複数の固定長レコードを含む圧縮データを解凍するデータ解凍装置として、圧縮データが、圧縮対象データが所定の圧縮対象ブロックサイズ単位で分割され、圧縮対象ブロック毎に圧縮された結果を含んだものであり、圧縮対象ブロックサイズが、固定長レコードのサイズと、当該データ解凍装置の仕様情報と、に基づいて決定されるものである場合に、固定長レコードのサイズと、データ解凍装置の仕様情報と、に基づいて圧縮対象ブロックのサイズを判定し、圧縮データから一以上の圧縮対象ブロックを取得し、圧縮対象ブロックに含まれる、複数の固定長レコードの同一列データを列毎に圧縮した結果である圧縮列データの各々を解凍し、複数の固定長レコードを復元する列データ解凍部と、を備えるデータ解凍装置が開示される。
【発明の効果】
【0020】
開示される内容により、多数の固定長レコードの並びを含む大容量データの圧縮率を向上しつつ、解凍性能を向上することが可能となる。
【図面の簡単な説明】
【0021】
図1】ツリーデータ圧縮システムの全体構成を例示する図(実施例1)。
図2】ツリーデータの1レコードの構造を例示する図(実施例1)
図3】圧縮対象データ(元データ)を例示する図(実施例1)
図4】キャッシュメモリ170の構造を例示する説明図(実施例1)。
図5】列方向圧縮時のキャッシュメモリの問題を例示する説明図(実施例1)。
図6】圧縮データの構成を例示する図(実施例1)。
図7】圧縮識別子の構成を例示する図(実施例1)。
図8】列圧縮識別子の構成を例示する図(実施例1)。
図9】圧縮定義ファイルの構成を例示する図(実施例1)。
図10】圧縮データ作成画面を例示する図(実施例1)。
図11】ブロックデータ圧縮部の動作を例示するフローチャート(実施例1)。
図12】列データ圧縮部の動作を例示するフローチャート(実施例1)。
図13】列方向圧縮処理の動作を例示するフローチャート(実施例1)。
図14】アプリケーションソフトからの要求を例示する説明図(実施例1)。
図15】ブロックデータ解凍部の動作を例示するフローチャート(実施例1)。
図16】列データ解凍部の動作を例示するフローチャート(実施例1)。
図17】列方向解凍処理の動作を例示するフローチャート(実施例1)。
図18】キャッシュメモリ170の状態を例示する図(実施例1)。
図19】走行履歴データ閲覧システムの全体構成を例示する図(実施例2)。
図20】走行履歴データの1レコードの構造を例示する図(実施例2)。
図21】圧縮対象データ(元データ)を例示する図(実施例2)。
図22】記憶媒体の構成を例示する図(実施例2)。
図23】圧縮データ(8KBキャッシュ用)の構成を例示する図(実施例2)。
図24】圧縮データ(16KBキャッシュ用)の構成を例示する図(実施例2)。
図25】圧縮データ(32KBキャッシュ用)の構成を例示する図(実施例2)。
図26】圧縮データ作成画面を例示する図(実施例2)。
図27】ブロックデータ圧縮部の動作を例示するフローチャート(実施例2)。
図28】各装置用の圧縮データ作成処理を例示するフローチャート(実施例2)。
図29】圧縮データ送受信シーケンスを例示する図(実施例2)。
図30】警告画面を例示する図(実施例2)。
図31】別の形態の走行履歴データ閲覧システムの全体構成を例示する図(実施例3)。
【発明を実施するための形態】
【実施例1】
【0022】
以下、図1から図18を用いて、実施例1のツリーデータ圧縮システムについて説明する。
【0023】
実施例1は、カーナビに格納するデータベースにおいて多くの領域を占めている検索データ(以降、ツリーデータと呼ぶ)を圧縮し、カーナビのデータベースのサイズを削減するものである。実施例1においては、列方向データ解凍装置100はカーナビに相当し、列方向データ圧縮装置200は、カーナビの記憶媒体150に格納するデータを作成するための装置(パーソナルコンピューター等)に相当する。
【0024】
図1は、実施例1のツリーデータ圧縮システムの機能構成を示したものである。本システムは、列方向データ解凍装置100、列方向データ圧縮装置200を含んで構成される。実施例1での圧縮対象であるツリーデータは、列方向データ圧縮装置200において圧縮され、列方向データ解凍装置100の記憶媒体150にコピーされる。列方向データ解凍装置100では、アプリケーションソフトが、圧縮されたツリーデータを部分的に解凍しながら検索処理を実行する。
【0025】
列方向データ解凍装置100は、アプリケーションソフトを実行するアプリケーションソフト実行部110、ブロック単位で圧縮されたデータを解凍するブロックデータ解凍部120、列方向に圧縮されたデータを解凍する列データ解凍部140、圧縮データ500を格納する記憶媒体150、主記憶装置160、およびキャッシュメモリ170を含んで構成される。
【0026】
列方向データ圧縮装置200は、圧縮定義ファイル700を参照しながらブロック単位でデータを圧縮するブロックデータ圧縮部220、データ圧縮のパラメータを設定する単位サイズ設定部230、列方向にデータを圧縮する列データ圧縮部240、圧縮対象の元データ600および圧縮データ500を格納する記憶媒体250を含んで構成される。なお、実施例1とは直接の関係が無いため図示していないが、列方向データ圧縮装置200においても、列方向データ解凍装置100と同様、一連の処理を実行するための主記憶装置およびキャッシュメモリが存在する。
【0027】
図1に示す各装置は、CPUと記憶装置とを備える一般的な計算機を用いて実現することができる。本実施例では、キャッシュメモリ170はCPUの内部に備わり、主記憶装置160は半導体メモリで構成され、記憶媒体150はHDDなどの磁気記録媒体や、主記憶装置160より低速で不揮発性のフラッシュメモリなどで構成されている、と想定している。
【0028】
さらに、各装置を構成するそれぞれの処理部は、CPUが主記憶装置160や記憶媒体150に格納されているプログラムを実行することにより、上記計算機上に具現化される。各プログラムは、あらかじめ、上記計算機内の記憶装置に格納されていても良いし、必要なときに、入出力インタフェースと上記計算機が利用可能な媒体を介して、他の装置から上記記憶装置に導入されてもよい。媒体とは、たとえば、入出力インタフェースに着脱可能な記憶媒体、または通信媒体(すなわち有線、無線、光などのネットワーク、または当該ネットワークを伝搬する搬送波やディジタル信号)を指す。
【0029】
図2は、圧縮対象のツリーデータのフォーマットおよびデータの例を示したものである。ツリーデータの1レコードは12バイトで構成され、下位ノード(ツリーの子)のアドレス601(4バイト)、下位ノードのサイズ602(4バイト)、およびレコードの値603(4バイト)を格納している。図2に示すデータの例では、例えば1文字目が「A」の場合、続く2文字目には「B」と「D」があり、「B」に続く3文字目には「C」「E」「H」が存在することを意味している。
【0030】
このようなツリーデータは、一般的なカーナビが備えている目的地名称等を入力する画面(英数字等の各文字を示すボタンが画面に表示されている)において使用されるもので、「A」が入力された時は「A」で始まる名称の2番目の文字(すなわち「B」「D」等)のボタンは押下可能にするが他の文字は押下できないようにする等の制御を行い、ユーザーが検索を行い易くするためのデータである。
【0031】
図3は、元データ600に含まれるツリーデータの並びを16進数で表記した例、および圧縮データ500に含まれる列02の圧縮データの例を記載したものである。ツリーデータの例は、理解し易いように、1レコードのサイズである12バイト単位で改行して記載している。このようにデータが固定長レコードの並びで構成される場合、同一桁の値は特徴的なパターンを有することが多く、例えば列00および列01の値は全て00になっている。列02については、同じ値が複数連続しており、これをランレングス符号によって圧縮すると、01、01、02、04、03、06のようになる。この圧縮データの意味は、記号01が1個、記号02が4個、記号03が6個連続するということを示している。なお、ランレングス符号は、記号と、その記号が連続する数を使ってデータを表現する圧縮方法であり、多数の文献で開示されているものである。
【0032】
また、列08および列09は、ツリーデータの各ノードに対応する文字を、1文字が2バイトであるUNICODE(UTF16)で格納しており、1レコード目の「0041」は文字「A」に、2レコード目の「0042」は文字「B」に対応する。使用する文字が英数字のみである場合、UTF16のコードでは、列08(上位バイト)は全て00になる。
【0033】
なお、図2および図3では、英数字による名称を持つ検索データの例を記載したが、本実施例は英数字を使用する場合に限るものではなく、日本語、ドイツ語、フランス語等、その他の言語の文字に対しても応用可能である。
【0034】
ここで、本実施例の背景についての理解の一助とするため、このようにデータを列方向で圧縮する際の問題について図4および図5を用いて説明する。
【0035】
図4は、近年、一般的に用いられている、セットアソシアティブと呼ばれる方式に基づいたキャッシュメモリ170の例を示したものである。一般的にキャッシュメモリ170は、一定サイズのデータ(これをラインと呼ぶ)を格納する複数の領域(これをエントリと呼ぶ)を含んで構成され、特にセットアソシアティブ方式とは、タグを用いて同一エントリに複数のラインを格納する方式である。同一エントリに格納できるラインの数をウェイ数と呼び、同一エントリに4つのラインを格納可能な場合を4ウェイセットアソシアティブ方式と呼ぶ。
【0036】
図4は、1ラインサイズが32バイトで、256エントリを有する、4ウェイセットアソシアティブ方式の例を記載したものであり、エントリとして仮想アドレスの第5ビット目から第12ビット目に対応する8ビットを、タグとしてアドレスの第13ビット目から第31ビット目に対応する19ビットを使用する方式の例である。図4の例では、ウェイ数(すなわち4個)の列を持つタグアレイ171とデータアレイ172を記載している。データアレイ172は、各エントリに格納している4つのラインを保持しているテーブルであり、タグアレイ171は、各エントリに対して、データアレイ172に格納されているデータがどのアドレスのものかを示すタグを格納するものである。
【0037】
ここで、仮想アドレス(32ビット値)0x00012041に位置するデータへの参照が発生した場合を例に、キャッシュメモリ170の動作を説明する。まず、仮想アドレスの第5ビット目から第12ビット目に格納されている8ビットの値からエントリを決定する(ステップS1701)。第5ビット目から第12ビット目に格納されている値は2進数表現で00000010、すなわち10進数の2であり、データがキャッシュメモリ170上にある場合はエントリ2に格納されていることを意味する。
【0038】
次に、仮想アドレスの第13ビット目から31ビット目に格納されている19ビット(タグ)を、タグアレイ171のエントリ2に含まれる4つのタグと比較する(ステップS1702)。例の場合、エントリ2、ウェイ3に同一のタグが格納されており、このことから、エントリ2のウェイ3に仮想アドレス0x00012041を含むラインのデータが保持されていることが識別される。この状態がいわゆるキャッシュにヒットした状態であり、CPUは主記憶装置160にアクセスすることなく、高速なキャッシュメモリ170からの出力で処理を完了することができる(ステップS1703)。
【0039】
一方で、タグアレイ171を参照した結果、仮想アドレスと一致するタグが見つからない場合がいわゆるキャッシュミスヒットであり、主記憶装置160からデータが読み込まれることになる。この場合、一般的に用いられる方式としては、エントリ2に含まれる4つのラインのうち、LRU(Least Recently Used)方式によって、最近最も参照されていないラインがキャッシュメモリ170から削除され、その場所に新たに主記憶装置160から読み込まれたラインが格納される。このようなラインの入れ替えが頻繁に発生すると、CPUによるデータへのアクセス性能が著しく低下することになる。
【0040】
図5は、図4で示したキャッシュメモリ170に対して、1レコード12バイトの固定長レコードの並びを列方向に参照した場合の問題の例を記載したものである。「#n」を含む四角形は1レコード(12バイト)を意味するもので、nはレコードの参照順序である。黒い四角形は、列00(1バイト)の場所を示したものであり、各レコードの先頭に位置している。図には、1366番目のレコードを参照した時点でウェイ1およびウェイ2に保持されている内容を記載している。例えばウェイ1のエントリ0には、レコード#1(12バイト)、#2(12バイト)、およびレコード#3の先頭8バイトが格納されている。続くエントリ1には、レコード#3の続きである4バイト、レコード#4(12バイト)、#5(12バイト)、およびレコード#6の先頭4バイトが格納されている。以降のエントリも同様である。
【0041】
ここで、キャッシュメモリ170を構成する4ウェイのうち、元データを保持するのに使用できるウェイ数を2個とした場合、レコード#1367の列00を参照した時点でキャッシュミスヒットとなり、LRUによって、エントリ0のウェイ1が、#1367の列00を含むデータで置き換えられる。同様に、続く各エントリのデータも順次置き換えられていく。その後、各レコードの列00を参照する処理が終わり、列01を参照する処理が開始される際、再びレコード#1がキャッシュメモリ170に読み込まれる。すなわち、レコード#1について言えば、列00(1バイト)が処理されたのち、12バイトのうち残り11バイトは何ら参照されることなくキャッシュメモリ170から削除され、
次に列01の処理においても残り10バイトは何ら参照されることなくキャッシュメモリ170から削除されており、キャッシュの利用効率が著しく悪いことになる。
【0042】
なお、ウェイは4個あるため、実際はウェイ3およびウェイ4も使用されることになるが、CPUが参照するデータには、解凍された各レコードの他に、解凍する前の圧縮データや、圧縮解凍アルゴリズムが使用する作業領域があるため、解凍された各レコードの保持だけに全てのウェイを使用することは出来ない。また、仮に全てのウェイを使用できたとしても、格納できるレコード数が高々2倍になるだけであり、問題の本質的な解決にはならない。
【0043】
以上の問題を踏まえて、以降、実施例1の詳細を説明する。
【0044】
図6は、実施例1における圧縮データ500のフォーマットを記載したものである(括弧内の数値は圧縮前のサイズを意味する)。圧縮データ500は、元データを所定のサイズ(図では64KB)のブロックに分割して圧縮を行ったもので、各ブロックの開始アドレスを示すインデックスデータ501、および圧縮対象である各ブロックの並びであるブロックデータの並び502を含んで構成される。
【0045】
ブロックの詳細503は、各ブロックに含まれる圧縮対象データを記載したものであり、圧縮識別子、レコード長、サブブロックの並び、および余りデータで構成される。サブブロックは、上記で説明した問題が発生しないサブブロックサイズでブロックを分割して圧縮対象ブロックとしたものであり、図では各ブロックを16380バイト(レコード数1365個に相当するサイズ)毎に分割した圧縮対象ブロックを圧縮したデータであり、余りデータは、サブブロックサイズ(ここでは16380バイト)で割り切れない余りデータ(ここでは16バイト)である。
【0046】
サブブロックの詳細504は、各サブブロックに含まれるデータを記載したものであり、複数の列圧縮識別子および列圧縮データを含んで構成される。例えば列00圧縮データは、1365個のレコードにおける列00の値を圧縮したものであり、元のデータサイズは1365バイトである。
【0047】
図7は、ブロックの詳細503に含まれる圧縮識別子122の値を記載したものである。圧縮識別子122は、各ブロックを圧縮する際の方式を示すもので、00(非圧縮)、01(列方向圧縮)、02(行方向圧縮)が定義される。00(非圧縮)は、圧縮対象のブロックに含まれるデータに何ら規則性がなく、圧縮してもサイズ削減効果を得られない場合に使用する識別子であり、01(列方向圧縮)は列方向で圧縮した場合にサイズ削減効果を得られる場合に使用する識別子であり、02(行方向圧縮)は行方向、すなわち通常どおりデータを先頭から1バイトずつ処理したほうがサイズ削減効果を得られる場合に使用する識別子である。
【0048】
図8は、サブブロックの詳細504に含まれる列圧縮識別子142の値を記載したものである。列圧縮識別子142は、圧縮対象の各列を圧縮する際の方式を示すもので、00(非圧縮)、01(ランレングス符号)、02(固定長ビット符号)、03(ハフマン符号)等を定義する。00(非圧縮)は、圧縮対象の列に含まれるデータに何ら規則性がなく、圧縮してもサイズ削減効果を得られない場合に使用する識別子であり、01(ランレングス符号)は圧縮対象の列に含まれるデータに対してランレングス符号による圧縮を行うことによりサイズ削減効果を得られる場合に使用する識別子である。02(固定長ビット符号)、03(ハフマン符号)についても同様で、それぞれの方式によってサイズ削減効果を得られる場合に使用する識別子である。
【0049】
なお、固定長ビット符号とは、例えば8ビットの記号を圧縮する際、元データに含まれる記号が高々16個しか存在しない場合に、16個を表現可能な4ビットの符号に置換して出力することによりデータサイズを削減する方式である。また、ハフマン符号とは、記号の出現確率を求めて最小冗長符号を出力することによりデータサイズを削減する方式である。実施例1は、各列の圧縮を行う際、最もサイズ削減効果が高い圧縮方法を選択して使用するものであり、一般的に使用されている技術をそのまま利用することを想定しているため、各圧縮方法の詳細については特に記載しない。
【0050】
図9は、ブロックデータ圧縮部220がデータを圧縮する際に参照する圧縮定義ファイル700について記載したものである。圧縮定義ファイル700には、開始アドレス701、圧縮識別子702、レコード長703が記載されている。一般的に、カーナビのデータベースにおいて、1つのファイルに含まれるデータがすべて同一のサイズを有する固定長レコードの並びであることは稀であり、固定長レコードの並びの他に、何ら規則性が無いデータや、通常のテキストデータのように列方向の圧縮に適さないデータも含まれる。 図9は、アドレス0x00000000からは1レコード12バイトである固定長レコードの並びが格納されており、同様に、アドレス0x001A0000からは何ら規則性が無いデータが、アドレス0x001B0000からは1レコード8バイトである固定長レコードの並びが、アドレス0x00300000からはテキストデータが、アドレス0x00310000からは何ら規則性が無いデータが格納されている様子を示している。圧縮定義ファイルは、これらの格納状況を踏まえ、ブロックデータ圧縮部220がデータを圧縮する際、各ブロックに適用する圧縮方法を決定するために使用される。
【0051】
以降、ツリーデータを圧縮してカーナビに格納し、カーナビにおいて圧縮されたツリーデータを参照する際の処理の流れに沿って、実施例1を説明する。
【0052】
図10は、列方向データ圧縮装置200を用いてツリーデータを圧縮する際、単位サイズ設定部230が表示する単位サイズ設定画面231を示したものである。単位サイズ設定画面231には、対象ファイル232、圧縮定義ファイル233、ブロックサイズ234、および端末キャッシュ容量235を入力する欄が存在する。対象ファイル232は、記憶媒体250上で元データ600が位置する場所を入力する欄、圧縮定義ファイル233は、記憶媒体250上で圧縮定義ファイル700が位置する場所を入力する欄、ブロックサイズ234は図6に示した各ブロックのサイズ(圧縮前のサイズ)を入力する欄、端末キャッシュ容量235は、列方向データ解凍装置100が備えるキャッシュメモリ170の容量を入力する欄である。これらのパラメータを入力し、OKボタン239を押下することで圧縮処理が開始される。
【0053】
図11は、OKボタン239が押下された後の、ブロックデータ圧縮部220の動作を示すフローチャートである。ブロックデータ圧縮部220は、まず、対象ファイル232に入力されたファイル(元データ)のサイズを取得する(ステップS2201)。
【0054】
次に、ブロックサイズ234に入力されたブロックサイズをもとに、元データに含まれるブロック数を計算する(ステップS2202)。例えば、元データのサイズが67588096バイト、ブロックサイズが64KB(65536バイト)の場合、ブロック数は、67588096を65536で割った値(小数点以下切り上げ)であり、1032になる。なお、1032番目のブロックのサイズは、65536で割り切れない20480バイトになる。
【0055】
次に、ブロック毎に繰り返されるループ処理のカウンタ変数iを0に初期化する(ステップS2203)。
【0056】
次に、変数iが、ステップS2202で求めたブロック数未満であるかどうかを判定する(ステップS2204)。変数iがブロック数未満である場合、インデックスデータ501に、ブロックデータの並び502における処理中のブロックの開始アドレス(オフセットデータ)を出力する(ステップS2205)。
【0057】
次に、圧縮定義ファイル700を参照して、処理中のブロックを圧縮する際に使用する圧縮識別子およびレコード長を取得する(ステップS2206)。これは、圧縮定義ファイルの各行を走査し、処理中のブロックのアドレスに対応する圧縮識別子およびレコード長を取得することにより行われる。
【0058】
次に、ブロックデータの並び502に、取得した圧縮識別子およびレコード長を出力する(ステップS2207)。
【0059】
次に、圧縮識別子に応じて処理を分岐させる(ステップS2208)。圧縮識別子が00(非圧縮)の場合、元データの内容(ブロック1からブロック1031の場合は64KB、ブロック1032の場合は20480バイト)をそのままブロックデータの並び502に出力する(ステップS2209)。圧縮識別子が01(列方向圧縮)の場合、列方向の圧縮を行う(ステップS2210)。列方向圧縮の詳細については後述する。圧縮識別子が02(行方向圧縮)の場合は、元データを行方向に圧縮(Zlib等の公知の圧縮アルゴリズムを使用)して、圧縮データをブロックデータの並び502に出力する(ステップS2211)。以上の3ステップのいずれかが完了した後、カウンタ変数iを1加算して、ステップS2204に戻る(ステップS2212)。以上のステップS2204からステップS2212までの処理を全てのブロックに対して繰り返し、ステップS2204において変数iがブロック数に等しくなった時点で、データの圧縮処理を終了し、圧縮データ500として記憶媒体250に格納する。
【0060】
図12は、図11のステップS2210で実行される、列データ圧縮部240の動作を示すフローチャートである。列データ圧縮部240は、まず、端末キャッシュ容量235に入力されたキャッシュメモリ容量、および圧縮定義ファイルから取得されたレコード長をもとに、サブブロックサイズを計算する(ステップS2401)。例えば、キャッシュメモリ容量が32KB、1レコードのサイズが12バイトの場合、32KBのうち半分(16KB)が解凍後のデータ保持に使用可能であると想定して、16KBに格納できる最大のレコード数のサイズがサブブロックサイズになる。すなわち、16KB÷12バイト=16380バイト(余り4バイト)がサブブロックサイズとなる。
【0061】
次に、ブロックサイズ234に入力されたブロックサイズと、ステップS2402で求めたサブブロックサイズから、サブブロック数と余り領域のサイズを計算する(ステップS2402)。ブロックサイズが65536バイト、サブブロックサイズが16380バイトであるので、サブブロック数は4、余り領域のサイズは16バイトとなる。
【0062】
次に、サブブロック毎に繰り返されるループ処理のカウンタ変数jを0に初期化する(ステップS2403)。
【0063】
次に、変数jがサブブロック数未満であるかどうかを判定する(ステップS2404)。変数jがサブブロック数未満である場合、レコードの各桁に対して繰り返されるループ処理のカウンタ変数kを0に初期化する(ステップS2405)。
【0064】
次に、変数kがレコード長未満であるかどうかを判定する(ステップS2406)。変数kがレコード長未満である場合、列kの圧縮処理を行う(ステップS2408)。列kの圧縮処理については後述する。
【0065】
次に、カウンタ変数kを1加算してステップS2406に戻る(ステップS2409)。
【0066】
以上のステップS2406からステップS2409までの処理を全ての列に対して繰り返し、ステップS2406において変数kがレコード長に等しくなった時点で、カウンタ変数jを1加算して、ステップS2404に戻る(ステップS2407)。
【0067】
以上の処理を各サブブロックに対して繰り返し、ステップS2404において変数jがサブブロック数に等しくなった時点で、残りの入力データ(すなわちステップS2402において算出した余り領域のサイズ分のデータ)を、ブロックデータの並び502にそのまま出力して、列データの圧縮処理を終了する(ステップS2410)。
【0068】
図13は、図12のステップS2408で実行される、列kの圧縮処理を示すフローチャートである。まず、列kの圧縮に使用する列圧縮識別子を決定する(ステップS2421)。この処理は、列kに含まれる記号の出現頻度をカウントすることにより、00(非圧縮)、01(ランレングス符号)、02(固定長ビット符号)、03(静的ハフマン符号)のどの方式を用いれば圧縮後のサイズが最も小さくなるかを計算することにより行う。
【0069】
次に、圧縮処理に使用する変数n、pSrc、pDestを初期化する(ステップS2422)。変数nは、処理済み入力データサイズ(バイト数)を示す変数であり、0に初期化する。変数pSrcは、元データのアドレスを示す変数であり、列kのデータの先頭アドレスで初期化する。変数pDestは、圧縮データの出力先アドレスで初期化する。 次に、変数nが列kのサイズ(すなわち1365)未満であるかどうかを判定する(ステップS2423)。変数nが列kのサイズ未満である場合、変数pSrcが示すアドレスに存在する1バイトを、列圧縮識別子が示す方式でエンコードし、変数pSrcをレコード長だけ加算、および変数nを1加算する(ステップS2424)。エンコードされた結果が1バイト未満、かつ変数nが列kのサイズ未満である場合、ステップS2424に戻る。エンコードされた結果が1バイトになるか、または変数nが列kのサイズに等しい場合,ステップS2426へ進む(ステップS2425)。
【0070】
pSrcによって示される1バイト以上の記号が、1バイトにエンコードされた時点で、エンコードされた値(1バイト)をpDestが示すアドレスに出力するとともに、pDestの値を1加算して、ステップS2423に戻る(ステップS2426)。以上のステップS2423からステップS2426までの処理を列kに含まれる記号の数だけ繰り返した結果、変数nの値が列kのサイズに等しくなった時点で、列kの圧縮処理を終了する。
【0071】
以上の図11から図13を用いて説明したブロックデータ圧縮部220および列データ圧縮部240の動作によって、図6に示した圧縮データ500が作成される。このようにして作成された圧縮データ500は、列方向データ解凍装置100の記憶媒体150にコピーされ、アプリケーションソフトによって使用される。
【0072】
図14は、実施例1における、アプリケーションソフト実行部110からブロックデータ解凍部120へ要求されるデータ取得要求の例を示したものである。この例では、アドレス0x00010000から始まる100KBのデータを参照する様子を示している。以降、この要求に対する列方向データ解凍装置100の動作に沿って説明する。
【0073】
図15は、アプリケーションソフト実行部110からデータ取得要求を受けた際の、ブロックデータ解凍部120の動作を示すフローチャートである。ブロックデータ解凍部120は、まず、要求されたアドレスおよび要求サイズをもとに、対象のブロック範囲を計算する(ステップS1201)。図14に示した要求の場合、アドレス0x00010000から始まる100KBを含むブロックであるブロック2からブロック3が対象ブロックの範囲となる。
【0074】
次に、対象ブロックの範囲から1ブロック分の圧縮データを記憶媒体150から読み込み、主記憶装置160に格納する(ステップS1202)。この処理は、インデックスデータ501が示すブロック2の開始アドレス0x00001520から、ブロック2の終了アドレス(次のブロック3の開始アドレスから1を減算した値)である0x00005043までを読み込むことにより行われる。
【0075】
次に、読み込まれたブロックの先頭から、圧縮識別子およびレコード長を取得する(ステップS1203)。
【0076】
次に、取得した圧縮識別子に応じて処理を分岐する(ステップS1204)。圧縮識別子が00(非圧縮)の場合、主記憶装置160に格納したブロックデータをそのままアプリケーションソフトに渡す(ステップS1205)。圧縮識別子が01(列方向圧縮)の場合、主記憶装置160に格納したブロックデータに対して列方向解凍処理を行う(ステップS1206)。列方向解凍処理の詳細は後述する。
【0077】
圧縮識別子が02(行方向圧縮)の場合、主記憶装置160に格納したブロックデータに対して行方向の解凍処理(Zlib等の公知の圧縮アルゴリズムを使用)を行い、解凍し復元した結果を主記憶装置160に格納してアプリケーションソフトに渡す(ステップS1207)。
【0078】
以上の3ステップのいずれかが実行されたのち、対象ブロックの範囲に含まれる全てのブロックの解凍処理が完了したかどうかを判定し、まだ解凍されていないブロックがある場合はステップS1202に戻る(ステップS1208)。
【0079】
S1202に戻った後の処理は上記と同様であり、ブロック3のデータに対しては、インデックスデータ501の内容からブロック3の格納アドレス(0x00005044から0x00008212)を取得し、ブロック3のデータを読み込み、解凍処理を行う。以上の処理を繰り返した結果、ステップS1208において全てのブロックの解凍が完了したと判定された場合、ブロックデータの解凍処理を終了する。
【0080】
図16は、図15のステップS1206で実行される、列データ解凍部140の動作を示すフローチャートである。列データ解凍部140は、まず、キャッシュメモリ170の容量から、サブブロックサイズを計算する(ステップS1401)。この計算処理は、列方向データ圧縮装置200におけるサブブロックサイズの計算処理と同一の計算式によってなされる。すなわち、キャッシュメモリ容量が32KB、1レコードのサイズが12バイトの場合、32KBのうち半分(16KB)が解凍後のデータ保持に使用可能であると想定して、16KBに格納できる最大のレコード数のサイズ(16380バイト)がサブブロックサイズになる。
【0081】
次に、処理中のブロックに含まれるサブブロック数および余りサイズを計算する(ステップS1402)。この計算処理も、列方向データ圧縮装置200におけるサブブロック数の計算処理と同一であり、サブブロック数は4、余りサイズは16バイトになる。
【0082】
次に、各サブブロックに対して繰り返されるループ処理のカウンタ変数jを0に初期化する(ステップS1403)。
【0083】
次に、変数jがサブブロック数未満であるかどうかを判定する(ステップS1404)。変数jがサブブロック数未満である場合、各列に対して繰り返されるループ処理のカウンタ変数kを0に初期化する(ステップS1405)。
【0084】
次に、変数kがレコード長未満であるかどうかを判定する(ステップS1406)。変数kがレコード長未満である場合、列kのデータを解凍する(ステップS1408)。列kの解凍処理の詳細は後述する。
【0085】
次に、カウンタ変数kを1加算して、ステップS1406に戻る(ステップS1409)。ステップS1406からステップS1409の処理を各列に対して繰り返した結果、変数kがレコード長に等しくなった場合は、カウンタ変数jを1加算して、ステップS1404に戻る(ステップS1407)。
【0086】
以上の処理を各サブブロックに対して繰り返した結果、変数jの値がサブブロック数に等しくなった場合は、余り領域をそのままアプリケーションソフトに返却する(ステップS1410)。
【0087】
図17は、図16のステップS1408において実行される、列kのデータの解凍処理を示すフローチャートである。まず、圧縮データの先頭から、列圧縮識別子を取得する(ステップS1421)。
【0088】
次に、解凍処理に用いる変数n、pSrc、pDestを初期化する(ステップS1422)。変数nは、出力したデータサイズ(バイト数)を示す変数であり、0に初期化される。変数pSrcは、圧縮データの格納アドレスを示す変数であり、圧縮データの先頭アドレス、または、直前の列k−1の解凍が終了した時点でのpSrcの値に初期化される。変数pDestは、列kの場合、解凍データ出力先の先頭アドレス+k(列幅が1バイトの場合)に初期化される。
【0089】
次に、変数が列kのサイズ(すなわち1365)未満であるかどうかを判定する(ステップS1423)。
【0090】
変数nが列kのサイズ未満である場合、変数pSrcが示すアドレスに存在する1バイトを列圧縮識別子が示す方式でデコードし、変数pSrcを1加算する(ステップS1424)。
【0091】
通常、1バイトからは1以上のバイト数のデータがデコードされるため、変数pDestの位置にデコードされた1バイトを出力し、pDestの値をレコード長だけ加算するとともに、変数nを1加算する処理を繰り返す(ステップS1425)。
【0092】
圧縮データ1バイトからデコードされる複数のバイトの出力が完了した後、ステップS1423に戻る(ステップS1426)。
【0093】
以上のステップS1423からステップS1426までの処理を繰り返した結果、変数nの値が列kのサイズに等しくなった場合は、列kのデータの解凍処理を終了する。
【0094】
以上の図15から図17で説明したブロックデータ解凍部120および列データ解凍部140の動作によって、アプリケーションソフト実行部から要求された位置にある圧縮データの解凍が行われる。
【0095】
以上が、実施例1のツリーデータ圧縮システムにおけるデータ圧縮処理およびデータ解凍処理の流れである。なお、図18は、実施例1による圧縮データの解凍処理における、キャッシュメモリ170の状態を示したものである。列00の参照によってレコード#1からレコード#1365までがキャッシュメモリ170に格納される状態は図5と同一であるが、レコード#1365まで処理した後に、列01の解凍処理を実行するため、キャッシュメモリ170上のエントリ0の内容は置き換わらない。すなわち、図16および図17に示した処理の実行において、キャッシュメモリ170の不要な更新が抑制されるため、圧縮されたデータを高速に解凍することが可能となる。
【実施例2】
【0096】
以下、図19から図30を用いて、実施例2の走行履歴データ閲覧システムについて説明する。実施例2は、カーナビの走行履歴データをセンタ装置に収集し、各種の端末から参照可能にするものである。走行履歴とは、カーナビの現在地の座標を1秒等の所定の時間毎に記録したデータであり、カーナビで不具合が発生した時の状況確認に役立つほか、近年では、ユーザーがセンタ装置にアップロードした走行履歴を用いて、地図上に走行経路を重畳描画して旅の思い出作りを支援するといったサービスも提供されている。
【0097】
なお、走行履歴データを収集する方法としては、SDカード等の外部記録媒体をカーナビに接続して出力する、携帯電話等の通信装置をカーナビに接続して通信ネットワーク経由でセンタ装置へアップロードする、ディーラーにおいて保守端末を用いてカーナビから取り出す等の方法が用いられているが、本実施例では、この走行履歴をセンタ装置に収集する方法については特に記載せず、センタ装置に走行履歴が収集されていることを前提に、圧縮された走行履歴を各種の端末に配信する方法について説明する。
【0098】
以降、実施例1との差異を中心に実施例2を説明する。実施例2において、列方向データ解凍装置100は走行履歴を閲覧する端末、列方向データ圧縮装置200は、圧縮された走行履歴データを配信するセンタ装置に相当する。
【0099】
図19は、実施例2における走行履歴データ閲覧システムの全体構成図である。実施例2の全体構成図は、図1に示した実施例1の全体構成図と比較して、圧縮データ要求部180および圧縮データ選択部280が追加されている。また、記憶媒体250には複数の圧縮データ510から530が格納されている。また、実施例1で記載した圧縮定義ファイル700は存在しない。これは、走行履歴データは8バイトの固定長レコードで構成されていることを想定しており、ブロック毎に圧縮方法を切り替える必要性が無いためである。
【0100】
図20は、走行履歴データのフォーマットおよびデータの例を示したものである。走行履歴データの1レコードは、X座標(4バイト)およびY座標(4バイト)によって構成される。走行履歴データは、車両が走行中に所定のサイクルで収集したXY座標の並びによって構成されており、図では、例として10地点の座標の並びを示している。
【0101】
図21は、元データ610に含まれる走行履歴データの並びを16進数で表記した例、および圧縮データ510に含まれる列00の圧縮データの例を記載したものである。走行履歴データの例は、理解し易いように、1レコードのサイズである8バイト単位で改行して記載している。ここで着目すべき内容は、X座標およびY座標のそれぞれについて、4バイトを使用するほどの大きな数値が格納されることは滅多に無いため、上位バイトはほとんど0または1等の小さな値になっている点である。したがって、実施例1で記載したツリーデータと同様に、列方向にデータを圧縮することで圧縮率の向上を期待できる。
【0102】
図22は、記憶媒体250に格納される、圧縮データ510から530を示したものである。圧縮データ510はキャッシュメモリ容量が8KBである列方向データ解凍装置用の圧縮データ、圧縮データ520はキャッシュメモリ容量が16KBである列方向データ解凍装置用の圧縮データ、圧縮データ530はキャッシュメモリ容量が32KBである列方向データ解凍装置用の圧縮データである。
【0103】
図23は、キャッシュメモリ容量が8KBである列方向データ解凍装置用の圧縮データ510の詳細を示したものである(括弧内の数値は圧縮前のサイズを意味する)。キャッシュメモリ容量8KBの半分である4KBに格納可能なレコード数(1レコードのサイズは8バイト)は512レコードであり、したがってサブブロックのサイズは512レコード×8バイトである4096バイトになる。サブブロックに含まれる各列のサイズは、512バイトになる。
【0104】
図24は、キャッシュメモリ容量が16KBである列方向データ解凍装置用の圧縮データ520の詳細を示したものである(括弧内の数値は圧縮前のサイズを意味する)。キャッシュメモリ容量16KBの半分である8KBに格納可能なレコード数(1レコードのサイズは8バイト)は1024レコードであり、したがってサブブロックのサイズは1024レコード×8バイトである8192バイトになる。サブブロックに含まれる各列のサイズは、1024バイトになる。
【0105】
図25は、キャッシュメモリ容量が32KBである列方向データ解凍装置用の圧縮データ530の詳細を示したものである(括弧内の数値は圧縮前のサイズを意味する)。キャッシュメモリ容量32KBの半分である16KBに格納可能なレコード数(1レコードのサイズは8バイト)は2048レコードであり、したがってサブブロックのサイズは2048レコード×8バイトである16384バイトになる。サブブロックに含まれる各列のサイズは、2048バイトになる。
【0106】
なお、圧縮データ510から530のいずれも、キャッシュメモリ容量がレコードサイズの倍数となっているため、図6に存在している余り領域は存在しない。
【0107】
以降、走行履歴データを配信する流れに沿って、実施例2を説明する。
【0108】
図26は、列方向データ圧縮装置200を用いて走行履歴データを圧縮する際、単位サイズ設定部230が表示する単位サイズ設定画面238を示したものである。単位サイズ設定画面238には、実施例1と同様に、対象ファイル232、ブロックサイズ234を入力する欄がある。実施例1との差異は、レコード長236およびサポートするキャッシュメモリ容量を指定するボタン237が追加されており、また、圧縮定義ファイル700を入力する欄は存在しない点である。サポートするキャッシュメモリ容量を指定するボタン237は、走行履歴データを閲覧する列方向データ解凍装置のキャッシュメモリ容量を指定するものであり、例では、キャッシュメモリ170のサイズが、それぞれ8KB、16KB、および32KBである複数の端末用の圧縮データを作成する設定を示している。 図27は、単位サイズ設定画面238においてOKボタン239が押下された後の、ブロックデータ圧縮部220の動作を示すフローチャートである。ブロックデータ圧縮部220は、まず、単位サイズ設定画面238に入力された、サポートするキャッシュメモリ容量の種別を取得する(ステップS2221)。
【0109】
次に、指定されたすべてのキャッシュメモリ容量の種別分の圧縮データを作成したかどうかを判定し(ステップS2222)、作成が完了していない場合は、未作成である圧縮データを作成する(ステップS2223)。ステップS2223において実行される圧縮データ作成の流れは、実施例1の図11に示した内容と同一である。
【0110】
以上の動作によって、キャッシュメモリ170の容量が異なる各列方向データ解凍装置用の圧縮データが作成される。
【0111】
図28は、アプリケーションソフト実行部110からデータを要求された時の、ブロックデータ解凍部120の動作を示すフローチャートである。図28は、実施例1の図15とほぼ同様であるが、一連の処理の開始の前に圧縮データ取得処理初期化を行う点と(ステップS1810)、1ブロック分のデータを取得する処理が通信ネットワーク経由になっている点が異なる(ステップS1820)。
【0112】
図29は、図28のステップS1810およびステップS1820において実行される、圧縮データ要求部180と圧縮データ選択部280の間における、圧縮データ取得処理初期化と、1ブロック分のデータを受信する処理の流れを示したものである。ステップS1810においては、まず、圧縮データ要求部180から圧縮データ選択部280へ、対象ファイルの名称が送信される(ステップS1811)。これを受けて、圧縮データ選択部280から圧縮データ要求部180へ、対象ファイルについてサポートしているキャッシュメモリ容量が通知される(ステップS1812)。実施例2の場合、対象ファイルについて、8KB、16KB、および32KBのキャッシュメモリ容量を有する列方向データ解凍装置向けの圧縮データを送信可能であることが通知される。これを受けて、圧縮データ要求部180から圧縮データ選択部280へ、キャッシュメモリ170の容量が通知される(ステップS1813)。これを受けて、圧縮データ選択部280から圧縮データ要求部180へ、指定された圧縮データを送信可能な状態になったことが通知される(ステップS1814)。
【0113】
なお、ステップS1812において、圧縮データ選択部280から通知されたキャッシュメモリ容量の中に、キャッシュメモリ170の容量と合致するものがなければ、圧縮データ要求部180は警告を表示する。図30は、この警告を表示するアプリケーションソフト実行画面111の例を示したものであり、受信した圧縮データがこの列方向データ解凍装置にとって最適なものではないことをユーザーに伝えるメッセージ112を記載したものである。実施例2では、このような場合でも解凍性能が低下するだけで解凍処理自体を続行することは可能のため、圧縮データ要求部180はそのまま処理を続行することを想定しているが、ここで処理を停止するとしても良い。
【0114】
図29のステップS1821以降は、図28のステップS1820における、1ブロック分の圧縮データを送受信する流れを示したものであり、まず、圧縮データ要求部180から圧縮データ選択部280へ、必要なブロックの番号が送信される(ステップS1821)。これを受けて、圧縮データ選択部280から圧縮データ要求部180へ、指定されたブロック番号に対応するブロックの圧縮データが送信される(ステップS1822)。圧縮データ要求部180は、受信したブロックをブロックデータ解凍部120に渡し、実施例1と同様の手順で解凍処理が行った上で、解凍したデータをアプリケーションソフトに渡す。以降のブロックについても同様である。
【0115】
以上が、実施例2の走行履歴データ閲覧システムにおけるデータ圧縮処理およびデータ解凍処理の流れである。このように、性能が異なる各種の端末向けにあらかじめ複数の圧縮データを用意しておくことで、各端末にとって最も高速にデータを閲覧可能となる圧縮データを提供することが可能となる。
【実施例3】
【0116】
以下、図31を用いて、実施例2とは別の形態の走行履歴データ閲覧システムについて説明する。
【0117】
図31は、実施例3における走行履歴データ閲覧システムの全体構成図である。実施例3の全体構成図は、図19に示した実施例2の全体構成図と比較して、ブロックデータ再圧縮部291、列データ再圧縮部292、ブロックデータ解凍部293、列データ解凍部294、主記憶装置260、キャッシュメモリ270が追加されている。また、記憶媒体250に格納する圧縮データは、圧縮データ540の1つである。また、圧縮データ選択部280は存在しない。
【0118】
以降、走行履歴データを圧縮して配信する際の処理の流れに沿って、実施例3を説明する。
【0119】
実施例3における走行履歴データの圧縮処理は、実施例2と基本的に同様である。ただし、作成される圧縮データは、圧縮データ540の1つであり、このデータは、列方向データ圧縮装置200自身が備えるキャッシュメモリ270にとってもっとも解凍性能が高い圧縮データである。すなわち、仮にキャッシュメモリ270の容量が32KBであるなら、圧縮データ540の内容は図25に示した圧縮データと同様である。
【0120】
また、列方向データ圧縮装置200と列方向データ解凍装置100の間の通信シーケンスについても、実施例2の図29と同様である。ただし、実施例3における列方向データ圧縮装置200では、列方向データ解凍装置100からの要求に対して、まず、列方向データ解凍装置100のキャッシュメモリ170の容量が、キャッシュメモリ270の容量に一致するかを調べる。
【0121】
容量が一致すれば、圧縮データ540を送信し、一致しなければ、ブロックデータ解凍部293、および列データ解凍部294において圧縮データ540は解凍され、次に、ブロックデータ再圧縮部291、および列データ再圧縮部292において、列方向データ解凍装置100からの要求内容に従ってデータが再圧縮されて送信される。
【0122】
ブロックデータ解凍部293の動作は、図15に示した列方向データ解凍装置100でのブロックデータ解凍処理と同様であり、列データ解凍部294の動作は、図16に示した列方向データ解凍装置100での列データ解凍処理と同様である。ブロックデータ再圧縮部291の動作は、図11に示したブロックデータ圧縮処理と同様であり、列データ再圧縮部292の動作は、図12に示した列データ圧縮処理と同様である。
【0123】
以上の構成とすることにより、実施例3においては、実施例2のような複数の圧縮データを保持する必要がなく単一の圧縮データを保持すればよい。
【0124】
なお、このような構成とする場合、圧縮データを一旦解凍して再圧縮する処理が加わるため、列方向データ圧縮装置200における処理時間が増加するが、これを削減するために、列データ解凍部294、および列データ再圧縮部292における圧縮解凍処理を、複数の処理装置を用いて列毎に並列に実行する構成としても良い。
【符号の説明】
【0125】
100:列方向データ解凍装置
110:アプリケーションソフト実行部
120:ブロックデータ解凍部(列方向データ解凍装置)
140:列データ解凍部(列方向データ解凍装置)
150:記憶媒体(列方向データ解凍装置)
160:主記憶装置(列方向データ解凍装置)
170:キャッシュメモリ(列方向データ解凍装置)
180:圧縮データ要求部
200:列方向データ圧縮装置
220:ブロックデータ圧縮部
230:単位サイズ設定部
240:列データ圧縮部
250:記憶媒体(列方向データ圧縮装置)
260:主記憶装置(列方向データ圧縮装置)
270:キャッシュメモリ(列方向データ圧縮装置)
280:圧縮データ選択部
291:ブロックデータ再圧縮部
292:列データ再圧縮部
293:ブロックデータ解凍部(列方向データ圧縮装置)
294:列データ解凍部(列方向データ圧縮装置)
300:通信ネットワーク
500:圧縮データ(実施例1)
510:圧縮データ(実施例2、8KBキャッシュ用)
520:圧縮データ(実施例2、16KBキャッシュ用)
530:圧縮データ(実施例2、32KBキャッシュ用)
540:圧縮データ(実施例3)
600:元データ(実施例1)
610:元データ(実施例2および実施例3)
700:圧縮定義ファイル
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22
図23
図24
図25
図26
図27
図28
図29
図30
図31