データストアの選び方

データエンジニアは、取り込んだデータを「どこに置くか」を最初に決めます。置き場所を誤ると、後からどれだけ変換やを工夫しても、性能とコストの問題が残ります。DEA-C01 では、アクセスパターン (誰が、どの頻度で、どの形で読むか)、コスト、性能の要件から、・・/・・・/ などを選び分ける力が問われます。

Point

OLTP = Online Transaction Processing (オンライントランザクション処理): 1件ずつの読み書きを大量に、すばやく行う処理です。注文の登録や在庫の更新が典型です。
OLAP = Online Analytical Processing (オンライン分析処理): 大量の行を集計・結合して傾向を見る処理です。売上の月次集計が典型です。
和訳
- Access pattern: アクセスパターン (データの読み書きのされ方)
- Weblio英和辞書「access pattern」

概要

データストアは「データの形」「読み書きの単位」「求める速さ」「保管する期間と量」で選びます。1つのサービスですべてを満たそうとせず、用途ごとに目的別のストアを組み合わせるのが AWS の基本の考え方です。

試験では、問題文から「か OLAP か」「ホットかコールドか」「スキーマが固定か可変か」「運用負荷を減らしたいか」を読み取り、最も要件に合うストアを選びます。

主要技術

①OLTP と OLAP の違い ⚠️ 頻出

観点		OLAP
典型の処理	注文の登録、残高の更新	期間別・地域別の売上集計
1回に触る行	少ない (1〜数件)	非常に多い (数百万〜数十億行)
格納方式	行指向	列指向
正規化	正規化して更新の矛盾を防ぐ	非正規化 () で結合を減らす
AWS の代表	、、	、 ( 上の列指向ファイル)

本番の OLTP データベースに重い集計クエリを流すと、業務の応答が遅くなります。集計は Redshift へ複製してから行う ( 統合、、エクスポート) か、から抽出します。

②主なデータストアの比較 ⚠️ 頻出

ストア	データの形	得意なアクセス	性能の目安	コストの考え方	向かないこと
	オブジェクト (任意の形式)	大量データの保管、// からの一括読み取り	プレフィックスごとに毎秒 3,500 件の書き込み、5,500 件の読み取りから自動で伸びる	保管量 + リクエスト。で下げられる	1行単位の更新、低遅延のキー検索
	構造化 + 半構造化 (SUPER 型)	大量データの集計・結合、	(超並列処理) で列指向に読む	プロビジョンドはノード時間、Serverless は時間	1件ずつの頻繁な更新 ()
/	リレーショナル	トランザクション、結合、制約	1件単位の読み書きが速い	インスタンス時間 + ストレージ	数十億行の集計
	キーと値、ドキュメント	キーを指定した1件の読み書き、予測できるアクセスパターン	規模によらず一桁ミリ秒	はリクエスト数、プロビジョンドは容量	アドホックな結合・集計
	ドキュメント	全文検索、ログの検索と可視化、	インデックスによる高速検索	ノード時間 (Serverless は OCU)	正規化データの更新、長期の安価な保管
Amazon MemoryDB	キーと値 ()	マイクロ秒の読み取り、のあるインメモリ DB	読み取りはマイクロ秒、書き込みは一桁ミリ秒	ノード時間	大量の履歴データ
/	レコードの流れ	複数のコンシューマーへの配信、再読み込み	秒未満で届く	時間 / ブローカー時間 (Serverless あり)	長期の保管と分析
Amazon EMR ()	任意	クラスター内の一時的な中間データ	ローカルディスクで高速	クラスターの稼働時間	永続的な保管 (クラスター停止で消える)

EMR の永続データは HDFS ではなく S3 () に置きます。HDFS はクラスターを止めると消えるため、中間データやに限ります。

Point

MPP = Massively Parallel Processing (超並列処理): 複数のノードがデータを分担し、同時に処理する方式です。Redshift の速さの源です。
RPU = Redshift Processing Unit: Redshift Serverless の処理能力の単位です。
OCU = OpenSearch Compute Unit: OpenSearch Serverless の処理能力の単位です。

③アクセスパターンからの選び方

同じデータでも、読み方で置き場所が変わります。

アクセスパターン	選ぶストア	理由
ユーザー ID で最新の状態を1件取得 (毎秒数万件)		キーでの取得が規模によらず速い
同じキーをマイクロ秒で繰り返し読む	MemoryDB (が必要)、 ()
複数テーブルを結合して更新、制約で整合性を守る	/	トランザクションと結合
数年分の売上を毎朝集計してダッシュボードへ		列指向と、
月に数回だけ、生ログをで調べる	+	置いておくだけなら安く、使った分だけ課金
エラーメッセージを全文検索、直近のログを可視化		転置インデックスによる検索
同じストリームを複数のアプリが読む、再処理したい	/	保持期間内なら読み直せる

⚠️ 頻出: 「頻繁ではない」「アドホック」「サーバーを管理したくない」とあれば S3 + Athena、「繰り返す複雑な集計」「のが多い」とあれば Redshift を選びます。

④ホットデータとコールドデータ

データは時間がたつほど読まれなくなります。読まれる頻度に合わせて置き場所を変えると、性能を保ったままコストを下げられます。

	例	置き場所の例
ホット (毎日読む)	直近30日の注文	のローカルテーブル、、のホットノード
ウォーム (ときどき読む)	直近1年の履歴	Standard- + 、OpenSearch
コールド (ほぼ読まない、保管義務)	7年分の監査ログ	Flexible Retrieval / Deep Archive

Redshift の古いデータをで S3 へとして書き出し、Redshift Spectrum の外部テーブルとして残すと、Redshift のストレージを減らしながらで読み続けられます。

⑤コストと性能の要件からの調整

ストアを選んだ後も、設定でコストと性能を合わせます。

ストア	性能を上げる設定	コストを下げる設定
	プレフィックスを分けて並列化、S3 Express One Zone	ライフサイクルルール、Intelligent-Tiering
	・、	Serverless の上限、プロビジョンドの一時停止、リザーブドノード
	分散する、	予測できる負荷はプロビジョンド + 、Standard- テーブルクラス
/	、RDS Proxy	v2、不要時の停止
	数とインスタンスの調整	/ コールドストレージ、Index State Management
	シャードの追加、	とプロビジョンドの選択
	パーティション数、ブローカーのサイズ	MSK Serverless

DEA ではの構成もよく出ます。S3 にのテーブルを置き、・・Redshift から同じデータを読むと、ストアをまたいだコピーを減らせます (「と」の章)。の権限を表・列の単位で一元管理する場合はを組み合わせます (「AWS Lake Formation」の章)。

試験対策

①判断マトリクス

問題文のキーワード	選ぶストア
ペタバイト級をで集計、ツールから接続
ワークロードが不定期、容量管理をしたくない DWH	Redshift Serverless
生データを安く無期限にためる、形式がばらばら	()
S3 のデータをたまに SQL で調べる、サーバーなし
キーで1件を一桁ミリ秒、規模が読めない	()
キーと値にマイクロ秒でアクセス、データを失えない	Amazon MemoryDB
結合とトランザクションが必要な業務データ	/
全文検索、ログの検索と可視化
複数のコンシューマーへ配信、保持期間内に再処理	/
のとエコシステムを使いたい	Amazon MSK
本番に影響を与えず分析したい	統合で Redshift へ、または S3 へのエクスポート
データレイクで行の更新・削除、	()

②よくある誤答

で任意の列による集計や結合を行おうとすること。DynamoDB はアクセスパターンを先に決めて設計するストアです。集計はへエクスポートしてやで行います。
に数十億行をためて分析用に使うこと。行指向のため大量の集計に向きません。
Redshift に生ログを全部ロードし続けること。頻繁に使わないデータは S3 に置いてで読む方が安くなります。
のを永続ストアとして使うこと。クラスター停止で消えるため、S3 に置きます。
を長期の保管先と考えること。保持期間を過ぎたレコードは消えます。