Redshiftのパフォーマンス関連メモ - Qiita
はじめに 本記事は個人メモです。 いろいろ書いていますが、私自身はRedshiftのパフォーマンス関連の経験値は低いです。 随時内容を追記していきます。粒度にムラがあります。長くなったら記事を分割するかもしれません。 RedshiftはSnowflakeなどに比べるとチューニングで考えるべきポイントが多い印象です。 学習による認知負荷が極めて高いため、本記事のように学習内容をまとめておく必要があると感じました。 本記事の構造と注意点 本記事の構造 本記事に記載する情報源やTipsは、「テーブル設計」と「クエリパフォーマンス」で分けて記載しています。 注意点 本記事は主にRedshiftクラスタ(Provisioned)版（つまりRedshiftサーバレスではない）を念頭に記載しています。 記事中に断りがなければRedshiftクラスタ版を指しているものとお考えください。 パフォーマンスチュ
Redshift の自動パフォーマンスチューニング機能まとめ - Qiita
はじめに Amazon Redshift には機械学習ベースで自動的にパフォーマンスを最適化する機能が複数あります。数が増えて追いきれなくなってきたので以下にまとめます。 Automatic Vacuum Delete デフォルトで有効 2018/12/19 に追加 UPDATE や DELETE オペレーションにより論理削除された行数にもとづいてバックグラウンドで自動的に VACCUM DELETE を実行します。これにより断片化で消費されていたスペースが解放され、ワークロードのパフォーマンスが向上します。 低負荷のときに実行するようにスケジュールされ、負荷が高い間は操作を停止します。 Automatic Analyze デフォルト有効 2019/1/18 に追加 バックグラウンドで自動的に ANALYZE を実行し、テーブルの統計情報を更新します。これにより最適なクエリの実行計画の作成
RDBMSの苦手なことを 如何に乗り越えていくか / challenge-to-rdbms
# 参考資料 - イミュータブルデータモデル(入門編) - https://www.slideshare.net/kawasima/ss-40471672 - イミュータブルデータモデル(世代編) - https://www.slideshare.net/kawasima/ss-44958468 - スタースキーマ（基礎） - https://zenn.dev/pei0804/articles/star-schema-design - ディメンション・モデリング - https://zenn.dev/pei0804/articles/dimensional-modeling - 失敗から学ぶRDBの正しい歩き方 - https://amzn.to/3vfD5nJ
RedshiftのPrimary KeyおよびUnique制約が実行計画に与える影響 | DevelopersIO
こんにちは。データアナリティクス事業本部の松村です。 早いものでもう入社から1年が経ちましたが、これまでの投稿ペースは平均して月1本、そして間隔にはかなりばらつきがあります。今後はコンスタントに月2本を達成したいなあと思う次第からの、2年目初の投稿です。 RedshiftにおけるPrimary Key制約の役割 Redshiftが一般的なRDBMSとは異なっていることのひとつとして、Primary Key制約が実際には制約として機能しない、というものがあります。かなり有名なのでご存じの方も多いと思います。 しかしながらマニュアルによると、実行計画の作成時には利用されるそうです。 CREATE TABLE Important Primary key constraints are informational only. They aren't enforced by the system,
パフォーマンスに影響！Redshiftのテーブル設計時に最低限意識すべきポイント3選
Introduction AWSが提供するDWHサービス、Amazon Redshift。 全世界での採用企業は数万社を超えており、弊社も国内において多くのお客様に導入のご支援をさせて頂きました。 RedshiftはAWSエコシステムとの親和性が高く、AWSを既にご利用のお客様は導入の敷居が低いDWHサービスとなっております。 しかし、適切なテーブル設計を行わなければパフォーマンスを全く発揮できません。 不適切なテーブル設計をしてしまったが故、「バッチ処理が当初想定していた時間で終わらない」等、弊社にご相談頂いたお客様も数多くいらっしゃいます。 では、Redshiftを扱うにあたってどのようなテーブル設計を行えば良いのか。 本記事では、パフォーマンスの向上に繋がるテーブル設計のポイントを3つ、ご紹介致します。 1. ソートキー（SortKey） ソートキー（SortKey）は、テーブルのデ
Amazon Redshift: 列レベルのアクセスコントロールが出来るようになりました | DevelopersIO
先日、Amazon Redshiftにおいて「列レベルのアクセスコントロール」が出来るようになった旨、アナウンスがありました。 Amazon Redshift のための列レベルのアクセスコントロールの発表 Announcing column-level access control for Amazon Redshift Amazon Redshift now supports access control at a column-level for data in Redshift. Customers can use column-level grant and revoke statements to help them meet their security and complianc... https://t.co/TJZlrbFvYI — What’s New on AWS (
クエリプランの評価 - Amazon Redshift
クエリプランを使用すると、分散スタイル最適化の候補を特定できます。 初期設計の決定を行った後で、テーブルを作成し、テーブルにデータをロードして、テーブルをテストします。実際のデータにできるだけ近いテストデータセットを使用します。比較のベースラインとして使用するロード時間を測定します。 実行する予定のクエリのうち、典型的な高コストクエリ、つまり結合と集計を使用するクエリを評価します。さまざまな設計オプションの実行時間を比較します。実行時間を比較する際は、最初のランタイムにはコンパイル時間が含まれるため、最初の時間はカウントしないでください。 DS_DIST_NONE 対応するスライスはコンピューティングノードにコロケーションされているため、再分散は必要となりません。通常は、DS_DIST_NONE ステップ (ファクトテーブルと単一のディメンションテーブル間の結合) が 1 つあるだけです。
Amazon Redshift テーブル設計詳細ガイド –分散スタイルとソートキーの決定方法–
© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved. アマゾン ウェブ サービス ジャパン株式会社 柴田竜典 2017/6/1 Amazon Redshift テーブル設計詳細ガイド 分散スタイルとソートキーの決定方法 自己紹介 柴田竜典［シバタツ］ • データベース関連の 相談ごと何でも担当 • AWSへの移行を機に RDBMSをAuroraに 乗り換えたい • オンプレミスOracleを AWSにフォーク リフティングしたい • 好きなAWSのサービス: S3 @rewse すでにRedshiftをお使いの方の悩み • クエリー性能をさらに向上させたい • 同時実行を上手にさばきたい • 料金を抑えたい などなど クエリー性能向上に大切なことは何か 最良のソートキーの選択 最適な分散スタイルの
Redshift クエリのパフォーマンス分析 - Qiita
Redshiftで遅いSELECT文のパフォーマンス分析した時の手順等メモ。 1. 分析対象SQLの実行 -- このセッション中でクエリ結果キャッシュを無効にする SET enable_result_cache_for_session TO off; -- 分析対象SQLを実行 -- SQLのコンパイル時間を除くため、分析対象SQLを再度実行 -- 現在のセッションで最後に実行されたクエリのクエリIDを取得 SELECT pg_last_query_id(); -- アラートが出てないか -- https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_STL_ALERT_EVENT_LOG.html SELECT * FROM stl_alert_event_log WHERE query = クエリID; -- 実行計画 -- http
[AWS] S3からRedshiftにCOPYする際にマニフェストで対象ファイルを複数指定する。 | DevelopersIO
はじめに Redshiftのテーブルにロードする際に簡単なのは、S3にCSVファイルなりを配置してそれをロードする方法です。 ファイル名にプレフィックスを使用して複数をロードする事も可能ですが、プレフィックスになっていない場合ではファイル毎に実行する必要が出てくるので面倒です。そんな時にマニフェストを作成してCOPY時に読み込ませれば、そこに記述してあるファイル一覧をロードできて便利です。 扱い方について調べたので記事にしておきます。 マニフェストについて 対象ファイルへの接続方法や処理について記述しておき、ロード時にマニフェストを読み込んでその指示通りに処理できるようにするものと理解しています。 環境 Windows10 Aginity For Redshift 準備 テーブル作成 create schema test; create table test.tablea ( id int
![[AWS] S3からRedshiftにCOPYする際にマニフェストで対象ファイルを複数指定する。 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/977093929c7bae81ce8ef1fba07f72411d2c9ded/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2014%2F05%2FAmazon_Redshift.png)
Amazon Redshift DB開発者ガイド – データのロード処理(3).データロードに関するトラブルシューティング | DevelopersIO
Amazon Redshift DB開発者ガイド、データロード処理の第3弾です。前回のエントリに盛り込もうと思ったのですがボリューム(文字数)の都合で断念しました。(^-^;) 第3弾はエラー発生時の解決方法やヒントについてまとめている『トラブルシューティング』にちなんだ内容です。実際実行時に数多く目にする事でしょうから、何かとこの手の情報は入り用になってくるのかな、と思います。問題解決に少しでもお役に立てるようであれば幸いです。 目次 データロードに関するトラブルシューティング マルチバイト文字のロードエラー ロードエラーリファレンス データロードに関するトラブルシューティング このセクションでは、ロード時のエラーに関するエラーの識別方法及び解決方法についての情報を提供します。 COPYコマンドで指定されたAmazon S3のバケットは、対象のクラスタと同じリージョン内にある必要がありま
Amazon Redshift: COPY時のエラー情報を見易い形で取得するSQL文 | DevelopersIO
超々小ネタです。 Amazon RedshiftでCOPY操作を行う際、新しく取り込むようなファイルだとエラーとなるようなデータの形式であったり、テーブルデータ型との齟齬が頻繁に発生する事も往々にしてありますので都度エラーが発生した際に対象となるシステム系テーブルを参照する必要が出て来ます。その際、これまではあまり意識しては居なかったんですが『そう言えば都度、エラー情報を得る時に手動でSQLを書いてたな』とふと思い、また可変長文字列が多いテーブルでもありますのでそのままの情報を得ようとすると若干見辛いというのもあるのでその手間を省くべく確認用のSQLをネタとして用意しとこうと思いました。 stl_loar_errorsテーブル参照用SQL 以下はエラー発生時に参照すべきテーブル、『stl_loar_errors』テーブルを分割して表示させるSQL群です。対象となるテーブルのテーブル名が無か
テーブルのバキューム処理 - Amazon Redshift
Amazon Redshift は、バックグラウンドでテーブルを自動でソートし、VACUUM DELETE オペレーションを実行できます。ロードまたは一連の増分更新の後にテーブルをクリーンアップするには、データベース全体または個々のテーブルに対して VACUUM コマンドを実行することもできます。 実質的に、テーブルの所有者またはスーパーユーザーのみがテーブルにバキューム処理を実行できます。そのテーブルの所有者権限またはスーパーユーザーアクセス許可を持っていない場合は、1 つのテーブルに対する VACUUM オペレーションは失敗します。テーブル名を指定せずに、データベース全体に VACUUM を実行した場合、オペレーションは正常に完了します。ただし、このオペレーションは、所有者の権限またはスーパーユーザーアクセス許可がないテーブルには効果がありません。 このため、必要に応じて、テーブルを個
Amazon Redshift 統計情報を自動更新する『Auto Analyze』の動きを確認してみました | DevelopersIO
はじめに Auto Analyzeは統計情報の更新（ANALYZE）がバックグラウンドで自動実行するサービスです。本日は実際の動作を確認してみました。 Auto Analyzeとは Amazon Redshiftは、テーブル内で、どのような値が、どのような頻度で出現するのかの情報である「統計情報」を事前に取得しておき、この情報を基に効率的にレコード操作を行う計画「実行計画」を立てて実行します。つまり最適なパフォーマンスを得るには、正確な「統計情報」が必要となります。 これまでテーブルのデータは日々更新に応じて、ANALYZEコマンドを実行する必要がありましたが、これをバックグラウンドで自動実行する機能が、『Auto Analyze』です。この機能は、クエリの負荷に基づいてスケジュール実行されるため、アドホッククエリやバッチクエリの妨げにならないので安心してご利用いただけます。 参考：テーブ
Redshiftにて、DBユーザーの権限をいい感じに管理する方法 - goodbyegangsterのブログ
Redshiftにおいて、DBユーザ向けに、あるスキーマ内にあるオブジェクト(tableとかviewとか)に対する権限を付与しようとした場合、今まで以下のSQLを利用していました。 GRANT SELECT ON ALL TABLES IN SCHEMA schema_name TO GROUP db_user_group; しかし、このSQLでは このGrant文を実行した後に作成したテーブルには、権限が反映されない という問題があります。（あります、というか、そんな事知らずに運用していました。。。） この事を考慮して ALTER DEFAULT PRIVILEGES文 を利用すべきとなります。これは、PostgreSQL 9.0から利用できる機能で、Redshiftでも利用できます。公式ドキュメントはこちらです。 ALTER DEFAULT PRIVILEGES - Amazon Re
Redshiftチューニングメモ（WIP） - packpak’s diary
仕事でRedshiftのチューニングをすることになりそうなのでメモ ※適宜更新 2018/04/04 更新 2018/04/11 更新 2018/10/04 更新。嘘いっぱい書いてたのを訂正。分散キーに関する項目を拡充 2018/11/07 更新。列圧縮に関する嘘八百を訂正。ソートキーに関して追記 2020/02/06 改めて見直すと肝心なことが書かれていなかったので更新。 この記事が想定する事例 検証環境では5秒～10秒程度で帰ってきているが、一定の負荷がある本番環境では何故かパフォーマンスが半分以下になる。 Redshiftは並列分散で、１つのタスクにリソースを全力投入することでパフォーマンスを出している。AWSのガイドラインが提示しているチューニングは、実はリソース消費を低減させることに重きを置いている。（ソートキー、列圧縮タイプなどは副次作用もある） Redshiftのチューニング
【Postgresql】【Redshift】SELECTの取得値にNULLを定数で指定するときは型指定する - packpak’s diary
やらかした。 やらかし SELECT order.orderno, orderdtl.orderidx, order.orderdate, NULL AS customer_id FROM order ; 上記のように、SELECTで型ヒントなしに NULL を指定すると、型が "unknown" となる。 CREATE VIEW view_orderlist AS SELECT order.orderno::numeric, orderdtl.orderidx::int, order.orderdate::date, NULL::unknown AS customer_id FROM order ; 通常の選択操作では困らないが、特定のSQLでエラーとなる。 SELECT COUNT(DISTINCT customer_id) FROM view_orderlist; -- postgr
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Redshift Epochs and Timestamps
Amazon Redshiftの開発者がこれだけは知っておきたい10のTIPS / 第18回 AWS User Group - Japan