DynamoDB vs Amazon S3

DynamoDB と Amazon S3 は異なる問題を解決するため、「どちらか」に対する正直な答えは、たいてい両方です。DynamoDB は、キーによって参照、クエリ、更新する構造化されたレコードのためのキーバリューおよびドキュメントデータベースです。Amazon S3 は、画像、バックアップ、ログ、動画といったファイルやブロブをまるごと保存・取得するためのオブジェクトストレージです。両者は互いに補完し合うものであり、どちらか一方というものではありません。

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

DynamoDB は、キーによって 1桁ミリ秒のレイテンシでクエリ、フィルター、更新する小さな構造化レコードが多数あるときに使います。Amazon S3 は、画像、バックアップ、エクスポートといったファイルやブロブをまるごと保存・提供し、名前によって取得するときに使います。両者は補完的であり、非常に一般的なパターンでは、オブジェクトを S3 に、そのメタデータを DynamoDB に保存します。

DynamoDB vs Amazon S3 の概要

特性	DynamoDB	Amazon S3
主な目的	構造化レコードのための NoSQL キーバリュー / ドキュメントデータベース	ファイル、ブロブ、非構造化データのためのオブジェクトストレージ
データ単位	アイテム(型付き属性の集合)。プライマリキーでアドレス指定	オブジェクト(バイト + メタデータ)。バケット内のキーでアドレス指定
単位あたりの最大サイズ	アイテムあたり 400 KB(属性名 + 値)	オブジェクトあたり 5 TB(単一 PUT は最大 5 GB。それより大きいアップロードはマルチパートを使用)
クエリ / アクセス	`GetItem`、`Query`、`Scan`、`BatchGetItem`、PartiQL、セカンダリインデックス(GSI/LSI)	キーによる `GET` / `PUT` / `DELETE`、バケットの `LIST`。Amazon Athena によるインプレースクエリ(既存顧客は S3 Select も可)
レイテンシプロファイル	あらゆる規模で単一アイテムに対し 1桁ミリ秒の読み書き	永続性のあるオブジェクトスループット。キーバリューデータベースよりリクエストあたりのレイテンシが高く、ミリ秒のレコード参照ではない
整合性	デフォルトは結果整合性。リクエストごとに強い整合性のある読み取りが可能	すべてのオブジェクトとすべてのリクエストに対する強い read-after-write 整合性(2020 年以降)
料金モデル	読み書きキャパシティ(RCU/WCU — オンデマンドまたはプロビジョンド)+ GB 月あたりのデータストレージ	GB 月あたりのストレージ(ストレージクラス別)+ リクエスト料金(PUT/GET/LIST)+ データの取得 / 転送
最適なワークロード	ユーザープロファイル、セッション、カート、イベント/状態レコード、メタデータ、高スループットな OLTP 的アクセス	メディア、バックアップ、データレイクファイル、静的アセット、大規模なエクスポート、アーカイブ

上記の各セルはすべて、AWS の公式ドキュメントに基づいています(このファイル冒頭の provenance 注記を参照)。

DynamoDB を使うべき場合

データがキーによってアクセスする構造化レコードであるときは、DynamoDB を選びます。

個別に読み書き・更新する多数の小さなアイテム(それぞれ 400 KB の上限未満)。
予測可能で低レイテンシの参照 — DynamoDB はあらゆる規模で単一アイテムに対し 1桁ミリ秒の読み書きを目指します。
プライマリキーとセカンダリインデックスで表現できるアクセスパターン。ID による取得、パーティションへのクエリ、パーティション内でのフィルタリングなど。
きめ細かな更新を伴う高い書き込みスループット(レコード全体を書き直すことなく 1 つの属性を変更)。

もし 5 MB のファイルをアイテムの内部に保存しようとしているなら、それは DynamoDB の境界に達したサインです。DynamoDB のアイテムサイズ上限を参照してください。

S3 を使うべき場合

データが名前によって取得するファイルやブロブそのものであるときは、Amazon S3 を選びます。

画像、PDF、動画、音声、その他のバイナリアセット。
バックアップ、データベースのエクスポート、後で Amazon Athena のようなツールでクエリするデータレイクファイル(Parquet、CSV、JSON)。
大きなオブジェクト — S3 はオブジェクトごとに最大 5 TB を保存でき、単一のデータベースレコードをはるかに超えます。
静的なウェブサイトのアセットや、ユーザーに直接提供するコンテンツ。

S3 はデータベースではありません。DynamoDB のアイテムをクエリするような豊富なインデックスで、任意のオブジェクトの内容をクエリすることはできません。オブジェクトに対するインプレースな SQL 的フィルタリングは Amazon Athena で利用できます(S3 Select は既存顧客には引き続き利用可能ですが、2024 年に新規顧客には閉じられました)。

併用する

この 2 つのサービスは組み合わせると最も強力になります。DynamoDB のアイテムに収まらないほど大きいデータに対する AWS 自身のガイダンスは、オブジェクトを S3 に保存し、ポインターを DynamoDB に保持することです。

大きなファイル(画像、ドキュメント、動画)をオブジェクトとして S3 に保存します。
そのメタデータ — S3 オブジェクトキー、コンテンツタイプ、所有者、タグ、タイムスタンプ — をアイテムとして DynamoDB に保存します。ここでは安価にクエリできます。
レコードをキーによって DynamoDB で参照し、保存した識別子を使ってオブジェクトを S3 から取得します。

AWS が注意点として挙げているのは、DynamoDB と S3 にまたがるトランザクションは存在しないため、部分的な失敗はアプリケーション側で処理する必要があるという点です(たとえば、DynamoDB への書き込みが失敗した場合に、孤立した S3 オブジェクトをクリーンアップするなど)。

DynamoDB を扱う

データの構造化された部分に DynamoDB を選んだら、DynoTable は macOS、Windows、Linux でテーブルの閲覧、編集、クエリを行うためのデスクトップ DynamoDB クライアントです。標準の AWS 認証情報チェーンを読み取るため、DynamoDB 固有で移行するものは何もありません。リージョンとテーブルを指定するだけで、データは DynamoDB に留まります。

上記のメタデータを DynamoDB に置くパターンを支える GetItem、Query、Update、条件式を手作業で組み立てる必要があるとき、無料の DynamoDB Expression Builder は、AWS SDK、CLI、boto3 の形式でリクエストを生成します。何を S3 に置くか決める前に、400 KB の上限に対してアイテムのサイズを測るには、アイテムサイズ計算ツールがレコードのバイトサイズを測定します。

よくある質問

DynamoDB はファイルや画像を保存できますか？

小さなものなら、上限の範囲内で可能です。DynamoDB のアイテムはバイナリデータを保持できますが、アイテム全体 — すべての属性名と値 — は 400 KB 未満に収める必要があります。それより大きいものについては、AWS が文書化しているベストプラクティスは、ファイルを Amazon S3 にオブジェクトとして保存し、S3 オブジェクトキー(とメタデータ)を DynamoDB のアイテムに保持することです。

S3 は DynamoDB より安いですか？

料金の仕組みが異なるため、一律の答えではなくワークロード次第です。S3 は GB 月あたりのストレージに加え、リクエストごとと取得の料金を課金し、大量のアクセス頻度の低いバイトを置く先としては一般に安価です。DynamoDB は読み書きキャパシティに加えストレージを課金し、多数の小さなレコードへの高スループットで低レイテンシなアクセスのために作られています。大きなブロブを DynamoDB に保存することはサイズが制限されるうえ比較的高価です。だからこそ、S3 オブジェクト + DynamoDB メタデータという分割が標準的なパターンなのです。

JSON には DynamoDB と S3 のどちらか？

その JSON がキーによってクエリ・更新する構造化レコード(ユーザー、注文、セッション)であれば、DynamoDB が適し、JSON を型付き属性にマッピングして PartiQL をサポートします。その JSON が保存して後でまとめてスキャンするドキュメントやデータレイクファイル全体(たとえば Amazon Athena でクエリする)であれば、S3 が適します。よくあるハイブリッドでは、クエリ可能なフィールドを DynamoDB に、JSON ペイロード全体を S3 のオブジェクトとして保持します。