分散パーティション ビューのデザイン
分散パーティション ビューを設計し、複数のデータベース サーバーを連携させる場合は、次の事項を検討してください。
アプリケーションによって実行される SQL ステートメントのパターンを判別します。
テーブルが互いにどのように関連しているのかを判別します。
外部キーを分析することで、SQL ステートメントの頻度と、定義されたパーティションを比較検討します。
SQL ステートメントのルーティング ルールを定義します。
アプリケーションによって実行される SQL ステートメントのパターン
通常の処理でアプリケーションによって実行される SQL ステートメントの一覧を作成します。一覧を SELECT、UPDATE、INSERT、および DELETE のカテゴリに分割し、実行の頻度に基づいて各カテゴリの一覧を順序付けします。SQL ステートメントでストアド プロシージャを参照する場合は、そのストアド プロシージャから、ベースとなる SELECT、INSERT、UPDATE、および DELETE ステートメントを使用します。既存の SQL Server データベースにパーティションを設定する場合は、SQL Server Profiler を使用してこの一覧を取得できます。
分散パーティション ビューが最もよく機能するような通常のオンライン トランザクション処理 (OLTP) または Web サイト データベースでは、SQL ステートメントの頻度を利用することによって、適切な近似値が得られます。このようなシステムには、個々の SQL ステートメントが、意志決定支援 (OLAP) システムの各種クエリと比較して、より小さな量のデータを取得するという特徴があります。SQL ステートメントが参照するデータ量が少ない場合は、単純に各ステートメントの頻度を調べることで、システムのデータ トラフィックの現実的な近似値が得られます。ただし、多くのシステムでは、大量のデータを参照する SQL ステートメントのグループがあります。場合によっては、より大きなデータ要件を反映するために、それらのクエリを加重するための追加のステップが必要になります。
テーブルのリレーションシップ
同じディメンション (部品番号、部署番号など) に沿ってパーティション分割できるテーブルのクラスタを検索して、そのディメンションの個別の発生に関連するすべての行が同じメンバ サーバーに格納されるようにすることを目的としています。たとえば 1 つの方法として、データベースを地域ごとにパーティション分割する方法が考えられます。そのためには、キーに地域番号を持たないテーブルについても、地域に関連する方法でパーティション分割が可能でなければなりません。そのようなデータベースでは、Customer テーブルに地域番号の列がない場合でも、地域が州または郡の集合として定義されていれば、Customer.StateProvince 列を使用することで、地域に関連する方法による顧客のパーティション分割が可能です。
明示的な外部キーおよび暗黙的な外部キーは、テーブル間のリレーションシップを定義しているので、データのパーティション分割の方法を探すうえで最も重要な要素です。明示的な外部キーの定義を調べ、クエリが通常 1 つのテーブルの行をどのように利用して、別のテーブルの行を検索しているのかを判別します。さらに、具体的な外部キーの定義がない場合にも、暗黙的な外部キー、つまり結合演算において SQL ステートメントが 1 つのテーブルの行の値を使用して別のテーブルの行を参照する方法を調べます。暗黙的な外部キーはデータベースのスキーマの一部として明示的に定義されないので、アプリケーションによって生成された SQL ステートメントを調べて、非キー列を使用してテーブルを結合するステートメントがあるかどうか判別する必要があります。この暗黙的な外部キーでは、通常、結合のパフォーマンスを向上させるためにインデックスが作成されています。したがって、データベースで定義済みのインデックスも確認する必要があります。
パーティションに対する SQL ステートメントの頻度
外部キーを分析することで、SQL ステートメントの頻度と、定義されたパーティションを比較検討します。アプリケーションの複数の SQL ステートメントを最もよくサポートするパーティション分割を選択します。一部のテーブルが複数の方法でパーティション分割できる場合は、SQL ステートメントの頻度を基準にして、最も多くの SQL ステートメントを満たすパーティションはどれなのかを判別します。SQL ステートメントによって最も頻繁に参照されるテーブルを、最初にパーティション分割するテーブルにしてください。テーブルが参照される頻度に基づいて、テーブルをパーティション分割する順序に優先順位を付けます。
SQL ステートメントのパターンも、テーブルをパーティション分割する必要の有無の判断に影響します。
テーブルを参照するステートメントの 5% を超えるステートメントが INSERT、UDATE、または DELETE ステートメントであり、選択したディメンションに沿ってテーブルをパーティション分割可能な場合には、テーブルをパーティション分割します。
テーブルを参照するステートメントの 5% 未満が INSERT、UPDATE、または DELETE ステートメントである場合には、各メンバ サーバーのテーブルの完全なコピーを保持します。また、そのテーブルのすべてのコピーが更新されるように、更新を行う方法を定義する必要もあります。高いトランザクション整合性が必要な場合は、分散トランザクションのコンテキスト内ですべてのコピーの分散更新を実行するトリガを記述することができます。高いトランザクション整合性が不要な場合は、SQL Server レプリケーション メカニズムの 1 つを使用して、テーブルの 1 つのコピーから他のすべてのコピーに更新を伝達することができます。
テーブルを参照するステートメントの 5% を超えるステートメントが INSERT、UPDATE、または DELETE ステートメントであり、選択したディメンションに沿ってテーブルをパーティション分割できない場合には、テーブルをパーティション分割またはコピーしないでください。
SQL ステートメントのルーティング ルール
ルーティング ルールでは、各 SQL ステートメントを最も効果的に処理できるのはどのメンバ サーバーか定義する必要があります。つまり、ユーザー入力のコンテキストと、ステートメントを完了するために必要な一連のデータが格納されているメンバ サーバーとのリレーションシップを確立できなければなりません。アプリケーションでは、ユーザーが入力したデータを取り出し、ルーティング ルールと照らし合わせて、どのメンバ サーバーで SQL ステートメントを処理すべきかを判別する必要があります。