JP6004453B2 - 展開マップを用いた改良されたデータアクセスのパフォーマンス - Google Patents

Description

本発明は、データベースシステムに関し、より詳細には、データベースシステムで利用される圧縮技術および展開技術に関する。データベースシステムは、大量のデータを管理し、一般にデータ圧縮を、データオブジェクトを格納するディスクおよび／または記憶装置の数を低減する手段として使用する。

例えば、ニューヨーク州のアーモンクに所在のインターナショナル・ビジネス・マシーンズ・コーポレーションから入手可能なＤＢ２データベースシステムは、ディスク内のデータを透過的に圧縮する圧縮機能の組み合わせを使用するストレージの最適化機能を提供し、ディスク領域の必要量およびストレージインフラの必要量を低減する。ディスクストレージシステムは、データベースソリューションの最も高価な構成要素であることが多いため、ストレージサブシステムを僅かに縮小させるだけでも、データベースソリューション全体のコストをかなり削減することができる。ＤＢ２データベースシステムで利用されるデータ圧縮技術には、Ｒｏｗ Ｃｏｍｐｒｅｓｓｉｏｎ、Ａｄａｐｔｉｖｅ Ｒｏｗ ＣｏｍｐｒｅｓｓｉｏｎおよびＸＭＬ Ｃｏｍｐｒｅｓｓｉｏｎがある。

通常、種々の圧縮技術は、メモリ消費およびストレージ消費を充分に抑制する一方、データにアクセスする際に、中央処理装置（ＣＰＵ）リソースを頻繁に使用する（すなわち、ＣＰＵの使用頻度が高い）。したがって、圧縮データの一部のみにアクセスする必要がある場合に、必要とされるＣＰＵリソースの量を低減する技術は有用であろう。

本発明の一実施形態により、データベースシステムでデータを展開する技術を実行および使用するコンピュータプログラム製品を含む、方法および装置が提供される。圧縮されたデータセット内のデータサブセットに関連するクエリーが受信される。コストモデルを使用して１以上の展開ストラテジーが算出される。コストモデルは、見積もられたフィルターファクタを含む。コストの低い展開ストラテジーが、１以上の展開ストラテジーの評価結果に基づいて選択される。圧縮されているデータセット内で、要求されているデータサブセットを示す１以上のバイトの位置を特定する。選択された展開ストラテジーを用いて、データサブセットに対応する圧縮データの一部のみが展開されると共に、残りのデータセットは、圧縮された状態のままとなる。

本発明の１以上の実施形態の詳細は、添付図面および以下の記載に示す。本発明の他の特徴や利点は、以下の記載および図面並びに請求項から明らかとなるであろう。

１の実施形態に係るデータを展開するプロセス（１００）を示すフローチャート。 １の実施形態で使用されるコンピュータアーキテクチャ（２００）を示す図。

種々の図面における同様の参照記号は、同様の構成要素を示す。

上述したように、ＤＢ２データベース等の多くのデータベースシステムは一般に、或る行のいずれかの列にアクセスする必要がある場合、行全体を圧縮して展開する。しかしながら、テーブルに対してクエリーを実行する場合、行に含まれる複数列のサブセット（またはテーブルの１のページに含まれる複数行から成るサブセット）のみにアクセスする必要があることはよく知られている。本明細書で説明する様々な実施形態は、特定のクエリーに必要なデータを提供すべく、展開されるデータのいずれの部分を展開する必要があるか判断する方法を提供することにより、行の一部にのみアクセスする必要があるクエリーのパフォーマンスを大幅に改善する。

当業者には明らかであるが、本発明の態様は、システム、方法またはコンピュータプログラム製品として具体化することができる。したがって、本発明の態様は、完全なハードウェアの実施形態、（ファームウェア、常駐ソフトウェア、マイクロコード等を含む）完全なソフトウェアの実施形態、または、本明細書で「回路」、「モジュール」または「システム」として参照されるソフトウェアとハードウェアを組み合わせた実施形態を採り得る。さらに、本発明の態様は、コンピュータ読取可能なプログラムコードを有する１以上のコンピュータ読取可能な媒体を備えるコンピュータプログラム製品の形態を採り得る。

１以上のコンピュータ読取可能な媒体の組み合わせを利用することができる。コンピュータ読取可能な媒体は、コンピュータ読取可能な信号媒体またはコンピュータ読取可能な記憶媒体とすることができる。コンピュータ読取可能な記憶媒体は、例えば、電子システム、電子装置或いは電子デバイス、磁気システム、磁気装置或いは磁気デバイス、光学システム、光学装置或いは光学デバイス、電磁気システム、電磁気装置或いは電磁気デバイス、赤外線システム、赤外線装置或いは赤外線デバイス、半導体システム、半導体装置或いは半導体デバイス、または、これらの好適な組み合わせとすることができるが、これらに限られない。コンピュータ読取可能な記憶媒体のさらに具体的な例（包括的でないリスト）は、１本以上のワイヤを備える電気接続、可搬型のコンピュータディスケット、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、読取り専用記憶装置（ＲＯＭ）、消去可能なプログラム可能読取り専用記憶装置（ＥＰＲＯＭまたはフラッシュメモリ）、光ファイバ、持ち運び可能なコンパクトディスク型の読取り専用記憶装置（ＣＤ−ＲＯＭ）、光学式記憶装置、磁気記憶装置、またはこれらの好適な組み合わせを含む。本明細書では、コンピュータ読取可能な記憶媒体は、命令実行システム、命令実行装置、或いは命令実行デバイスによって使用されるプログラム、またはこれらと共に使用されるプログラムを収容または格納可能な有形の媒体とすることができる。

コンピュータ読取可能な信号媒体は、コンピュータ読取可能なプログラムコードを含む伝搬型のデータ信号であって、例えば、ベースバンド内のデータ信号や搬送波の一部であるデータ信号を含み得る。このような伝搬型の信号は、電磁気信号、光学信号、これらの好適な組み合わせを含む様々な形態をとり得るが、これらに限られない。コンピュータ読取可能な信号媒体は、コンピュータ読取可能な記憶媒体ではなく、命令実行システム、命令実行装置或いは命令実行デバイスによって使用されるプログラム、またはこれらのシステム、装置或いはデバイスと共に使用されるプログラムを通信、伝搬または転送可能な任意のコンピュータ媒体とすることができる。

コンピュータ読取可能な媒体に組み込まれるプログラムコードは、無線、有線、光ファイバーケーブル、赤外線等を含む、好適な手段を用いて伝送することができるが、これらに限られない。本発明の態様のためにオペレーションを実行するコンピュータプログラムコードは、Ｊａｖａ（登録商標）、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋等のオブジェクト指向のプログラミング言語や、「Ｃ」プログラミング言語または同様のプログラミング言語等の従来の手続き型のプログラミング言語を含む、１以上のプログラミング言語を組み合わせて記述することができる。プログラムコードは、スタンドアロンのソフトウェアパッケージとしてユーザのコンピュータ上で完全に或いは部分的に実行でき、ユーザのコンピュータ上で部分的に実行すると共にリモートコンピュータ上で部分的に実行でき、または、リモートコンピュータ或いはサーバ上で完全に実行できる。後者の場合では、リモートコンピュータは、ローカルエリアネットワーク（ＬＡＮ）やワイドエリアネットワーク（ＷＡＮ）を含む任意の種類のネットワークを介してユーザのコンピュータに接続でき、または（例えば、インターネットサービスプロバイダを利用したインターネットを介して）外部のコンピュータに接続することもできる。

本発明の態様は、本発明の実施形態に係る方法、装置（システム）およびコンピュータプログラム製品のフローチャート図および／またはブロック図を参照して、以下に説明される。フローチャート図および／またはブロック図の各ブロックと、フローチャート図および／またはブロック図のブロックの組み合わせは、コンピュータプログラム命令によって実行可能であることが理解できるであろう。これらのコンピュータプログラム命令は、マシンを構成する汎用コンピュータのプロセッサ、専用コンピュータのプロセッサ、または他のプログラム可能なデータ処理装置に提供することができ、コンピュータのプロセッサまたは他のプログラム可能なデータ処理装置によって実行される当該コンピュータプログラム命令が、フローチャートおよび／またはブロック図に明記される機能や処理を実行する手段を生成する。

また、これらのコンピュータプログラム命令は、コンピュータ、他のプログラム可能なデータ処理装置、または他のデバイスに指示可能なコンピュータ読取可能な媒体に格納することができ、コンピュータ読取可能な媒体は、当該コンピュータ読取可能な媒体に格納された当該コンピュータプログラム命令が、フローチャートおよび／またはブロック図に明記される機能や処理を実行する命令を備える製品を提供するように機能する。

また、コンピュータプログラム命令は、コンピュータ、プログラム可能な他のデータ処理装置、または他のデバイスにロードして、コンピュータ、プログラム可能な他の装置または他のデバイスで一連の動作ステップを実行させることにより、コンピュータによって実行されるプロセスを提供することができ、コンピュータまたはプログラム可能な他の装置で実行される当該コンピュータプログラム命令が、フローチャートおよび／またはブロック図に明記される機能や処理を実行するプロセスを提供する。

図１に示すように、１の実施形態に係るデータを展開するプロセス１００が、圧縮されたデータセット内のデータサブセットに関連するクエリーを受信することにより開始する（ステップ１０２）。通常、データベースシステムでは、行のいずれの列にアクセスする必要が有るかを示す情報を有するストラクチャーが構築される。例えば、ＤＢ２データベースシステムでは、特定のクエリーのために、いずれの列が述語（プレディケート）を評価する必要が有るのかを示し、また、行を限定するために、いずれの列が検索されて呼び出し元に出力される必要が有るのかを示すストラクチャーが存在する。クエリーの受信に応答して、データベースシステムは、これらのストラクチャーに問い合わせ、述語の評価段階およびリスト選択処理の双方に必要な行の部分（述語の条件に合致する行について返却する必要のある行）を正確に決定する。例えば、２０の列Ｃ１〜Ｃ２０を有するテーブルの場合、以下のクエリーが有り得る。

この場合、クエリーは、列Ｃ１にアクセスして述語を評価する必要があり、述語が真実である場合、列Ｃ１および列Ｃ１７にアクセスする必要がある。説明のために、各列が１０バイト長であり、これらの列が、Ｃ１，Ｃ２，Ｃ３〜Ｃ２０の順に格納されている場合を仮定する。この場合、列Ｃ１は行のバイト位置１〜１０を占有し、列Ｃ１７は行のバイト位置１６１〜１７０を占有する。その結果、ストラクチャーを評価するコードは、行について述語を評価するために、行のバイト１〜１０のみが必要であると決定する。さらに、上述したリスト選択処理のためにＣ１およびＣ１７の双方が必要であるが、Ｃ１は、述語の評価のために予め展開されるため、実際に行が返却されるときには、Ｃ１７のみを展開する必要がある。したがって、上述したクエリーのために、以下の展開ストラテジーが利用できる。

段階１の展開（すなわち、述語を評価するために必要な列の展開）
列Ｃ１（行のバイト１〜１０）のみが必要とされる。

段階２の展開（すなわち、リスト選択処理に必要な残り全ての列の展開）
Ｃ１は既に展開されているため、列Ｃ１７（行のバイト１６１〜１７０）のみが必要とされる。

当業者であれば理解できるように、列が必要とされる前に必要な列のみを展開可能な方法は多数存在し、上述した２段階の例は、例示的な実施形態に過ぎない。例えば、上述した方法の代わりに、段階１において、列Ｃ１およびＣ１７の全てのバイトを展開してもよい。他の実施形態では、行の異なる位置を要求する、より多くの段階を追加することができ、すなわち、例えばグループ化（group by）処理の場合、追加された段階において、当該グループ化処理に必要な列を同様に展開してもよい。したがって、プロセス１００は、１以上の展開ストラテジーを評価する（ステップ１０４）。図１に示す実施形態では、見積もられたフィルターファクタを有するコストモデルを使用し、（当該フィルターファクタが訂正された場合に）最適な展開方法を見つける。例えば、列Ｃ１を展開するのにｎ１サイクルが必要であり、列Ｃ１７を展開するのにｎ１７サイクルが必要であり、述語のフィルターファクタが０．２５である場合（すなわち、行全体の４分の１が述語の条件に合致する場合）、各展開のコストは、ｎ１＋（ｎ１７×０．２５）サイクルである。同様に、ＣＰＵがＣ１からＣ１７までの全ての列を展開する時間がｎ１…ｎ１７であり、かつ、ｎ１…ｎ１７がｎ１＋（ｎ１７×０．２５）サイクル未満である場合は、行全体を展開する方が理に適うであろう。したがって、展開ストラテジーを決定する際に、このようなコストモデル方法を利用することにより、行のアクセスに最適な展開ストラテジーを見つけることができる。当業者であれば理解できるように、このようなコストモデルは拡張可能であり、当該コストモデルを利用することにより、行／ストラテジーの異なる部分について、異なるソフトウェアおよび／またはハードウェアが展開する方法のコストを算出することができる。ステップ１０４の展開ストラテジーの評価に基づいて、低コストの展開ストラテジーが選択される（ステップ１０６）。この文脈では、「サイクル」の語が本実施形態で使われているが、必ずしも実際のサイクルを意味するものではないことに留意すべきである。「最善」の展開ストラテジーを選択するために、複数の展開方法を適切に比較することが可能な如何なる種類の「カウント」や「ＣＰＵユニット」を使用することができる。

最後に、選択された展開ストラテジーを用いて、実際に行にアクセスし、要求されているバイト・データの位置を特定し、当該バイト・データを展開する（ステップ１０８）。上述したクエリーの例では、データベースエンジンは、この時点で、述語を評価するために、圧縮された行のバイト１〜１０にアクセスする必要があることを認識している。したがって、２００バイトの行全体を展開する代わりに、最初の１０バイトのみを展開して停止する展開ロジックが呼び出される。この後、述語を評価することができる。述語の評価が、選択された列を返却する必要がある旨を示す真（ＴＲＵＥ）である場合、データベースエンジンは、列Ｃ１７に必要なバイトのみ（バイト１６１〜１７０）を展開しようと試みる。この例では、展開アルゴリズムは、圧縮データの「サブストリング化（substringing）」を扱うように拡張される。これを実現するために、圧縮データの各トークンについて、当該トークンによって表される正確なバイト数を決定するストラクチャーが構築される。ＤＢ２データベースシステムを含む多くのデータベースシステムは、現在のところ、Ｌｅｍｐｅｌ−Ｚｉｖ圧縮を使用しているが、当業者であれば理解できるように、他の多くの圧縮アルゴリズムを同様に処理することができる。例えば、Ｌｅｍｐｅｌ−Ｚｉｖ圧縮はトークンを使用するが、他の圧縮アルゴリズムは、可変長の列のストラクチャーを認識する他の種類のユニットまたは他のロジックであって、可変長の列が存在する場合に必要とされる一連のバイトを決定可能なユニットまたはロジックを使用することができる。

例えば、８のトークンを有する非常に小さな圧縮ディクショナリが存在し、各トークンが以下の長さを有すると仮定する。

さらに、以下の圧縮された一連のトークンが存在すると仮定する。

プロセスは、上記トークン長テーブルを用いてカウントし、行のバイト１６１〜１７０を得るために、いずれのトークンを展開する必要があるか判断することができる。上記情報が与えられた場合は、以下のように算出することができる。

したがって、圧縮されたストリングを「カウント」することにより、１０番目の圧縮されたトークン「８」の長さが３バイトであることが明らかとなり、行のバイト１５９〜１６１をカバーする。選択リスト処理に必要な最初のバイトがバイト１６１であるため、展開処理は、１０番目のトークンから開始する。そして、展開処理は、行のバイト１７０が展開されるまで、すなわち、後続のトークンであるトークン「５」が見つかるまで続く。したがって、トークン８および５のみ（または、代替的にこれらのトークンの必要な部分のみ）を展開することにより、行のＣ１７にアクセスするための全てのデータが利用可能になる。一般的に、適切なオフセットを「カウント」するコストは、実際にバイトを展開するよりも非常に小さい。したがって、必要とされる行の部分のみを展開する方が非常に速い。

上述したプロセス（１００）は一例に過ぎず、当業者にとって明らかな多くのバリエーションがあることに留意すべきである。

例えば、上述したコストモデル方法を使用することにより、いずれの展開ストラテジーを最適に使用する判断が可能になる。例えば、クエリーのために列Ｃ１およびＣ３のみを展開する必要がある場合、列Ｃ１およびＣ３のみを展開するコストと、列Ｃ１、Ｃ２およびＣ３を展開するコストとを比較するコスト見積もりを行うことができる。列Ｃ２が必要でない場合でも、連続する範囲全体を展開する方が、列Ｃ１およびＣ３のみを個別に展開してカウントするよりも速いことがある。同様に、列Ｃ３のみが必要な場合、列Ｃ１は行の先頭であるため、列Ｃ１〜Ｃ３を展開する方が、列Ｃ３のみを展開するよりも速いことがある。このように、コストモデルによって様々なサブストリングの展開方法を比較することが可能になり、最もコストの低い案が選択される。

さらに、必要とされる列の一部が可変長である場合や、同じ行内で様々なオフセットを有する列があることに留意すべきである。これらのケースでは、単一のバイトオフセットでは不十分である場合がある。可変長の列の長さは、様々な方法で格納することができる。例えば、ＤＢ２は、可変長のアイテムを格納する２つの異なる方法を使用する。一方の方法では、可変長の列が、その長さに応じて整列される。他方の方法では、マップが行と共に格納され、可変長の各列の先頭にオフセットを提供する。しかしながら、これらは単なる例に過ぎない。重要なのは、展開手段に対し、可変長の列のストラクチャーを発見させ、可変長の列が有る場合に、必要とされる一連のバイトを決定させるロジックが存在することである。オフセットが行の中間に格納されるか否か、オフセットが先頭に存在するか否か、またはＶＡＲＣＨＡＲに先行する単一の長さが存在するか否かは問題ではない。様々なストラクチャーの展開マップを生成して提供することができ、本質的なポイントは、これらのいずれの方法でも、可変長の列が有る場合に、実際に必要なバイトを決定できることである。

例えば、オフセットを各ＶＡＲＣＨＡＲの最初の部分に格納するデータベースシステムの場合、それはしばしば「再配列行フォーマット（reordered row format）」と呼ばれる。以下に、ＤＢ２データベースシステム内の行のストラクチャー等の例示的な行のストラクチャーを示す。この場合、可変長の各列は、行内の固定位置に開始オフセットを有する。列Ｃ１、ＶＣ２、ＶＣ３を有するテーブルの場合、Ｃ１は、長さが１０の固定長の文字列であり、ＶＣ２およびＶＣ３は、最大長が１００バイトの可変長の文字フィールドである。この場合、行は以下のようになる。

クエリーが列ＶＣ３のみへのアクセスを要求する場合、サブストリングの展開を利用して、（Ｏｆｓ（ＶＣ３）として圧縮データに格納されている）ＶＣ３の開始オフセットのみを得ることができる。そして、展開処理は、ＶＣ３の先頭が検出されるまで「カウント」を続行し、列の最後が検出されるまで展開を続行する（この場合、最後の列については、圧縮データの最後まで展開処理が実行される）。サブストリングの展開では、カウント処理と展開処理を素早く切り替えることができるため、行内の所望のオフセットを素早く展開することができ、これらのオフセットを用いて、後続の展開のバイト範囲を指定する。例えば、ＤＢ２データシステムの現在の実装では、展開に必要なバイトの位置が、０で終わるアドレスの配列と共に与えられる。例えば、或る行がアドレスＷＡＰｔｒのワークエリアに展開され、当該行の１６１から１７０のバイトを展開することが要求される場合、以下のような配列を生成することができる。

このような配列は、展開マップと呼ばれ、展開する必要のある行の部分を示す。アドレスの代わりにオフセットを展開マップに格納する実施形態も可能であるが、上述したアドレスをバッファに入れる方法は、特定のデータベースシステムの実装に効果的であろう。代替的に、（Ｏｆｓ（ＶＣ３）と同様に）エントリの開始位置がオフセット１４の圧縮データ内に格納される可変長のエントリに対するアクセスが要求される場合は、以下のような展開マップを生成することができる。

この場合、最初のオフセットは、このオフセットの２バイトのフィールドをＷＡＰｔｒに追加すべき旨を示すフィールドによって印付けられ、展開マップの次のエントリに格納される。したがって、展開マップの次のエントリは、展開処理を開始すべき位置を示すオフセットで満たされる。ＶＣ３は行の最後の列であるため、「最後」の展開処理のオフセットが、行の最大長を示すｍａｘＲｏｗＬｅｎに設定され、全ての圧縮データが処理されたときに、展開処理が終了する。ＶＣ３に後続する他の可変長の列が存在する場合、これらの可変長の列のオフセットは、圧縮された行の終了位置を示す同様の間接演算子と共に使用してもよい。いくつかの代替例では、行の可変長部分全体を展開する方が早い場合があり、この代替例のコスト見積もりも算出されることに留意すべきである。例えば、行の終端部の全ての可変長の列を常に格納する実施形態では、展開マップを「間接参照（indirection）」することなく、行の最後尾のみが展開される。

可変長の列が長さに応じて整列されるイベントでは、可変長の列の長さを使用する間接参照による方法によって後続の展開処理の位置を調整することができる。例えば、第３の可変長の列が要求される場合、特定のオフセットの値を展開マップの後続のエントリに追加する間接参照による方法を利用することにより、先行する可変長のエントリの長さを考慮することができる。当業者であれば理解できるように、このような間接参照による方法は、可変長の列の様々なフォーマットに好適である。

さらに、いくつかの実施形態では、展開マップが多数のバイト範囲を格納できることに留意すべきである。例えば、述語を使用せずに、上記例から列Ｃ１およびＣ１７を常に検索するクエリーの場合、以下のような展開マップを構築することができる。

この方法では、行全体を展開することなく、行の連続していない複数の部分を展開することができる。

上述した説明では、ＤＢ２データベースシステムを例として用いたが、上述した技術は、もちろん他の多くの例に適用可能であることに留意すべきである。例えば、圧縮されたネットワークストリームは、予測可能なオフセットが示すデータストリームの一部（すなわち、ヘッダまたはトレーラ）にのみアクセスすればよい。この場合、調べる必要のあるストリーム部分のみをカウントして展開することができる。このように、上述した汎用性のある技術を様々な分野に応用することができる。

さらに、上述した例では、行の先頭から行の最後までトークンやユニットをカウントして展開するのに適切なバイトを特定するデータ展開に着目しているが、これを逆にした同様の技術を利用できることに留意すべきである。すなわち、行の先頭から展開するのではなく、行の最後から展開することができる。これは特に、例えば、行の長さが２００バイトであり、最後の２０バイトのみが必要であることが分っている場合に有用である。このような場合、行の最後から展開することにより、トークンやユニットをカウントして展開すべきバイトを特定する必要がなくなり、展開処理をさらに効率的にすることができる。当業者であれば、これらの技術の様々なバリエーションおよび／または組み合わせを想到することができるであろう。

図２は、特定の実施形態で使用されるコンピュータアーキテクチャ（２００）を示す。本実施形態では、コンピュータデバイスが、コンピュータアーキテクチャ（２００）を有する。コンピュータアーキテクチャ（２００）は、プログラムコードの格納および／または実行に適しており、システムバス（２２０）を介して直接的または間接的に記憶素子（２０４）に接続される少なくとも１のプロセッサ（２０２）を備える。記憶素子（２０４）には、実際にプログラムコードを実行する際に使用されるローカルメモリとして、大容量記憶装置と、実行時に大容量記憶装置からコードを読み出す回数を低減するために少なくともプログラムコードの一部を一時的に格納するキャッシュメモリとを含むことができる。記憶素子（２０４）は、オペレーティングシステム（２０５）と、１以上のコンピュータプログラム（２０６）とを有する。

（これらに限らないが、キーボードやディスプレイ、ポインティングデバイス等を含む）入力装置／出力装置（２１２，２１４）を、システムに直接接続し、または入出力（Ｉ／Ｏ）コントローラ（２１０）を介して接続することができる。

プライベートネットワークまたはパブリックネットワークを介して、データ処理システムを他のデータ処理システム、リモートプリンタまたは記憶装置に接続可能なネットワークアダプタ（２０８）をシステムに組み込むこともできる。モデム、ケーブルモデムおよびイーサネットカードは、現在利用可能なネットワークアダプタ（２０８）の種類の一部である。

コンピュータアーキテクチャ（２００）は、記憶装置（２１６）（例えば、磁気ディスクドライブや光ディスクドライブ、テープドライブ等の不揮発記憶装置などの任意の種類の記憶装置）を接続することができる。記憶装置（２１６）には、内部の記憶装置、接続された記憶装置、またはネットワークを介してアクセス可能な記憶装置を含むことができる。記憶装置（２１６）内のコンピュータプログラム（２０６）は、本技術分野で知られている方法により、記憶素子（２０４）にロードして、プロセッサ（２０２）が実行することができる。

コンピュータアーキテクチャ（２００）は、構成要素を図２に示すよりも少なくすることができ、また、図示していない構成要素を追加することができ、さらに、図２に示す構成要素および追加の構成要素を組み合わせることができる。コンピュータアーキテクチャ（２００）は、メインフレーム、サーバ、パーソナルコンピュータ、ワークステーション、ラップトップコンピュータ、可搬型のコンピュータ、テレフォニーデバイス、ネットワークアプライアンス、仮想化デバイス、ストレージコントローラ等の本技術分野で知られている様々なコンピュータデバイスを含み得る。

上述した本発明の実施形態の説明は、図示および説明を目的としており、本発明の全ての実施形態を網羅するものではなく、また、本発明の実施形態を本明細書に開示されている態様に限定するものではない。上記の教示を考慮することにより、多くの変更例およびバリエーションが可能である。本発明の実施形態の範囲は、この詳細な説明に限定されるものではなく、本明細書に付加されている請求項によって規定されるものである。上述した仕様、例およびデータは、本発明の実施形態の構成の製造および使用を完全に説明する。本発明の主旨や意図から外れることなく、多くの実施形態を構成することが可能であるため、本発明の実施形態は、下記請求項または従属項、これらに均等な範囲に属する。

図に示すフローチャートおよびブロック図は、本発明の様々な実施形態に係るシステム、方法およびコンピュータプログラム製品の実施形態のアーキテクチャ、機能および処理を示す。この点において、フローチャートまたはブロック図の各ブロックは、特定の論理機能を実現する１以上の実行可能な命令を有するモジュール、セグメント、またはコードの一部を表す。また、代替的な実施形態では、ブロック内に記載されている機能は、図に示す順序と異なる順序で実行できることに留意すべきである。例えば、図１に示す連続する２つのブロックは、実際には、ほぼ同時に実行する場合があり、また、関連する機能に応じて、これらのブロックを逆の順序で実行する場合もある。また、ブロック図および／またはフローチャート図の各ブロック、およびブロック図および／またはフローチャート図のブロックの組み合わせは、特定の機能や動作を実行する専用のハードウェアに基づくシステムや専用のハードウェアおよびコンピュータ命令の組み合わせによって実行することができる。

本明細書で使用される用語は、特定の実施形態のみを説明する目的であり、本発明を限定することを意図するものではない。本明細書で使用するように、単数表現「１（ａ）」、「１（ａｎ）」および「その（ｔｈｅ）」は、文脈で明示的に除外しない限り、複数表現とすることもできる。さらに、「備える」および／または「備えている」の語は、本明細書で使用する場合、前述した機能、整数、ステップ、動作、要素および／または構成要素の存在を意味するが、１以上の他の機能、整数、ステップ、動作、要素、構成要素および／またはこれらの組み合わせの存在や追加を排除するものではないことが理解されるであろう。

下記請求項に記載されている全ての手段、または機能要素を伴うステップに対応するストラクチャーや材料、動作、または同等の手段やステップは、他の請求項で明確に要求されている要素と組み合わせて機能を実行する如何なるストラクチャー、材料または動作を含む。本発明の説明は、図示および説明を目的とするものであり、本発明を網羅するものではなく、本明細書で開示されている態様に本発明を限定するものでもない。本発明の意図および主旨から逸脱しない多くの変更例やバリエーションは、当業者に明らかであろう。本発明の実施形態は、本発明の原理および実用的な応用を最もよく説明すべく、また、検討される特定の使用に適した種々の修正を伴う様々な実施形態のために、当業者が本発明を理解できるようにすべく、選択および説明された。

２００：コンピュータアーキテクチャ
２０２：プロセッサ
２０４：記憶素子
２０５：オペレーティングシステム
２０６：コンピュータプログラム
２０８：ネットワークアダプタ
２１０：Ｉ／Ｏコントローラ
２１２：入力装置
２１４：出力装置
２１６：記憶装置
２２０：システムバス

Claims (20)

1. データベースシステム内のデータを展開するためにコンピュータが実行する方法であって、
   圧縮されているデータセット内のデータサブセットに関連するクエリーを受信するステップと、
   見積もられたフィルターファクタを有するコストモデルを使用して、１以上の展開ストラテジーを評価するステップと、
   １以上の展開ストラテジーの評価結果に基づいて、コストの低い展開ストラテジーを選択するステップと、
   圧縮されているデータセット内の要求されているデータサブセットを表す１以上のバイトの位置を特定するステップと、
   選択された展開ストラテジーを用いて、データサブセットに対応する圧縮されているデータの一部のみを展開し、残りのデータセットを圧縮された状態のままにするステップと
   を含む、方法。
2. 前記データサブセットは、
   １のデータベーステーブルの１の行に含まれる複数列のサブセット、
   前記データベーステーブル内の複数列または複数バイトのサブセット、
   前記データベーステーブルの１のページ内の複数列のサブセット
   のうちの１つを含む、請求項１に記載の方法。
3. 前記展開ストラテジーは、２以上の展開段階を含む、請求項１または２に記載の方法。
4. １以上の展開ストラテジーを評価するステップは、
   １の行内の列のサブセットのみを展開するためのコストを算出するステップと、
   算出したコストと前記行内の全ての列を展開するコストとを比較するステップと
   を含む、請求項１〜３のいずれか１項に記載の方法。
5. 前記圧縮されているデータセット内の要求されているデータサブセットを示す１以上のバイトの位置を特定するステップは、
   圧縮されているデータの特定の数のバイトを示すユニットを決定するステップと、
   前記圧縮されているデータセット内の要求されているデータサブセットを示す１以上のバイトを取得するために、いずれのユニットを展開する必要があるか決定するステップと
   を含む、請求項１〜４のいずれか１項に記載の方法。
6. 前記方法は、
   各ユニットの開始位置に対するオフセットを表す各行のマップを格納するステップをさらに含む、請求項５に記載の方法。
7. 前記マップは、前記データベースシステムのバッファメモリに配列として格納されることを特徴とする、請求項６に記載の方法。
8. 各可変長の列が、可変長の列の長さを示す数に応じて整列されることを特徴とする、請求項５〜７のいずれか１項に記載の方法。
9. 前記展開は、行の先頭から開始することを特徴とする、請求項１〜８のいずれか１項に記載の方法。
10. 前記展開は、行の最後から開始することを特徴とする、請求項１〜８のいずれか１項に記載の方法。
11. データベースシステム内のデータを展開するコンピュータプログラムであって、前記コンピュータプログラムは、プログラムコードを有するコンピュータ読取可能な記憶媒体を備え、前記プログラムコードが、プロセッサによって実行されることにより、前記プロセッサが、
    圧縮されているデータセット内のデータサブセットに関連するクエリーを受信するステップと、
    見積もられたフィルターファクタを有するコストモデルを使用して、１以上の展開ストラテジーを評価するステップと、
    １以上の展開ストラテジーの評価結果に基づいて、コストの低い展開ストラテジーを選択するステップと、
    圧縮されているデータセット内の要求されているデータサブセットを表す１以上のバイトの位置を特定するステップと、
    選択された展開ストラテジーを用いて、データサブセットに対応する圧縮されているデータの一部のみを展開し、残りのデータセットを圧縮された状態のままにするステップと
    を実行する、コンピュータプログラム。
12. 前記データサブセットは、
    １のデータベーステーブルの１の行に含まれる複数列のサブセット、
    前記データベーステーブル内の複数列または複数バイトのサブセット、
    前記データベーステーブルの１のページ内の複数列のサブセット
    のうちの１つを含む、請求項１１に記載のコンピュータプログラム。
13. 前記展開ストラテジーは、２以上の展開段階を含む、請求項１１または１２に記載のコンピュータプログラム。
14. １以上の展開ストラテジーを評価するステップは、
    １の行内の列のサブセットのみを展開するためのコストを算出するステップと、
    算出したコストと前記行内の全ての列を展開するコストとを比較するステップと
    を含む、請求項１１〜１３のいずれか１項に記載のコンピュータプログラム。
15. 前記圧縮されているデータセット内の要求されているデータサブセットを示す１以上のバイトの位置を特定するステップは、前記プロセッサが、
    圧縮されているデータの特定の数のバイトを示すユニットを決定するステップと、
    前記圧縮されているデータセット内の要求されているデータサブセットを示す１以上のバイトを取得するために、いずれのユニットを展開する必要があるか決定するステップと
    を含む、請求項１１〜１４のいずれか１項に記載のコンピュータプログラム。
16. 前記プロセッサに対し、各ユニットの開始位置に対するオフセットを表す各行のマップを格納するステップを実行させるプログラムコードをさらに備える、請求項１５に記載のコンピュータプログラム。
17. 前記マップは、前記データベースシステムのバッファメモリに配列として格納されることを特徴とする、請求項１６に記載のコンピュータプログラム。
18. 各可変長の列が、可変長の列の長さを示す数に応じて整列されることを特徴とする、請求項１５〜１７のいずれか１項に記載のコンピュータプログラム。
19. 前記展開は、行の先頭から開始することを特徴とする、請求項１１〜１８のいずれか１項に記載のコンピュータプログラム。
20. 前記展開は、行の最後から開始することを特徴とする、請求項１１〜１８のいずれか１項に記載のコンピュータプログラム。