Amazon ダイナモDB

Amazon ダイナモDB

開発者	アマゾン
初回リリース	2012年1月; 12年前[1] ( 2012-01 )
書かれた	ジャワ
オペレーティング·システム	クロスプラットフォーム
利用可能	英語
タイプ	ドキュメント指向データベース キーバリューデータベース
ライセンス	独自
Webサイト	ダイナモDB

Amazon DynamoDBは、 Amazon Web Servicesポートフォリオの一部としてAmazon.comが提供する、完全に管理された独自のNoSQL データベースです。 ^{[2] [3] DynamoDBは、}レプリケーション、自動スケーリング、保存時の暗号化、オンデマンドバックアップなどの機能が組み込まれた、高速で永続的なキーバリューデータストアを提供します。 ^{[4] [5]}

Amazon.comのCTOであるWerner Vogels氏は、2012年の発表でこのプロジェクトの動機を述べています。^[6] Amazonは分散型サービスネットワークとして始まりました。当初、サービスは互いのデータベースに直接アクセスしていました。これがエンジニアリング運用のボトルネックになったため、サービスはこの直接アクセスパターンから離れ、公開APIを採用しました。それでも、サードパーティのリレーショナルデータベース管理システムは、 Amazonのクライアントベースを処理するのに苦労していました。これは、2004年のホリデーシーズンにピークに達し、いくつかのテクノロジーが高トラフィックで機能しなくなりました。 ^{[7] [8]}

エンジニアは、データの冗長性を減らすために、これらのリレーショナル システムを標準化していました。これは、ストレージを最適化する設計です。犠牲になったのは、特定の「アイテム」のデータ (たとえば、製品データベース内の製品に関する情報) を複数の関係にわたって保存し、クエリ用にばらばらの部分を組み立てるのに時間がかかることでした。Amazon のサービスの多くは、主にデータの主キー読み取りを要求し、速度が最優先であったため、これらの部分を組み立てるのは非常に困難でした。^[9]

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

DynamoDB では、データはテーブルにアイテムとして保存され、インデックスを使用してクエリできます。アイテムは、いくつかのデータ型に属することができるいくつかの属性で構成され、テーブル全体で一意であることが期待される キーを持つ必要があります。

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

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

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

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

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

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

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

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

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

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

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

DynamoDB は、その普遍性から、構文にJSONを使用します。 ^{[引用が必要]}テーブル作成アクションに必要な引数は、TableName、KeySchema (パーティション キーとオプションのソート キーを含むリスト)、AttributeDefinitions (パーティション キーとソート キーとして使用される属性の定義を少なくとも含む必要がある、定義する属性のリスト) の 3 つだけです。リレーショナル データベースは堅牢なクエリ言語を提供しますが、DynamoDB は Put、Get、Update、および Delete 操作のみを提供します。Put リクエストには、TableName 属性と、アイテムが持つすべての属性と値で構成される Item 属性が含まれます。Update リクエストも同じ構文に従います。同様に、アイテムを取得または削除するには、TableName と Key を指定するだけです。

DynamoDB はハッシュとB ツリーを使用してデータを管理します。入力されると、データはまずパーティション キーのハッシュによって異なるパーティションに分散されます。各パーティションは最大 10 GB のデータを格納でき、デフォルトで 1,000 書き込み容量ユニット (WCU) と 3,000 読み取り容量ユニット (RCU) を処理できます。^[12] 1 RCU は、最大 4KB のサイズのアイテムに対して、 1 秒あたり 1 回の強力な一貫性のある読み取り、または 1 秒あたり 2 回の結果的に一貫性のある読み取りを表します。 ^[13] 1 WCU は、最大 1KB のサイズのアイテムに対して、1 秒あたり 1 回の書き込みを表します。

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

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

Amazon のエンジニアは、パーティションやノードのプロビジョニングや管理などのエンジニアリングのオーバーヘッドのため、当初 Dynamo を避けていました。^[9]これに対応して、DynamoDB チームはデータベースを管理する AutoAdmin というサービスを構築しました。^[14] AutoAdmin は、応答が停止したノードを別のノードからデータをコピーして置き換えます。パーティションが 3 つのしきい値 (RCU、WCU、または 10GB) のいずれかを超えると、AutoAdmin は自動的にパーティションを追加してデータをさらにセグメント化します。^[12]

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

DynamoDB ユーザーが書き込み操作 (Put、Update、または Delete) を発行するとします。一般的なリレーショナル システムでは、SQL クエリをリレーショナル代数に変換して最適化アルゴリズムを実行しますが、DynamoDB では両方のプロセスをスキップしてすぐに作業を開始します。^[14]リクエストは DynamoDB リクエスト ルーターに到着し、そこで認証 (「リクエストは、そのリクエストが主張する場所/人から送信されたか?」) が行われ、承認 (「リクエストを送信したユーザーには必要な権限があるか?」) がチェックされます。これらのチェックに合格すると、システムはリクエストのパーティション キーをハッシュして適切なパーティションに到着させます。パーティション内には 3 つのノードがあり、それぞれにパーティションのデータのコピーがあります。システムは最初にリーダー ノードに書き込み、次に 2 番目のノードに書き込み、次に「成功」​​メッセージを送信し、最後に 3 番目のノードに伝播し続けます。書き込みは常に最初にリーダー ノードを通過するため、一貫性があります。

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

ここで、DynamoDB ユーザーが Get 操作を発行するとします。リクエスト ルーターは、前と同じように認証と承認を進めます。次に、上記と同様に、パーティション キーをハッシュして適切なハッシュに到達します。ここで問題が発生します。3 つのノードが互いに結果的に一貫性を保つ場合、どのノードを調べるかをどのように決定すればよいでしょうか。DynamoDB は、読み取りを発行するときに、一貫性と結果的に一貫性のある 2 つのオプションをユーザーに提供します。一貫性のある読み取りでは、リーダー ノードにアクセスします。ただし、一貫性と可用性のトレードオフがここで再び問題になります。読み取りが多いシステムでは、常にリーダーから読み取ると、1 つのノードに負担がかかり、可用性が低下する可能性があります。

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

DynamoDB は、ユーザーが DynamoDB を正しくプロビジョニングし、DynamoDB を使用するアプリケーションをスムーズに実行し続けるために役立つパフォーマンス メトリックを公開します。

• リクエストとスロットリング
• エラー: ProvisionedThroughputExceededException、ConditionalCheckFailedException、内部サーバー エラー (HTTP 500)
• グローバルセカンダリインデックス作成に関連する指標^[16]

これらのメトリクスは、 AWSマネジメントコンソール、AWSコマンドラインインターフェイス、またはAmazon CloudWatchと統合された監視ツールを使用して追跡できます。^[17]

DynamoDB開発者は以下を行うべきである: ^[18]

• データアクセスパターンを特定する
• ポーリングの代わりにイベントを使用する

DynamoDBバインディングを備えた言語とフレームワークには、 Java、JavaScript、Node.js、Go、C# .NET、Perl、PHP、Python、Ruby、Rust、Haskell、Erlang、Django、Grailsなどがあります。^[19]

HTTP API に対するクエリ項目:

POST  /  HTTP / 1.1
ホスト:  dynamodb.<region>.<domain>; 
Accept-Encoding :  identity 
Content-Length :  <PayloadSizeBytes> 
User-Agent :  <UserAgentString> 
Content-Type :  application/x-amz-json-1.0 
Authorization :  AWS4-HMAC-SHA256 Credential=<Credential>、SignedHeaders=<Headers>、Signature=<Signature> 
X-Amz-Date :  <Date> 
X-Amz-Target :  DynamoDB_20120810.Query

{
    "TableName": "返信",
    "インデックス名": "PostedBy-Index",
    「制限」: 3,
    「一貫性のある読み取り」: true、
    "ProjectionExpression": "Id、PostedBy、ReplyDateTime",
    "KeyConditionExpression": "Id = :v1 AND PostedBy BETWEEN :v2a AND :v2b",
    "式属性値": {
        ":v1": {"S": "Amazon DynamoDB#DynamoDB スレッド 1"},
        ":v2a": {"S": "ユーザーA"},
        ":v2b": {"S": "ユーザーC"}
    },
    「ReturnConsumedCapacity」: 「TOTAL」
}

サンプル応答:

HTTP / 1.1  200  OK 
x-amzn-RequestId :  <RequestId> 
x-amz-crc32 :  <Checksum> 
Content-Type :  application/x-amz-json-1.0 
Content-Length :  <PayloadSizeBytes> 
Date :  <Date> 
 { 
    "ConsumedCapacity": { 
        "CapacityUnits": 1, 
        "TableName": "Reply" 
    }, 
    "Count": 2, 
    "Items": [ 
        { 
            "ReplyDateTime": {"S": "2015-02-18T20:27:36.165Z"}, 
            "PostedBy": {"S": "User A"}, 
            "Id": {"S": "Amazon DynamoDB#DynamoDB Thread 1"} 
        }, 
        { 
            "ReplyDateTime": {"S": "2015-02-25T20:27:36.165Z"}, 
            "PostedBy": {"S": "ユーザー B"}, 
            "Id": {"S": "Amazon DynamoDB#DynamoDB スレッド 1"} 
        } 
    ], 
    "ScannedCount": 2 
}

Go での GetItem :

getItemInput := & dynamodb.GetItemInput { TableName : aws.String ( " happy-marketer" ) , Key : map [ string ] * dynamodb.AttributeValue { " pk" : { S : aws.String ( " project" ), } , " sk " : { S : aws.String ( email + " " + name ) , } , } , } getItemOutput , err : = dynamodbClient.GetItem ( getItemInput )  
	 
	 
		 
			 
		
		 
			     
		
	

   

Goでの DeleteItem :

deleteItemInput := & dynamodb . DeleteItemInput { TableName : aws . String ( "happy-marketer" )、Key : map [ string ] * dynamodb . AttributeValue { "pk" : { S : aws . String ( "project" )、}, "sk" : { S : aws . String ( email + " " + name )、}, }, }  
	 
	 
		 
			 
		
		 
			     
		
	


_ 、err := dynamodbClient . DeleteItem ( deleteItemInput )の場合、err != nil { panic ( err ) }   
    
	

式ビルダーを使用して Go で UpdateItem を実行する:

update : =式.Set (式.Name (名前) ,式.Value (値) , )  
	
	


expr , err :=式.NewBuilder ( ) . WithUpdate ( update ) .Build () if err != nil { panic ( err ) }   
    
	


updateItemInput := & dynamodb . UpdateItemInput { TableName : aws . String ( tableName ), Key : map [ string ] * dynamodb . AttributeValue { "pk" : { S : aws . String ( "project" ), }, "sk" : { S : aws . String ( "mySortKeyValue" ), }, }, UpdateExpression : expr . Update (), ExpressionAttributeNames : expr . Names (), ExpressionAttributeValues : expr . Values (), } fmt . Printf ( "updateItemInput: %#v\n" , updateItemInput )  
	 
	 
		 
			 
		
		 
			 
		
	
	          
	  
	 

 

_ 、err = dynamodbClient . UpdateItem ( updateItemInput )の場合、err != nil { panic ( err ) }   
    
	

• アマゾンオーロラ
• Amazon ドキュメントDB
• アマゾンレッドシフト
• Amazon リレーショナル データベース サービス
• ScyllaDB (DynamoDB 互換)
• リレーショナルデータベース管理システムの比較

• 公式サイト
• ビデオ: AWS re:Invent 2019: [繰り返し 1] Amazon DynamoDB の詳細: 高度な設計パターン (DAT403-R1)