(57)【要約】【課題】ページ単位で圧縮あるいは伸張可能なデータベース圧縮装置を提供する。【解決手段】データベース管理システムと、ユーザテーブルを管理する論理ページを記録するための論理ページ用メモリと、可変長の圧縮ページを表形式で管理するページ管理テーブル内の圧縮ページを記録するための物理ページ用メモリと、データベース管理システムに配置され、論理ページ用メモリに記録される未圧縮ページを圧縮する圧縮ライブラリと、データベースファイルを記録・格納するストレージと、を備え、データベース管理システムは、ページ単位でデータを圧縮／伸張する。【選択図】図２
2013101470.tif 000002
【特許請求の範囲】
【請求項１】
データベース管理システムと、
ユーザテーブルを管理する論理ページを記録するための論理ページ用メモリ領域と、可変長の圧縮ページを表形式で管理するページ管理テーブル内の圧縮ページを記録するための物理ページ用メモリ領域と、
前記データベース管理システムに配置され、前記論理ページ用メモリ領域に記録される未圧縮ページを圧縮する圧縮ライブラリと、
データベースファイルを記録・格納するストレージと、を備え、
前記データベース管理システムは、ページ単位でデータを圧縮／伸張するデータベース圧縮装置。
【請求項２】
前記データベース管理システムは、
ＳＱＬ文を解釈して処理するＳＱＬコンパイル部と、
前記ＳＱＬコンパイル部での処理に応じてデータベースファイルからページ単位でデータを展開するページ管理部と、
前記ページ管理部で展開されたデータをページ単位で圧縮または伸張するデータ圧縮／伸張部と、
前記ページ管理部から展開されたデータを取得し、前記ＳＱＬコンパイル部での処理に応じたデータベースの操作を制御するデータベースエンジン部と、
前記ＳＱＬコンパイル部での処理に応じてデータベースファイルにアクセスして、前記ページ管理部とのファイルの受け渡しを司るファイル操作部と、
を備え、
データベースファイルからのページ単位のデータ読出しと伸張を実行する請求項１記載のデータベース圧縮装置。
【請求項３】
前記データベース管理システムは、
ＳＱＬ文を解釈して処理するＳＱＬコンパイル部と、
前記ＳＱＬコンパイル部での処理に応じて前記ユーザテーブルからレコードデータを展開するページ管理部と、
前記ページ管理部で展開されたレコードデータをページ単位で圧縮するデータ圧縮／伸張部と、
前記データ圧縮／伸張部による圧縮ページを取得して前記ページ管理部への受け渡しを行うデータベースエンジン部と、
前記ＳＱＬコンパイル部での処理に応じて前記ページ管理部から圧縮ページの受け渡しを受け、データベースファイルにアクセスするファイル操作部と、
を備え、
前記ページ管理部は、前記データベースエンジン部から圧縮ページを取得し、レコードデータに変換し、
データベースファイルへの書込みを実行する請求項１記載のデータベース圧縮装置。
【請求項４】
前記ストレージは、ハードディスク装置又はソリッドステートドライブ装置のいずれかである請求項１乃至請求項３のいずれか1項に記載のデータベース圧縮装置。
【請求項５】
前記圧縮ライブラリは、任意のアルゴリズムに入れ替え可能である請求項１乃至請求項４のいずれか1項に記載のデータベース圧縮装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、データベース圧縮装置に関する。
【背景技術】
【０００２】
データベースでは、データを蓄えてあるデータベースファイルが大きくなると、メモリや記憶装置が大規模なものとなる。そのため、データベースファイルを小さくしたい、あるいは大きくしたくない、との要請がある。特に、小型機器へのデータベースの導入に際しては、メモリ容量は大きいがストレージは小さいことから、大量のデータを取り扱うことが難しい。
【０００３】
このようなことから、データベースの圧縮についていくつかの提案がなされている（例えば、特許文献１、特許文献２参照。）。
【０００４】
データベースにおいて、データファイルの内部領域はページ単位で管理され、ページへのアクセスは、ページサイズをもとに行っている。ところが、圧縮されたページサイズは一定でないという問題がある。また、データベースを圧縮するための速度を上げるには、全体を圧縮するのではなく、ページ単位で圧縮あるいは伸張できることが望ましく、圧縮後であっても、通常のデータベースとして操作可能で、テーブルの作成、削除、参照、更新が通常通り実行できることが強く要請されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開平１１−２７２５７５号公報
【特許文献２】特開平９−２６９０２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明が解決しようとする課題は、ページ単位で圧縮あるいは伸張可能なデータベース圧縮装置を提供することである。
【課題を解決するための手段】
【０００７】
実施形態のデータベース圧縮装置は、データベース管理システムと、ユーザテーブルを管理する論理ページを記録するための論理ページ用メモリと、可変長の圧縮ページを表形式で管理するページ管理テーブル内の圧縮ページを記録するための物理ページ用メモリと、
前記データベース管理システムに配置され、前記論理ページ用メモリに記録される未圧縮ページを圧縮する圧縮ライブラリと、データベースファイルを記録・格納するストレージと、を備え、前記データベース管理システムは、ページ単位で圧縮／伸張する。
【図面の簡単な説明】
【０００８】
【図１】本実施形態に係るデータベース圧縮装置の構成例を示す図である。
【図２】圧縮処理の概要について説明する図である。
【図３】テーブルの作成の操作の流れを示すフローチャートである。
【図４】テーブルの削除の操作の流れを示すフローチャートである。
【図５】テーブルの参照の操作の流れを示すフローチャートである。
【図６】テーブルの更新の操作の流れを示すフローチャートである。
【図７】ページの取得の処理の流れを説明する図である。
【図８】ページの更新と圧縮の処理の流れを説明する図である。
【図９】圧縮ページの格納の処理の流れを説明する図である。
【発明を実施するための形態】
【０００９】
以下、本発明の一実施の形態について、図面を参照して説明する。尚、各図において同一箇所については同一の符号を付すとともに、重複した説明は省略する。
【００１０】
まず、本実施形態で用いる主要な用語について説明する。
【００１１】
「ページ」とは、データファイルからデータを読み書きする単位をいう。ページには、テーブルを構成するレコードが、複数格納される。テーブルは、１乃至複数のページに所属している。ユーザは、テーブルに対してレコードの追加や、変更、削除等レコードを操作するが、実際のデータの取り扱いはページ単位となる。
【００１２】
本実施形態に係るデータベース圧縮装置は、ページ単位でデータベースを圧縮するものである。
【００１３】
図１は、本実施形態に係るデータベース圧縮装置の構成例を示す図である。データベース圧縮装置１００は、ＣＰＵ１０、主記憶装置２０、データベース管理システム（以下、ＤＢＭＳという。）３０、ストレージ４０、メモリ５０を主な構成要素としている。
【００１４】
主記憶装置２０の上には、ストレージ４０もしくは他のストレージ装置（図示しない）から読み出されたオペレーティングシステムとして機能するアプリケーション６０が展開される。さらに、ＤＢＭＳ３０が主記憶装置２０の上で展開される。アプリケーション６０の制御のもとでＣＰＵ１０がＤＢＭＳ３０における処理を実行する。
【００１５】
まず、各部を簡潔に説明する。
【００１６】
ＤＢＭＳ３０は、データベースを管理し、データに対するアクセス要求に応えるものである。ＤＢＭＳ３０は、管理するデータの表現形式により、いくつかの種類に分類でき、カード型、リレーショナル型、オブジェクト型などがある。本実施形態では、特定の種類に限定されることはないが、例えばリレーショナル型が典型的といえる。リレーショナルデータベースでは、１件のデータを複数の項目（フィールド）の集合として表現し、データの集合をテーブルと呼ぶ表で表す。ＩＤ番号や名前などのキーとなるデータを利用して、データの結合や抽出を行う。
【００１７】
ＤＢＭＳ３０は、ＳＱＬコンパイル部３１、データベースエンジン部（以下、ＤＢエンジン部という。）３２、ページ管理部３３、データ圧縮／伸張部３４、ファイル操作部３５、圧縮ライブラリ３６から構成されている。
【００１８】
ＳＱＬコンパイル部３１は、ＳＱＬ（構造化問い合わせ言語）文を解釈して処理するものである。
【００１９】
ＤＢエンジン部３２は、ＤＢＭＳ３０がデータベースファイル４１に実際にアクセスして、データを挿入、抽出、更新、削除するために使用するソフトウェア部品である。
【００２０】
ページ管理部３３は、ファイルからページ単位でデータを展開し、ページの取得、ページの更新、ページの圧縮、ページの格納に際して、中心的な機能を果たす。ＤＢエンジン部３２は、ページ管理部３３から展開されたデータを取得し圧縮ページを伸張する。
【００２１】
また、ページ管理部３３は、展開されたページ中のデータをページ単位で更新した後、データ圧縮／伸張部３４に渡すものである。
【００２２】
データ圧縮／伸張部３４は、ページ単位でデータを圧縮または伸張するものである。
【００２３】
ファイル操作部３５は、ストレージ４０中のデータベースファイル４１にアクセスして、ファイルの受け渡しを司るものである。
【００２４】
圧縮ライブラリ３６は、ファイルを圧縮するもので、そのアルゴリズムに特徴を有する。例えば、圧縮方式としてハフマン符号化法に代表される辞書を別途保存する必要がある方式、LZ77符号化法に代表される辞書を別途保存する必要がない方式などのアルゴリズムが用いられる。本実施形態では、圧縮ライブラリそのものは、入れ替えることが可能である。
【００２５】
ストレージ４０は、外部記憶装置であって、データベースファイル４１を記録・格納するものである。例えば、ハードディスク装置や、半導体メモリであるフラッシュメモリを使用したソリッドステートドライブ（ＳＳＤ）装置が好適である。
【００２６】
メモリ５０は、データやプログラムを記憶する記憶装置である。本実施形態では、記憶装置を小さなサイズで固定長にて管理されるページと呼ぶ単位に分割して割り当てを行うページング方式が採用されている。物理メモリ空間、論理メモリ空間ともページ単位に分割して管理される。論理メモリから物理メモリ空間への対応づけは、ページテーブルという構造体で実現される。メモリ５０は、論理ページを記憶する論理ページ用メモリ５１と物理ページを記憶する物理ページ用メモリ５２に分けることができる。本実施形態では、ユーザがデータベースファイルを利用するためのテーブルとしてユーザテーブル５３が設けられ、圧縮ページを表形式で管理するためのテーブルとしてページ管理テーブル５４が設けられる。
【００２７】
以上のように構成されたデータベース圧縮装置１００における圧縮処理の概要について説明する。図２は、圧縮処理の概要について説明する図である。
【００２８】
＜圧縮からＤＢファイルへの書込み＞
アプリケーション６０からＳＱＬコマンドが渡されると、ＤＢエンジン部３２は、ＳＱＬコマンドを解釈する。ここでは、そのＳＱＬコマンドがユーザテーブル５３のレコードＩＤ３０１に新たにレコードを書き込むＩＮＳＥＲＴステートメントであるとする。
【００２９】
ＤＢエンジン部３２は、ページ管理部３３を介して、ユーザテーブル５３を参照する。ユーザテーブル５３には、既にレコードＩＤ１０１、レコードＩＤ２０１にレコードが記録されている。そこで、ＩＮＳＥＲＴステートメントを実行し、ユーザテーブル５３のレコードＩＤ３０１に新たにレコードを書き込む。
【００３０】
本実施形態では、ユーザテーブル５３は論理ページ用メモリ５１によって管理されており、ユーザテーブル５３のレコードＩＤ３０１に記録されたレコードは、論理ページの３ページ目に書き込まれていることがわかる。
【００３１】
論理ページの３ページ目に記録されたレコードＩＤ３０１のレコードは、レコードＩＤ１０１のレコード、レコードＩＤ２０１のレコードに続けて詰めて記録される。
【００３２】
レコードＩＤ３０１のレコードが記録された３ページ目は、まだ圧縮されていない。そこで、未圧縮のページ３を圧縮ライブラリを使用して圧縮する。圧縮されたページ３は、可変長となっている。
【００３３】
ＤＢエンジン部３２は、ページ管理部３３を介して、ページ管理テーブル５４にインサートする。ページ管理テーブル５４では、可変長の圧縮ページを表のように管理するもので、ユーザは、可変長の圧縮ページを固定長のページの集合体のイメージで利用することができる。
【００３４】
ここでは、ページ管理テーブル５４のレコードＩＤ３に圧縮されたページ３がインサートされる。ページ管理テーブル５４の中身は、物理ページ用メモリ５２で管理されている。図２に示す例では、ページ管理テーブル５４の中身は、物理ページ用メモリ５２のページ２に対応していることがわかる。
【００３５】
圧縮ページ３は、物理ページ用メモリ５２のページ２に詰めて、データベースファイル４１に記録・格納される。
【００３６】
＜ＤＢファイルからの読出しから伸張＞
基本的には、圧縮からＤＢファイルへの書込みとは、逆の流れの処理となる。
【００３７】
アプリケーション６０からＳＱＬコマンドがなげられると、ＤＢエンジン部３２は、ＳＱＬコマンドを解釈する。ここでは、そのＳＱＬコマンドが圧縮済みのデータベースファイル４１から、物理ページ用メモリ５２のページ２に詰めて記録・格納されている圧縮ページ３を読出す。圧縮ページ３は、物理ページ用メモリ５２とページ管理テーブル５４との対応から、ページ管理テーブル５４ではレコードＩＤ３として圧縮された状態で展開される。
【００３８】
ＤＢエンジン部３２は、ページ管理部３３を介して、レコードＩＤ３に展開された圧縮ページ３を圧縮ライブラリ３６を使用して伸張する。伸張されたページ３は、論理ページ用メモリ５１のページ３として展開される。ページ３の中には、いくつかのレコードが詰めて記録されている。
【００３９】
論理ページ用メモリ５１とユーザテーブル５３との対応から、論理ページ用メモリ５１のページ３のレコードは、ユーザテーブル５３の各レコードＩＤ毎に、レコードに展開される。ここでは、レコードＩＤ３０１に読み出したレコードがインサートされる。
【００４０】
次に、以上のように構成されたデータベース圧縮装置１００におけるデータベースとしての操作について説明する。本実施形態では、通常のデータベースとして、テーブルの作成、テーブルの削除、テーブルの参照、テーブルの更新が可能である。
【００４１】
図３は、テーブルの作成の操作の流れを示すフローチャートである。
【００４２】
まず、テーブルを作成する（ステップＳ３１）。次いで、コミット時、すなわち、トランザクションによる内容更新を確定する場合には、ページを圧縮する（ステップＳ３２）。圧縮データをデータベースにインサートする（ステップＳ３３）。次いで、ＤＢファイルへの書き込みを行う（ステップＳ３４）。
【００４３】
図４は、テーブルの削除の操作の流れを示すフローチャートである。
【００４４】
まず、目的のページを圧縮したレコードを取得する（ステップＳ４１）。次いで、レコードの伸張を行い、メモリへの展開を行う（ステップＳ４２）。次いで、テーブルの削除処理を行う（ステップＳ４３）。その後、コミット時、ページを圧縮する（ステップＳ４４）。圧縮データをデータベースにインサートする（ステップＳ４５）。次いで、ＤＢファイルへの書き込みを行う（ステップＳ４６）。
【００４５】
図５は、テーブルの参照の操作の流れを示すフローチャートである。
【００４６】
まず、目的のページを圧縮したレコードを取得する（ステップＳ５１）。次いで、レコードの伸張を行い、メモリへの展開を行う（ステップＳ５２）。その後、通常の参照処理を行う（ステップＳ５３）。
【００４７】
図６は、テーブルの更新の操作の流れを示すフローチャートである。
【００４８】
まず、目的のページを圧縮したレコードを取得する（ステップＳ６１）。次いで、レコードの伸張を行い、メモリへの展開を行う（ステップＳ６２）。次いで、通常のテーブルの更新処理を行う（ステップＳ６３）。その後、コミット時、ページを圧縮する（ステップＳ６４）。圧縮データをデータベースにインサートする（ステップＳ６５）。次いで、ＤＢファイルへの書き込みを行う（ステップＳ６６）。
【００４９】
次に、更新処理を行う際の、ページの取得、更新、圧縮、格納の一連の流れにおける、それぞれの処理の詳細について説明する。
【００５０】
＜ページの取得＞
図７は、ページの取得の処理の流れを説明する図である。ページ管理部３３は、ページ単位でデータを展開するために、ファイル操作部３５を介してＤＢファイル４１にアクセスし、２ページ目（ここでは、ページ２）に該当のデータが存在していることを把握する。このページ２は、物理ページ用メモリ５２において、圧縮ページとして詰めて記録・格納されている。ページ管理部３３は、当該圧縮ページを取得し、ＤＢエンジン部３２に受け渡す。ＤＢエンジン部３２は、データ圧縮／伸張部３４を介して、取得した圧縮ページを伸張する。論理ページ用メモリ５１において、伸張された圧縮ページが書き込まれる。
【００５１】
＜ページの更新と圧縮＞
図８は、ページの更新と圧縮の処理の流れを説明する図である。
【００５２】
論理ページ用メモリ５１上で、該当のデータが更新されると、ページ管理部３３は、データ圧縮／伸張部３４を介して、そのデータが含まれるページを圧縮する。ページ管理部３３は、圧縮されたページを、インサートのためＤＢエンジン部３２に受け渡す。
【００５３】
＜圧縮ページの格納＞
図９は、圧縮ページの格納の処理の流れを説明する図である。
【００５４】
ＤＢエンジン部３２は、論理ページ用メモリ５１上にある圧縮されたデータを取得し、ページ管理部３３を介して、物理ページ用メモリ５２上で指定された圧縮ページに通常のレコードとしてインサートする。ページ管理部３３は、ファイル操作部３５を介してＤＢファイル４１にアクセスし、圧縮ページ、ここでは、ページ２としてＤＢファイル４１に格納する。
【００５５】
＜圧縮率等の比較＞
本実施形態に係るデータベース圧縮装置と、従来手法による圧縮率等を比較する。比較する従来手法には、MySQL InnoDB Pluginとし、以下の表に示すようなＤＢファイルを圧縮する。
【表１】
2013101470.tif 000003
【００５６】
MySQL InnoDB Pluginでは、圧縮後のページがKEY_BLOCK_SIZEより大きい場合には、２分割して再圧縮する。全てのページがKEY_BLOCK_SIZE以下になった時点で、終了する。したがって、ここでの比較事例での両者の圧縮率、圧縮回数、圧縮時間は次のように表される。
【００５７】
本実施形態による圧縮率＝圧縮後のページのサイズの合計／圧縮前のファイルサイズ
MySQL InnoDB Pluginによる圧縮率＝圧縮済ページ数×KEY_BLOCK_SIZE／圧縮前のファイルサイズ
本実施形態による圧縮回数＝ｎ
MySQL InnoDB Pluginによる圧縮回数＝ｎ＋ｍ＊２
本実施形態による圧縮時間＝ｎ＊
MySQL InnoDB Pluginによる圧縮時間＝ｎ＊ｔｃｏｍｐ＋ｍ＊ｔｄｉｖ+ｍ＊２＊ｔｃｏｍｐ
このとき、ｎ：ページ数、ｍ：一回目の圧縮率がKEY_BLOCK_SIZE以上となったファイルの数、ｔｃｏｍｐ：圧縮時間、ｔｄｉｖ  ：ページ分割時間とする。
【００５８】
以上から、
本実施形態による圧縮率＝４４５５／９０００＝４９．５％
MySQL InnoDB Pluginによる圧縮率＝４０７×１６／９０００＝７２．４％
となり、圧縮率は２２．９％、上回っている。
【００５９】
また、圧縮回数の比較は、
本実施形態による圧縮回数＝２８９（ページ数）＝２８９回
MySQL InnoDB Pluginによる圧縮回数＝２８９＋１１８（分割したページ数）×２＝５２５回
となり、圧縮回数は２３６回、上回っている。
【００６０】
また、処理時間の比較は、
本実施形態による処理時間＝２８９＊ｔｃｏｍｐ
MySQL InnoDB Pluginによる処理時間＝５２５＊ｔｃｏｍｐ ＋１１８ｔｄｉｖ
となり、（２３６ｔｃｏｍｐ ＋１１８ｔｄｉｖ ）、上回っている。
【００６１】
本実施形態によれば、短い処理速度でページ単位で圧縮／伸張することができ、圧縮後の可変長データにも対応することができ、データベース機能に制約が無い。また、用途に応じて圧縮アルゴリズムを変更することができる。
【００６２】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【００６３】
１００・・・データベース圧縮装置、
１０・・・ＣＰＵ、
２０・・・主記憶装置、
３０・・・データベース管理システム（ＤＢＭＳ）、
４０・・・ストレージ、
５０・・・メモリ、
６０・・・アプリケーション。
【図１】
2013101470.tif 000004
【図２】
2013101470.tif 000005
【図３】
2013101470.tif 000006
【図４】
2013101470.tif 000007
【図５】
2013101470.tif 000008
【図６】
2013101470.tif 000009
【図７】
2013101470.tif 000010
【図８】
2013101470.tif 000011
【図９】
2013101470.tif 000012