JP6280872B2 - モジュール式ブロックおよび関連付けられたログファイルを伴う分散型データベース - Google Patents

Description

（関連出願の引用）
本願は、米国特許出願第１３／３４５，６２０号（２０１２年１月６日出願、名称“Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａｂａｓｅ ｗｉｔｈ Ｍｏｄｕｌａｒ Ｂｌｏｃｋｓ ａｎｄ Ａｓｓｏｃｉａｔｅｄ Ｌｏｇ Ｆｉｌｅｓ”）を基礎とする優先権を主張する。該出願の内容は、参照により本明細書に引用される。

本願は、以下の同時出願され、共有に係る特許出願に関連する：
名称「Ｔｉｍｅ Ｓｔａｍｐ Ｂｏｕｎｄｅｄ Ａｄｄｉｔｉｏｎ ｏｆ Ｄａｔａ ｔｏ ａｎ Ａｐｐｅｎｄ−Ｏｎｌｙ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａｂａｓｅ Ｔａｂｌｅ」、第１３／３４５，６２１号、２０１２年１月６日出願、
名称「Ｌｏｇｉｃａｌ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ｏｆ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａｂａｓｅ Ｔａｂｌｅ Ｕｐｄａｔｅｓ ｉｎ ａｎ Ａｐｐｅｎｄ−Ｏｎｌｙ Ｌｏｇ Ｆｉｌｅ」、第１３／３４５，６２５号、２０１２年１月６日出願、および、
名称「Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａｂａｓｅ ｗｉｔｈ Ｍａｐｐｉｎｇｓ Ｂｅｔｗｅｅｎ Ａｐｐｅｎｄ−Ｏｎｌｙ Ｆｉｌｅｓ ａｎｄ Ｒｅｐａｒｔｉｔｉｏｎｅｄ Ｆｉｌｅｓ」、第１３／３４５，６２６号、２０１２年１月６日出願。

（発明の分野）
本発明は、概して、ソフトウェアベースのデータストレージおよび読み出しに関する。より具体的には、本発明は、モジュール式ブロックおよび関連付けられたログファイルを伴う分散型データベースに関する。

分散型データベースは、データのパーティションが、個別の計算リソースにわたって分散される、データベースである。分散型データベースは、同一の物理的場所に位置する、複数のコンピュータ内に実装され得、または相互接続されたコンピュータのネットワークを経由して、離散され得る。分散型データベースは、インターネット、企業内イントラネットまたはエクストラネット、あるいは他のネットワーク上のネットワークサーバ上に常駐することができる。

分散型データベースは、好ましいモジュール性、信頼性、可用性およびスケーラビリティ特性を有するが、依然として、これらの好ましい特性を向上させるための技法を開発することが望ましい。

システムは、マスタノードと、マスタノードによって制御される、ワーカノードとを含む。各ワーカノードは、分散型データベースの２５個以上のモジュール式ブロックを記憶して、各モジュール式ブロックは、５Ｇバイト以下のサイズを有し、関連付けられたログファイルを有する。
本発明は、例えば、以下を提供する。
（項目１）
システムであって、
マスタノードと、
前記マスタノードによって制御される複数のワーカノードであって、各ワーカノードは、分散型データベースの２５個以上のモジュール式ブロックを記憶し、各モジュール式ブロックは、５Ｇバイト以下のサイズを有し、関連付けられたログファイルを有する、ワーカノードと
を備えている、システム。
（項目２）
前記マスタノードは、データベースクエリを受信し、前記データベースクエリをパーティション分割し、前記複数のワーカノードにわたって並行して起動する、項目１に記載のシステム。
（項目３）
前記マスタノードは、前記モジュール式ブロック内のデータに関する統計を収集する、項目１に記載のシステム。
（項目４）
前記マスタノードは、前記統計を使用して、データベースクエリを最適化する、項目３に記載のシステム。
（項目５）
前記マスタノードは、モジュール式ブロックの場所、サイズ、関連付けられたログファイル、および更新時間から選択される統計を収集する、項目３に記載のシステム。
（項目６）
前記マスタノードは、前記複数のワーカノードと通信し、前記統計を更新する、項目５に記載のシステム。
（項目７）
前記マスタノードは、前記複数のワーカノードに対する可用性情報を維持する、項目１に記載のシステム。
（項目８）
前記マスタノードは、前記複数のワーカノードにわたって前記モジュール式ブロックに対する分散情報を維持する、項目１に記載のシステム。
（項目９）
前記マスタノードは、前記複数のワーカノードに対する前記可用性情報を使用して、新しいモジュール式ブロックの配置を決定する、項目７に記載のシステム。
（項目１０）
前記マスタノードは、前記モジュール式ブロックに対する前記分散情報に基づいて、新しいモジュール式ブロックの配置を決定する、項目８に記載のシステム。
（項目１１）
前記マスタノードは、前記複数のワーカノードにわたってモジュール式ブロックを再分散させる、項目１に記載のシステム。
（項目１２）
前記マスタノードは、前記可用性情報に基づいて、モジュール式ブロックを再分散させる、項目７に記載のシステム。
（項目１３）
前記マスタノードは、前記モジュール式ブロックに対する前記分散情報に基づいて、モジュール式ブロックを再分散させる、項目８に記載のシステム。
（項目１４）
前記マスタノードは、前記複数のワーカノードにわたってモジュール式ブロックの複製を制御する、項目１に記載のシステム。
（項目１５）
前記マスタノードは、前記複数のワーカノードに対する可用性情報に基づいて、前記モジュール式ブロックの複製を制御する、項目１４に記載のシステム。
（項目１６）
前記マスタノードは、前記モジュール式ブロックに対する分散情報に基づいて、前記モジュール式ブロックの複製を制御する、項目１４に記載のシステム。
（項目１７）
複製は、構成可能パラメータである、項目１４に記載のシステム。
（項目１８）
前記モジュール式ブロックは、５ＧＢ未満の任意の値に構成可能なサイズを有する、項目１に記載のシステム。
（項目１９）
前記マスタノードは、現在のモジュール式ブロックが最大サイズを超えると、新しいモジュール式ブロックを生成する、項目１に記載のシステム。
（項目２０）
前記マスタノードは、前記現在のモジュール式ブロックが、最大サイズを超えると、現在のモジュール式ブロックからの情報の半分を有する新しいモジュール式ブロックを生成する、項目１に記載のシステム。

本発明は、付随の図面と関連して検討される、以下の発明を実施するための形態と併せて、より完全に理解される。
図１は、本発明のある実施形態に従って構成される、システムを図示する。 図２は、本発明のある実施形態に従って行なわれる、最小および最大ローディング動作を図示する。 図３は、本発明のある実施形態に従って維持される、最小および最大ローディング統計を図示する。 図４は、本発明の実施形態に関連付けられた中継ファイル処理動作を図示する。 図５は、本発明のある実施形態に従って処理される、更新データを図示する。 図６は、本発明のある実施形態に従って利用される、データベースエントリおよび対応する中継ファイルを図示する。 図７は、本発明のある実施形態に従って処理される、中継ファイル更新を図示する。 図８は、本発明の実施形態に関連付けられたテーブル結合動作を図示する。 図９は、本発明のある実施形態に従って受信された更新値を伴う再パーティション分割されたテーブルを図示する。 図１０は、図９の構成に適用される、データ更新を図示する。 図１１は、本発明のある実施形態に従って行なわれる、再パーティション分割動作のより詳細な実施例である。 図１２は、図１１の構成に適用される、データ更新を図示する。

類似参照番号は、図面のいくつかの図全体を通して、対応する部分を指す。

本発明は、解析およびデータウェアハウスの作業負荷を対象とする。例えば、データ解析作業負荷は、通常、時間次元を有するデータを有し、このデータは、定期的間隔において、システムにまとめてロードされる。本発明の実施形態は、これらの特性を利用して、新しいパーティション分割方法を提案する。

従来技術システムは、典型的には、特殊ファイバディスクまたはネットワーク接続を経由して、互に接続された、いくつかのサーバ上で起動する。本発明は、標準的ネットワーク接続を経由して、数百個ものサーバにまで拡張するように設計される。その規模では、大容量テーブル結合を行なうために、ネットワークを経由して転送されるデータの量は、膨大となる。本発明の実施形態は、大容量テーブル結合を行なうために要求されるネットワークＩ／Ｏを最小限にする。

従来技術システムは、典型的には、特殊ファイバディスクまたはネットワーク接続を使用する、いくつかの信頼性のあるサーバ上で起動する。そのようなシステムでは、稀に、管理された様式において、新しいサーバが、システムに追加され、古いサーバが、除去される。本発明の実施形態は、数百個もの汎用サーバにまで拡張するように設計される。これらのサーバは、クラウド内にあり得る。その規模では、サーバ追加および除去は、定期的に生じる。クラウド内の汎用ハードウェアまたはサーバの場合、サーバおよびネットワーク障害は、より頻繁となる。本発明の実施形態は、システムの性能に影響を及ぼさずに、サーバ追加および除去に対処し、ユーザ監視を要求せずに、サーバおよびネットワーク障害から回復する。

図１は、本発明のある実施形態に従って構成される、システム１００を図示する。システム１００は、マスタノード１０２と、分散型データベースを実装する、一組のワーカノード１０４＿１から１０４＿Ｎとを含む。マスタノード１０２は、任意の有線または無線ネットワーク接続１０６を通して、ワーカノード１０４に接続される。

マスタノード１０２は、バス１１４を介して、一組の入力／出力デバイス１１２に接続される、中央処理ユニット１１０等の標準的構成要素を含む。入力／出力デバイス１１２は、キーボード、マウス、ディスプレイ、プリンタ等を含み得る。ネットワークインターフェース回路（ＮＩＣ）１１６もまた、バス１１４に接続され、ネットワーク接続１０６を通して、ワーカノード１０４へのアクセスを提供する。メモリ１２０もまた、バス１１４に接続される。メモリ１２０は、開示される動作を実装するための実行可能命令を記憶する。特に、メモリは、以下に開示される分散型データベース動作を実装するための実行可能命令を含む、マスタノードモジュール１２２を記憶する。

各ワーカノード１０４はまた、中央処理ユニット１６０、バス１６２、入力／出力デバイス１６４、およびネットワークインターフェース回路１６６等の標準的構成要素を含む。各ワーカノードコンピュータ１０４はまた、ワーカノードモジュール１７２の形態における実行可能命令を伴うメモリ１７０を含む。ワーカノードモジュール１７２は、マスタノードモジュール１２２からのコマンドに応答する実行可能命令を含む。そのようなコマンドは、以下に論じられるように、分散型データベースパーティションのストレージ、アクセス、複製、および重複に関連する。追加のコマンドは、分散型データベースパーティションにクエリを行ない、データから知見を導き出す。

システム１００はまた、１つ以上のクライアントコンピュータ１８０を含み得る。各クライアントコンピュータ１８０は、分散型データベースの関連付けられたユーザを有する。クライアントコンピュータ１８０はまた、中央処理ユニット１９０、バス１９４、入力／出力デバイス１９２、およびネットワークインターフェース回路１９６等の標準的構成要素を含む。各クライアントコンピュータ１８０はまた、クライアントモジュール２０２の形態における実行可能命令を伴うメモリ２００を含む。クライアントモジュール２０２は、分散型データベースにアクセスするために使用されるブラウザであり得る。代替として、クライアントモジュール２０２は、分散型データベースと相互接続するための専用アプリケーションであり得る。この専用アプリケーションは、Ｓｔｒｕｃｔｕｒｅｄ ＱｕｅｒｙＬａｎｇｕａｇｅ（ＳＱＬ）、Ｏｐｅｎ Ｄａｔａｂａｓｅ Ｃｏｎｎｅｃｔｉｖｅｌｙ（ＯＤＢＣ）、およびＪａｖａ（登録商標）−ｂａｓｅｄ Ｄａｔａｂａｓｅ Ｃｏｎｎｅｃｔｉｖｉｔｙ（ＪＤＢＣ）等の標準的プロトコルを通して、分散型データベースと通信し得る。最後に、クライアントモジュール２０２は、ワーカノード１０４上で実行されることにより、データアップロード動作の間のデータ転送のコストを削減し得る。

システム１００は、公知の分散型データベース構成に関連付けられた多くの属性を含むが、システム１００は、モジュール式ブロックおよび関連付けられたアペンド専用ログファイルのその利用を通して、従来技術分散型データベース構成と基本的に異なる。各モジュール式ブロックは、分散型データベースに関連付けられたデータのセグメントを保持する。マスタノード１０２は、モジュール式ブロックを定義し、種々のワーカノード１０４へのその分散を管理する。各モジュール式ブロックは、５ギガバイト以下のサイズを有する。これは、データをワーカノードにパーティション分割し、したがって、データベースパーティションサイズにハード限界を課さない、従来技術分散型データベースと対照的である。その結果、従来技術システムは、約１００ギガバイト〜約１０，０００ギガバイトのサイズに及ぶ、分散型データベースパーティションを有する。さらに、従来技術では、単一ワーカノードは、分散型データベースからのデータの単一パーティションを保持する。対照的に、本発明では、各ワーカノード１０４は、パーティション分割されたデータの２５個以上のモジュール式ブロックを保持する。

パーティション分割は、個別の独立部分への論理データベースの分割である。各パーティションは、複数のノードにわたって拡散され得る。ローカルノードにおけるユーザは、ローカルトランザクションをそのパーティションに対して行なうことができる。開示されるモジュール式ブロックも、パーティションであるが、用語「モジュール式ブロック」は、分散型データベースの従来技術の実装と比較して、サイズ区別を強調するために使用される。この構成は、リソース障害の場合、およびリソースがシステムに追加されるとき、利点を有する。

例えば、３つのノードにわたって、データベーステーブルをパーティション分割する従来技術システムの例を検討する。最初に、データは、３つのノードにロードされ、３つのデータベーステーブルパーティションに均等にパーティション分割される。これらのデータベースパーティションは、次いで、より多くのデータが、システムに追加されるにつれて、大きくなる。各パーティションは、典型的には、１００ギガバイトを超えるサイズまで大きくなる。ある時点で、データベースアドミニストレータは、新しいノードを従来技術システムに追加し、分散型データベースの性能を改善する必要がある。このノードが追加されると、分散型データベースは、ネットワークを経由して、大量のデータをシャッフルし、元となるデータを均等に分散させる必要がある。この実施例では、各データベーステーブルパーティションの１／４が、ネットワークを経由して、新しく追加されたノードに転送され、次いで、新しいノード上でマージされ、新しいデータベーステーブルパーティションを作成する。

従来技術システムにおけるこれらのデータ転送動作は、２つの短所を有する。第１に、データベースユーザは、システムに対して、読み取りおよび書き込みクエリを継続的に発行し、大容量データ転送は、システムおよびクエリの性能に悪影響を及ぼす。新しいノードの追加が、十分に稀である場合、データベースアドミニストレータは、データベースユーザに通知し、システムをオフラインにし、データ転送動作が完了することを待つことができる。しかしながら、ノード追加が頻繁である場合、これは、管理不能となる。

さらに、大容量データ転送はまた、従来技術システムにおける障害対処の観点において、課題をもたらす。この実施例では、新しいパーティションが作成されるために、既存のノードからの全３つのデータ転送動作が、正常に完了する必要がある。データ転送のいずれか１つが失敗する場合、全データ転送動作が、データセット全体を一貫して保つために、巻き戻される必要がある。システム内にいくつかのノードが存在し、かつそのハードウェアおよびネットワーク接続に信頼性があるとき、約１００ギガバイト〜１０，０００ギガバイトのいくつかの大容量データ転送動作は、正常に完了する。しかしながら、システムが、汎用ハードウェア上で起動しており、数百個のノードに拡張されるとき、全データ転送が正常に完了する確率は、著しく低くなる。

この従来技術システムと対照的に、本発明の実施形態は、データベーステーブルを３つのワーカノード１０４上に記憶し、ノードの各１つが、４０個のモジュール式ブロックを記憶する。データベースアドミニストレータが、新しいノードをシステムに追加する場合、分散型データベースは、各既存のノードから新しいノードに、１０個のモジュール式ブロックを容易に転送することができる。分散型データベースはまた、データ転送動作を経時的に拡散させ、性能に及ぼす影響を最小限にすることができる。各モジュール式ブロックは、数ギガバイトを超えないので、システム１００は、モジュール式ブロックを転送し、また、性能に及ぼす最小限の影響を伴って、読み取りおよび書き込みクエリを処理することができる。さらに、モジュール式ブロックのためのデータ転送動作は、互に独立し、これらのデータ転送のうちの１つが失敗する場合、失敗したデータ転送動作は、別の時に、全体として再試行されることができる。これは、新しいデータベーステーブルパーティションが出現するために、全データ転送が完了することを要求する、従来技術システムとは対照的である。

ノード追加におけるその利点に加え、モジュール式ブロックはまた、ノードが障害を起こすとき、またはシステムから除去される必要があるとき、利点を有する。例えば、３つの元々のノード（これらの元々のノードは、３つのデータベーステーブルパーティションを保持する）を有する従来技術システムを検討する。ノード障害および除去に対処するために、システムはまた、元々のノードの正確な複製として構成される、３つの複製ノードを有する。元々のノードの障害の場合、元々のノード上のデータベーステーブルパーティションは、利用不可能となり、複製ノードから再複製される必要がある。このため、分散型データベースは、データ転送動作を発行し、スタンバイノード上に新しい複製データベーステーブルパーティションを作成する。

しかしながら、このアプローチは、従来技術システムにおける大容量データ転送に関連する、前述の短所を有する。障害を起こしたノードの複製は、ライブのユーザクエリにも応答しながら、大量のデータを転送する必要がある。この大容量データ転送は、複製ノード、したがって、クエリの性能に影響を及ぼす。さらに、データ転送動作は、大容量データセットのためであり、しばらくの間、継続するので、転送自体が、ハードウェアまたはネットワーク問題により、途中で失敗し得る。実際には、前述の短所は、元々のノードの障害から生じるデータ転送が、その複製ノード上に不均等にもたらされるので、増大する。

加えて、元々のノードの障害はまた、第３の短所を導入する。元々のノード上で起動している全てのライブのクエリが、今度は、複製ノード上で再始動される必要がある。データ解析作業負荷では、ビジネスインテリジェンスクエリが数時間またはさらに数日間実行することは稀ではない。このノード障害は、したがって、起動中のクエリにおける全経過が、喪失され、クエリが、障害を起こしたノードの複製において、その全体が再始動される必要があるので、平均して、これらのクエリの実行時間を５０％増加させる。

対比的に、本発明の実施形態は、データをモジュール式ブロック内に記憶することによって、これらの問題を克服する。例えば、システム１００が、６つのワーカノード１０４を有し、各ワーカノード１０４が、４０個のモジュール式ブロックを記憶すると仮定する。システム内の各モジュール式ブロックは、ランダムに選択される、２つのワーカノードに複製される。したがって、ノードのうちの１つが障害を起こすと、残りのノードの各１つから、平均して８つのモジュール式ブロックが、複製される必要がある。すなわち、再複製データのタスクは、システム内の全ノードにわたって、均等に拡散される。さらに、再複製されたタスクはまた、時間にわたり拡散されることができる。１つのモジュール式データベースブロックが、最初に複製された後、別のモジュール式ブロックの複製が続き得る。各モジュール式ブロックは、サイズが小さいので、ノードに及ぼす性能の影響は、最小限である。さらに、ハードウェアまたはネットワーク障害が、より短いデータ転送動作の間に生じる場合、動作は、単純に、最小限のコストで再試行されることができる。

加えて、ノードのうちの１つが障害を起こすと、全解析クエリは、依然として、再始動される必要があるが、この作業は、システム１００内の全５つのノードにわたって均等に分散される。したがって、システム内で失敗した解析クエリは、従来技術システムにおいて、５０％長くなるのとは対照的に、わずか１０％しか長くかからない。この特定の利点は、数百個のノードを有する分散型システムでは、より顕著となる。それらの規模では、任意の１つのノード障害の確率は、はるかに高くなり、そのような障害が生じると、失敗した解析クエリは、より多くのノードにわたって分散されることができる。

要するに、モジュール式ブロックは、データ解析作業負荷に対して、着目に値する利点を有し、これらの利点は、ノードが汎用ハードウェアを使用するとき、かつ、システム内のノードの数が増加するにつれて、より明らかとなる。説明されるシステム内のワーカノード１０４は、ピアとして定義されるが、また、階層の一部として構成され得ることは、着目に値する。さらに、ワーカノード１０４は、システム１００において、分散合意に達する必要があり得る。分散型合意に達する方法の１つは、２相コミット、Ｐａｘｏｓ、または定足数ベースの投票等のプロトコルの使用を通したものである。合意を達成する別の方法は、システム内の他のノードおよびクエリの実行を調整するマスタノードモジュール１２２に依拠することを通したものである。マスタノードモジュール１２２は、データベースクエリをクライアントデバイス１８０から受信し、データベースクエリをパーティション分割し、複数のスレーブまたはワーカノード１０４にわたって並行して起動する。マスタノードモジュール１２２は、モジュール式ブロック内のデータに関する統計を収集し、次いで、それらの統計を使用して、データベースクエリを最適化し得る。例えば、マスタノードは、これらの統計を使用して、特定のデータ解析クエリに関連しないモジュール式ブロックを決定し、これらの非関連ブロックをクエリから取り除く。マスタノードモジュール１２２はまた、モジュール式ブロック場所、モジュール式ブロックサイズ、ログファイル、および最新更新時間に関する統計を保つ。これらの統計は、クエリをモジュール式ブロックに向け、障害に直面すると、ブロックデータ一貫性を維持するために使用される。これらの統計は、次いで、マスタノード１０２がワーカノード１０４への接続を開始することを通して、ワーカノード１０４がマスタノード１０２への接続を開始することを通して、またはクライアントモジュール２０２がローディングデータをワーカノード１０４にアップロード後、それらをマスタノード１０２に送信することを通してのいずれかによって更新される。

マスタノードモジュール１２２はまた、異なるワーカノード１０４に関する可用性情報を維持する。マスタノードモジュール１２２は、次いで、この可用性情報を使用して、ワーカノード１０４にわたるモジュール式ブロックの配置、配置換え、または複製を決定する。従来技術と対照的に、マスタノードモジュール１２２は、新しいブロックを配置する方針、または既存のブロックを複製する方法の観点において、より柔軟性を有する。例えば、マスタノードモジュール１２２は、ワーカノードに対する可用性情報を使用して、その障害特性を決定し、より障害を起こしやすいと見なされるノード上には、より少ないモジュール式ブロックを配置し得る。または、マスタノードは、この可用性情報とワーカノードのネットワーク場所を組み合わせ得、データセンターの停電に直面した場合でさえ、モジュール式ブロックのための十分な複製が、アクセス可能なままであることを確実にし得る。

マスタノードモジュール１２２はまた、ワーカノード１０４にわたるモジュール式ブロックに対する分散情報を維持する。マスタノードモジュール１２２は、次いで、この分散情報を使用して、ワーカノード１０４にわたるモジュール式ブロックの配置、配置換え、または複製を決定する。システム１００は、有利には、データ分散の観点において、従来技術に匹敵する。マスタノードモジュール１２２は、モジュール式ブロック上の分散情報をワーカノード１０４に関するリソース情報と組み合わせ得、ワーカノード１０４上で利用可能なリソースに比例して、モジュール式ブロックを分散させ得る。したがって、システム１００は、そのリソースにおいて異種のワーカノード１０４を含み得、より多くのリソースを伴うワーカノードは、単純に、より多くのモジュール式ブロックが割り当てられる。

マスタノードモジュール１２２は、種々の構成可能パラメータを含み、分散、再分散、および複製動作を制御し得る。一実施形態では、モジュール式ブロックサイズは、マスタノードモジュール１２２を通して構成可能である。例えば、モジュール式ブロックサイズは、５ギガバイト未満の任意の値に構成可能であり得る。代替として、モジュール式ブロックサイズは、８ギガバイト未満の任意の値に構成可能である。４〜６ギガバイトの範囲もまた、指定され得る。モジュール式ブロックサイズを指定する追加の方法もまた、可能である。モジュール式ブロックサイズは、入力ファイルサイズおよびログファイルサイズに比例する。他の実施形態では、入力ファイルサイズまたはログファイルサイズは、モジュール式ブロックサイズより優先され得、マスタノードモジュール１２２を通して構成可能であり得る。

マスタノードモジュール１２２および／またはクライアントモジュール２０２は、モジュール式ブロックが、その指定されたサイズに一致することを確実にする必要がある。その結果、モジュール式ブロックが、そのエントリが削除され、その指定された最小サイズを下回って減少する場合、モジュール式ブロックは、別のブロックとマージされる必要がある。

同様に、モジュール式ブロックが、その指定された最大サイズを超えて大きくなる場合、新しいモジュール式ブロックが作成されるか、または既存のモジュール式ブロックが２つのブロックに分割される。これらのブロックが作成される特定の機構は、パーティション分割方法に依存する。データベーステーブルが、ハッシュまたは範囲パーティション分割を使用してパーティション分割される場合、マスタノードモジュール１２２は、行の半分を各新しいブロックに割り当てることによって、２つへの既存のブロックの分割を規則化する。マスタノードモジュール１２２は、次いで、２つの新しいブロックに関するハッシュバケット値または範囲規則性を記録する。しかしながら、パーティション分割方法が、データベーステーブル行の間に厳格な規則性を課す必要がない場合、クライアントモジュール２０２は、単純に、入力ファイルを取り込み、ワーカノード上にブロックを作成し、そのブロックへのデータのアップロードを開始する。ブロックサイズが、最大構成サイズを超える場合、クライアントモジュール２０２は、別の新しいブロックを作成し、この新しいブロックへのデータのアップロードを継続する。全入力データが、モジュール式ブロックにロードされると、クライアントモジュール２０２は、全ブロック配置情報および他の重要統計をマスタノードモジュール１２２に渡す。

開示されるアーキテクチャは、本明細書においてアペンドパーティション分割と称される特徴をサポートする。このパーティション分割方法は、データが、短要求としてではなく、バッチとしてデータベースにロードされるときに適用可能となる。さらに、パーティション分割方法は、元となるデータが、固有の最小および最大パラメータを有し、元となるデータが、アペンド専用様式でモデル化され、データベースにロードされ得ると仮定する。これらの特性を伴うデータに対して、アペンドパーティション分割は、効率的データローディングおよびクエリ機構をもたらす。

例えば、その顧客によって閲覧された全ページを記憶する、オンラインウェブサイトを検討する。ウェブサイトは、それらを毎時間のテキストファイルに定期的に集約することによって、これらのデータをロードする。さらに、これらの毎時間のテキストファイルは、固有の最小および最大タイムスタンプを有し、それらが含むページ閲覧データは、不変であり、したがって、アペンド専用様式でデータベースに容易にロードされることができる。

この例では、データローディング動作は、クライアントモジュール２０２が、マスタノードモジュール１２２に、新しいデータベーステーブルパーティションを割り当て、その中にデータをアップロードするためのワーカノード１０４の名を返すように依頼することによって開始し得る。クライアントモジュール２０２は、次いで、新しいデータベーステーブルパーティションをワーカノード１０４上に作成し、毎時間のテキストファイルデータをその中にアップロードし、最小および最大タイムスタンプをこれらのデータから読み出す。クライアントモジュール２０２は、最小および最大タイムスタンプおよび他の統計をマスタノードモジュール１２２に送信することによって、データアップロードを終了する。マスタノードモジュール１２２は、この情報を記憶し、将来的解析クエリを最適化する。

後に、ユーザが、「先週の火曜日に閲覧された最も人気のあるページ」のようなクリエを送信すると、データベースは、自動的に、その開始および終了タイムスタンプが、先週の火曜日のもの内に入らないデータベースパーティションを取り除くことができる。実際、データベースは、有意な数のクエリをこのように最適化することができる。

従来技術方法もまた、パーティション選別に関連するが、データがシステムにロードされる方法に関して、より厳格な要件を課す、類似クエリ最適化を導入する。例えば、ある従来技術方法は、データベースアドミニストレータが、それらがアップロードする各毎時間のテキストファイルに対して、手動で時間範囲を指定することを要求する。このアプローチは、クエリ最適化を可能にするが、手動プロセスはまた、顕著な管理上の課題を導入する。対比して、アペンドベースのパーティション分割は、毎時間のテキストファイルが、既に事前に集約されており、固有の時間次元を有するという仮定の下で動作し、自動的に、時間範囲を各毎時間のテキストファイルから抽出する。

別の従来技術方法データベースアドミニストレータは、典型的には、データベーステーブルのハッシュまたは範囲パーティション分割を使用する。この方法は、パーティション選別を可能にするが、また、データローディングの間、非効率性を導入する。この方法では、毎時間のテキストファイル内の各ウェブページ閲覧データは、ハッシュまたは範囲パーティション分割され、次いで、関連パーティションにルーティングされる。その結果、データをアップロードするモジュールは、毎時間のテキストファイル内の各行に対して、マスタノードモジュール１２２と通信する必要があるか、あるいはデータベーステーブルに関するリースまたはロックを取得し、異なるデータベーステーブルパーティション間でハッシュまたは範囲規則性を施行する必要があるかのいずれかとなる。

対比して、アペンドベースのパーティション分割は、毎時間のテキストファイルデータが、更新されないことを認識し、したがって、各行間に厳格な関係を施行すること、およびその行に対するデータベーステーブルパーティションは、不必要である。代わりに、データベースアドミニストレータは、効率的に、かつ独立して、毎時間のテキストデータをシステム内の任意のノードからロードすることができる。実際、これらのデータロードは、並行して生じることさえできる。マスタノードモジュール１２２は、新しいデータベーステーブルパーティションの作成の管理と、アップロードされたデータに関するメタデータを記憶することのみに関わる必要がある。その結果、ページ閲覧データは、効率的かつ並行して、データベースにロードされることができる。

図２は、第１の毎時間の入力ファイル２００および第２の毎時間の入力ファイル２０２を図示する。各入力ファイルは、ｕｓｅｒ＿ｉｄ列、ｗｅｂｐａｇｅ＿ｉｄ列、ｃａｔｅｇｏｒｙ＿ｉｄ列、およびタイムスタンプ列を有する。タイムスタンプ（ｔｓｔａｍｐ）列は、行内に特徴付けられるアクティビティに関する日時を指定する。毎時間の入力ファイル２００は、日付２００９−０２−０２における１１時間目の間に行なわれたアクションを追跡する一方、毎時間の入力ファイル２０２は、日付２００９−０２−０２における１２時間目の間に行なわれたアクションを追跡する。毎時間の入力ファイル２００からのデータは、ノード２０４上にロードされ、毎時間の入力ファイル２０２からのデータは、ノード２０６上にロードされる。いくつかの実施形態では、マスタノードモジュール１２２は、異なるワーカノード１０４にわたるデータのアップロードを調整し得る。さらに、マスタノードモジュール１２２は、ワーカノード可用性またはデータ分散情報を使用して、その中にデータをアップロードするためのワーカノードの組を決定する。

ユーザが、システムがロックおよびリースを維持することなく、複数のファイルを並行してロードすることができることが観察される。ユーザはまた、アップロードされるデータの時間または日付粒度を選定あるいは指定する必要がない。さらに、ユーザは、データを挿入する前に、手動でパーティションを作成する必要がない。

図３は、マスタノードモジュール１２２によって維持され得る、統計テーブル３００を図示する。この実施例では、統計テーブル３００は、ｔａｂｌｅ＿ｉｄ列、ｐａｒｔｉｔｉｏｎ＿ｉｄ列、ｍｉｎ＿ｖａｌｕｅ列、およびｍａｘ＿ｖａｌｕｅ列を含む。行３０２は、日付２００９−０２−０１における１時間目に対応する、あるデータベーステーブルパーティションを表す。すなわち、行は、この日付における１時間目の間に収集されたデータに対して、ｔａｂｌｅ＿ｉｄおよびｐａｒｔｉｔｉｏｎ＿ｉｄを指定する。行３０４は、同一の日付における１１時間目を指定する。行３０６および３０８は、同一の日付における１２時間目を指定する。同一の時間に対する２つのエントリは、１つ以上のウェブサーバが、そのページ閲覧データの転送に問題があり、これらのページ閲覧が、集約され、後にシステムにロードされたために生じ得る。

統計テーブル３００は、時間範囲を有するクエリを最適化するために使用される。例えば、マスタノードモジュール１２２は、２００９−０２−０１における１１時間目と１２時間目の間（境界値を含む）の最も人気のあるウェブページを尋ねるクエリを受信し得る。この場合、マスタノードモジュールは、統計テーブル３００内に記憶された開始および終了タイムスタンプを使用して、行３０４、３０６、および３０８によって識別されるもの以外の全データベーステーブルパーティションを取り除く。マスタノードモジュール１２２は、次いで、最も人気のあるウェブページクエリのみをデータベーステーブルパーティション３１４、３１６、および３１８に送信し、これらのデータベーステーブルパーティションから応答を受信し、応答をマージし、マージされた応答をユーザに返す。

マスタノードモジュール１２２がパーティション選別を行なうために、１日が２４時間の時間間隔に対応することを把握する必要はない。データベースは、既に、時間データタイプのための内蔵比較演算子を有する。マスタノードモジュールは、単純に、解析クエリ内の時間範囲を統計テーブル内の最小および最大タイムスタンプと比較し、関連パーティションを決定する。

要するに、アペンドベースのパーティション分割は、ハッシュおよび範囲パーティション分割と同一のパーティション選別利点をもたらす。しかしながら、アペンドパーティション分割では、マスタノードモジュール１２２は、行毎レベルでのデータアップロード動作に関わる必要はない。代わりに、ワーカノードモジュール１７２またはクライアントノードモジュール２０２は、データをアップロードしているときのあるメタデータを追跡する。それらがこのメタデータをコミットすると、アップロードされたデータベーステーブルパーティションは、システム内の全ノードに対して明らかとなる。

さらに、これらのデータベーステーブルパーティションはまた、モジュール式ブロックとしてモデル化され得、各モジュール式ブロックは、固定された最大サイズを有する。例えば、ある１時間の間のウェブページ閲覧データをロードするためのコマンドが、受信される。コマンドは、最初に、マスタノードモジュール１２２に、作成されるモジュール式ブロックのための一意の識別子、データがロードされるべきノード名、および所望の複製要因に応答するように依頼する。マスタノードは、回答で返信し、コマンドは、ページ閲覧データを指定されたノードにアップロードおよび複製する。

アップロードされたデータが、システム内のモジュール式ブロックに対して定義された最大サイズを超える場合、新しいモジュール式ブロックが作成され、要求が、追加の情報のために、マスタノードに発行される。全データが、モジュール式ブロックにアップロードされると、コマンドは、マスタノードモジュール１２２に、ブロック場所ならびに最小および最大統計をまとめる。

開示される技法は、コアビジネス機能を特徴付ける事実またはイベントデータを含む、アペンド専用データベーステーブルに関連して利用され得る。アペンド専用データベーステーブルはまた、ゆっくりと変化するディメンションテーブルであり得、各変化とともにタイムスタンプを記憶し得る。このディメンションテーブルはまた、十分なデータ変化が生じると、最初から、データベースにロードされ得る。

このアペンドパーティション分割特徴は、異なるノードにわたって、モジュール式ブロックを複製し、自動的に、新しいデータベーステーブルパーティションを作成する等、種々のデータベース管理動作を伴い得ることが観察される。これらの動作は、マスタノードモジュール１２２に実装され得る。

また、このアペンドパーティション分割特徴は、完全疎結合アーキテクチャおよび共有ディスクアーキテクチャの両方において適用可能であることが観察される。完全疎結合アーキテクチャでは、データベースは、システム内のノードにわたってパーティション分割され、各ノードは、その独自のリソースを有する。共有ディスクアーキテクチャでは、データベースのためのストレージエリアは、ストレージアレイネットワーク（ＳＡＮ）またはネットワークアタッチトストレージ（ＮＡＳ）のいずれかとして構成される、個々のディスクにわたってパーティション分割される。

本開示は、本発明のある実施形態に従って利用される、モジュール式ブロックを説明する。各モジュール式ブロックは、関連付けられたログファイルを有する。ログファイルは、モジュール式ブロックに関連付けられた全変更を記録する。ログファイルは、アペンド専用ログファイルである。アペンド専用ログファイルは、以前のログ付けされた動作を削除せずに、追加のデータ変更を記録する。すなわち、データ更新および削除動作さえ、別個のエントリとして、ログファイル内に記録される。ログファイルはまた、本明細書では、中継ファイルとも称される。

本発明のある実施形態によると、アペンド専用ログファイルは、システムの任意の所与のノード上のデータの物理的表現から独立する様式において、データへの変更を表す。例えば、データは、物理的様式（例えば、ストレージアドレス）の代わりに、論理様式（例えば、テーブル名および行を表すデータ組）において、指定される。このアプローチは、従来技術技法に勝るいくつかの利点を有する。

従来技術データベースは、データベーステーブルおよびそれら内のデータを連続的形式で保つ。言い換えると、データベーステーブルのメタデータおよび再実行ログは、典型的には、他のデータベースのものと連結される。加えて、データベーステーブルのデータは、性能理由から、物理的様式で表される。すなわち、このデータは、異なるデータベースファイルに散在され、データベースページ番号、ページポインタ、またはオフセット番号を通して、一緒に結び付けられる。例えば、データベーステーブル内の特定の行に関するデータは、特定のデータベースファイル、ページ、およびオフセット番号上に記憶される。データベーステーブル内の次の行は、次いで、完全に異なるデータベースファイル、ページ、およびオフセット番号上に記憶され得る。

このデータの物理的表現および強結合は、課題を導入する。第１に、データベーステーブルの一部のみ取り込み、それをネットワークにわたって移動させることは、著しく困難となる。第２に、移動されたとしても、データベーステーブルのその部分はまた、そのデータベースのその独自の物理的表現を有する、別のノード上に再構築される必要がある。これらの課題のため、分散型データベースは、典型的には、互の正確な複製として、いくつかのノードを構成し、複製は、データベースの正確に同一の物理的表現を保つ。しかしながら、これは、データベーステーブルの一部のみ移動されることを非常に困難にする。

このアプローチに関する別の欠点は、特に、障害の場合、テーブルデータを一貫して保つことが困難であることである。例えば、ユーザが、あるテーブル内の行を更新または削除する場合、この変更は、このテーブルの複製を有する、他のノードに複製される必要がある。これらのノードが利用不可能である場合、このテーブルへの変更は、記憶され、後に適用される必要がある。ノードが定期的に障害を起こし、単一ノード上に多くのテーブルが記憶される場合、データを一貫して保つことは、困難となる。

本発明の実施形態は、分散型データベースに対するデータベーステーブル更新を受信することによって、これらの難点を克服する。データベーステーブル更新は、分散型データベースを実行するコンピュータネットワークのノード上のデータベーステーブルパーティションにロードされる。データベーステーブルパーティションまたはモジュール式ブロックは、最大サイズ（例えば、５ギガバイト）を超えない。データベーステーブル更新は、そのデータベーステーブルパーティションに対応するアペンド専用ログファイルに追加される。特に、データベーステーブル更新は、データ挿入、データロード、データ修正、データ削除、またはデータ記述言語（ＤＤＬ）イベントを表す。さらに、データベーステーブル更新に関連付けられたデータは、ノードにおけるデータの物理的表現から独立した論理表現として、アペンド専用ログファイル内に記憶される。これは、データベーステーブルパーティションのコンピュータネットワーク内の他のノードへの転送を促進する。

図４は、本発明の実施形態に関連付けられた処理動作を図示する。最初に、最後に中継されたバイトが、最後に書き込まれたバイトと同一であるかどうか決定される４００。該当する場合、中継された情報は、いかなる更新も含まず、処理は、完了される４０２。バイトが一致しない場合、次のイベントが、中継ファイルから読み取られる４０４。イベントサイズもまた、この動作において記録される。チェックサム整合が、次いで、行なわれる４０６。チェックサムが一致しない場合、エラーが、報告される４０８。チェックサムが一致する場合、最初に、イベントタイプが、解決される。次いで、イベントが、データ定義言語（ＤＤＬ）イベントであるかどうか決定される４１０。該当しない場合、指定された変更が、データベースのストレージエンジンに適用される４１２。例えば、挿入、更新、または削除が、適用される。最後に再現されたバイトが、次いで、イベントのサイズだけインクリメントされる４１４。

これが、ＤＤＬイベントである場合、テーブルおよびテーブルインデックス名が、中継ファイル識別子とともに、ＤＤＬステートメント内に拡張される４１６。テーブルおよびテーブルインデックス名は、同一のノード上に、同一のテーブルの複数のパーティションを保つことを可能にするように拡張される必要があり得る。対応する関数が、次いで、呼び出され、ＤＤＬステートメントを実行する４１８。最後に再現されたバイトは、次いで、イベントのサイズだけインクリメントされる４１４。

これらの動作は、実施例を参照してより完全に理解される。図５は、本発明のある実施形態に従って処理される、受信したデータベーステーブル更新を図示する。図は、ｃｕｓｔｏｍｅｒ＿ｉｄ１５、１６、および１７を有する３つの行のためのテーブル１０２の変更を示す。ｃｕｓｔｏｅｍｒ＿ｉｄ１５に対して、氏名Ｊｏｈｎ Ｄｏｅが、１９８０の生年とともに追加されるべきである。同一の形式は、ｃｕｓｕｔｏｍｅｒ＿ｉｄ１６および１７を含む行にも適用される。

図６は、これらの変更のデータベース表現６００を図示する。図は、データベース６００にロードされた図５内の指定された情報を図示する。これらの変更は、一組の動作を使用してデータベースに追加され得、変更は、異なるデータベースページおよびオフセットに記憶される。変更は、次いで、中継ファイル６０２にロードされる。中継ファイル６０２は、イベントサイズ、イベントタイプ、データ、およびチェックサムを指定する。

したがって、この時点において、データベーステーブル更新が、図５に示されるように、受信されている。データベーステーブル更新は、データベース表現６００で示されるように、コンピュータネットワークのノード上のデータベーステーブルパーティションにロードされる。データベーステーブル更新はまた、中継ファイル６０２で示される、アペンド専用ログファイルにも追加される。ワーカノードモジュール１７２は、これらの動作を実装し得、マスタノードモジュール１２２に経過を通知し得る。

ここで、プライバシーの理由から、生年が維持されるべきではないと決定されるとする。この動作を維持するために、ＤＤＬステートメント「Ａｌｔｅｒ Ｔａｂｌｅ Ｄｒｏｐ Ｃｏｌｕｍｎ Ｄａｔｅ ｏｆ Ｂｉｒｔｈ」が、実行され、中継ファイル１０２に追加される。追加の動作７００が、中継ファイル６０２に追加され、図７に示されるように、これらの動作を実装する。データベース表現７０２は、これらの変更を反映させる。

中継ファイルまたは中継ファイルの最新アペンドされた部分は、システム内の任意のノード１０４に容易に転送される。中継ファイルからのデータ変更は、別のノードに適用され、複製データベーステーブルパーティションを作成し、データをこの複製パーティションに挿入する。データが、最初に中継ファイルにアペンドされ、ノードにわたって複製される方法の仕様は、データベーステーブル更新の性質に応じて、異なり得る。

一実施形態では、データベーステーブル更新は、広範囲のコマンドを表す。実施例として、以下の３つのコマンド：
（ａ）Ｕｐｄａｔｅ ｐｒｏｄｕｃｔｓ Ｓｅｔ ｐｒｉｃｅ＝ｐｒｉｃｅ＊１．１０ Ｗｈｅｒｅ ｐｒｏｄｕｃｔ＿ｉｄ＝９７００、
（ｂ）Ｉｎｓｅｒｔ Ｉｎｔｏ ｐｒｏｄｕｃｔｓ（ｐｒｏｄｕｃｔ＿ｉｄ，ｐｒｏｄｕｃｔ＿ｐｒｉｃｅ）Ｖａｌｕｅｓ（９７００，ｒａｎｄｏｍ（））、および
（ｃ）Ｉｎｓｅｒｔ Ｉｎｔｏ ｐｒｏｄｕｃｔｓ（ｐｒｏｄｕｃｔ＿ｉｄ，ｐｒｏｄｕｃｔ＿ｐｒｉｃｅ）Ｖａｌｕｅｓ（９７００，１５．００）
を検討する。第１のコマンドは、副次的影響を伴うデータ修正コマンドであり、第２のものは、ｒａｎｄｏｍ（）を含む、非決定論的データ挿入コマンドであり、第３のものは、決定論的データ挿入コマンドである。

第１の２つのコマンドに対して、単一ノードが、最初に、それらを実行し、その結果を入手し、これらの結果を対応する中継ファイルにログ付けし、再現のためにこの中継ファイルを別のノードに複製する必要がある。そうでなければ、２つの別個のノードは、ｒａｎｄｏｍ（）に対して、２つの異なる結果を生成し、互に一貫していない可能性がある。同様に、ｎｏｗ（）等の関数を実行するか、またはｓｅｒｉａｌ等の自動インクリメント列値をインクリメントする、２つの別個のノードは、異なる値を生成し得る。より一般的には、データ修正コマンド、データ削除コマンド、および非決定論的データ挿入コマンドは、最初に、単一ノードで実行される必要がある。この実行の結果は、次いで、中継ファイルにログ付けされ、中継ファイルを介して、複製される。

別の実施形態では、データベーステーブル更新は、より多くの限られたコマンドの組を表す。すなわち、これらのコマンドは、決定論的データ挿入およびデータロードコマンドを含む。これらのコマンドは、２つの異なるノード上で２つの異なる値を生成するリスクを課さず、したがって、実行に先立って、異なるノードにわたって複製されることができる。いったん挿入またはロードコマンドが、異なるノードに複製されると、ノードは、独立して、コマンドを適用し、それをその中継ファイルにアペンドすることができる。

中継ファイル（アペンド専用ログファイル）が、ネットワークにわたって転送される必要があるとき、アペンド専用ログファイルは、ネットワークトラフィックを低減させるために圧縮され得る。アペンド専用ログファイルはまた、データ修正およびデータ削除コマンドによって割り当てられた空間を再利用するために圧縮され得る。この圧縮化は、新しいアペンド専用ログファイルを作成する形態で生じ得る。さらに、アペンド専用ログファイルは、データへの論理変更を記憶しているので、ファイルは、アペンド専用ログファイルとデータベースとの間のコネクタが利用可能であることを前提として、異なるベンダからのデータベースとともに使用されることができる。

図４および６に関して示されるように、アペンド専用ログファイルは、最後に書き込まれたバイトオフセットおよび最後に適用されたバイトオフセットを維持し得る。加えて、データベーステーブル更新をアペンド専用ログファイルに追加することは、データベーステーブル更新のためのチェックサムを計算および追加することを含み得る。データベーステーブルパーティションまたはアペンド専用ログファイルのサイズは、構成可能であり得る。一実施形態では、データベーステーブルパーティションは、システム１００にわたって認識される、一意の識別子を有する。この一意の識別子は、アペンド専用ログファイル内のログエントリにハードコード化され得、またはログファイル名の中に抽象化され得る。

本発明の中継ファイル技法はさらに、テーブル結合と関連して利用されることができる。図８は、順序テーブルパーティション８０２および顧客テーブルパーティション８０４を伴う第１のノード８００を図示する。別のノード８０６は、順序テーブルパーティション８０８および顧客テーブルパーティション８１０を有する。順序テーブルおよび顧客テーブルは、示されるように、異なるノードにわたって分散される、大容量テーブルである。テーブルは、テーブルのコストがかかりすぎ、システム内の全ノードに全体として複製することができないとき、大容量と見なされ得る。

順序テーブルは、ｏｒｄｅｒ＿ｉｄに基づいてパーティション分割され、および顧客テーブルは、ｃｕｓｔｏｍｅｒ＿ｉｄに基づいてパーティション分割される。これらの２つのテーブルが、クエリをサポートするために一緒に結合される必要がある場合、順序テーブルは、システム内の全ノードにわたって、ｃｕｓｔｏｍｅｒ＿ｉｄに基づいて、再パーティション分割される必要がある。既存のデータベースソリューション（恐らく、フィルタ処理射影または他の動作の適用後）が、テーブル全体を再パーティション分割し、ネットワークにわたって、再パーティション分割されたテーブルを転送する。これは、ベースデータへの変更を追跡することは困難であるので、ほぼ全ての結合において生じる。分散型データベースの実践的用途では、再パーティション分割されたテーブルは、膨大であり、単一ノード上に記憶されることができない。したがって、有意なデータ処理およびデータ転送が、再パーティション分割動作を支持するために、全ての結合において必要とされる。

図９は、ノード８００および８０６が、順序テーブルを一緒に保持する、本発明の実施形態を図示する。分散型データベースは、順序および顧客テーブルを結合することを要求する、解析クエリを受信する。分散型データベースは、再パーティション分割のための順序テーブルを選定し、テーブルパーティション８０２および９０８がｃｕｓｔｏｍｅｒ＿ｉｄに基づいて再パーティション分割されるように命令する。分散型データベースはまた、再パーティション分割方法を範囲パーティション分割として指定し、データが２つの範囲に再パーティション分割されるべきことを決定する。その結果、ノード８００は、ｃｕｓｔｏｍｅｒ＿ｉｄ次元に基づいて、テーブル８０２を再パーティション分割し、再パーティション分割されたデータの一部をローカルで保つ一方、他の部分をノード８０６に転送する。ノード８０６は、類似動作を行なう。総合して、これらの動作は、４つのデータ再パーティションをもたらす。ノード８００は、データ再パーティションのうちの２つを取り込み、それらを再パーティション分割されたテーブル９０４にマージする。同様に、ノード８０６は、２つのデータ再パーティションをテーブル９１２にマージする。最後に、分散型データベースは、再パーティション分割されたテーブル９０４と顧客テーブル８０４と結合し、再パーティション分割されたテーブル９１２と顧客テーブル８１０を結合し、解析クエリに応答する。

テーブル再パーティション分割方法またはデータ転送機構の詳細は、状況に応じて、異なり得る。例えば、テーブルは、ハッシュまたは範囲パーティション分割を使用して、再パーティション分割され得る。同様に、再パーティション分割されたデータは、ストリーミング様式において、ノード間で転送され得、または転送前に、中間ファイルに書き込まれ得る。

前述の初期テーブル再パーティション動作後、より多くの変更が、ベーステーブルパーティションに適用され得る。第２のテーブル再パーティションが、次いで、発行されると、開示される方法は、最新の変更のみを再パーティション分割およびシャッフルする必要がある。

図９は、再パーティション分割されたテーブル９０４に適用される例示的変更９１４、および再パーティション分割されたテーブル９１２に適用される変更９１６を図示する。図１０は、変更９１４および９１６に対応する、データ表現１０００を図示する。

要するに、開示される方法は、最新の変更のみ再パーティション分割し、ベースデータにマージし、有利には、データセット全体を再パーティション分割する必要がある従来技術方法に匹敵する。開示される方法では、中継ファイルだけを再パーティション分割し、再パーティション分割されたデータを既存の再パーティション分割された中継ファイルにアペンドすることができる。その結果、データの再パーティション分割およびシャッフルの不利益は、１回しか被られない。初期再パーティション分割後、新しい挿入、更新、および削除のみ、再パーティション分割される必要がある。

データは、アペンド専用中継ファイル内に維持されるので、最後のクエリ実行時間以降のいかなる新しい変更も容易に決定することができる。これらの変更を再パーティション分割し、それらを中継ファイルにアペンドし、それらをデータベースに対して中継することができる。中継ファイルの使用は、データウェアハウス内のファクトテーブルが、アペンド専用であり、ディメンションテーブルが、比較的に小さく、稀に変更されるため、この状況では、妥当である。

これらの動作は、図１１を参照して、より完全に理解される。図１１は、順序テーブルパーティション１１０２および顧客テーブルパーティション１１０４を伴う第１のノード１１００を図示する。順序パーティション１１０２は、順序パーティションを別のノード上に構築するために使用され得る、対応する中継ファイル１１０８を有する。ノード１１００はまた、ノード１１００上のテーブル１１０２およびノード１１１２上のテーブルパーティション１１１４の再パーティションである、再パーティション分割された順序テーブル１１０６を有する。テーブル１１０６は、対応する中継ファイル１１１０を有する。再パーティション分割された中継ファイル１１１０は、矢印１１１６によって示されるように、中継ファイル１１０８からのエントリを受信する。

順序テーブルパーティション１１１４は、対応する中継ファイル１１１８を有する。ノード１１１２はまた、顧客パーティション１１２０と、対応する中継ファイル１１２４を有する再パーティション分割された順序テーブル１１２２とを有する。中継ファイル１１２４は、矢印１１２６によって示されるように、中継ファイル１１１８からのエントリと、矢印１１２８によって示されるように、中継ファイル１１０８からのエントリとを有する。

図１２は、更新を受信した後の図１１の構成要素を図示する。中継ファイル１１０８は、行１２０２に示されるように、再パーティション分割された中継ファイル１１１０にパスされる、更新１２００を受信する。この変更は、次いで、矢印１２０４に示されるように、再パーティション分割されたテーブル１１０６に再現される。同様に、中継ファイル１１１８は、矢印１２１０によって示されるように、再パーティション分割された中継ファイル１１１０にパスされる、更新１２０６を受信する。加えて、中継ファイル１１１８は、矢印１２１２によって示されるように、再パーティション分割された中継ファイル１１２４にパスされる、更新１２０８を受信する。順に、この変更は、矢印１２１４によって示されるように、テーブル１１２２に適用される。

したがって、データ変更は、中継ファイル（アペンド専用ファイル）で受信される。アペンド専用ファイルと再パーティション分割されたファイルとの間のマッピングが、次いで、再パーティション分割されたファイル内で変更を行うために使用される。アペンド専用ファイルは、データ挿入、ロード、更新、削除、およびデータ記述言語（ＤＤＬ）動作を含み得る。アペンド専用ファイルは、テキストファイル、バイナリファイル、またはログファイルであり得る。

アペンド専用ファイルは、元となるデータが、決定論的挿入およびロード動作のみを含むとき、テキストファイルとしてより良好に表される。その場合、テキストファイルは、データベーステーブルのコンテンツを容易に表すことができる。実際、テキストファイルは、データベーステーブルのコンテンツを表すために、追加のデータベースファイルさえ必要としないこともある。例えば、コンマで分離されたテキストファイルは、データベーステーブルを表し得、改行は、行を分離し、コンマは、列を分離する。さらに、このテキストファイルは、ノード間で転送が容易である。テキストファイルは、既に、データを論理表現内に保っており、システムは、ノードにわたるデータの異なる物理的表現について懸念する必要はない。受信されたデータベースクエリは、パーティション分割され、再パーティション分割されたファイルにわたって並行して起動し得る。マスタノードモジュール１２２は、再パーティション分割されたファイル内のデータに関する統計を維持し得る。統計は、次いで、クエリに関連しない再パーティション分割されたファイルを取り除こうとするクエリの間、使用され得る。マスタノードモジュール１２２はまた、データ転送前に、フィルタ処理および射影動作の適用等、他のクエリ最適化技法を採用し、ネットワークにわたって転送されるデータの量を削減し得る。マスタノードモジュール１２２は、再パーティション分割されたファイルの数を決定するための構成値および再パーティション分割されたファイルの最大サイズを決定するための構成値をサポートし得る。構成値はまた、データベーステーブルパーティションの最大サイズを指定するために使用され得る。データベーステーブルパーティションまたは再パーティション分割されたファイルが、その構成される最大サイズを超える場合、自動的に、より小さいパーティションまたは再パーティションファイルに分割され得る。これらのより小さいパーティションまたは再パーティションファイルに関する統計が、次いで、マスタノードモジュール１２２に報告され得る。

さらに、マスタノードモジュール１２２は、データベーステーブルパーティションまたは再パーティション分割されたファイルをモジュール式ブロックとして表し得る。この表現は、小データベーステーブルが、いくつかのモジュール式ブロックで表され、これらのブロックが、システム内の全ノードに容易に複製され、効率的テーブル結合を行なうことができるという利点を有する。また、モジュール式ブロックの更新は、容易に追跡され、複製ブロックに伝搬されることができる。

対比して、従来技術方法は、モジュール式ブロックではなく、ノードにデータをパーティション分割する。その結果、小容量テーブルは、多数のデータベーステーブルパーティションにパーティション分割され得、これらのパーティションは全て、全ノードに複製される必要があり得る。例えば、５０個のノードを伴うシステムでは、テーブル結合コマンドは、データベーステーブルのサイズが小さい場合でも、２，５００個の複製動作をもたらし得る。さらに、データベーステーブルの後続更新もまた、追跡および伝搬がより困難となる。

言い換えると、モジュール式ブロックは、テーブル結合が小容量テーブルを伴うとき、利点を導入する。例えば、１つの小容量テーブルおよび２つの大容量テーブルを伴うテーブル結合コマンドに応答するために、小容量テーブルが、システム内の全ノードに複製され得、１つの大容量テーブルが、別の大容量テーブルのパーティション次元上に再パーティション分割され得る。大容量テーブルと小容量テーブルとの間の区別は、複数の方法で定義され得る。方法の１つは、大容量テーブルが有すべき分割データベースの最小数を定義するための構成値を提供することによって、ユーザに定義を任せ得る。別の方法は、システム内の全ノードに対してテーブルを全体として複製するコストを測定し得、そのコストを元となるデータを再パーティション分割するコストに対して比較検討し得る。

データの再パーティション分割は、自動的に、テーブル結合または個別のカウントコマンドによって開始され得る。ベーステーブルが再パーティション分割されると、再パーティション分割されたファイルは、テーブル結合コマンドを行なうために使用され得る。このテーブル結合コマンドは、より具体的には、内部結合、左側外部結合、右側外部結合、完全外部結合、半結合、またはアンチ結合を表し得る。代替として、テーブルデータの再パーティション分割はまた、手動データベースコマンドによって開始され得る。

例えば、ユーザが、テーブルが別の次元において頻繁にアクセスされることを把握している場合、ユーザは、Ｃｒｅａｔｅ Ｔａｂｌｅ ＡｓまたはＳｅｌｅｃｔ Ｉｎｔｏコマンドを使用することによって、再パーティション分割されたテーブルを手動で作成し得る。

一般に、各データベーステーブルパーティションは、単一アペンド専用中継ファイルを有するであろう。データベーステーブルパーティションは、システム１００の異なるノード１０４にわたって分散および複製される。

本発明の実施形態は、種々のコンピュータ実装動作を行なうためのコンピュータコードを有するコンピュータ読み取り可能な記憶媒体を伴うコンピュータストレージ製品に関する。媒体およびコンピュータコードは、本発明の目的のために、特別に設計および構築されたものであり得、またはコンピュータソフトウェア技術分野における当業者に周知かつ利用可能な種類であり得る。コンピュータ読み取り可能な媒体の実施例として、ハードディスク、フロッピー（登録商標）ディスク、および磁気テープ等の磁気媒体；ＣＤ−ＲＯＭ、ＤＶＤ、およびホログラフィックデバイス等の光学媒体；磁気光学媒体；ならびに特定用途向け集積回路（「ＡＳＩＣ」）、プログラマブル論理デバイス（「ＰＬＤ」）、ならびにＲＯＭおよびＲＡＭデバイス等のプログラムコードを記憶および実行するように特別に構成される、ハードウェアデバイスが挙げられるが、それらに限定されない。コンピュータコードの実施例として、コンパイラによって生成されるような機械コード、およびインタープリタを使用して、コンピュータによって実行される、高次コードを含むファイルが挙げられる。例えば、本発明の実施形態は、（登録商標）ＪＡＶＡ（登録商標）、Ｃ＋＋、または他のオブジェクト指向プログラミング言語および開発ツールを使用して、実装され得る。本発明の別の実施形態は、機械実行可能ソフトウェア命令の代わりに、またはそれと組み合わせて、有線回路内に実装され得る。

前述の説明は、説明目的のために、本発明の完全理解を提供するために具体的専門用語を使用した。しかしながら、具体的詳細が、本発明を実践するために要求されないことは、当業者に明白であろう。したがって、本発明の具体的実施形態の前述の説明は、例証および説明目的のために提示される。それらは、包括的である、または本発明を開示される精密な形態に限定することを意図するものではない。明らかに、多くの修正および変形例が、前述の教示に照らして、可能性として考えられる。実施形態は、本発明の原理およびその実践的用途を最も良く説明するために選定および説明され、それによって、他の当業者が、想定される特定の使用に好適な種々の修正を伴って、本発明および種々の実施形態を最も良く利用することを可能にする。以下の請求項およびその均等物は、本発明の範囲を定義することが意図される。

Claims (20)

1. システムであって、
   マスタノードと、
   前記マスタノードによって制御される複数のワーカノードであって、各ワーカノードは、分散型データベースパーティションの２５個以上のモジュール式ブロックを記憶し、各モジュール式ブロックは、前記分散型データベースパーティションと関連付けられたデータのセグメントを保持し、前記分散型データベースパーティションの各モジュール式ブロックは、５Ｇバイト以下のサイズを有し、前記分散型データベースパーティションと関連付けられた変更を記録する関連付けられたログファイルを有し、前記分散型データベースパーティションと関連付けられた前記変更は、前記データのセグメントの物理的表現から独立している論理表現で記録される、ワーカノードと
   を備え、
   前記マスタノードおよび前記複数のワーカノードは、標準的ネットワーク接続およびプロトコルを利用して分散型ネットワークを経由して通信する汎用サーバである、システム。
2. 前記マスタノードは、データベースクエリを受信し、前記データベースクエリをパーティション分割し、前記複数のワーカノードにわたって並行して起動する、請求項１に記載のシステム。
3. 前記マスタノードは、前記モジュール式ブロック内のデータに関する統計を収集する、請求項１に記載のシステム。
4. 前記マスタノードは、前記統計を使用して、データベースクエリを最適化する、請求項３に記載のシステム。
5. 前記マスタノードは、モジュール式ブロックの場所、サイズ、関連付けられたログファイル、および更新時間から選択される統計を収集する、請求項３に記載のシステム。
6. 前記マスタノードは、前記複数のワーカノードと通信し、前記統計を更新する、請求項５に記載のシステム。
7. 前記マスタノードは、前記複数のワーカノードに対する可用性情報を維持する、請求項１に記載のシステム。
8. 前記マスタノードは、前記複数のワーカノードにわたって前記モジュール式ブロックに対する分散情報を維持する、請求項１に記載のシステム。
9. 前記マスタノードは、前記複数のワーカノードに対する前記可用性情報を使用して、新しいモジュール式ブロックの配置を決定する、請求項７に記載のシステム。
10. 前記マスタノードは、前記モジュール式ブロックに対する前記分散情報に基づいて、新しいモジュール式ブロックの配置を決定する、請求項８に記載のシステム。
11. 前記マスタノードは、前記複数のワーカノードにわたってモジュール式ブロックを再分散させる、請求項１に記載のシステム。
12. 前記マスタノードは、前記可用性情報に基づいて、モジュール式ブロックを再分散させる、請求項７に記載のシステム。
13. 前記マスタノードは、前記モジュール式ブロックに対する前記分散情報に基づいて、モジュール式ブロックを再分散させる、請求項８に記載のシステム。
14. 前記マスタノードは、前記複数のワーカノードにわたってモジュール式ブロックの複製を制御する、請求項１に記載のシステム。
15. 前記マスタノードは、前記複数のワーカノードに対する可用性情報に基づいて、前記モジュール式ブロックの複製を制御する、請求項１４に記載のシステム。
16. 前記マスタノードは、前記モジュール式ブロックに対する分散情報に基づいて、前記モジュール式ブロックの複製を制御する、請求項１４に記載のシステム。
17. 複製は、構成可能パラメータである、請求項１４に記載のシステム。
18. 前記モジュール式ブロックは、５ＧＢ未満の任意の値に構成可能なサイズを有する、請求項１に記載のシステム。
19. 前記マスタノードは、現在のモジュール式ブロックが最大サイズを超えると、新しいモジュール式ブロックを生成する、請求項１に記載のシステム。
20. 前記マスタノードは、現在のモジュール式ブロックが最大サイズを超えると、前記現在のモジュール式ブロックからの情報の半分を有する新しいモジュール式ブロックを生成する、請求項１に記載のシステム。

Images