【Redshift】クエリパターンとパフォーマンスから学ぶCompound SortKeyとInterleaved SortKeyのユースケース | DevelopersIO
実行時間はほぼ横ばい。コストはCOMPOUND SORT KEYが一番低く、ソートキーなしとINTERLEAVED SORT KEYは同じ結果に。 -- レコード数1億件未満のテーブル -- セカンダリキーでORDER BY SELECT eventid FROM sales ORDER BY eventid; -- EXPLAIN XN Merge (cost=1000000016724.67..1000000017155.81 rows=172456 width=4) Merge Key: eventid -> XN Network (cost=1000000016724.67..1000000017155.81 rows=172456 width=4) Send to leader -> XN Sort (cost=1000000016724.67..1000000017155.81
パフォーマンスに影響！Redshiftのテーブル設計時に最低限意識すべきポイント3選
Introduction AWSが提供するDWHサービス、Amazon Redshift。 全世界での採用企業は数万社を超えており、弊社も国内において多くのお客様に導入のご支援をさせて頂きました。 RedshiftはAWSエコシステムとの親和性が高く、AWSを既にご利用のお客様は導入の敷居が低いDWHサービスとなっております。 しかし、適切なテーブル設計を行わなければパフォーマンスを全く発揮できません。 不適切なテーブル設計をしてしまったが故、「バッチ処理が当初想定していた時間で終わらない」等、弊社にご相談頂いたお客様も数多くいらっしゃいます。 では、Redshiftを扱うにあたってどのようなテーブル設計を行えば良いのか。 本記事では、パフォーマンスの向上に繋がるテーブル設計のポイントを3つ、ご紹介致します。 1. ソートキー（SortKey） ソートキー（SortKey）は、テーブルのデ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
