Dwh-partitioning-strategy
データウェアハウジング-パーティショニング戦略
パーティション化は、パフォーマンスを向上させ、データの管理を容易にするために行われます。 パーティショニングは、システムのさまざまな要件のバランスを取るのにも役立ちます。 各ファクトテーブルを複数の個別のパーティションに分割することにより、ハードウェアのパフォーマンスを最適化し、データウェアハウスの管理を簡素化します。 この章では、さまざまなパーティション戦略について説明します。
分割する必要があるのはなぜですか?
パーティションは次の理由で重要です-
- 管理を容易にするために、
- バックアップ/リカバリを支援するために、
- パフォーマンスを向上させるため。
簡単な管理のために
データウェアハウスのファクトテーブルは、サイズが数百ギガバイトまで拡大する可能性があります。 この巨大なファクトテーブルは、単一のエンティティとして管理するのが非常に困難です。 したがって、パーティション化が必要です。
バックアップ/リカバリを支援するには
ファクトテーブルをパーティション分割しない場合、すべてのデータを含む完全なファクトテーブルをロードする必要があります。 パーティショニングにより、定期的に必要なデータだけをロードできます。 ロード時間を短縮し、システムのパフォーマンスも向上します。
注-バックアップサイズを削減するために、現在のパーティション以外のすべてのパーティションを読み取り専用としてマークできます。 その後、これらのパーティションを変更できない状態にすることができます。 その後、それらをバックアップできます。 これは、現在のパーティションのみがバックアップされることを意味します。
パフォーマンスを向上させる
ファクトテーブルをデータセットに分割することにより、クエリプロシージャを強化できます。 クエリが関連するパーティションのみをスキャンするようになったため、クエリのパフォーマンスが向上しました。 データ全体をスキャンする必要はありません。
水平分割
ファクトテーブルをパーティション分割するには、さまざまな方法があります。 水平分割では、データウェアハウスの管理性の要件を考慮する必要があります。
時間による等しいセグメントへの分割
このパーティション分割戦略では、期間に基づいてファクトテーブルがパーティション分割されます。 ここで、各期間は、ビジネス内の重要な保持期間を表しています。 たとえば、ユーザーが*月間のデータ*を照会する場合、データを月単位のセグメントに分割するのが適切です。 パーティションテーブル内のデータを削除することで、パーティションテーブルを再利用できます。
時間ごとに異なるサイズのセグメントに分割
この種のパーティションは、古くなったデータにアクセスする頻度が低い場所で行われます。 比較的最新のデータには小さなパーティションのセットとして、非アクティブなデータには大きなパーティションのセットとして実装されます。
注意点
- 詳細情報は引き続きオンラインで入手できます。
- 物理テーブルの数は比較的少なく抑えられ、運用コストが削減されます。
- この手法は、最近の履歴に浸るデータと履歴全体のデータマイニングの組み合わせが必要な場合に適しています。
- 再パーティション化はデータウェアハウスの運用コストを増加させるため、この手法はパーティション化プロファイルが定期的に変更される場合には役立ちません。
異なる次元のパーティション
ファクトテーブルは、製品グループ、地域、サプライヤー、またはその他のディメンションなど、時間以外のディメンションに基づいてパーティション化することもできます。 例を見てみましょう。
市場機能が、*州ごと*のように、別個の地域部門に構成されているとします。 各地域がその地域内でキャプチャされた情報を照会する場合、ファクトテーブルを地域パーティションに分割するとより効果的であることがわかります。 これにより、関係のない情報をスキャンする必要がないため、クエリの速度が向上します。
注意点
- クエリは、クエリプロセスを高速化する無関係なデータをスキャンする必要はありません。
- この手法は、将来ディメンションが変更される可能性が低い場合には適切ではありません。 したがって、ディメンションが将来変更されないことを判断する価値があります。
- ディメンションが変更された場合、ファクトテーブル全体を再パーティション化する必要があります。
注-推奨されるディメンショングループがデータウェアハウスの有効期間内に変更されないことが確実でない限り、時間ディメンションに基づいてのみパーティションを実行することをお勧めします。
テーブルのサイズによるパーティション
ディメンションでファクトテーブルをパーティション分割する明確な根拠がない場合は、*サイズに基づいてファクトテーブルをパーティション分割する必要があります。*所定のサイズをクリティカルポイントとして設定できます。 テーブルが所定のサイズを超えると、新しいテーブルパーティションが作成されます。
注意点
- このパーティショニングは管理が複雑です。
- 各パーティションに保存されているデータを識別するためのメタデータが必要です。
分割寸法
ディメンションに多数のエントリが含まれる場合、ディメンションをパーティション化する必要があります。 ここでは、ディメンションのサイズを確認する必要があります。
時間の経過とともに変化する大規模な設計を検討してください。 比較を適用するためにすべてのバリエーションを保存する必要がある場合、そのディメンションは非常に大きくなる可能性があります。 これは間違いなく応答時間に影響します。
ラウンドロビンパーティション
ラウンドロビン手法では、新しいパーティションが必要になると、古いパーティションがアーカイブされます。 メタデータを使用して、ユーザーアクセスツールが正しいテーブルパーティションを参照できるようにします。
この手法により、データウェアハウス内のテーブル管理機能を簡単に自動化できます。
垂直パーティション
垂直分割、データを垂直に分割します。 次の図は、垂直分割がどのように行われるかを示しています。
垂直分割は、次の2つの方法で実行できます-
- 正規化
- 行分割
正規化
正規化は、データベース編成の標準的なリレーショナル方式です。 この方法では、行が単一の行に縮小されるため、スペースが削減されます。 正規化の実行方法を示す次の表をご覧ください。
正規化前の表
Product_id | Qty | Value | sales_date | Store_id | Store_name | Location | Region |
---|---|---|---|---|---|---|---|
30 | 5 | 3.67 | 3-Aug-13 | 16 | sunny | Bangalore | S |
35 | 4 | 5.33 | 3-Sep-13 | 16 | sunny | Bangalore | S |
40 | 5 | 2.50 | 3-Sep-13 | 64 | san | Mumbai | W |
45 | 7 | 5.66 | 3-Sep-13 | 16 | sunny | Bangalore | S |
正規化後の表
Store_id | Store_name | Location | Region |
---|---|---|---|
16 | sunny | Bangalore | W |
64 | san | Mumbai | S |
Product_id | Quantity | Value | sales_date | Store_id |
---|---|---|---|---|
30 | 5 | 3.67 | 3-Aug-13 | 16 |
35 | 4 | 5.33 | 3-Sep-13 | 16 |
40 | 5 | 2.50 | 3-Sep-13 | 64 |
45 | 7 | 5.66 | 3-Sep-13 | 16 |
行分割
行分割は、パーティション間で1対1のマップを残す傾向があります。 行分割の動機は、サイズを小さくすることで大きなテーブルへのアクセスを高速化することです。
注意-垂直分割を使用しているときは、2つのパーティション間で主要な結合操作を実行する必要がないことを確認してください。
パーティションのキーを特定する
適切なパーティションキーを選択することは非常に重要です。 間違ったパーティションキーを選択すると、ファクトテーブルが再編成されます。 例を見てみましょう。 次のテーブルをパーティション分割するとします。
Account_Txn_Table
transaction_id
account_id
transaction_type
value
transaction_date
region
branch_name
任意のキーでパーティションを選択できます。 2つの可能なキーは
- 領域
- transaction_date
ビジネスが30の地理的地域で構成されており、各地域の支店数が異なるとします。 これにより、30個のパーティションが得られますが、これは妥当です。 要件のキャプチャにより、クエリの大部分がユーザー自身のビジネス地域に制限されていることが示されているため、このパーティションは十分に優れています。
リージョンではなくtransaction_dateでパーティション化すると、すべてのリージョンからの最新のトランザクションが1つのパーティションになります。 これで、自分の地域内のデータを確認したいユーザーは、複数のパーティションをクエリする必要があります。
したがって、適切なパーティション化キーを決定する価値があります。