DynamoDB vs Redshift

DynamoDB と Amazon Redshift が代替関係になることはめったにありません。DynamoDB は運用データベースです — 既知のキーに対する 1桁ミリ秒の読み書きで、ライブなアプリケーショントラフィックに応答します。Redshift は "a fully managed, petabyte-scale data warehouse service in the cloud" で、レポートと分析のために大規模データセットをスキャンし集計するよう作られています。両方を運用するチームが普通であり、AWS は両者間を一方向にデータを移すマネージド統合を提供しています。

DynamoDB と Redshift のどちらを使うべきか？

DynamoDB はアプリケーションのライブデータに使います。注文の確定、セッションの読み取り、キーによるレコード取得です。Redshift はデータセット全体にまたがる問いが必要なとき — 地域と月別の売上、コホートリテンション、複数ソースを結合するダッシュボード — に使います。「どちらか」という問いは、たいてい「書き込みパスは DynamoDB、分析担当は Redshift、その間に zero-ETL 統合」に解けます。

DynamoDB vs Redshift の概要

特性	DynamoDB	Redshift
ワークロード	運用（OLTP スタイル）— キーによる大量の読み書き	分析 — 大規模データセットのスキャンと集計
データモデル	スキーマレスな NoSQL アイテム、最大 400 KB。アイテムごとに属性が異なる	宣言された列、ディストリビューションキーとソートキーを持つリレーショナルテーブル
クエリ言語	ネイティブ API（`GetItem`、`Query`、`Scan`、…）に加え PartiQL	フルの SQL。それに伴う BI と SQL ツール
結合と集計	サーバーサイドの結合なし。集計もサーバーサイドの操作ではない	結合、ウィンドウ関数、`GROUP BY` など分析 SQL の一式
アクセスパターン	既知のキーを中心に設計。スキャンは高コストな例外	スキャン前提 — 多くの行を読むのが通常
レイテンシ	リクエストあたり 1桁ミリ秒	分析クエリあたり秒から分、はるかに多いデータに対して
スケーリング	サーバーレス。パーティションは AWS が管理	サーバーレスワークグループまたはプロビジョンドクラスター。クエリワークロードに合わせてキャパシティをサイズ
鮮度	要求に応じた書き込み直後の読み取り	ロード方法次第 — zero-ETL 統合は 15〜30 分ごとに更新を反映
料金モデル	リクエストまたはプロビジョンドキャパシティに加えストレージ	コンピュートキャパシティに加えストレージ。アイドルのサーバーレスウェアハウスはコンピュート課金なし

DynamoDB が適している場合

ライブなアプリケーショントラフィック。 既知のキーに対する予測可能な 1桁ミリ秒の読み書きを、どんなリクエストレートでも。
アイテムごとに異なるスキーマ。 1つのテーブルに異種アイテムがあるのは DynamoDB では普通。データウェアハウスは宣言された列を求めます。
サーバーレス運用。 サイズ設定、パッチ、一時停止するクラスターがない。
書き込み集中のパス。 DynamoDB は高ボリューム書き込みを主目的として吸収します。データウェアハウスはバルクロードと読み取りに最適化されています。

Redshift が適している場合

テーブル全体にまたがる問い。 1年分の注文を集計するのは本質的にスキャンであり、DynamoDB が避けるよう求めるアクセスパターンであり、Redshift が設計されたものです。
多数のソースにまたがる結合。 データウェアハウスは結合します。DynamoDB にサーバーサイドの結合はありません。
BI ツール。 Redshift は JDBC/ODBC 越しに SQL を話すため、既存のダッシュボードや "the same SQL-based tools and business intelligence applications that you use today" にそのまま入ります。
本番を乱さない分析。 レプリケートされたコピーに対して分析を走らせれば、ユーザーを担うテーブルから負荷を外せます。

併用する

標準パターンは一方向です。DynamoDB がアプリケーションに応答し、コピーが Redshift に着地し、分析担当はコピーで作業します。AWS は2つの経路をサポートします — 古い COPY コマンドで "from Amazon S3 or Amazon DynamoDB into Amazon Redshift" に直接ロードする方法と、コピーを自分で最新に保つマネージド zero-ETL 統合です。

zero-ETL 統合が実際に行うこと

"Zero-ETL" はライブビューを連想させます。そうではなく、ダッシュボード設計の前に詳細が重要です。

タイマー駆動のレプリケーションパイプラインです。 AWS は明確に述べています。"On activation, the integration exports the full DynamoDB table to populate the Amazon Redshift database." その後 "the zero-ETL integration then incrementally replicates updates from DynamoDB to Amazon Redshift every 15-30 minutes using DynamoDB incremental exports." つまり Redshift 上のデータは最大約30分古くなります。日次レポートには十分で、ユーザーの直前の操作を反映すべきものには不適切です。

ポイントインタイムリカバリ（PITR）は必須 — 理由も明らかです。 前提条件ははっきりしています。"A zero-ETL integration between Amazon DynamoDB and Amazon Redshift requires your source DynamoDB table to have Point-in-time recovery (PITR) enabled." AWS は要件と仕組みを別々に文書化し、結びつけませんが、付与しなければならないリソースベースのポリシーが答えを示します — redshift.amazonaws.com に dynamodb:ExportTableToPointInTime アクションを許可します。統合は DynamoDB の S3 エクスポート機構の上に構築されており、その機構は継続バックアップから読み取ります。PITR がなければエクスポートも統合もありません。

予算への影響は後から気づかれがちです。大きなテーブルで PITR を有効にすると、テーブルサイズに対する常時料金が発生し、リカバリのためではなく分析パイプラインのために負担します。統合の価格は「Redshift 単体」ではなく「Redshift ＋ PITR」として見積もってください。無料の DynamoDB 料金計算ツールが、コミット前にストレージ側をサイズできます。

既存テーブルを阻む2つの制約。 どちらも文書化された制限であり、後から直すのは厄介です。

"The DynamoDB table and Amazon Redshift cluster need to be in the same Region." 複数リージョンを統合するデータウェアハウスは、この経路ではすべてを引き込めません。
"The source DynamoDB table must be encrypted with either an Amazon-owned or Customer-managed AWS KMS key. Amazon managed encryption is not supported for the source DynamoDB table." AWS マネージド暗号化で作られたテーブルは、統合作成前に暗号化設定を変更する必要があります。

データ形状が効いてくる場所。 DynamoDB アイテムは設計上異種です。データウェアハウステーブルには列があります。1つのパーティションキー規約の下に複数エンティティタイプを持つシングルテーブル設計は、レプリケートされただけではきれいなスタースキーマにはなりません。データ着地後の Redshift でのモデリング作業を計画してください。統合が取り除くのはパイプラインであり、スキーマ設計ではありません。

まだデータウェアハウスが不要な場合

すべての集計が分析問題になるわけではありません。「Redshift に入れるべき」という話の多くは、1つの問いから始まります — この状態のアイテムはいくつか、この顧客の合計はいくらか、どのパーティションキーが支配的か — を、エンジニアがたまに1テーブルに対して尋ねる形です。

DynoTable の SQL Workbench は、そのクラスの問いに DynamoDB に対して直接、オンデマンドで答えます。COUNT、SUM、AVG、MIN、MAX、GROUP BY、HAVING、DISTINCT を備えた本物の SQL に加え、INNER/LEFT JOIN です。位置づけは意図的に狭く — DynamoDB のアクセスパターンのルールの範囲内の SQL です。単一の SELECT であり、CTE、UNION、ウィンドウ関数、スカラー副問い合わせはありません。結合先はパーティションキーまたは GSI のパーティションキーでなければなりません。結果は部分バッジ付きでストリーミングされ、クエリが最後まで走ると正確になりますが、データを読むコストは依然としてかかります。

データウェアハウスの代替ではなく、上記の制限が正直な境界です。それでもレプリケーションパイプライン、PITR 料金、スキーマ設計より速い答えであり、その問いがデータウェアハウスに値するかを、構築前に見極められます。Workbench クエリの実行は有料機能です。エディタとオートコンプリートは無料です。DynoTable はクローズドソースの商用アプリです。このページはその機能を説明するものであり、どのように構築されているかを説明するものではありません。

よくある質問

Redshift は DynamoDB を置き換えられますか？

アプリケーショントラフィック向けにはいいえ。Redshift はスキャンと集計のためのデータウェアハウスであり、1桁ミリ秒のキー検索を大量に捌くよう設計されていません。両者は並行して動き、DynamoDB がアプリケーションに応答し、Redshift 上のレプリケートされたコピーが分析に応答します。

Redshift 上の DynamoDB データはどれくらい新鮮ですか？

zero-ETL 統合では、最大約30分古くなります。AWS は、初回のフルエクスポート後に "incrementally replicates updates from DynamoDB to Amazon Redshift every 15-30 minutes using DynamoDB incremental exports" と文書化しています。ニアリアルタイムのレポートとして扱い、ライブビューではないと考えてください。

zero-ETL 統合に PITR が必要なのはなぜですか？

DynamoDB のポイントインタイムエクスポートの上に構築されているためです。統合に必要なリソースベースのポリシーは、Amazon Redshift に dynamodb:ExportTableToPointInTime アクションを許可し、そのエクスポートは PITR が維持する継続バックアップから読み取ります。したがって PITR の有効化は、統合の実際の継続コストです。

参考資料

Last verified 2026-08-02 against the official AWS Redshift Management Guide and DynamoDB Developer Guide.