Deep Dive: Amazon DynamoDB

Yuko Mori

Solutions Architect

Amazon Data Services Japan K.K.

自己紹介

• 森 祐孝(もり ゆうこう)– アマゾンデータサービスジャパン株式会社

– ソリューションアーキテクト

• 経歴– Sierなどで、アプリケーション開発、PL、PMなどを担当

– ゲーム会社（テクニカルディレクタ）• ブラウザソーシャルゲーム、スマートフォン向けソーシャルゲーム

• 担当– ソーシャルゲーム、コンソールゲーム系のお客様のAWS構築支援

Agenda

• DyanamoDBとは

• Table, API, Data Type

• Indexes

• Scaring

• Data Modeling

• ユースケース& ベストプラクティス

• DynamoDB Stream

DyanamoDBとは

Amazon DynamoDBの生い立ち• Amazon.comではかつて全てのアクセスパターンをRDBMSで

処理していた• RDBMSのスケールの限界を超えるため開発されたDynamoが

祖先

• 結果整合性モデル採用による可用性向上

• HWを追加する毎に性能が向上するスケーラビリティ

• シンプルなクエリモデルによる予測可能な性能

Amazon DynamoDBの特徴

• 完全マネージド型の NoSQL データベースサービス

• ハイスケーラブル、低レイテンシー

• 高可用性– 3x レプリケーション

• シンプル且つパワフルAPI

• ストレージの容量制限がない

• 運用管理必要なし

クライアント

Tables, API, Data Types

Tabletable

items

attributes

HashKey

RangeKey

必須キーバリュー型のアクセスパターンデータ分散に利用される オプション

1:Nモデルのリレーションシップ豊富なQueryをサポート

ハッシュキー検索用

==, <, >, >=, <=“begins with”“between”sorted resultscounts先頭/末尾 N件ページ単位出力

• CreateTable

• UpdateTable

• DeleteTable

• DescribeTable

• ListTables

• GetItem

• PutItem

• UpdateItem

• DeleteItem

• Query

• Scan

• BatchGetItem

• BatchWriteItem

• Liststreams

• DescribeStream

• GetShardIterator

• GetRecords

Table API

Stream API

DynamoDB

In preview

AWS SDKs and CLI

• 各種言語むけのオフィシャルSDKやCLIを利用

Java Python PHP .NET Ruby nodeJS

iOS AndroidJavascript

in the Browser AWS CLI

Data Types

• String (S)

• Number (N)

• Binary (B)

• String Set (SS)

• Number Set (NS)

• Binary Set (BS)

• Boolean (BOOL)

• Null (NULL)

• List (L)

• Map (M)

JSON用に定義

00 55 A954 AA FF

Hash Table• Hash key は単体でプライマリキーとして利用

• 順序を指定しないハッシュインデックスを構築するためのキー

• テーブルは、性能を確保するために分割(パーティショニング)される場合あり

00 FF

Id = 1

Name = Jim

Hash (1) = 7B

Id = 2

Name = Andy

Dept = Engg

Hash (2) = 48

Id = 3

Name = Kim

Dept = Ops

Hash (3) = CD

Key Space

データは3箇所にレプリケーション

Id = 2

Name = Andy

Dept = Engg

Id = 3

Name = Kim

Dept = Ops

Id = 1

Name = Jim

Id = 2

Name = Andy

Dept = Engg

Id = 3

Name = Kim

Dept = Ops

Id = 1

Name = Jim

Id = 2

Name = Andy

Dept = Engg

Id = 3

Name = Kim

Dept = Ops

Id = 1

Name = Jim

Replica 1

Replica 2

Replica 3

Partition 1 Partition 2 Partition N

Hash-Range Table

• Hash + Rangeでプライマリキーとすることもできる• Hash keyに該当する複数のデータの順序を保証するためにRange keyが使われる

• Hash Keyの数に上限はありません（Local Secondary Indexesを使用時は上限あり）

00:0 FF:∞

Hash (2) = 48

Customer# = 2

Order# = 10

Item = Pen

Customer# = 2

Order# = 11

Item = Shoes

Customer# = 1

Order# = 10

Item = Toy

Customer# = 1

Order# = 11

Item = Boots

Hash (1) = 7B

Customer# = 3

Order# = 10

Item = Book

Customer# = 3

Order# = 11

Item = Paper

Hash (3) = CD

55 A9:∞54:∞ AAPartition 1 Partition 2 Partition 3

DynamoDBの整合性モデル

• Write

• 少なくとも２つのレプリカでの書き込み完了が確認とれた時点でAck

• Read

• デフォルト

• 結果整合性のある読み込み

• 最新の書き込み結果が反映されない可能性がある

• Consistent Readオプションを付けたリクエスト

• 強力な整合性のある読み込み

• Readリクエストを受け取る前までのWriteがすべて反映されたレスポンスを保証

Indexes

Local Secondary Index (LSI)• Range key以外に絞り込み検索を行うkeyを持つことができる• Hash keyが同一で、他のアイテムからの検索のために利用

• すべての要素（テーブルとインデックス）の合計サイズを、各ハッシュキーごとに 10 GB に制限

A1(hash)

A3(range)

A2(table key)

A1(hash)

A2(range)

A3 A4 A5

LSIs A1(hash)

A4(range)

A2(table key)

A3(projected)

Table

KEYS_ONLY

INCLUDE A3

A1(hash)

A5(range)

A2(table key)

A3(projected)

A4(projected)

ALL

Global Secondary Index (GSI)• Hash Key属性の代わりとなる

• Hash Keyをまたいで検索を行うためのインデックス

A1(hash)

A2 A3 A4 A5

GSIs A5(hash)

A4(range)

A1(table key)

A3(projected)

Table

INCLUDE A3

A4(hash)

A5(range)

A1(table key)

A2(projected)

A3(projected) ALL

A2(hash)

A1(table key) KEYS_ONLY

GSIの更新フロー

Table

Primary

tablePrimary

tablePrimary

tablePrimary

table

Global

Secondary

Index

Client

2. 非同期Update

(in progress)

GSIにはテーブルとは独立したスループットをプロビジョンして利用するため十分なスループットが必要

Scaling

Scaling

• スループット– テーブル単位で、読み書きのスループットを指定（プロビジョニングされたスループット）

• サイズ– テーブルには任意の数のアイテムが追加可能

• 1 つのアイテムの合計サイズは 400 KB

• local secondary index について、異なるハッシュキーの値ごとに最大10 GB のデータを格納

• スケーリングはパーティショニングによって実現

スループット

• テーブルレベルによってプロビジョニング– Write Capacity Units (WCU)

• 1 秒あたりの項目書き込み回数 x 項目のサイズ (1 KB ブロック)

– Read Capacity Units (RCU)

• 1 秒あたりの読み込み回数 x 項目のサイズ (4 KB ブロック)

• 結果整合性のある読み込みをする場合はスループットが 2 倍

• 読み込みと書き込みのスループットはそれぞれ独立

WCURCU

パーティショニングの算出方法

# 𝑜𝑓 𝑃𝑎𝑟𝑡𝑖𝑡𝑖𝑜𝑛𝑠 =𝑇𝑎𝑏𝑙𝑒 𝑆𝑖𝑧𝑒 𝑖𝑛 𝐺𝐵

10 𝐺𝐵(𝑓𝑜𝑟 𝑠𝑖𝑧𝑒)

# 𝑜𝑓 𝑃𝑎𝑟𝑡𝑖𝑡𝑖𝑜𝑛𝑠(𝑓𝑜𝑟 𝑡ℎ𝑟𝑜𝑢𝑔ℎ𝑝𝑢𝑡)

=𝑅𝐶𝑈𝑓𝑜𝑟 𝑟𝑒𝑎𝑑𝑠

3000 𝑅𝐶𝑈+

𝑊𝐶𝑈𝑓𝑜𝑟 𝑤𝑟𝑖𝑡𝑒𝑠

1000𝑊𝐶𝑈

(𝑓𝑜𝑟 𝑡ℎ𝑟𝑜𝑢𝑔ℎ𝑝𝑢𝑡)(𝑓𝑜𝑟 𝑠𝑖𝑧𝑒)(𝑡𝑜𝑡𝑎𝑙)

• スループット

• ストレージサイズ

• 大きいほうを採用

パーティショニング算出例

# 𝑜𝑓 𝑃𝑎𝑟𝑡𝑖𝑡𝑖𝑜𝑛𝑠 =8 𝐺𝐵

10 𝐺𝐵= 0.8 = 1

(𝑓𝑜𝑟 𝑠𝑖𝑧𝑒)

# 𝑜𝑓 𝑃𝑎𝑟𝑡𝑖𝑡𝑖𝑜𝑛𝑠(𝑓𝑜𝑟 𝑡ℎ𝑟𝑜𝑢𝑔ℎ𝑝𝑢𝑡)

=5000𝑅𝐶𝑈

3000 𝑅𝐶𝑈+

500𝑊𝐶𝑈

1000𝑊𝐶𝑈= 2.17 = 3

Table size = 8 GB, RCUs = 5000, WCUs = 500

(𝑡𝑜𝑡𝑎𝑙)

RCUs per partition = 5000/3 = 1666.67WCUs per partition = 500/3 = 166.67Data/partition = 8/3 = 2.66 GB

RCUとWCU の値は均一に各パーテションに割り当てられます

• スループット

• ストレージサイズ

• 大きいほうを採用

DynamoDBの料金体系

• プロビジョニングされたスループットで決まる時間料金– Read/Writeそれぞれプロビジョンしたスループットによって時間あたりの料金がきまる

– 大規模に利用するのであればリザーブドキャパシティによる割引もあり

• ストレージ利用量– 保存したデータ容量によって決まる月額利用料金

– 計算はGBあたりの単価が適用される

http://aws.amazon.com/jp/dynamodb/pricing/詳細はこちらを参照

DynamoDB のスループットを最大限に活用

“DynamoDB のスループットを最大限に活用するには、テーブルを作成するときに、ハッシュキー要素に個別の値が多数含まれ、できるだけランダムかつ均一に値がリクエストされるようにします。”

– DynamoDB Developer Guide

• Space: キーアクセスはなるべく均等になるように

• Time: リクエストはなるべく均等な間隔で

Example: Hot Keys

Part

itio

n

Time

Heat

Example: Periodic spike

DynamoDBのバースト処理は?

• DynamoDBはパーティションごとのキャパシティのうち、利用されなかった分を過去300秒分までリザーブ

• プロビジョン分を超えたバーストラフィックを処理するために利用する– リザーブされたキャパシティは、各パーティションで利用可能

Burst capacity is built-in

0

400

800

1200

1600

Cap

ac

ity U

nit

s

Time

Provisioned Consumed

使われなかったキャパシティ分を保持

保持していたキャパシティを使用

バーストキャパシティ: 300秒(1200 × 300 = 3600 CU)

Burst capacity may not be sufficient

0

400

800

1200

1600

Cap

ac

ity U

nit

s

Time

Provisioned Consumed Attempted

バーストキャパシティ: 300秒(1200 × 300 = 3600 CU)

超過したリクエスト

バーストキャパシティの機能に依存しないように。

Data Modeling

1:1 リレーション or キー・バリュー型

• Hash keyを使ったテーブルまたはGSI

• GetItem かBatchGetItem APIを使用

例: UserIDやEmailから要素を抽出する場合Users TableHash key AttributesUserId = bob Email = bob@gmail.com, JoinDate = 2011-11-15UserId = fred Email = fred@yahoo.com, JoinDate = 2011-12-01

Users-email-GSIHash key AttributesEmail = bob@gmail.com UserId = bob, JoinDate = 2011-11-15Email = fred@yahoo.com UserId = fred, JoinDate = 2011-12-01

1:N リレーション or 親子関係

• Hash key とRange key を使ったテーブル、GSI

• Query APIを使ってアクセス

例:1ユーザでN個のゲームをプレイしている場合User-Games

Hash Key Range key AttributesUserId = bob GameId = Game1 HighScore = 10500, ScoreDate = 2011-10-20UserId = fred GameId = Game2 HIghScore = 12000, ScoreDate = 2012-01-10UserId = bob GameId = Game3 HighScore = 20000, ScoreDate = 2012-02-12

N:M リレーション

• table と GSI を使用してhash key とrange key の要素をスイッチして設計

• Query API を用いてアクセス

例: 1ユーザが複数のゲームをプレイし,

1ゲームで複数のプレイヤーがゲームをしている場合User-Games-Table

Hash Key Range keyUserId = bob GameId = Game1

UserId = fred GameId = Game2

UserId = bob GameId = Game3

Game-Users-GSI

Hash Key Range key

GameId = Game1 UserId = bob

GameId = Game2 UserId = fred

GameId = Game3 UserId = bob

Document (JSON)

• 新データタイプ (M, L, BOOL,

NULL) としてJSONをサポート

• Document SDKs

– 単純なプログラミングモデル

– JSONから、JSONへの変換

– Java, JavaScript, Ruby, .NET

Javascript DynamoDB

string S

number N

boolean BOOL

null NULL

array L

object M

ユースケース及び、ベストプラクティス

イベントログ

Storing time series data

Time Series Tables

Events_table_2015_June

Event_id

(Hash key)

Timestamp

(range key)

Attribute1 …. Attribute N

Events_table_2015_May

Event_id

(Hash key)

Timestamp

(range key)

Attribute1 …. Attribute N

Events_table_2015_April

Event_id

(Hash key)

Timestamp

(range key)

Attribute1 …. Attribute N

Events_table_2015_March

Event_id

(Hash key)

Timestamp

(range key)

Attribute1 …. Attribute N

RCU = 1000

WCU = 100

RCU = 10000

WCU = 10000

RCU = 100

WCU = 10

RCU = 10

WCU = 1

Current table

Older tables

Hot

data

Cold

data

ホットデータとコールドデータは混在させないアーカイブしたコールドデータはS3へ

メッセージアプリ

Large Items

Filters vs Indexes

M:N modeling – Inbox & Sent Items

Messages

Table

Messages App

David

SELECT *

FROM Messages

WHERE Recipient='David'

LIMIT 50

ORDER BY Date DESC

Inbox

SELECT *

FROM Messages

WHERE Sender ='David'

LIMIT 50

ORDER BY Date DESC

Outbox

Recipient Date Sender Message

David 2014-10-02 Bob …

… 48 more messages for David …

David 2014-10-03 Alice …

Alice 2014-09-28 Bob …

Alice 2014-10-01 Carol …

大小のデータが混在

(Many more messages)

David

Messages Table

50 items × 平均 256 KB

大きなメッセージボディーを格納

SELECT *

FROM Messages

WHERE Recipient='David'

LIMIT 50

ORDER BY Date DESC

Inbox

クエリーコストの計算

1回の問い合わせによって取得されるアイテム数

平均アイテムサイズ

4KB毎に1RCU

消費

結果整合性のある読み込み

Recipient Date Sender Subject MsgId

David 2014-10-02 Bob Hi!… afed

David 2014-10-03 Alice RE: The… 3kf8

Alice 2014-09-28 Bob FW: Ok… 9d2b

Alice 2014-10-01 Carol Hi!... ct7r

大きいデータを分けて配置

Inbox-GSI Messages Table

MsgId Body

9d2b …

3kf8 …

ct7r …

afed …

David1. Query Inbox-GSI: 1 RCU

2. BatchGetItem Messages: 1600 RCU

(50 separate items at 256 KB)

(50 sequential items at 128 bytes)

均等に大きいアイテムを読むように配置

(Recipientをindex,

Message メタデータを格納)

Inbox GSI

書き込み処理を単純化

David

PutItem

{

MsgId: 123,

Body: ...,

Recipient: Steve,

Sender: David,

Date: 2014-10-23,

...

}

Inbox

Global secondary

index

Messages

Table

Outbox Sender

Outbox GSI

SELECT *

FROM Messages

WHERE Sender ='David'

LIMIT 50

ORDER BY Date DESC

Messaging app

Messages

Table

David

Inbox

Global secondary

index

Inbox

Outbox

Global secondary

index

Outbox

update

マルチプレイヤーオンラインゲーム

Query filters vs

Composite key indexes

GameId Date Host Opponent Status

d9bl3 2014-10-02 David Alice DONE

72f49 2014-09-30 Alice Bob PENDING

o2pnb 2014-10-08 Bob Carol IN_PROGRESS

b932s 2014-10-03 Carol Bob PENDING

ef9ca 2014-10-03 David Bob IN_PROGRESS

Games Table

マルチプレイヤーオンラインゲームデータ

ゲーム内でのクエリー要件

• DynamoDBのインデックスはhash keyと range

keyのみ対応

• 2つの一致条件と範囲検索を行いたい場合は?

SELECT * FROM Game

WHERE Opponent='Bob‘

AND Status=‘PENDING'

ORDER BY Date DESC

(hash)

(range)

(?)

Secondary Index

Opponent Date GameId Status Host

Alice 2014-10-02 d9bl3 DONE David

Carol 2014-10-08 o2pnb IN_PROGRESS Bob

Bob 2014-09-30 72f49 PENDING Alice

Bob 2014-10-03 b932s PENDING Carol

Bob 2014-10-03 ef9ca IN_PROGRESS David

Approach 1: Query filter

Bob

Secondary Index

Approach 1: Query filter

Bob

Opponent Date GameId Status Host

Alice 2014-10-02 d9bl3 DONE David

Carol 2014-10-08 o2pnb IN_PROGRESS Bob

Bob 2014-09-30 72f49 PENDING Alice

Bob 2014-10-03 b932s PENDING Carol

Bob 2014-10-03 ef9ca IN_PROGRESS David

SELECT * FROM Game

WHERE Opponent='Bob'

ORDER BY Date DESC

FILTER ON Status='PENDING'

(filtered out)

Needle in a haystack

Bob

消費されるキャパシティーユニット数は、フィルタされた分は取り除かれない

Approach 2: 複合キー

StatusDate

DONE_2014-10-02

IN_PROGRESS_2014-10-08

IN_PROGRESS_2014-10-03

PENDING_2014-09-30

PENDING_2014-10-03

Status

DONE

IN_PROGRESS

IN_PROGRESS

PENDING

PENDING

Date

2014-10-02

2014-10-08

2014-10-03

2014-10-03

2014-09-30

Secondary Index

Approach 2: 複合キー

Opponent StatusDate GameId Host

Alice DONE_2014-10-02 d9bl3 David

Carol IN_PROGRESS_2014-10-08 o2pnb Bob

Bob IN_PROGRESS_2014-10-03 ef9ca David

Bob PENDING_2014-09-30 72f49 Alice

Bob PENDING_2014-10-03 b932s Carol

Opponent StatusDate GameId Host

Alice DONE_2014-10-02 d9bl3 David

Carol IN_PROGRESS_2014-10-08 o2pnb Bob

Bob IN_PROGRESS_2014-10-03 ef9ca David

Bob PENDING_2014-09-30 72f49 Alice

Bob PENDING_2014-10-03 b932s Carol

Secondary Index

Approach 2: 複合キー

Bob

SELECT * FROM Game

WHERE Opponent='Bob'

AND StatusDate STARTS_WITH 'PENDING'

Needle in a sorted haystack

Bob

消費されるキャパシティーユニット数を節約

スパースなインデックスの利用

Id (hash)

User Game Score Date Award

1 Bob G1 1300 2012-12-23

2 Bob G1 1450 2012-12-233 Jay G1 1600 2012-12-24

4 Mary G1 2000 2012-10-24 Champ5 Ryan G2 123 2012-03-10

6 Jones G2 345 2012-03-20

Game-scores-table

Award (hash)

Id User Score

Champ 4 Mary 2000

Award-GSI

項目内にインデックスキー値がある場合のみ書き込み

書き込み、読み込みキャパシティユニットも少なくなる

リアルタイム投票システム

Write-heavy items

投票システムの要件

• 投票は一回のみ

• 一度投票したものは変えられない

• リアルタイムに集計

• 投票者の統計、分析を行いたい

リアルタイム投票システムのアーキテクチャ

票集計Table

Voters

投票Table

Voting App

Partition 1

1000 WCUs

Partition K

1000 WCUs

Partition M

1000 WCUs

Partition N

1000 WCUs

投票Table

Candidate A Candidate B

スケールすることによるボトルネック

Voters

Provision 200,000 WCUs

シャーディングでの書き込み

Candidate A_2

Candidate B_1

Candidate B_2

Candidate B_3

Candidate B_5

Candidate B_4

Candidate B_7

Candidate B_6

Candidate A_1

Candidate A_3

Candidate A_4Candidate A_7 Candidate B_8

Candidate A_6 Candidate A_8

Candidate A_5

Voter

投票 Table

シャーディングでの書き込み

Candidate A_2

Candidate B_1

Candidate B_2

Candidate B_3

Candidate B_5

Candidate B_4

Candidate B_7

Candidate B_6

Candidate A_1

Candidate A_3

Candidate A_4Candidate A_7 Candidate B_8

UpdateItem: “CandidateA_” + rand(0, 200)

ADD 1 to Votes

Candidate A_6 Candidate A_8

Candidate A_5

Voter

投票Table

正確な投票

UserId Candidate Date

１ A 2013-10-02

２ B 2013-10-02

３ B 2013-10-02

４ A 2013-10-02

投票Table

Segment Votes

A_1 23

B_2 12

B_1 14

A_2 25

投票集計Table

Voter

1. 投票データの登録、重複排除 2. 投票データの集計

正確な集計は?

UserId Candidate Date

１ A 2013-10-02

２ B 2013-10-02

３ B 2013-10-02

４ A 2013-10-02

投票Table

Segment Votes

A_1 23

B_2 12

B_1 14

A_2 25

投票集計Table

Voter

DynamoDB Stream

In preview

What is DynamoDB Stream?It is a stream of updates

Scales with your table

DynamoDB StreamDynamoDB

In preview

• テーブルの更新の情報を保持

• 非同期に更新

• シリアライズされたデータ

• アイテム毎の厳密な管理

• 高耐久性

• テーブルよるスケール

• 有効期限は24時間

• 1秒未満の遅延書き込み

DynamoDB stream

View Type Destination

Old Image – 更新前の情報 Name = John, Destination = Mars

New Image – 更新後の情報 Name = John, Destination = Pluto

Old and New Images Name = John, Destination = Mars

Name = John, Destination = Pluto

Keys Only Name = John

View types更新情報（Name = John, Destination = Mars）

⇒(Name = John, Destination = Pluto)

Stream

Table

Partition 1

Partition 2

Partition 3

Partition 4

Partition 5

テーブル

Shard 1

Shard 2

Shard 3

Shard 4

KCL

Worker

KCL

Worker

KCL

Worker

KCL

Worker

Amazon Kinesis Client

Library Application

DynamoDB

クライアントアプリケーション 更新

DynamoDB Stream and

Amazon Kinesis Client Library

DynamoDB Stream

Open Source Cross-

Region Replication Library

Asia Pacific (Sydney) EU (Ireland) Replica

US East (N. Virginia)

クロスリージョンレプリケーション

DynamoDB Stream and AWS Lambda

AWS Lambda

• 特徴 (http://aws.amazon.com/jp/lambda/)

– OS、キャパシティ等インフラの管理不要

– S3、Kinesis、SNS等でのイベント発生を元にユーザが用意したコード（Node.js）を実行

– ユーザアプリからの同期/非同期呼び出し

• 価格体系 (http://aws.amazon.com/jp/lambda/pricing/)

– コード実行時間（100ms単位）

– Lambdaファンクションへのリクエスト回数

– 1月あたり100万リクエスト、400,000GB/秒が無料で利用可能

イベントをトリガーにコードを実行するコンピュートサービス

AWS LambdaAmazon S3 Bucket イベント

元画像 サムネイル画像1

2

3

AWS LambdaAmazon DynamoDB

Table and Stream

プッシュ通知

別テーブルを更新

■イメージのリサイズやサムネイルの作成

■値チェックや別テーブルへのコピー

Real-time voting architecture

投票集計Table

Amazon

Redshift Amazon EMR

Your Amazon Kinesis–

Enabled App

Voters 投票TableVoting app 投票DynamoDB

Stream

Real-time voting architecture

投票集計Table

Amazon

Redshift Amazon EMR

Your Kinesis-enabled

app

Voters 投票TableVoting app 投票DynamoDB

Stream

Real-time voting architecture

投票集計Table

Amazon

Redshift Amazon EMR

Your Kinesis-enabled

app

Voters 投票TableVoting app 投票DynamoDB

Stream

Real-time voting architecture

投票集計Table

Amazon

Redshift Amazon EMR

Your Kinesis-enabled

app

Voters 投票TableVoting app 投票DynamoDB

Stream

投票者の統計、分析

DynamoDBが使われているユースケース

• KVSとして– Webアプリケーションのセッションデータベース

– ユーザー情報の格納するデータベース

• 広告やゲームなどのユーザー行動履歴DBとして– ユーザーIDごとに複数の行動履歴を管理するためのデータベース

• ソーシャルアプリのバックエンドとして– モバイルアプリから直接参照できるデータベースとして

• 他にも– バッチ処理のロック管理

– フラッシュマーケティング

– ストレージのインデックス

ユースケースに合わせてDB製品を選択

Elastic

Load

Balancing

ClientsEC2

Amazon

DynamoDB

Managed NoSQL

Amazon RDS

Managed SQL

Amazon ElastiCache

Managed in-memory caching

Amazon Redshift

Managed data

warehouse

BI tools

ありがとうございました！