問題タブ [greenplum]

ビューでunnest（）を使用し、selectステートメントでそのビューを使用すると、Greenplumは目的のパーティションの検索に失敗し、代わりにメインテーブルのすべてのパーティションを検索するように見えます。ビューの代わりにサブクエリを使用する場合にも同じことが当てはまります。

例えば：

現在、2つの異なるバージョンのGreenplumを実行している2つの異なるサーバーがあります。サーバーAは古いバージョン（4.2.1）で実行され、サーバーBは4.2.3で実行されます。上記と同じクエリを実行すると、結果が異なります。サーバーA（古い）は数秒でクエリを返しますが、サーバーB（新しい）は戻るのに永遠にかかります。クエリのExplainを実行すると、サーバーAはパーティションの1つ（where句に日付と状態を含む）でのみスキャンを実行し、サーバーBは各パーティションでスキャンを実行するため、速度が低下することがわかります。

両方のDBのテーブル構造は同じです。悪意のないクエリを実行しても問題はありません。ですから、新しいバージョンと関係があるのではないかと思います。この問題を解決するために私にできることはありますか？

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 時間かかることがあるため、試行錯誤によって生産性が大幅に低下します。

ありがとう。

PostgreSQL で特定の月の最後の平日を見つける

使用法: 月末が土曜日または日曜日の場合は前の金曜日を返し、それ以外の場合は月末を使用します

例:

• 2013 年 3 月 31 日は日曜日なので、2013 年 3 月 29 日を返します。
• 2013 年 11 月 30 日は土曜日なので、2013 年 11 月 29 日を返します。

これをPostgreSQL SQLでどのように書くのですか?

私がこれまでに持っているのはこれです（月末のみを返しますが、土曜日または日曜日にあたる場合、月末は存在しません）：

ありがとう

2 つのデータ セットが高価な空間述語で結合されるユース ケースがあります。クエリを並列化するために、同じタイルに属するレコードのみを空間述語でテストする必要があるように、空間ユニバースを (数千のオーダーで) タイルに分割しました。クエリは次のとおりです。

理想的には、クエリ プランは に従ってレコードをハッシュし、インデックス スキャン結合またはネストされたループ結合を使用しtilenameて空間述語チェックを実行する必要があります。ST_Intersects

ただし、私が今得ているのは、空間結合を時期尚早に実行する次善の計画です。計画を以下に示します。

だから、私の質問は次のとおりです。クエリオプティマイザーに、より良いプランを強制的に生成させるにはどうすればよいですか (基本的に結合順序を変更します)。

Greenplum データベースのバージョン: PostgreSQL 8.2.15 (Greenplum データベース 4.2.3.0 ビルド 1)

SQL Server データベースのバージョン: Microsoft SQL Server 2008 R2 (SP1)

現在のアプローチ:

1) 各テーブルを SQL Server からフラット ファイルにエクスポートします。

2) PSQL コンソールの psql.exe ユーティリティを使用して、pgAdmin III でデータを Greenplum にロードします。

利点...

• 速度: わかりましたが、もっと速いものはありますか? 数百万行のデータを数分で読み込みます
  

• 自動化: わかりました。VB のシェル スクリプトを使用して、SSIS パッケージからこのユーティリティを呼び出します。
  

落とし穴...

• 信頼性: ETL は、フラット ファイルを保持するファイル サーバーに依存しています。
  

• セキュリティ: ファイル サーバー上の機密データの可能性がある大量のデータ
  

• エラー処理: 問題です。psql.exe は、エラーが発生し、データや部分的なファイルをロードしない場合でも、キャッチできるエラーを発生させません
  

他に試したことは...

.Net Providers\Odbc Data Provider: DataDirect 6.0 Greenplum Wire Protocol を使用してシステム DSN を構成しました。DELETE の優れたパフォーマンス。INSERT が非常に遅い犬。

参考までに、これは前述の SSIS の VB スクリプトです...

これは「load_MyTable.sql」ファイルの内容です...

一括日付クエリを増分クエリに変換する方法を作成しようとしています。たとえば、クエリに where 条件が次のように指定されている場合

これを今日実行すると、1 年のデータが取得されます。明日同じクエリを実行すると、365 日分のデータが再び取得されます。ただし、前回の実行からの過去 364 日間のデータが既にあります。1 日分のデータを取得し、1 日分のデータをシステムから削除して、365 日分のデータのパフォーマンスを向上させたいだけです。このデータは別の一時テーブルに保存されます。

これを実現するために、次の実行で実行されるインクリメンタル クエリを作成します。ただし、単一の日付データの削除は、その「日付」列が SELECT 句では機能せずに WHERE 条件で機能する場合、一時テーブル スキーマに「日付」列がないため、注意が必要です。

そこで、一括クエリをチャンクで実行し、そのチャンクに ID を割り当てることを考えました。このようにして、チャンクを削除してチャンクを追加しても、他のデータは影響を受けません。

postgresまたはgreenplumで同じことを達成する方法はありますか? いくつかの組み込み機能のように。ドキュメント全体を調べましたが、何も見つかりませんでした。

また、そうでない場合、この問題に対するより良い解決策はありますか。