8

400 万行のテーブルがある場合は IE です。

STATUS次の値を想定できるフィールドがあります: TO_WORK、BLOCKEDまたはWORKED_CORRECTLY.

1 回だけ (ほとんどの場合 to_work から working_correctly に) 変更されるフィールドで分割しますか? いくつのパーティションを作成しますか?

4

2 に答える 2

18

パーティション内の行の絶対数は、最も有用なメトリックではありません。本当に必要なのは、テーブルが大きくなっても安定し、パーティション分割の潜在的な利点を提供する列です。これらは、可用性、テーブルスペース管理、およびパフォーマンスです。

たとえば、例の列には 3 つの値があります。つまり、3 つのパーティションを持つことができるということは、3 つのテーブルスペースを持つことができるということです。したがって、テーブルスペースが破損すると、データの 3 分の 1 が失われます。パーティショニングによってテーブルの可用性が向上しましたか? あまり。

パーティションを追加または削除すると、大量のデータの管理が容易になります。しかし、ステータスが のすべての行WORKED_CORRECTLYを削除する可能性はありますか? 非常にありそうもない。パーティショニングにより、テーブルが管理しやすくなりましたか? あまり。

パーティショニングのパフォーマンス上の利点は、オプティマイザーがテーブルのチャンクをすぐに割り引くことができるクエリ プルーニングから得られます。現在、各パーティションには 130 万行あります。したがって、クエリを実行したとしてもSTATUS='WORKED_CORRECTLY'、選別する膨大な数のレコードがまだ残っています。また、STATUS を含まないクエリは、パーティション分割されていないテーブルに対して実行した場合よりもパフォーマンスが低下する可能性があります。パーティショニングによってテーブルのパフォーマンスは向上しましたか? おそらくそうではありません。

これまでのところ、パーティションが均等に分散されていると想定してきました。しかし、あなたの最後の質問は、そうではないことを示しています。すべてではないにしても、ほとんどの行はWORKED_CORRECTLY. そのため、そのパーティションは他のパーティションに比べて膨大になり、パーティション分割によるメリットの可能性はさらに低くなります。

最後に、提案されたスキームは弾力的ではありません。現在のボリュームとして、各パーティションには 130 万行が含まれます。テーブルが合計で 4,000 万行になると、各パーティションには 1,330 万行が保持されます。これは悪いです。

では、パーティション キーの適切な候補となるのは何でしょうか? 多くのパーティションを生成するもの、パーティションのサイズがほぼ同じもの、キーの値が変更される可能性が低いもの、値が基になるオブジェクトのライフサイクルで何らかの意味を持つもの、最後にテーブルに対して実行される大量のクエリで役立ちます。

これが、DATE_CREATED のようなものが、データ ウェアハウス内のファクト テーブルのパーティション分割に非常に一般的な選択肢である理由です。さまざまな粒度 (日、月、または年が通常の選択) にわたって適切な数のパーティションを生成します。特定の期間に作成されたほぼ同じ数のレコードを取得します。データのロードとデータのアーカイブは、通常、年齢 (つまり、作成日) に基づいて行われます。BI クエリには、ほぼ常に TIME ディメンションが含まれます。

于 2011-07-31T10:48:00.043 に答える
7

通常、テーブル内の行数は、テーブルを分割するかどうか、およびその方法を決定するために使用する優れたメトリックではありません。

どのような問題を解決しようとしていますか? クエリのパフォーマンスを改善しようとしていますか? データロードのパフォーマンス? データのパージのパフォーマンス?

クエリのパフォーマンスを改善しようとしていると思いますか? STATUSすべてのクエリに列の述語がありますか? 行の単一行ルックアップを行っていますか? それとも、クエリでパーティション全体をスキャンしたいですか?

于 2011-07-30T21:04:00.297 に答える