Amazon DynamoDB Advanced Design Pattern

© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Amazon DynamoDB
Advanced Design Pattern
Daichi Egawa, AWS Solutions Architect

Agenda
• はじめに
• Amazon DynamoDB 概要＆
データモデリングのためのおさらい
• NoSQL データモデリング
• DynamoDB を活用したデザインパターン

本日お話しすること
• 想定する参加者
• Amazon DynamoDB を既に利用している
• Amazon DynamoDB の基本的な用語や機能を知っている
• 例)パーティション、GSI, LSI など
• お話しする内容
• Amazon DynamoDB のテーブル設計のポイント
• ユースケースに応じて、Amazon DynamoDB を
どのように利用するかの例

Amazon DynamoDBの生い立ち
Amazon.comではかつて全アクセスパターンをRDBMSで処理
RDBMSのスケールの限界を超えるため開発された
Dynamoが祖先
• 結果整合性モデル採用に
よる可用性向上
• HWを追加する毎に性能
が向上するスケーラビリ
ティ
• シンプルなクエリモデル
による予測可能な性能

Amazon DynamoDB
ドキュメント型 or KVS 高いスケーラビリティ完全マネージド型
NoSQL データベースサービス
アクセスコントロールイベントドリブン
プログラミング
高速かつ一貫した
パフォーマンス

管理不要で高い信頼性
• SPOFの存在しない構成
• データは3箇所のAZに保存されるので信頼性が高い
• ストレージは必要に応じて自動的にパーティショニング
クライアント

テーブル設計基礎知識
table
items
attributes
Partation
Key
Sort Key
必須
キーバリュー型のアクセスパターン
データ分散に利用される
オプション
1:Nモデルのリレーションシップ
豊富なQueryをサポート
デフォルトの並べ替え順序は昇順
キー検索用
==, <, >, >=, <=
“begins with”
“between”
sorted results
counts
先頭/末尾 N件
ページ単位出力
name/value 型、JSON 型等
アイテム間で不揃いであって
も問題ない

Local Secondary Index (LSI)
• Sort key以外に絞り込み検索を行うkeyを持つことができる
• Partition keyが同一で、他のアイテムからの検索のために利用
• すべての要素（テーブルとインデックス）の合計サイズを、各ハッシュ
キーごとに 10 GB に制限
A1
(PK)
A3
(Sort)
A2
(table key)
A1
(PK)
A2
(Sort)
A3 A4 A5
LSIs A1
(PK)
A4
(Sort)
A2
(table key)
A3
(projected)
Table
KEYS_ONLY
INCLUDE A3
A1
(PK)
A5
(Sort)
A2
(table key)
A3
(projected)
A4
(projected)
ALL

Global Secondary Index (GSI)
Partition Key属性の代わりとなる
Partition Keyをまたいで検索を行うためのインデックス
A1
(PK)
A2 A3 A4 A5
GSIs
A5
(PK)
A4
(Sort)
A1
(table key)
A3
(projected)
Table
INCLUDE A3
A4
(PK)
A5
(Sort)
A1
(table key)
A2
(projected)
A3
(projected) ALL
A2
(PK)
A1
(table key)
KEYS_ONLY

NoSQL Data Modeling

SQL vs. NoSQL design pattern
商品
アルバム
トラック

1:1 リレーション or キー・バリュー型
• Partition keyを使ったテーブルまたはGSI
• GetItem かBatchGetItem APIを使用
• 例: UserIDやEmailから要素を抽出する場合
Users Table
Partition key Attributes
UserId = bob Email = bob@gmail.com, JoinDate = 2011-11-15
UserId = fred Email = fred@yahoo.com, JoinDate = 2011-12-01
Users-email-GSI
Partition key Attributes
Email = bob@gmail.com UserId = bob, JoinDate = 2011-11-15
Email = fred@yahoo.com UserId = fred, JoinDate = 2011-12-01

1:N リレーション or 親子関係
• Partition key とSort key を使ったテーブル、GSI
• Query APIを使ってアクセス
• 例:1ユーザでN個のゲームをプレイしている場合
User-Games
Partition Key Sort key Attributes
UserId = bob GameId = Game1 HighScore = 10500,
ScoreDate = 2011-10-20
UserId = fred GameId = Game2 HIghScore = 12000,
UserId = bob GameId = Game3 HighScore = 20000,

N:M リレーション
• table と GSI を使用してPartition key とSort key の要素を
スイッチして設計
• Query API を用いてアクセス
• 例: 1ユーザが複数のゲームをプレイし,1ゲームで複数のプレイヤーがゲー
ムをしている場合
User-Games-Table
Partition Key Sort key
UserId = bob GameId = Game1
UserId = fred GameId = Game2
UserId = bob GameId = Game3
Game-Users-GSI
Partition Key Sort key
GameId = Game1 UserId = bob
GameId = Game2 UserId = fred
GameId = Game3 UserId = bob

Targeting queries
Query filters, composite keys, and sparse indexes

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
BobPartition key Sort key
複数の値を条件にしたソート・絞り込み

Secondary Index
Approach 1: Query filter(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)
アクセスイメージ

Approach 2: Composite key(キーの結合)
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
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
Partition key Sort key

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
Bob
SELECT * FROM Game
WHERE Opponent='Bob'
AND StatusDate BEGINS_WITH 'PENDING'

Sparse indexes
Id
(Partition)
User Game Score Date Award
1 Bob G1 1300 2012-12-23
2 Bob G1 1450 2012-12-23
3 Jay G1 1600 2012-12-24
4 Mary G1 2000 2012-10-24 Champ
5 Ryan G2 123 2012-03-10
6 Jones G2 345 2012-03-20
Game-scores-table
Award
(Partition)
Id User Score
Champ 4 Mary 2000
Award-GSI
Scan sparse GSIs
テーブル全体を Scan する場合に比べて
少ないコストで Scan, Query が可能

フィルターの代わりにインデックスを活用
• Attribute の結合(Composite Key)により、
より効果的なセカンダリインデックスキーを実現
• Sparse indexes によりクエリコストを削減
クエリを最適化したい場面で効果的
Status + Date

GSI Overloading
Holding many different types of data
Beyond GSI limitation

GSI OVERLOADING(GSI の多重定義)
• GSI の制限：テーブルあたり最大5つまで
• DynamoDB テーブルでは異なるデータを1つの item で保持可能
• 一つのGSIで複数の用途で利用できる様に定義(Overload)
• Overloadするattributeの値はitemのcontextが分かる値にする
例: 従業員テーブルにたいして以下の情報を元にクエリしたい場合
(1) 従業員名 (2)デスク(3) 採用日(4) 四半期ごとの売上高
(5) ジョブロール/役職 (6) 住所 (7)ロケーションion (8) 従業員ID
などなど

RDBMSの場合
勤務地
大阪Rows
Primary Key Index
東京
北海道
社員ID 名前
1
2
3
桑野
江川
西谷
職種
SA
SA
SA
Columns
もし勤務地、職種などで
検索したければその時必
要なIndexを作成する

GSI OVERLOADINGの例
Data
東京
AttributePartition Key Sort Key
桑野
SA
社員ID ColA
1
1
1
名前
勤務地
職種

GSI OVERLOADINGの例
Data
東京
AttributePartition Key Sort Key
桑野
SA
社員ID ColA
1
1
1
名前
勤務地
職種
Data
東京
桑野
SA
ColA
名前
勤務地
職種
Partition KeySort Key
社員
ID
1
1
1
GSI
GSIを作成しColAの値
と、Dataの組で検索す
ることで一つのGSIで複
数の条件を検索できる

GSI OVERLOADING(GSI の多重定義)
• GIS のテーブルあたりの作成数に関する制限を回避
• テーブル構成としては複雑になる点に注意
 RDBMS で実現する場合に比べて、DynamoDB で得たいメリットを整理
多数の異なるデータをもとにクエリをかけたい場面で効果的

Vertical Pertitioning
(メッセージアプリ)
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 …
David
1. 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 メタデータを格納)

Messaging app
Messages
Table
David
Inbox
Global secondary
index
Inbox
Outbox
Global secondary
index
Outbox
update

大きい Item の分割
• 1:Nを表す Item サイズの削減
• secondary index の設定
• GSI により M:N リレーションの構築
サイズが大きい Item を一度に多数クエリする際に効果的
ProcessedReportsPending

Design patterns and best practices

DynamoDB Triggers
DynamoDB + AWS Lambda= DynamoDB Triggers
● AWS Lambdaとは
- OS、キャパシティ等インフラの管理不要
- S3、Kinesis、SNS等での
イベント発生を元にユーザが
用意したコードを実行
- ユーザアプリからの
同期/非同期呼び出し

DynamoDB Triggers ユースケース
• DynamoDBへの書き込みに応じて値チェックをしつつ別テーブルの
更新やプッシュ通知を実行
• DynamoDBの更新状況の監査ログをS3に保存
• ゲームデータなどのランキング集計を非同期に実施
AWS Lambda
Amazon DynamoDB
Table and Streams
プッシュ通知
別テーブルを
更新
監査ログを
保存

TTL（Time To Live）
特徴
• Itemの有効期限が切れ、データベースか
ら自動削除されるタイミングを定義可能
• プロビジョニングスループットを使用す
ることなく、関連性のないデータのスト
レージ使用量と保存コストを削減可能
• 追加料金なし
• 既存・新規のテーブルに設定可能
• DynamoDB Streamsとの併用可能
注意点
• 期限切れ後、即削除されるわけではない
 48時間以内に削除
 読み取り時に期限切れのものを取得し
ないようにするにはQuery or
アプリ側でのフィルタが必要
詳細：https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/TTL.html

Time-based workflows
(チケットシステム)
Processing the entire table efficiently

時系列データが必要なアプリケーション
• ホットデータとコールドデータでテーブルを分ける
• DynamoDB StreamsとGSIを活用し、非同期でホットデータをコール
ドデータへと移動する
• ホットデータではWCU、RCUを高く設定、コールドデータでは
書き込み、読み込みは最低限必要な分のみに限定する
• コスト最適化

時系列データが必要なアプリケーション
Active Tickets_Table(現在処理する必要があるチケット)
Event_id
(Partition)
Timestamp GSIKey
Rand(0-N)
… Attribute N
Expired Tickets GSI
GSIKey
(Partition)
Timestamp
(Sort)
Archive Table(処理/解決済みのアーカイブされたチケット)
Event_id
(Partition)
Timestamp
(Sort)
Attribute1 …. Attribute N
RCUs = 10000
WCUs = 10000
RCUs = 100
WCUs = 1
Current table
コールドデータ
期限切れのデータをTTLを使用してアーカイブ
AWS Lambda DynamoDB Streams
ホットデータ

AWS Lambda を活用してテーブルを効率良く整理
• ホットデータとコールドデータでテーブルを分ける
• テーブル全体に効率的にクエリをかけるために GSI を使用
• Lambda “ストアドプロシージャ”を作成し、Item を遷移
• TTL/DynamoDB Streams/Lambda を利用してテーブル間で
データを移行
全て/多くのItem を効率良くクエリしなければいけない場合に効果的

Product catalog
Popular items (read)
アクセスが集中する特定の Item に対する Read

Partition 1
2000
RCUs
Partition K
2000 RCUs
Partition M
2000 RCUs
Partition 50
2000 RCU
特定のパーティションに対して集中した読み込み
商品 A 商品 B
Shoppers
商品カタログテーブル
SELECT Id, Description, ...
FROM ProductCatalog
WHERE Id="POPULAR_PRODUCT"

特定のパーティションに対して集中した読み込み

• フルマネージドかつ高可用性: リージョン内でマルチAZ構成かつ
キャッシュ情報のレプリケーション、障害時のフェイルオーバーな
どをフルマネージドで実現
• DynamoDB API互換: 現在のSDKと互換性を保っているので
コードの大部分は書き直す必要が無い
• Write-through: ライトスルーでキャッシュを保持
• Flexible: 様々なDynamoDBのテーブル状況に対応
• Scalable: 最大10ノードまでのスケールアウトに対応
• Manageability: Amazon CloudWatch, Tagging for DynamoDB,
AWS Consoleなどとの連携も完備
• Security: Amazon VPC, AWS IAM, AWS CloudTrail, AWS
Organizationsに対応
特徴
DynamoDB Accelerator (DAX)によるキャッシング
DynamoDB
Your Applications
DynamoDB Accelerator

特定パーティションへの偏りをキャッシュで吸収

Write sharding
Handling high velocity writes

Partition 1
1000
WCUs
Partition K
1000 WCUs
Partition M
1000 WCUs
Partition N
1000 WCUs
投票テーブル
Candidate
(候補者) A
Candidate B
特定のパーティションに対して集中した書き込み
投票者
Provision 200,000 WCUs

キューによる負荷調整
Workers
Dashboard
SQS
• 送信される投票内容を
一旦、SQS で受ける
• SQS からメッセージを取得
してDynamoDB へ書き込み
を実施する Worker を必要に
応じてスケールさせ、キュー
内のメッセージを処理
• 特定キーへの偏りを回避

書き込みのシャーディング
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_4
Candidate A_7 Candidate B_8
Candidate A_6 Candidate A_8
Candidate A_5
投票者
投票テーブル

書き込みのシャーディング
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_4
Insert: “CandidateA_” + rand(0, 10)
Candidate A_5
投票者
投票テーブル

投票テーブル
結果のマージ/集計
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_4
Candidate A_5
Periodic
process
Candidate A
Total: 2.5M
1. Sum
2. Store 投票者

パーティション数の計算(reads)
Items per partition
Average item size
RCU Size
Requests per second
100 K * 0.2 KB / 4 KB * 10 / 3000 =
Partition max RCU
~ 17

パーティション数の計算(writes)
Items per second
Average item size
100 K * (itemSize < 1KB ? 1KB : itemSize) / 1000 =
Partition max WCU
100

書き込みが偏るパーティションキーをシャーディング
• 同時アクセス数に応じてスループットを調整(増加)
• キー、Itemサイズ、リクエストレートごとのRCU/WCU を考慮
水平方向(均等)に書き込みワークロードがスケールできない場合に効果的

まとめ
• NoSQLはRDBとは全く特性が異なるので、それらを理解した上で適所
でうまく活用する！
• NoSQL, DynamoDB の特徴を理解した上でテーブルを設計する
 以下のドキュメントも参考に
https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/d
eveloperguide/best-practices.html
• 運用はゼロではないが、拡張性の面や性能面ではとても楽ができるの
がNoSQLの中でのDynamoDBの特徴
• 構築・運用にかかる時間を、本来のビジネス価値を高めることに投資
できる！

Amazon DynamoDB Advanced Design Pattern

More Related Content

Amazon DynamoDB Advanced Design Pattern