Greenplum のさまざまなクエリ タイプの最適なパーティショニング/インデックス作成のための適切な戦略を定義するための一般的なガイドライン (試行錯誤を超えて) があるかどうかを知る必要がありますか?
Greenplum は管理ガイドにいくつかのアドバイスを提供しています...しかし、真実は、それはほぼ postgres ドキュメントからのコピーペーストであり、そのアドバイスの一部は明らかなように見えますが (IE: テーブルが大きすぎてメモリに収まらない場合のパーティション)、それはこれを達成するための優れた戦略を定義するには十分ではありません。
通常、Greenplum データベースには非常に大きなテーブル (数百 GB を超える範囲) があり、ハードウェアはこの種の使用のために特別に選択されていますが、ほとんどの場合、非常に大きなデータベースになると問題に遭遇しました (IE: かつてデータベースがあった60 フィールドのテーブルと 2 億行を超える行があり、そのサイズは 1 日あたり 400 万から 800 万のレジストリで増加し続けています)。
適切なパーティションを選択するには、ほぼ同じサイズ (日付範囲など) で区切られる予測可能な範囲を選択するなど、いくつかの手法があることを知っています。しかし、他のデータベースではインデックスに頼ろうとしますが、Greenplum は、インデックスがまったく使用されないように、ランダム ページ コストなど、いくつかの設定により大きな重みを与えることで、それらを完全に思いとどまらせるという事実もあります。
しかし、これが完全に非生産的であるいくつかの状況を読みました: GP によると、テーブルが 192 を超えるまでパーティション分割を行うべきではありませんが、インデックスが使用されていないため、それぞれ 64GB RAM の 3 つのノードがあるとします。ノードあたり最大 64 GB の seq スキャン! --- これでも高速ですが、インデックスの使用を強制すると、20 秒以上からわずか数ミリ秒に短縮できます。
もう 1 つの既知のケースは、パーティショニング時に、オーバーヘッドによりクエリが本来よりも大幅に遅くなるというものです。
それでは、元の質問に戻り
ます。パーティショニング/インデックス作成戦略を定義する方法について、適切で確固たるアドバイスはありますか?
一部の ETL では、ソースからのテスト クエリに 30 分から 1 時間かかることがあるため、試行錯誤によって生産性が大幅に低下します。
ありがとう。