特許 6388655 選択性用データビットインターリーブによるリレーショナルデータベースのマルチカラムインデックスの生成

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6388655

(24)【登録日】2018年8月24日

(45)【発行日】2018年9月12日

(54)【発明の名称】選択性用データビットインターリーブによるリレーショナルデータベースのマルチカラムインデックスの生成

(51)【国際特許分類】

   G06F 17/30 20060101AFI20180903BHJP

   G06F 12/00 20060101ALI20180903BHJP

【ＦＩ】

   G06F17/30 414Z

   G06F17/30 180D

   G06F17/30 110C

   G06F12/00 505

   G06F12/00 520A

   G06F12/00 513J

【請求項の数】15

【全頁数】35

(21)【出願番号】特願2016-531804(P2016-531804)

(86)(22)【出願日】2014年7月29日

(65)【公表番号】特表2016-532199(P2016-532199A)

(43)【公表日】2016年10月13日

(86)【国際出願番号】US2014048531

(87)【国際公開番号】WO2015017361

(87)【国際公開日】20150205

【審査請求日】2016年1月27日

(31)【優先権主張番号】13/953,432

(32)【優先日】2013年7月29日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】507303550

【氏名又は名称】アマゾン・テクノロジーズ・インコーポレーテッド

(74)【代理人】

【識別番号】100098394

【弁理士】

【氏名又は名称】山川 茂樹

(74)【代理人】

【識別番号】100064621

【弁理士】

【氏名又は名称】山川 政樹

(72)【発明者】

【氏名】グプタ，アヌラグ，ウィンドラス

【審査官】 齊藤 貴孝

(56)【参考文献】

【文献】 米国特許出願公開第２０１１／０２１３７７５（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２０１１／０２４６４３２（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２０１０／０１８５６９２（ＵＳ，Ａ１）

【文献】 国際公開第２０１０／０６７８９７（ＷＯ，Ａ１）

【文献】 米国特許出願公開第２０１０／００８８３０９（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２０１３／００４６９４９（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２０１２／０３２３９２３（ＵＳ，Ａ１）

【文献】 米国特許第６６１８７２０（ＵＳ，Ｂ１）

【文献】 米国特許第６４２１６６２（ＵＳ，Ｂ１）

【文献】 鈴木 伸和、外２名，Ｐ２Ｐネットワーク上での類似度検索のためのデータ配置方法，情報処理学会研究報告，日本，社団法人情報処理学会，２００８年１１月２０日，第２００８巻，第１１７号，ｐ．５５−６０

【文献】 西村 祥治，ビッグデータ処理を支える先進技術，ＮＥＣ技報，日本，日本電気株式会社，２０１２年 ９月 １日，第６５巻，第２号，ｐ．６９−７２

【文献】 多田 典史、外６名，異業種の顧客を根こそぎ誘客するポイントプログラムシステム，月刊ソリューションＩＴ，日本，株式会社リックテレコム，２００６年 ８月 １日，第１８巻，第８号，ｐ．３４−４４

【文献】 梅田 弘之，新人ＳＥのためのＤＢ性能向上入門 第１回 インデックス編，日経オープンシステム 第９０号，日本，日経ＢＰ社，２０００年 ９月１５日，第90号，160〜167

【文献】 土田 真菜，構造と使いどころがパパっと分かる 今さら聞けない「インデックス」再入門，ＤＢ Ｍａｇａｚｉｎｅ，日本，株式会社翔泳社，２０１０年 ３月 １日，第１９巻，第１１号，ｐ．１０８−１１４

【文献】 小原 忍，ＳＱＬの書き方がレスポンスを決める ただし“常識”は不変ではない，日経オープンシステム，日本，日経ＢＰ社，２０００年 ６月１５日，第８７号，ｐ．２２０−２２７

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １７／３０

Ｇ０６Ｆ １２／００

(57)【特許請求の範囲】

【請求項1】

カラム型リレーショナルデータベーステーブルのストレージを提供する、複数のデータブロックを備える１以上のストレージデバイスと、
前記カラム型リレーショナルデータベーステーブルの複数のカラムのうち少なくとも２つのカラムを特定し、
選択性用データビットインターリーブに少なくとも一部基づいて、前記の特定された少なくとも２つのカラムから、前記カラム型リレーショナルデータベーステーブルのマルチカラムインデックスを生成し、当該マルチカラムインデックスは、前記カラム型リレーショナルデータベーステーブルの各エントリのそれぞれのインデックス値を提供する
ように構成されたマルチカラムキージェネレータと、
前記１以上のストレージデバイスに対し、各エントリのそれぞれのインデックス値に従ってソートされた前記カラム型リレーショナルデータベーステーブルの前記エントリを、前記複数のデータブロックのうちの１以上のデータブロックに記憶するように指示し、
前記１以上のストレージデバイスに対し、前記１以上のデータブロックごとに記憶された前記エントリの前記インデックス値に対応するマルチカラムインデックス値範囲を示すメタデータを記憶するように指示する
ように構成された書込モジュールと
を実行する複数の計算ノードを備える分散データウェアハウスシステム。

【請求項2】

選択性用データビットインターリーブに少なくとも一部基づいて、前記の特定された少なくとも２つのカラムから、前記カラム型リレーショナルデータベーステーブルの前記マルチカラムインデックスを生成するために、前記マルチカラムキージェネレータは、順序保存型圧縮法に従って前記の少なくとも２つのカラムのうちの１つ以上のカラムのデータを圧縮するように構成された、請求項１に記載のシステム。

【請求項3】

順序保存型圧縮法に従って前記の少なくとも２つのカラムのうちの前記１つ以上のカラムのデータを圧縮するために、前記マルチカラムキージェネレータはさらに、
前記１以上のカラムのうちの特定の１つのカラムに関するカラムデータ階層を、前記カラム型リレーショナルデータベーステーブルの１以上の他のカラムを基に決定し、
前記１以上のカラムのうちの前記の特定の１つのカラムのデータを前記カラムデータ階層に従ってグループ化するために、前記１以上のカラムのうちの前記の特定の１つのカラムに対し前記カラムデータ階層を適用する
ように構成された、請求項２に記載のシステム。

【請求項4】

読取モジュールと、
選択データに関して、前記の少なくとも２つのカラムのうちの１以上のカラムに対する、または前記カラム型リレーショナルデータベーステーブルの１以上のその他のカラムのうちの１以上のカラムに対するクエリの指示を受信し、
選択性用データビットインターリーブに少なくとも一部基づいて、前記の特定された少なくとも２つのカラムから、前記選択データを特定する１以上の述語データ値を決定するために、前記クエリの前記指示を評定し、
前記クエリの前記指示の受信及び評定に応じて、
前記選択データに関する前記クエリを処理する際、前記１以上のデータブロックのうち読取る必要のある特定ブロックを特定するために、前記１以上のデータブロックごとに、前記１以上の述語データ値に関して、前記マルチカラムインデックス値範囲を示す前記メタデータを分析し、
前記読取モジュールに対し、前記カラム型リレーショナルデータベーステーブルのデータを記憶する前記１以上のデータブロックのうちの前記特定ブロックを読取るように指示する
ように構成されたクエリエンジンと
をさらに備える請求項３に記載のシステム。

【請求項5】

１以上のコンピューティングデバイスにより、
リレーショナルデータベーステーブルの複数のカラムのうち少なくとも２つのカラムを特定し、
選択性用データビットインターリーブに少なくとも一部基づいて、前記の特定された少なくとも２つのカラムから、前記リレーショナルデータベーステーブルのマルチカラムインデックスを生成し、当該マルチカラムインデックスは前記リレーショナルデータベーステーブルの各エントリのそれぞれのインデックス値を提供し、
前記リレーショナルデータベーステーブルの前記エントリを各エントリのそれぞれのインデックス値に従って記憶する
ことを含む方法。

【請求項6】

前述の前記リレーショナルデータベーステーブルの前記マルチカラムインデックスを生成することは、前記の少なくとも２つのカラムのうちの１以上のカラムのデータを圧縮するために順序保存型圧縮法を適用することを含む、請求項５に記載の方法。

【請求項7】

前述の前記の少なくとも２つのカラムのうちの前記１以上のカラムのデータを圧縮するために順序保存型圧縮法を適用することは、カラムデータ階層に従って前記１以上のカラムのうちの特定の１つのカラムのデータをグループ化するために、前記１以上のカラムのうちの前記の特定の１つのカラムに対し、前記カラムデータ階層を適用することを含む、請求項６に記載の方法。

【請求項8】

前記リレーショナルデータベーステーブルの各エントリのそれぞれのインデックス値は分散キー値であり、前述の前記リレーショナルデータベーステーブルの前記エントリを各エントリのそれぞれのインデックス値に従って記憶することは、持続させる前記リレーショナルデータベーステーブルの前記エントリを、前記リレーショナルデータベーステーブルの前記エントリの前記分散キー値に少なくとも一部基づいて、複数の異なる永続的ストレージデバイスに分散的に配置することを含む、請求項５に記載の方法。

【請求項9】

前記リレーショナルデータベーステーブルの各エントリのそれぞれのインデックス値はソートキー値であり、前述の前記リレーショナルデータベーステーブルの前記エントリを各エントリのそれぞれのインデックス値に従って記憶することは、前記リレーショナルデータベーステーブルの前記エントリの前記ソートキー値に従ってソートされた前記リレーショナルデータベーステーブルの前記エントリを記憶することを含む、請求項５に記載の方法。

【請求項10】

前記リレーショナルデータベーステーブルに記憶させる１以上の追加エントリを受信し、
前記追加エントリに関して、前記選択性用データビットインターリーブに少なくとも一部基づいて、前記の特定された少なくとも２つのカラムから１以上のソートキー値を生成する
ことをさらに含む、請求項９に記載の方法。

【請求項11】

前記リレーショナルデータベーステーブルの前記エントリは複数のデータブロックに持続的に記憶され、前記方法は、前記１以上のデータブロックごとに記憶された前記エントリの前記ソートキー値に対応するマルチカラムソートキー値範囲を示すメタデータを保持することをさらに含む、請求項９に記載の方法。

【請求項12】

選択データに関して、前記リレーショナルデータベーステーブルの前記の少なくとも２つのカラムのうちの１以上のカラムに対するクエリの指示を受信し、
前記選択性用データビットインターリーブに少なくとも一部基づいて、前記の特定された２つのカラムから、前記選択データを特定する１以上の述語データ値を決定するために、前記クエリの前記指示を評定し、
前記クエリの前記指示の受信及び評定に応じて、
前記選択データに関する前記クエリを処理する際、前記複数のデータブロックのうち読取る必要のある特定ブロックを特定するために、前記１以上のデータブロックごとに、前記１以上の述語データ値に関して、前記マルチカラムソートキー値範囲を分析する
ことをさらに含む、請求項１１に記載の方法。

【請求項13】

前記１以上のコンピューティングデバイスが、分散データベースシステムにおける１以上のクライアントのデータを記憶するデータウェアハウスクラスタを実行するコンピューティングデバイスのより大きな集合の一部であり、前記１以上のコンピューティングデバイスは共に前記データウェアハウスクラスタの計算ノードを実行し、前述の前記リレーショナルデータベーステーブルの前記複数のカラムのうち前記の少なくとも２つのカラムを特定することは、クライアントが選んだカラムの指示を前記の少なくとも２つの特定されたカラムとして受信することを含む、請求項５に記載の方法。

【請求項14】

１以上のプロセッサと、１以上のメモリを備えるシステムであって、
前記メモリはプログラム命令を記憶しており、前記プログラム命令は１以上のコンピューティングデバイスにより実行されると、前記１以上のプロセッサにリレーショナルデータベースシステムを実行させ、前記リレーショナルデータベースシステムは、
リレーショナルデータベーステーブルの複数のカラムのうち少なくとも２つのカラムを特定し、
選択性用データビットインターリーブに少なくとも一部基づいて、前記の特定された少なくとも２つのカラムから、前記リレーショナルデータベーステーブルのマルチカラムインデックスを生成し、当該マルチカラムインデックスは前記リレーショナルデータベーステーブルの各エントリのそれぞれのインデックス値を提供し、
前記リレーショナルデータベーステーブルの前記エントリを各エントリのそれぞれのインデックス値に従って記憶することを指示する
前記システム。

【請求項15】

前述の前記リレーショナルデータベーステーブルの前記マルチカラムインデックスの生成において、前記プログラム命令は前記データベースシステムに、前記少なくとも２つのカラムのうちの１以上のカラムのデータを圧縮するために順序保存型圧縮スキームを適用することを実行させる、請求項１４に記載のシステム。

【発明の詳細な説明】

【背景技術】

【0001】

組織が情報を作成、追跡、保持するための技術力の継続的な発展に伴い、増加する情報を管理し記憶する様々な異なる技術が開発されてきた。例えば、データベースシステムはクライアントに、記憶された情報を管理するためのハードウェア及びソフトウェアの多数の異なる特殊構成またはカスタマイズされた構成を提供する。しかしながら、組織が記憶し管理しなければならないデータ量が増え続けることに応じて、多くの場合データベースシステム等のデータストレージ及び管理技術において増大化並びに複雑化の両方が進み、同様に情報維持費用が次第に上昇する。新しい技術においては、データストレージ及びデータ管理の効率性が改善されると同時に、データ維持の複雑さ及びストレージ要件の両方の軽減がますます試みられている。

【図面の簡単な説明】

【0002】

【図1】いくつかの実施形態による、選択性用データビットインターリーブによるリレーショナルデータベースシステムのマルチカラムインデックス化に関するデータフローブロック図を示す。

【図2】いくつかの実施形態による、例示的分散データベースウェアハウスサービスを示すブロック図である。

【図3】いくつかの実施形態による、例示的分散データウェアハウスクラスタを示すブロック図である。

【図4】いくつかの実施形態による、例示的計算ノードを示すブロック図である。

【図5】いくつかの実施形態による、選択性用データビットインターリーブに基づいたマルチカラムインデックスに従ってクエリの生成及び処理を実行する例示的データアクセスモジュールを示すブロック図である。

【図6】いくつかの実施形態による、例示的マルチカラムインデックスキージェネレータを示すブロック図である。

【図7】いくつかの実施形態による、選択性用データビットインターリーブに基づいてリレーショナルデータベーステーブルのマルチカラムインデックスを生成する方法を示す高次フローチャートである。

【図8】いくつかの実施形態による、選択性によるデータビットインターリーブに基づいたマルチカラムインデックスを有するリレーショナルデータベースに対するクエリを処理する方法の高次フローチャートを示す。

【図9】いくつかの実施形態による、修正された圧縮スキームに従って再圧縮されたカラムデータに基づいてリレーショナルデータベースのマルチカラムインデックスを再生成する方法の高次フローチャートを示す。

【図10】いくつかの実施形態による、本明細書に記載される様々な方法、技法、及びシステムを実施するように構成された例示的システムを示す。

【発明を実施するための形態】

【0003】

本明細書では、実施形態がいくつかの例示的実施形態及び説明図により説明されるが、実施形態は説明される実施形態または図面に限定されないことを当業者は認識するであろう。図面及びその詳細説明には、実施形態を開示される特定の形態に限定する意図はなく、それとは逆に、添付の請求項で定義される精神と範囲に入る全ての修正、均等物及び代替案を含める意図があることを理解されたい。本明細書で使用される見出しは、本明細書を構成する目的でのみ使用され、説明または請求項の範囲を限定するために用いられることを意図しない。本特許出願を通して使用される英単語「ｍａｙ」は、義務的な意味（すなわち「〜するべきである」という意味）よりむしろ許容的な意味（すなわち「〜する可能性がある」という意味）で使用される。同様に英単語「ｉｎｃｌｕｄｅ」、 「ｉｎｃｌｕｄｉｎｇ」、及び「ｉｎｃｌｕｄｅｓ」は「含む」ことを意味するが、その対象を限定しない。

【0004】

以下の詳細説明において、請求される内容の完全な理解のために、数多くの特定的な詳細が明らかにされる。しかしながら、請求される内容はこれらの特定的な詳細なしに実施可能であることを、当業者は理解するであろう。別の事例においては、請求される内容を曖昧にしないために、当業者が知りうる方法、装置、またはシステムは記載されていない。

【0005】

本明細書において様々な要素を説明するのに、第１、第２等の用語が使用されうるが、これらの要素はこれらの用語に限定されてはならないことも理解されよう。これらの用語は、１つの要素を別の要素と区別するためにのみ使用される。例えば、本発明の範囲から逸脱することなく、第１コンタクトを第２コンタクトと称することが可能であり、そして同様に第２コンタクトを第１コンタクトと称することも可能である。第１コンタクト及び第２コンタクトは両方ともコンタクトであるが、同一のコンタクトではない。

【0006】

本明細書の発明の説明において使用される用語は、特定の実施形態を説明する目的でのみ使用され、本発明を限定する意図はない。発明の説明及び添付の請求項において使用される単数形「１つの（英単語「ａ」、 「ａｎ」）」、及び「その（英単語「ｔｈｅ」）」は、文脈が別に明示しない限り、複数形も含むことが意図される。本明細書で使用される用語「及び／または」は、１以上の列挙された関連項目の任意または全ての可能性のある組合せを指し、包含することも理解されよう。用語「含む」、「含んでいる」、「備える」、及び「備えている」が本明細書で使用される場合、述べられた特徴、整数、ステップ、動作、要素、及び／またはコンポーネントの存在を特定するが、１以上の他の特徴、整数、ステップ、動作、要素、コンポーネント、及び／またはそれらの群の存在または追加を除外しないことがさらに理解されよう。

【0007】

本明細書で使用される用語「場合」は、文脈により「時」、「にあたり」、「決定／特定／判定に応じて」、または「検出に応じて」という意味に解釈されうる。同様に、「決定／特定／判定された場合」または「［述べられた状態またはイベント］が検出された場合」は、文脈により「決定／特定／判定にあたり」、「決定／特定／判定に応じて」、「［述べられた状態またはイベント］の検出にあたり」、または「［述べられた状態またはイベント］の検出に応じて」という意味に解釈されうる。

【0008】

選択性用データビットインターリーブによりリレーショナルデータベーステーブルのマルチカラムインデックスを生成する様々な実施形態が、本明細書において説明される。分散データウェアハウスシステムまたは他のデータベース管理システム等のデータベース管理サービスは、クライアントに効率的なデータ管理を提供するために、ロー指向フォーマット及び／またはカラム指向フォーマット（以下「カラム型データベーステーブル」と称する）等の数多くの異なるフォーマットに従ってリレーショナルデータベーステーブルを実行しうる。一般に、リレーショナルデータベーステーブルのデータは、日付順等のデータベーステーブルの１つのカラムに従ってソートされる。データをソートするのに使用するカラムのデータをブロックがソートしているか否かを判定する時、各データブロックの異なる範囲が記憶または推定され、これによりクエリは、データブロックに記憶されていると見られる要求データを有するデータブロックの読取指示のみを行えばよい。しかしながら、このような技法は、データベーステーブルが１度に１つのカラムのみを使用してソートされうるため、リレーショナルデータベーステーブルをソートするのに使用するカラムのデータに対するクエリに応答する時にのみ適用されうる。クエリが複数の異なるカラムを対象とする場合、単一のカラムによるソートは、同一の効率的なクエリ処理特性を提供しえない。典型的データベースシステムの共通の解決策は、さらに多くのリソースを消費して、異なるカラムを利用しソートされたデータベーステーブルの複数のコピーを提供することである。別の共通の解決策において、他のデータベースシステムは、各エントリの単一カラム値に関してカラムを検索する対象となる複数のカラムの値を結合した連結ソートキーを有する新たなカラムに従って、データベーステーブルをソートしうる。しかしながら、このような解決策はなお、値が連結された順番に従った偏った効率的検索を行う。さらに、このような連結キーは、インデックスに使用された複数のカラムにわたり均等に選択的ではありえない。

【0009】

マルチカラムインデックスにより、リレーショナルデータベーステーブルを、リレーショナルデータベーステーブルの複数のカラムを使用してソートまたは編制（例えば、分類配置）することが可能になる。選択性のためデータビットをインターリーブするインターリーブ法に少なくとも一部基づいて、複数のカラムのエントリに記憶されたデータ値から生成されたマルチカラムインデックスは、マルチカラムインデックスを構成するカラムに対し、より均一に分布した選択性（例えば、特定のカラムのデータ値の選別性または蓋然性）を有するインデックス値を提供しうる。従って、インデックスカラム及び／またはマルチカラムインデックスを生成するのに使用したカラム（例えば、インデックスカラムのうちの１つのカラムに関するデータ階層を決定するのに使用したカラム）に対するクエリを処理する時、インデックスカラム間で均衡した、またはより均一に分布したマルチカラムインデックスの選択性が、選択データをより効率的に検索するために使用されうる。例えば、マルチカラムインデックス値範囲を維持すること（前の実施例で述べられたように）により、クエリを処理する時、どのデータブロックを読取る必要があり、どのデータブロックを読取る必要がないか、決定することが可能になる。例えば、受信したクエリを処理する際、データを取得するためにより少ない読取動作（または他の様々なアクセス動作）が実行されうる。リレーショナルデータベースに対するクエリを処理するために、選択性用データビットインターリーブに少なくとも一部基づいたマルチカラムインデックスを生成することで、いくつかの実施形態は、大量のデータのより効率的な管理及びアクセスを提供することが可能になる。

【0010】

図１は、いくつかの実施形態による、選択性用データビットインターリーブに基づいたリレーショナルデータベースシステムのマルチカラムインデックスの生成に関するデータフローブロック図を示す。様々な実施形態において、リレーショナルデータベースに記憶させるデータが受信されうる（または既に現在データは記憶されている）。いくつかの（他を除く）データカラム１１２からマルチカラムインデックスキージェネレータ１３０に向かう矢印で例示されるように、データベーステーブルに記憶させる複数のデータカラム１１２のうち異なる選択カラムが、マルチカラムインデックスキーを生成するのに使用されうる。マルチカラムインデックスキー値を生成するために使用するカラムの選択または特定は、使用するカラムに関するクライアント特定カラム識別子を受信する等、テーブル作成処理の一環として行われうる。

【0011】

いくつかの実施形態において、マルチカラムインデックスキー（すなわち値）を含むデータベーステーブル用の新しいデータカラムを生成するために、マルチカラムインデックスキージェネレータ１３０がデータベースシステムまたは他のデータ記憶管理コンポーネントにより実行されうる。このマルチカラムインデックス１２２は、選択性用データビットインターリーブに少なくとも一部基づいて、マルチカラムインデックスを生成するのに使用する特定カラムから生成されうる。例えば、ｚ曲線または他の空間充填曲線（例えば、ヒルベルト曲線）を生成するインターリーブ法またはスキームは、異なるカラム値のデータビットを、それらの選択性によりインターリーブするために使用されうる。例えば、ｚ曲線において、各カラム値の最も有意なデータビットがインターリーブされ、それから次に有意なデータビット等々が同様にインターリーブされる。数多くの異なる様々な当技術並びに他の技術が、図７に関連してさらに詳しく後述される。インターリーブ法またはスキームに従って、エントリの各カラム値のデータビットをインターリーブすることで、データベーステーブルにおける各エントリに対し、マルチカラムインデックス値が生成されうる。そして生成されたインデックス値が、エントリのマルチカラムインデックスキーとしてマルチカラムインデックス１２２に記憶されうる。マルチカラムインデックス１２２のインデックス値を生成するために様々な異なる方法及び技法が使用され、図７に関連してさらに詳しく後述され、並びにマルチカラムインデックスキージェネレータ１３０を実行するための様々な手段が図５及び６に関連してさらに詳しく後述される。いくつかの実施形態において、特定のカラム値のデータビットをインターリーブする前に、順序保存型圧縮法が当該値に対して適用されうる。順序保存型圧縮法を適用することで、エントリのカラム値を表す個々のデータビット間により良く分布された選択性が実現されうる。少なくともいくつかの実施形態において、不自然な順序のカラムに対し順序を与えるために、カラムに対し階層または分類が圧縮前に適用され、これにより圧縮データの選択性が改善されうる。

【0012】

様々な実施形態において、データストア１２０は、ロー指向ストレージシステムまたはカラム型ストレージシステム等のデータベースシステムの永続的ストレージでありうる。マルチカラムインデックスキージェネレータ１３０により生成されたマルチカラムインデックスキー値を伴うデータカラム１１２は、データベースのデータストア１２０において持続されうる。少なくともいくつかの実施形態において、データカラムはマルチカラムインデックス１１２に従った整列順序で記憶され、従ってソートされたデータカラム１２４として持続されうる。これらのソートされたデータカラム１２４及びマルチカラムインデックス１１２は、マルチカラムインデックスキー値のソート順に従って物理的に持続されうる。データベーステーブルに対するクエリを処理する時、類似したマルチカラムインデックスキー値を有するエントリは、クエリを処理するためのアクセス要求及び他の関連動作の数を削減するために、一緒に近くに配置されうる。

【0013】

その後のストレージまたは管理を要しうる大量のデータを収集することは、クライアント（または顧客、組織、企業等）にとって珍しいことではない。一部のクライアントは自身のデータに対して自身のデータ管理システムの実行を所望しうるが、データ管理サービスを受けることはより効率的で費用効果のある選択肢であることは、自身のデータの管理を所望しないクライアントにとってますます明らかである。例えば、小規模のビジネスの場合、売上記録及び関連データを将来のデータ分析のために維持することが所望されうる。小規模のビジネスの場合、データを維持するためのデータ管理システム及びシステムを設定し維持するのに必要な専門技術に直接投資する代わりに、自身のデータを記憶し管理するためにデータ管理サービスと契約するほうがより効率的であると認知されるであろう。

【0014】

図２から４に関して後述される分散データウェアハウスサービス等のデータ管理サービスはクライアントに対し、クライアントの様々なニーズに従って多様な異なるデータ管理サービスを提供しうる。時として、クライアントは、売上記録、マーケティング、管理報告、ビジネスプロセス管理、予算予測、財務報告、ウェブサイト分析、または数多くの他のタイプまたは種類のデータ等の大量のデータを記憶し維持することを所望しうる。クライアントのデータの使用目的も、データを記憶するために使用されるデータ管理システムの構成に影響しうる。例えば、各ローの少ないカラムから大きなデータセットを集約するような特定の種類のデータ分析及び他の操作に関し、カラム型データベーステーブルはより効率的なパフォーマンスを提供しうる。言い換えれば、データベーステーブルのカラム情報はディスク上のデータブロックに記憶され、カラムを含む全てのローが各データブロックに記憶されることはない（従来のデータベーススキームのように）。下記において、リレーショナルカラム型データベースシステムの様々な実施形態が説明される。しかしながら、選択性用データビットインターリーブによるリレーショナルデータベースシステムのマルチカラムインデックスの生成に関連した後述の様々なバージョンのコンポーネントは、同様に、ロー指向データベースシステム等の様々な他の種類のリレーショナルデータベースシステムの実施形態を実行するように構成または適応されうる。ゆえに、以降の実施例に、様々な他の種類または形式のリレーショナルデータベースシステムに関して制限する意図はない。

【0015】

いくつかの実施形態において、このようなカラム型様式でテーブルデータを記憶することは、様々なクエリに関する全体のディスク入出力要件を軽減し、分析的クエリパフォーマンスを改善しうる。例えば、データベーステーブル情報をカラム型様式で記憶することは、クエリを処理する一環としてデータベース操作を行うためにメモリからデータを取得する時（例えば、テーブル内の全てのローの全てのカラムフィールド値を取得する時）に行われるディスク入出力要求の数を削減し、そしてクエリを処理する時にディスクからロードされる必要のあるデータ量を軽減しうる。反対に、各データブロックが全てのテーブルローを記憶していたならば、所定の数のディスク要求に対し、クエリを処理する時に必要以上のローのカラムフィールド値が取得されうる。いくつかの実施形態において、カラム型ストレージデータ形式に合う圧縮方法を使用することにより、ディスク要件はさらに軽減されうる。例えば、各ブロックは均一のデータ（すなわち、全て同一のデータ形式のカラムフィールド値）を含んでいるため、特定のカラムデータ形式に最適な圧縮方法を適用することで、ディスクの記憶及び取得要件はさらに軽減されうる。いくつかの実施形態において、ディスク上における単一カラムのフィールド値のみを含むデータブロックの記憶スペースの節約は、システムメモリにおけるデータ取得及びそのデータの記憶時（例えば、取得されたデータを分析する、そうでなければ処理する時）のスペースの節約となりうる。例えば、クエリを実行するのに実際に必要な特定のカラムのデータを記憶するデータブロックのみが取得されメモリに記憶されうるため、１度に１つまたは少ないカラムへのアクセス及び／または処理のみを要するデータベース操作に関して必要となるメモリスペースは、従来のロー指向ストレージと比べて小さくて済む。カラム型リレーショナルデータベーステーブルの実行の効率性を向上するために、カラム型リレーショナルデータベーステーブルのインデックスカラムのデータを記憶するデータブロックに記憶されている可能性のあるデータ値を示すマルチカラムインデックスが生成され、これはクエリに応答する時に読取る必要のないデータブロックを特定するのに使用されうる。

【0016】

前述のように、様々なクライアント（または顧客、組織、企業、またはユーザ）は、データ管理サービスを利用したデータの記憶及び管理を所望しうる。図２は、いくつかの実施形態による、クライアントにデータ管理サービスを提供しうる例示的分散データウェアハウスシステムを示す。具体的には、分散データウェアハウスクラスタは、他のデータ管理またはストレージサービスを伴って、ストア要求（例えば、ストレージへのデータの書込み）またはデータのクエリ（例えば、選択データのサーバ照会言語（ＳＱＬ）要求）に応答しうる。

【0017】

多数のユーザまたはクライアントが、分散データウェアハウスクラスタにアクセスしてデータウェアハウスサービスを受けうる。いくつかの実施形態によれば、クライアントには、ユーザ、クライアントアプリケーション、及び／またはデータウェアハウスサービス契約者が含まれうる。当実施例において、クライアント２５０ａから２５０ｎまでの各クライアントは、分散データウェアハウスサービス２８０内の分散データウェアハウスクラスタ２２５及び２３５にそれぞれアクセス可能である。分散データウェアハウスクラスタ２２５及び２３５は、これらのクラスタにアクセスできるクライアント２５０ａから２５０ｎのためにデータを記憶しうる２つ以上のノードを含みうる。

【0018】

クライアント２５０ａから２５０ｎ等のクライアントは、データウェアハウスクラスタ２２５または２３５との通信を、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、パーソナルデジタルアシスタント、モバイルデバイス、サーバ、または図１０に関して後述される、分散データウェアハウスクラスタ２２５及び２３５に要求を送信し、及び／または分散データウェアハウスクラスタ２２５及び２３５から応答を受信するように構成されたコンピュータシステム１０００等のその他のコンピューティングシステムもしくは他のデバイスを介して行いうる。要求は、例えばデータウェアハウスクラスタが提供する特定の機能またはサービスに対応付けられたパラメータ及び／またはデータを含むメッセージとしてフォーマットされうる。このようなメッセージは、拡張マークアップ言語（ＸＭＬ）等の特定のマークアップ言語に従ってフォーマットされ、及び／または簡易オブジェクトアクセスプロトコル（ＳＯＡＰ）等のプロトコルを使用してカプセル化されうる。クライアントが分散データウェアハウスサービスマネジャー２０２と通信している時等、クライアントに標準メッセージフォーマットを提供するためにアプリケーションプログラマインタフェース（ＡＰＩ）が実行されうる。

【0019】

クライアント２５０ａから２５０ｎは、分散データウェアハウスサービス２８０が提供する分散データウェアハウスクラスタ２２５及び２３５と、広域ネットワーク（ＷＡＮ）２６０（例えば、インターネット）等の様々な異なる通信方法を使用して通信しうる。クライアントと分散データウェアハウスクラスタとの間の通信は、プライベートネットワーク、イントラネット、及び他の形式の通信ネットワークによっても簡易化されうる。クライアントは、要求を含むメッセージをアセンブルし、そして生成したメッセージをネットワークエンドポイント（例えば、データウェアハウスクラスタに対応するユニフォームリソースロケータ（ＵＲＬ））へ伝送しうる。例えば、クライアント２５０ａは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）要求を分散データウェアハウスクラスタ２２５へＷＡＮ２６０を介して送信するように構成された、ウェブクライアント等のローカルソフトウェアアプリケーションを実行するデスクトップコンピュータを介して通信を行いうる。クライアントに送信された応答または他のデータも、同様のやり方でフォーマットされうる。

【0020】

少なくともいくつかの実施形態において、２８０で示されるような分散データウェアハウスサービスは、クラスタ２２５及び２３５等の分散データウェアハウスクラスタを提供しうる。分散データウェアハウスサービス２８０は、クライアント２５０ａから２５０ｎが直接特定のクラスタに要求及び他のメッセージを送信することを可能にするネットワークエンドポイントを、クライアント２５０ａから２５０ｎに提供しうる。前述のように、ネットワークエンドポイントは、例えば特定のクラスタを示すＵＲＬ等の特定のネットワークアドレスでありうる。例えば、クライアント２５０ａに、様々な要求メッセージを送信するために、ネットワークエンドポイント「ｈｔｔｐ：／／ｍｙｃｌｕｓｔｅｒ．ｃｏｍ」が提供されうる。特定クラスタのネットワークエンドポイントが、複数のクライアント（または特定クライアントのユーザ）に提供されうる。不正ユーザがクラスタにアクセスすることを防ぐために、様々なセキュリティ機能が実行されうる。逆に、複数のクラスタのネットワークエンドポイントがクライアントに提供されうる。

【0021】

データウェアハウスクラスタ２２５及び２３５等の分散データウェアハウスクラスタは、１以上のノードで構成されうる。これらのクラスタは、異なる数のノードを含みうる。ノードは、サーバ、デスクトップコンピュータ、ラップトップ、または図１０のコンピュータシステム１０００に関して後述されるコンピューティングデバイス等のより一般的なその他のコンピューティングデバイスでありうる。いくつかの実施形態において、データウェアハウスクラスタ内のノードの数は、クラスタスケーリング要求等により修正されうる。データウェアハウスクラスタのノードは、データを記憶するために１以上のデータスライスを実装しうる。これらのデータスライスは、図３及び４に関して後述されるディスクストレージデバイス等のストレージデバイスの一部でありうる。クラスタは、クライアント２５０ａから２５０ｎ等のクライアントからＷＡＮ２６０を介して、要求及び他の情報を受信するように構成されうる。クラスタは、複数のクライアントからクラスタのネットワークエンドポイントを介して、要求を受信するように構成されうる。

【0022】

いくつかの実施形態において、分散データウェアハウスサービス２８０は、ユーザがクラウドコンピューティング環境においてデータウェアハウスを設定、操作、及びスケーリングすることを可能にするネットワークベースサービスの一部として実行されうる。ネットワークベースサービスが提供するデータウェアハウスクラスタは、企業クラスのデータベースクエリ、及びネットワークベースサービスにより実行されるクラスタ制御インターフェイスへクラスタスケーリング要求を送信すること等により、ユーザがクラスタをスケーリングすることを可能にする管理システムを提供しうる。クラスタのスケーリングにより、ネットワークベースサービスのユーザは、構造化データにおける高速クエリ能力、様々なデータロード及びＥＴＬ（抽出、変換、及びロード）ツールとの統合、クラス最高のビジネスインテリジェンス（ＢＩ）報告へのクライアント接続、データマイニング、及び分析ツール等のクラスタのデータウェアハウス機能と、並びにマルチテーブル結合、サブクエリ、及び集約を含むような複合分析クエリの非常に速い実行のための最適化とを、より効率的に実行することが可能になる。

【0023】

様々な実施形態において、分散データウェアハウスサービス２８０は、クライアント（例えば、分散データウェアハウスシステムが提供するデータウェアハウスサービスの契約者）に対し、ストレージクライアントの要求に対する応答において、作成、構成、管理、スケーリング、及び終了が行われうるデータストレージ及び管理リソースを提供しうる。例えば、いくつかの実施形態において、分散データウェアハウスサービス２８０は、システムのクライアントに対し仮想計算ノードで構成された分散データウェアハウスクラスタを提供しうる。これらの仮想計算ノードは、ハードウェア仮想マシン等の仮想マシン、あるいはハードウェア構成をシミュレートするために実装された他の形式のソフトウェアにより実行されるノードでありうる。仮想ノードは、物理ハードウェアに実装されたノードと同一のタスク、機能、及び／またはサービスを行うように構成されうる。

【0024】

分散データウェアハウスサービス２８０は、カスタマイズされた、もしくは既製のコンピューティングシステム、サーバ、または図１０に関して後述される様々な種類のデバイス等のデバイスもしくはコンピューティングシステムのその他の組合せといった、コンピューティングデバイスの大きな集合により実行されうる。これらのコンピューティングデバイスの異なるサブセットは、分散データウェアハウスサービスマネジャー２０２により制御されうる。例えば、分散データウェアハウスサービスマネジャー２０２は、クライアント２５０ａから２５０ｎ等のクライアント、または分散データウェアハウスマネジャー２０２が管理するデータウェアハウスクラスタ（当例示図の分散データウェアハウスクラスタ２２５及び２３５）との対話を所望するその他のクライアントまたはユーザに対し、クラスタ制御インターフェイスを提供しうる。例えば、分散データウェアハウスサービスマネジャー２０２は、ストレージクライアントのために１以上のグラフィカルユーザインターフェイス（ＧＵＩ）を生成し、そしてこのＧＵＩは、分散データウェアハウスサービス２８０が提供する分散データウェアハウスクラスタの制御インターフェイスにより提供される様々な制御機能を選択するのに利用されうる。

【0025】

図３は、一実施形態による、分散データウェアハウスサービスにおける分散データウェアハウスクラスタを示すブロック図である。当実施例において示されるように、分散データウェアハウスクラスタ３００は、リーダーノード３２０と計算ノード３３０、３４０、３５０とを含み、これらは相互接続配線３６０を介して互いに通信しうる。リーダーノード３２０は、分散データウェアハウスクラスタ３００においてクエリを実行するための１以上のクエリプラン３２５を生成及び／または保持しうる。本明細書にて説明されるように、分散データウェアハウスクラスタ内の各ノードは、クライアント（例えば、ユーザ、クライアントアプリケーション、及び／または分散データウェアハウスサービス契約者）のためにデータブロックを記憶しうる複数のディスクを含みうる。当実施例において、計算ノード３３０はディスク３３１〜３３８を含み、計算ノード３４０はディスク３４１〜３４８を含み、そして計算ノード３５０はディスク３５１〜３５８を含む。いくつかの実施形態において、分散データウェアハウスクラスタのコンポーネント（またはそれ自体がコンポーネントである分散データウェアハウスシステム)は、多様な適用可能な負荷分散法のいずれかを使用して、負荷分散を支援しうる。例えば、いくつかの実施形態において、リーダーノード３２０は負荷分散コンポーネントを含みうる（図示せず）。

【0026】

少なくともいくつかの実施形態において、分散データウェアハウスクラスタ３００は、前述のようなウェブベースのデータウェアハウスサービスの一部として実行され、そしてリーダーノード３２０と計算ノード３３０、３４０、３５０等の複数の計算ノードとを含む。リーダーノード３２０は、図２に関して前述されたクライアント２５０ａから２５０ｎ等のストレージクライアントとの通信を管理しうる。例えば、リーダーノードは、様々なクライアントプログラム（例えば、アプリケーション）及び／または契約者（ユーザ）から要求を受信し、そしてそれらを構文解析し、関連データベース操作（複数可）を実行するための実行プラン（例えば、クエリプラン（複数可）３２５）を創出するサーバでありうる。より具体的には、リーダーノードは、複合クエリ及び結合に対する結果を取得するのに必要な一連のステップを創出しうる。リーダーノード３２０はまた、分散データウェアハウスクラスタ３００に記憶されたデータに対するデータベース操作を実行するように命令された計算ノード３３０から３５０の間の通信を管理しうる。例えば、クエリを実行するために必要となるステップを決行するために、コンパイル済みコードが、リーダーノード３２０により計算ノード３３０から３５０のうちの様々なノードへ配布され、そしてこれらのクエリの中間結果がリーダーノード３２０へ返信されうる。リーダーノード３２０は、計算ノード３３０、３４０、３５０からデータ及びクエリ応答すなわち結果を受信しうる。クラスタに記憶されたデータテーブル等の計算ノードに記憶されたデータのデータベーススキーマ及び／または他のメタデータ情報は、リーダーノード３２０により管理及び記憶されうる。

【0027】

分散データウェアハウスクラスタ３００は、計算ノード３３０、３４０、３５０等の計算ノードも含みうる。これらの１以上の計算ノードは（時にストレージノードと称される）は、例えばサーバまたは図１０のコンピュータシステム１０００に関して後述されるような他のコンピューティングデバイスに実装され、そして各ノードは、例えばサーバのマルチコアプロセッサのコアごとに定義された個別のクエリ処理スライスを含みうる。計算ノードは、リーダーノード３２０から計算ノード３３０、３４０、３５０へ送信された命令に基づいて、クエリ等のデータベース操作の処理を行いうる。命令は、例えば、命令が送信された特定データ計算ノードにより実行可能な実行プランセグメント及びステップに基づいたコンパイル済みコードでありうる。データ計算ノードは、最終集約のために、クエリの中間結果をリーダーノード３２０に返送しうる。各データ計算ノードは、１以上の計算ノード３３０、３４０、または３５０に送信されたクエリ（または他のデータベース操作）の作業量の一部を処理するために、特定のメモリ及びディスクスペースにアクセスするように構成されうる。従って、例えば計算ノード３３０は、ディスク４３１、４３２からディスク４３８までアクセス可能である。

【0028】

図３に示されるディスク３３１から３５８等のディスクは、データ計算ノードがアクセス可能なデータを記憶するのに好適な１以上の任意の種類のストレージデバイス及び／またはストレージシステムとして実装されうる。ディスクには、低価格ディスク冗長アレイ（ＲＡＩＤ）デバイス、単純ディスク束（ＪＢＯＤ）（ＲＡＩＤにより構成されないディスクを指すのに使用される）等のディスクドライブもしくはディスクドライブアレイ、光学ストレージデバイス、テープドライブ、ＲＡＭディスク、ストレージエリアネットワーク（ＳＡＮ）、ネットワークアクセスストレージ（ＮＡＳ）、またはこれらの組合せが含まれるが、これらに限定はされない。様々な実施形態において、ディスクは、様々なカラム指向データベーススキームを通してカラム型データベーステーブルを記憶するようにフォーマットされうる。

【0029】

いくつかの実施形態において、分散データウェアハウスクラスタ内の各計算ノードは、例えばコマンドを受信し、データを返信し、所定のクエリを実行するために個々のクエリプロセスに（例えば、ノード上のコアまたはスライスごとに）コンパイル済みコードを届ける等、リーダーノードとの通信を管理するノードサーバの（または他のコンピューティングデバイスの）オペレーティングシステム上で作動する一式のプロセスを実行しうる。いくつかの実施形態において、各計算ノードは、ノード上に記憶されたブロックのメタデータを含みうる。少なくともいくつかの実施形態において、このブロックメタデータは、エントリが情報（例えば、そのノード上に記憶された各データブロックに関するメタデータ）を記憶する（すなわち、データブロックごとに１つのエントリを使用）データ構造（例えば、データの配列）であるスーパーブロックデータ構造に、まとめて集約されうる。いくつかの実施形態において、スーパーブロックデータ構造の各エントリは各自のブロックの固有ＩＤを含み、そしてこの固有ＩＤはデータブロックに関連する様々な操作を行うのに使用されうる。例えば、データブロックに記憶されたデータに適用されたカラム特定圧縮法の指示、データブロックに記憶されたデータに適用されたデフォルトの圧縮法の指示、またはデータブロックに記憶されていないデータ値を示す確率的データ構造は全て、データブロックの各自のエントリに記憶されうる。いくつかの実施形態において、データブロックが分散データウェアハウスシステムに最初に書込まれた時に、リーダーノードにより、または計算ノードにより、固有ＩＤは生成されうる（そしてスーパーブロックにおいて対応するエントリが作成されうる）。少なくともいくつかの実施形態において、スーパーブロックに記憶されたエントリのデータ値に関連するマルチカラムインデックス値の最小及び最大値等の範囲を示すスーパーブロック内のエントリが保持されうる。

【0030】

図４は、いくつかの実施形態による、例示的計算ノードを示す。リーダーノード３２０等のリーダーノードに送信され、そしてリーダーノードから計算ノードへ送信された様々なクエリ及びメッセージ等のアクセス要求４５２は、計算ノード４５０において受信されうる。図５に関してさらに詳しく後述されるデータアクセスモジュール４６０は、ディスク４５０から４５８に対する読取、書込、そして他のアクセス動作を指示するアクセス要求を処理しうる。クエリ実行モジュール４６０を実行するために、様々な異なるハードウェア及びソフトウェアデバイスが単一に、または組合わせて使用されうる。クエリの処理時、データアクセスモジュール４６０は、クエリを処理する際読取る必要のあるデータブロックを特定するために、データベーステーブルのデータを記憶するデータブロックごとに、スーパーブロックにおけるマルチカラムインデックス値の範囲に関してエントリを調べ、そしてカラムのデータを記憶する特定されたデータブロックを読取りうる。

【0031】

いくつかの実施形態において、計算ノード４５０はまた、ローカルに計算ノードに記憶される、または遠隔だが計算ノードがアクセス可能な状態で記憶される、前述のスーパーブロックデータ構造等のスーパーブロックデータ構造４７０も含みうる。スーパーブロックデータ構造４７０は、計算ノード４５０上に記憶されたデータブロックのそれぞれのエントリを含み、データブロックのそれぞれのエントリは、データブロックに関するマルチカラムインデックス値範囲並びに他の情報を含むブロックメタデータを記憶する。しかしながら、いくつかの実施形態において、データブロックのメタデータは、データブロック自身内、または他の個別のデータ構造内等の複数の異なる場所に記憶されうることに留意されたい。ゆえに、スーパーブロックデータ構造４７０に、データブロックのメタデータ情報を保存するために適用されうる様々な他の構造、場所、方法、または技法に関して制限する意図はない。

【0032】

前述のように、計算ノードは、クエリ、ストレージ操作、及び他のデータ管理操作等のアクセス要求を受信するように構成されうる。図５は、いくつかの実施形態による、クエリ処理のためにブルームフィルタを実施する例示的データアクセスモジュールを示すブロック図である。クエリ５０４及びデータストア要求５０２、またはクエリもしくはデータストア要求指示が、データアクセスモジュール５００にインプットとして受信されうる。データアクセスモジュール５００は、カラム型データベーステーブルの複数のカラムの複数のデータブロックを記憶しうるストレージ５３０と通信しうる。複数のカラムのデータは、ストレージ５３０内のデータブロックに記憶され、そしてデータアクセスモジュール５００は、このデータのストレージへの記憶、及びこのデータのストレージからの読取りの両方を行うように構成されうる。

【0033】

データアクセスモジュール５００の一部または全てが、図４に関して前述された計算ノード４５０等の計算ノードに実装されうる。データアクセスモジュール５００または、マルチカラムキージェネレータ１３０等のデータアクセスモジュール５００のコンポーネントもしくはモジュールは、図４の計算ノードに実装されたように描かれているが、図３に関して前述されたリーダーノード３２０、またはデータウェアハウスサービスのある他のコンポーネントもしくはモジュールに実装されうる。様々な異なる構成のハードウェア及びソフトウェアコンポーネントが、データアクセスモジュール５００並びに共に示されたコンポーネントもしくはモジュールを実行するのに使用されうる。データアクセスモジュール５００と共に、異なるモジュールもしくはコンポーネントが１以上の個別のモジュールもしくはデバイスとして例示されるが、これらの様々なコンポーネントは、１つに合併、別々に配置、あるいはカラム型リレーショナルデータベーステーブルにおける選択性用データビットインターリーブによるマルチカラムインデックスの生成を実行するように構成されることが可能であり、ゆえに、以降の図５の説明に、データアクセスモジュールまたは同様のモジュールもしくはデバイスを実行しうる様々な他の方法に関して制限する意図はないということにも留意されたい。

【0034】

データストア要求５０２は、ストレージ５３０に記憶されたカラム型リレーショナルデータベーステーブルに記憶させたいデータを含みうる。例えば、ストレージ５３０内のデータブロックに記憶させるストレージ用データは、ストレージ要求情報及びストレージ用データを受信するように構成されたオープンデータベースコネクティビティ（ＯＤＢＣ）及び／またはジャバデータベースコネクティビティ（ＪＤＢＣ）のドライバインターフェイスもしくは他のコンポーネントを介して取得されうる。マルチカラムインデックスキージェネレータ１３０は、ストレージ５３０内のデータベーステーブルに記憶させるデータをインプットとして受信しうる。例示されていないが、少なくともいくつかの実施形態において、ストレージ内のデータブロックから取得されたデータもまた、マルチカラムインデックスキージェネレータ１３０にてインプットとして受信されうる。例えば、マルチカラムインデックスは、既に記憶または保持されたカラム型リレーショナルデータベーステーブルに対して生成されうる。従って、既に記憶されたカラム型リレーショナルデータベーステーブルのマルチカラムインデックスを生成するために、既に記憶されたデータもマルチカラムインデックスキージェネレータ１３０にてインプットとして受信されうる。

【0035】

記憶対象のデータの受信にあたり、マルチカラムインデックスキージェネレータ１３０は、選択性用データビットインターリーブに少なくとも一部基づいて、マルチカラムインデックス用に特定されたカラムから、カラム型リレーショナルデータベーステーブルのマルチカラムインデックスを生成しうる。カラム型リレーショナルデータベーステーブルのマルチカラムインデックスを生成する様々な技法及び方法が、図７に関して後述される。図６は、いくつかの実施形態による、図７において後述される様々な１以上の技法を実行しうる例示的マルチカラムインデックスキージェネレータを示すブロック図である。少なくともいくつかの実施形態において、マルチカラムインデックスキージェネレータ１３０は、マルチカラムインデックス用に特定された１以上のカラムのエントリのデータ値を圧縮するように構成されうる１以上の圧縮エンジン６２０を実行しうる。圧縮エンジン６２０は、１以上の順序保存型圧縮法を実行または適用するように構成されうる。一般に、順序保存型圧縮法は、圧縮されるデータ要素の順序が保存される方法でデータを圧縮しうる。いくつかの実施形態において、全ての特定されたカラムがデータ値を圧縮される必要があるわけではない。例えば、いくつかの実施形態において、マルチカラムインデックスを生成するために３つのカラムを使用するように特定したとしても、そのうちの１つのカラムのみが圧縮されうる。

【0036】

少なくともいくつかの実施形態において、マルチカラムインデックスキージェネレータ１３０は、階層スキームジェネレータ６３０も実行しうる。階層スキームジェネレータ１３０は、不自然な順序を有するカラムに対し階層を提供する１以上の異なるデータ構造、カラム、テーブル、または他のインジケータを生成しうる。例えば、日付は自然な順序（すなわち時間順）を有する。顧客識別子等のランダムに生成された数は、自然な順序／分類を有さない。例えば、顧客識別子番号は、顧客に関する記述を全く含みえない。階層スキームジェネレータ１３０は、１つのカラムに対し適用される階層スキームを、カラム型リレーショナルデータベーステーブルの１以上の他のカラムから生成するように構成されうる。例えば、階層スキームジェネレータ１３０は、居住州、次に郵便番号、次に顧客識別子自体を含む階層組織である顧客識別子カラムに関して顧客の圧縮コードが生成されるように、圧縮エンジン６２０に対し、顧客の住居州及び顧客の郵便番号を含むスキームを提供しうる。例えば、これは、顧客の州及び郵便番号を表すビットパターンまたはコードを適用し、そしてこれらと顧客識別子を表すデータビットとを連結させることにより行われうる。この情報は、グループ化（ｇｒｏｕｐ−ｂｙ）用カラム、またはカラムのディメンションテーブルから取得されうる。いくつかの実施形態において、特定カラムのエントリの値に関する階層または分類を提供するために、スノーフレークまたはスタースキーム等の様々な階層法が使用されうる。

【0037】

圧縮データの生成時にカラムに対し階層スキームを適用することで、階層により定義される類似した値のインデックス値が近くに一緒に配置され、その結果、適用された階層スキームにおいて特定された分類に対しより効率的なクエリが実行可能になる。例えば、顧客識別子と共に提供された前述の実施例を続けると、圧縮版の顧客識別子は、データ内の顧客識別子に関連する州及び郵便番号を表すデータビットまたはデータビットのパターンを含むため、データビットが他のカラムのデータビットと共にインデックス値ジェネレータ６４０によりインターリーブされると、同様または同一の居住州及び／または郵便番号を伴う顧客識別子は類似したｚ値を有し、従って近くに一緒に配置されうる。これにより、特定の州及び／または郵便番号の顧客識別子に対するクエリの処理に必要となるアクセス動作はより少なくて済む。

【0038】

マルチカラムインデックスキージェネレータ１３０は、インデックス値ジェネレータ６４０も実行しうる。インデックス値ジェネレータ６４０は、図７の構成要素７１０に関して後述される様々な技法を実施しうる。例えば、いくつかの実施形態において、インデックス値ジェネレータ６４０は、データベーステーブルのエントリにおける特定されたインデックスカラムのデータビットを、有意性の順にインターリーブしうる。例えば、最も有意なビットを最初に各データブロックから取り、それから次に有意なビット（例えば、ｚ順インターリーブ法を行うのと同様に）等々を、カラムのデータビットが新たに生成されたインデックス値に配置され終わるまで、同様に取ることでインターリーブが行われうる。生成されたインデックス値は、マルチカラムインデックス値（ソートキーまたは分散キー等のカラム型リレーショナルデータベーステーブルのキー値でありうる）として使用されうる。いくつかの実施形態において、マルチカラムインデックスキージェネレータ１３０は、カラム型リレーショナルデータベーステーブルに記憶させる追加データ／エントリをインプットとして受信しうる。マルチカラムインデックスキージェネレータ１３０は、追加エントリに対してマルチカラムインデックス値を生成しうる。いくつかの実施形態において、特定カラムのデータビットに均衡に分布した選択性を維持するために、圧縮エンジン６２０等により、追加データ／エントリに関して追加データビットが追加されうる。例えば、カラムが１４及び１６を含むデータ値を有し、そして新たな値１５が追加された場合、全てのデータカラムを再圧縮する代わりに、１５が１４と１６の間であることを示すインデックス値を生成するために使用される圧縮版の１５に対しデータビットが追加されうる。

【0039】

マルチカラムインデックスキー値ジェネレータ１３０は、書込モジュール５２０に対し、カラム型リレーショナルデータベーステーブルに関して生成されたマルチカラムインデックス値を記憶、更新、または送信し、その後書込モジュール５２０はストレージ５３０にエントリを記憶しうる。既存のテーブルに対し受信された追加エントリに関して、書込モジュール５２０は、ストレージ５３０に対して、ストレージ５３０の未ソート領域に当該エントリを記憶するように指示しうる。ブロックメタデータ５２６は、図４に関して前述されたスーパーデータ構造４７０等のストレージ５３０内のブロックに関する集約メタデータでありうる。書込モジュール５２０は、ブロックメタデータ５２６の一部として、データブロックのマルチカラムインデックス値範囲を記憶する。あるいは、いくつかの実施形態において、ブロックメタデータ５２６は、異なるブロックの異なる場所に分散的に配置、またはデータアクセスモジュールから遠隔だがデータアクセスモジュールがアクセス可能な場所に記憶されうる。

【0040】

書込モジュール５２０はまた、ストレージ５３０内のデータブロックにデータブロックのデータを記憶するように、データアクセスモジュール５００によって実行されうる。少なくともいくつかの実施形態において、書込モジュール５２０は、カラム型リレーショナルデータベーステーブルのエントリを各エントリのマルチカラムインデックス値に従ってソートし、ストレージ５３０に対しカラム型リレーショナルデータベーステーブルをソート順に従って記憶するように指示を行うように構成されうる。いくつかの実施形態において、書込モジュール５２０（またはマルチカラムインデックスキージェネレータ１３０等の別の１以上のモジュール）は、データブロックに記憶されたデータに関して、ブロックメタデータ５２６を他のメタデータにより更新するように構成されうる。

【0041】

データアクセスモジュール５００はまた、ストレージ５３０に記憶された選択データに関するクエリ等、クエリ５０４またはクエリの指示を受信しうる。例えば、図３に関して前述されたリーダーノード３２０等のリーダーノードは、ストレージクライアントからクエリを受信し、データアクセスモジュール５００を実行する計算ノードにクエリを送信するクエリ実行プランを生成しうる。データアクセスモジュール５００は、クエリの処理及び受信のために、クエリエンジン５４０を実行しうる。前述のように、クエリは、クエリプランに従って実行されるべき命令であるが、より一般的には、特定の判定基準を満たす、または特定のプロセスにより生成された、任意の種類のデータ要求でもありうる。いくつかの実施形態において、クエリまたはクエリの指示は、クエリを処理するために選択データを特定する１以上の述語データ値を含みうる。例えば、ＳＱＬクエリは、「ＷＨＥＲＥ 顧客＝『小』 及び 顧客＝『中』」等、取得されるデータに関して満たされるべき等価条件を特定する述語データ値を含みうる。いくつかの実施形態において、異なる種類のクエリが存在しうる。いくつかの種類のクエリは、特性値に対するフィルタリング（例えば、州の値が「テキサス」である全てのレコード）を要しうる。別のクエリは、より大きいデータ群を要求しうる。例えば、範囲クエリは、データ値の範囲（例えば、購入価格が１，０００ドルから１０，０００ドルまでの全ての発注書）に基づいてデータをフィルタにかける。いくつかのクエリは、データベース内の１つのテーブルのレコードを、別のデータベースから取得された対応値に基づいて、結合させるデータ結合を示しうる。（例えば、特定部署の指示と共に、同一部署を含む従業員人事情報のレコードを含む人事データベースからのレコードを結合する。）クエリエンジン５４０は当業者によく知られているように、前述の説明にクエリエンジンに関する数多くの異なる技法及び実施に関して制限する意図はない。例えば、ＳＱＬ要求等の標準データベースプロトコルメッセージを処理するように構成された標準クエリエンジンが実行されうる、あるいはＡＰＩにより特定されるようなカスタマイズされたクエリを処理するクエリエンジンが使用されうる。

【0042】

いくつかの実施形態において、ゆえに、クエリエンジン５２０は、選択データに関して、ストレージ５３０内のカラム型リレーショナルデータベーステーブルのマルチカラムインデックスを生成するのに使用した１以上のカラム（インデックスカラムのうちの１つのカラムに適用した階層スキームを決定するのに使用した１以上のカラムを含む）に対するクエリ５０４の指示を受信しうる。クエリエンジン５４０は、マルチカラムインデックスを生成するのに使用した選択性用データビットインターリーブを行う同一のインターリーブ法に基づいて、１以上の述語データ値を決定するために、当該指示を評定しうる。例えば、クエリが３つのカラムを対象とし、これらの３つのカラムに対し選択範囲または値を指示する場合（例えば、日付＝最近の２ヶ月）、インデックス値が生成され、このインデックス値により、どのデータブロックを読取る必要があるかを特定する際使用される述語インデックス値が作成される。例えば、１以上のインデックス値の範囲は、選択データを含んでいるように示されうる。特定のデータブロックが述語インデックス値に関連するエントリのデータを記憶しているか否かを判定するために、ブロックメタデータ５２６に記憶されうるようなマルチカラムインデックス値範囲が調べられうる。当該範囲に述語インデックス値が含まれない場合、当該データブロックにアクセスする必要はない。このように、いくつかの実施形態において、インデックス値は、クエリを処理する際用意すべきデータブロックを特定するのに使用されうる。さらに詳しく後述される図８は、マルチカラムインデックス値を利用してクエリを処理するために使用されうるいくつかの様々な方法及び技法を説明する。ゆえに前述の実施例に制限する意図はない。クエリエンジン５４０はそれから、読取モジュール５５０に対し、クエリを処理するために、カラム型リレーショナルデータベーステーブルのデータを記憶する特定されたデータブロックを読取るように指示しうる。

【0043】

少なくともいくつかの実施形態において、データアクセスモジュール５００は、読取モジュール５５０を含みうる。読取モジュール５５０は、ストレージ５３０からデータを取得するために、読取動作を行いうる。いくつかの実施形態において、読取モジュール５５０はクエリエンジン５４０に指示されて、カラム型リレーショナルデータベーステーブルのカラムに関して特定のデータブロックを読取り、さらなる処理のためにクエリエンジン５４０に読取データを返しうる。クエリエンジン５４０はそれから、クエリ応答５０６の中の少なくとも一部のデータをストレージクライアント、リーダーノード、または他の要求システムもしくはデバイスに対し提供しうる、あるいは、受信したクエリに従ってストレージ５３０から読取ったデータを処理、フィルタ、操作、そうでなければ変更しうる。少なくともいくつかの実施形態において、読取モジュール５５０はまた、ストレージ５３０から読取ったデータを、クエリ５０４を処理する際より頻繁にアクセスするデータのストレージを提供するデータベースキャッシュ（図示せず）または他のモジュールもしくはデバイス部分へ転送しうる。クエリエンジン５４０はそれから、読取モジュール５５０による新たな読取処理を要求することで、キャッシュまたは他のモジュールにアクセスしうる。データ管理及びストレージシステムに関する様々な異なるキャッシュ技法が当業者によく知られているように、前述の実施例に制限する意図はない。

【0044】

図示されていないが、クエリエンジン５４０またはマルチカラムインデックスキージェネレータ１３０等のデータアクセスモジュール５００の様々なコンポーネントのうちの１つは、カラム型リレーショナルデータベーステーブルのマルチカラムインデックスに使用したカラムに関する再圧縮イベントを検出するように構成されうる。図９は、修正された圧縮スキームに従って再圧縮されたカラムデータに基づいてリレーショナルデータベースのマルチカラムインデックスを再生成するために実施されうる様々な方法及び技法を示す。マルチカラムインデックスキージェネレータ１３０は、例えば、再圧縮イベントの検出にあたり、新たなマルチカラムインデックス値を生成するために、特定のカラムのデータに対し修正した圧縮スキームを適用し、当該再圧縮データビットを他のカラムのデータビットと共にインターリーブすることで、カラム型リレーショナルデータベーステーブルのマルチカラムインデックスを再生成するように構成されうる。

【0045】

様々な実施形態において、再圧縮イベントの結果であろうと、ある他のイベントの結果であろうと、更新されたマルチカラムインデックスが生成される場合、現行のマルチカラムインデックスは、更新されたマルチカラムインデックスの生成中にカラム型リレーショナルデータベースに対するクエリを処理するために、維持されうる。更新されたマルチカラムインデックスの完了にあたり、更新されたマルチカラムインデックスを使用してクエリが処理されうる。

【0046】

カラム型リレーショナルデータベーステーブルを実行する分散データウェアハウスシステムの文脈の中で図２から６が記述され例示されてきたが、図２から５において例示及び記述された様々なコンポーネントは、ロー指向リレーショナルデータベース等の様々な他のデータ形式を含むリレーショナルデータベーステーブルのデータ管理及び／またはストレージサービスを提供する他のデータ管理システムにも容易に適用可能である。このように、図２から５は、分散データウェアハウスクラスタにおける限定された実施形態である意図はなく、またデータストレージ及び管理クラスタの説明を制限する意図もない。例えば、ロー指向データベースシステムの様々な実施形態も、選択性用データビットインターリーブによりマルチカラムインデックスを生成するために、同様のモジュール及びコンポーネントを実行しうる。

【0047】

前述されてきたように、データベース管理システムは、より効率的なデータ管理機能を提供するためにリレーショナルデータベーステーブルを使用するように構成されうる。これらの機能をより効率的に実行するために、選択用データビットインターリーブに少なくとも一部基づいたマルチカラムインデックスが、リレーショナルデータベーステーブルに対し生成されうる。図７は、いくつかの実施形態による、選択性用データビットインターリーブに基づいてリレーショナルデータベーステーブルのマルチカラムインデックスを生成する方法を示す高次フローチャートである。様々な異なるシステム及びデバイスが、後述の様々な方法及び技法を、単体で、または組合わせて実行しうる。例えば、図５及び６に関して前述されたマルチカラムインデックスキージェネレータ１３０等のマルチカラムインデックスキージェネレータと、クエリエンジン５４０等のクエリエンジンとを実行するデータアクセスモジュールは、様々な方法を実施しうる。または、図３に示されたリーダーノード３２０だけでなく、例えば、図３に同様に示された一緒に稼働する複数の計算ノード等の異なるシステム及びデバイスの組合せも、後述の方法及び技法を実行しうる。ゆえに、前述の実施例及び、例示された方法を実行する参照されたその他のシステムまたはデバイスに、他の異なるコンポーネント、モジュール、システム、またはシステム及びデバイスの構成を制限する意図はない。

【0048】

図７の構成要素７００に示されるように、様々な実施形態において、リレーショナルデータベーステーブルの少なくとも２つのカラムが特定されうる。いくつかの実施形態において、データベースカラムの特定は、マルチカラムインデックスに含めるカラムを選択するクライアント要求または他の要求の受信に応じて決定されうる。例えば、図２において前述されるクライアント２５０等のクライアントは、より大きなテーブル作成要求の一環として、またはデータウェアハウスサービスで処理されるテーブル作成要求を生成する他のインターフェイスのフォームへの入力の一環として、カラム識別子を送信しうる。様々な実施形態はまた、マルチカラムインデックスに使用されうる２つ以上のカラムを特定するために、いくつの固有データ値が所定カラムに記憶されているか（例えば、性別は２つの固有値、郵便番号は９９９９９つの値）等、カラムに記憶させる（または既に記憶されている）データに対して様々な選択性分析を行いうる。例えば、３つのカラムのグループ化が、選択性の特定レベルを満たさないと特定されると、マルチカラムインデックスの一部としてグループ化されるように選択されうる。いくつかの実施形態は、エントリが最もよく検索されるカラムを特定するために、メタデータまたはデータベースに対する他のクエリもしくはアクセス統計を分析または評定しうる。特定カラムがクエリの述語値として使用された回数に関する統計をリレーショナルデータベースシステムが保持し、これにより最も頻繁に使用された３つのカラムが特定され、マルチカラムインデックスの一部として使用されるというシナリオを考察する。このように、同一（または同様）の最も頻繁にアクセスされる３つのカラムを含む新規のリレーショナルデータベーステーブルが作成される場合、これらのカラムは新規データベーステーブルのマルチカラムインデックスを生成するのに使用されうる。

【0049】

図７の構成要素７１０に示されるように、リレーショナルデータベーステーブルの少なくとも２つのカラムが１度特定されると、様々な実施形態において、リレーショナルデータベーステーブルのマルチカラムインデックスが生成されうる。前述のように、リレーショナルデータベーステーブルのマルチカラムインデックスは、データベーステーブルの各エントリ（すなわち、ロー）のインデックス値を提供しうる。従って、様々な実施形態において、データベーステーブルに対し、これらの各マルチカラムインデックスキーまたは値を含む新たなカラムが生成される。また前述のように、マルチカラムインデックスキーまたは値としてインデックス値を生成するために、選択性用データビットインターリーブに少なくとも一部基づいて、特定されたカラムからマルチカラムインデックスが生成されうる。様々な実施形態において、これらインデックス値は、単独な値であるとみなされると、特定されたカラムに関して様々なクエリ操作を行う際、個々のカラムが提供しうる選択性よりも高い選択性を提供しうる。

【0050】

選択性用インターリーブ法に従ったインデックス値の生成は、様々な実施形態によって異なるやり方で実行されうる。インデックス値は、新たなインデックス値を生成するために選択されたデータのインターリーブ二進値により生成されうる。リレーショナルデータベーステーブルのエントリ（すなわち、ロー）のインデックス値の生成に関して、図７の構成要素７００において特定されたカラムのデータビットが、この特定のエントリの新たなインデックス値を作成するためにインターリーブされうる。いくつかの実施形態において、データビットはその有意性の順にインターリーブされる（例えば、ｚ曲線を生成する技法を使用する等）。例えば、リレーショナルデータベーステーブルの特定されたカラムがカラムＡ及びカラムＥであり、そしてカラムＡのエントリ値が６（二進値は１１０）かつカラムＢのエントリ値が３（二進値は０１１）である場合、カラムＡ及びカラムＢのエントリのビットは、最も有意なビット（すなわち最初のビット値）に従ってインターリーブされうる。当実施例において、カラムＡの値の最初のビットは１であり、Ｂの最も有意なビット値０が追加され、それからＡの次に最も有意なビット値１が追加され、それからＢの次に最も有意なビット値１等々が追加される。当実施例において最終的に作成されたインデックス値は、１０１１０１となる（下線が引かれた値はカラムＢからインターリーブされた値を表す）。同様の技法が、より数の多い選択されたカラムに対して適用されうる。例えば、５つのカラムが特定された場合、特定されたカラムにおけるエントリ値の次の各ビットに対し同様なパターンを繰り返すことで、５つのカラムのそれぞれからビットがインターリーブされうる。様々な実施形態はまた、特定されたカラムの変動的な個数に応じて、データビットをインターリーブするのに異なる選択パターンを使用しうる。前述の実施例において、カラムＡの値はカラムＢの値の前にインターリーブされるが、Ｂの後にＡという逆のパターンも使用されうる。同様にさらに多数の特定されたカラムからインデックス値を生成する際も、さらに変動的な選択パターンが用いられうる（例えば、カラム１、次にカラム６、次にカラム２、次にカラム２３）。少なくともいくつかの実施形態において、特定されたカラムのデータビットをインターリーブする時、同一のパターンが繰り返される。さらに、数多くの異なるインターリーブ法（例えば、空間充填曲線法等）が当業者によく知られているように、前述の実施例に、リレーショナルデータベーステーブルの特定されたカラムに関しマルチカラムインデックスを生成しうる様々な他のやり方に関して制限する意図はない。

【0051】

様々な実施形態において、カラムの各エントリに記憶されたデータは、当該エントリの全てのデータビット値にわたる均一な分布性、または選択性を有しえない。例えば、カラムが性別を記載する場合、データビットのパターンは、アスキー値Ｍ（０１００ １１０１）またはＦ（０１００ ０１１０）等、２つの異なるパターンしかありえない。各値の最初の４ビットは同一である。これらのビットをインターリーブすることは、より均一（または均等）な選択性を有する異なるカラムのビットをインターリーブすることから生成されるインデックス値ほど、効率的な選択性を有するインデックス値を生成しえない。少なくともいくつかの実施形態において、各インデックス値にわたるより均一に分布された選択性を提供するために、データビットをインターリーブする際異なる数を含むビットが選択されうる。従って、前述で性別値アスキーコードが使用された場合、他の値をインターリーブする前に、最初の５ビットがグループとして追加されうる。いくつかの実施形態において、各カラムの異なる数を含むビットがインターリーブされうる。あるいは、別の実施形態においては、前述の実施例のように、同一の数のデータビットがインターリーブされうる。

【0052】

少なくともいくつかの実施形態において、マルチカラムインデックスのインデックス値を生成する一環として、１以上の特定されたカラムのデータに順序保存型圧縮法が適用されうる。辞書型圧縮法等の一般の順序保存型圧縮法は、データ要素の元の順序を維持すると同時に、データ値の反復または非選択的部分をより選択的なデータ値で置換える等して、データ値の反復または非選択的部分を削減しうる。例えば、発送の種類に関する所定のカラムが、「翌日、２日、夜間、陸便、航空便」等の様々な異なる語句を含む場合、共通する文字の組合せを、その文字の組合せを表すより小さいビットパターンで置換えるために、辞書型圧縮法が使用されうる。従って、当実施例において、「日」が「日」を表すより小さい数のデータビットにより置換えられうる。様々な異なる順序保存型圧縮法が当業者に知られているように、前述の実施例に、順序保存型圧縮法を適用する様々な異なる種類、方法、または技法に関して制限する意図はない。マルチカラムインデックスのインデックス値を生成するために、その後カラムのエントリの圧縮されたデータのデータビットは、他の特定されたカラムのデータビットと共にインターリーブされうる。少なくともいくつかの実施形態において、同一の圧縮法が、特定のカラムのデータ値に適用されうる。順序保存型圧縮法を適用した結果、カラムのデータビットはより均一な選択性を有し、より選択的なマルチカラムインデックスのｚ値を提供しうる。いくつかの実施形態において、追加エントリのインデックス値を生成する時、インデックスカラムにわたる均衡のとれた選択性を保つために、カラムのデータ値にデータビットが追加されうる。

【0053】

カラムに記憶されたいくつかの種類のデータは、当該カラムのデータ値の間で自然な順序または分類を有し（例えば、売上日付は自然に時間順になりうる）、他の種類のデータは自然な順序またはデータ値構造を有しえない。例えば、製品識別子または顧客識別子カラムは、自然な順序または構造を有しえないが、代わりにランダムに生成された、または割当てられた文字をまとめてグループ化したものでありうる。リレーショナルデータベーステーブルのマルチカラムインデックスの一部として特定されたこれらのカラムに対し、カラムのデータ値に自然な順序または分類を提供するために、階層が特定され、決定され、適用されうる。従って、例えば、特定の年齢及び所在地に関連する顧客識別子の検索時に、顧客識別子に適用された階層により、類似した顧客識別子（適用された階層スキームにより定義された）は、マルチカラムインデックスに使用されたそれらの類似インデックス値に基づいて、近くに一緒に配置されうる。従って、いくつかの実施形態において、１以上のカラムを圧縮する前に、１以上のカラムに対して階層または分類スキームが決定されうる。

【0054】

階層スキームの適用の一環として、カラムのデータを圧縮するのに使用される様々な順序保存型圧縮法は、カラムのデータの圧縮版にカラムの階層を含むデータビットを含みうる。例えば、製品識別子（ランダムに生成された数でありうるため、自然な順序または分類をほとんど、または全く有しえない）は、製品識別子ごとに製品の一般系統（例えば、家庭用品、電子機器、衣類、食品、等）及びさらに詳しいサブクラス（例えば、電子機器アイテムでは、テレビ、オーディオプレーヤー、ビデオプレーヤー、カメラ、携帯電話、等）を含む決定された階層スキームを有しうる。順序保存型圧縮スキームの製品識別子カラムへの適用時、製品識別子に関する製品系統、次に製品サブクラス、次に製品識別子自体を含む製品識別子の圧縮コードが生成されうる（辞書型圧縮法による）。例えば、これは、製品の系統及び顧客のサブクラスを表すビットパターンまたはコードを適用し、そしてこれらと顧客識別子を表すデータビットとを連結させることにより行われうる。階層の特定ビットパターンまたはコードの決定は、各グループの固有値の数に基づいて決定されうる。例えば、州及び郵便番号等の所在地が使用される場合、郵便番号が少ない州を表すコードは、郵便番号が多い州を表すコードより小さくなりうる。数多くの他の異なるやり方で階層スキームの適用は実施可能であり、従って前述の実施例に他を制限する意図はない。いくつかの実施形態において、特定カラムに関する階層に使用する追加ディメンション情報を含めるために、スノーフレークまたはスタートスキームが使用されうる。

【0055】

図７の構成要素７２０に示されるように、様々な実施形態において、リレーショナルデータベーステーブルのエントリがその後、リレーショナルデータベーステーブルの各エントリのそれぞれのインデックス値に従って記憶されうる。少なくともいくつかの実施形態において、マルチカラムインデックス値は、リレーショナルデータベーステーブルのソートキーとして使用されうる。エントリが１以上のストレージデバイス上に持続的に記憶されている時、エントリはそれぞれのソートキー（すなわち、インデックス値）の順にソートされ、そしてソートされた順序で記憶されうる。図４に関して前述されたスーパーブロック４７０等のストレージに関して記述するメタデータは、特定のデータブロックに記憶されたデータのそれぞれのインデックス値を示しうる（例えば、インデックス値の範囲等）。少なくともいくつかの実施形態において、マルチカラムインデックス値は、リレーショナルデータベーステーブルの分散キーとして使用されうる。分散キーは、リレーショナルデータベーステーブルが複数の異なる場所に記憶された時、部分的リレーショナルデータベーステーブルのストレージ場所を特定するのに使用されうる。例えば、図３において前述されたように、リレーショナルデータベーステーブルのデータを記憶するために、複数の計算（またはストレージ）ノードが実行されうる。各エントリのマルチカラムインデックス値に従って異なる計算ノードに配置され、そして記憶されるリレーショナルデータベーステーブルの異なる部分を特定するために、分散キーが使用されうる。例えば、１〜２０００、２００１〜４０００、そして４００１〜６０００等のマルチカラムインデックス値の異なる範囲が、異なる計算ノード上にそれぞれ記憶されうる。マルチカラムインデックス値を分散キーとして実行することで、いくつかの実施形態において、マルチカラムインデックスを生成するのに使用した特定カラムに基づいて他のリレーショナルデータベーステーブルを結合するクエリのパフォーマンスが向上されうる。

【0056】

図５に関して前述された様々な方法及び技法は、異なるイベント、トリガー、または他の要求の発生にあたって実行されうる。例えば、いくつかの実施形態において、リレーショナルデータベーステーブルは既に記憶または保持され、そして前に例示されたように、選択性用データビットインターリーブに少なくとも一部基づいてマルチカラムインデックスを生成するのに使用する２つ以上のカラムを示す要求が受信されうる。別の実施例では、いくつかの実施形態において、データベーステーブルに持続させるためのデータ及び／またはエントリが受信されうる（例えば、データベーステーブルの新たなロー）。追加データ／エントリの受信にあたり、データ／エントリを追加するリレーショナルデータベーステーブルのマルチカラムインデックス値を生成した時に既に使用した同一のカラムに従って、１以上のマルチカラムインデックス値が生成されうる。別の実施例においては、データベースシステムマネジャー、モジュール、または他の管理コンポーネント等のリレーショナルデータベースシステムは、特定のデータベーステーブルが２つ以上のカラムに対し頻繁なクエリを受信していると動的に、または自動で判定し、そしてデータベーステーブルのマルチカラムインデックスを生成するための前に例示された方法または技法を、クライアントの指示なしに実行するように構成されうる。

【0057】

前述のように、追加のデータ／エントリの受信は、データベーステーブルにおける新たなデータ／エントリのマルチカラムインデックス値の生成を引き起こしうる。少なくともいくつかの実施形態において、リレーショナルデータベーステーブルに対する様々な更新（削除、挿入、修正、追加等）は、新たなエントリとしてストレージの未ソート領域に記憶されうる。再ソートイベント（例えば、解放スペース取り戻すためのクライアント要求、または未ソート領域において持続された未ソートデータのある閾値を超えるクライアント要求）の検出に応じて、リレーショナルデータベーステーブルに対する更新結果である新たなデータ／エントリもまた、新たなデータ／エントリのために生成されたマルチカラムインデックス値／キーに従ったソート順序で（前にソートされたエントリと共に）記憶されうるように、リレーショナルデータベーステーブルが再ソートされうる。

【0058】

いくつかの実施形態において、リレーショナルデータベーステーブルの１以上のカラムに対するクエリを処理するために、マルチカラムインデックス値が提供されうる。マルチカラムインデックス値を調べることで、読取る必要のある永続的ストレージデバイス内のデータブロック数を削減すること等により、クエリはより効率的に処理されうる。図８は、いくつかの実施形態による、選択性用データビットインターリーブに基づいたマルチカラムインデックスを有するリレーショナルデータベースに対するクエリを処理する方法の高次フローチャートを示す。

【0059】

図８の構成要素８００に示されるように、様々な実施形態において、リレーショナルデータベーステーブルのマルチカラムインデックスを計算するために使用した少なくとも１つのカラムに対するクエリの指示が受信されうる。例えば、顧客識別子、製品識別子、及び売上日付カラムがカラムに関するマルチカラムインデックスを生成するのに使用された場合、１以上の顧客識別子、製品識別子、及び／または売上日付の値を検索するクエリ指示が受信されうる。クエリは、マルチカラムインデックスを生成するのに使用した全ての特定カラムを対象にする必要はないことに留意されたい。同様に、いくつかの実施形態において、クエリは、マルチカラムインデックスに使用されたこれらのカラムに加えて、他のカラムも対象としうる。例えば、いくつかの実施形態において、クエリは、インデックスカラムに対しデータ階層を決定及び／または適用するのに使用したカラムも（インデックスカラムと共に、またはインデックスカラムなしで）対象としうる。従って、前述の実施例を続けると、クエリは顧客識別子及び製品識別子、並びに顧客年齢層及び顧客性別（顧客識別子に適用される階層を決定するのに使用されうる）も対象としうる。

【0060】

図８の構成要素８１０に示されるように、クエリの指示の受信にあたり、リレーショナルデータベーステーブルのマルチカラムインデックスを生成するのに使用した同一の選択性用データビットインターリーブに基づいてクエリの述語データ値を決定するために、当該指示が評定されうる。マルチカラムインデックスのインデックス値の生成に関する前述と同様に、インデックス値は、リレーショナルデータベーステーブルに関して検索される述語データ値として生成されうる。例えば、述語データ値を特定するのに使用した値、範囲、または他のデータは、クエリを処理するために使用する１以上のインデックス値を生成するのに使用されうる。当実施例において、顧客識別子の範囲またはリストが示された場合、これらのデータ値は、インデックス値を生成するために、マルチカラムインデックスを生成するのに使用した他のカラムを表す値と共にインターリーブされうる。従って、顧客識別子１００〜２００は、１００〜２００のデータビットと共に生成されるインデックス値に変換されうる。インデックス値を生成するのに使用した他のカラムの値も判れば使用されうる。別なやり方では、いくつかの実施形態において、これらのインデックスカラムの全てのエントリを含むインデックス値を生成するために、他の値が含まれうる。

【0061】

そして図８の構成要素８２０に示されるように、様々な実施形態において、クエリを処理する際読取る必要のあるデータブロックを特定するために、リレーショナルデータベーステーブルのデータを記憶するデータブロックごとに、述語データ値に関して、マルチカラムインデックス範囲が分析または調べられうる。例えば、いくつかの実施形態において、永続的ストレージ内のデータブロックに記憶されたデータ／エントリのインデックス値を記述するメタデータが記憶／保持されうる（例えば、メタデータは、特定データブロックに記憶されたエントリの最小及び最大インデックス値等のｚ値の範囲を記述しうる）。前述のように、いくつかの実施形態において、リレーショナルデータベーステーブルのエントリは記憶され、各エントリのインデックス値に従ってソートされ、これにより、類似したデータエントリ（インデックス値により決定された）は、データブロック内に一緒に配置されうる。従って、マルチカラムインデックス範囲の分析時、述語データ値は、述語データ値を範囲内に含んでいると示されたデータブロックを有する１つの場所にのみ記憶されていると判定されうる。

【0062】

そして図８の構成要素８３０に示されるように、クエリを処理するために、リレーショナルデータベーステーブルの特定されたデータブロックが読取られうる。例えば、特定されたデータブロックは、リレーショナルデータベーステーブルのデータを記憶している永続的ストレージデバイス（または永続的ストレージデバイスを管理またはアクセスする他のシステム）に対してアクセス要求において送信されるべきブロックアドレスのリストでありうる。

【0063】

図７に関して前述されたように、リレーショナルデータベーステーブルに対する更新は、リレーショナルデータベーステーブルの新たなエントリの作成を引き起こしうる。いくつかの実施形態において、これらの新たなデータ／エントリは、特定カラムの選択性を変えうる。例えば、主にカリフォルニアでビジネスを行い、そして周りの州である小規模ビジネスを行う会社が、会社の売上データを保持する場合、インデックス値を生成する時の圧縮スキームまたはデータビットの選択は、カリフォルニアの売上のエントリの選択性を、カリフォルニアの売上を表すのに使用されるビットにより均一に分布させることに基づきうる。しかしながら、会社がその後オレゴン等の別の州に大きく拡大した場合、さらに新たな売上データすなわち新たなエントリを生成することは、所在地のカラムを表すビットの選択性分布を変えうる（オレゴンを表すためにもさらなるエントリが必要となったため）。例えば、順序保存型圧縮法が適用された場合、当該技法では、少ないオレゴンの売上に基づいてオレゴンの選択性を、当初のように適切に分布しえない。ゆえに、いくつかの実施形態において、カラムのデータビットの選択性を均一に分布させるのに圧縮が使用される実施形態等に対して、データの選択性における変化を適応させるため、様々な方法及び技法が実行されうる。図９は、いくつかの実施形態による、修正された圧縮スキームに従って再圧縮されたカラムデータに基づいてリレーショナルデータベースのマルチカラムインデックスを再生成する方法の高次フローチャートを示す。

【0064】

図９の構成要素９００に示されるように、いくつかの実施形態において、リレーショナルデータベースのマルチカラムインデックスを生成するのに使用されたカラムに対して、当該カラムの選択性に少なくとも一部基づいて、再圧縮イベントが検出されうる。例えば、様々な実施形態において、辞書型圧縮法の辞書データ構造等、リレーショナルデータベースのカラムのデータビットを均一に分布するのに使用された圧縮法／スキームを記述するメタデータが保持されうる。例えば、あるスキュー測定閾値または他の限度を超える、カラムに関するある個数の新たなデータ値が受信されると、カラムに対する再圧縮イベントが引き起こされうる。図９の構成要素９１０に示されるように、再圧縮イベントの検出にあたり、前に適用された順序保存型圧縮法／スキームが、カラムの選択性に基づいて修正されうる。様々な実施形態において、これは、新たに再発するデータ値の一部のより小さなビット表現を含むように、辞書型圧縮エンコーダまたは他の置換ベース圧縮エンコーダを単に調整することでありうる。あるいは、異なる圧縮法が全体に適用されうる（または再分析及び自己修正しうる同一の圧縮法が再度適用されうる）。

【0065】

図９の構成要素９２０に示されるように、再圧縮データを生成するために、カラムのデータを圧縮するよう修正された順序保存型圧縮スキームが適用されうる。図９の構成要素９３０に示されるように、この再圧縮されたデータはその後、選択性のために再圧縮されたデータのデータビットをインターリーブすることにより、特定されたカラムからリレーショナルデータベーステーブルの更新されたマルチカラムインデックスを再生成する一環として使用されうる。少なくともいくつかの実施形態において、インデックス値は、ストレージのリレーショナルデータベーステーブルのエントリを再ソートまたは再配置せずに更新されうる。少なくともいくつかの実施形態において、更新されたマルチカラムインデックスが完全に生成されるまで、元のマルチカラムインデックスが、リレーショナルデータベースにおけるアクセス要求（例えば、読取要求）を処理するのに使用されうる。

【0066】

本明細書で説明された選択性用データビットインターリーブによりリレーショナルデータベースシステムのマルチカラムインデックスを生成する実施形態は、様々な他のデバイスと対話しうる１以上のコンピュータシステム上で実行されうる。そのようなコンピュータシステムの１つが、図１０に例示される。異なる実施形態において、コンピュータシステム１０００は、パーソナルコンピュータシステム、デスクトップコンピュータ、ラップトップ、ノートブックもしくはネットブックコンピュータ、メインフレームコンピュータシステム、携帯型コンピュータ、ワークステーション、ネットワークコンピュータ、カメラ、セットトップボックス、モバイルデバイス、消費者デバイス、据置型ゲーム装置、携帯型ゲーム装置、アプリケーションサーバ、ストレージデバイス、または、スイッチ、モデム、ルーターなどの周辺デバイス、または一般に任意の種類のコンピューティングもしくは電子デバイス、以上を含むがこれに限定されない様々な種類のデバイスのいずれかでありうる。

【0067】

図示された実施形態において、コンピュータデバイス１０００は、入出力インターフェイス１０３０を介してシステムメモリ１０２０に接続された１以上のプロセッサ１０１０を備える。コンピュータシステム１０００はさらに、入出力インターフェイス１０３０に接続されたネットワークインターフェイス１０４０と、カーソル制御デバイス１０６０、キーボード１０７０、及びディスプレイ（複数可）１０８０等の１以上の入出力デバイス１０５０とを備える。ディスプレイ（複数可）１０８０は、標準のコンピュータモニタ（複数可）及び／または他のディスプレイシステム、技術またはデバイスを備えうる。少なくともいくつかの実装例において、入出力デバイス１０５０はまた、ユーザがスタイラス型デバイス及び／または１本以上の指により入力を行うパッドまたはタブレット等のタッチ対応デバイスまたはマルチタッチ対応デバイスも含みうる。いくつかの実施形態において、一部の実施形態はコンピュータシステム１０００の単一のインスタンスを使用して実行されうるが、一方他の実施形態においては、複数のこのようなシステム、またはコンピュータシステム１０００を構成する複数のノードが、実施形態の異なる部分またはインスタンスを提供するように構成されうると考えられる。例えば、一実施形態において、一部の要素は、他の要素を実行するコンピュータシステム１０００のノードとは異なる、コンピュータシステム１０００の１以上のノードを介して実行されうる。

【0068】

様々な実施形態において、コンピュータシステム１０００は、１つのプロセッサ１０１０を含むユニプロセッサシステム、またはいくつか（例えば２つ、４つ、８つ、または別の好適な個数）のプロセッサ１０１０を含むマルチプロセッサシステムでありうる。プロセッサ１０１０は、命令を実行可能な任意の好適なプロセッサでありうる。例えば、様々な実施形態において、プロセッサ１０１０は、様々な命令集合アーキテクチャ（ＩＳＡ）（例えばｘ８６、ＰｏｗｅｒＰＣ、ＳＰＡＲＣ、ＭＩＰＳ‐ＩＳＡ、またはその他の好適なＩＳＡ等）のいずれかを実施する汎用または組込みプロセッサでありうる。マルチプロセッサシステムにおいて、それぞれのプロセッサ１０１０は一般に、必ずではないが、同一のＩＳＡを実施しうる。

【0069】

いくつかの実施形態において、少なくとも１つのプロセッサ１０１０は、グラフィック処理装置でありうる。グラフィック処理装置、すなわちＧＰＵは、パーソナルコンピュータ、ワークステーション、ゲーム装置、または他のコンピューティングもしくは電子デバイスの専用グラフィックレンダリングデバイスであるとみなされうる。最新のＧＰＵは、コンピュータグラフィックを操作し表示する点において非常に効率的であり、そしてその高度な並列構造により、複雑なグラフィックアルゴリズムの範囲において、一般的なＣＰＵよりも効果的でありうる。例えば、グラフィックプロセッサは、ホスト中央処理装置（ＣＰＵ）により画面に直接描くよりももっと早くグラフィック基本処理を遂行するやり方で、いくつかのグラフィック基本処理を実行しうる。様々な実施形態において、グラフィックレンダリングは、このようなＧＰＵのうちの１つで実行される、またはこのようなＧＰＵのうちの２つ以上で並行実行されるように構成されたプログラム命令により、少なくとも部分的に実行されうる。ＧＰＵ（複数可）は、プログラマがＧＰＵ（複数可）の機能性を呼び出すことを可能にする１以上のアプリケーションプログラマインターフェイス（ＡＰＩ）を実行しうる。好適なＧＰＵは、ＮＶＩＤＩＡ Ｃｏｒｐｏｒａｔｉｏｎ（エヌビディアコーポレーション）、ＡＴＩ Ｔｅｃｈｎｏｌｏｇｉｅｓ（エーティアイテクノロジーズ）（ＡＭＤ、アドバンストマイクロデバイセズ）等のベンダーから購入可能である。

【0070】

システムメモリ１０２０は、プログラム命令及び／またはプロセッサ１０１０がアクセス可能なデータを記憶するように構成されうる。様々な実施形態において、システムメモリ１０２０は、静的ランダムアクセスメモリ（ＳＲＡＭ）、同期式動的ＲＡＭ（ＳＤＲＡＭ）、不揮発性／フラッシュメモリ、またはその他の種類のメモリ等、任意の好適なメモリ技術を使用して実行されうる。例示された実施形態において、前述のような所望する機能を実行するプログラム命令及びデータは、それぞれシステムメモリ１０２０においてプログラム命令１０２５及びデータストレージ１０３５として記憶されていることが示される。別の実施形態において、プログラム命令及び／またはデータは、異なる種類のコンピュータアクセス可能媒体、またはシステムメモリ１０２０もしくはコンピュータシステム１０００から独立した同様の媒体上で、受信、送信、または記憶されうる。一般に、非一時的コンピュータ可読記憶媒体には、例えば入出力インターフェイス１０３０を介してコンピュータシステム１０００に接続されたディスクまたはＣＤ／ＤＶＤ−ＲＯＭといった、磁気媒体または光学式媒体等の記憶媒体またはメモリ媒体が含まれうる。コンピュータ可読媒体を介して記憶されたプログラム命令及びデータは、送信媒体、すなわち、ネットワーク及び／または無線リンク等の通信媒体を介して伝達されうる電気、電磁またはデジタル信号等の信号によって送信され、このような信号送信はネットワークインターフェイス１０４０を介して実行されうる。

【0071】

一実施形態において、入出力インターフェイス１０３０は、プロセッサ１０１０と、システムメモリ１０２０と、ネットワークインターフェイス１０４０または入出力デバイス１０５０等の他の周辺インターフェイスを含む、デバイス内の任意の周辺デバイスとの間の入出力トラフィックを調整するように構成されうる。いくつかの実施形態において、入出力インターフェイス１０３０は、１つのコンポーネント（例えば、システムメモリ１０２０）からのデータ信号を、別のコンポーネント（例えば、プロセッサ１０１０）が使用する好適な形式に変換するのに必要な任意のプロトコル、タイミング、または他のデータ変換を行いうる。いくつかの実施形態において、入出力インターフェイス１０３０には、例えば周辺構成要素相互接続（ＰＣＩ）バス規格、または汎用シリアルバス（ＵＳＢ）規格の変形等、様々な種類の周辺バスを介して取り付けられるデバイスのサポートが含まれうる。いくつかの実施形態において、入出力インターフェイス１０３０の機能は、例えばノースブリッジとサウスブリッジといった２つ以上の別々のコンポーネントに分割されうる。さらに、いくつかの実施形態において、システムメモリ１０２０に対するインターフェイス等、一部または全ての入出力インターフェイス１０３０の機能性は、プロセッサ１０１０に直接取込まれうる。

【0072】

ネットワークインターフェイス１０４０は、コンピュータシステム１０００と他のコンピュータシステム等のネットワークに接続された他のデバイスとの間、またはコンピュータシステム１０００のノードの間において、データ交換が可能なように構成されうる。様々な実施形態において、ネットワークインターフェイス１０４０は、例えば任意の好適な種類のイーサネット（登録商標）ネットワーク等の有線もしくは無線の一般データネットワークを介して、またはアナログ音声ネットワークもしくはデジタルファイバ通信ネットワーク等の電気通信／電話ネットワークを介して、またはファイバチャネルＳＡＮ等のストレージエリアネットワークを介して、または他の任意の好適な種類のネットワーク及び／またはプロトコルを介して、通信を支援しうる。

【0073】

いくつかの実施形態において、入出力デバイス１０５０には、１以上のディスプレイ端末、キーボード、キーパッド、タッチパッド、スキャニングデバイス、音声または光学認識デバイス、または１以上のコンピュータシステム１０００がデータ入力もしくはデータ取得を行うのに好適なその他のデバイスが含まれうる。複数の入出力デバイス１０５０は、コンピュータシステム１０００に存在する、またはコンピュータシステム１０００の様々なノードに分散して配置されうる。いくつかの実施形態において、同様の入出力デバイスがコンピュータシステム１０００から独立した状態であり、ネットワークインターフェイス１０４０等を介した有線または無線接続を通して、コンピュータシステム１０００の１以上のノードと対話しうる。

【0074】

図１０に示されるように、メモリ１０２０は、本明細書に説明される様々な方法及び技法を実行するように構成されたプログラム命令１０２５と、プログラム命令１０２５によりアクセス可能な様々なデータを含むデータストレージ１０３５とを備えうる。一実施形態において、プログラム命令１０２５は、本明細書に説明され、図に例示される実施形態のソフトウェア要素を含みうる。データストレージ１０３５は、実施形態において使用されうるデータを含みうる。別の実施形態においては、他または異なるソフトウェア要素及びデータが含まれうる。

【0075】

コンピュータシステム１０００は単なる例示であり、本明細書に記載される立体図面技術の範囲を制限する意図はないことを、当業者は理解するであろう。特に、コンピュータシステム及びデバイスは、コンピュータ、パーソナルコンピュータシステム、デスクトップコンピュータ、ラップトップ、ノートブックもしくはネットブックコンピュータ、メインフレームコンピュータシステム、携帯型コンピュータ、ワークステーション、ネットワークコンピュータ、カメラ、セットトップボックス、モバイルデバイス、ネットワークデバイス、インターネットアプライアンス、ＰＤＡ、無線電話機、ポケットベル、消費者デバイス、据置型ゲーム装置、携帯型ゲーム装置、アプリケーションサーバ、ストレージデバイス、または、スイッチ、モデム、ルーターなどの周辺デバイス、または一般に任意の種類のコンピューティングもしくは電子デバイス、以上を含む示された機能を実行可能なハードウェアまたはソフトウェアの任意の組合せを備えうる。コンピュータシステム１０００は、例示されていない他のデバイスにも接続されうる、またはその代わりに、独立型システムとして作動しうる。さらに、いくつかの実施形態において、例示されたコンポーネントにより提供される機能性は、さらに少ないコンポーネントにおいて結合されうる、または追加コンポーネントに分散されうる。同様に、いくつかの実施形態において、いくつかの例示されたコンポーネントの機能性は提供されず、及び／または他の追加の機能性が利用可能となりうる。

【0076】

様々なアイテムが利用される一方でメモリまたはストレージに記憶されているように例示されているが、これらアイテムまたはこれらの一部は、メモリ管理及びデータ保全性の目的で、メモリと他のストレージデバイスとの間で転送されうることを、当業者はまた理解するであろう。または、別の実施形態において、一部または全てのソフトウェアコンポーネントが別のデバイス上のメモリにおいて実行され、そしてコンピュータ間通信を介して例示されたコンピュータシステムと通信しうる。一部または全てのシステムコンポーネントまたはデータ構造は、コンピュータアクセス可能媒体または適切なドライブにより読取られる携帯品上にも記憶されうる（例えば、命令または構造データとして）。これに関する様々な実施例は前述される。いくつかの実施形態において、コンピュータシステム１０００から独立した非一時的コンピュータアクセス可能媒体に記憶された命令は、送信媒体、すなわち、ネットワーク及び／または無線リンク等の通信媒体を介して伝達される電気、電磁またはデジタル信号等の信号により、コンピュータシステム１０００へ送信されうる。様々な実施形態はさらに、コンピュータアクセス可能媒体に関する前述の説明に従って実行される命令及び／またはデータの受信、送信または記憶処理を含みうる。よって、本発明は、他のコンピュータシステム構成でも実行可能である。

【0077】

本明細書に説明された分散システムの実施形態のいずれかは、またはそれらのコンポーネントのいずれかは、１以上のウェブサービスとして実行可能であることに留意されたい。例えば、データウェアハウスシステム内のリーダーノードは、データストレージサービス及び／またはデータベースサービスを、ネットワークベースサービスとしてクライアントに提供しうる。いくつかの実施形態において、ネットワークベースサービスは、ネットワークを介した相互運用可能なマシン間対話を支援するように設計されたソフトウェア及び／またはハードウェアシステムにより実施されうる。ネットワークベースサービスは、ウェブサービス記述言語（ＷＳＤＬ）等のマシン処理可能な形式で記述されたインターフェイスを有しうる。他のシステムは、ネットワークベースサービスのインターフェイスの記述により定められたやり方で、ウェブサービスと対話しうる。例えば、ネットワークベースサービスは、他のシステムが呼び出しうる様々な動作を定義し、そして他のシステムが様々な動作の要求時に従うべき特定のアプリケーションプログラミングインタフェース（ＡＰＩ）を定義しうる。

【0078】

様々な実施形態において、ネットワークベースサービスは、ネットワークベースサービス要求に関連するパラメータ及び／またはデータを含むメッセージの使用を通して、要求、または呼び出されうる。このようなメッセージは、拡張マークアップ言語（ＸＭＬ）等の特定のマークアップ言語に従ってフォーマットされ、及び／または簡易オブジェクトアクセスプロトコル（ＳＯＡＰ）等のプロトコルを使用してカプセル化されうる。ウェブサービス要求を行うために、ネットワークベースサービスのクライアントは、要求を含むメッセージをアセンブルし、そして生成したメッセージをウェブサービスに対応するアドレス指定可能なエンドポイント（例えば、ユニフォームリソースロケータ（ＵＲＬ））へ、ハイパーテキスト転送プロトコル（ＨＴＴＰ）等のインターネットベースのアプリケーション層転送プロトコルを使用して伝送しうる。

【0079】

いくつかの実施形態において、ウェブサービスは、メッセージベースの技法ではなく、レプレゼンテーショナルステートトランスファ（「ＲＥＳＴｆｕｌ」、表現可能な状態の転送）法を使用して実施されうる。例えば、ＲＥＳＴｆｕｌ法に従って実施されるウェブサービスは、ＳＯＡＰメッセージ内にカプセル化されたパラメータではなく、ＰＵＴ、ＧＥＴ、またはＤＥＬＥＴＥ等のＨＴＴＰメソッド内に含まれるパラメータを通して呼び出されうる。

【0080】

本明細書で説明される実施形態は、以下の代表的な項目を参照することで、より理解されるであろう。
（第１項）
カラム型リレーショナルデータベーステーブルのストレージを提供する、複数のデータブロックを備える１以上のストレージデバイスと、
カラム型リレーショナルデータベーステーブルの複数のカラムのうち少なくとも２つのカラムを特定し、
選択性用データビットインターリーブに少なくとも一部基づいて、特定された少なくとも２つのカラムから、カラム型リレーショナルデータベーステーブルのマルチカラムインデックスを生成し、当該マルチカラムインデックスはカラム型リレーショナルデータベーステーブルの各エントリのそれぞれのインデックス値を提供する
ように構成されたマルチカラムキージェネレータと、
１以上のストレージデバイスに対し、各エントリのそれぞれのインデックス値に従ってソートされたカラム型リレーショナルデータベーステーブルのエントリを、複数のデータブロックのうちの１以上のデータブロックに記憶するように指示し、
１以上のストレージデバイスに対し、１以上のデータブロックごとに記憶されたエントリのインデックス値に対応するマルチカラムインデックス値範囲を示すメタデータを記憶するように指示する
ように構成された書込モジュールと
を実行する複数の計算ノードを備える分散データウェアハウスシステム。
（第２項）
選択性用データビットインターリーブに少なくとも一部基づいて、特定された少なくとも２つのカラムから、カラム型リレーショナルデータベーステーブルのマルチカラムインデックスを生成するために、マルチカラムキージェネレータは、順序保存型圧縮法に従って少なくとも２つのカラムのうちの１つ以上のカラムのデータを圧縮するように構成された、第１項に記載のシステム。
（第３項）
順序保存型圧縮法に従って少なくとも２つのカラムのうちの１つ以上のカラムのデータを圧縮するために、マルチカラムキージェネレータはさらに、
１以上のカラムのうちの特定の１つのカラムに関するカラムデータ階層を、カラム型リレーショナルデータベーステーブルの１以上の他のカラムを基に決定し、
１以上のカラムのうちの特定の１つのカラムのデータをカラムデータ階層に従ってグループ化するために、１以上のカラムのうちの特定の１つのカラムに対しカラムデータ階層を適用する
ように構成された、第２項に記載のシステム。
（第４項）
読取モジュールと、
選択データに関して、少なくとも２つのカラムのうちの１以上のカラムに対する、またはカラム型リレーショナルデータベーステーブルの１以上の他のカラムのうちの１以上のカラムに対するクエリの指示を受信し、
選択性用データビットインターリーブに少なくとも一部基づいて、特定された少なくとも２つのカラムから、選択データを特定する１以上の述語データ値を決定するために、クエリの指示を評定し、
クエリの指示の受信及び評定に応じて、
選択データに関するクエリを処理する際、１以上のデータブロックのうち読取る必要のある特定ブロックを特定するために、１以上のデータブロックごとに、１以上の述語データ値に関して、マルチカラムインデックス値範囲を示すメタデータを分析し、
読取モジュールに対し、カラム型リレーショナルデータベーステーブルのデータを記憶する１以上のデータブロックのうちの特定ブロックを読取るように指示する
ように構成されたクエリエンジンと
をさらに備える第３項に記載のシステム。
（第５項）
１以上のコンピューティングデバイスにより、
リレーショナルデータベーステーブルの複数のカラムのうち少なくとも２つのカラムを特定し、
選択性用データビットインターリーブに少なくとも一部基づいて、特定された少なくとも２つのカラムから、リレーショナルデータベーステーブルのマルチカラムインデックスを生成し、当該マルチカラムインデックスはリレーショナルデータベーステーブルの各エントリのそれぞれのインデックス値を提供し、
リレーショナルデータベーステーブルのエントリを各エントリのそれぞれのインデックス値に従って記憶する
ことを含む方法。
（第６項）
前述のリレーショナルデータベーステーブルのマルチカラムインデックスを生成することは、少なくとも２つのカラムのうちの１以上のカラムのデータを圧縮するために順序保存型圧縮法を適用することを含む、第５項に記載の方法。
（第７項）
前述の少なくとも２つのカラムのうちの１以上のカラムのデータを圧縮するために順序保存型圧縮法を適用することは、カラムデータ階層に従って１以上のカラムのうちの特定の１つのカラムのデータをグループ化するために、１以上のカラムのうちの特定の１つのカラムに対し、カラムデータ階層を適用することを含む、第６項に記載の方法。
（第８項）
リレーショナルデータベーステーブルの各エントリのそれぞれのインデックス値は分散キー値であり、前述のリレーショナルデータベーステーブルのエントリを各エントリのそれぞれのインデックス値に従って記憶することは、持続させるリレーショナルデータベーステーブルのエントリを、リレーショナルデータベーステーブルのエントリの分散キー値に少なくとも一部基づいて、複数の異なる永続的ストレージデバイスに分散的に配置することを含む、第５項に記載の方法。
（第９項）
リレーショナルデータベーステーブルの各エントリのそれぞれのインデックス値はソートキー値であり、前述のリレーショナルデータベーステーブルのエントリを各エントリのそれぞれのインデックス値に従って記憶することは、リレーショナルデータベーステーブルのエントリのソートキー値に従ってソートされたリレーショナルデータベーステーブルのエントリを記憶することを含む、第５項に記載の方法。
（第１０項）
リレーショナルデータベーステーブルに記憶させる１以上の追加エントリを受信し、
追加エントリに関して、選択性用データビットインターリーブに少なくとも一部基づいて、特定された少なくとも２つのカラムから１以上のソートキー値を生成する
ことをさらに含む、第９項に記載の方法。
（第１１項）
リレーショナルデータベーステーブルのエントリは複数のデータブロックに持続的に記憶され、方法は、１以上のデータブロックごとに記憶されたエントリのソートキー値に対応するマルチカラムソートキー値範囲を示すメタデータを保持することをさらに含む、第９項に記載の方法。
（第１２項）
選択データに関して、リレーショナルデータベーステーブルの少なくとも２つのカラムのうちの１以上のカラムに対するクエリの指示を受信し、
選択性用データビットインターリーブに少なくとも一部基づいて、特定された２つのカラムから、選択データを特定する１以上の述語データ値を決定するために、クエリの指示を評定し、
クエリの指示の受信及び評定に応じて、
選択データに関するクエリを処理する際、複数のデータブロックのうち読取る必要のある特定ブロックを特定するために、１以上のデータブロックごとに、１以上の述語データ値に関して、マルチカラムソートキー値範囲を分析する
ことをさらに含む、第１１項に記載の方法。
（第１３項）
１以上のコンピューティングデバイスが、分散データベースシステムにおける１以上のクライアントのデータを記憶するデータウェアハウスクラスタを実行するコンピューティングデバイスのより大きな集合の一部であり、１以上のコンピューティングデバイスは共にデータウェアハウスクラスタの計算ノードを実行し、前述のリレーショナルデータベーステーブルの複数のカラムのうち少なくとも２つのカラムを特定することは、クライアントが選んだカラムの指示を少なくとも２つの特定されたカラムとして受信することを含む、第５項に記載の方法。
（第１４項）
プログラム命令を記憶する非一時的コンピュータ可読記憶媒体であって、プログラム命令は１以上のコンピューティングデバイスにより実行されると、１以上のコンピューティングデバイスにリレーショナルデータベースシステムを実行させ、リレーショナルデータベースシステムは、
リレーショナルデータベーステーブルの複数のカラムのうち少なくとも２つのカラムを特定し、
選択性用データビットインターリーブに少なくとも一部基づいて、特定された少なくとも２つのカラムから、リレーショナルデータベーステーブルのマルチカラムインデックスを生成し、当該マルチカラムインデックスはリレーショナルデータベーステーブルの各エントリのそれぞれのインデックス値を提供し、
リレーショナルデータベーステーブルのエントリを各エントリのそれぞれのインデックス値に従って記憶することを指示する
ことを実行する、非一時的コンピュータ可読記憶媒体。
（第１５項）
前述のリレーショナルデータベーステーブルのマルチカラムインデックスの生成において、プログラム命令はデータベースシステムに、少なくとも２つのカラムのうちの１以上のカラムのデータを圧縮するために順序保存型圧縮スキームを適用することを実行させる、第１４項に記載の非一時的コンピュータ可読記憶媒体。
（第１６項）
プログラム命令はさらにデータベースシステムに、
リレーショナルデータベーステーブルに記憶させる１以上の追加エントリを受信し、
１以上の追加エントリに関して、選択性用データビットインターリーブに少なくとも一部基づいて、特定された少なくとも２つのカラムから１以上のインデックス値を生成する
ことを実行させる、第１５項に記載の非一時的コンピュータ可読記憶媒体。
（第１７項）
プログラム命令はさらにデータベースシステムに、
１以上のカラムのうちの特定の１つのカラムの選択性に少なくとも一部基づいて、１以上のカラムのうちの特定の１つのカラムの再圧縮イベントを検出し、
１以上のカラムのうちの特定の１つのカラムの選択性に少なくとも一部基づいて、順序保存型圧縮スキームを修正し、
再圧縮データを生成するために、追加の１以上のエントリを含む１以上のカラムのデータを圧縮するよう修正された順序保存型圧縮スキームを適用し、
追加の１以上のエントリを含むリレーショナルデータベーステーブルの各エントリのそれぞれのインデックス値を更新するために、１以上のカラムのうちの特定の１つのカラムの再圧縮データに少なくとも一部基づいて、前述のリレーショナルデータベーステーブルのマルチカラムインデックスの生成を行う
ことを実行させる、第１６項に記載の非一時的コンピュータ可読記憶媒体。
（第１８項）
プログラム命令はさらにデータベースシステムに、
再圧縮データに少なくとも一部基づいてリレーショナルデータベーステーブルのマルチカラムインデックスを生成する動作の間、読取要求を処理するためにマルチカラムインデックスを維持し、
再圧縮データに少なくとも一部基づいたリレーショナルデータベーステーブルのマルチカラムインデックスの生成の完了にあたり、再圧縮データに少なくとも一部基づいたマルチカラムインデックスの更新されたインデックス値に少なくとも一部基づいて読取要求を処理する
ことを実行させる、第１７項に記載の非一時的コンピュータ可読記憶媒体。
（第１９項）
前述の少なくとも２つのカラムのうちの１以上のカラムのデータを圧縮するための順序保存型圧縮スキームの適用において、プログラム命令はさらにデータベースシステムに、１以上の追加エントリごとの値を表すために追加データビットを追加することを実行させる、第１６項に記載の非一時的コンピュータ可読記憶媒体。
（第２０項）
少なくとも２つのカラムのうちの１以上のカラムのデータを圧縮するための順序保存型圧縮スキームの適用において、プログラム命令はデータベースシステムに、カラムデータ階層に従って１以上のカラムのうちの特定の１つのカラムのデータをグループ化するために、１以上のカラムのうちの特定の１つのカラムに対しカラムデータ階層を適用することを実行させ、カラムデータ階層はリレーショナルデータベーステーブルの１以上の他のカラムを基に決定される、第１５項に記載の非一時的コンピュータ可読記憶媒体。
（第２１項）
リレーショナルデータベーステーブルの各エントリのそれぞれのインデックス値はソートキー値であり、リレーショナルデータベーステーブルのエントリはリレーショナルデータベーステーブルのエントリのソートキー値に従ってソートされ、リレーショナルデータベーステーブルのエントリは複数のデータブロックに持続的に記憶され、プログラム命令はデータベースシステムにさらに、
１以上のデータブロックごとに記憶されたエントリのソートキー値に対応するマルチカラムソートキー値範囲を示すメタデータを保持し、
選択データに関して、少なくとも２つのカラムのうちの１以上のカラムに対する、またはリレーショナルデータベーステーブルの１以上の他のカラムのうちの１以上のカラムに対するクエリの指示を受信し、
選択性用データビットインターリーブに少なくとも一部基づいて、特定された２つのカラムから、選択データを特定する１以上の述語データ値を決定するために、クエリの指示を評定し、
クエリの指示の受信及び評定に応じて、
選択データに関するクエリを処理する際、複数のデータブロックのうち読取る必要のある特定ブロックを特定するために、１以上のデータブロックごとに、１以上の述語データ値に関して、マルチカラムソートキー値範囲を分析する
ことを実行させる、第２０項に記載の非一時的コンピュータ可読記憶媒体。
（第２２項）
リレーショナルデータベーステーブルの各エントリのそれぞれのインデックス値は分散キー値であり、前述のリレーショナルデータベーステーブルのエントリを各エントリのそれぞれのインデックス値に従って記憶するように指示することにおいて、プログラム命令はデータベースシステムに、持続させるリレーショナルデータベーステーブルのエントリを、リレーショナルデータベーステーブルのエントリの分散キー値に少なくとも一部基づいて、複数の異なる永続的ストレージデバイスに分散的に配置することを実行させる、第１４項に記載の非一時的コンピュータ可読記憶媒体。

【0081】

本明細書で図示及び記述された様々な方法は、方法の例示的実施形態を表す。方法は、ソフトウェア、ハードウェア、またはこれらの組合せにおいて実行されうる。方法の順序は変更され、そして様々な要素が追加、並替、結合、省略、修正等されうる。

【0082】

本開示の恩恵を受ける当業者に明らかであろう様々な修正及び変更が行われうる。本発明は全てのこのような修正及び変更を包含し、従って前述の説明は制限的な意味ではなく実例的な意味としてみなされるものとする。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】