DynamoDB vs Google Cloud Bigtable
DynamoDB と Google Cloud Bigtable は、どちらもキーでデータをパーティション分割する分散 NoSQL データベースですが、対象とするワークロードの形が異なります。DynamoDB は運用（OLTP スタイル）のアクセス向けに構築されたサーバーレスな AWS のキーバリュー・ドキュメントストアです。Bigtable は、分析、時系列、高スループットな取り込みワークロード向けにペタバイト規模までスケールするよう設計された GCP のワイドカラムストアです。
DynamoDB と Bigtable のどちらを使うべきか？
AWS 上で、運用アクセスパターン向けにクラスターを運用する必要のないサーバーレスでリクエスト従量課金のキーバリュー/ドキュメントデータベースが欲しいなら DynamoDB を選びましょう。GCP 上で非常に高スループットまたはペタバイト規模の時系列、IoT、分析データを扱い、HBase/Cassandra API 互換を望み、クラスターノードをプロビジョニングできるなら Google Cloud Bigtable を選びましょう。通常はクラウドとワークロードの形が決め手になります。
DynamoDB vs Bigtable の概要
| 特性 | DynamoDB | Google Cloud Bigtable |
|---|---|---|
| データモデル | NoSQL キーバリュー・ドキュメント。テーブル内で最大 400 KB の型付きアイテム | ワイドカラムストア。行キーでキー付けされた、疎でソートされたマップ。カラムファミリーとセルを持つ（非常に幅広くなり得る） |
| クエリ言語 / API | ネイティブ API（GetItem、Query、Scan）に加え、SQL 互換言語の PartiQL | Bigtable API（行キーの読み取りとスキャン）。HBase および Cassandra API 互換。クエリ向けの SQL サポート |
| キー / アクセス | パーティションキーとオプションのソートキー。既知のパターンを中心に設計されたアクセス | ソート順を決定する単一の行キー。ソートされたキー空間に対する範囲スキャン |
| セカンダリインデックス | グローバルセカンダリインデックス（GSI）とローカルセカンダリインデックス（LSI） | セカンダリインデックスなし。行キーを設計する（必要なら独自のインデックステーブルを保守できる） |
| 整合性 | デフォルトは結果整合性。リクエストごとに強い整合性のある読み取りも利用可能 | 単一クラスターインスタンスでは強い整合性。マルチクラスターインスタンスはデフォルトで結果整合性（構成可能） |
| スケーリングモデル | 自動パーティショニング。サーバーレスのオンデマンドまたはプロビジョンドキャパシティ | プロビジョンドクラスターノード（オートスケーリング対応）。多数のマシンにまたがってペタバイトまでスケール |
| トランザクション | リージョン内で複数アイテムにまたがる ACID トランザクション | 単一行のアトミックな read-modify-write。汎用的なマルチ行 ACID トランザクションはなし |
| 料金 / 運用モデル | リクエスト従量課金（オンデマンド）またはプロビジョンドキャパシティに加えてストレージ。サーバーレス、AWS 限定 | プロビジョンドノード時間に加えて SSD/HDD ストレージ（およびネットワーク）で課金。ノードベース、GCP 限定 |
| 最適なワークロード | 一貫した低レイテンシーを必要とする、予測可能なキーアクセスの運用アプリ | 範囲スキャンを伴うペタバイト規模の時系列、IoT、分析、高スループットな取り込み |
DynamoDB が適している場合
- AWS 上でゼロ運用を望む。 DynamoDB はサーバーレスで、サイズ調整やスケールを行うクラスターノードがありません。オンデマンドキャパシティはリクエスト単位で課金し、トラフィックに合わせて自動的にスケールします。
- アクセスが運用的でキーベースである。 ID による取得、パーティションのクエリ、パーティション内でのフィルタリングは DynamoDB に自然にマッピングされ、セカンダリインデックスによって別テーブルを保守せずに代替キーでクエリできます。
- リクエストごとの強い整合性が欲しい。 DynamoDB はクラスタートポロジーを構成することなく、必要に応じて強い整合性のある読み取りを提供します。
- ネイティブな AWS 統合が必要。 IAM、Lambda、Streams によってグルーコードが減ります。
Bigtable が適している場合
- GCP 上でペタバイト規模のデータを扱う。 Bigtable は数百から数千台のマシンにまたがってペタバイト規模までスケールするよう構築されており、スループットを増やすにはノードを追加します。
- ワークロードが時系列、IoT、分析である。 単一のソートされた行キーと幅広い行は、時間順のデータや大規模な範囲スキャンに適し、Hadoop/Spark/Beam エコシステムに供給できます。
- HBase または Cassandra API 互換が欲しい。 Bigtable はオープンな HBase API 標準と Cassandra API をサポートし、それらのシステムからの移行を容易にします。
- 非常に高い持続的な書き込みスループットを、予測可能なプロビジョンドノードキャパシティで必要とする。
DynamoDB を扱う
DynamoDB が運用ワークロードに合うなら、DynoTable は macOS、Windows、Linux 向けのネイティブなデスクトップクライアントです。標準の AWS 認証情報チェーンを読み取るため、データは DynamoDB に留まり、移行するものは何もありません。アイテムの参照とインライン編集を行い、キー条件やフィルターを視覚的に構築し、DynamoDB のアクセスパターンのルールの範囲内でリレーショナル形状のクエリを表現する SQL Workbench を備え、さらに自分の AWS Bedrock 認証情報で動作する AI アシスタントを追加します。
無料の DynamoDB Expression Builder は、インストールなしで、キー条件、フィルター、更新の各式を SDK、CLI、PartiQL の形式で生成します。DynoTable はクローズドソースの商用アプリです。このページは何をするかを説明するもので、どのように作られているかを説明するものではありません。
よくある質問
DynamoDB は Bigtable をベースにしていますか？
いいえ。両者は AWS と Google の独立した製品です。Bigtable の2006年の設計は、より広い NoSQL 分野（Cassandra を含む）に影響を与え、DynamoDB は Amazon の2007年の Dynamo に由来しますが、両者が共有するのはこの分野における設計上の系譜であり、コードベースではありません。
Bigtable には DynamoDB のようなセカンダリインデックスがありますか？
いいえ。Bigtable は単一の行キーを持ち、セカンダリインデックスはありません。読み取りパターンに合わせて行キーを設計し、必要なら独自のインデックステーブルを保守します。DynamoDB は、代替キーで直接クエリできるグローバルおよびローカルセカンダリインデックスを提供します。
時系列データには DynamoDB と Bigtable のどちらがよいですか？
Bigtable は大規模な時系列向けに専用設計されています。時間範囲にわたるソートされた行キーと幅広い行が、範囲スキャンとペタバイト規模のボリュームに適しています。DynamoDB も時系列を扱えます。一般的には複合ソートキーと時間バケット化されたパーティションを用いる方法で、中程度の規模では AWS 上でよりシンプルな選択肢ですが、Bigtable は非常に大容量な分析の領域向けに設計されています。
関連
- DynamoDB のパーティションキーの仕組み と、時間順データ向けの ソートキー戦略 を学びましょう。
- DynamoDB 整合性ガイド と DynamoDB をいつ使うべきか で読み取りモードを理解しましょう。
- 無料の DynamoDB Expression Builder でクエリをすばやく構築しましょう。
- DynamoDB テーブルの参照、クエリ、編集のために DynoTable をダウンロード。
最終検証日 2026-07-12、公式の AWS DynamoDB Developer Guide および Google Cloud Bigtable のドキュメントに照らして確認しました。Google Cloud Bigtable は Google LLC の商標であり、ここでは識別のみを目的として参照しています。