アマゾンダイナモDB
アマゾンダイナモDB
開発者Amazon.com
初回リリース2012年1月[ 1 ] （2012年1月）
書かれたジャワ
オペレーティング·システムクロスプラットフォーム
入手可能な英語
タイプ
ライセンス独自の
Webサイトaws .amazon .com /dynamodb /

Amazon DynamoDBは、 Amazon Web Services （AWS）が提供するマネージドNoSQLデータベースサービスです。キーバリュー型とドキュメント型のデータ構造をサポートし、スケーラビリティとパフォーマンスが求められる幅広いアプリケーションに対応できるように設計されています。[ 2 ]

歴史

Amazon.comのCTOであるヴェルナー・フォーゲルス氏は、2012年の発表でこのプロジェクトの動機を説明しました。[ 3 ] Amazonは分散型サービスネットワークとして始まりました。当初、サービスは互いのデータベースに直接アクセスしていました。これがエンジニアリング運用のボトルネックになったため、サービスはこの直接アクセスパターンをやめ、公開APIを導入しました。それでも、サードパーティのリレーショナルデータベース管理システムはAmazonの顧客ベースに対応するのに苦労していました。この苦境は2004年のホリデーシーズンに頂点に達し、 [ 4 ] [ 5 ]トラフィックの増加によりいくつかの技術が機能不全に陥りました。

従来のデータベースでは、スペースを節約するためにデータを小さな断片に分割することがよくありますが、検索中にこれらの断片を組み合わせるとクエリが遅くなる可能性があります。Amazonの多くのサービスは、主に主キーによるデータの読み取りを必要としており、速度が最優先事項であったため、これらの断片をまとめるのは非常に負担が大きかったのです。[ 6 ]

ストレージ効率を犠牲にしてAmazonが出した答えは、社内利用向けに構築された高可用性のキーバリューストア、Dynamoでした。 [ 3 ] DynamoはAmazonのエンジニアが必要としているものをすべて備えているように見えましたが、普及は遅れました。Amazonの開発者は、 S3とSimpleDBという「そのまま使える」設計パターンを選択しました。これらのシステムには目立った設計上の欠陥がありましたが、ハードウェアのプロビジョニングやデータのスケーリングと再パーティション化といったオーバーヘッドは発生しませんでした。AmazonのNoSQL技術の次の段階であるDynamoDBは、これらのデータベース管理操作を自動化しました。

概要

ウェブコンソール
ウェブコンソール

DynamoDBはデータをスプレッドシートに似たテーブルに整理します。各テーブルには項目（行）が含まれ、各項目は属性（列）で構成されています。各項目には主キーと呼ばれる一意の識別子があり、テーブル内での特定に役立ちます。

DynamoDB テーブル

DynamoDBテーブルは、テーブルに格納されるデータを表す項目の論理的なグループです。DynamoDBはNoSQLであるため、テーブル内のすべての項目が事前定義されたスキーマに準拠する必要はありません。[ 7 ]

DynamoDB アイテム

DynamoDB のアイテムは、テーブル内で一意に識別できる属性のセットです。属性は、それ自体がキーと値のペアであるアトミックなデータエンティティです。キーは常に文字列型で、値は複数のデータ型のいずれかになります。

アイテムは、キーと呼ばれる属性のサブセットを使用してテーブル内で一意に識別されます。[ 7 ]

DynamoDBのキー

主キーとは、DynamoDB テーブル内の項目を一意に識別する属性のセットです。DynamoDB テーブルを作成するには、主キーを定義する必要があります。DynamoDB テーブル内の各項目は、主キーを構成するすべての属性を持つ必要があり、テーブル内の複数の項目が同じ主キーを持つことはできません。Dynamo DB の主キーは、1 つまたは 2 つの属性で構成できます。

主キーが1つの属性のみで構成されている場合、それはパーティションキーと呼ばれます。パーティションキーは、関連付けられた項目の物理的な位置を決定します。この場合、テーブル内の2つの項目が同じパーティションキーを持つことはできません。

プライマリキーが2つの属性で構成されている場合、最初の属性は「パーティションキー」、2番目の属性は「ソートキー」と呼ばれます。前述のように、パーティションキーはデータの物理的な位置を決定しますが、ソートキーは、その物理的な位置内での関連項目のレコードの相対的な論理位置を決定します。この場合、テーブル内の2つの項目が同じパーティションキーを持つことができますが、パーティション内の2つの項目が同じソートキーを持つことはできません。言い換えれば、パーティションキーとソートキーの特定の組み合わせには、DynamoDBテーブル内で最大1つの項目が関連付けられることが保証されています。[ 7 ]

DynamoDB データ型

DynamoDBは数値、文字列、ブール値、ドキュメント、セットデータ型をサポートしています。[ 8 ]

DynamoDB インデックス

テーブルの主キーは、DynamoDB テーブルのデフォルトまたはプライマリインデックスです。

さらに、DynamoDB テーブルにはセカンダリインデックスを設定できます。セカンダリインデックスは、プライマリインデックスのパーティションキーやソートキーとは異なる属性に定義されます。

セカンダリ インデックスがプライマリ インデックスと同じパーティション キーを持ち、ソート キーが異なる場合、ローカル セカンダリ インデックスと呼ばれます。

プライマリインデックスとセカンダリインデックスが異なるパーティションキーを持つ場合、セカンダリインデックスはグローバルセカンダリインデックスと呼ばれます。[ 7 ]

DynamoDB データモデリングにおけるアーキテクチャパターン

DynamoDBデータモデリングパターンは、分散システム向けに設計されたNoSQLデータベースサービスであるAmazon DynamoDBで使用されるアーキテクチャアプローチです。これらのパターンには、DynamoDBの400KBのアイテムサイズ制限を遵守しながら関連データを統合する「単一テーブル設計」、アクセスパターンとデータモデルの違いに基づいてデータを個別のテーブルに分割する「複数テーブル設計」、そして両方のアプローチを組み合わせて柔軟性と効率性のバランスをとる「ハイブリッド設計」など、様々なデータ編成の課題に対応するものがあります。[ 9 ] [ 10 ] [ 11 ]

AWSドキュメントに記載されているその他のパタ​​ーンには、「イベントソーシング」があります。これは、データの変更が不変のイベントとして保存され、履歴状態の再構築を可能にします。「マテリアライズドビュー」は、事前計算された集計を通じて分析クエリを簡素化します。これは、多くの場合、DynamoDBストリーム、アプリケーションレベルの処理、またはLambda関数を使用した定期的なバッチ更新によって実装されます。また、「時系列設計」は、ログ記録やメトリクスなどのワークロードに最適化されており、通常、エンティティ識別用のパーティションキーと、タイムスタンプを表すソートキーを使用して、時間ベースのデータセットを効率的にクエリします。[ 12 ] [ 13 ] [ 14 ]

各パターンは特定の技術要件に対応しています。「単一テーブル設計」は、関連するデータを同じパーティションキーの下に配置することでクエリ効率を最適化し、アクセスレイテンシを削減します。「複数テーブル設計」は、異なるアクセスパターンを持つ目的別のテーブルにデータを分離することで、関心の分離を実現します。「イベントソーシング」は、多くの場合、不変データストレージを使用して実装される、状態変化の履歴ログを保存します。「マテリアライズドビュー」は、アクセスパターンに合わせて調整された事前集計戦略を通じて、複雑な分析クエリを簡素化します。「時系列設計」は、パーティション分割とソート戦略を用いて、大量の時系列データを効率的に保存およびクエリします。[ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ]

DynamoDB のレイテンシーに関するパフォーマンスの制限

Amazon DynamoDBの1桁ミリ秒のレイテンシーという主張は、主に、プライマリキーを使用して個々のアイテムを取得または変更する、GetItemやなどの単純な操作に適用されますPutItem。これは、均等なパーティション分散と十分なスループットのプロビジョニングなどの理想的な条件下での平均レイテンシーを反映しており、DynamoDBエンドポイントとの通信中に発生するトランスポートオーバーヘッドは考慮されていません。Queryフィルター、、Scanまたは大規模なデータセットを含む操作などのより複雑な操作では、追加の計算とデータ転送要件により、レイテンシーが増加する可能性があります。[ 15 ] [ 16 ]

ロック

DynamoDBはネイティブでロックをサポートしていませんが、異なるメカニズムが存在します。楽観的ロックでは、事前に競合を防ぐのではなく、更新後に発生する競合を検出するためにバージョン番号を使用する場合があります。対照的に、悲観的ロックでlockTimeは、やなどの属性を使用した条件付き更新が行われる場合があります。これらの属性は、 Time to LivelockedBy （TTL）と組み合わせることで、期限切れのロックを自動的に削除することを可能にし、イベント駆動型アーキテクチャにおける同時実行管理を強化する可能性があります。[ 15 ] [ 17 ] [ 18 ] [ 19 ]

システムアーキテクチャ

DynamoDBでのテーブル作成

データ構造

DynamoDBはハッシュとBツリーを用いてデータを管理します。入力されたデータは、まずパーティションキーに基づいてハッシュ化され、異なるパーティションに分散されます。各パーティションは最大10GBのデータを格納でき、デフォルトで1,000書き込み容量単位（WCU）と3,000読み込み容量単位（RCU）を処理できます。[ 20 ] 1RCUは、最大4KBのサイズのアイテムに対して、1秒あたり1回の強力な整合性のある読み込み、または1秒あたり2回の結果整合性のある読み込みを表します。 [ 21 ] 1WCUは、最大1KBのサイズのアイテムに対して、1秒あたり1回の書き込みを表します。

データ損失を防ぐため、DynamoDBはレプリケーションと長期保存の2層バックアップシステムを備えています。[ 22 ]各パーティションには3つのノードがあり、各ノードにはそのパーティションのデータのコピーが含まれています。また、各ノードには2つのデータ構造が含まれています。1つはアイテムの位置を特定するためのBツリー、もう1つはノードに加えられたすべての変更を記録するレプリケーションログです。DynamoDBはこれらの2つのデータ構造のスナップショットを定期的に取得し、S3に1か月間保存します。これにより、エンジニアはデータベースのポイントインタイムリストアを実行できます。

各パーティション内では、3つのノードのうち1つが「リーダーノード」に指定されます。すべての書き込み操作は、伝播前にまずリーダーノードを通過します。これにより、DynamoDB内で書き込みの一貫性が保たれます。リーダーノードは、そのステータスを維持するために、1.5秒ごとに他の各ノードに「ハートビート」を送信します。他のノードがハートビートの受信を停止した場合、そのノードは新しいリーダーの選出を開始できます。DynamoDBは、リーダーの選出にPaxosアルゴリズムを使用します。

Amazonのエンジニアは当初、パーティションやノードのプロビジョニングや管理といったエンジニアリング上のオーバーヘッドを理由に、Dynamoの使用を避けていました。[ 6 ]これに対し、DynamoDBチームはデータベース管理のためのAutoAdminというサービスを開発しました。[ 22 ] AutoAdminは、ノードが応答を停止すると、別のノードからデータをコピーすることでノードを置き換えます。パーティションが3つのしきい値（RCU、WCU、または10GB）のいずれかを超えると、AutoAdminは自動的にパーティションを追加し、データをさらに細分化します。[ 20 ]

リレーショナルモデルのインデックスシステムと同様に、DynamoDBではテーブルへの更新が各テーブルのインデックスに反映される必要があります。DynamoDBはこれを「ログプロパゲータ」と呼ばれるサービスを使って処理します。ログプロパゲータは各ノードのレプリケーションログを購読し、必要に応じてインデックスに追加のPut、Update、Deleteリクエストを送信します。[ 22 ]インデックスは書き込みリクエストのパフォーマンスに重大な影響を与えるため、DynamoDBでは、ユーザーが特定のテーブルに対して最大5つのインデックスしか使用できません。[ 23 ]

クエリ実行

DynamoDBユーザーが書き込み操作（Put、Update、またはDelete）を実行するとします。一般的なリレーショナルシステムではSQLクエリをリレーショナル代数に変換し、最適化アルゴリズムを実行しますが、DynamoDBでは両方の処理を省略します。[ 22 ]リクエストはDynamoDBリクエストルーターに到達し、そこで認証（「リクエストはどこから、誰から送信されたのか？」）と認可（「リクエストを送信したユーザーは必要な権限を持っているのか？」）が行われます。これらのチェックに合格すると、システムはリクエストのパーティションキーをハッシュ化し、適切なパーティションに書き込みます。パーティション内には3つのノードがあり、それぞれがパーティションのデータのコピーを保持しています。システムはまずリーダーノードに書き込み、次に2番目のノードに書き込み、「成功」メッセージを送信し、最後に3番目のノードへの書き込みを続けます。書き込みは常にリーダーノードを経由するため、一貫性が保たれます。

最後に、ログプロパゲータは変更をすべてのインデックスに伝播します。各インデックスについて、ログプロパゲータはアイテムからそのインデックスの主キー値を取得し、ログ伝播なしで同じ書き込みをそのインデックスに対して実行します。操作が既存のアイテムに対する更新である場合、更新された属性はインデックスの主キーとして機能する可能性があるため、そのインデックスのBツリーも更新する必要があります。Bツリーは挿入、削除、読み取り操作のみを処理するため、実際にはログプロパゲータが更新操作を受信すると、すべてのインデックスに対して削除操作と書き込み操作の両方を発行します。

ここで、DynamoDB ユーザーが Get 操作を発行したとします。リクエストルーターは前述と同様に認証と承認を行います。次に、上記と同様にパーティションキーをハッシュ化し、適切なハッシュ値を取得します。ここで問題が発生します。3 つのノードが互いに結果整合性を持つ場合、どのノードを調査すべきかをどのように判断すればよいでしょうか？ DynamoDB は、読み取りを発行する際に、一貫性と結果整合性の 2 つのオプションを提供します。一貫性のある読み取りは、リーダーノードにアクセスします。しかし、ここでも一貫性と可用性のトレードオフが問題となります。読み取り負荷の高いシステムでは、常にリーダーノードから読み取りを行うと、単一のノードに過負荷がかかり、可用性が低下する可能性があります。

2つ目のオプションである結果整合性のある読み取りでは、ランダムなノードが選択されます。実際には、DynamoDBはここで整合性を犠牲にして可用性を確保しています。この方法を採用した場合、不整合が発生する確率はどれくらいでしょうか？書き込み操作は「成功」を返し、3番目のノードへの伝播を開始する必要がありますが、完了する必要はありません。また、Get操作もこの3番目のノードを対象にする必要があります。つまり、書き込み操作の伝播時間枠内で不整合が発生する確率は3分の1です。この伝播時間はどれくらいでしょうか？様々な災害によってノードが遅延する可能性はありますが、ほとんどの場合、3番目のノードはリーダーノードから数ミリ秒以内に最新の状態になります。

論争

2025年10月19日、DynamoDBコンポーネントの競合状態によりAmazonのUS-EAST-1リージョンで14時間の停止が発生し、[ 24 ]世界中のサービスが広範囲に停止しました。[ 25 ]

参照

参考文献

  1. ^ 「Amazon DynamoDB – インターネット規模のアプリケーション向けに設計された高速でスケーラブルなNoSQLデータベースサービス - All Things Distributed」 www.allthingsdistributed.com 2012年1月18日。
  2. ^ 「Amazon DynamoDB とは何ですか?」。
  3. ^ a b Vogels, Werner (2012年1月18日). 「Amazon DynamoDB – インターネット規模のアプリケーション向けに設計された高速かつスケーラブルなNoSQLデータベースサービス」 All Things Distributedブログ. 2012年1月21日閲覧。
  4. ^ 「AmazonのDynamoDBがデータベースの改革にどのように貢献したか」 Network World . 2023年11月30日閲覧。
  5. ^ brockmeier 1, joe (2012年1月18日). 「Amazon、DynamoDBでNoSQLに新たな一歩」 . ReadWrite . 2023年11月30日閲覧。{{cite web}}: CS1 maint: numeric names: authors list (link)
  6. ^ a bデカンディア、ジュゼッペ;デニズ、ハストールン。ジャンパニ、マダン。カクラパティ、グナヴァルダン。ラクシュマン、アヴィナシュ。ピルチン、アレックス。シヴァスブラマニアン、スワミナタン。ヴォッシャル、ピーター。フォーゲルス、ヴェルナー (2007 年 10 月)。 「Dynamo: Amazon の高可用性 Key-Value ストア」。シゴプス・オペラ。システム。 Rev . 41 (6): 205–220。土井: 10.1145/1323293.1294281。ISSN 0163-5980。 
  7. ^ a b c d「Amazon DynamoDB のコアコンポーネント - Amazon DynamoDB」 . docs.aws.amazon.com . 2023年5月28日閲覧。
  8. ^ 「Amazon DynamoDB でサポートされているデータ型と命名規則 - Amazon DynamoDB」 . docs.aws.amazon.com . 2023年5月28日閲覧。
  9. ^ a b「Amazon DynamoDB を使用した単一テーブル設計の作成」。2021 年 7 月 26 日。
  10. ^ a b「Amazon DynamoDB における単一テーブル設計と複数テーブル設計」。
  11. ^ a b「DynamoDB のデータモデリングの基礎」。
  12. ^ a b「DynamoDB で時系列データを処理するためのベストプラクティス」。
  13. ^ a b「AWS 規範的ガイダンス マイクロサービスでのデータ永続性の有効化」。
  14. ^ a b「Amazon DynamoDB を使用して CQRS イベント ストアを構築する」。2022 年 9 月 26 日。
  15. ^ a b Dhingra, Aman; MacKay, Mike (2024年8月30日). Amazon DynamoDB - 決定版ガイド: 予測可能でスケーラブルなパフォーマンスを備えたエンタープライズ対応のサーバーレスNoSQLを探る. Packt Publishing. ISBN 9781803248325。
  16. ^ 「Amazon DynamoDB のレイテンシー問題のトラブルシューティング」。
  17. ^ 「DynamoDB での式の使用」。
  18. ^ 「DynamoDB での有効期限 (TTL) の使用」。
  19. ^ 「DynamoDB とバージョン番号を使用した楽観的ロック」。
  20. ^ a b Gunasekara, Archie (2016年6月27日). 「DynamoDBパーティションの詳細」 . Shine Solutions Group . 2019年8月3日閲覧。
  21. ^ 「Amazon DynamoDB 開発者ガイド」 . AWS . 2012年8月10日. 2019年7月18日閲覧。
  22. ^ a b c d AWS re:Invent 2018: Amazon DynamoDB Under the Hood: How We Built a Hyper-Scale Database (DAT321)、2018年11月27日、2019年8月3日取得
  23. ^ 「Amazon DynamoDB のサービス、アカウント、およびテーブルのクォータ - Amazon DynamoDB」 . docs.aws.amazon.com . 2024年1月9日閲覧。
  24. ^ 「北バージニア（US-EAST-1）リージョンにおけるAmazon DynamoDBサービス障害の概要」AWS . 2025年10月28日閲覧。
  25. ^ 「単一障害点がAmazonの障害を引き起こし、数百万人に影響」 Ars Technica 2025年10月28日閲覧。
「 https://en.wikipedia.org/w/index.php?title=Amazon_DynamoDB&oldid=1324507979」から取得