問題タブ [paraccel]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
analytics - ParAccelに相当するFastLoad(Teradata)とは何ですか?
最近、TeradataからParAccelに移行し、SAS環境でBIDBMSを使用しています。Teradataには、FastLoad
大規模なデータセットを高速かつ効率的にロードするために必要なこのユーティリティがあります。SASライブラリからTeradataにデータセットを転送するには、このユーティリティを利用する必要があります。ParAccelにも同様のユーティリティ/コマンド/関数があるかどうか知りたいです。どんな助けでもありがたいです。
amazon-redshift - 関数またはストアド プロシージャを使用しない Amazon RedShift でのアップサート
RedShift ではユーザー定義関数またはストアド プロシージャがサポートされていないためUPSERT
、PostgreSQL 8.0.2 フォークである ParAccel を使用している RedShift でメカニズムを実現するにはどうすればよいですか。
現在、私は IF...THEN...ELSE... ステートメントを使用して UPSERT メカニズムを実現しようとしています。
これは私にエラーを与えています。関数やSPに含めずに、このコードを個別に書いているので。それで、UPSERTを達成するための解決策はありますか。
ありがとう
postgresql - postgresql カーソルが更新時に遅い
簡単な序文として、私はpostgresqlの初心者です。さらに、アドバイスが必要なpostgresqlのバージョンは8.1です。その理由は、postgresql 8.1 が、ParAccel によるこの言語の最後の実装およびサポート バージョンであるためです。
Postgresql カーソルは、少なくとも 8.1 では、UPDATE や INSERT などの DML 操作で非常に遅くなります (DELETE はテストしていませんが、同じであると想定しています)。これはデモンストレーションのための単なる例です:
いくつかのテーブルからいくつかのレコードを入力します。
tab_cur_DML_test には、2 つのフィールドのみを持つ数千のレコードが含まれるようになりました
実行後:
速度は、30 秒あたり約 1,000 レコードであることがわかります。
繰り返しますが、これはセットベースの操作として実行できる単純な更新です。ここでは、カーソルを使用して行ごとの処理をシミュレートするためだけに使用しました。行ごとの処理が必要な同様の実際のタスクの状況では、単純な sql を使用してもうまくいかないか、そうでなければかさばりすぎたり複雑すぎたりする状況では、そのような低い処理速度でカーソルを使用するのは簡単です。実行可能なオプションではなくなります。
これは、データベース エンジンのコンテキスト スイッチが原因で発生したと思われます。私の質問は、ParAccel (v. 4.0) で、postgresql 8.1 カーソル内の行ごとのロジックを大幅に改善するための回避策 (または特定の方法) はありますか?
ありがとうございました!
スタニスラフ
amazon-web-services - amazon redshift での同時クエリ パフォーマンス
Amazon Redshift では、同時クエリは相互のパフォーマンスに影響しますか?
たとえば、2 つのクエリがあるとします。1 つは比較的小さなテーブル (~5m 行) ですべての行を取得し、もう 1 つは大きなテーブル (~500m) の行を取得します。どちらのテーブルにも同じフィールドがあり、どちらも圧縮されていません。どちらのクエリも、それぞれのテーブルのすべてのデータを取得して結果を計算します。結合やフィルターはありません。どちらのクエリも、計算のために約 2 ~ 4 個のフィールドを取得します。
単独で実行すると、小さなクエリは約 700 ミリ秒で返されます。ただし、大きなクエリが実行されている間 (それ自体で数分かかります)、小さなクエリは 4 ~ 6 秒で返されます。
これは、単一の XL ノードを持つクラスターで観察された動作です。
これは予想される動作ですか?大きなクエリが実行されている場合でも、小さなクエリのパフォーマンスの一貫性を約束する構成設定はありますか?
amazon-web-services - Amazon Redshift Equality フィルターのパフォーマンスとソートキー
Redshift は、条件 A= を持つクエリの列 A で並べ替えられたテーブルのブロックを効率的に (つまり、バイナリ検索で) 見つけますか?
例として、フィールド A に分散およびソートされた、最大 5 億行、最大 50 フィールドのテーブル T があるとします。 T: 値ごとに最大 100 行。
単一の XL ノードを持つ redshift クラスターを想定します。
フィールド A は圧縮されません。ANALYZE COMPRESSION で提案されているように、他のすべてのフィールドには何らかのフォーム圧縮があります。圧縮されていないテーブルと比較して、1:20 の比率が指定されました。
簡単なクエリが与えられた場合:
VACUUM と ANALYZE の後、次の説明プランが提供されます。
このクエリが完了するまでに 39 秒かかります。
主な質問は次のとおりです。これは赤方偏移の予想される動作ですか?
最適なソートキーの選択のドキュメントによると、
「1 つの列で頻繁に範囲フィルタリングまたは等価フィルタリングを行う場合は、その列をソートキーとして指定します。Redshiftは、最小値を追跡するため、その列のデータブロック全体の読み取りをスキップできます。各ブロックに格納されている列の最大値と、述語範囲に適用されないブロックをスキップできます。」
ソートキーの選択: 「ソートされたデータに依存するもう 1 つの最適化は
、範囲制限された述語の効率的な処理です。Amazon Redshift は、列データを 1 MB のディスク ブロックに格納します。各ブロックの最小値と最大値は、メタデータの一部として格納されます。 If range-restricted column is a sort key, the query processor is able to use the min and max values to immediately skip over large numbers of blocks during table scans. たとえば、テーブルに日付で並べ替えられた 5 年間のデータが格納されている場合、クエリで 1 か月の日付範囲を指定すると、最大 98% のディスク ブロックをスキャンから除外できます. データが並べ替えられていない場合は、より多くのディスク ブロック (おそらくすべて) をスキャンする必要があります.これらの最適化に関する情報については、配布キーの選択を参照してください。 "
二次的な質問:
ソート キーでの前述のスキッピング スキャンの複雑さは何ですか? それは線形 ( O(n) ) ですか、それとも二分探索 ( O(logn) ) の変形ですか?
キーがソートされている場合 - 利用可能な唯一の最適化をスキップしていますか?
説明計画では、この「スキップ」最適化はどのように見えるでしょうか?
上記の説明は、このクエリで可能な最良の説明ですか?
このシナリオを考えると、赤方偏移が提供することが期待できる最速の結果は何ですか?
このユース ケースでは、バニラの ParAccel は異なる動作をしますか?
amazon-web-services - RedShift / ParAccel でディスク上のテーブルスペースを測定する方法
RedShift にテーブルがあります。使用しているディスク容量を確認するにはどうすればよいですか?
amazon-redshift - ParAccel にはどのようなエンコーディングが存在しますか?
誰でも、ParAccel が持つすべての列エンコーディングと、それぞれの説明と例を見つけることができる ParAccel ドキュメントへのリンクを持っていますか?
ありがとう!
amazon-redshift - RedShift / ParAccel での UNION 選択クエリのパフォーマンスが非常に悪い
redshift に 2 つのテーブルがあります。
- tbl_current_day - 約 450 万行
- tbl_previous_day - 約 450 万行、tbl_current_day とまったく同じデータ
それに加えて、次のように定義されたqry_both_daysというビューがあります。
別のテーブルの 1 つでクエリを実行すると、期待どおりの非常に優れたパフォーマンスが得られます。たとえば、次のクエリは 5 秒間実行されます。
計画の説明:
私の列はint型であるため、幅は想定どおり4バイトであることに注意してください。
ただし、qry_both_daysで同じクエリを実行すると、クエリの実行速度は 20 倍遅くなりますが、2 倍の行を超える必要があるため、実行速度は 2 倍しか遅くないと予想されます。
計画の説明:
問題:幅が本来の 4 バイトではなく 190 になりました!!! UNION SELECT で RedShift に関連する列のみを選択させる方法を知っている人はいますか?
ありがとう!
amazon-redshift - RedShift で初めてクエリを実行するときの実行時間が長い
RedShift で初めてクエリを実行すると、3 ~ 10 秒かかることに気付きました。同じクエリを再度実行すると、WHERE 条件の引数が異なっていても、高速に実行されます (0.2 秒)。私が話していたクエリは、3 つの整数列で、約 100 万行のテーブルで実行されます。
この実行時間の大きな違いは、RedShift がクエリを最初に実行したときにコンパイルし、コンパイルされたコードを再利用するという事実によって引き起こされたものですか?
はいの場合 - コンパイルされたクエリのこのキャッシュを常に暖かく保つ方法は?
もう 1 つの質問: queryA と queryB が与えられた場合。queryA が最初にコンパイルおよび実行されたとします。queryB の実行が queryA 用にコンパイルされたコードを使用するように、queryB は queryA とどの程度類似している必要がありますか?