JP2012504825A - 列ベースデータエンコードされた構造のクエリに対する効率的な大規模フィルタリングおよび／または並べ替え - Google Patents

Abstract

本明細書の開示は、大規模データストレージにまたがる効率的なクエリ処理を可能にする、より具体的には、定義されたウィンドウを覆うデータに関するフィルタ演算および／または並べ替え演算を巻き込む複雑なクエリに関して効率的なクエリ処理を可能にする、列ベースデータエンコードされた構造の問合せ（ｑｕｅｒｙｉｎｇ）に関する。この点に関して、さまざまな実施形態では、行を全く並べ替えないことによって、あるいはデータに関して要求されたデータウィンドウのサイズに関連した行数に一致するか、またはそれよりも少ない非常に小数の行だけを並べ替えることによって、高い割合の行または全ての行のコストのかかる並べ替えを含むシナリオを回避する方法が提供される。一実施形態では、これが、外部クエリ要求を、２つの異なる内部副要求、すなわち指定されたＷＨＥＲＥ節およびＯＲＤＥＲ ＢＹ列に対する行の分布についての統計量を計算する第１の内部副要求と、この統計量に基づいて、ウィンドウにマッチする行だけを選択する第２の内部副要求とに分割することによって達成される。

Description

本開示は一般に、大量のデータに関するクエリ（ｑｕｅｒｙ）に関する効率的な列ベースの（以下、列ベース）フィルタリング（ｆｉｌｔｅｒｉｎｇ）および／または並べ替え（ｓｏｒｔｉｎｇ）演算に関する。

従来のデータクエリシステムに関する背景として、サーバコンピュータが、データの多数のレコードまたはトランザクションを長期間にわたって集めているときなど、大量のデータがデータベースに保存されているときに、他のコンピュータが時に、そのデータまたはターゲットとするそのデータのサブセットへのアクセスを希望することがある。このような場合、これらの他のコンピュータは、１つまたは複数のクエリ演算子（ｑｕｅｒｙ ｏｐｅｒａｔｏｒ）を介して、所望のデータに関して問い合わせることができる。この点に関して言えば、歴史的に、リレーショナルデータベースがこの目的のために発展し、このような大規模データ収集のために使用されており、問い合わせているクライアントに代わって、リレーショナルデータベースまたは一組の分散データベースからデータを取り出すようにデータベース管理ソフトウェアに命令するさまざまなクエリ言語が開発されている。

伝統的に、リレーショナルデータベースは、レコードに対応し、フィールドを有する行に基づいて編成されている。例えば、第１の行は、第１の行のレコードを定義する、列に対応するそのフィールド（名前１、年齢１、住所１、性別１など）に対するさまざまな情報を含み、第２の行は、第２の行のフィールド（名前２、年齢２、住所２、性別２など）に対するさまざまな異なる情報を含む。しかしながら、クライアントによるローカルクエリまたはローカルビジネスインテリジェンスに対する従来の莫大な量のデータに関する問合せ、または莫大な量のデータの取出しは、それらが、リアルタイム要件またはリアルタイム要件に近い要件を満たすことができないために、制限されている。特に、クライアントが、最新のデータのローカルコピーをサーバから得たい場合、限られたネットワーク帯域幅および限られたクライアントキャッシュストレージ（ｃｌｉｅｎｔ ｃａｃｈｅ ｓｔｏｒａｇｅ）を考えると、このような大規模な量のデータをサーバから転送することは、現在までのところ、多くの用途に対して非実用的である。

追加の背景として、リレーショナルデータベースをアーキテクチャの一部として用いて、異なる行を異なるレコードとして概念化することが便利であるため、リレーショナルデータベースが編成される方法の性質から、データセットサイズを低減させる技法はこれまで、行に焦点を合わせてきた。言い換えると、行情報は、レコードのフィールドの全てを１つの行上に一緒に保持することによってそれぞれのレコードを保存し、集計データ（ａｇｇｒｅｇａｔｅ ｄａｔａ）のサイズを低減させる伝統的な技法は、それ自体のエンコードの部分として、それらのフィールドを一緒に保持してきた。

したがって、データサイズ低減とクエリ処理速度を同時に達成する解決策を提供することが望ましいであろう。特に、クライアントアプリケーションまたはユーザが、データの小さなウィンドウを見たいだけ、または（例えば実際のディスプレイリアルエステート（ｄｉｓｐｌａｙ ｒｅａｌ ｅｓｔａｔｅ）による制限のため）一度にデータの小さなウィンドウしか見ることができない場合には、大量のデータに関する非常に効率的なクエリを生成する方法に圧縮を適用することに加えて、大量のデータに関するフィルタ演算、並べ替え演算などの複雑な演算に対する追加の洞察（ｉｎｓｉｇｈｔ）を得ることも望ましいであろう。このような状況では、ユーザまたはクライアントアプリケーションに送る前に、バックエンド（ｂａｃｋ ｅｎｄ）でデータセット全体に対するフィルタ演算および並べ替え演算を実行すると、時間がかかることがあり、したがって、リアルタイム用途の場合には非効率であり、または不適当であることがある。

例えば、クライアントアプリケーションが、ストレージ内に保持された大量のデータに関するウィンドウを表示するように要求するときには、現在、論理レベルにおいて、クライアントアプリケーションは、以下の擬似ＳＱＬクエリなどのクエリによって、このことを要求することができる。

従来の方法によれば、この要求を解決するためには、最初に、ストレージ層が、そのデータを並べ替え、フィルタリングし、最後に、この順序付けされ（ｏｒｄｅｒｅｄ）、フィルタリングされた結果を使用して、指定されたウィンドウに行だけを返す。しかしながら、この順序付けされ、フィルタリングされた結果の中のデータの量が、ウィンドウサイズを大幅に上回る場合には、所与のウィンドウだけをできるだけ速く見たいユーザから見て、この方法が非効率である理由が分かる。

この点に関して言えば、１つの問題は、大量のデータを並べ替える演算が、データのウィンドウを要求したコンポーネントの性能に影響を及ぼす非常にコストのかかる演算であることである。

この問題を解決する従来の１つの方法は、最初にフィルタを適用し、次いでフィルタを通過した結果だけを順序付けることを、ストレージコンポーネントに保証させることである。このことは、より少ないデータを並べ替えるだけですむことを保証し、このことはまた、フィルタがどれくらい選択的であるのか、すなわち、そのフィルタが、並べ替えるターゲットデータセットの範囲をどれくらい狭めるのかに概ね比例して役立つ。しかしながら、多くの行がフィルタ述語（ｆｉｌｔｅｒ ｐｒｅｄｉｃａｔｅ）にマッチする場合には、多数の行を依然として並べ替える必要があるため、この計画も役立たないことが分かり、最初の問題へ立ち返ることになる。

別の従来の解決策は、キャッシング（ｃａｃｈｉｎｇ）機構を使用して、ユーザがデータの最初のウィンドウを要求したときにだけ、全ての行を並べ替えするコストを支払うようにする方策である。フィルタ条件および順序付け条件が不変のとき、クエリプロセッサ／ハンドラ（ｈａｎｄｌｅｒ）は、キャッシュに入れられた結果を使用して、データ関する異なるウィンドウを返すことができるため、最初のウィンドウの後の後続のクエリは、償還済みのコスト（ａｍｏｒｔｉｚｅｄ ｃｏｓｔ）を有する。しかしながら、この方法は、キャッシュ結果を保存しなければならないため、メモリに関して比較的に高いコストを有する。キャッシュは、メモリ圧力（ｍｅｍｏｒｙ ｐｒｅｓｓｕｒｅ）、使用パターンなどを含むさまざまな理由に基づいて、空にし、または無効にすることができるが、少なくとも、フィルタを通過した全ての行を並べ替える初期コストは支払われなければならないという問題は残る。時間が重要なクエリに関しては、このことが容認できないことがある。

したがって、データ集約的なアプリケーション環境における大量のデータに関するクエリ、特に、大規模なデータ、例えばターゲットストア（ｔａｒｇｅｔ ｓｔｏｒｅ）内の１０億行以上の行に関するコストのかかるフィルタ演算および／または並べ替え演算を巻き込むクエリに対する、高速でスケーリング可能なアルゴリズムが求められている。

今日のリレーショナルデータベースおよび対応するクエリ技法の前述の欠陥は、単に、従来のシステムの諸問題の一部を概観することを意図したものであり、全ての欠陥を挙げることは意図されていない。従来のシステムのその他の問題、および本明細書に記載する非限定的なさまざまな実施形態の対応する利点は、以下の説明を精査すると、よりいっそう明白になるだろう。

本発明は、上述したような課題に鑑みてなされたものであり、その目的とするところは、大量のデータに関するクエリに関する効率的な列ベースのフィルタリングおよび／または並べ替えを提供することにある。

ここでは、以下のより詳細な説明および添付図面で説明する例示的で非限定的な実施形態のさまざまな態様の基本的なまたは一般的な理解を可能にするのに役立つ単純化された概要を提供する。しかしながら、この概要は、広範囲にわたるまたは網羅的な概要としては意図されていない。この概要の唯一の目的は、後に続くさまざまな実施形態のより詳細な説明に対する序文として、ある例示的な非限定的な実施形態に関係したいくつか概念を、単純化された形で提示することである。

大規模データストレージにまたがる効率的なクエリ処理を可能にする、より具体的には、定義されたウィンドウを覆うデータに関するフィルタ演算および／または並べ替え演算を巻き込む複雑なクエリに関して効率的なクエリ処理を可能にする、列ベースデータエンコードされた構造を問い合わせる実施形態を説明する。さまざまな実施形態では、行を全く並べ替えないことによって、あるいはデータに関して要求されたデータウィンドウのサイズに関連した行数に一致するか、またはそれよりも少ない非常に小数の行だけを並べ替えることによって、高い割合の行または全ての行のコストのかかる並べ替えを含むシナリオを回避する方法が提供される。一実施形態では、これが、外部クエリ要求を、２つの異なる内部副要求（ｓｕｂ−ｒｅｑｕｅｓｔ）、すなわち指定されたＷＨＥＲＥ節およびＯＲＤＥＲ ＢＹ列に対する行の分布についての統計量（ｓｔａｔｉｓｔｉｃｓ）を計算する第１の内部副要求と、この統計量に基づいて、ウィンドウにマッチする行だけを選択する第２の内部副要求とに分割することによって達成される。

以下では、これらの実施形態および任意選択の特徴ならびにその他の実施形態および任意選択の特徴をより詳細に説明する。

非限定的なさまざまな実施形態を、以下の添付図面を参照してさらに説明する。

クエリを処理する一実施形態に基づく一般的なプロセスを示す流れ図である。 本明細書の１つまたは複数の実施形態と整合したクエリ処理環境の一般化されたブロック図である。 本明細書の１つまたは複数の実施形態に基づくクエリを処理する一般化された方法を示す流れ図である。 本明細書の１つまたは複数の実施形態と整合した、クエリ要求を満たすエンドツーエンド処理の流れを示す流れ図である。 １つまたは複数の実施形態の技法を適用することができる、実世界データにおいて一般的に見られるいくつかのサンプルデータ分布を示す図である。 本明細書に記載されたヒストグラムを使用してクエリを処理することを含む代表的な流れ図である。 本明細書の１つまたは複数の実施形態においてヒストグラム計算とともに使用される、テキスト値、フロート値などの実世界データの離散化の一例である。 本明細書に記載された実施形態に基づく予め設定された１つまたは複数のデータ「形状」に基づくヒストグラムの特徴を示す図である。 男性値または女性値を有するフィールドなど、比較的に少数の別個のデータ値を有し、データが１つまたは複数のスパイクで表されるサンプル分布を示す図である。 少数のデータ値スパイクを有するサンプル分布のランレングス原理と整合したフィルタリングを示すブロック図である。 スパイクとして示された単一の卓越値を有し、残りの値は比較的に一様に示されたサンプル分布を示す図である。 卓越する少数のスパイクを有し、残りの値は比較的に一様に示されたサンプルデータ分布に関する、フィルタ演算および／または並べ替え演算を巻き込むクエリの処理を取り扱う代表的方法を示す図である。 本明細書に記載された１つまたは複数の実施形態に基づくライトデータキャッシュの例示的で非限定的な任意選択の実施態様を示す図である。 本明細書に記載された任意選択のデータ処理技法に対するデータセルの概念を示す図である。 ハッシュ追跡データ構造の任意選択の実施態様を示す図である。 ヒストグラムを計算する、本明細書に記載された実施形態に基づく例示的で非限定的なプロセスを示す流れ図である。 統計量を得、それを使用する、本明細書に記載された実施形態に基づく例示的で非限定的なプロセスを示す流れ図である。 所与のウィンドウに関するクエリを処理する際に標準並べ替え技法と列ベース並べ替え技法のどちらの技法を使用するべきかを判定する、本明細書に記載された実施形態に基づく例示的で非限定的なプロセスを示す流れ図である。 所与のウィンドウ内で並べ替えを実行する、本明細書に記載された実施形態に基づく例示的で非限定的なプロセスを示す流れ図である。 ライトデータキャッシュを使用してクエリを処理する、本明細書に記載された実施形態に基づく例示的で非限定的なプロセスを示す流れ図である。 １つまたは複数の実施形態に基づく例示的で非限定的なプロセスを示す流れ図である。 １つまたは複数の実施形態に基づく例示的で非限定的なプロセスを示す他の流れ図である。 列ベースエンコード技法およびエンコードされたデータに関するクエリのインメモリクライアントサイド処理を示す一般的なブロック図である。 列ベースエンコード技法を使用するエンコード装置の例示的で非限定的な実施態様を示すブロック図である。 クエリとともに受け取った列データのインメモリクライアントサイド処理の作業を、複数のコア間で分割して、多数の行を処理する負荷を列編成を横切って分担することができることを示す図である。 列ベースエンコードを大規模データに適用する例示的で非限定的なプロセスを示す流れ図である。 生データの列ベース表現を示す図であり、この表現では、レコードがそのそれぞれのフィールドに分割され、次いで同じタイプのフィールドが直列化されてベクトルを形成する。 レコードデータの列化を例示する非限定的なブロック図である。 辞書エンコードの概念を示す非限定的なブロック図である。 値エンコードの概念を示す非限定的なブロック図である。 ハイブリッド圧縮技法の一態様に適用されたビットパッキングの概念を示す非限定的なブロック図である。 ハイブリッド圧縮技法の他の態様に適用されたランレングスエンコードの概念を示す非限定的なブロック図である。 列ベースエンコード技法を使用するエンコード装置の例示的で非限定的な実施態様を示すブロック図である。 列ベースエンコードを大規模データに適用する、一実施態様に基づく例示的で非限定的なプロセスを示す流れ図である。 代替圧縮技法を適用するしきい値節約アルゴリズムの任意選択の適用を含む、貪欲なランレングスエンコード圧縮アルゴリズムを実行する方法を例示的に示す図である。 代替圧縮技法を適用するしきい値節約アルゴリズムの任意選択の適用を含む、貪欲なランレングスエンコード圧縮アルゴリズムを実行する方法を例示的に示す図である。 貪欲なランレングスエンコード圧縮アルゴリズムをさらに示すブロック図である。 ハイブリッドランレングスエンコード／ビットパッキング圧縮アルゴリズムを示すブロック図である。 全体ビット節約分析に基づいて異なるタイプの圧縮を適応的に提供するハイブリッド圧縮技法の適用を示す流れ図である。 本開示のさまざまな実施形態に従ってデータの全体サイズを低減させる列ベースエンコードのサンプル性能を示すブロック図である。 純粋なエリアと不純なエリアの間および不純なエリアと純粋なエリアの間の遷移に関する、列ベースエンコードされたデータに適用することができるバケット化プロセスを示す図である。 一実施形態に基づく列のバケット化に関する不純レベルを示す図である。 現在のクエリ／スキャンに関連した列に存在する異なるタイプのバケットに対応する副演算子へのクエリ／スキャン演算子の効率的な分割を示す図である。 結果として生じる純粋バケットがデータの行の５０％超を占める列ベースエンコードの能力を示す図である。 データに関するクエリを標準化された方法で指定するクエリ言語の例示的で非限定的なクエリビルディングブロックを示す図である。 消費クライアント装置によって要求された、ネットワークを経由して入手可能な大規模データに関するサンプルクエリの代表的な処理を示す図である。 列に基づいてデータをエンコードする、さまざまな実施形態に基づくプロセスを示す流れ図である。 整数シーケンスをビットパッキングする、１つまたは複数の実施形態に基づくプロセスを示す流れ図である。 データの列ベース表現に関して問い合わせるプロセスを示す流れ図である。 本明細書に記載されたさまざまな実施形態を実施することができる例示的で非限定的なネットワーク環境を示すブロック図である。 本明細書に記載されたさまざまな実施形態の１つまたは複数の態様を実施することができる例示的で非限定的なコンピューティングシステムまたはオペレーティング環境を示すブロック図である。

（概要）
これから説明する内容のロードマップとして、最初に、さまざまな実施形態の概要を説明し、次いで、補足的コンテキスト（ｓｕｐｐｌｅｍｅｎｔａｌ ｃｏｎｔｅｘｔ）および理解のために、例示的で非限定的な任意選択の実施態様についてより詳細に論じる。次いで、ランレングスエンコード（ｒｕｎ ｌｅｎｇｔｈ ｅｎｃｏｄｉｎｇ）とビットパッキングの性能上の利益を、ハイブリッド圧縮技法によって適応的にトレードオフする実施形態を含む、大量のデータをパックする列ベースエンコード技法に関するある補足的コンテキストを説明する。最後に、さまざまな実施形態を実現し、または展開することができるある代表的なコンピューティング環境および装置を記載する。

背景の項で論じたとおり、とりわけ、従来のシステムは、現在の圧縮技法の限界、ネットワークを横切る伝送帯域幅の限界およびローカルキャッシュメモリの限界のため、サーバまたは「クラウド（ｃｌｏｕｄ）」内のデータストアからの莫大な量のデータを、非常に高速にメモリに読み込む問題を適切に処理しない。リアルタイム要件を有するさまざまな異なるデータ集約的なアプリケーションによって多数のクエリが実行されると、この問題は複合化し、大量のデータに関するフィルタリングおよび／または並べ替えを巻き込むクエリは、このような演算のコストのため、固有の難問を提示する。

この点に関して言えば、本明細書のさまざまな実施形態に関連して説明したとおり、行を全く並べ替えないことによって、あるいはデータウィンドウのサイズに関連した行数に一致するか、またはそれよりも少ない非常に小数の行だけを並べ替えることによって、高い割合の行または全ての行のコストのかかる並べ替えを含むシナリオが回避される。外部クエリ要求を、２つの異なる内部副要求、すなわち指定されたＷＨＥＲＥ節およびＯＲＤＥＲ ＢＹ列に対する行の分布についての統計量を計算する第１の内部副要求と、この統計量に基づいて、ウィンドウにマッチする行だけを選択する第２の内部副要求とに分割することができる。

この点に関しては、後にデータをウィンドウイング（ｗｉｎｄｏｗｉｎｇ）するため、ＷＨＥＲＥおよびＯＲＤＥＲ ＢＹに依存する動的に得られた統計量をレバレッジ（ｌｅｖｅｒａｇｅ）する。ある実施形態では、統計量の構築時間を最小化するため、実データ値、またはヒストグラム構築を容易にするために離散化した（ｄｉｓｃｒｅｔｉｚｅｄ）後の合成データ値に対して統計量を構築する。この点に関して言えば、合成（「離散化された」）データは、結合された列の形態として処理されて、ＯＲＤＥＲ ＢＹ演算に加わる。

さらに、後により詳細に説明する実施形態と一致して、ＯＲＤＥＲ ＢＹ演算によって巻き込まれる列の内容が分析された後のＯ（ｎ）内の２次スキャンまで、最終ウィンドウが生成されない。さらに、あるケースでは、この方法が、予め計算された階層データを使用して、あるタイプの合成（「離散化された」）列をシミュレートする。一実施形態では、あるアルゴリズムが、所与のデータに対する適当な離散化方法、ならびにクエリ定義、統計量から決定される最終ウィンドウの内容および並列化（ｐａｒａｌｌｅｌｉｚａｔｉｏｎ）の程度に基づくバッファリング戦略を選択する。

さらに、本明細書では、ＷＨＥＲＥバケット（ｂｕｃｋｅｔ）およびＯＲＤＥＲ ＢＹバケットの内容ならびに統計量から決定される最終ウィンドウの内容に基づいて射影（ｐｒｏｊｅｃｔｉｏｎ）法を選択するあるアルゴリズムを提示する。さらに、ある方法は、最大Ｎ個、例えば３つの予め構成されたバッファのうちの１つのバッファへの挿入だけを使用して最終ウィンドウを並列に構築することを備える。他の実施形態では、クエリ仕様（ｑｕｅｒｙ ｓｐｅｃｉｆｉｃａｔｉｏｎ）、選択された離散化法、ヒストグラムによって決定される最終ウィンドウ内のデータの分布、およびデータ処理に適用される並列化の程度に従って、射影中に使用する内部バッファ、例えばバッファサイズおよびそれらのポリシーを構成するプロセスを説明する。

並列処理に関して、セグメント離散化は、ＯＲＤＥＲ ＢＹのない（ＷＨＥＲＥフィルタだけを有する）クエリに対して、またはスパイク（ｓｐｉｋｅ）とマッチするウィンドウに対して、Ｏ（１）時間内の最終ウィンドウを並列に埋めることを可能にする。さらに、さまざまな実施形態では、最終ウィンドウに現れないＯ（１）内の行を破棄するスマートなバッファリング法を適用する。さらに、さまざまな実施形態が、任意選択で、射影された全ての列を流す（ｓｔｒｅａｍ）するため、ウィンドウイングされたライン（ｗｉｎｄｏｗｅｄ ｌｉｎｅ）の上に繰返し子（ｉｔｅｒａｔｏｒ）を生成する。

非限定的なプロセスへの導入として、図１は、一般的なクエリに対する実行フローの概要を示す。クエリ仕様を受け取った後、１００で、システムがそのクエリ仕様を分析する。これは、１１０で、この分析によって選択された方法に従ってデータを離散化することを含むことができる。１２０で、データに関するヒストグラムを計算する。１３０で、このヒストグラムを使用して、クエリ仕様によって巻き込まれたデータのウィンドウを分析し、その結果、ウィンドウイングバッファ１５０、１５２、１５４および１５６をスキャンし、埋めることによって、並列処理するためのデータバッファ１４０の準備が整う。１６０で、これらのバッファ結果をマージ（ｍｅｒｇｅ）し、表示するウィンドウに対してトリミング（ｔｒｉｍ）し、ある条件が満たされた場合、１７０で、必要な場合にのみ、最終ウィンドウに関するローカル並べ替えを実行する。次いでｌｉｎｅ＃繰返し子１８０を出力する。

（フィルタ／結合演算を用いた列ベースクエリ処理）
概要の項で述べたとおり、列指向（ｃｏｌｕｍｎ ｏｒｉｅｎｔｅｄ）エンコードおよび圧縮を大量のデータに適用して、データをコンパクト化し、同時に、データに関する後のスキャン／検索／クエリ操作を実質的により効率的にするためにデータを編成することができる。これに応じて、さまざまな実施形態では一般に、外部クエリ要求を、２つの異なる内部副要求、すなわち指定されたＷＨＥＲＥ節およびＯＲＤＥＲ ＢＹ列に対する行の分布についての統計量を計算する第１の内部副要求と、この統計量に基づいて、ウィンドウにマッチする行だけを選択する第２の内部副要求とに分割することによって、これを達成する。この点に関して言えば、本明細書に記載した技法を任意のクエリ用途に対して使用して、エンドアプリケーションまたはエンドユーザへのクエリ結果の送達速度を向上させることができる。すなわち、並べ替えられ、フィルタリングされた行をウィンドウイングする任意の用途が利益を得ることができる。

より詳細には、クエリ要求がストレージ層に到来した後、そのクエリ要求を分析し、そのクエリがＯＲＤＥＲ ＢＹ節またはＷＨＥＲＥ節を含まない場合には、ＳＫＩＰおよびＴＯＰによって指定された物理行を返すことによって、このクエリをストレージに対して直接に解決する。これらの行がフィルタリングされ、かつ／または順序付けされる場合、最初のステップは、ウィンドウの内容の性質を識別するのに役立てるため、統計量を構築することができるかどうかを判定するステップである。

この時点で、実データを含む列に関してそれらの統計量を構築することができるかどうか、または合成（「離散化された」）列に関してそれらの統計量を構築する必要があるのかどうかを判定することもできる。この離散化ステップは、例えばそれぞれのスレッドによって最終ウィンドウ内にいくつの行が生成されるのかを識別することを可能にすることによって、またはデータスパイクに関するウィンドウを生成する間のメモリおよび時間のコストを最小化することによって、例えば並べ替えられた列の中の別個の（ｄｉｓｔｉｎｃｔ）ＤａｔａＩＤの数が大きい場合に統計量を構築するコストを最小化すること、またはＯＲＤＥＲ ＢＹが指定されていないときに並列ウィンドウイング中のメモリ割当てのコストを最小化するのに役立つ。この離散化関数は一般に、順序付けされた列と物理セグメントの関数ｆｎ（順序付けされた列，物理セグメント）と見ることができる。

使用することができる離散化のタイプには、同じグループ内の順序付けされた隣接する値をクラスタ化すること、ＯＲＤＥＲ ＢＹが設定されていないときに、フィルタリングされたデータがＷＨＥＲＥ節を通過する場合にセグメントによって離散化すること、およびスパイクを（セグメントごとに）別個のグループに分割することによって離散化するなどが含まれる。離散化関数が存在する場合に、離散化関数が選択されると、次いで、一般に以下のような形態の内部クエリが実行される。

このクエリは、並べ替えられた列上のそれぞれの値の発生数、または、離散化関数がプラグインされている場合には、離散化されたそれぞれの値の発生数を記述する統計量を返す。

それらの結果に対して、例えばｘ軸が、順序付けされたＧｒｏｕｐＩＤを含み、ｙ軸が、以前のグループの発生の累積和（ｒｕｎｎｉｎｇ ｓｕｍ）を含むヒストグラムを構築することができる。本明細書では用語「和」を時にΣと短縮する。

同じＧｒｏｕｐＩＤへの離散化によって複数のＤａｔａＩＤがマッチすることがあるため、ＧｒｏｕｐＩＤを順序付けするのに、存在する全ての行を並べ替える必要があるわけではなく、別個の全てのＤａｔａＩＤを並べ替える必要があるわけではないことに留意されたい。さらに、データを保存するために使用するエンコード法を考慮し、かつ／または予め計算された順序付けされたストア（「階層」）を使用することによって、特定のグループの位置を、それらの値自体を比較することなく決定することができる。

この時点で、最終仮想行セット内のそれぞれのグループの位置を知らせる有用な統計量、例えばヒストグラムデータが取得されたことになる。後に使用するため、任意選択で、この情報をキャッシュに入れることができる。次に、指定されたウィンドウ位置を、ヒストグラム中のデータと比較することができ、並べ替えられた列上のどの値を、目に見えるウィンドウに表示するのかを決定することができる。

これが分かった後、第２の内部クエリを生成する。第２の内部クエリは一般に以下のような形態をとる。

内部的に、複数のスレッド上で並列に実行することができるこのクエリは、最終ウィンドウのトラックを維持するデータキャッシュデータ構造を使用する。このデータキャッシュは、クエリ仕様、渡されたヒストグラム、ウィンドウの位置、使用する離散化のタイプおよび処理に適用する並列性の程度に基づいて、その構成を決定する。したがって、最終ウィンドウを埋める要求は、潜在的に複数のプロセッサ上で並列に実行することができ、この複数のプロセッサはそれぞれ、異なるセグメント（含まれる列の部分）をスキャンし、最終結果セットを部分的に実現する。この点に関して言えば、前述のデータキャッシュ構成に応じたさまざまなバッファタイプを使用することができる。

それらのバッファ内へ挿入はＯ（１）であり、それらのバッファ間で異なるものはそれらのポリシーである。挿入を実行する方法、および特定のバッファを選択するのかまたは別のバッファを選択するのかの判断は、バッファ構成、ならびにスキャンしている現在のバケット内の内容の純粋さ（ｐｕｒｉｔｙ）／不純さ（ｉｍｐｕｒｉｔｙ）についてのメタデータに基づく（バケットは、含まれるＷＨＥＲＥおよびＯＲＤＥＲ ＢＹ列内の現在スキャンされているフラグメント（ｆｒａｇｍｅｎｔ）である）。一例として、ＯＲＤＥＲ ＢＹ列上の純粋さについてのこのメタデータを分析することができ、そのバケットの全長の間、ＯＲＤＥＲ ＢＹ処理されている値が変化しない場合には、そのバケット全体に対して、条件を満たすｌｉｎｅ＃を記録する適正なバッファがどのバッファであるのかを決定することができる。あるいは、バケット全体の長さに対してＷＨＥＲＥ条件が変化しないことをメタデータが示している場合には、バケット内の全てのラインを同じように処理する（バッファに追加する資格を与え、または与えない）ことができる。

あるタイプのバッファは、クライアントが要求したものは何でも挿入する「通常の」バッファの働きをし、他のバッファは、所与のしきい値後に挿入しようとする一切の試みを破棄し、別のバッファは、循環／リングバッファ方式で既存のレコードに上書きする。それらのバッファによって使用されるサイズおよびポリシーは、データキャッシュが構成される間に選択され、全てのプロセッサをレバレッジしている、すなわち並列実行を使用しているＯ（ｎ）スキャン時間の間に、最終ウィンドウを埋めることを可能にする。

このクエリの終わりに、１つまたは複数のデータキャッシュ、２つ以上のセグメントおよび２つ以上のプロセッサが使用可能な場合はより多くのデータキャッシュが存在する可能性があり、それらのデータキャッシュは、最終ウィンドウに表示する全てのｌｉｎｅ＃を含み、これは、正確な数よりもやや多くすることもできる。次いで、トリミングを適用する。すなわち、Ｏ（１）のうちに、ヒストグラムを使用することによって余分なｌｉｎｅ＃を排除する。多くの場合、ｌｉｎｅ＃を保持している残ったレコードは、（セグメントをスキャンする固有の順序のため）自然な順序（ｎａｔｕｒａｌ ｏｒｄｅｒ）にあるか、または結果を外へ流すときにその場でマルチマージ（ｍｕｌｔｉ−ｍｅｒｇｅ）することができるため、追加の並べ替えを必要としない可能性がある。それにもかかわらず、例えばクラスタ化によって離散化するために、トリミングされた結果を並べ替えることが依然として必要となる可能性があるいくつかの場合、または、中間バッファに複数の値が割り当てられているが、並べ替えは、目に見えるウィンドウのサイズに限定され、目に見えるウィンドウのサイズに関係するため、この並べ替えのコストが常に、最もコストがかかる場合でさえも、テーブル全体を並べ替えるコストよりも小さいいくつかの場合がある。一般的なウィンドウイングシナリオに関して、目に見えるウィンドウのサイズは、テーブル中で使用可能な行数よりも何桁も小さい。

生成されたウィンドウイング情報は次いで、条件を満たす行（ｌｉｎｅ＃）を返す列挙子（ｅｎｕｍｅｒａｔｏｒ）を使用する外側の層にさらされる。この列挙子は、最終行セットを生成する際の主要なドライバとして使用される。

このように、さまざまな実施形態では、ユーザインタフェースコンポーネントまたは他のインタフェースによって生成されたクエリを処理して、ある種のデータウィンドウを要求し、それらのウィンドウに関するフィルタを適用し、それらのウィンドウを並べ替えることができる。この点に関して言えば、非限定的な一実施態様では、性能を向上させるため、下記のクエリなどのクエリに応答するために、データと要求しているアプリケーションとの間の層として、ウィンドウイングサポート（ｗｉｎｄｏｗｉｎｇ ｓｕｐｐｏｒｔ）を追加する。

典型的なシナリオでは、データを消費するシステムまたはアプリケーションが、クエリハンドラ／プロセッサとのインタフェースを使用し、このクエリハンドラ／プロセッサは、このデータ消費システムまたはアプリケーションに代わって、クエリを満たすために、データを効率的に探査し、フィルタリングし、並べ替え、データウィンドウを返す。非同期クエリ演算がサポート可能である間、実際のクエリは比較的に高速に完了すると予想される。

例えば、シナリオの一例において、ユーザまたはアプリケーションが１０億行を含むテーブルと対峙し、このテーブルに関する問合せをしたいとする。例えば、ユーザは、フィルタを適用し、さらに１つの列によって並べ替えを実施することができる。後に詳細に説明するさまざまな実施形態では、ユーザは、クエリを満たす適当なテータウィンドウを数秒以内に取り出すことができる。ウィンドウが取り出された後、ユーザは、追加のクエリを巻き込むＵＩコンポーネントを介して、スクロールダウンすることができ、そのときには、わずか０．５秒のうちに１万行の後続のウィンドウが返される。

ある用語（ｎｏｍｅｎｃｌａｔｕｒｅ）に関して、任意選択で、集計（ａｇｇｒｅｇａｔｉｏｎ）結果を保持するように最適化されたデータキャッシュデータ構造を使用することができる。単純化された例として、座標として、一方の側に販売員のＩＤ、もう一方の側に製品のＩＤを有し、それぞれのセル内に集計値（例えばその販売員が製品を販売した販売の和。販売員および製品はそのセルの座標によって識別される）を保持した２次元アレイとして「スクエア（ｓｑｕａｒｅ）」データキャッシュが編成される。この例において、データキャッシュ内の集計された値に関連付けられた固有の順序はない。

本明細書で使用するとき、クエリカーネル（ｑｕｅｒｙ ｋｅｒｎｅｌ）は、集計およびフィルタリングを含み、論理的観点からは、ＳＱＬクエリ：ＳＥＬＥＣＴ＜列＞，＜集計＞ＦＲＯＭ＜テーブル＞ＷＨＥＲＥ＜述語＞ＧＲＯＵＰ ＢＹ＜列＞と等価であるフォーミュラエンジン（ｆｏｒｍｕｌａ ｅｎｇｉｎｅ）要求に応答するように最適化されたコンポーネントを指す。クエリカーネルは、データキャッシュを返すように設計される。これは、データキャッシュが、さまざまなコアシナリオに対して上位層が効率的に動作することができる最適な構造であるためである。

本明細書で使用するとき、行セットは、このクエリ処理コンポーネントとのインタフェースを用いて見ることができる項目（ｉｔｅｍ）を含む一組のデータ、複数の行、複数の列を指す。例えば、行セットは、「販売員」によって並べ替えられた行として表された、「販売員」、「製品」および「請求価格」列を含む、全ての販売のリストを含むことができる。行セットは、サーバによって流されることができ、行セットの行は固有の順序を有する。

クエリスペック（ｑｕｅｒｙ ｓｐｅｃ）データ構造はクエリを記述し、任意選択で、サーバとストレージの間のインタフェースとして使用することができる。テキストフォーマットで構成されてはいないが、クエリスペックデータ構造は、論理的に、サーバがストレージエンジンに送るクエリと等価であるとみなすことができる。

後により詳細に説明するが、ランレングスエンコード（ＲＬＥ）は、シーケンス中で値Ｘが続けてＮ回現れると言うことによってデータを圧縮する手段である。大量のデータに対するエンコード技法についての補足的コンテキストに関する項で後に説明するパッキングアルゴリズムによる処理時に、ＲＬＥ圧縮は有利である。ＲＬＥ圧縮はさらに、データを高速に集計し、高速にフィルタリングするためにクエリカーネルによって実行されるスキャン中にレバレッジされる。これについても、補足的コンテキストの項で後により詳細に説明する。処理中に、列指向ストレージにおいてＲＬＥシーケンスが最大化され、列指向ストレージは、特定の列に同じ値を有する隣接する行のシーケンスを最大にする際に変換される。

限定はされないがＳＱＬクエリなどのクエリがクエリエンジンに渡されると、エンジンは、それらのクエリを解析し、それらのクエリを内部クエリスペックに結合し、そのクエリスペックをクエリハンドラに渡す。クエリハンドラは、並べ替えられ、フィルタリングされたデータの指定されたウィンドウを含む順序付けされた行セットを返す処理を内部的に実行する。

クエリエンジンとクエリハンドラの間の通信のため、標準クライアント−要求インタフェース機構、例えばクエリクライアント要求／応答を使用することができる。渡される要求は、どのデータを返すべきかを記述したクエリスペックを含む。応答は、データキャッシュの代わりに行セットを含む。これは、データキャッシュが固有の順序を有するためである。

図２は、コンポーネントおよび例示的なインタフェースの非限定的な概要ブロック図である。消費側で、インタフェースコンポーネント２００は、クエリ２０２の発行、およびその結果としての行セット（１つまたは複数）２０４の受取りを処理する。中間層のクエリエンジン２１０は、クエリ仕様（スペック）２１２を定義し、クエリハンドラ２２０のクライアント要求ハンドラ２２２に渡すことによって、クエリ２０２を準備することができる。クライアント要求コンポーネントは、クエリスペック２１２が、高速並べ替えなしアクセスアルゴリズム（ｆａｓｔ ｎｏ ｓｏｒｔ ａｃｃｅｓｓ ａｌｇｏｒｉｔｈｍ）２２６にクエリスペック２２４を転送することを巻き込むのか、または、列ベース並べ替えアルゴリズム２４０にクエリスペック２４２を転送することを巻き込むのかを判定する。いずれの場合も、クエリエンジン２１０に行セット２１４が返され、インタフェースコンポーネント２００へ転送される。前述のとおり、列指向ストレージ、統計量および他のコアサービスコンポーネント２３０は、要求されたデータに関するヒストグラムの生成などを処理する。列ベース並べ替え２４０は、クエリスペック２３８に関して列ベーススキャン２３４と協力し、任意選択で、ライトデータキャッシュ（ｌｉｇｈｔ ｄａｔａ ｃａｃｈｅ）２３６を交換に関して使用することができる。他のキャッシュデータ構造２３２を使用して、後に再使用する一時結果を保存することもできる。高速並べ替えなしアクセス２２６が使用される場合には、列挙子２２８が、コアサービスコンポーネント２３０からの結果を知らせる。

このクエリハンドリングコンポーネントの内部では、ＯＲＤＥＲ ＢＹをターゲットとする完全に異なるクエリエンジンを提供することから、既存のクエリカーネルを変更し、クエリカーネルの内部での並べ替えに対する直接サポートを追加すること、またはハイブリッド解決手段までのいくつかのオプションが関係する。

この点に関して言えば、クエリが、クエリスペックの形態でクエリハンドリングコンポーネントに到来すると、クエリが調べられ、実行経路が決定される。並べ替えまたはフィルタリングを巻き込まない単純なクエリに関しては、簡単なＩＳＡＭ型のアクセスをストレージに対して直接に使用することができ、より複雑なクエリに関しては、データ分布に留意し、クエリカーネルまたはバケット指向並べ替えアルゴリズムを使用するより複雑な実行計画が選択されることに留意されたい。

キャッシュを使用して、後にユーザがＵＩコンポーネント内でスクロールする間に再使用することができるコストのかかる中間結果を保存することができる。

１０億行に関する並べ替えられた結果を数秒の時間フレーム内に返す要件を満たすのに、力ずくで全てを並べ替える（ｂｒｕｔｅ−ｆｏｒｃｅ−ｓｏｒｔ−ｅｖｅｒｙｔｈｉｎｇ）単純な方法は、時間とメモリ使用の両面でコストがあまりにかかりすぎる。

ある種の状況下においてある種のモジュールを再使用し、他のモジュールをスキップするモジュール式の方法が、さまざまな実施形態で使用される。どのモジュールを実行するのかを含む全体実行フローの一般的なアルゴリズムの完全で網羅的な概要が利用可能であり、次に、これについてより詳細に論じる。

最初に、含まれるモジュールの高レベル概要を図３に示す。示されているように、最初に、３００で、クエリスペックを分析する。次いで、３１０で、第１のステップとして、ヒストグラムを計算する。このヒストグラムに基づいて、３２０で、そのクエリによって巻き込まれるローカルウィンドウ分布を分析し、標準選択３３０または列ベース並べ替え３４０を選択して、処理を実行する。いずれの場合も、結果は、３５０で、要求を出したアプリケーションに返される。

最初に、さまざまなケース／シナリオを提示する。最初に、最も単純な特定のケースを示し、次第により複雑で汎用的（ｇｅｎｅｒｉｃ）なケースを見ていく。さまざまな実施形態では、統合された汎用的で網羅的なアルゴリズムがモジュール式に提示される。任意選択で、キャッシュを使用して、ある一時結果を、再使用のため保存することができる。

この点に関して言えば、クエリを受け取ると、後に分析するクエリスペックを定義する。クライアント要求がクエリハンドリングコンポーネントに到来したら、このクエリスペックを分析して、並べ替えおよびフィルタリングを一切含まない単純なクエリが含まれるのか、または、そのクエリが、かなりの処理を必要とするクエリであるのかを判定する。

フィルタリングもせず、並べ替えもしないクエリ、例えば索引付き順次アクセス法（ＩＳＡＭ）に関しては、フィルタリングも並べ替えもしない場合、直接ＩＳＡＭ方式型のアクセスを使用することにより、オーバヘッドなしでこの要求を満たすことができる。このことは、（１）含まれる列に関して適正な列挙子を得、（２）正しい位置でＧｏｔｏ（）を実行し（例えばＳＫＩＰを実行し）、（３）そのデータに関する行セットを構築し、例えばＴＯＰ数の行に対してＮｅｘｔ（）を実行し、その値をデコードし、行セットを埋めることを含意する。この点に関して、一実施形態では、ＤａｔａＩＤを変換するためのサーバからクエリハンドラへの往復が不要になるため、ＤａｔａＩＤを含む行を返す代わりに、クエリハンドリングコンポーネントのレベルでデコードを実施する。

フィルタリングはするが、並べ替えはしないクエリに関して、これは、より汎用的な「フィルタリングも並べ替えもするクエリ」の並べ替えのない単純化されたケースであり、実行に関する違いは、専用の並べ替え演算が必要ないことであり、データフィルタリングステップを含むが、並べ替えステップを含まず、フィルタに関するウィンドウを返すこの汎用的なケースを使用することができる。

この点に関して、一実施形態では、クエリカーネル、例えば複数の並列ジョブを処理することができるクエリカーネルを使用して、既存のバケット指向フィルタリング論理をレバレッジし、（ｌｉｎｅ＃、連続ｌｉｎｅ＃）の形の行を含む複数の「ライト」データキャッシュを得、それらにキャッシュに関して、複数のライトデータキャッシュをマージする（Ｍｅｒｇｅ−Ｍｕｌｔｉ−Ｌｉｇｈｔ−ＤａｔａＣａｃｈｅｓ）一般的なアルゴリズムを実行して、実（ＳＫＩＰ，ＴＯＰ）ウィンドウを見つける。最初のＳＫＩＰ＋ＴＯＰウィンドウが既に取り出されたことが分かったら、一部のセグメントジョブをより早く停止することができることに留意されたい。本明細書ではｃｌｉｎｅ＃ｓとも呼ぶ連続ｌｉｎｅ＃ｓは、列ストレージ内で物理的に隣接しており、フィルタ述語にマッチするラインのカウント（ｃｏｕｎｔ）である。したがって、（ｌｉｎｅ＃，ｃｌｉｎｅ＃−ｓ）フォーマットは、述語にマッチし、連続した形で物理的に保存されているデータのチャンク（ｃｈｕｎｋ）を記述する。それらのチャンクは、列に基づいてデータがコンパクト化されたことの副産物であることがあり、並べ替え演算が実行される列上で自然の（ｎａｔｕｒａｌ）ＲＬＥシーケンスが見つかることもある。ｃｌｉｎｅ＃ｓは「フィルタリングされた」チャンクを取り扱うため、バケットのＲＬＥレングスはｃｌｉｎｅ＃ｓとは異なることにも留意されたい。

次いで、それらの分割された複数のウィンドウに関して、単純なＩＳＡＭのケースと同じ方法で行セットを構築することができる。図４は、このプロセスの概要ブロック図である。外部クエリスペック４１２は、サーバ４００のクエリハンドラ４１０によって処理され、内部クエリスペック４３５に変換される。

フィルタ述語を含むこのクエリはクエリカーネルに転送され、フィルタとマッチする連続した行のチャンクが、それらが存在する位置とともに得られ、それらのチャンクから、このケースでは並べ替えを実行する必要なしに、「選択された」ウィンドウが計算される。

フィルタリングはしないが、並べ替えはするクエリに関して、これも、より汎用的な「フィルタリングも並べ替えもするクエリ」（後により広範囲に論じる）の単純化されたケースである。この特定のケースでは、実際のフィルタを適用する必要はないが、並べ替えられたデータを出力する必要がある。次いで、値のコンパクト化された列ベースシーケンス４６０に関して問い合わせるクエリカーネル４５０によって、このデータが、式４４０に従ってフィルタリングされる。クエリカーネル４５０は次いで、フィルタとマッチしたｌｉｎｅ＃および連続ｌｉｎｅ＃ｓ（ｃｌｉｎｅ＃ｓ）を含む行４３０を返す。前述のとおり、ライトデータキャッシュ４２５を使用して、行セット出力４１５を形成するための処理およびマージ４２０の操作をサポートすることができる。

この点に関して言えば、並べ替えられた列上の分布が、選択される実行計画に影響を及ぼすことに留意されたい。本明細書で実行されるさまざまな効率的なフィルタリングおよび並べ替え演算の単純化された概要は、フィルタ述語がクエリカーネルにプッシュされないことを除いて、汎用的なケースと同じ演算が実行されるということである。ある時点で、（並べ替えられた列のＤａｔａＩＤ，ｌｉｎｅ＃，ｃｌｉｎｅ＃ｓ）を含む行のチャンクが得られ、これらのチャンクが、前述のより単純なケース（ＩＳＡＭケースおよびフィルタリングはするが並べ替えはしない（Ｆｉｌｔｅｒｅｄ−ｂｕｔ−Ｎｏｔ−Ｓｏｒｔｅｄ）ケース）に対して説明した方法と同じ方法で行セットを構築するために使用される。

大量のデータに関するフィルタリングおよび並べ替えを含むクエリに関しては、クエリが、フィルタまたはＯＲＤＥＲ ＢＹ節を含む場合、その要求を満たす実行計画が決定される。実際の計画は、データのパターンに依存し、その因子には、並べ替えが実行される列上のＤａｔａＩＤの分布および基数（ｃａｒｄｉｎａｌｉｔｙ）が含まれる。以下のセクションでは、これをより詳細に検討し、データの分布およびパターンが実行計画にどのように影響するのかを説明する。

並べ替えられた列の異なるデータ分布に対する実行計画に関して、図５は、遭遇しうる潜在的なデータ分布５００、５１０、５２０、５３０のリストである。これらのそれぞれのケース５００、５１０、５２０、５３０の処理については、後により詳細に説明する。説明を容易にするためより単純なケースから始めて、より複雑なケースへ一般化する。図５では、ｘ軸に、別個のＤａｔａＩＤがあり、ｙ軸に、ＤａｔａＩＤの頻度（重複（ｄｕｐｌｉｃａｔｅ）の数）が示されている。

ケース５００は、多くの重複を有する分布、例えば合理的な数の別個のＤａｔａＩＤを有するが、歪んだケース（ｓｋｅｗｅｄ ｃａｓｅ）ではない分布を示す。一般に、この分布は、合理的な数の別個のＤａｔａＩＤがあり、それぞれが多数の重複を有し、極端に「歪んだ」ケース（例えば値の半分が単一のＤａｔａＩＤとマッチする）ではないため、このシナリオにおいて「良い（ｇｏｏｄ）」基数として知られている。

ケース５００の例は、一様分布、正規分布、またはテーブル内の行の数に比べて別個のＤａｔａＩＤの数が合理的に少ない、すなわち、１＜＜｜別個のＤａｔａＩＤ｜＜＜｜テーブル内の行の数｜である他の任意の分布を含むことができる。「良い」基数の一例としては、例えば最大１００万個の別個のＤａｔａＩＤを有し、歪んだ分布を持たないテーブルが考えられる。

それらのタイプの分布上にレバレッジすることができる属性は、概して、ＤａｔａＩＤが何回も重複し、したがって、それぞれのＤａｔａＩＤに対応する発生数、例えば１０億行が存在するが、別個のＤａｔａＩＤは１００万個しかないことを記述する統計量（ヒストグラム）を追跡する（ｔｒａｃｋ）ことができることである。したがって、並べ替えられたＤａｔａＩＤを発生数とともに保持する、例えば階層処理時間に計算された正確なヒストグラムを実現することができる。

この点に関して、ヒストグラムは「並べ替えられている」ことに留意されたい。その結果、実際のカウントの代わりに、次のＤａｔａＩＤを調べることによってカウントを計算することができる累積和を保持することができる。必要な場合には、逆方向の並べ替え順のために、物質化された（ｍａｔｅｒｉａｌｉｚｅｄ）累積和を実際のカウントから差し引くことによって、逆方向の累積和を計算することができる。累積和の概念をさらに下表Ｉに示す。

フィルタを適用しないケースでは、この正確なヒストグラムを使用して、フィルタを適用しなかった場合に特定のウィンドウで見ることができる実際のＤａｔａＩＤを（並べ替えられた列から）決定することができる。

例えば、以下のクエリを考える。

上表Ｉのヒストグラム情報を調べれば、行３１２および３１３に対しては「バス」が返され、行３１４、３１５、３１６に対しては「自動車」が返されることが簡単に分かる。

バスおよび自動車を含む正確な行が何なのかに関しては、以下のクエリを実行することによってこれを決定することができる。

これクエリから、ストレージｌｉｎｅ＃ｓに従って、最後の２つのバスおよび最初の３つの自動車がピックアップされる。

＜他の列＞の代わりにｃｌｉｎｅ＃ｓを使用し、出力された行セットを流すことに関してより高速である可能性があるＳＥＬＥＣＴを実行することができるが、関係が含まれない場合、すなわちデータが単一の物理テーブルから到来し、ＮＡＴＵＲＡＬ ＪＯＩＮがない場合に、これは最もよく機能することに留意されたい。さらに、フィルタが適用される場合には、予め計算されたヒストグラムが一切なくてもこれを実行することができるが、クエリカーネルを使用してある統計量をその場で生み出すことにより、クエリ時にそれが少し遅くなる可能性があることにも留意されたい。

さらなる詳細として、フィルタが適用される場合には、順序付けされたＤａｔａＩＤおよびそれらのカウントを記述したヒストグラムは、フィルタアグノスティック（ｆｉｌｔｅｒ ａｇｎｏｓｔｉｃ）であるため十分ではない。したがって、どれが表示される実際の行であるかが決定される。例えば、以下のクエリを考える。

最初に、この述語を直接に評価すべきではない。なぜなら、このクエリカーネルは既に、これを実行するための多くの最適化をその場に有しており、そのため、この述語は、ＷＨＥＲＥ節を評価するためにクエリカーネルへプッシュされるためである。

次いで以下のような内部クエリが実行される場合には、

車両ごとのマッチのカウントを保持する１座標の「標準」データキャッシュが受け取られる。ＤａｔａＩＤが並べ替えられ、それらに関する累積和が維持される。このデータ分布例に関しては、合計で約１００万個以上の別個のＤａｔａＩＤが存在し、そのうちの一部は、おそらくフィルタによって除外される。

この時点で、上記の統計量（フィルタリングしないケース）と同じ統計量（ヒストグラム）が得られる。主な違いは、この統計量が次にフィルタリングされた行に適用されることである。フィルタリングしないケースと同じ形式の後続のクエリは、ウィンドウからのＤａｔａＩＤにマッチする行をもたらす。主な違いは、＜ｕｓｅｒが指定した述語＞が、以下のように、クエリカーネルにプッシュされて処理されることである。

これは基本的に、統計量、クエリカーネル、およびＶｅｒｔｉＰａｑの副産物である自然の連続したシーケンスをレバレッジする、（ＳＫＩＰ，ＴＯＰ）ウィンドウを得るための選択アルゴリズムの変形である。フィルタリングされたデータに関するＣＯＵＮＴ（）およびＲＵＮＮＩＮＧ＿ＳＵＭ（）を得る代替法は、階層を知っている列をクエリカーネルにフィードすることであることでありうることに留意されたい。この方法は、後続の並べ替えを回避するが、仮想列を提供する点から実現に手際を要するだけでなく、クエリカーネル実行中に、性能に悪影響を及ぼすと考えられるランダムメモリアクセスが関与する。

図６は、実際の出力ウィンドウを決定するために論理的観点から何が実行されるのかを説明する図である。ヒストグラム６１０は、処理鎖を通じて効率的な結果６２０を生成する、上でより詳細に説明したＤａｔａＩＤ６００および累積和６０２のリストを含む。

ＤａｔａＩＤあたりの重複が非常に少ない状況では、別個のＤａｔａＩＤが多数存在するが、歪んだケースは存在しない。例えば、取引ＩＤまたは（例えば多数のＤａｔａＩＤがあり、重複が非常に少ない）何か類似のものによって並べ替えるときのケースのように、別個のＤａｔａＩＤが多数あるケース、例えば１０億行のうちの１億行〜１０億行が別個のＤａｔａＩＤであるケースを考える。そのケースの分布は、ｙ軸に発生数、ｘ軸に別個の値を示す図７の分布７００のように見える。

この状況では、正確なヒストグラムは実現可能ではなく、フィルタリングされたＣＯＵＮＴ（）に対してクエリカーネル要求を実行し、巨大なデータキャッシュを得ることも実際的ではない（多数の別個の値→高い基数→大きなデータキャッシュ）。

したがって、このような状況では、離散化法を使用することができる。すなわち、（順序に関して隣接する）連続した一組のＤａｔａＩＤを離散的な対応物にマップし、次いでその離散値に関するヒストグラム（統計量）を構築する。この概念を下表ＩＩに示す。

同時に、表ＩＩＩに示すように、ＧｒｏｕｐＩＤに関して累積和を計算することができる。

この離散化を使用すると、クエリカーネルからのそれぞれのＤａｔａＩＤ（ＳＥＬＥＣＴ ＤａｔａＩＤ、ＣＯＵＮＴ（）ＧＲＯＵＰＢＹ ＤａｔａＩＤ）の正確な発生数に関する統計量を得る代わりに、順序付けされた離散グループ内で、基本的に以下の内部クエリを実行することによって値の発生数を得ることを除き、上記のアルゴリズムと同じアルゴリズムを使用することができる。

これは、最初にある迂回（ｉｎｄｉｒｅｃｔｉｏｎ）レベル（離散化フェーズ（ｐｈａｓｅ））を経ることを除き、適当に（ｎｉｃｅｌｙ）分散した平均的な数の重複に対する前述のアルゴリズムの一般化であることに留意されたい。より具体的には、データが適当に分布したケースとはちょうど、離散化が実際に１→１であり、ＤａｔａＩＤ＝＝ＧｒｏｕｐＩＤである（１つのグループが正確に１つの値を有する）特定のケースである。

このクエリカーネルがＧｒｏｕｐＩＤに対してどのように機能することができるかに関して、ＧｒｏｕｐＩＤは、（ＤａｔａＩＤだけを処理することができる）クエリカーネルの外側の概念であるため、１つの一般的な解決策は、外部キー（ＦＫ）→主キー（ＰＫ）に対して「プロキシ（ｐｒｏｘｙ）」列が機能するのと同じように、セグメントクエリに「仮想」列をフィードすることである。この仮想列は、実際の現在のストレージ行ＤａｔａＩＤに対応するＧｒｏｕｐＩＤを返す。

１０億個のＤａｔａＩＤが存在する場合によく適した別の解決策では、１０億の別個のＤａｔａＩＤが、ストリングではなく、数に対応し、それらを「値によってエンコードする」ことができる。この解決策は、１０億の別個の数を保持する列に対してはよく機能するが、１０億の別個のストリングを保持する列に対しては機能しない。

ＤａｔａＩＤ→ＧｒｏｕｐＩＤを解くためのルックアップ中のクエリカーネル内でのランダムメモリアクセスを意味する１０億の別個のストリングの場合に関しては、少なくとも、そのデータセットを介して階層にアクセス可能である場合には、ｇｒｏｕｐ＃を識別するのにＤａｔａＩＤの位置だけで十分であるため、離散グループを計算するときに、ストリング比較は必要ない。１つの解決策は、値によってエンコードするときだけでなく、ハッシュによるエンコードするときにも、「ｉｆ ｖ１＞ｖ２→ｄｉｄ１＞ｄｉｄ２」属性を強制することである。これを実行する間、強制にはコストが伴い、このコストは、クエリ時にではなく処理時に支払われる。さらに、この方法は、（ｄｉｄ＞ｖ１ ＡＮＤ ｄｉｄ＜ｖ２のようなものをバイパスする）ＯＲスライス（ＯＲ ｓｌｉｃｅ）を使用したときにクエリカーネル性能を向上させることができること、ならびに階層繰返し子を「非物質化（ｄｅｍａｔｅｒｉａｌｉｚｅ）」し、ｐｏｓ＝ｄｉｄ−ＸＭ＿ＤＡＴＡ＿ＩＤ＿ＮＵＬＬのような合成関数を有することによって階層繰返し子を改良することを含む、別のいくつかの利点を有すると考えられる。

基本的に、値によるエンコードは、関数ｆ：ｖａｌｕｅ→ＤａｔａＩＤを使用し、この関数に対しては以下の属性が維持され、

ＤａｔａＩＤが別のＤａｔａＩＤ（ＮＵＬＬに対するＤａｔａＩＤを除く）よりも小さい場合には逆になり、この場合には、値も同じように順序付けされる。

このことは、ＤａｔａＩＤの相対的な順序が、並べ替えられた値の相対的な順序と一致することを意味し、隣接するＤａｔａＩＤは隣接する並べ替えられた値に対応するため、隣接するＤａｔａＩＤをグループ化することができる。ランダムメモリアクセスを必要としない１つのグループ化戦略は、ＤａｔａＩＤをＧｒｏｕｐＩＤにマップする単純な関数ｇ：ＤａｔａＩＤ→ＧｒｏｕｐＩＤを適用することによって、（Ｍｉｎ−ＤａｔａＩＤ．．．Ｍａｘ−ＤａｔａＩＤ）内の別個のＤａｔａＩＤの空間全体を、比較的に等しい（数値）区間（ｉｎｔｅｒｖａｌ）に分割することである。

他のグループ化アルゴリズムおよび戦略は、ヒストグラムに基づくものとすることができる。設定する境界については、後にデータパターンの判定について述べるときに説明する。

この離散化はしたがって、ＤａｔａＩＤの空間を、ＧｒｏｕｐＩＤのより小さな空間に圧縮すること、およびＤａｔａＩＤの空間が、ＧｒｏｕｐＩＤのそれぞれの発生に対してより多く重複を有すること可能にし、それにより、この問題は、適当に分散したＤａｔａＩＤのケースに関して上で解決した問題に変化する。

図８に例示的に示すように、ＤａｔａＩＤのグループ８００に関する統計量８１０をクエリカーネルから得た後、以下の形のクエリを実行する。

ここで、統計量から得られる累積和に関してＳＫＩＰ／ＴＯＰウィンドウのマッチングを実行し、それに対する行が出力される実際の候補ＧｒｏｕｐＩＤを受け取る。

この候補ＧｒｏｕｐＩＤ（例えばＧ＃１２、Ｇ＃１３、Ｇ＃１４）は、候補ＤａｔａＩＤのリストに拡張される。

（既に論じた値によるエンコード関数の属性のため）値によるＤａｔａＩＤに対して、選択されたＤａｔａＩＤをフィルタリングする追加の述語を、（より高速なクエリカーネル評価を可能にするために）以下のように書き直すことができるので、これは有益である。

この場合の結果は、データ分布のよりいっそう極端なケースに対して後に説明する並べ替えアルゴリズムを容易に適用するのに適した一組の特殊な「ライト」データキャッシュである。

このタイプのデータパターンに対するｃｌｉｎｅ＃ｓは、追跡（ｔｒａｃｋｉｎｇ）を必要としない可能性があり、列ベース並べ替えの代わりに、ＤａｔａＩＤの連続したチャンクを知らない標準並べ替えアルゴリズムを使用することができることに留意されたい。その理由は、ｃｌｉｎｅ＃ｓの追跡は、ほとんど全てが＝＝１であるときに、不必要なオーバヘッドとなるためである。理論上の変曲点は、フィルタリングされたＤａｔａＩＤの連続したチャンクの平均値がｃｌｉｎｅ＃ｓ＞４であるときであるが、実用上の限界はおそらくこれよりも少し高い。任意選択の一実施形態では、述語の選択性（ｓｅｌｅｃｔｉｖｉｔｙ）および／または並べ替えられた列の平均ＲＬＥランに基づいて、この値を推定することができる。

ＤａｔａＩＤが少数で、重複が１０億あるスパイクを有するデータ分布の状況に関して、１０億個の一組の行にまたがる［性別］列に対するデータ分布を考える。この点に関して言えば、図９のサンプル分布９００に示すように、それぞれが５億個の重複を有する２つの別個のＤａｔａＩＤを示す統計量が得られる。ウィンドウがたまたま端にある場合には、１０億の全ての行を並べ替える必要がある。たとえ、一方の別個のＤａｔａＩＤだけが選択されたウィンドウ内にあると判定された場合であっても、それは依然として、フィルタがない場合、またはフィルタの選択性が、ほとんど全てが含まれるようなものである場合に、その行を要求している後続のクエリが、５億行を有するデータキャッシュを返すことを意味する。

データのこのパターン対してレバレッジすることができる１つの属性は、スパイクを有するそれらのＤａｔａＩＤがおそらく、ＲＬＥの形に圧縮されることである。このことは、並べ替えが実行される列がおそらく、長いＲＬＥランを有することを意味する。そのため、やはりフィルタが存在しない場合には、行ごとに並べ替える代わりに、列ベース並べ替えに従ってＲＬＥシーケンスを並べ替えることができる。ＲＬＥの能力のため、これは、桁違いに高速になると予想される。

しかしながら、フィルタが適用される場合には、出力されるセット内に一部の行が含まれない可能性があるため、直接にＲＬＥシーケンスに基づいて並べ替えを実行することはできない。この場合には、ｃｌｉｎｅ＃ｓ（述語を通過した行の連続したチャンク）を得るために、特殊なクエリカーネル要求が生成され、並べ替えは、ｃｌｉｎｅ＃ｓを追跡している間に、複合キー（ＤａｔａＩＤ，ストレージ−ｌｉｎｅ＃）に関して実行され、この追跡は、いくつの行が、述語とマッチする並べ替え列上に不変のＤａｔａＩＤを有する有効な行であるかを指示する。

図１０は、実行されるものの論理図である。ＲＬＥエンコードされた男性および女性データに関して、下記のクエリなどの内部クエリが送られる。

応答として、クエリカーネルの見地からデータキャッシュが返されるが、内部的には、集計をサポートする必要がなく、やはり後により詳細に説明するように、フィルタを通過した、連続したラインのチャンクの列ベース並べ替えを含む次の演算に対してより良好にフィットする特殊な「ライトデータキャッシュ」（後に詳述する）が組み込まれる。

次に、歪んだデータ分布に関して、これは、１０億の別個のＤａｔａＩＤが存在し、その一部は固有だが（決して重複しないが）、それでも重複した５億個の値を有するあるＤａｔａＩＤ、例えばスパイクを有するＤａｔａＩＤを有する最も汎用的なケースを表す。

図１１に示した分布の一例１１０は、１０億個のレコードを有するテーブルを含み、その列上の値の半分はＮＵＬＬであり、残りの半分は、ほとんど完全に重複しない個のＤａｔａＩＤである。例えば、あるデータベースは、それぞれの従業員の住所を有することがあり、それらの住所は固有である傾向があるが、従業員の半分に対するレコードデータがないこともあり、したがって、値「Ｄｏｎ′ｔ ｈａｖｅ ａｄｄｒｅｓｓ ｄａｔａ」（住所データなし）が何回も重複する。

この場合、（離散化を使用して）１０億の別個のＤａｔａＩＤをターゲットとする解決策は、スパイクを処理する困難を有し、スパイクを有するケースをターゲットとし、不変のＤａｔａＩＤの長く連続したランを利用する解決策は、全く重複を持たないＤａｔａＩＤに関するウィンドウを処理する困難を有する。基本的に、ｃｌｉｎｅ＃−ｓに気を配ることができるが、そのフィルタにマッチする行の全てのシーケンスは、それら自体の別個のＤａｔａＩＤを有し、したがってｃｌｉｎｅ＃ｓに気を配るオーバヘッドは不要である。

このような場合、方法は、データの「ローカル」分布に対して適当な実行計画を使用することである。このケースでは、大域的なデータ分布は重要ではなく、要求されたデータの特定のウィンドウに対してデータがどのように分布しているかの方が重要である。これを図１２に示す。クエリおよびウィンドウがスパイクを巻き込む場合、スパイクを有するデータアルゴリズムを適用することができる。一様分布部分が巻き込まれる場合、離散化技法を適用することができる。

これを達成するためには、この場合も、ヒストグラムおよび統計量を集める。分布ヒストグラムを計算するため、サンプリングを実行して、スパイクを見つける。この点に関しては、適当な実行戦略を選択するために、データの一般的なパターンを知ることが望ましい。要求されたウィンドウに対するある候補ＤａｔａＩＤが「スパイク」に含まれることが分かっている場合には、例えば＞重複が１００万または他のしきい値よりも大きいか否かを推定する。

（ＤａｔａＩＤが非常に少数の重複を有し、それらを一緒のグループに分けたいときに）離散化を実行するケースでは、順序付けされた隣接するＤａｔａＩＤのグループをどのように分割するか、すなわちそれぞれのバケットにいくつ含まれるのかを推定する。１つの方法は、別個のＤａｔａＩＤの最小−最大空間全体を等しい区間に分割し、固定された区間サイズに依存する非常に高速なＤａｔａＩＤ←→ＧｒｏｕｐＩＤ変換をそれぞれのグループに対して使用する方法である。

このために、必要ならば、ヒストグラムを構築することができ、これは、処理時またはクエリ時に実行することができる。このヒストグラムは、例えば無作為に抽出すること、または１／１０００程度の値をチェックし、次いでそのヒストグラムを空間全体に広げることに基づくことができる。（１／１０００の比率では、１０億行は単に１００万ランダムメモリアクセスであるため、）このヒストグラムは、比較的に速い時間で構築することができるはずである。

このデータに関する無作為抽出はさらに、所与のＤａｔａＩＤがスパイクであるか否か、例えば１，０００，０００個の標本が抽出され、ＤａｔａＩＤが半分の時間で見つかるかどうかを知らせる。「スパイクを有する」ＤａｔａＩＤのこのリストを追跡することができ、１０億行に対して、別個の値は１００個未満であるはずである。さらに、並べ替えを実行する判断を下す前に、ウィンドウがこのＤａｔａＩＤを含むか否かを、ｃｌｉｎｅ＃ｓに基づいて、またはｃｌｉｎｅ＃ｓに基づかずに（例えば全てのＤａｔａＩＤが別個である場合）調べることができる。

ＶｅｒｔｉＳｏｒｔまたは列ベース並べ替えに関して、１０億個の行に関する並べ替えを実行するため、（並べ替えられ、かつ／またはフィルタリングされた列上のＲＬＥシーケンス／バケットを利用して）データが、値の列ベースシーケンスに従ってＶｅｒｔｉＰａｑ処理されまたはコンパクト化にされることがレバレッジされることは、歪んだ分布の議論の際に既に述べた（ただしこれは、他の大部分のケースでも当てはまる）。

この点に関して言えば、（クエリカーネルが、データだけでなく、フィルタリングされたＤａｔａＩＤの連続したチャンクについてのメタ情報をも返すようにすることによって）内部（ストレージ）ＲＬＥレングスを知ることにより、並べ替えプロセスを、それらのＲＬＥレングスを使用して最小化することができる。したがって、値が変化しない１０億の行が存在する場合には、たとえそれらがフィルタによってチャンクに分割される場合でも、返されたデータキャッシュに関する物理的な並べ替えは必要ない。

これを実現するために、Ａ）データだけではなく、メタデータも返すようにクエリカーネルに何らかの変更を加え（実際にはこれは、特殊なデータキャッシュ内の連続したラインの集計を実行することによって、力ずくで実行することもできるため、不必要なスキャンを回避するバケット処理レベルでの最適化である）、Ｂ）（ＤａｔａＩＤ）→（ｌｉｎｅ＃，ｃｌｉｎｅ＃ｓ）（ｌｉｎｅ＃，ｃｌｉｎｅ＃ｓ）．．．を追跡することができ、並べ替え演算の複雑さを、ｎ^*ｌｏｇ（ｎ）（ｎは行数）からｍ^*ｌｏｇ（ｍ）（ｍは、ウィンドウ内の別個のＤａｔａＩＤの数）へ低減することを可能にする、特殊な「ライトデータキャッシュ」を実現することができ、かつ／またはＣ）同じプロセッサによって異なるセグメントに対して再使用されたデータキャッシュの高速インプレースマージ（ｆａｓｔ ｉｎ−ｐｌａｃｅ ｍｅｒｇｅ）、ならびにクエリカーネルによって生成された全ての「ライトデータキャッシュ」が集計される最終ステップ中の高速マルチマージを可能にする、「ライトデータキャッシュ」の特殊な集計を実現することができる。

図１３は、並べ替えられたデータに関するウィンドウを生成する際に含まれるコンポーネントのスタックの代表的な図である。これは、サーバ１３４０によって受け取られ、クエリハンドラ１３５０によって処理されるクエリスペック１３００を含み、クエリハンドラ１３５０は、ｌｉｎｅ＃、ｃｌｉｎｅ＃および累積和を含む、フィルタリングされたデータに関するインデックス１３６０を生成することができる。この点に関して、処理鎖のボトムアップ（ｂｏｔｔｏｍ ｕｐ）に続いて、列ベーススキャン１３２０の適用中に列ベースコンパクト化１３３０がレバレッジされる。前述のとおり、列ベーススキャン１３２０とともに、ライトデータキャッシュを使用することができるが、このライトデータキャッシュは集計を実行しない。最後に、列ベース並べ替え１３１０からの結果セットが、クライアントに返す行セット１３０２として表現される。

この点に関して言えば、示されているとおり、長いＲＬＥシーケンス（例えば性別）に対するフィルタの適用が、連続したＤａｔａＩＤ（ｃｌｉｎｅ＃ｓ）のチャンクを返すことがある。しかし、それらは、フィルタリングされた連続したデータを表す仮想チャンクである。したがって、（ＤａｔａＩＤ，ｌｉｎｅ＃）を複合キーとして使用し、ｃｌｉｎｅ＃を追跡することによって、（ＤａｔａＩＤ，ｌｉｎｅ＃，ｃｌｉｎｅ＃ｓ）の並べ替えを実行することができる。

フィルタ演算によって、ＲＬＥチャンクを、以下のような形にフラグメント化することができることにも留意されたい。

最終ビュー（ｖｉｅｗ）内のストレージラインの順序を保持することが望ましいため、たとえそれらの間にギャップがあったとしても、同じＤａｔａＩＤに対応するｌｉｎｅ＃−ｓを連結することができ、それらは、以下のような形を有することができる。

ここまでで、（最終ウィンドウ内に見える別個のＤａｔａＩＤだけを並べ替え）、実際のラインを並べ替えない並べ替えははるかに高速になる。

並べ替えた後、それらの結果を、ＷＨＥＲＥ節に固有のインデックスとして集計することができ、インデックスは累積和も追跡する。例えば、Ｌｉｎｅ＃は保持されるが、ｃｌｉｎｅ＃は、累積和から推論することができるためもはや必要ではない。

したがって、このインデックスのフォーマットを、（ｌｉｎｅ＃，累積和）を含むテーブルと見ることができる。なお、このインデックスは、ＷＨＥＲＥ節に固有であり、任意選択でキャッシュに入れることができる。キャッシュに入れる場合には、圧縮のため、および、後に、キャッシュに入れられたＷＨＥＲＥに、より制限的なＡＮＤ節が適用される場合に、このデータをクエリカーネルにフィードバックするために、そのキャッシュを物理的なストレージテーブルとして維持することに価値があることがある。

ｃｌｉｎｅ＃ｓおよび「ライトデータキャッシュ」に対するクエリカーネルサポートに関して、選択並べ替えのためのある統計量（例えばフィルタリングされたデータに関するＧＲＯＵＰＢＹ）を得るために、クエリカーネルを使用することができ、クエリカーネルは、ＤａｔａＩＤが含まれることを知った後に、フィルタリングされた実際の行を得るために使用される。

しかし、行自体は出力されず、その代わりに、バケット指向並べ替えアルゴリズムを実行するのに役立つ（ＤａｔａＩＤ，ｌｉｎｅ＃，ｃｌｉｎｅ＃）を使用する。

（ＤａｔａＩＤ，ｌｉｎｅ＃，ｃｌｉｎｅ＃）の形の行を要求しているクエリのためにｌｉｎｅ＃、ｃｌｉｎｅ＃を得ることに関して、（ＤａｔａＩＤの代わりに）ｌｉｎｅ＃を返すある仮想列をフック（ｈｏｏｋ）することができ、クエリカーネルはラインを得るためにある仮想機構を使用するため遅くなることはあるが、それぞれのラインをカウントすることによって「ライトデータキャッシュ」内での集計を達成することができ、または、偽（ｆａｋｅ）の列全体を物質化することができるが、ラインはそれぞれ異なるｌｉｎｅ＃を有するため、これはさらに、スキャン／バケット化（ｂｕｃｋｅｔｉｚａｔｉｏｎ）の純粋さを破壊することになろう。フィルタとマッチする実際のｌｉｎｅ＃（ｃｌｉｎｅ＃）をカウントするため、別の「偽の」（しかし純粋な）列が使用されることになる。これも遅くなるが、この場合には、常にＰｕｒｅ（）値を返すライトエヌメレータ（ＬｉｇｈｔＥｎｕｍｅｒａｔｏｒ）をシミュレートすることができる。

より高速な解決策は、（ｌｉｎｅ＃，ｃｌｉｎｅ＃）を特殊なデータキャッシュへ出力するための論理を、クエリカーネルに追加することであろう。

この場合のクエリカーネル内のバケットプロセッサは、バケットごとに述語を評価するが、それぞれのマッチに対してＷＨＥＲＥ節があれば、

ＷＨＥＲＥが純粋であり、並べ替えられた列に対するバケットが純粋である場合には、
ａ．並べ替えられた列の純粋な（ＤａｔａＩＤ）を、ＤＣ座標として、
ｂ．バケットが始まるｌｉｎｅ＃を、ＤＣ座標として、
ｃ．バケットサイズ（ｃｌｉｎｅ＃）を、集計された測度（ｍｅａｓｕｒｅ）として
データキャッシュに送る必要があり、

ＷＨＥＲＥが純粋であり、並べ替えられた列に対するバケットが不純であるか、または

ＷＨＥＲＥが不純であり、並べ替えられた列に対するバケットが純粋であるか、または

ＷＨＥＲＥが不純であり、並べ替えられた列に対するバケットが不純である場合には、
ａ．並べ替えられた列の現在のＤａｔａＩＤを、ＤＣ座標として、
ｂ．マッチする行が見つかったｌｉｎｅ＃を、ＤＣ座標として、
ｃ．（ｃｌｉｎｅ＃）を、集計された測度（ｍｅａｓｕｒｅ）として
データキャッシュに送る必要がある。

行のＳＫＩＰ＋ＴＯＰ＃が（セグメントからの）フィルタによって受け入れられた後は、そのウィンドウに対してそれ以上のデータは必要ないことが分かっているいくつかのケース（例えば並べ替えられていないが、フィルタが適用されたデータ）を除き、ＳＫＩＰ＋ＴＯＰマッチ後の停止は任意選択である。データはどのみち出力されないため、この内部要求に対して、より高速に停止し、データをそれ以上スキャンしないように、セグメントクエリを構成することができる。その時点で、列ベーススキャンを停止することができる。

ライトデータキャッシュに関して、クエリカーネルから得られた（ＤａｔａＩＤ、ｌｉｎｅ＃、ｃｌｉｎｅ＃）データに対する集計は実行されないが、そのデータは、並べ替えの準備ができていなければならない。そのために、標準データキャッシュを使用する代わりに、実際の集計を実行することはできないが、並べ替えを容易にする形で（ＤａｔａＩＤ、ｌｉｎｅ＃、ｃｌｉｎｅ＃）を累積する専用の「ライト」データキャッシュを、クエリカーネルにフックすることができる。

クエリカーネルの点からは、データキャッシュは（論理的に）、表されたセル１４００を有する図１４のように見える。離散化の場合には、図１４のＤａｔａＩＤはＧｒｏｕｐＩＤに置き換えられることに留意されたい。

実際は、同じ（ｌｉｎｅ＃，ＤａｔａＩＤ）座標にはヒットせず、加算は不要である（同じＤａｔａＩＤを含むクロスセグメント行のある合体（ｃｏａｌｅｓｃｉｎｇ）を実行することができるが、ｌｉｎｅ＃は実際に異なるため、これは「標準の」加算とは異なる）。

所与のセグメントに関して、クエリカーネルは、低いｌｉｎｅ＃から高いｌｉｎｅ＃へデータを順番にスキャンすることが分かっており、そのため、ｌｉｎｅ＃は（セグメントの境界において）昇順である。これは、ｌｉｎｅ＃が「予め」並べ替えられることを意味する。

高速並べ替えのため、１次並べ替えキー＝ＤａｔａＩＤ、２次並べ替えキー＝ストレージ−ｌｉｎｅ＃に基づいて、別個のＤａｔａＩＤが追跡され、所与のセグメント内の連続した（ｌｉｎｅ＃，ｃｌｉｎｅ＃ｓ）のシーケンスも追跡される。

それぞれのセグメントに対するハッシュ（ＤａｔａＩＤ）→（ｌｉｎｅ＃，ｃｌｉｎｅ＃ｓ）の順序付けされたシーケンスを使用して、これを達成することができる。最後に（マルチマージフェーズ中に）、（ｓｅｇ＃１＜ｓｅｇ＃２）の場合には、ｓｅｇ＃１内の全てのラインがｓｅｇ＃２内のラインの前にあるため、Ｏ（１）時間内の異なるセグメントに由来する順序付けられたシーケンスを照合することができる。

物理的に、それぞれのセグメントに対して、このハッシュは、ｌｉｎｅ＃、ｃｌｉｎｅ＃対によって記述された値を指すキー：ＤａｔａＩＤ１５００を有する図１５のようなものを有する。チャンクのシーケンスに関連した増大するメモリのために、インクリメンタル（ｉｎｃｒｅｍｅｎｔａｌ）ポリシーまたは推定ベースのポリシーに対するインクリメンタルアロケータ（ａｌｌｏｃａｔｏｒ）を使用することができる。

ＤａｔａＩＤ、または離散化が適用される場合にはＧｒｏｕｐＩＤの実際の並べ替えに関して、（値によるＤａｔａＩＤが使用される場合、ＧｒｏｕｐＩＤが使用される場合、または階層情報が使用可能な場合には、）実際の値を見る前に、ウィンドウ内の別個の値の並べ替えを実行することができる。

ライトデータキャッシュのマージに関して、クエリカーネルに由来する複数の「ライト」データキャッシュを、内部要求の結果として得ることができる。これは、実際に、クエリアグリゲータ（Ｑｕｅｒｙ Ａｇｇｒｅｇａｔｏｒ）が、複数のプロセッサ上で複数のセグメントクエリ（セグメントにつき１つ）をスケジュールするためであり、最終的には、プロセッサの数までの別個のデータキャッシュを生成することができる。

最終フェーズの間に、セグメント内の全てのｌｉｎｅ＃が、別のセグメント内の全てのラインよりも大きいか、または小さいという属性を利用することによって、Ｏ（ｍ）時間内の複数のハッシュを高速にマージすることができる（ｍ＝見えるウィンドウ内の別個のＤａｔａＩＤ）。この属性は、所与のＤａｔａＩＤに対してチャンクのリストの合体がうまくいくことを意味する。

最終インデックスの構築に関して、これは基本的に、ＷＨＥＲＥ節、ＳＯＲＴ列および（通常、歪んだ）ＤａｔａＩＤのセットに依存するインデックスである。

最終クエリカーネル結果から、最も汎用的なケースでは以下のデータが得られる。
（ＤａｔａＩＤ）→（ｌｉｎｅ＃，ｃｌｉｎｅ＃ｓ），（ｌｉｎｅ＃，ｃｌｉｎｅ＃ｓ），（ｌｉｎｅ＃，ｃｌｉｎｅ＃ｓ）．．．

これは、並べ替えられていない複数のデータキャッシュが並べ替えられ、続いてマルチマージされた上記のステップで並べ替えられた。次いで、以下のデータが得られ、
（並べ替えられたＤａｔａＩＤ）→（ｌｉｎｅ＃，ｃｌｉｎｅ＃ｓ），（ｌｉｎｅ＃，ｃｌｉｎｅ＃ｓ），（ｌｉｎｅ＃，ｃｌｉｎｅ＃ｓ）．．．
これから、以下のインデックスが構築される。

（ｌｉｎｅ＃、累積和）

ｌｉｎｅ＃は、クエリカーネルから来たときのストレージ行番号である。

累積和は、（ＳＫＩＰ，ＴＯＰ）ウィンドウが位置する仮想ｌｉｎｅ＃を与える。このインデックスをキャッシュに入れることもでき、これにより、ライトデータキャッシュを構築するためにデータを再スキャンすることを回避することができ、スキャンが十分に高速になることがある。

出力された行に関して、クエリハンドリングコンポーネントコード経路と行セットを出力する関連ＵＩコンポーネントは同じ機構を使用することができる。プロデューサ（ｐｒｏｄｕｃｅｒ）としての（ｌｉｎｅ＃，ｃｈｕｎｋ＃）が追加されたクエリスペック（選択された列）および直接にデコードされた行に基づいて生成された行セットが出力される（対応するラインからＤａｔａＩＤを得、辞書（ｄｉｃｔｉｏｎａｒｙ）を調べて、結果を行に入れる）。したがって、ＩＳＡＭ型のアクセスはちょうど、（ｌｉｎｅ＃，ｃｈｕｎｋ＃）に対する単一の（ＳＫＩＰ，ＴＯＰ）値だけが追加されるアクセスの特定のケースである。

実行フローに関して、一実施態様では、モジュール法が使用される。

図１６は、クエリスペック分析モジュール（Ａｎａｌｙｚｅ Ｑｕｅｒｙ Ｓｐｅｃ Ｍｏｄｕｌｅ）のプロセスフローを示す。開始１６００の後、１６１０で、並べ替えが指定されており、１６３０で、ヒストグラムがまだキャッシュに入れられていない場合、１６４０で、ヒストグラムを計算する。ヒストグラムがキャッシュに入れられている場合には、１６６０で、ローカルウィンドウ分布を分析する。１６１０で並べ替えが指定されていない場合には、１６２０で、フィルタが指定されているかどうかを判定する。フィルタが指定されている場合、フローは１６３０へ進む。フィルタが指定されていない場合には、１６５０で、行セットを決定し、出力する。

図１７は、ヒストグラム計算モジュール（Ｃｏｍｐｕｔｅ Ｈｉｓｔｏｇｒａｍ Ｍｏｄｕｌｅ）のプロセスフローを示す。ステップ１７１０は、離散化が必要かどうかを判定する。離散化が必要な場合には、１７２０で、エンコードが値によるかどうかを判定する。エンコードが値によらない場合には、１７３０で、階層が使用可能であるかどうかを判定する。階層が使用可能でない場合、実行できることはほとんどなく、処理は遅くなる可能性がある。１７１０で、離散化が必要でない場合には、ＧｒｏｕｐＩＤ＝ＤａｔａＩＤであり、フローは、統計量を得る１７４０へ進み、１７５０で、ＧｒｏｕｐＩＤに基づいて統計量を並べ替え、累積和を計算する１７６０。任意選択で、１７７０で、ヒストグラムをキャッシュに入れることができ、最後に、１７８０で、ローカルウィンドウ分布を分析する。同様に、１７２０で、エンコードが値によると判定された場合には、ＧｒｏｕｐＩＤ＝ＤａｔａＩＤ／区間であり、フローはやはり１７４０へ進む。１７３０で、階層が使用可能な場合には、ＧｒｏｕｐＩＤ＝階層位層（Ｈｉｅｒａｒｃｈｙ Ｐｏｓｉｔｉｏｎ）（ＤａｔａＩＤ）／区間であり、フローはやはり、上で説明した１７４０へ進む。

図１８は、ローカルウィンドウ分布分析モジュール（Ａｎａｌｙｚｅ Ｌｏｃａｌ Ｗｉｎｄｏｗ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｍｏｄｕｌｅ）のプロセスフローを示す。１８００で、候補ＧｒｏｕｐＩＤを識別する。１８１０で、候補ＤａｔａＩＤを識別する。次いで、１８２０で、クラスタ化されたＤａｔａＩＤが予想されるかどうかを判定する。クラスタ化されたＤａｔａＩＤが予想される場合には、１８４０で、列ベース並べ替え技法を適用する。クラスタ化されたＤａｔａＩＤが予想されない場合には、１８３０で、標準選択アルゴリズム１８３０を使用する。

図１９は、標準選択アルゴリズムモジュール（Ｓｔａｎｄａｒｄ Ｓｅｌｅｃｔｉｏｎ Ａｌｇｏｒｉｔｈｍ Ｍｏｄｕｌｅ）のプロセスフローを示す。１９００で、候補（ＤａｔａＩＤ，Ｌｉｎｅ＃）を選択する。１９１０で、これらの候補を複合キーによって並べ替える。１９２０で、ヒストグラムを使用して（ＳＫＩＰ，ＴＯＰ）ウィンドウを計算する。最後に、１９３０で、行セットを出力する。この点に関して言えば、これは標準選択アルゴリズムであり、このアルゴリズムは、非常に少ない重複（または連続したチャンク）、例えばＤａｔａＩＤあたり平均４未満の連続した重複が予想されるデータに関して、巨大なウィンドウ、例えばＴＯＰ１００万行＋が返されることが予想される場合に有用である。このケースでは、オーバヘッドが利益よりも大きいため、連続したチャンクｃｌｉｎｅ＃ｓを追跡する価値はない。

図２０は、後によりいっそう詳細に説明するＶｅｒｔｉＳｏｒｔ選択モジュール（ＶｅｒｔｉＳｏｒｔ Ｓｅｌｅｃｔｉｏｎ Ｍｏｄｕｌｅ）のプロセスフローを示す。２０００で、インデックスがキャッシュに入れているかどうかを判定する。インデックスがキャッシュに入れられている場合には、フローは２０６０までスキップし、ヒストグラムおよびインデックスを使用して（ＳＫＩＰ，ＴＯＰ）ウィンドウを計算する。インデックスがキャッシュに入れられていない場合には、２０１０で、（ＤａｔａＩＤ，Ｌｉｎｅ＃，Ｃｌｉｎｅ＃ｓ）を含むライトデータキャッシュを参照する。２０２０で、ＤａｔａＩＤを（Ｌｉｎｅ＃，Ｃｌｉｎｅ＃ｓ）と照合する。２０３０で、別個のＤａｔａＩＤを並べ替える。２０４０で、インデックス（ｌｉｎｅ＃，累積和）を計算する。２０５０で、インデックスをキャッシュすることができ、フローはやはり２０６０へ進み、ヒストグラムおよびインデックスを使用して（ＳＫＩＰ，ＴＯＰ）ウィンドウを計算する。最後に、２０７０で、行セット結果を出力する。

行セット出力モジュール（Ｏｕｔｐｕｔ Ｒｏｗｓｅｔ Ｍｏｄｕｌｅ）に関して、一実施形態では、指定されたｌｉｎｅ＃−ｓの選択された（潜在的には複数の）チャンクに基づいて、ＸＭＱｕｅｒｙＲｏｗｓｅｔが生成され、行セットは、クライアント要求結果の一部としてサーバに返される。

フィルタリングされた結果に関するヒストグラムおよびインデックスをキャッシュに入れることに関して、「並べ替えられた統計量」は、どの物理行が、（所与のフィルタおよび並べ替え順に対して）見られるデータの１つ（または任意の）ウィンドウに対応するのかを記述する。したがって、現在の要求を満たし、（計算するコストが小さいため場合には）このインデックスを破棄し、またはこのインデックスをキャッシュに入れ、後に、例えばユーザが、スクロールダウンし、並べ替え順をＡＳＣからＤＥＳＣに切り換え、新たなデータ列を追加し、新たなＡＮＤまたはＯＲ節を追加するときなどに、再使用することができる。

キャッシングは任意だが、キャッシングは、同じ結果を再計算することを省き、特に同じクエリに関するスクローリング時に性能を向上させることができる。例えば、（ｌｉｎｅ＃，累積和）レコードを保持したフィルタリングされたデータに関するインデックスを節約することができる場合には、２回のクエリカーネル内部要求が回避される。

さらに、キャッシングは、ユーザを含むシナリオにおいて、既存のＷＨＥＲＥに、より制限的な（ＡＮＤ）節を追加するのに役立つ。このシナリオでは、（ｌｉｎｅ＃，累積和）スーパーセットを含むキャッシュに入れられた（不完全）マッチングインデックスを取り出すことができ、クエリカーネルに、（列ストレージ中に配置された）このデータから来るｌｉｎｅ＃ｓをフィードすることができ、追加のＷＨＥＲＥ節だけが渡される（より高速なクエリカーネル評価）。

キャッシュに入れられた（ｌｉｎｅ＃，累積和）インデックスは、実際のＤａｔａＩＤを保存する必要はなく（すなわちいかなる種類の粒度（ｇｒａｎｕｌａｒｉｔｙ）が指定されず）、したがって、選択において他の列を含むが、同じＷＨＥＲＥ節を有するクエリに対する一切の追加のコストなしで、それらを再使用することができる。

正確なキャッシュヒット（ｃａｃｈｅ ｈｉｔ）が得られた後、キャッシュに入れられたｌｉｎｅ＃−ｓおよび行数からデータのウィンドウを構成することによって、例えば累積和に対してデルタ（ｄｅｌｔａ）を計算することによって、ＸＭＱｕｅｒｙＲｏｗｓｅｔを生成することができる）。さまざまなキャッシングポリシーを使用することができ、これには例えば、ＵＩシナリオに対する使用パターンについての専用の知識を使用して、キャッシュ内における生存期間を決定すること、スケジューラ（ｓｃｈｅｄｕｌｅｒ）からの統計量およびテンプ（ｔｅｍｐ）構造のメモリコストからの統計量を使用して、インデックスの値を決定すること、立ち退き（ｅｖｉｃｔｉｏｎ）中のインデックスのコスト値ｆ（ＣＰＵコスト／メモリ使用）を使用して、キャッシュ内における生存期間を決定すること、インデックスのコスト値ｆ（ＣＰＵコスト／メモリ使用）を使用して、項目をキャッシュに入れるか否かを判定することなどが含まれる。

このように、一般的な方法を説明した。これを図２１に示す。２１１０で、ローカルウィンドウに適用するデータのサブセットを取り出すため、データに関するフィルタ演算および／または並べ替え演算を巻き込むアプリケーションからクエリを受け取る。２１２０で、そのクエリの指定された任意のＷＨＥＲＥ節および／またはＯＲＤＥＲ ＢＹ列に対する行の分布についての統計量を計算する。２１３０で、これらの統計量に基づき、ローカルウィンドウとマッチする、１つのフィルタ演算および／または並べ替え演算に対する結果セットを決定する。２１４０で、結果セットをアプリケーションに送信する。

図２２は、要求しているクライアントの視点から見た流れを示す。この点に関しては、２２１０で、ローカルウィンドウに適用するデータのサブセットを取り出すため、データに関するフィルタ演算および／または並べ替え演算を巻き込むアプリケーションからクエリを送信する。２２２０で、前述の統計ベースの分析に基づいて結果セットを返す。２２３０で、結果を得る際に使用した１つまたは複数の結果または中間構造をキャッシュに入れることができる。

（列ベースデータエンコードに関する補足的コンテキスト）
概要の項で述べたとおり、さまざまな実施形態において、列指向エンコードおよび圧縮を大量のデータに適用して、データをコンパクト化し、同時に、データに関する後のスキャン／検索／クエリ操作を実質的により効率的にするためにデータを編成することができる。さまざまな実施形態では、ウィンドウイングされたデータに関する統計量を決定し、要求されたウィンドウに関連する結果の計算中にそれらの統計量をレバレッジすることによって、複雑なフィルタ演算および／または並べ替え演算を巻き込む大量のデータに関するクエリのケースに、効率的な演算を適用することができる。

例示的で非限定的な実施形態では、生データを、列ごとに１つの値シーケンスを有する一組の値シーケンスに列化（ｃｏｌｕｍｎｉｚｅ）した後に（例えばデータ列のフィールドを直列化（ｓｅｒｉａｌｉｚｅ）した後に、例えば、全ての姓を１つのシーケンスとして直列化し、または全てのＰＯ Ｏｒｄｅｒ＃ｓを別のシーケンスとして直列化するなどした後に）、データを「整数化（ｉｎｔｅｇｅｒｉｚｅ）」して、辞書エンコードもしくは値エンコードに従って、または辞書エンコードと値エンコードの両方に任意の順序で従って一様に表された整数シーケンスを、列ごとに形成する。この整数化ステージは、一様に表された列ベクトルを与え、特にテキストストリングなどの長いフィールドがデータに記録される場合に、単独でかなりの節約を達成することができる。次に、全ての列を調べて、圧縮ステージが、任意の列のランに、列ベクトルセット全体の全体サイズ節約量が最も大きくなるランレングスエンコードを繰り返し適用する。

前述のとおり、このパッキング技法は列ベースであり、優れた圧縮を提供するだけでなく、圧縮技法自体が、コンパクト化された整数列ベクトルがクライアント側に送達された後に、データを高速に処理するのに役立つ。

非限定的なさまざまな実施形態では、図２３に示すように、大規模データストレージ２３００をコンパクト化し、さらに、データに関する結果として生じるスキャン／検索／クエリ操作を実質的により効率的にする、列ベースエンコーダ／コンプレッサ（ｃｏｍｐｒｅｓｓｏｒ）２３１０が提供される。データ処理ゾーンＣのデータ消費装置２３２０によるクエリに応答して、コンプレッサ２３１０は、このクエリに関連する圧縮された列を、データ伝送ゾーンＢの伝送網（１つまたは複数）２３１５を介して送信する。このデータはインメモリストレージ（ｉｎ ｍｅｍｏｒｙ ｓｔｏｒａｇｅ）２３３０に送達され、したがって、データ処理ゾーンＣのデコーダおよびクエリプロセッサ２３４０によって、関連する列の圧縮解除を非常に高速に実行することができる。この点に関して言えば、クエリに関連する圧縮解除された列によって表される行に、効率的な処理の追加の層のため、バケットウォーキング（ｂｕｃｋｅｔ ｗａｌｋｉｎｇ）が適用される。繰返しの操作が一緒に実行されるように、バケットウォーキング中には行の類似性が利用される。後により詳細に説明するが、大量のウェブトラフィックデータまたはトランザクションデータなどの実世界サンプルデータにこの技法を適用すると、１９６Ｇｂ ＲＡＭを有する標準または商品サーバでは、サーバデータのクエリ／スキャンが、従来システムの能力を天文学的に超える毎秒約１．５テラバイトデータの速度、および大幅に低減したハードウェアコストで達成される。

圧縮することができるデータのタイプは特定のデータタイプに一切限定されず、莫大な量のデータの大規模スキャンに依存するシナリオも同様に無数にあり、リアルタイムビジネスインテリジェンス用途におけるビジネスデータまたはビジネスレコードにこれらの技法を適用する商業上の重要性は疑いえない。この圧縮技法によって達成されるクエリ処理速度のとてつもない向上により、リアルタイムリポーティングおよびトレンド識別は全く新しいレベルに移行する。

エンコーダの一実施形態の全体を図２４に示す。この実施形態では、２４００で、生データを受け取り、またはストレージから読み込み、この時点で、エンコード装置および／またはエンコードソフトウェア２４５０が、２４１０で、データを列として編成する。２４２０で、列ストリームを、一様なベクトル表現に変換する。例えば、整数エンコードを適用して、名前または場所のような個々のエントリを整数にマップすることができる。このような整数エンコード技法は、２×〜１０×の因子でデータを減らすことができる辞書エンコード技法とすることができる。これに加えて、またはこれの代わりに、値エンコードはさらに、１×〜２×のサイズ低減を提供することができる。これは、２４２０で、列ごとに整数のベクトルを残す。このような性能の向上は、コンパクト化されているデータの影響を受けやすく、したがって、このようなサイズ低減の範囲は、単に非限定的な推定値として与えられ、異なるステップの相対性能についてのおおまかな見当を与える。

次いで、２４３０で、エンコードされた一様な列ベクトルをさらにコンパクト化することができる。一実施形態では、全ての列を横切って最も頻度の高い値または値の発生を決定するランレングスエンコード技法を適用し、その場合には、その値に対してランレングスが定義され、このプロセスは、例えばその列内で少なくとも６４回の発生を有する繰り返し発生する整数値に対して、ランレングスエンコードの利益がかろうじて得られる点まで繰り返される。

他の実施形態では、この繰返しプロセスのそれぞれのステップで、ランレングスエンコードを適用することによるビット節約を調べ、再順序付けおよびランレングスの定義の適用によって、それらの列の中で最大のビット節約を達成する列を選択する。言い換えると、目標は、できるだけ少ないビットで列を表すことであるため、それぞれのステップで、最も大きな節減を提供する列のビット節約を最大にする。この点に関して言えば、ランレングスエンコードは、かなりの、例えば単独で１００×以上の圧縮の向上を提供することができる。

他の実施形態では、２４３０で、ビットパッキングとランレングスエンコードの組合せを使用するハイブリッド圧縮技法を適用する。これらの２つの技法の潜在的な節約を調べる圧縮分析を適用し、例えばランレングスエンコードが与える正味のビット節約が不十分であるとみなされる場合には、列ベクトルの残りの値にビットパッキングを適用する。したがって、１つまたは複数の基準に従って、ランレングスによる節約が最低限であると判定されると、列の残りの比較的に珍しい値に対して、アルゴリズムはビットパッキングに切り替わる。例えば、列中に表された値が比較的に珍しい値になった場合（珍しくないまたは繰り返し出現する値が既にランレングスエンコードされた場合）には、ランレングスエンコードの代わりに、ビットパッキングをそれらの値に対して適用することができる。２４４０で、出力は、前述の技法に従ってエンコードされ、圧縮された、列値に対応する一組の圧縮された列シーケンスである。

一実施形態では、消費クライアントシステム上のメモリに、前述の技法に従って圧縮された列がロードされると、それぞれの列Ｃ１、Ｃ２、Ｃ３、Ｃ４、Ｃ５、Ｃ６を横切ってそのデータをセグメント化して、図２５に示すようなセグメント２５００、２５０２、２５０４、２５０６などを形成する。この点に関して言えば、それぞれのセグメントは数億以上の行を含むことがあるため、並列化は、例えばクエリに従ってデータを処理しまたはスキャンする速度を向上させる。それぞれのセグメントを別々に処理している間に、それぞれのセグメントの結果を集計して、結果の完全セットを形成する。

図２６は、上記の方法の全体を、生データ２６００の入力から始まる流れ図に従って説明する。２６１０で、前述のとおり、生データ２６００の列に従って、データを再編成する。これは、従来のシステムのようにレコードのそれぞれのフィールドを一緒に維持するとは対照的である。例えば、図２７に示すように、それぞれの列が、シーケンスＣ２７０１、Ｃ２７０２、Ｃ２７０３、Ｃ２７０４、Ｃ２７０５、Ｃ２７０６などの独立したシーケンスを形成する。例えば、このデータが小売取引データである場合には、列Ｃ２７０１が製品価格のストリングであり、列Ｃ２７０２が購入日のストリングを表し、列Ｃ２７０３が保管位置を表し、．．．ということがありうる。この列ベース編成は、コンピュータシステムによって集められる大部分の実世界データは、表される値に関してそれほど多様ではないことを考慮して、データ型内において固有の類似性を維持する。２６２０で、この列ベースデータを１回または数回の変換にかけて、一様に表された列ベースデータシーケンスを形成する。一実施形態では、ステップ２６２０が、それぞれの列を、辞書エンコードおよび／または値エンコードによって、データの整数シーケンスに低減させる。

２６３０で、ランレングスエンコードプロセスおよび任意選択のビットパッキングを用いて、この列ベースシーケンスを圧縮する。一実施形態では、ランレングスエンコードプロセスが、全ての列のうち、最も大きな圧縮節約を達成する列の列データ値シーケンスを再順序付けする。したがって、ランレングスエンコードが最も大きな節約を達成する列を再順序付けして、ランレングスエンコードによって置き換えられている共通の値をグループ化し、次いで、再順序付けされたグループに対してランレングスを定義する。一実施形態では、ランレングスエンコードアルゴリズムを、それらの列を横切って繰り返し適用して、ステップごとにそれぞれの列を調べ、最も大きな圧縮節約を達成する列を決定する。

ビット節約が不十分である、または節約がしきい値よりも小さいなど、１つまたは複数の基準に従って、ランレングスエンコードを適用する利益がかろうじて得られ、または最低限になると、それを適用する利益は対応して小さくなっていく。その結果として、アルゴリズムを停止することができ、または、それぞれの列内のランレングスエンコードによってエンコードされていない残り値に対してビットパッキングを適用して、それらの値に対するストレージ必要量をさらに低減させることができる。組合せにおいて、ハイブリッドランレングスエンコードとビットパッキング技法は、列シーケンス、特に有限のまたは限られた数の値がその中に表されている列シーケンスを低減させるのに、非常に効果的であることがある。

例えば、フィールド「性別」は、２つのフィールド値：男と女だけを有する。ランレングスエンコードを用いると、データが、前述のように生データの列ベース表現に従ってエンコードされている限りにおいて、このようなフィールドを非常に単純に表すことができる。これは、背景の項で説明した行に焦点を合わせた従来の技法が、事実上、それぞれのレコードのフィールドを一緒に保持することによって、列データの共通性をバラバラにするためである。「２１」などの年齢値のとなりの「男」値は圧縮されず、「男」または「女」値だけのとなりの「男」値も圧縮されない。このように、データの列ベース編成は、効率的な圧縮を可能とし、プロセスの結果は、一様に表され、コンパクト化された一組の別個の列ベースデータシーケンス２６４０である。

図２８は、実際のデータに基づく列化プロセスの一例を示す。図２８の例は、４つのデータレコード２８００、２８０１、２８０２および２８０３に対するものだが、本発明は、数テラバイトのデータに適用することができるため、これは説明を単純にするためである。一般的に言って、コンピュータシステムによってトランザクションデータが記録されるとき、そのデータは、一般にレコードを受け取った時間順に、１レコードずつ記録される。したがって、そのデータは、事実上、それぞれのレコードに対応する行を有する。

図２８では、レコード２８００が、値「Ｊｏｎ」２８１１を有する名前フィールド２８１０、値「５５５−１２１２」２８２１を有する電話番号フィールド２８２０、値「ｊｏｎ＠ｇｏ」２８３１を有するｅメールフィールド２８３０、値「２１^st Ｓｔ」２８４１を有する住所フィールド２８４０、および値「Ｗａｓｈ」２８５１を有する州フィールド２８５０を有する。

レコード２８０１は、値「Ａｍｙ」２８１２を有する名前フィールド２８１０、値「１２３−４５６７」２８２２を有する電話番号フィールド２８２０、値「Ａｍｙ＠ｗｏ」２８３２を有するｅメールフィールド２８３０、値「１２^nd Ｐｌ」２８４２を有する住所フィールド２８４０、および値「Ｍｏｎｔ」２８５２を有する州フィールド２８５０を有する。

レコード２８０２は、値「Ｊｉｍｍｙ」２８１３を有する名前フィールド２８１０、値「７６５−４３２１」２８２３を有する電話番号フィールド２８２０、値「Ｊｉｍ＠ｓｏ」２８３３を有するｅメールフィールド２８３０、値「９ Ｆｌｙ Ｒｄ」２８４３を有する住所フィールド２８４０、および値「Ｏｒｅｇ」２８５３を有する州フィールド２８５０を有する。

レコード２８０３は、値「Ｋｉｍ」２８１４を有する名前フィールド２８１０、値「９８７−６５４３」２８２４を有する電話番号フィールド２８２０、値「Ｋｉｍ＠ｔｏ」２８３４を有するｅメールフィールド２８３０、値「９１ Ｙ Ｓｔ」２８４４を有する住所フィールド２８４０、および値「Ｍｉｓｓ」２８５４を有する州フィールド２８５０を有する。

行表現２８６０が、再編成された列表現２８７０に列化されると、それぞれが５つのフィールドを有する４つのレコードを有する代わりに、それらのフィールドに対応する５つの列が形成される。

したがって、列１は、名前フィールド２８１０に対応し、値「Ｊｏｎ」２８１１、値「Ａｍｙ」２８１２、値「Ｊｉｍｍｙ」２８１３および値「Ｋｉｍ」２８１４をこの順に有する。同様に、列２は、電話番号フィールド２８２０に対応し、値「５５５−１２１２」２８２１、値「１２３−４５６７」２８２２、値「７６５−４３２１」２８２３および値「９８７−６５４３」２８２４をこの順に有する。列３は、ｅメールフィールド２８３０に対応し、値「ｊｏｎ＠ｇｏ」２８３１、値「Ａｍｙ＠ｗｏ」２８３２、値「Ｊｉｍ＠ｓｏ」２８３３および値「Ｋｉｍ＠ｔｏ」２８３４をこの順に有する。次に、列４は、住所フィールド２８４０に対応し、値「２１^st Ｓｔ」２８４１、値「１２^nd Ｐｌ」２８４２、値「９ Ｆｌｙ Ｒｄ」２８４３および値「９１ Ｙ Ｓｔ」２８４４をこの順に有する。そして列５は、州フィールド２８５０に対応し、値「Ｗａｓｈ」２８５１、値「Ｍｏｎｔ」２８５２、値「Ｏｒｅｇ」２８５３および値「Ｍｉｓｓ」２８５４をこの順に有する。

図２９は、本明細書に記載された実施形態によって使用される辞書エンコードの非限定的な一例を示すブロック図である。都市の一般的な列２９００は、値「Ｓｅａｔｔｌｅ」、「Ｌｏｓ Ａｎｇｅｌｅｓ」、「Ｒｅｄｍｏｎｄ」などを含むことができ、このような値は、何度も繰り返されることがある。辞書エンコードでは、エンコードされた列２９１０が、値ごとの固有の整数など、それぞれの別個の値に対する記号を含む。したがって、テキスト「Ｓｅａｔｔｌｅ」を何度も表現する代わりに、はるかにコンパクトな整数「１」が保存される。よりしばしば繰り返される値は、最もコンパクトな表現（最小ビット、ビット中の最小変化など）へのマッピングを用いて列挙することができる。値「Ｓｅａｔｔｌｅ」は、辞書２９２０の一部としてエンコード中に依然として含まれるが、「Ｓｅａｔｔｌｅ」は、何回も表現するのではなしに、１度だけ表現すればよい。エンコードされた列２９１０のストレージ節約は、辞書２９２０によって巻き込まれる追加のストレージをはるかに上回る。

図３０は、本明細書に記載された実施形態によって使用される値エンコードの非限定的な一例を示すブロック図である。列３０００は、販売量を表し、フロートストレージを巻き込む、小数を含む一般的なドルおよびセント表現を含む。ストレージをよりコンパクトにするため、値を、フロート値ではなく、より少ないビットで保存できる整数で表すために、値エンコードでエンコードされた列３０１０は、１０の因子、例えば１０²が適用された値を有することができる。同様に、変換を適用して、値を表す整数の数を減らすこともできる。例えば、２，０００，０００、１８５，０００，０００など、ある列に対して一貫して１００万で終わる値を全て１０⁶で割って、それらの値を、よりコンパクトな２、１８５などの表現にすることができる。

図３１は、本明細書に記載された実施形態によって使用されるビットパッキングの非限定的な一例を示すブロック図である。列３１００は、辞書エンコードおよび／または値エンコードによって整数化された発注量を表すが、それらの値を表すために、１行あたり３２ビットが確保されている。ビットパッキングは、セグメント内の値に対してできるだけ少数のビットを使用するように努める。この例では、値５９０、１１０、６８０および３２０を表すために１０ビット／行を使用することができ、これは、列３１１０を形成するためにビットパッキングを適用した最初の層に比べて相当な節約である。

ビットパッキングはさらに、共通の１０（または他の数）のべき乗を除去して、パックされた第２の列３１２０を形成することができる。したがって、この例のように値が０で終わる場合、それは、発注量を表すために使用している３ビット／行が必要なく、ストレージ構造が７ビット／行に低減されることを意味する。辞書エンコードと同様に、このビット節約は、使用した１０のべき乗が何であるかなど、データを列３１００に復元するために必要なメタデータによって増大するストレージを大きく上回る。

パックされた第３の列３１３０を形成するためのビットパッキングの他の層として、６８のような値を表すために７ビット／行が必要であることは認識することができるが、最も小さな値は１１であるため、範囲を１１だけずらす（それぞれの値から１１を差し引く）ことができ、そうすると最も大きな数は６８−１１＝５７になり、２⁶＝６４の値が可能なため、５７は、６ビット／行で表すことができる。図３１は、パッキング層の特定の順序を示しているが、これらの層を異なる順序で実行することができ、あるいは、これらのパッキング層を選択的に除去し、またはこれらのパッキング層に、知られている他のビットパッキング技法を追加することもできる。

図３２は、本明細書に記載された実施形態によって使用されるランレングスエンコードの非限定的な一例を示すブロック図である。示されているように、値が繰り返されているため、注文のタイプを示す列３２００などの列を、ランレングスエンコードを用いて効果的にエンコードすることができる。列値ランテーブル３２１０は、注文のタイプを、その注文のタイプに対するランレングスにマップする。テーブル３２１０のメタデータの表現の対するわずかな変異は許されるが、基本的認識は、ランレングスエンコードが、１００のランレングスに対して×５０の圧縮を与えることができるということであり、これは一般に、同じデータセットに対してビットパッキングが提供することができる利益よりも優れている。

図３３は、技法を合成して、エンコード／圧縮スキームのさまざまな実施形態に統合した、本明細書に記載された一実施形態の全体ブロック図である。生データ３３００を、列編成３３１０に従って列ストリームとして編成する。辞書エンコード３３２０および／または値エンコード３３３０が、前述のそれぞれのサイズ低減を提供する。次いで、ハイブリッドＲＬＥ／ビットパッキングステージで、圧縮分析３３４０が、列を横切る潜在的なビット節約を調べ、それによりランレングスエンコード３３５０を適用するのか、またはビットパッキング３３６０を適用するのかを判定する。

図３３を、図３４の流れ図に拡張する。３４００で、固有の行表現に基づく生データを受け取る。３４１０で、このデータを列として再編成する。３４２０で、辞書エンコードおよび／または値エンコードを適用して、データを初めて低減させる。３４３０で、前述のハイブリッドＲＬＥ／ビットパッキング技法を適用することができる。３４４０で、圧縮され、エンコードされた列ベースデータシーケンスを保存する。次いで、クライアントが、この圧縮され、エンコードされた列ベースデータシーケンスの全てまたはそのサブセットについて問い合わせたときに、３４５０で、関係する列を、要求しているクライアントに送信する。

図３５は、ハイブリッド圧縮技法の圧縮分析を実行する例示的な方法のブロック図である。例えば、列３５００から、値の発生頻度または個々のランレングスの発生頻度を表すヒストグラム３５１０を計算する。ランレングスの利益が最低限である可能性がある回数の少ない値の再発生に対しては、ランレングスエンコードが適用されないように、任意選択で、しきい値３５１２を設定することができる。あるいは、またはそれに加えて、ビット節約ヒストグラム３５２０は、値の発生頻度を表すだけでなく、ハイブリッド圧縮モデルの圧縮技法のうちのどちらか一方を適用することによって達成されるであろう全体ビット節約をも表す。さらに、ランレングスエンコード技法を適用するには、そうすることの利益があまり十分ではない線を引くために、任意選択で、しきい値３５２２を適用することができる。その代わりに、列のそれらの値に対してビットパッキングを適用することができる。

さらに、任意選択で、列３５００のランレングスエンコードを適用する前に、列３５００を再順序付けして、最も類似した値の全てを、再順序付けされた列３５３０としてグループ化することができる。この例では、これが、ランレングスエンコードのためにＡを一緒にグループ化し、ビットパッキングのためにＢを残すことを意味する。これは、頻度も、または全体ビット節約も、２つのＢ値に対してランレングスエンコードを適用することを正当化しないためである。この点に関して、これらの残りの列に再順序付けを適用して、レコードデータをロックステップ（ｌｏｃｋ ｓｔｅｐ）に維持することができ、または、ランレングスエンコードの再順序付けを取り消して元に戻す方法を、列固有のメタデータを介して記憶することができる。

図３６は類似の例を示し、この例では、類似列３６００に圧縮分析が適用されるが、ハイブリッド圧縮分析によると、２つのＢ値の正味のビット節約の方がより大きいため、１０個のＡ値の前であっても、２つのＢ値に対してランレングスエンコードを実行することが正当化されるように、ランレングスの置換えあたりのビット節約が変更されている。この点に関して、異なる料理が盛られた１０枚の異なる皿から選ぶ大食家（ｇｌｕｔｔｏｎ）によく似て、ランレングスエンコードの適用は、ステップごとに、全ての列を横切るサイズ低減の最も大きな利益を繰り返し追求する点で、「貪欲（ｇｒｅｅｄｙ）」である。図３５と同様に、前述のようにランレングスエンコードを適用するのか、またはビットパッキングを適用するのかについての判定を実施するため、頻度ヒストグラム３６１０および／またはビット節約ヒストグラム３６２０のデータ構造を構築することができる。さらに、ＲＬＥを実行するのか、またはビットパッキングを実行するのかを判断するときに、任意選択のしきい値３６１２および３６２２を使用することもできる。再順序付けされた列３６３０は、ランレングスエンコードが、より長いランレングスを定義し、したがってより大きなランレングス節約を達成するのに役立つことができる。

図３７は、全ての列を横切って、それぞれのステップで最も大きなビット節約がどこで達成されるのかを調べ、任意選択で、ランレングス節約を最大にするために、ランレングス節約を最大にするそれらの列を列３７３０、３７３２などとして再順序付けすることを含むことができる、ランレングスエンコードの「貪欲な」態様を示す。ある時点で、値が比較的に珍しい値になるため、ランレングス節約が比較的に小さくなることがあり、この時点で、ランレングスエンコードは停止される。

ハイブリッド実施形態では、残りの値の範囲にビットパッキングを適用する。これを図３８に示す。この点に関して、ハイブリッド圧縮技法を適用すると、再順序付けされた列３８００は、ＲＬＥ部分３８１０と、ビットパッキング部分３８２０とを含み、これらはそれぞれ一般に、繰り返し発生する値および比較的に珍しい値に対応する。同様に、再順序付けされた列３８０２も、ＲＬＥ部分３８１２とＢＰ部分３８２２とを含む。

図３９に示す一実施形態では、ハイブリッドアルゴリズムが、ビットパッキングによるビット節約およびランレングスエンコードによるビット節約を計算し３９００、次いで、３９１０で、ビットパッキングによるビット節約とランレングスによるビット節約とを比較し、または、３９２０で、ビットパッキングによるビット節約とランレングスによるビット節約とを調べて、どちらの圧縮技法がビット節約を最大にするのかを判定する。

前述のエンコード技法および圧縮技法の例示的な性能は、実世界データサンプル４００１、４００２、４００３、４００４、４００５、４００６、４００６、４００７および４００８に対して達成することができる約９×から９９．７×までの範囲のかなりの向上を示し、この向上はとりわけ、特定の大規模データサンプル内における値の相対的な繰返し量に依存する。

図４１は、本明細書のさまざまな実施形態で説明した列化、エンコードおよび圧縮プロセスの最終結果を示すブロック図である。この点に関して、列Ｃ１、Ｃ２、Ｃ３、．．．、ＣＮはそれぞれ、ランレングスエンコードが適用された繰り返された等質（ｈｏｍｏｇｅｎｅｏｕｓ）な値を有するエリアと、図中に「Ｏｔｈｅｒｓ」または「Ｏｔｈ」と標識された、列中の異質（ｈｅｔｅｒｏｇｅｎｅｏｕｓ）な値のグループを表す別のエリアとを含む。凡例に示されているように、ランレングスによって定義された繰り返された同一の値を有するエリアは純粋（ｐｕｒｅ）なエリア４１２０であり、変化に富む（ｖａｒｉｅｇａｔｅｄ）値を有するエリアは不純（ｉｍｐｕｒｅ）なエリア４１１０である。この点に関して、人の眼が列を「下方へたどる」と、本明細書で論じた圧縮技法の固有の利益として、そのデータに関する新たなビューが出現する。

全ての列を横切って、不純なエリア４１１０と純粋なエリア４１２０の間の最初の遷移点で、または純粋なエリア４１２０と不純なエリア４１１０の間の最初の遷移点で、バケットが、最初の行から遷移点の行までの行として定義される。この点に関して、バケット４１００は、列を下って、点線によって示された遷移点ごとに定義される。バケット４１００は遷移間の行によって定義される。

図４２は、特定の行を横切る純粋なエリアの数および不純なエリアの数に基づいてバケットに対して定義される名称を示す。純粋バケット４２００は、不純なエリアを持たないバケットである。シングル不純バケット４２１０は、そのバケットの行を横切って不純なエリアを１つ有するバケットである。ダブル不純バケット４２１０は、そのバケットの行を横切って不純なエリアを２つ有するバケットである。トリプル不純バケットは不純なエリアを３つ有するバケットであり、以下同様である。

したがって、例示的なデータロードプロセスの間に、データは、後の効率的なクエリに適した表現でエンコードされ、圧縮され、保存され、セグメント内のデータ分布を捜し、ビットパッキングよりも頻繁にＲＬＥ圧縮を使用することを試みる圧縮技法を使用することができる。この点に関して、ＲＬＥは、圧縮とクエリの両方に関して以下の利点を提供する：（Ａ）ＲＬＥは一般に、必要なストレージがビットパッキングよりもかなり少なくてすみ、（Ｂ）ＲＬＥは、Ｇｒｏｕｐ Ｂｙ、フィルタリングおよび／または集計などのクエリビルディングブロック演算を実行する間に、データ範囲を通して効果的に「早送りする（ｆａｓｔ ｆｏｒｗａｒｄ）」能力を含む。このような演算は、数学的に、列として編成されたデータに関する効率的な演算にすることができる。

非限定的なさまざまな実施形態では、１つの列セグメントを一度に並べ替えてから、その同じセグメント内の他の列を並べ替える代わりに、圧縮アルゴリズムが、データの行を、それらの分布に基づいてクラスタ化し、そのようなものとして、セグメント内のＲＬＥの使用を増大させる。本明細書で使用する場合、用語「バケット」は、行のクラスタを記述するために使用され、疑いを回避するため、明確に定義されたＯＬＡＰ（ｏｎｌｉｎｅ ａｎａｌｙｔｉｃａｌ ｐｒｏｃｅｓｓｉｎｇ）およびＲＤＢＭＳの概念である用語「パーティション（ｐａｒｔｉｔｉｏｎ）」とは異なると考えるべきである。

データ分布は歪んでおり、多量のデータでは一様分布はまれにしか存在しないと認識されるため、以上に論じた技法は有効である。圧縮用語において、算術符号化（Ａｒｉｔｈｍｅｔｉｃ Ｃｏｄｉｎｇ）は、全体としてより少ないビットを使用することを目的として、頻繁に使用される文字をより少ないビットを使用して表し、まれにしか使用されない文字をより多くのビットを使用して表すことによって、これをレバレッジする。

ビットパッキングでは、ランダムアクセスをより高速にするため、固定サイズのデータ表現を利用する。しかしながら、本明細書に記載した圧縮技法はさらに、より頻繁な値に対してより少ないビットを使用する方法を提供するＲＬＥを使用する能力を有する。例えば、原テーブル（説明を単純にするために１つの列「列１」を含む）が以下のようである場合、

圧縮後、列１は、以下のようになり、ランレングスエンコードを適用する第１の部分と、ビットパッキングを適用する第２の部分とに分割される。

上記のテーブルから分かるとおり、最も共通する値１００の発生はＲＬＥに縮約され、まれにしか現れない値は、これまでどおりビットパックされた固定幅のストレージに保存される。

この点に関して、データパッキングの前述の実施形態は、以下の２つの別個のフェーズを含む：（１）バケット化を決定するためのデータ分析、および（２）バケット化されたレイアウトに従うためのセグメントデータの再編成。次に、これらのフェーズをそれぞれ、例を挙げてより詳細に説明する。

バケット化を決定するためのデータ分析に関して、目標は、ＲＬＥを有するセグメント内のできるだけ多くのデータをカバーすることである。そのため、このプロセスは、「より厚い」列、すなわち、クエリの間により頻繁に使用される列ではなく、大きな基数を有する列に有利な方向へ歪む。使用ベースの最適化を適用することもできる。

別の単純な例を示すため、説明を容易にするために、以下の小さなテーブルを使用する。実際には、このようなテーブルを圧縮しても利益にならない傾向があるため、このような小さなテーブルは一般に、前述の圧縮の範囲には含まれない。さらに、このような小さなテーブルが一般に含まれないのは、圧縮が、エンコードを実行した後に実行され、一実施形態では、値自体ではなくＤａｔａＩＤｅｎｔｉｆｉｃａｔｉｏｎ（ＩＤ）とともに機能するためである。したがって、説明のため、さらに列「行番号」を追加する。

これらの列を横切って、セグメントデータ内の最大の空間を占める単一の値を見つけることによって、バケット化プロセスは始まる。図１８および１９に関して前に述べたとおり、これは、それぞれの列に対する例えば以下のような単純なヒストグラム統計量を使用して、実行することができる。

この値を選択した後、そのセグメント内の行を、この値の全ての発生がシーケンスとして起こるように論理的に再順序付けして、ＲＬＥランの長さを最大にする。

一実施形態では、同じ行に属する値が全て、それぞれの列セグメントの同じインデックスに存在する。例えば列１［３］と列２［３］はともに３番目の行に属する。このことが保証されると、アクセスごとにマッピングテーブルを使用する回り道のコストを招くことなく、同じ行の値への効率的なランダムアクセスが提供される。したがって、貪欲なＲＬＥアルゴリズムまたはハイブリッドＲＬＥ／ビットパッキングアルゴリズムを適用する本明細書に記載された実施形態では、１つの列内の値を再順序付けすると、これは、他の列セグメント内の値も同様に再順序付けされることを含意する。

上記の例では、この時点で、２つのバケット｛１，２，４，６，７｝および｛３，５｝が存在する。前述のとおり、本明細書で適用するＲＬＥは貪欲なアルゴリズムであり、このことは、このアルゴリズムが、大域的な最適を見つけることを望んでステージごとに局所的な最適を選択するメタヒューリスティック（ｍｅｔａｈｅｕｒｉｓｔｉｃ）な問題解決に従うことを意味する。最も大きなバケットを見つける最初のフェーズの後、次のフェーズは、次に大きなバケットを選択し、そのバケット内でこのプロセスを繰り返すことである。

それに応じて行を再編成したとき、その時点で、３つバケット｛２，７｝、｛１，４，６｝、｛３，５｝が存在する。最も大きなバケットは第２のバケットだが、そこに値の繰返しはない。第１のバケットは全ての列がＲＬＥランを有し、残りの値は固有である。そのため、列１においてこれ以上ＲＬＥ利得は得られないことが分かる。バケット｛３，５｝を考慮すると、ＲＬＥに変換することができる別の値１２３１がある。興味深いことに、１２３１は、直前のバケットにも出現し、そのバケットを再順序付けして、１２３１が一番下になり、次のバケットの最上位とマージする準備が整うようにすることができる。次のステップは以下のようになる。

上記の例では、この時点で４つのバケット｛２，７｝、｛６，４｝、｛１｝、｛３，５｝が存在する。このデータをこれ以上低減させることができないため、プロセスは、セグメントデータを再編成する次のフェーズに移る。

冒頭の例では、性能上の理由から行も再順序付けしたが、それぞれの列セグメント内のデータを再順序付けする操作からのバケットの決定は、純粋に統計量に基づくことができる。それぞれの列セグメント内のデータを再順序付けする操作は、使用可能なコアに基づき、ジョブスケジューラを使用して並列化することができる。

前述のとおり、前述の技法を小さなデータセットに対して使用することは実際的でない。顧客データセットに対して、前述の技法はしばしば何万ものステップを経ることがあり、これに時間がかかることがある。このアルゴリズムの貪欲な性質のため、大部分の空間節約は、最初の数ステップで達成される。数千のステップのうちの最初の２ステップで、節約される大部分の空間は既に節約されている。しかしながら、圧縮されたデータのスキャン側で観察されるとおり、たとえごく小さな圧縮利得であってもクエリ中に報酬を得るため、パックされた列内にＲＬＥが存在すると、クエリの間に性能がかなり向上する。

１つのセグメントは一度に処理されるため、複数のコアを使用して、データ源からセグメント内へデータを読み込むのにかかる時間と、直前のセグメントを圧縮するのにかかる時間とをオーバラップさせることができる。従来の技術では、リレーショナルデータベースから約１００，０００行／秒の速度で読み取ると、８Ｍ行のセグメントでは約８０秒かかり、これは、このような作業に対して使用可能なかなりの量の時間である。任意選択で、一実施形態では、次のセグメントに対するデータが使用可能になったら、直前のセグメントのパックも停止することができる。

（列ベースデータエンコードの処理）
前述のとおり、列ベースエンコードに対するさまざまな実施形態に従ってデータを編成する方法は、メモリ内の選択された数の列に対して処理を非常に高速に実行することができる場合に、データの消費側での効率的なスキャンに役立つ。前述のデータパッキング技法および圧縮技法は、行エンコード中に圧縮フェーズを更新し、スキャンは、このインテリジェントエンコードをレバレッジするクエリオプティマイザ（ｑｕｅｒｙ ｏｐｔｉｍｉｚｅｒ）およびプロセッサを含む。

このスキャンまたはクエリ機構を使用して、ビジネスインテリジェンス（ＢＩ）クエリに対する結果を効率的に返すことができ、このスキャンまたはクエリ機構は、前述のデータパッキング技法および圧縮技法によってクラスタ化されたレイアウトが生成されるように設計され、ＲＬＥの使用が増大するように最適化される。例えば、クエリ処理時、クエリに対して使用されるかなりの数の列が、ＲＬＥを使用して既に圧縮されていることが予想される。さらに、この高速スキャンプロセスは、列ストアを横切る行方向（ｒｏｗ−ｗｉｓｅ）クエリプロセッサの代わりに、列指向クエリエンジンを導入する。そのため、（ＲＬＥデータと対照をなす）ビットパックされたデータを含むバケットでさえ、データの局所性（ｌｏｃａｌｉｔｙ）による性能の向上は、かなりのものになりうる。

前述のデータパッキング技法および圧縮技法ならびに効率的なスキャンを導入することに加えて、非常に効率的な方法：クエリ内の「ＯＲ」スライスおよび関係が指定された複数のテーブル間の「Ｊｏｉｎ」で以下のことをサポートすることができる。

前述のとおり、スキャン機構は、セグメントが、あるセグメントを横切って延び、「純粋」ＲＬＥランまたは「不純」ＲＬＥランビットパックストレージ内に列値を含むバケットを含むことを前提としている。

一実施形態では、あるセグメントに対してスキャンが呼び出され、キーは、一度に１つのバケットを処理することである。バケット内で、スキャンプロセスは、クエリ仕様に応じて、列指向処理を複数のフェーズで実行する。最初のフェーズは、どの列エリアが純粋で、どのエリアが不純であるのかについての統計量を集めることである。次に、フィルタを処理し、続いてＧｒｏｕｐ ＢＹ演算を処理し、続いてプロキシ列を処理することができる。次に、別のフェーズとして、集計を処理することができる。

以前に述べたとおり、本明細書に記載されたスキャンに対する実施形態は、従来のシステムのような行指向クエリ処理ではなく、列指向クエリ処理を実現することに留意されたい。したがって、これらのそれぞれのフェーズ対して、実行される実際のコードを、（１）操作されている列が、ランレングスエンコードされているか否か、（２）ビットパッキングに対して使用される圧縮のタイプ、（３）結果は疎（ｓｐａｒｓｅ）なのか、または密（ｄｅｎｓｅ）なのかなどに対して特定的（ｓｐｅｃｉｆｉｃ）とすることができる。集計に関しては、（１）エンコードタイプ（ハッシュまたは値）、（２）集計関数（和／最小／最大値／カウント）など、追加の事項が考慮される。

したがって、スキャンプロセスは一般に、さまざまな標準クエリ／スキャン演算子４３００からのクエリ結果が全てのバケット行の関数である図４３の形態に従う。事実上、クエリ／スキャン演算子４３００は、フィルタ、Ｇｒｏｕｐ Ｂｙ、プロキシ列および集計が複数のフェーズで互いに別個に処理されるような態様で、数学的に分割することができる。

この点に関して言えば、処理ステップごとに、４３１０で、バケットの純粋さの違いに基づき、バケットウォーキングプロセスに従って演算子が処理される。その結果として、一般化されたコストのかかる全バケット行のスキャンの代わりに、本明細書に記載されたエンコードおよび圧縮アルゴリズムの働きによって、異なるバケットの特殊化（ｓｐｅｃｉａｌｉｚａｔｉｏｎ）が導入され、したがって、その結果は、純粋バケット、シングル不純バケット、ダブル不純バケットなどの処理を集計したものになる。

圧縮アーキテクチャのこの能力は、処理数学が単純な演算になるため、純粋バケット対して実行される処理が最も速く、次いでシングル不純バケットが速く、以降の不純バケットでは順に遅くなるため、図４４は、バケットのサンプル分布および圧縮アーキテクチャの能力を示す。さらに、意外に多くのバケットが純粋バケットであることも分かった。例えば、図４４に示すように、クエリによって巻き込まれる６つの列に関して、それぞれの列の純粋さが約９０％である場合（これは、データが似ていることにより、値の約９０％がランレングスエンコードで表されることを意味する）、バケットの約６０％は純粋バケット、約１／３はシングル不純バケット、約８％はダブル不純バケットであり、残りは１％にすぎない。純粋バケットの処理が最も高速であり、シングル不純バケットおよびダブル不純バケットの処理も依然としてかなり高速であるため、３つ以上の不純なエリアを有するバケットの「より複雑な」処理は最小限に留まる。

図４５は、サンプル「ｆｉｌｔｅｒ ｂｙ ｃｏｌｕｍｎ」クエリビルディングブロック４５０２、サンプル「Ｇｒｏｕｐ ｂｙ Ｃｏｌｕｍｎ」クエリビルディングブロック４５０４、サンプル「Ａｇｇｒｅｇａｔｅ ｂｙ Ｃｏｌｕｍｎ」クエリビルディングブロック４５０６などのいくつかのサンプル標準クエリビルディングブロックを有するサンプルクエリ４５００を示す。

図４６は、列選択性による追加の帯域幅低減態様を示すブロック図である。サンプルクエリ４６００を見ると、全ての列４６２０のうちわずか６つの列４６１０だけが巻き込まれ、したがって、クエリを非常に効率的にするためには、６つの列だけをローカルＲＡＭにロードすればよいことが分かる。

このように、本明細書ではさまざまな実施形態を説明した。図４７は、データをエンコードする一実施形態を示し、この実施形態は、４７００で、データの異なるデータフィールドに対応する値の一組の列ベースシーケンスに従ってデータを編成することを含む。次いで、４７１０で、この値の一組の列ベースシーケンスを、辞書エンコードおよび／または値エンコードなどの少なくとも１つのエンコードアルゴリズムに従って、値の一組の列ベース整数シーケンスに変換する。次いで、４７２０で、この一組の列ベース整数シーケンスを、この一組の列ベース整数シーケンスを横切って適用される貪欲なランレングスエンコードアルゴリズム、またはビットバッキングアルゴリズム、あるいはランレングスエンコードとビットパッキングの組合せを含む少なくとも１つの圧縮アルゴリズムに従って圧縮する。

一実施形態では、この整数シーケンスを分析して、ランレングスエンコード（ＲＬＥ）圧縮を適用するのかまたはビットパッキング圧縮を適用するのかを判定する。これには、ＲＬＥ圧縮のビット節約をビットパッキング圧縮に対して分析して、最大ビット節約がどこで達成されるのかを判定することが含まれる。このプロセスは、最大ビット節約がどこで達成されるのかを判定する際に役立てるため、ヒストグラムを生成することを含むことができる。

他の実施形態では、図４８に示すように、ビットパッキング技法が、４８００で、値の整数シーケンスのうち、あるデータ列を表す部分を受け取ること、およびビットパッキングによる潜在的な低減の３つのステージを含む。４８１０で、データフィールドを表すために必要なビットの数に基づいて、データを低減することができる。４８２０で、整数シーケンスの前記部分の値を横切って共有するべき乗数値（ｎｕｍｅｒｉｃａｌ ｐｏｗｅｒ）を除去することによって、データを低減することができる。４８３０で、整数シーケンスのある範囲にまたがる部分の値をずらすことによって、データをさらに低減することができる。

図４９の流れ図に示す他の実施形態では、クエリに応答して、４９００で、データの異なる列に対応する値のエンコードされ圧縮された整数シーケンスとして、データのサブセットを取り出す。次いで、４９１０で、このデータサブセットの値のエンコードされ圧縮された整数シーケンスのいずれかで生じた圧縮タイプの変更に基づいて、このデータサブセットにまたがる処理バケットを定義する。次に、４９２０で、クエリ処理を効率的にするため、処理されている現在のバケットのタイプに基づいてクエリ操作を実行する。これらの操作はメモリ内で実行することができ、マルチコアアーキテクチャで並列化することができる。

異なるバケットは、（１）シーケンスを横切るバケット内の値の異なる部分が全て、ランレングスエンコード圧縮に従って圧縮され、純粋バケットを定義するバケット、（２）１つを除く全ての部分がランレングスエンコードに従って圧縮され、シングル不純バケットを定義するバケット、または（３）２つを除く全ての部分がランレングスエンコードに従って圧縮され、ダブル不純バケットを定義するバケットを含む。

改良されたスキャンは、特に最も純粋なバケットに対して、さまざまな標準クエリおよびスキャン演算をはるかに効率的に実行することを可能にする。例えば、バケットウォーキング技法が適用され、バケットタイプに基づいて処理が実行されるとき、論理ＯＲクエリスライス演算、関係が指定された複数のテーブル間のクエリ結合演算、フィルタ演算、Ｇｒｏｕｐ Ｂｙ演算、プロキシ列演算または集計演算は全てより効率的に実行することができる。

（例示的なネットワーク環境および分散環境）
本明細書に記載した列ベースエンコードおよびクエリ処理のさまざまな実施形態は、コンピュータネットワークの一部として、または分散コンピューティング環境内で展開し、任意の種類のデータストアに接続することができる任意のコンピュータまたは他のクライアントないしサーバ装置とともに、実施することができることを当業者は理解することができる。この点に関して言えば、本明細書に記載したさまざまな実施形態は、任意の数のメモリまたはストレージユニットを有し、任意の数のアプリケーションおよびプロセスが任意の数のストレージユニットを横切って起こる任意のコンピュータシステムまたはコンピュータ環境において実施することができる。これには、限定はされないが、ネットワーク環境または分散コンピューティング環境内に展開され、リモートまたはローカルストレージを有するサーバコンピュータおよびクライアントコンピュータを含む環境が含まれる。

分散コンピューティングは、コンピューティング装置およびコンピューティングシステム間の通信交換によって、コンピュータ資源およびコンピュータサービスの共有を提供する。これらの資源およびサービスは、ファイルなどのオブジェクトに対する情報、キャッシュストレージおよびディスクストレージの交換を含む。これらの資源およびサービスはさらに、ロードバランシングのための複数の処理ユニットを横切る処理パワーの共有、資源の拡張、処理の特殊化などを含む。分散コンピューティングは、クライアントがその総体的なパワーをレバレッジすることを可能にするネットワーク接続性を利用して、その企て全体に利益を与える。この点に関して言えば、さまざまな装置が、本明細書の開示のさまざまな実施形態のうちの任意の実施形態の１つまたは複数の態様を実行するために協力することができるアプリケーション、オブジェクトまたは資源を有することができる。

図５０は、例示的なネットワークコンピューティング環境ないし分散コンピューティング環境の概略図である。この分散コンピューティング環境は、コンピューティングオブジェクト５０１０、５０１２など、およびコンピューティングオブジェクトまたは装置５０２０、５０２２、５０２４、５０２６、５０２８などを備え、これらは、アプリケーション５０３０、５０３２、５０３４、５０３６、５０３８によって表されたプログラム、方法、データストア、プログラマブルロジックなどを含むことができる。オブジェクト５０１０、５０１２など、およびコンピューティングオブジェクトまたは装置５０２０、５０２２、５０２４、５０２６、５０２８などは、ＰＤＡ、オーディオ／ビデオ装置、移動電話、ＭＰ３プレーヤー、パーソナルコンピュータ、ラップトップなどの異なる装置を備えることができることが理解される。

それぞれのオブジェクト５０１０、５０１２など、およびコンピューティングオブジェクトまたは装置５０２０、５０２２、５０２４、５０２６、５０２８などは、１つまたは複数の他のオブジェクト５０１０、５０１２など、および１つまたは複数の他のコンピューティングオブジェクトまたは装置５０２０、５０２２、５０２４、５０２６、５０２８などと、通信ネットワーク５０４０を介して、直接にまたは間接的に通信することができる。図５０では単一の要素として示されてはいるが、ネットワーク５０４０は、図５０のシステムにサービスを提供する他のコンピューティングオブジェクトおよびコンピューティング装置を含むことができ、かつ／または図示されていない相互接続された複数のネットワークを表すことができる。それぞれのオブジェクト５０１０、５０１２など、または５０２０、５０２２、５０２４、５０２６、５０２８などはさらに、本明細書の開示のさまざまな実施形態に従って提供された列ベースエンコードおよびクエリ処理と通信し、それらに対して処理を実施し、またはそれらを実現するのに適した、ＡＰＩを利用することがあるアプリケーション５０３０、５０３２、５０３４、５０３６、５０３８などのアプリケーション、または他のオブジェクト、ソフトウェア、ファームウェアおよび／ないしハードウェアを含むことができる。

分散コンピューティング環境をサポートするさまざまなシステム、コンポーネントおよびネットワーク構成が存在する。例えば、有線もしくは無線システムによって、ローカルネットワークによって、または広範囲に分散したネットワークによって、コンピューティングシステムを一体に接続することができる。現在、多くのネットワークが、広範囲に分散したコンピューティングに対するインフラストラクチャを提供し、多くの異なるネットワークを包含するインターネットに結合されているが、さまざまな実施形態で説明した列ベースエンコードおよびクエリ処理に付随して実施される例示的な通信に対しては、任意のネットワークインフラストラクチャを使用することができる。

したがって、クライアント／サーバ、ピアツーピア、ハイブリッドアーキテクチャなど、ネットワークトポロジおよびネットワークインフラストラクチャのホストを利用することができる。「クライアント」は、それが関係していない別のクラスまたはグループのサービスを使用するあるクラスまたはグループのメンバである。クライアントは、別のプログラムまたはプロセスによって提供されるサービスを要求するプロセス、すなわち概ね一組の命令またはタスクであることができる。このクライアントプロセスは、これらの別のプログラムまたはサービスに関する機能上の詳細を一切「知る」必要なしに、要求したサービスを利用する。

クライアント／サーバアーキテクチャ、特にネットワークシステムにおいて、クライアントは通常、別のコンピュータ、例えばサーバによって提供される共用ネットワーク資源にアクセスするコンピュータである。図５０の例では、非限定的な例として、コンピュータ５０２０、５０２２、５０２４、５０２６、５０２８などは、クライアントと考えることができ、コンピュータ５０１０、５０１２、などはサーバと考えることができ、サーバ５０１０、５０１２などは、クライアントコンピュータ５０２０、５０２２、５０２４、５０２６、５０２８などからデータを受け取り、データを保存し、データを処理し、クライアントコンピュータ５０２０、５０２２、５０２４、５０２６、５０２８などにデータを送信するなどのデータサービスを提供するが、状況に応じて、どのコンピュータも、クライアントまたはサーバ、またはその両方とみなすことができる。これらのコンピューティング装置はいずれも、本明細書において１つまたは複数の実施形態に関して説明した列ベースエンコードおよびクエリ処理を巻き込むことがある、データを処理し、データをエンコードし、データを問い合わせ、またはサービスもしくはタスクを要求する操作を実施することができる。

サーバは一般に、インターネット、無線ネットワークインフラストラクチャなどのリモートまたはローカルネットワークを介してアクセス可能なリモートコンピュータシステムである。第１のコンピュータシステムでクライアントプロセスがアクティブであり、第２のコンピュータシステムでサーバプロセスがアクティブであることがあり、これらは互いに通信媒体を介して通信し、したがって分散機能を提供し、複数のクライアントが、サーバの情報収集能力を利用することを可能にする。列ベースエンコードおよびクエリ処理に従って利用される、独立型の、または複数のコンピューティング装置もしくはオブジェクトを横切って分散した任意のソフトウェアオブジェクトを提供することができる。

通信ネットワーク／バス５０４０が例えばインターネットであるネットワーク環境では、サーバ５０１０、５０１２などをウェブサーバとすることができ、クライアント５０２０、５０２２、５０２４、５０２６、５０２８などは、それらのウェブサーバを利用して、ハイパーテキストトランスファプロトコル（ＨＴＴＰ）などの知られているいくつかのプロトコルのうちの任意のプロトコルを介して通信する。分散コンピューティング環境の特徴として、サーバ５０１０、５０１２などが、クライアント５０２０、５０２２、５０２４、５０２６、５０２８などの働きをすることもある。

（例示的なコンピューティング装置）
前述のとおり、有利には、本明細書に記載した技法を、大量のデータを迅速に問い合わせることが望ましい任意の装置に適用することができる。したがって、あらゆる種類のハンドヘルド、ポータブルおよび他のコンピューティング装置およびコンピューティングオブジェクトを、さまざまな実施形態とともに使用すること、すなわち、ある装置が、莫大な量のデータをスキャンし、または処理して、迅速かつ効率的に結果を得たいあらゆる場合に、さまざまな実施形態とともに使用することが企図される。したがって、図５１で後述する以下の汎用リモートコンピュータは、コンピューティング装置の唯一の例ではない。

必須ではないが、装置またはオブジェクトに対するサービスの開発者が使用するために、オペレーティングシステムを介して実施形態を部分的に実現することができ、かつ／または本明細書に記載されたさまざまな実施形態の１つないし複数の機能的態様を実行するように動作するアプリケーションソフトウェアに、実施形態を含めることができる。ソフトウェアは、クライアントワークステーション、サーバまたは他の装置などの１つまたは複数のコンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈で記述することができる。コンピュータシステムは、データを伝達するために使用することができるさまざまな構成およびプロトコルを有し、したがって、特定の構成またはプロトコルを、限定するためのものとみなすべきではないことを当業者は理解するであろう。

したがって、図５１は、本明細書に記載された実施形態の１つまたは複数の態様を実現することができる適当なコンピューティングシステム環境５１００の一例を示すが、上述のことから明らかなように、コンピューティングシステム環境５１００は、適当なコンピューティング環境の一例にすぎず、コンピューティングシステム環境５１００が、使用または機能の範囲に関して何らかの限定を提示することは意図されていない。さらに、コンピューティング環境５１００が、例示的な動作環境５１００中に示されたコンポーネントのうちの任意の１つのコンポーネントまたはコンポーネントの組合せに関係した何らかの依存関係または要件を有すると解釈すべきではない。

図５１に関して、１つまたは複数の実施形態を実現する例示的なリモート装置は、コンピュータ５１１０の形態の汎用コンピューティング装置を含む。限定はされないが、コンピュータ５１１０のコンポーネントには、処理ユニット５１２０、システムメモリ５１３０、およびシステムメモリを含むさまざまなシステムコンポーネントを処理ユニット５１２０に結合するシステムバス５１２２が含まれる。

コンピュータ５１１０は一般に、さまざまなコンピュータ可読媒体を含み、コンピュータ５１１０がアクセスすることができる使用可能な任意の媒体であることができる。システムメモリ５１３０は、リードオンリーメモリ（ＲＯＭ）および／またはランダムアクセスメモリ（ＲＡＭ）など、揮発性および／または不揮発性メモリの形態のコンピュータ記憶媒体を含むことができる。一例として、メモリ５１３０はさらに、限定はされないが、オペレーティングシステム、アプリケーションプログラム、他のプログラムモジュールおよびプログラムデータを含むことができる。

ユーザは、入力装置５１４０を介してコンピュータ５１１０にコマンドおよび情報を入力することができる。さらに、出力インタフェース５１５０などのインタフェースを介して、システムバス５１２２に、モニタまたは他のタイプの表示装置が接続される。モニタに加えて、コンピュータはさらに、出力インタフェース５１５０を介して接続することができるスピーカ、プリンタなどの他の周辺出力装置を含むことができる。

コンピュータ５１１０は、リモートコンピュータ５１７０などの１つまたは複数の他のリモートコンピュータへの論理結合を使用して、ネットワーク環境または分散環境で動作することができる。リモートコンピュータ５１７０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置もしくは他の一般的なネットワークノード、または他の任意のリモート媒体消費もしくは伝送装置とすることができ、コンピュータ５１１０に関して上で説明した要素のうちの任意の要素または全ての要素を含むことができる。図５１に示した論理接続は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）などのネットワーク５１７２を含むが、他のネットワーク／バスを含むこともできる。このようなネットワーク環境は、家庭、オフィス、企業規模のコンピュータネットワーク、イントラネットおよびインターネットにおいて珍しいものではない。

前述のとおり、さまざまなコンピューティング装置およびネットワークアーキテクチャに関する例示的な実施形態を説明したが、その根底をなす概念は、大規模データを圧縮し、または大規模データに関するクエリを処理することが望ましい任意のネットワークシステムおよび任意のコンピューティング装置またはコンピューティングシステムに適用することができる。

また、アプリケーションおよびサービスが効率的なエンコードおよびクエリ技法を使用することを可能にする同じ機能または類似の機能、例えば適当なＡＰＩ、ツールキット、ドライバコード、オペレーティングシステム、制御、独立型のまたはダウンロード可能なソフトウェアオブジェクトなどを実現する方法は複数ある。したがって、本明細書の実施形態は、ＡＰＩ（または他のソフトウェアオブジェクト）の見地から、ならびに列ベースエンコードおよび／またはクエリ処理を提供するソフトウェアまたはハードウェアオブジェクトから企図される。したがって、本明細書に記載されたさまざまな実施形態は、全体がハードウェアとして実現される態様、一部がハードウェア、一部がソフトウェアとして実現される態様、ならびに全体がソフトウェアとして実現される態様を有することができる。

本明細書では、語「例示的な」が、例、実例または例示を意味するために使用される。疑いを回避するため、本明細書に開示された主題はこのような例によって限定されない。さらに、本明細書において「例示的」と記述された態様または設計は、他の態様または設計よりも好ましいまたは有利であるとは必ずしも解釈されず、当業者に知られている例示的な等価の構造および技法を排除することを意味するものでもない。さらに、「発明を実施するための形態」または「特許請求の範囲」において用語「含む（ｉｎｃｌｕｄｅｓ）」、「有する（ｈａｓ）」、「含む（ｃｏｎｔａｉｎｓ）」および他の類似の語が使用される限りにおいて、疑いを回避するため、このような用語は、開いた遷移語（ｏｐｅｎ ｔｒａｎｓｉｔｉｏｎ ｗｏｒｄ）としての用語「含む（ｃｏｍｐｒｉｓｉｎｇ）」と同様に、包括的（ｉｎｃｌｕｓｉｖｅ）であり、追加の要素または他の要素を排除しないことが意図される。

前述のとおり、本明細書に記載したさまざまな技法は、ハードウェアもしくはソフトウェアとともに、または、適当な場合には、ハードウェアとソフトウェアの両方とともに実現することができる。本明細書で使用するとき、用語「コンポーネント」、「システム」なども同様に、ハードウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェアであるコンピュータに関係したエンティティ（ｅｎｔｉｔｙ）を指すことが意図されている。例えば、コンポーネントは、限定はされないが、プロセッサ上で実行中のプロセス、プロセッサ、オブジェクト、エグゼキュータブル（ｅｘｅｃｕｔａｂｌｅ）、実行のスレッド、プログラム、および／またはコンピュータであることができる。例示として、コンピュータ上で実行中のアプリケーションとそのコンピュータはともに、コンポーネントでありえる。プロセスおよび／または実行のスレッド内に、１つまたは複数のコンポーネントが存在することができ、コンポーネントは、１つのコンピュータ上に局限され、かつ／または２つ以上のコンピュータ間に分散することができる。

前述のシステムは、いくつかのコンポーネント間の対話に関して説明した。このようなシステムおよびコンポーネントは、それらのコンポーネントまたは指定されたサブコンポーネント、指定されたコンポーネントもしくはサブコンポーネントの一部、および／または追加のコンポーネント、ならびに上記のもののさまざまな置換および結合を含むことができることが理解できる。サブコンポーネントは、（階層的に）親コンポーネント内に含まれるのではなく、他のコンポーネントに通信可能に結合されたコンポーネントとして実現することもできる。さらに、１つもしくは複数のコンポーネントを結合して、集計機能を提供する単一のコンポーネントとし、または１つもしくは複数のコンポーネントを分割して、別個のいくつかのサブコンポーネントにすることができること、および統合化された機能を提供するために、管理層などの任意の１つまたは複数の中間層を、このようなサブコンポーネントに通信可能に結合するように提供することができることに留意すべきである。本明細書に記載されたコンポーネントはさらに、本明細書に具体的には記載されてはいないが、一般に当業者には知られている１つまたは複数の他のコンポーネントと対話することができる。

記載した主題に従って実現することができる方法は、以前に説明した例示的なシステムを考慮し、さまざまな図の流れ図を参照することによって、よりいっそう理解される。説明を単純にするため、これら方法を一連のブロックとして示し、説明したが、あるブロックは、本明細書に示され、記載された順序とは異なる順序で実行することができ、かつ／または他のブロックと同時に実行することができるため、請求の主題は、ブロックの順序によって限定されないことを理解すべきである。流れ図によって、一連でないフロー、すなわち枝分かれしたフローを示したが、同じ結果または類似の結果を達成する別のさまざまな枝、フロー経路およびブロックの順序を実現することができることが理解される。さらに、以下に記載する方法を実現するのに、示した全てのブロックが必要であるというわけでない。

本明細書に記載したさまざまな実施形態に加えて、他の類似の実施形態を使用することができること、または、記載した実施形態（１つもしくは複数）から逸脱することなく、それらの実施形態と同じ機能もしくは等価の機能を実行するために、対応する実施形態（１つもしくは複数）に変更および追加を実施されることができることを理解されたい。また、複数の処理チップまたは複数の装置が、本明細書に記載した１つまたは複数の機能の実行を分担することができ、同様に、ストレージは、複数の装置を横切って達成することができる。したがって、本発明は、単一の実施形態だけに限定されるものではなく、添付された特許請求の範囲に基づく幅、趣旨および範囲の中で解釈されるべきである。

Claims (20)

1. データ処理装置であって、
   データのウィンドウイングされたサブセットに関するクエリを、データストア内の値のターゲットウィンドウ内の分布に対して計算されたヒストグラムに基づいて処理する少なくとも１つのクエリプロセッサ２２０と、
   前記クエリに応答して、受け取った前記データのウィンドウイングされたサブセットを、前記データの異なる列に対応する値のエンコードされ、圧縮された整数シーケンスとしてエンコードするエンコーダ２１０と
   を備えることを特徴とする装置。
2. 統計量は動的に得られ、前記データを前記ターゲットウィンドウにウィンドウイングするため、ＷＨＥＲＥおよびＯＲＤＥＲ ＢＹに依存することを特徴とする請求項１に記載の装置。
3. 統計量は実データに対して構築され、合成データ値に対して、データは最初に、離散化プロセスに従って離散化されることを特徴とする請求項１に記載の装置。
4. 前記離散化された合成データは、結合された列の形態として処理されて、ＯＲＤＥＲ ＢＹ演算に加わることを特徴とする請求項３に記載の装置。
5. 最終ウィンドウは、ＯＲＤＥＲ ＢＹ演算によって巻き込まれる列の内容が分析された後の２次スキャンまで生成されないことを特徴とする請求項１に記載の装置。
6. 少なくともある離散化された合成列をシミュレートするため、予め計算された階層データが使用されることを特徴とする請求項１に記載の装置。
7. クエリ定義、統計量から決定される前記ターゲットウィンドウの内容または並列化の程度のうちの少なくとも１つに基づいて、データを離散化する離散化法および前記クエリに対するバッファリング戦略を選択するために、選択アルゴリズムが使用されることを特徴とする請求項１に記載の装置。
8. データのＷＨＥＲＥバケットおよびＯＲＤＥＲ ＢＹバケットの内容、ならびに統計量から決定される前記ターゲットウィンドウの内容に基づいて、射影法が選択されることを特徴とする請求項１に記載の装置。
9. 最終ウィンドウは、最大Ｎ個の予め構成されたバッファのうちの１つのバッファへの挿入だけを使用して並列に構築され、Ｎは、前記装置のプロセッサの数に対応することを特徴とする請求項１に記載の装置。
10. データをバッファする内部バッファは、クエリ仕様、選択された離散化法、ヒストグラムによって決定される最終ウィンドウ内のデータの分布、またはデータ処理に適用される並列化の程度のうちの少なくとも１つに基づくバッファサイズおよびそれらのポリシーに従って構成されることを特徴とする請求項１に記載の装置。
11. データ処理方法であって、
    ローカルウィンドウに適用するデータのサブセットを取り出すために、少なくとも１つのデータストア内のデータに関する少なくとも１つのフィルタ演算または並べ替え演算を巻き込むクエリを、アプリケーションから受け取るステップ２１１０と、
    前記クエリの指定された任意のＷＨＥＲＥ節またはＯＲＤＥＲ ＢＹ列のために、行の分布についての統計量を計算するステップ２１２０と、
    前記統計量に基づいて、前記ローカルウィンドウとマッチする、前記少なくとも１つのフィルタ演算または並べ替え演算に対する少なくとも１つの結果セットを決定するステップ２１３０と、
    前記少なくとも１つの結果セットを前記アプリケーションに送信するステップ２１４０と
    を含むことを特徴とする方法。
12. 少なくとも部分的に再使用するために、前記統計量をキャッシュに入れるステップ２２３０をさらに含むことを特徴とする請求項１１に記載の方法。
13. 前記決定するステップ２１３０は、前記クエリによって定義された前記演算を、複数のプロセッサおよび対応する数のデータセグメントを用いて並列化するステップを含み、前記セグメントはそれぞれ、少なくとも１つの異なるプロセッサによって処理されることを特徴とする請求項１１に記載の方法。
14. 請求項１１に記載の方法を実行するためのコンピュータ実行可能命令を含むことを特徴とするコンピュータ可読媒体。
15. クエリ処理方法であって、
    ローカルウィンドウに適用するデータのサブセットを取り出すために、少なくとも１つのデータストア内のデータに関する少なくとも１つのフィルタ演算または並べ替え演算を巻き込むクエリを、アプリケーションから送信するステップ２２１０と、
    前記クエリの指定された任意のＷＨＥＲＥ節またはＯＲＤＥＲ ＢＹ列のための行の分布についての統計量に基づいて、前記ローカルウィンドウとマッチする、前記少なくとも１つのフィルタ演算または並べ替え演算に対する少なくとも１つの結果セットを受け取るステップ２２２０と
    を含むことを特徴とする方法。
16. データを再使用するコストおよび可能性に関するポリシーに基づいて結果をキャッシュに入れるステップ２２３０をさらに含むことを特徴とする請求項１５に記載の方法。
17. 前記データを前記ローカルウィンドウにウィンドウイングするため、ＷＨＥＲＥおよびＯＲＤＥＲ ＢＹに依存する前記統計量を動的に決定するステップ２１２０をさらに含むことを特徴とする請求項１５に記載の方法。
18. 前記統計量を決定する前に、合成データ値を離散化して、離散化された合成データを形成するステップ７００をさらに含むことを特徴とする請求項１５に記載の方法。
19. 列結合の間に、前記離散化された合成データを使用して、ＯＲＤＥＲ ＢＹ演算に加わるステップをさらに含むことを特徴とする請求項１８に記載の方法。
20. ＯＲＤＥＲ ＢＹ演算によって巻き込まれた列の内容が分析されるまで、ターゲットウィンドウに対する最終ウィンドウを生成するのを待つことを特徴とする請求項１５に記載の方法。

Images