Redshift

Redshift とは

Amazon Redshift は、ペタバイト規模のデータウェアハウス (DWH) サービスで、列指向ストレージと大規模並列処理 (MPP) により、大量データの分析クエリを高速に実行する。SQL 方言は PostgreSQL をベースにしており、PostgreSQL 向けのクライアントやドライバーの多くがそのまま使える。ただし互換ではない。公式の開発者ガイドは両者に「非常に重要な違い」があると明示しており、二次索引や単一行の効率的な更新といった OLTP 向けの機能は、分析性能を優先して省かれている。PostgreSQL 9.x 系の機能・データ型・関数にも未対応のものがあるため、既存のクエリをそのまま流せる前提では設計しない (2026 年 8 月時点)。

列指向 vs 行指向

同じ表でも、ディスク上で行ごとに並べるか列ごとに並べるかで、得意なクエリが正反対になる。

行指向 (RDS などの RDBMS):
  Row 1: [id=1, name="Alice", age=30, city="Tokyo"]
  Row 2: [id=2, name="Bob",   age=25, city="Osaka"]
  → 1 行の全カラムを取得するのが高速

列指向 (Redshift):
  id:   [1, 2, 3, ...]
  name: ["Alice", "Bob", ...]
  age:  [30, 25, ...]
  → 特定カラムの集計 (SUM, AVG) が高速、圧縮効率が高い

観点	行指向 (RDS)	列指向 (Redshift)
得意	CRUD、トランザクション	集計、分析クエリ
苦手	大量データの集計	単一行の取得・更新
用途	OLTP (業務処理)	OLAP (分析)

列指向が集計に強いのは、必要な列のブロックだけ読めばよく、同じ型の値が隣り合うので圧縮も効くからである。裏返しとして、1 行を書き換えるだけでもその行が関わる全ての列のブロックに触ることになり、単一行の更新は不利になる。この使い分けの詳細は OLAP と OLTP を参照。

MPP の仕組みと分散設計

プロビジョンドクラスターは、リーダーノードとコンピュートノードで構成される。リーダーノードが SQL を解析して実行計画を作り、各コンピュートノードがその計画を並列に実行し、必要に応じてノード間でデータを交換して、最後にリーダーノードが結果を集約する。速さの理由は 1 台が大きいことではなく、1 つのクエリを複数ノードで分担することにある。

分担がうまく効くかどうかを決めるのが、行をどのノードに置くかという分散スタイルである。

分散スタイル	行の置き方	向く場面
AUTO (既定)	データ量に応じて ALL / KEY / EVEN を Redshift が選び直す	設計方針が固まっていない段階
KEY	指定した列の値が同じ行を同じスライスへ集める	結合列が決まっている大きな表同士の結合
EVEN	列の値を見ずラウンドロビンで均等に配る	結合に参加しない表
ALL	表全体を全ノードへ複製する	頻繁に結合される小さなマスタ表

落とし穴は、結合する 2 つの表で分散キーが揃っていない場合である。結合のたびにノード間で行を配り直す処理が入るため、ノードを増やしても待ち時間が思ったほど縮まない。ALL はその配り直しを消せる代わりに、必要なストレージがノード数の分だけ増える。

Athena との比較

同じ分析用途で Athena と比べられることが多い。判断軸はデータの置き場所と課金の形である。

観点	Redshift	Athena
データの場所	Redshift クラスター内	S3 上のファイル
課金	プロビジョンドはノード稼働時間、Serverless は RPU 時間	スキャンしたデータ量
パフォーマンス	高い (データがローカル)	中程度 (S3 スキャン)
管理	プロビジョンドはクラスター管理が必要 (Serverless は不要)	サーバーレス
適するケース	定常的な分析ワークロード	アドホッククエリ

少量・低頻度のクエリなら Athena、大量・高頻度のクエリなら Redshift。

構成の選び方 (Serverless とプロビジョンド)

Redshift Serverless はクラスターを自分で用意せずに使える構成で、容量の単位は RPU (Redshift Processing Unit) である。1 RPU は 16 GB のメモリに相当し、ベース容量は既定で 128 RPU で、下限は 4 RPU から指定できる (上限値は公式資料の記載が改定されているため、利用時点のコンソールで確認する)。課金は RPU 時間で、使用量は秒単位に計測されるが、1 回の実行には最低 1 分ぶんが計上される (2026 年 8 月時点)。問い合わせが断続的なら待機中の費用が出ない一方、一日中クエリが流れ続ける使い方では秒単位の積み上がりが大きくなるため、プロビジョンドとの費用比較が必要になる。

プロビジョンド構成では、2026 年 8 月時点の公式管理ガイドが RG または RA3 のノードタイプを、必要な性能・データ量・想定される増加量に応じて選ぶよう案内している。どちらも Redshift マネージドストレージを使い、コンピュート能力とストレージ容量を別々に増減・課金できる。以前提供されていた高密度コンピュート型の DC2 と、非推奨となった DS2 にはこの分離がない。古い構成のクラスターを引き継いだ場合は、まず現行ノードタイプへ移行できるかを確認する。

データの取り込み経路

業務データを Redshift へ集める道は、自分で組む方式と統合機能に任せる方式に分かれる。

自前で組む:   [DynamoDB] → [Kinesis Data Streams for DynamoDB] → [Amazon Data Firehose] → [S3] → [Redshift COPY]
統合に任せる: [DynamoDB] → [zero-ETL 統合] → [Redshift (SUPER 型の列)]

DynamoDB の変更を流す口は 2 種類ある。DynamoDB Streams は Lambda や Kinesis アダプター、Apache Flink といったアプリケーション側から読む前提のストリームで、配信サービスへ直接繋ぐ口ではない。下流の配信サービスへそのまま渡したい場合は Kinesis Data Streams for DynamoDB を選ぶ。なお配信側の Amazon Data Firehose は Amazon Kinesis Data Firehose から改称されており、古い名前のままでは公式ドキュメントを追いにくい。

zero-ETL 統合を使う場合、DynamoDB 側は PITR (ポイントインタイムリカバリ) を有効にしておくことが前提で、有効化時に表の全量エクスポートが走り、その後は増分エクスポートで追随する。取り込まれた項目は Redshift 側では SUPER 型の列にマップされる。反映の最小遅延は 15 分で、リフレッシュ間隔を指定すればさらに広げられる (2026 年 8 月時点)。秒単位の鮮度が求められる用途にはこの経路は向かない。

集めたデータは BI ツール (QuickSight) から参照して可視化する。

よくある用途

Redshift が選ばれるのは、集計対象の行数が大きく、似た形のクエリを繰り返し流す場面である。

用途	クエリ例
売上分析	月別・商品別の売上集計
ユーザー行動分析	ファネル分析、コホート分析
ログ分析	大量のアクセスログの集計

実務での活用方法は関連書籍にも詳しい。