特許 6870071 テーブルのインクリメンタルクラスタリング保守

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

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

(11)【特許番号】6870071

(24)【登録日】2021年4月16日

(45)【発行日】2021年5月12日

(54)【発明の名称】テーブルのインクリメンタルクラスタリング保守

(51)【国際特許分類】

   G06F 16/906 20190101AFI20210426BHJP

   G06F 16/20 20190101ALI20210426BHJP

【ＦＩ】

   G06F16/906

   G06F16/20

【請求項の数】30

【全頁数】36

(21)【出願番号】特願2019-511705(P2019-511705)

(86)(22)【出願日】2017年9月5日

(65)【公表番号】特表2019-530068(P2019-530068A)

(43)【公表日】2019年10月17日

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

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

(87)【国際公開日】20180308

【審査請求日】2019年11月21日

(31)【優先権主張番号】62/383,201

(32)【優先日】2016年9月2日

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

(73)【特許権者】

【識別番号】516245999

【氏名又は名称】スノーフレーク インク．

(74)【代理人】

【識別番号】100074099

【弁理士】

【氏名又は名称】大菅 義之

(74)【代理人】

【識別番号】100121083

【弁理士】

【氏名又は名称】青木 宏義

(74)【代理人】

【識別番号】100138391

【弁理士】

【氏名又は名称】天田 昌行

(74)【代理人】

【識別番号】110000132

【氏名又は名称】大菅内外国特許事務所特許業務法人

(72)【発明者】

【氏名】クルアネス，ティエリー

(72)【発明者】

【氏名】ズコウスキー，マーシン

(72)【発明者】

【氏名】ダジュヴィル，ブノワット

(72)【発明者】

【氏名】ヤン，ジァチー

【審査官】 吉田 誠

(56)【参考文献】

【文献】 米国特許第０５９６０４３１（ＵＳ，Ａ）

【文献】 特開２０１４−２２５２６０（ＪＰ，Ａ）

【文献】 特開２０１３−０８０４０３（ＪＰ，Ａ）

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

Ｇ０６Ｆ １６／００−１６／９５８

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

【請求項1】

コンピュータにより実行されるデータベースデータのクラスタリングのための方法であって、前記方法は、
テーブルのためのテーブルデータを複数のパーティションに記憶することであって、各パーティションが前記テーブルのための前記テーブルデータの一部を含み、前記パーティションは前記テーブル内の１つ以上の属性に基づいて少なくとも部分的にクラスタリングされることと、
前記テーブルへの変更に基づいて１つ以上の新規パーティションを作成することと、
前記１つ以上の新規パーティションを作成した後、前記１つ以上の新規パーティションの少なくとも１つと他のパーティションとの間で１つ以上の属性値が重複することに基づいて前記テーブルのクラスタリングの度合いを判別することであって、前記他のパーティションは前記１つ以上の新規パーティションを作成する前に前記テーブルに既に存在する先のパーティションを含み、前記重複することは前記テーブルのクラスタリングの前記度合いの低下を招く、ことと、
前記テーブルのクラスタリングの前記度合いがクラスタリング閾値を下回っていることを判別することと、
前記テーブルのクラスタリングの前記度合いが前記クラスタリング閾値を下回っていることを判別することに応答して、前記テーブルの１つ以上のパーティションを再クラスタリングして前記テーブルのクラスタリングの前記度合いを増加させることと、
を備える。

【請求項2】

請求項１に記載の方法であって、前記テーブルのクラスタリングの前記度合いを判別することは、
いくつのパーティションが、前記テーブルの他のパーティションと前記１つ以上の属性値が重複しているか、
前記テーブルの他のパーティションとの１つ以上のパーティションの前記１つ以上の属性値の重複の度合い、
前記１つ以上の属性値に対していくつのパーティションが重複しているか、
前記パーティションの各個別の深さ、
前記パーティションの深さの分布、及び、
前記パーティションの平均深さであって、前記深さは前記１つ以上の属性に対する特定の属性値について重複するパーティションの数を含む、前記パーティションの平均深さ、
の１つ以上に基づく。

【請求項3】

請求項１に記載の方法であって、前記テーブルのクラスタリングの前記度合いが前記クラスタリング閾値を下回っていることを判別することが、前記テーブル上のデータ操作言語（ＤＭＬ）文の量、頻度、若しくは種類、又は前記テーブルに追加された新規データの量を判別することを備える。

【請求項4】

請求項１に記載の方法であって、前記テーブルのクラスタリングの前記度合いが前記クラスタリング閾値を下回っていることを判別することが、サンプルクエリ（example query）の実行時間がクエリ実行時間閾値を超えることを判別することを備える。

【請求項5】

請求項１に記載の方法であって、前記テーブルのクラスタリングの前記度合いが前記クラスタリング閾値を下回っていることを判別することは、コンパイル中のプルーニングの有効性、及び実行中のフィルタ選択性に基づく。

【請求項6】

請求項１に記載の方法であって、再クラスタリングは２つ以上のパーティションをマージ候補として選択することを備える。

【請求項7】

請求項６に記載の方法であって、前記２つ以上のパーティションを前記マージ候補として選択することは、
前記１つ以上の属性に対して重複する値を含む２つ以上のパーティション、
前記２つ以上のパーティションにおける前記値が重複する度合い、
選択されたパーティションの深さ、
選択されたパーティションの分布、
パーティションが再クラスタリングされた回数、
リソースのバジェット、
前記２つ以上のパーティションによってカバーされる前記１つ以上の属性に対応する値の幅、及び、
前記１つ以上の属性に基づいてパーティションが理想的にクラスタリングされているか否か、
の１つ以上に基づいて選択することを備える。

【請求項8】

請求項６に記載の方法であって、前記２つ以上のパーティションを前記マージ候補として選択することは、
前記１つ以上の属性の値が前記テーブル内のどの他のパーティションとも重複せず、又は、
前記テーブル内のどの他のパーティションとも、前記値の重複が重複閾値よりも多くない、
パーティションを選択しないことを備える。

【請求項9】

請求項６に記載の方法であって、前記２つ以上のパーティションを前記マージ候補として選択することは、前記１つ以上の属性に対して同一の値を有するロウの値を含むパーティションを選択しないことを備える。

【請求項10】

請求項１に記載の方法であって、再クラスタリングは、インクリメンタルに前記テーブルのクラスタリングの前記度合いを増加することを備える。

【請求項11】

請求項１に記載の方法であって、再クラスタリングは、再クラスタリングリソースバジェット、パーティションの数、データサイズ、及び利用可能なコンピューティングリソースの１つ以上に基づいて再クラスタリングすることを備える。

【請求項12】

請求項１に記載の方法であって、再クラスタリングは、２つ以上のパーティションをマージして増加したクラスタリングを有する１つ以上のパーティションを生成することを備える。

【請求項13】

請求項１に記載の方法であって、前記テーブルに対する前記変更の前及び後の両方で、前記テーブルは理想的にはクラスタリングされておらず、理想的なクラスタリングは、
前記パーティションが前記１つ以上の属性に対応する値の範囲内で１つ以上の他のパーティションと重複しないことを含むこと、及び、
前記１つ以上の属性の属性についての前記パーティションの全てのロウが同じ値を含むこと、
の１つ以上が前記テーブルの前記パーティションの各々に当てはまることを備える。

【請求項14】

データベースデータのインクリメンタルクラスタリング保守のためのシステムであって、前記システムは、
１つ以上のプロセッサと、
命令を記憶するコンピュータ読取り可能記憶媒体であって、前記命令は、１つ以上のプロセッサによって実行されたときに、前記１つ以上のプロセッサに、
テーブルのためのテーブルデータを複数のパーティションに記憶することであって、各パーティションが前記テーブルのための前記テーブルデータの一部を含み、前記パーティションは前記テーブル内の１つ以上の属性に基づいて少なくとも部分的にクラスタリングされることと、
前記テーブルへの変更に基づいて１つ以上の新規パーティションを作成することと、
前記１つ以上の新規パーティションを作成した後、前記１つ以上の新規パーティションの少なくとも１つと他のパーティションとの間で１つ以上の属性値が重複することに基づいて前記テーブルのクラスタリングの度合いを判別することであって、前記他のパーティションは前記１つ以上の新規パーティションを作成する前に前記テーブルに既に存在する先のパーティションを含み、前記重複することは前記テーブルのクラスタリングの前記度合いの低下を招く、ことと、
前記テーブルのクラスタリングの前記度合いがクラスタリング閾値を下回っていることを判別することと、
前記テーブルのクラスタリングの前記度合いが前記クラスタリング閾値を下回っていることを判別することに応答して、前記テーブルの１つ以上のパーティションを再クラスタリングして前記テーブルのクラスタリングの前記度合いを増加させることと、
を引き起こさせるものと、
を備える。

【請求項15】

請求項１４に記載のシステムであって、前記命令は、前記１つ以上のプロセッサに、
いくつのパーティションが、前記テーブルの他のパーティションと前記１つ以上の属性値が重複しているか、
前記テーブルの他のパーティションとの１つ以上のパーティションの前記１つ以上の属性値の重複の度合い、
１つ以上の属性値に対していくつのパーティションが重複しているか、
前記パーティションの各個別の深さ、
前記パーティションの深さの分布、及び、
前記パーティションの平均深さであって、前記深さは前記１つ以上の属性に対する特定の属性値について重複するパーティションの数を含む、前記パーティションの平均深さ、
の１つ以上に基づいて前記テーブルのクラスタリングの前記度合いを判別することを引き起こさせる。

【請求項16】

請求項１４に記載のシステムであって、前記命令は、前記１つ以上のプロセッサに、サンプルクエリ（example query）の実行時間がクエリ実行時間閾値を超えることを判別することによって、前記テーブルのクラスタリングの前記度合いが前記クラスタリング閾値を下回っていることを判別することを引き起こさせる。

【請求項17】

請求項１４に記載のシステムであって、前記コンピュータ読取り可能記憶媒体は、２つ以上のパーティションをマージ候補として選択することによって前記パーティションの再クラスタリングを前記１つ以上のプロセッサに引き起こさせる命令を更に記憶する。

【請求項18】

請求項１７に記載のシステムであって、前記命令は、前記１つ以上のプロセッサに、
前記１つ以上の属性に対して重複する値を含む２つ以上のパーティション、
前記２つ以上のパーティションにおける前記値が重複する度合い、
選択されたパーティションの深さ、
選択されたパーティションの分布、
パーティションが再クラスタリングされた回数、
リソースのバジェット、
前記２つ以上のパーティションによってカバーされる前記１つ以上の属性に対応する値の幅、及び、
前記１つ以上の属性に基づいてパーティションが理想的にクラスタリングされているか否か、
の１つ以上に基づいて選択することによって、前記２つ以上のパーティションを前記マージ候補として選択することを引き起こさせる。

【請求項19】

請求項１７に記載のシステムであって、前記命令は、前記１つ以上のプロセッサに、
前記１つ以上の属性の値が前記テーブル内のどの他のパーティションとも重複せず、又は、
前記テーブル内のどの他のパーティションとも、前記値の重複が重複閾値よりも多くない、
パーティションを選択せずに、前記２つ以上のパーティションを前記マージ候補として選択することを引き起こさせる。

【請求項20】

請求項１７に記載のシステムであって、前記命令は、前記１つ以上のプロセッサに、前記１つ以上の属性に対して同一の値を有するロウの値を含むパーティションを選択せずに、前記２つ以上のパーティションを前記マージ候補として選択することを引き起こさせる。

【請求項21】

請求項１４に記載のシステムであって、前記命令は、前記１つ以上のプロセッサに、インクリメンタルに前記テーブルのクラスタリングの前記度合いを増加することによって再クラスタリングさせることを引き起こさせる。

【請求項22】

請求項１４に記載のシステムであって、前記命令は、前記１つ以上のプロセッサに、再クラスタリングリソースバジェット、パーティションの数、データサイズ、及び利用可能なコンピューティングリソースの１つ以上に基づいて１つ以上のパーティションを再クラスタリングすることを引き起こさせる。

【請求項23】

請求項１４に記載のシステムであって、前記命令は、前記１つ以上のプロセッサに、２つ以上のパーティションをマージして増加したクラスタリングを有する１つ以上のパーティションを生成することによって再クラスタリングすることを引き起こさせる。

【請求項24】

請求項１４に記載のシステムであって、前記テーブルに対する前記変更の前及び後の両方で、前記テーブルは理想的にはクラスタリングされておらず、理想的なクラスタリングは、
前記パーティションが前記１つ以上の属性に対応する値の範囲内で１つ以上の他のパーティションと重複しないことを含むこと、及び、
前記１つ以上の属性の属性についての前記パーティションの全てのロウが同じ値を含むこと、
の１つ以上が前記テーブルの前記パーティションの各々に当てはまることを備える。

【請求項25】

データベースデータのインクリメンタルクラスタリング保守のためのシステムであって、前記システムは、
テーブルのためのテーブルデータを複数のパーティションに記憶するための手段であって、各パーティションが前記テーブルのための前記テーブルデータの一部を含み、前記パーティションは前記テーブル内の１つ以上の属性に基づいて少なくとも部分的にクラスタリングされるものと、
前記テーブルへの変更に基づいて１つ以上の新規パーティションを作成するための手段と、
前記１つ以上の新規パーティションを作成した後、前記１つ以上の新規パーティションの少なくとも１つと他のパーティションとの間で１つ以上の属性値が重複することに基づいて前記テーブルのクラスタリングの度合いを判別するための手段であって、前記他のパーティションは前記１つ以上の新規パーティションを作成する前に前記テーブルに既に存在する先のパーティションを含み、前記重複することは前記テーブルのクラスタリングの前記度合いの低下を招くものと、
前記テーブルのクラスタリングの前記度合いがクラスタリング閾値を下回っていることを判別するための手段と、
前記テーブルのクラスタリングの前記度合いが前記クラスタリング閾値を下回っていることを判別することに応答して、前記テーブルの１つ以上のパーティションを再クラスタリングして前記テーブルのクラスタリングの前記度合いを増加させるための手段と、
を備える。

【請求項26】

請求項２５に記載のシステムであって、前記テーブルのクラスタリングの前記度合いを判別するための前記手段は、
いくつのパーティションが、前記テーブルの他のパーティションと前記１つ以上の属性値が重複しているか、
前記テーブルの他のパーティションとの１つ以上のパーティションの前記１つ以上の属性値の重複の度合い、
１つ以上の属性値に対していくつのパーティションが重複しているか、及び、
前記パーティションの平均深さであって、前記深さは前記１つ以上の属性に対する特定の属性値について重複するパーティションの数を含むこと、
の１つ以上に基づいて前記テーブルのクラスタリングの前記度合いを判別する。

【請求項27】

請求項２５に記載のシステムであって、前記テーブルのクラスタリングの前記度合いが前記クラスタリング閾値を下回っていることを判別するための前記手段は、サンプルクエリ（example query）の実行時間がクエリ実行時間閾値を超えることを判別することによって前記テーブルのクラスタリングの前記度合いが前記クラスタリング閾値を下回っていることを判別する。

【請求項28】

請求項２５に記載のシステムであって、再クラスタリングのための前記手段は、２つ以上のパーティションをマージ候補として選択するための手段を備える。

【請求項29】

請求項２５に記載のシステムであって、再クラスタリングのための前記手段は、インクリメンタルに前記テーブルのクラスタリングの前記度合いを増加する。

【請求項30】

請求項２５に記載のシステムであって、前記テーブルに対する前記変更の前及び後の両方で、前記テーブルは理想的にはクラスタリングされておらず、理想的なクラスタリングは、
前記パーティションが前記１つ以上の属性に対応する値の範囲内で１つ以上の他のパーティションと重複しないことを含むこと、又は、
前記１つ以上の属性の属性についての前記パーティションの全てのロウが同じ値を含むこと、
の１つ以上が前記テーブルの前記パーティションの各々に当てはまることを備える。

【発明の詳細な説明】

【技術分野】

【0001】

＜関連出願の参照＞
本特許出願は、２０１６年９月２日出願の名称「ＩＮＣＲＥＭＥＮＴＡＬ ＣＬＵＳＴＥＲ ＭＡＩＮＴＥＮＡＮＣＥ ＯＦ Ａ ＴＡＢＬＥ」の米国仮特許出願番号６２／３８３，２０１に対して優先権を主張し、この出願は、参照によりその全体が本明細書に組み込まれる。

【0002】

本開示はデータベースに関し、より詳細には、データベース又はテーブル内のデータのインクリメンタルクラスタリング保守に関する。

【図面の簡単な説明】

【0003】

本開示の非限定的かつ非網羅的な実施例は、以下の図を参照して説明されるが、同じ参照番号は、特に断りのない限り、様々な図を通して、同じ又は類似の部分を指す。本開示の利点は、以下の説明及び添付図面に関して、よりよく理解されるであろう。

【0004】

【図1】本明細書に記載されるシステム及び方法の例示的実施形態に係るデータベースシステムのための処理プラットフォームを示すブロック図である。

【図2】一実施形態によるデータベースサービスマネージャのコンポーネントを示すブロック図である。

【図3】一実施形態による、テーブルの論理構造を示す模式図である。

【図4】一実施形態による、メモリ内の図３のテーブルの物理構造を示す模式図である。

【図5】一実施形態による、重なり方がテーブルのクラスタリング率にどのように影響を及ぼすかの単純化された見え方を示す模式図である。

【図6】一実施形態による、再クラスタリング後のメモリ内の図３のテーブルの物理構造を示す模式図である。

【図7】一実施形態による、クラスタリング保守モジュールのコンポーネントを示す模式的ブロック図である。

【図8】一実施形態による、インクリメンタルクラスタリング保守の方法を示す模式的フローチャート図である。

【図9】本明細書に開示されている１つ以上の実施形態と一致する、コンピューティング装置又はシステムの実施例を示すブロック図である。

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

【0005】

データベースは、コンピューティングアプリケーションにおけるデータ記憶及びアクセスに広く使用されている。データベースは、クエリを用いて読み出し、変更し、又は削除することができるデータを含み又は参照する、１つ以上のテーブルを含むことができる。大規模なデータベース及び／又はテーブルに対してクエリを行うには、大量のデータをスキャンする必要がある。スキャンされるデータの量を減らすことは、データ組織化及び処理の主な課題の１つである。

【0006】

我々は、テーブルを、レコード（ロウ）の集合として定義する。各レコードは、テーブル属性（カラム）の値の集合を含む。通常、テーブルは、例えばファイル又はブロックの複数の小さい（可変サイズ又は固定サイズの）記憶単位に、物理的に記憶される。これらのファイル又はブロックは、テーブルの異なるパーティションの一部である可能性がある。我々は、パーティショニングを、異なるデータを持つレコードを、異なるデータパーティションに、物理的に分離することと定義する。例えば、テーブルは、日付属性（又はカ
ラム）に基づいてデータを分割して１日毎のパーティションを作成したり、又は、国の属性（又はカラム）に基づいて国毎のパーティションを作成したりできる。

【0007】

データウェアハウスシステムは、これらの大きなテーブルを管理可能なデータのチャンクに分割するために、パーティショニングを日常的に使用する。クエリで指定された述語に基づいてパーティションを削ること（パーティションプルーニング）ができることは、ＩＯボリュームの劇的な減少をもたらし、それらのシステムの満足な性能を保守するために重要である。

【0008】

従来、静的パーティショニングはデータウェアハウス領域で使用されてきた。パーティションサポートの例としては、Ｏｒａｃｌｅ（米国登録商標）パーティショニング（例えば、https://www.oracle.com/database/partitioning/index.htmlの「Ｏｒａｃｌｅ Ｐ
ａｒｔｉｔｉｏｎｉｎｇ」を参照）、Ｈｉｖｅ（米国登録商標）パーティショニング（例えば、https://www.brentozar.com/archive/2013/03/introduction-to-hive-partitioningの「Ａｎ Ｉｎｔｒｏｄｕｃｔｉｏｎ ｔｏ Ｈｉｖｅ’ｓ Ｐａｒｔｉｔｉｏｎｉｎ
ｇ」を参照）、ＳＱＬ Ｓｅｒｖｅｒ（米国登録商標）テーブルパーティショニング（例えば、https://technet.microsoft.com/en-us/library/cc966457.aspxの「Ｓｔｒａｔｅ
ｇｉｅｓ ｆｏｒ Ｐａｒｔｉｔｉｏｎｉｎｇ Ｒｅｌａｔｉｏｎａｌ Ｄａｔａ Ｗａｒｅｈｏｕｓｅ ｉｎ Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒ」を参照）、及びＴｅｒａｄａｔａ（米国登録商標）パーティショニング（例えば、http://www.dwhpro.com/teradata-partitioned-primary-indexの「Ｔｈｅ Ｔｅｒａｄａｔａ Ｐａｒｔｉｔｉｏｎｅｄ Ｐｒｉｍａｒｙ Ｉｎｄｅｘ（ＰＰＩ）」を参照）を含む。

【0009】

多くの場合、大きなテーブルは、データベース管理者によって手動で指定されるようにして、パーティショニングされる。例えば、管理者は、パーティションの数及び／又はパーティショニングキーを指定することができる。ただし、これらの詳細を手動で指定するには、管理者は正しいパーティショニングキーを選択するためのクエリ工数（query workload）の十分な理解を有している必要がある。また、パーティショニングキーの数は、物理記憶の断片化に直接変換されるため、通常は制限される。更に、パーティションを保守することは、通常、計算能力と時間の点で非常に高価である。

【0010】

パーティショニングに関連する概念は、クラスタリング又は順序付けである。（順序付けキー属性又はカラムのセットを用いた）順序付けは、これらのキー属性の値に従ってデータを順序付ける。クラスタリングは、互いに近接している値を持つ互いに物理的にグループとなっているレコード（又はロウ）として定義できる。例えば、同じキーを共有するロウは、互いに隣接して配置されるようにすることができる。キーのセットに基づいた順序付けは、それらのキーに基づくクラスタリングを実現するための一般的な方法である。同じキーを共有している値は相互に隣接していてもかまわないが、同じキー又は近いキーを共有しているグループは隣接している必要はない。今後、「クラスタリング」又は「部分的な順序付け」の用語又は概念も適用できる「順序付け」という用語を使用する場合がある。これらの概念は、別々の物理実体を導入しないため、パーティショニングとは異なり、テーブル全体又は例えばパーティション内などのデータを順序付けることが可能である。

【0011】

データが順序付けられるとき、パーティショニングと同様の利点を提供するために使用できる方法と構成がある。例えば、ゾーンマップ（「最小最大インデックス」又は「スモールマテリアライズトアグリゲート」としても知られている）は、属性クラスタリング又は並替えとともに、多くのパーティショニングのベネフィットを達成するためのもう１つの手段である。例として、（http://www.ibm.com/support/knowledgecenter/SSULQD_7.2.0/com.ibm.nz.adm.doc/c_sysadm_zone_maps.html）の「Ｚｏｎｅ Ｍａｐｓ」及び（http
s://docs.oracle.com/database/121/DWHSG/zone_maps.htm#DWHSG9357）の「Ｚｏｎｅ Ｍａｐｓ ａｎｄ Ａｔｔｒｉｂｕｔｅ Ｃｌｕｓｔｅｒｉｎｇ」を参照されたい。しかしながら、これらのシステム又は方法は、基になるデータのクラスタリングを保守又は最適化しようとしないか、基になるテーブルの全体的で完全な再クラスタリングを必要とする。

【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】

【数1】

【0049】

式1は、クラスタリング比率のために［０，１］の範囲を提供することが保証されてい
る。この値は、所望のスケールを得るために数字を掛けることができる（例えば、１００を乗算して０〜１００のスケールを得る）。

【0050】

いくつかの実施形態では、１００のクラスタリング比率は理論的には可能であるが、最適なクエリ性能を達成するために必要ではないことに注意されたい。単一のマイクロパーティション又はマイクロパーティション無し（つまり空のテーブル）で構成されるテーブルは、常に１００のクラスタリング比率を有する。一実施形態では、クラスタリング比率の最小値は０であり、任意の負の比率は０に丸められる。負の比率は、重複するマイクロパーティションの数が、テーブルのマイクロパーティションの総数に対して高い場合に、発生し得る。

【0051】

テーブルのクラスタリング比率は、テーブルが十分にクラスタリングされているかどうかの絶対的又は正確な尺度ではない場合がある。それは、特定のテーブル内のデータ記憶を最適化するためのガイドラインとして意図された相対値である場合がある。テーブルのデータ特性に依存してそれぞれのテーブルとデータクラスタリングのシナリオは異なるため、クラスタリング比率はテーブル間の比較としては役に立たない場合がある。つまり、テーブルが他のテーブルよりも高い比率を有する場合、必ずしも１番目のテーブルが２番目のテーブルよりも良好にクラスタリングされていることを示しているとは限らない。究極的には、クエリ性能がしばしば、テーブルがどの度合い適切にクラスタ化されているかを示す最適な指標になる。テーブル上でクエリが必要に応じて又は期待通りに実行されている場合は、テーブルが十分にクラスタリングされている可能性が高く、それに続く再クラスタリングが大幅に比率を変更したり性能を改善させたりしない可能性がある。クエリ性能が時間の経過と共に低下し、テーブルのクラスタリング比率が低下する場合、テーブルはもはや最適にクラスタリングされていない可能性が高く、再クラスタリングのメリットを享受できる。

【0052】

図５は、パーティション間の重複の度合いがクラスタリング比率にどのように影響するかの簡略化された見え方を示す模式図である。５つのマイクロパーティションで構成されるテーブルの重複は、重複するマイクロパーティションの数、重複の深さ、及びクラスタリングの比率に対する統計とともに、様々な段階で示される。テーブルは、ＡからＺまでの範囲の値を含むカラム上でクラスタリングされている。最初の状態では、全てのマイクロパーティションの値の範囲が重なり、クラスタリングの比率が低くなる（３０．１）。重複するマイクロパーティションの数が減り、重複の深さが第２の状態と第３の状態で減少すると、クラスタリングの比率が向上する（７１．４及び８１．９）。全てのマイクロパーティション間の値の範囲に重複がない場合、マイクロパーティションは一定の状態に（つまり再クラスタリングでは改善できなく)なると見なされ、テーブルは１００のクラ
スタリング比率を有する。この４番目の状態では、テーブルは完全にクラスタ化されていると見なされる。

【0053】

一実施形態では、クラスタリング保守モジュール２３０によって実行されるインクリメンタルクラスタリングは、第１ステップから第２ステップへなどのようなクラスタリングのインクリメンタルな改善をもたらすプロセスを実行することができる。従って、クラスタリングにおいてインクリメンタルな改善が達成される場合もあれば、（他のＤＭＬなどのような）その他の変更が常にテーブルに対して実行されている場合でも、望ましいレベルのクラスタリングが保持されるようにすることができる。

【0054】

多くの場合、自然クラスタリングはテーブル内で良好にクラスタリングされたデータを生成する。しかしながら、時間の経過と共に、特にＤＭＬが発生した場合、一部のテーブルのロウのデータは、必要なディメンションで自然にクラスタリングされない。基になる
マイクロパーティションの自然なクラスタリングを改善するために、ユーザはロウを重要なカラム上で並べ替えてテーブルに再挿入したいと思うかもしれない。しかしながら、（ロウの数ではなくテーブル内のデータのサイズによって定義される）非常に大きなテーブルに対しては、この手動操作はコストが高く、扱いにくい可能性がある。ここで少なくとも一実施形態は、ユーザがテーブル上の１つ以上のカラム／式に対してクラスタリングキーを指定することを可能にする。

【0055】

クラスタリングキーはフィルタリングをより効率的にするかもしれないが、全てのテーブルが必ずしもクラスタリングキーの恩恵を受けるわけではない。クラスタリングキーからの性能の改善を確認するには、テーブルが１つ以上のマイクロパーティションに存在するのに十分な大きさでなければならず、クラスタリングキーが、これらのマイクロパーティションのサブセットを選択するために、十分なフィルタリングを提供しなければならない。いくつかの実施形態では、マルチテラバイト（ＴＢ）サイズ範囲のテーブルは、特にテーブルが顕著な量のＤＭＬコマンドを経験する場合、クラスタリングキーからの最も大きな利点がわかるであろう。

【0056】

一実施形態では、クラスタリングキーは、同じマイクロパーティション内でデータを同じ場所に置くために明示的に指定されるテーブル上のカラム又は式のサブセットである。クラスタリングキーは、（ＣＲＥＡＴＥ ＴＡＢＬＥコマンドを使用して）テーブルを作成する時、又は（ＡＬＴＥＲ ＴＡＢＬＥコマンドを使用して）以後に、定義されるようにすることができる。クラスタリングキーは、いつでも変更又は削除されるようにすることができる。非常に大きなテーブルに対してクラスタリングキーを定義することが役立つかどうかを判別するためのいくつかの一般的な指標は、テーブル上のクエリが予想より遅く実行されており又は時間の経過とともに著しく性能が低下していること、及び／又は、テーブルのクラスタリング比率が非常に低くクラスタリングの深さが非常に高くなっていること、を含む。少なくとも一実施形態では、ユーザが既存のテーブルに対してクラスタリングキーを定義した場合（又はテーブルに対して既存のクラスタリングキーを変更した場合）、テーブル内のロウは、ＡＬＴＥＲ ＴＡＢＬＥコマンドを使用してテーブルが再クラスタリングされるまで、再編成されない。同じマイクロパーティション内で類似のロウを同じ場所に置くことがフィルタ述語に一致しない大量のデータをスキップすることによりクエリにおけるスキャン効率を改善すること、同じマイクロパーティション内で類似のロウを同じ場所に置くことが一般的にクラスタリングキーが無いテーブルにおける場合よりも良好なカラム圧縮を可能にすること、このことは特に他のカラムがクラスタリングキーと強く関連性があるときに確実であること、及び／又は、ひとたび定義されればクラスタリングキーは少ししか又は全く保守を必要としないこと、を含むいくつかの利点を提供することができる。

【0057】

適切なクラスタリングキーを選択することは、クエリ性能に劇的な影響を及ぼす可能性がある。作業負荷の分析は、通常、理想的なクラスタリングキー候補をいくつか生成するであろう。例えば、クエリが通常、日付カラムなどの１つのカラム上でフィルタ処理される場合、そのカラムはテーブルのクラスタリングキーとして適切な候補になる可能性がある。同様に、クエリは通常、ａｐｐｌｉｃａｔｉｏｎ＿ｉｄやｕｓｅｒ＿ｉｄカラムなどの２つのディメンションによってテーブル上で実行されるため、それらのカラム上でのクラスタリングは、テーブルのクエリ性能を改善するのに役立つことができる。少なくともいくつかの実施形態では、クラスタリングキーにおける明瞭値（すなわち基数）の数は、クラスタリングキーを選択することの重要な側面である。テーブル上でのプルーニングを効果的にすることのできる十分に多数の明瞭値を有し、システムが同じマイクロパーティション内でロウを効率的にグループ化することを可能にするように十分に少数の明瞭値を有するクラスタリングキーを選択することが重要であるようにすることができる。非常に低い基数カラム（性別の値を含むカラムなど）は、最小限のプルーニングのみを生成する
。対照的に、非常に高い基数カラム（例えば、タイムスタンプ又はＵＵＩＤ値を含むカラム）は、クラスタリングの維持にコストがかかる可能性がある。原則として、最低の基数から最高の基数までのキーをオーダーすることが推奨される。カラムの基数が非常に大きい場合、多くの場合、クラスタリングキーとして直接使用するのは適切ではない。例えば、ファクトテーブルは、（テーブル内のマイクロパーティションの数よりも多く）多くの不連続な値を含むタイムスタンプカラムｃ＿ｔｉｍｅｓｔａｍｐを有するかもしれない。そのカラムは引き続きクラスタリングキーとして使用できるが、そのカラムに定義された式となるクラスタリングキーを用いると、明瞭値の数が減少する。例えば、ｃ＿ｔｉｍｅｓｔａｍｐカラム上では、タイムスタンプではなく日付に値をキャストすることによって（例えば、ｔｏ＿ｄａｔｅ（ｃ＿ｔｉｍｅｓｔａｍｐ））、クラスタリングキーを定義できる。これにより合計日数に対する明瞭値が減少するが、これはプルーニングのためにはるかに優れている。

【0058】

一実施形態では、クラスタリング保守モジュール２３０は、ＲＥＣＬＵＳＴＥＲ句を有するＡＬＴＥＲ ＴＡＢＬＥコマンドを使用して、いつでもクラスタリングキーを有するテーブルを手動で再クラスタリングすることをサポートする。このコマンドは、関連レコードが同じマイクロパーティションに再配置されるように、クラスタリングキーに基づいてテーブルに対するレコードを編成する。このＤＭＬ操作は、移動されるべき全てのレコードを削除し、クラスタリングキー上でグループ化されるそれらを再挿入する。任意のＤＭＬ操作の場合と同様に、この操作は、その操作の間、テーブルをロックすることがある。また、再クラスタリングのための記憶コストもある。データが再クラスタリングされるたびに、ロウはクラスタリングキーに基づいて物理的にグループ化され、その結果、システムはそのデータ用の新規マイクロパーティションを生成する。テーブルにたとえ少数のロウを追加することであっても、それらの値を含む全てのマイクロパーティションが再作成される可能性がある。

【0059】

図６は、テーブル３００（図３）の物理構造４００（図４）に関連する再クラスタリングされたパーティションの物理構造６００を示す模式図である。再クラスタリングされた物理構造６００は、次のようなクエリの実施例 ＳＥＬＥＣＴ ｎａｍｅ，ｃｏｕｎｔｒｙ ＦＲＯＭ ｔ ＷＨＥＲＥ ｉｄ＝２ ＡＮＤ ｄａｔｅ＝‘１１／２’ に関するクエリ性能を向上させるために、テーブルの再クラスタリングがマイクロパーティションのスキャンを減らすのにどのように役立つかを説明している。前述したように、図４でパーティショニングされたテーブル３００は、マイクロパーティション１〜４にわたって日付によって自然クラスタリングされている。図４のクラスタ化状態では、上記のクエリの実施例は、マイクロパーティション１、２、及び３をスキャンする必要がある。日付とｉｄのカラムは、次のような文「ＡＬＴＥＲ ＴＡＢＬＥ ｔ１ ＣＬＵＳＴＥＲ ＢＹ （ｄａｔｅ，ｉｄ）；」を使用してクラスタリングキーとして定義することができる。次に、テーブル３００は、「ＡＬＴＥＲ ＴＡＢＬＥ ｔ１ ＲＥＣＬＵＳＴＥＲ；」という文を用いて再クラスタリングされる。再クラスタリングにおいて、システムは、図６に示されるように、新規マイクロパーティション５〜８を作成する。クラスタリングの後、上記クエリはマイクロパーティション５と６のみをスキャンする必要がある。ロウ２は太破線３０２で示される新規相対位置で示され、ロウ２３は太実線３０４で同じ相対位置に表示される。

【0060】

加えて、再クラスタリングの後、マイクロパーティション５は、一定の状態に達し（即ち、それは再クラスタリングによって改善されず）、そのため、将来の保守のために再クラスタリングの候補として考慮されることから除外される。良好にクラスタリングされた大きなテーブルでは、ほとんどのマイクロパーティションがこのカテゴリに入る。一実施形態では、元のマイクロパーティション（図４の１〜４）は削除済みとしてマークされるようにすることができるが、システムからはパージされないようにすることができる。例
えば、回復又はバージョン管理のために保持されるようにすることができる。この実施例は、非常に小さい規模での再クラスタリングの影響を示している。大きなテーブルの（即ち、数百万のマイクロパーティションから成る）場合、再クラスタリングはスキャンに大きな影響を与え、その結果、クエリ性能を向上させることができる。

【0061】

一実施形態では、明示的な再クラスタリング又は（例えば、テーブルのクラスタリングの度合いの低下によって引き起こされる）自動再クラスタリングは、再クラスタリングプロセスが使用することができるリソースについてのバジェット又は制限が与えられるようにすることができる。例えば、ユーザは、次のようなコマンドを使用して、ＲＥＣＬＵＳＴＥＲ句を有するＡＬＴＥＲ ＴＡＢＬＥコマンドを入力して、クラスタリングキーが定義されているテーブルを手動で再クラスタリングすることができる： ＡＬＴＥＲ ＴＡＢＬＥ ＜ｎａｍｅ＞ ＲＥＣＬＵＳＴＥＲ [ ＭＡＸ＿ＳＩＺＥ＝＜ｂｕｄｇｅｔ＿
ｉｎ＿ｂｙｔｅｓ＞] ［ ＷＨＥＲＥ ＜ｃｏｎｄｉｔｉｏｎ＞ ]。上記ＭＡＸ＿ＳＩＺＥ＝ｂｕｄｇｅｔ＿ｉｎ＿ｂｙｔｅｓは、再クラスタリングするテーブル内のデータ量（バイト単位）の上限を指定する。再クラスタリングするマイクロパーティションがなくなった場合、又はバジェットを超えずに再クラスタリングすることができる場合には、制限に達する前に再クラスタリングが停止するようにすることができる。ＭＡＸ＿ＳＩＺＥが指定されていない場合は、再クラスタリングのために使用される仮想ウェアハウス内で使用可能なリソースに基づいて、システムが自動的にサイズを選択するようにすることができる。例えば、コマンド「ＡＬＴＥＲ ＴＡＢＬＥ ｔ１ ＲＥＣＬＵＳＴＥＲ；」は、このコマンドが実行されているシステムで使用可能なリソースに基づいて、テーブルの再クラスタリングに使用する最適なバジェットを自動的に選択する。ウェアハウスが大きくなればなるほど、再クラスタリングコマンドにより多くのバジェットが与えられ、再クラスタリングはより効果的になる。上記ＷＨＥＲＥ条件は、テーブル内のデータを再クラスタリングするための条件又は範囲を指定する。一実施形態では、再クラスタリングは、クラスタリングキーが定義されているテーブルに対してのみ実行可能である。再クラスタリングキーは、明示的に定義され又は自動的に選択されるカラム又はキーを含むことができる（例えば、システムは、データがどのように読み込まれるか、又は最も一般的なクエリの種類に基づいて、日付、場所、及び／又は、ｉｄカラムを自動的に選択することができる）。

【0062】

図７は、一実施形態による、クラスタリング保守モジュール２３０のコンポーネントを示す概略ブロック図である。クラスタリング保守モジュール２３０は、少なくとも性能を維持するためにテーブルの近似的なクラスタリングを保守するための方法及びアルゴリズムを実装するためのコード、回路等を含むことができる。クラスタリング保守モジュール２３０は、記憶コンポーネント７０２と、新規データコンポーネント７０４と、クラスタリング状態コンポーネント７０６と、パーティション選択コンポーネント７０８と、再クラスタリングコンポーネント７１０とを含む。コンポーネント７０２〜７１０は、実施例としてのみ与えられ、全ての実施形態に全てが含まれなくてもよい。例えば、各コンポーネント７０２〜７１０は、別個の装置又はシステムの一部として含まれ又は実装されてもよい。

【0063】

記憶コンポーネント７０２は、複数のパーティション内のテーブルデータのクラスタリングの記憶及び／又は管理を行うように構成されている。例えば、テーブルのテーブルデータの１つの部分が最初のパーティションに含まれ、テーブルのデータの別の部分が２番目のパーティションに含まれるようにすることができる。パーティション又はクラスタは、同じ又は異なる記憶装置上に配置されるようにすることができる。異なる記憶装置上のデータは同時にアクセスされるようにすることができため、データの異なる部分に関連するクエリは他方が終了するのを待たずに同時にサービスを受けるようにすることができる。

【0064】

一実施形態において、データベース又はテーブルデータは、基礎となるデータのための自然分割、及び／又は管理者、制御プログラムなどのようなユーザからの指示又はルールに基づいて、パーティショニング又はクラスタリングされるようにすることができる。例えば、モノのインターネット（ＩｏＴ）データは、時間単位、日単位、週単位、又はその他の間隔などの定期的な間隔で到来することがある。データ収集の定期的な間隔が、特定の日又は間隔のデータが同じパーティション内に含まれるように、データの自然な分割が提供されるようにすることができる。その他の種類の自然分割は、データの種類、データの場所（例えば、州、郵便番号、市区町村、国など）、データに対応する顧客、又はデータに関するその他のメタデータ又は情報を含む。また、記憶コンポーネント７０２は、データベースサーバマネージャ４０２に、１つ以上の属性に対応する最小及び最大のロウ値を含むメタデータを各パーティションに記憶させることもできる。

【0065】

一実施形態では、自然分割は、システム制限又は管理者仕様に基づいて自動的に選択されるようにすることができる。例えば、システム又は管理者が最大パーティションサイズを指し示している場合、クラスタリング保守モジュール２３０は、そのデータをパーティショニングする方法を自動的に決定する。更なる説明として、ユーザは、データベース又はテーブル内のデータが特定のメトリック又はメタデータ（日付、場所、顧客など）に基づいてクラスタリングされるように指定し、次に、システムがユーザ又はシステムの要件を満たすような方法（例えば、最大パーティションサイズ）でデータを分割する。例えば、データが、どのパーティション又はクラスタも最大パーティションサイズよりも大きくならないように、パーティション又はクラスタに分割されるようにすることができる。

【0066】

新規データコンポーネント７０４は、データベース又はテーブル内の記憶用に新規データを受信するように構成されている。新規データは、データベース又はテーブルによって記憶されるデータ又は情報の種類に対応するデータを含むことができる。例えば、データベース又はテーブルは、センサ又はスマートデバイスからのＩｏＴデータの記憶に使用されるようにすることができる。新規データは、これらのセンサ又はスマートデバイスからのデータを含むことができる。

【0067】

一実施形態では、新規データコンポーネント７０４は、入力してくる新規データのための中間パーティションを作成する。中間パーティションは、記憶コンポーネント７０２によって記憶されるデータのパーティションと同じ規則を使用して生成されるようにすることができる。例えば、データベース又はテーブルが、日付と最大パーティションサイズに基づいてパーティショニング又はクラスタリングされている場合、新規データコンポーネント７０４は、新規データから１つ以上の中間パーティションを作成することができる。その後、中間パーティションは、新規パーティションを作成したり既存のパーティションと組み合わせられたりするようにするために、マージ又は再クラスタリングされようにすることができる。

【0068】

一実施形態では、テーブルへの変更は、新規パーティションにまとめてグループ化されるようにすることができる。例えば、テーブルの１つ以上のＤＭＬ操作に基づいて追加されたデータを含む、１つ以上の新規パーティションが作成されるようにすることができる。これらの変更は、新規パーティションでは、別の新規パーティション又はテーブル内に既に存在する先行するパーティションのいずれかと重複する可能性がある。これらの重複により、テーブルのクラスタリングの度合いが低下する可能性がある。テーブルのクラスタリングの度合いは、少なくとも部分的には、例えば、クラスタリング比率に基づいてもよい。テーブルに対する変更は、ＤＭＬコマンド、又はテーブルデータの少しずつ又は一括のローディングの１つ以上に基づくようにすることができる。

【0069】

クラスタリング状態コンポーネント７０６は、特定のテーブルのパーティションテーブルデータがどの度合いクラスタ化されているかを判別するように構成されている。例えば、本明細書に開示されるシステム、方法、及び実施形態は、テーブル又はデータベースが「十分にクラスタリングされている」という考えを提示する。具体的には、パーティショニング／クラスタリングの利点の多くは、完全にクラスタリングされていない場合でも、テーブルのパーティションを十分にクラスタリングすることによって得られる。しかしながら、時間の経過と共にクラスタリングの品質は低下し、これらの利点は失われる可能性がある。

【0070】

一実施形態において、クラスタリング状態コンポーネント７０６は、クラスタリング比率又は他のメトリックに基づいてデータベース又はテーブルがどの度合い適切にパーティショニングされているかを判別することができる。データベースの現在の状態がクラスタリング又はパーティションの品質を満たしているかどうかを判別するためのアルゴリズムの実施例は、幅深度のアルゴリズム、幅プラス重複しているファイル（パーティション）の数アルゴリズム、又はクラスタリング又はパーティショニング品質のための任意の他のアルゴリズム又はメトリックを含む。以下の「インクリメンタルクラスタリングヒューリスティック」セクションにおけるインクリメンタルクラスタリングヒューリスティックのためのアルゴリズムを参照されたい。一実施形態では、クラスタリング比率又は他のメトリックは、ユーザ又はプログラムによる表示及び変更のために公開されてもよい。従って、ユーザ又はプログラムは、テーブル又はデータベースがどのように良好にクラスタリング又はパーティショニングされるべきかを指定することができる。

【0071】

一実施形態では、クラスタリング状態コンポーネント７０６は、テーブルデータのクラスタリングの度合いがクラスタリング閾値を下回ったことを判別する。クラスタリング閾値は、計算又は測定可能なテーブルの属性の値を含むことができる。例えば、クラスタリングの閾値は、テーブルのクラスタリング比率に基づくようにすることができる。クラスタリング状態コンポーネント７０６は、いくつのパーティションがテーブルの他のパーティションに重複しているか、テーブルの他のパーティションとの１つ以上のパーティションの重複の度合い、１つ以上の属性値に対していくつのパーティションが重複しているかを判別すること、又はテーブルパーティションの平均深さを判別することであって、その深さは１つ以上の属性に対する特定の属性値について重複するパーティションの数を含むこと、のうちの１つ以上に基づいてクラスタリングの度合い（例えば、クラスタリング閾値）を判別することができる。クラスタリング状態コンポーネント７０６はまた、サンプル（example）クエリ（例えば、一般的に実行されるクエリや、管理者がクラスタリング
のテストとして指定したクエリ）及びそのクエリがどのくらいの時間を取るかに対する閾値時間に基づいて、クラスタリングの度合いを判別するようにすることもできる。クラスタリング状態コンポーネント７０６は、サンプル（example）クエリの実行時間がクエリ
実行長閾値を超えることを判別するようにすることができる。一実施形態では、クラスタリング状態コンポーネント７０６は、リソースが利用可能な場合に、バックグラウンドプロセスの一部として、テーブルデータのクラスタリングの度合いがクラスタリング閾値を下回っているかどうかを、周期的又は断続的に判別するようにすることができる。

【0072】

パーティション選択コンポーネント７０８は、２つ以上のパーティションをマージ候補として選択して２つ以上の新規パーティションにマージするように構成される。パーティション選択コンポーネント７０８は、テーブルのクラスタリングが閾値を下回ったことを判別するクラスタリング状態コンポーネント７０６に応答するか、ユーザからの明示的なユーザコマンドに応答するか、及び／又はＤＭＬコマンドの一部として、マージ候補を選択するようにすることができる。マージは、テーブルに対するパーティションのクラスタリングの度合いを改善又は維持するためのインクリメンタル再クラスタリングプロセスの一部として実行されるようにすることができる。

【0073】

パーティション選択コンポーネント７０８は、様々な特徴に基づいてマージ候補を選択することができる。実施例として、パーティション選択コンポーネント７０８は、１つ以上の属性に対して重複する値を含むパーティションのみを選択することができる。別の実施例として、パーティション選択コンポーネント７０８は、２つ以上のパーティションが重複する度合いが最大になる（例えばそれらが任意の使用可能なパーティションの最大の重複を有する）パーティションを選択する。パーティション選択コンポーネント７０８は、対象となる値の範囲又は幅に基づいて、パーティションの優先順位付け又は省略を行うことができる。例えば、大きなキー値の範囲をカバーするパーティションは、小さい範囲をカバーするパーティションより優先される。パーティション選択コンポーネント７０８は、現在の再クラスタリング又はクラスタリング保守手順のためのバジェットに基づいて、マージ候補を選択することもできる。例えば、バジェットは、マージ可能なパーティションの数、使用できるメモリの量、又は使用できる処理リソースの量を示すことができる。パーティション選択コンポーネント７０８は、このバジェットに基づいて、パーティションを選択することができる。更に、パーティション選択コンポーネント７０８は、バジェットが大きく、従って、クラスタリングに大きな改善を提供する場合は、マージ／再クラスタリングのためのより多くのパーティションを選択することができる。

【0074】

既に理想的にクラスタリングされているパーティションは、マージ／再クラスタリングがその理想的にクラスタリングされたパーティションのクラスタリングを改善しないので、考慮から省略できる。例えば、パーティション選択コンポーネント７０８は、テーブル内のどの他のパーティションとも重複せず、及び／又は、テーブル内のどの他のパーティションとも重複閾値を超えて重複しない、パーティションを無視するようにすることができる。同様に、パーティション選択コンポーネント７０８は、クラスタリングキーのための全ての値が同一の値を持つパーティションを無視することができる。

【0075】

一実施形態では、パーティション選択コンポーネント７０８は、同様のパーティション幅に基づいてパーティションをグループ化する。パーティション幅は、値の範囲であってよく、又はパーティション内のロウ内の１つ又はキー属性のための値の範囲に少なくとも比例してよい。例えば、パーティション内のロウの最小及び最大の値の差が大きいほど、パーティション幅が大きくなる。同様に、指定されたカラム内の全てのロウに対して同一の値を持つパーティションは、パーティション幅が最小（例えば、パーティション幅＝０）になる。一実施形態では、パーティション選択コンポーネント７０８は、パーティション幅のＮ底のログ（ｌｏｇ_Ｎ（パーティション幅））に基づいてパーティションをグループ化する。例えば、Ｎ＝２の場合、パーティションは次のグループをグループ化することができる：０＞パーティション幅＞＝２；２＞パーティション幅＞＝４；４＞パーティション幅＞＝８；８＞パーティション幅＞＝１６；０＞パーティション幅＞＝３２；等々。対数基底Ｎは、所望に応じて任意の値とすることができる。グループ化の後、パーティション選択コンポーネント７０８は、同じグループに属しているか、又は最大幅の同じグループに属するパーティションの選択を優先する。

【0076】

再クラスタリングコンポーネント７１０は、テーブルのパーティションを再クラスタリングするための再クラスタリング手順を実行するように構成されている。例えば、再クラスタリングコンポーネント７１０は、パーティション選択コンポーネント７０８によって選択された２つ以上のパーティションに対して再クラスタリング手順を実行することができる。再クラスタリングコンポーネント７１０は、テーブルのクラスタリングが閾値を下回ったことを判別するクラスタリング状態コンポーネント７０６に応答するか、ユーザからの明示的なユーザコマンドに応答するか、及び／又はＤＭＬコマンドの一部として、再クラスタリングを実行するようにすることができる。再クラスタリングは、テーブルに対するパーティションのクラスタリングの度合いを改善又は維持するためのインクリメンタ
ル再クラスタリングプロセスの一部として実行されるようにすることができる。

【0077】

再クラスタリングコンポーネント７１０は、バジェット又は再クラスタリングのタイプに基づいて異なるタイプの再クラスタリングを実行することができる。例えば、無制限のバジェット又は完全な再クラスタリングが要求された場合、再クラスタリングコンポーネント７１０は、別の仮想ウェアハウスを利用して、理想的な方法でテーブルの新規パーティションを作成できる。一方、低バジェットが使用可能な場合、又は再クラスタリングがＤＭＬコマンド又はインクリメンタル再クラスタリング手順の一部として実行される場合、再クラスタリングコンポーネント７１０は、一度に２つ以上のパーティションをマージ又は再クラスタリングパーティションにすることができる。インクリメンタルクラスタリングの手順は、クラスタリングの増加（重複の削減など）を目的として設計されるようにすることができため、インクリメンタルクラスタリングの手順は、時間の経過や多くの反復により、理想的なクラスタリングに収束するであろう。

【0078】

実施例として、インクリメンタル再クラスタリングは、マージする２つ以上のパーティションを選択して、１つ以上の新規パーティションを作成することができる。結果として得られる新規パーティションは、より良好にクラスタリングされるようにすることができ、それによりテーブル全体のクラスタリングを改善することができる。選択された２つ以上のパーティションがマージされた後に、２つ以上の追加パーティションがマージされるようにして、クラスタリングを更に改善することができる。インクリメンタルクラスタリングが使用されるようにするようにすることができ、理想的なクラスタリングは必要ないため、再クラスタリング手順の前又は後、あるいはテーブルの存在中のいつでさえも、テーブルは理想的にはクラスタリングされないようにすることができる。例えば、異なるパーティション間に依然として重複がある可能性があり、又はパーティションが指定されたクラスタリングキーに対して１つより多い値を含む可能性があるため、テーブルが理想的にクラスタリングされないことがある。しかしながら、そのクラスタリングは、プルーニングが依然として最適又はほぼ最適なクエリ応答を可能にする「十分に良好な」状態に維持されるようにすることができる。従って、理想的なクラスタリングが実現されていないために生じる可能性がある非効率性は、理想的にクラスタリングされたパーティションを生成し又は維持することのオーバーヘッドを回避することで得られる効率性と、あるケースにおいて顕著に相殺されるようにすることができる。

【0079】

図８は、テーブルについてのインクリメンタルクラスタリング保守のための例示的方法８００を説明した概略フローチャート図である。この方法８００は、データベース管理システム、データベースサービスマネージャ１０２、及び／又はクラスタリング保守モジュール２３０によって実行されるようにすることができる。

【0080】

方法８００が開始され、データベース管理システム１０２は、テーブルのためのテーブルデータを複数のパーティションに記憶（８０２）する。各パーティションは上記テーブルのためのテーブルデータの一部を含み、上記パーティションは上記テーブル内の１つ以上の属性に基づいて少なくとも部分的にクラスタリングされる。データベースサービスマネージャ１０２は、テーブルへの変更に基づいて１つ以上の新規パーティションを作成（８０４）する。テーブルに対する変更は、テーブルに対するロウの追加又はロウの削除につながるＤＭＬコマンドを含むようにすることができる。１つ以上の新規パーティションの少なくとも１つが互いに又は先のパーティションと重複してテーブルのクラスタリングの度合いの低下を招く。一実施形態では、データベースサービスマネージャ１０２は、１つ以上の新規パーティション上で、互いに対して、マージ／再クラスタリングを実行することができる。

【0081】

データベースサービスマネージャ１０２は、テーブルデータのクラスタリングの度合い
がクラスタリング閾値を下回っているかどうかを判別（８０６）する。データベースサービスマネージャ１０２が上記クラスタリングの度合いがクラスタリングの閾値を下回っていると判別（８０６でＹＥＳ）した場合、データベースサービスマネージャ１０２は、テーブルの１つ以上のパーティションの再クラスタリング（８０８）をトリガして、テーブルのクラスタリングの度合いを改善する。再クラスタリング８０８は、上述したように、マージ／再クラスタリングのためにパーティションが選択されるインクリメンタル再クラスタリングであるようにすることができる。例えば、再クラスタリング８０８は、テーブルに理想的にクラスタリングされたパーティションをもたらす完全な再クラスタリングが含まれないようにすることができる。データベースサービスマネージャ１０２が、クラスタリングの度合いがクラスタリングの閾値を下回っていないと判別（８０６でＹＥＳ）した場合、データベースサービスマネージャ１０２は、テーブルへの変更に基づいて１つ以上の新規パーティションを生成（８０４）し続けることができる。従って、再クラスタリング又はインクリメンタル再クラスタリング手順の犠牲は、テーブル上のクエリを改善するために必要／有用でない限り、回避することができる。

【0082】

図９は、コンピューティング装置９００の実施例を描いたブロック図である。いくつかの実施形態において、コンピューティング装置９００は、本明細書で論じられる１つ以上のシステム及びコンポーネントを実装するために使用される。例えば、コンピューティング装置９００は、１つ以上のデータベースサービスマネージャ１０２、クラスタリング保守モジュール２３０のようなデータベースサービスマネージャのコンポーネント又はモジュール、及び／又はクラスタリング保守モジュール２３０のコンポーネント７０２〜７１２を実装するために使用されるようにすることができる。更に、コンピューティング装置９００は、本明細書に記載される任意のシステム及びコンポーネントと相互に作用することができる。従って、コンピューティング装置９００は、本明細書で論じられるような種々の手順及びタスクを実行するために使用されるようにすることができる。コンピューティング装置９００は、サーバ、クライアント、又は任意の他のコンピューティング実体として機能することができる。コンピューティング装置９００は、デスクトップコンピュータ、ノート型コンピュータ、サーバコンピュータ、ハンドヘルドコンピュータ、タブレット等のような多種多様なコンピューティング装置のいずれでもよい。

【0083】

コンピューティング装置９００は、１つ以上のプロセッサ９０２、１つ以上のメモリ装置９０４、１つ以上のインタフェース９０６、１つ以上の大容量記憶装置９０８、及び１つ以上の入出力（Ｉ／Ｏ）装置９１０を含み、全てがバス９１２に結合される。プロセッサ９０２は、メモリ装置９０４及び／又は大容量記憶装置９０８に記憶された命令を実行する１つ以上のプロセッサ又はコントローラを含む。プロセッサ９０２は、キャッシュメモリなどの様々な種類のコンピュータ読取り可能媒体を含むことができる。

【0084】

メモリ装置９０４は、種々のコンピュータ読取り可能媒体、例えば揮発性メモリ（例えば、ランダムアクセスメモリ（ＲＡＭ））及び／又は不揮発性メモリ（例えば、読取り専用メモリ（ＲＯＭ））を含む。メモリ装置９０４はまた、フラッシュメモリなどの書換え可能ＲＯＭを含むことができる。

【0085】

大容量記憶装置９０８は、磁気テープ、磁気ディスク、光ディスク、ソリッドステートメモリ（例えば、フラッシュメモリ）などの様々なコンピュータ読取り可能媒体を含む。様々なドライブはまた、様々なコンピュータ読取り可能媒体からの読出し及び／又は書込みを可能にするために、大容量記憶装置９０８に含まれるようにすることができる。大容量記憶装置９０８は、リムーバブルメディア及び／又は非リムーバブルメディアを含む。

【0086】

Ｉ／Ｏ装置９１０は、コンピューティング装置９００からデータ及び／又は他の情報を入力又は取得することを可能にする様々な装置を含む。例えばＩ／Ｏ装置９１０は、カー
ソル制御装置、キーボード、キーパッド、マイクロフォン、モニタ又は他の表示装置、スピーカ、プリンタ、ネットワークインタフェースカード、モデム、レンズ、ＣＣＤ又は他の画像キャプチャー装置等を含む。

【0087】

インタフェース９０６は、コンピューティング装置９００が他のシステム、装置、又はコンピューティング環境と対話できるようにする様々なインタフェースを含む。インタフェース９０６の実施例は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、ワイヤレスネットワーク、及びインターネットへのインタフェースなど、任意の数の異なるネットワークインタフェースを含む。

【0088】

バス９１２は、プロセッサ９０２、メモリ装置９０４、インタフェース９０６、大容量記憶装置９０８、及びＩ／Ｏ装置９１０が互いに、並びにバス９１２に結合された他の装置又はコンポーネントと、通信することを可能にする。バス９１２は、システムバス、ＰＣＩバス、ＩＥＥＥ１３９４バス、ＵＳＢバスなどのような、いくつかのタイプのバス構造の１つ以上を表す。

【0089】

例証の目的のために、プログラム及び他の実行可能プログラムコンポーネントは、個別のブロックとして本明細書に示されているが、そのようなプログラム及びコンポーネントは、コンピューティング装置９００の異なる記憶コンポーネントにおいて様々な時間に存在し得ることが理解されるが、それらはプロセッサ９０２によって実行される。或いは、本明細書に記載されるシステム及び手順は、ハードウェア、又はハードウェア、ソフトウェア、及び／又はファームウェアの組合せで実装されるようにすることができる。例えば、１つ以上のアプリケーション固有集積回路（ＡＳＩＣ）を、本明細書に記載される１つ以上のシステム及び手順を実行するようにプログラムすることができる。本明細書において使用される場合、用語「モジュール」又は「コンポーネント」は、本明細書に開示された動作の全部又は一部を実行する目的のために、ハードウェアによる、又はハードウェア、ソフトウェア、及び／又はファームウェアの組合せによるようなプロセスを達成するための実装装置を伝えることが意図されている。「モジュール」又は「コンポーネント」という用語は、モジュール、コンポーネント、又はそれらの機能又はハードウェアが異なる実施形態で実装され得るされ方からは独立して伝えることが意図されている。

【0090】

＜インクリメンタルクラスタリングのアルゴリズムの例＞
このアルゴリズムは、追加のデータ構造を使用せずにＬＳＭＴのような振る舞いをすることを目的としており、完全に増分動作も可能にする。一実施形態では、このアルゴリズムは、永続的なデータ構造を維持し、複数列のクラスタリングをサポートし、最終的にはテーブルの完全にソート/クラスタリングされたパーティションに収束する。完全にソー
ト/クラスタリングすると、ファイルがパーティションセット内の特定の順序になってい
るわけではありませんが、データを連結してソートされたシーケンスを形成したり、プルーニングが最適であるようにパーティションを配置することができる。このアルゴリズムは、独立したサブタスクにも簡単に分解できる。このアルゴリズムでは、データセットを完全に並べ替える必要はなく、プルーニングは必要以上のパーティションを検出できることを意味する。次の説明では、各列又はパーティションを独自のファイルに格納し、データがクラスタリングされている列に対して多くの操作が実行されるため、「ファイル」及び「パーティション」という用語を区別なく使用する。

【0091】

＜１．幅を見つける＞
アルゴリズムは、ファイル又はパーティションの幅の検索を含む。アルゴリズムの後続の部分では、ファイル又はパーティションの幅が使用される。多次元のキーを使用すると、それを定義するのは扱いにくい場合がある。また、不均一なドメインの場合、アルゴリズムは、必ずしもドメインの一部ではなく、実際の値の分布に関連する幅を必要とする場
合がある。幅を検索するために、少なくとも２つのオプションがある。

【0092】

１番目のオプションは、値の範囲を擬似等高さヒストグラムに変換する。この最初のオプションは、非減少値を有するパーティションの最も長いシーケンスを検索する。これにより、データ分布の適切な近似値が得られる。そのシーケンスの検索は、パーティションを並び替え、以下の操作を実行することにより、行われるようにすることができる。
files =sort(files, by-EPs-MAX-value)
last_file =files[0]
sequence =[last_file]
for (int i = 1;i < sorted_files.size(); i++) {
if(files[i].min < last_file.max) ／／ ファイルが最後の先行ファイルと重複
continue
last_file =files[i]
sequence.append(last_file)
}

【0093】

結果として得られるシーケンスでバイナリ検索を行うことにより、アルゴリズムはそのシーケンスに関してファイル又はパーティションのサイズを見つけることができる。これは、シーケンス内でいくつのパーティションが特定のファイル／パーティションと重複しているかを判別するために使用されるようにすることができる。一実施形態では、ファイル又はパーティションは、指標としてパーティション内のレコード数とともに記憶されてもよい。これは、いくつかの「より小さな」パーティションに役立ち、もう少し正確にすることができる。この手順では、各パーティションに値１．．．Ｎを与える。ここで、Ｎはシーケンスの長さである。完全に並び替えられたケース（明瞭値を想定）では、各パーティションの幅は１（狭いパーティション）になる。その後、新しいランダムな並び替えられていないパーティションが追加され、それらが全体的に使用されている範囲の大部分にまたがると仮定すると、そのサイズはＮ（幅の広いパーティション）になる。１０００パーティションの完全に並び替えられたシーケンスがある場合、１０個の未並替えパーティションが挿入され、パーティション／ファイルには幅１の１０００パーティションと１０００に近い幅の１０パーティションが含まれる。ここでのパーティションの「幅」は、ＬＳＭＴのレベルのサイズとやや逆であることに留意されたい。言い換えれば、非常に小さなＬＳＭＴグループはここでは非常に「広い」であろう。より正確ではないが、幅のより単純な定義は、全ての最小と最大を取り、それらをポイントとして扱い、それらを並べ替えることであろう。次に、幅＝パーティションがカバーするこれらのポイントの数とする。

【0094】

幅を決定するためのもう１つのより正確なオプションは、全てのパーティションに対して範囲ツリーを構築することを含む。次に、範囲ツリーを使用して、２番目のオプションは、特定のパーティションが重複するパーティションの部分がいくつあるか計算する。

【0095】

＜２．幅によってパーティションを分類する＞
ひとたびパーティションの幅を有したら、それらはＮの累乗個のバケットに分類（又はグループ化）されるようにすることができる。例えば、Ｎを２にすることができる。ここでの直感は、常に同じような幅のパーティションをマージしたいということである。その理由は、同じレベルのものをマージすると、より高いレベルが増加することである。また、後続のステップで有用な作業を行う可能性を高めるために、ファイル又はパーティションをより少ない数のバケット（例えば、４又は１６の累乗）にグループ化することもできるということに注意されたい。バケットの数は、いつでもマージされないであろうパーティション（ファイル）の重複の回数にほぼ一致する。そのことは、より少ないバケットが
役に立つことを意味する。同時に、より少ないバケットはまた、幅の異なるパーティションもマージされる可能性があることも意味する。これは、ほぼ同じ幅のパーティションをマージする利点と、少ないバケットに対して少ない作業量との間のバランスである。

【0096】

＜３．マージ候補を見付ける＞
アルゴリズムは、マージするファイル又はパーティションの検索を含む。マージの間、並び替えられたパーティションは新しく並び替えられたパーティションにマージされる。マージ候補を見つけるには、各バケット又はグループが最も幅の広いものから始まり、重複している最大Ｎ個のパーティションを検索することが含まれる。Ｎは何でもかまわないし、マージ／インクリメンタルクラスタリングに割り当てられたリソースのバジェットによって異なる場合がある。重複するパーティションの検索は、並び替えられたシーケンスにペアを配置し、重複する最大Ｎ個のパーティションを検索することによって実行できる（例えば、［“ｓｔａｒｔ”，ｆｉｌｅ．ｍｉｎ−ｖａｌ］［“ｅｎｄ”，ｆｉｌｅ．ｍａｘ−ｖａｌ］）。これらのパーティションは、マージされると、次のアルゴリズムの反復で「より狭い」パーティションを形成する。１つのセットが特定されると、バジェットに達するまで追加セットが識別される。バケットに（重複している）パーティションがない場合、アルゴリズムはより「狭い」バケットに移動して、何らかの作業機会を構築するようにすることができることに注意されたい。最初のデフォルトパスが十分な作業を見つけられない場合、これは第２パスのアプローチであるようにすることができる。

【0097】

＜シナリオ実施例＞
１次元のクラスタリングキーを有する簡単なシナリオを使用してみる。記法：[０-７]
は、０から７までの値を持つ単一のパーティションを表わす。開始点-完全に並び替えら
れたシーケンス、及びいくつかの「新規」パーティション。我々のドメインは１６進数字であると仮定する。
[0-1][2-3] [4-5] [6-7] [8-9] [A-B] [C-D] [E-F] // 並び替えられたパーティションシーケンス-ノート、パーティションの順序は関係ない
[0-E] [2-F] [1-C] [2-D]// 「幅」が導出される前の新しいパーティション

【0098】

最も長い並び替えられたシーケンスは８個のパーティションであることに注意されたい。新しいパーティションの幅は以下の通りである。
[0-----------------------------------------E ] - width = 8
[2------------------------------------ F] - width = 7
[1--------------------------------C] - width = 7
[2-------------------------------D] - width = 6

【0099】

これらのパーティションが同じバケットに分類され、Ｎ（マージする数）が２であると仮定する。アルゴリズムは、マージされるべきパーティション[０-E]と[１-C]を選択し、そして[２-D]と[２-F]を選択する。これにより、４つの新しいパーティションが作成される。データはアルゴリズムの一部として並び替えられるため、結果として得られる各パーティション内の範囲は小さくなる。
[0-E] + [1-C] => [0-7] , [8-C]
[2-D] + [2-F] => [2-8] , [9-F]

【0100】

最初のパスの後の状況は次のとおりである。
[0-1] [2-3] [4-5] [6-7] [8-9] [A-B] [C-D] [E-F] // 並び替えられたファイル - width = ca.1
[0-7] [8-C] [2-8] [9-F] // 新しいマージされたファイル, width = ca. 4(より小さい値範囲)

【0101】

ここで、新しいマージされたファイル（パーティション）の「幅」は、以前よりも「狭く」なっていることに注意されたい。新しい「マージされた」ファイルを追加すると「広い」範囲が含まれる可能性がある。
[1-E] [1-F] [0-D] [2-F] // 追加的に新しい追加されたファイル, width =ca.8

【0102】

このアルゴリズムは[1-E]+[1-F],[0-D]+[2-F]を幅＝８のバケット（例えば、ｌｏｇ２
）からマージするために選択し、新しいパーティション[1-8]+[9-F]と[0-7][8-F]を生成
する。ただし、次のように、重複するパーティションも幅＝４（十分なバジェットがある場合）とマージされる。
[0-7]+[2-8]=> [0-4]+[5-8] and [8-C]+[9-F]=>[8-B]+[C-F]

【0103】

このパスの後、パーティション／ファイルの状況は次のようになる。
[0-1] [2-3] [4-5] [6-7] [8-9] [A-B] [C-D] [E-F] // 並び替えられたファイル- width = ca.1
[0-4] [5-8] [8-B] [C-F] // 幅4からマージされたファイル、いまそれらは幅2を有
する
[1-8] [9-F] [0-8] [8-F] // 幅8からマージされたファイル、いまそれらは幅4を有
する

【0104】

アルゴリズムを数回繰り返していくと、パーティションは最終的には重複する「狭い」パーティションに到達し、マージされて完全に並び替えられたシーケンスになる。

【0105】

＜実施例＞
以下の実施例は、更なる実施形態に関する。

【0106】

実施例１では、テーブルのためのテーブルデータを複数のパーティションに記憶することであって、各パーティションがテーブルのための上記テーブルデータの一部を含み、上記パーティションは上記テーブル内の１つ以上の属性（例えばカラム）に基づいて少なくとも部分的にクラスタリングされることを含む方法である。その方法は、上記テーブルへの変更に基づいて１つ以上の新規パーティションを作成することであって、上記１つ以上の新規パーティションの少なくとも１つが互いに又は先のパーティションと重複して上記テーブルのクラスタリングの度合いの低下を招くこととを含む。その方法は、上記テーブルのクラスタリングの度合いがクラスタリング閾値を下回っていることを判別することを含む。その方法はまた、クラスタリングの上記度合いが上記クラスタリング閾値を下回ったことを判別することに応答して、上記テーブルの１つ以上のパーティションを再クラスタリングして上記テーブルのクラスタリングの上記度合いを改善することも含む。

【0107】

実施例２では、実施例１のテーブルに対する変更が、ＤＭＬコマンド、又はテーブルデータの少しずつ若しくは一括のローディングの１つ以上に基づく１つ以上の変更を含む。

【0108】

実施例３では、実施例１〜２のいずれかの方法が、いくつのパーティションが上記テーブルの他のパーティションに重複しているか、上記テーブルの他のパーティションとの１つ以上のパーティションの重複の度合い、１つ以上の属性値に対していくつのパーティションが重複しているかを判別すること、又は、テーブルパーティションの平均深さを判別することであって、上記深さは上記１つ以上の属性に対する特定の属性値について重複するパーティションの数を含むこと、の１つ以上に基づいて上記クラスタリングの度合いを判別することを更に含む。

【0109】

実施例４では、実施例１〜３のいずれかにおいて、上記テーブルデータが十分にクラスタリングされていないことを判別することが、サンプルクエリの実行時間がクエリ実行長
閾値を超えることを判別することを含む。

【0110】

実施例５では、実施例１〜４のいずれかにおいて、テーブルデータのクラスタリングの度合いがクラスタリング閾値を下回っているかどうかを判別すること、又は再クラスタリングすることが、バックグラウンドプロセスの一部として判別すること又は再クラスタリングすることを含む。

【0111】

実施例６では、実施例１の方法が更に、２つ以上のパーティションをマージ候補として選択することを含む。

【0112】

実施例７では、実施例６のように上記２つ以上のパーティションを上記マージ候補として選択することは、上記１つ以上の属性に対して重複する値を含む２つ以上のパーティション、上記２つ以上のパーティションが重複する度合い、上記２つ以上のパーティションによってカバーされる１つ以上の属性に対応する値の幅、又は、上記１つ以上の属性に基づいてパーティションが理想的にクラスタリングされているか否か、の１つ以上に基づいて選択することを含む。

【0113】

実施例８では、実施例６〜７のいずれかにおいて、上記２つ以上のパーティションを上記マージ候補として選択することは、上記テーブル内のどの他のパーティションとも重複せず、又は、上記テーブル内のどの他のパーティションとも重複閾値を超えて重複しない、パーティションを無視することを含む。

【0114】

実施例９では、実施例６〜８のいずれかにおいて、上記２つ以上のパーティションを上記マージ候補として選択することは、上記１つ以上の属性に対して同一の値を有するロウの値を含むパーティションを無視することを含む。

【0115】

実施例１０では、実施例６の方法が更に、パーティション幅に基づいてパーティションをグループ化することを含み、ここで、パーティション幅は、パーティション内のロウ内の１つ以上の属性の値の範囲に比例する。

【0116】

実施例１１では、実施例１０のパーティション幅に基づいてパーティションをグループ化することが、パーティション幅のＮ底の対数に基づいてグループ化することを含む。

【0117】

実施例１２では、実施例１０〜１１のいずれかにおいて、２つ以上のパーティションを選択することが、同じグループからパーティションを選択することを含む。

【0118】

実施例１３において、実施例１〜１２のいずれかにおける再クラスタリングは、インクリメンタルにクラスタリングを改善することを備え、再クラスタリングの繰返しに基づいて上記テーブルデータの上記１つ以上のパーティションを再クラスタリングすることが理想的なパーティショニングに向けて収束することを含む。

【0119】

実施例１４において、実施例１〜１３のいずれかにおける再クラスタリングは、リソースバジェット（例えば、再クラスタリングのリソースのバジェット）に基づく再クラスタリングを含む。

【0120】

実施例１５では、実施例１〜１４のいずれかにおける再クラスタリングが、２つ以上のパーティションをマージして改善されたクラスタリングを有する１つ以上のパーティションを生成することを含む。

【0121】

実施例１６では、実施例１〜１５のいずれかの方法を含み、上記テーブルに対する上記
変更の前又は後に上記テーブルは理想的にはクラスタリングされていない。上記エーブルは、上記１つ以上の属性に対応する値の範囲内で重複するパーティションのペアが１つも存在しないこと、及び／又は上記１つ以上の属性に対応する属性についてのパーティションの全てのロウが同じ値を含むときに、理想的にクラスタリングされる。

【0122】

実施例１７では、実施例１〜１６のいずれかの方法が、ＤＭＬコマンドの一部としてインクリメンタル再クラスタリングを実行することを含む。

【0123】

実施例１８では、実施例１７におけるＤＭＬコマンドの一部としてのインクリメンタル再クラスタリングは、マージバジェットに基づいて制限される。マージバジェットは、マージ可能なパーティションの数、及び／又は割り当てられたメモリ又はインクリメンタル再クラスタリングの一部として使用される処理リソースの量の１つ以上が制限されるようにすることができる。

【0124】

実施例１９は、実施例１〜１８のいずれかのような方法を実行する手段を含む装置又はシステムである。

【0125】

実施例２０は、機械読取り可能命令を含む機械読取り可能記憶装置であり、その命令が実行される時には、実施例１９の何れかの方法を実装し又は装置を実現する。

【0126】

様々な技法、又はそれらの特定の態様若しくはその一部は、フロッピーディスク、ＣＤ−ＲＯＭ、ハードドライブ、非一時的なコンピュータ読取り可能記憶媒体、又はその他の前述の機械読取り可能記憶媒体に具現化されるプログラムコード（即ち、命令）の形式を取るようにすることができる。上記プログラムコードが、コンピュータのような機械によって読み込まれそして実行されるときに、その機械が様々な技術を実践するための装置となる。プログラマブルコンピュータ上でプログラムコードが実行される場合、そのコンピューティング装置は、プロセッサ、プロセッサによって読み取り可能な記憶媒体（揮発性及び不揮発性メモリ及び／又は記憶エレメントを含む）、少なくとも１つの入力デバイス、及び少なくとも１つの出力デバイスを含むようにすることができる。揮発性及び不揮発性メモリ及び／又は記憶エレメントは、ＲＡＭ、ＥＰＲＯＭ、フラッシュドライブ、オプティカルドライブ、磁気ハードドライブ、又は電子データを記憶するための別の媒体とすることができる。本明細書に記載される様々な技法を実装又は利用することができる１つ以上のプログラムは、アプリケーションプログラミングインターフェース（ＡＰＩ）、再利用可能なコントロール等を使用することができる。このようなプログラムは、コンピュータシステムと通信するための高レベルの手続き型、機能的、オブジェクト指向のプログラミング言語で実装されるようにすることができる。しかし、プログラムは、必要に応じてアセンブリ言語又は機械語で実装されてもよい。いずれの場合も、言語はコンパイル済み又はインタープリタ型の言語であり、ハードウェアの実装と組み合わせることができる。

【0127】

明細書に記載された機能単位の多くは、より具体的にその実装の独立性を強調するために使用される用語である１つ以上のコンポーネント又はモジュールとして実装されるようにすることができることが理解されるべきである。例えば、コンポーネント又はモジュールは、カスタム超大規模インテグレーション（ＶＬＳＩ）回路若しくはゲートアレイ、論理チップ、トランジスタ、又は他のディスクリート部品などの既製半導体を含むハードウェア回路として実装することができる。コンポーネントは、フィールドプログラマブルゲートアレイ、プログラマブルアレイロジック、プログラマブルロジックデバイスなどのプログラマブルハードウェアデバイスに実装することもできる。

【0128】

コンポーネントは、様々な種類のプロセッサによって実行するためのソフトウェアで実
装されるようにすることもできる。例えば、実行可能コードの識別されたコンポーネントは、コンピュータ命令の１つ以上の物理的又は論理的なブロックを構成し、例えば、オブジェクト、プロシージャ、又は関数として編成することができる。それにもかかわらず、識別されたコンポーネントの実行可能ファイルは物理的に一緒に配置される必要はないが、論理的に一緒に結合してコンポーネントを構成し、そのコンポーネントのための指定された目的を達成する別の場所に記憶される異なる命令を含む場合がある

【0129】

実際、実行可能コードのコンポーネントは、単一の命令又は多くの命令であってもよく、複数の異なるコードセグメント、異なるプログラム間、及び複数のメモリデバイスに分散されている場合もある。同様に、オペレーショナルデータは、本明細書においてコンポーネント内で識別及び図示されてもよく、任意の適切な形式で具体化され、任意の適切なタイプのデータ構造内に組織化され得る。オペレーショナルデータは、単一のデータセットとして収集されるか、異なる記憶装置を含む異なる場所に分散され、少なくとも部分的にはシステム又はネットワーク上の電子信号として存在してよい。コンポーネントは、所望の機能を実行するように動作可能なエージェントを含み、パッシブ又はアクティブであってもよい。

【0130】

本明細書中の「一実施例」の参照は、本開示の少なくとも１つの実施形態に含まれる特定の特徴、構造、又は特性について説明することを意味する。従って、本明細書全体を通じて種々の箇所に「一実施例における」という語句の外観は、必ずしも全て同じ実施形態を指すわけではない。

【0131】

本明細書において使用されるように、複数の項目、構造要素、組成要素、及び／又は材料は、便宜のために共通のリストに提示されてもよい。ただし、これらのリストは、リストの各メンバが個別でユニークなメンバとして個別に識別されるかのように解釈されるべきである。従って、そのようなリストの個々のメンバは、その逆を示すことなく、共通のグループでのプレゼンテーションに基づいてのみ、同じリストの他のメンバの事実上の等価として解釈されるべきではない。加えて、本開示の様々な実施形態及び実施例は、本明細書において種々の構成要素についての代替物と共に参照され得る。そのような実施形態、実施例、及び代替物は、互いの事実上の等価として解釈されるべきではないが、本開示の独立した及び自律的な表現として考慮されるべきであることが理解される。

【0132】

上記は明瞭さの目的でいくつかの詳細に記載されているが、特定の変更及び改変がその原則を逸脱することなくなされ得ることは明らかである。本明細書に記載されるプロセス及び装置の両方を実施する多くの代替的な方法があることに留意すべきである。従って、本実施形態は、限定的ではなく例示的なものと考えることができる。

【0133】

当業者は、開示の根底にある原則から逸脱することなく、上記の実施形態の詳細に多くの変更がなされ得ることを理解するであろう。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】