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