Data Modeling and Best Practices on Amazon DynamoDB

Basics Save Games Social Gaming Replication Voting Leaderboards

Data Modeling and Best Practices on Amazon DynamoDBDavid Yanacek, Sr. Software Development Engineer,Amazon DynamoDB


Plan

• Basics– Basic Game State– Save Games– Social Gaming

• Advanced– Social Gaming– Replication– Voting– Social Leaderboard– Global Leaderboard


Plan

• Basics– Basic Game State (conditional writes)– Save Games (hash + range)– Social Gaming (secondary indexes)

• Advanced– Social Gaming (transactions)– Replication (cross-region, cross-data-store)– Voting (write sharding)– Social Leaderboard (hash + range, complex transactions)– Global Leaderboard (scatter-gather query)


Basic Game Stateconditional writes

Basics


Tic Tac Toe

Basics


Tic Tac Toe

Alice Bob

DynamoDB

Your App

Basics


Tic Tac Toe Table

Game Table

Id Players O State IsTie Winner Data

abecd [ Alice, Bob ] Alice DONE 1 …

fbdcc [ Alice, Bob ] Alice DONE Alice …

dbace [ Alice, Bob ] Alice STARTED …

Basics


Tic Tac Toe Table

Game Table





Basics






Tic Tac Toe Table

Item

Basics






Tic Tac Toe Table

Attribute

Basics






Tic Tac Toe Table

Primary Key

Basics






Tic Tac Toe Table

Set String Number Binary

Basics


Tic Tac Toe Table{ "Data" : [ [ "X", null, "O" ], [ null, "O", null], [ "O", null, "X" ] ] }





Basics


State Transitions with Conditional Writes

{ "Id" : "abecd", "Players" : [ "Alice", "Bob" ], "State" : "STARTED", "Turn" : "Bob", "Top-Right" : "O"}

Basics



DynamoDB

Alice Bob

Basics



DynamoDB

UpdateItem:Top-Right = OTurn = Bob

Alice Bob

Basics



DynamoDB

UpdateItem:Top-Left = XTurn = Alice

Alice Bob

Basics



Alice Bob (1)

DynamoDB

Bob (2) Bob (3)

Basics



Alice Bob (1)

DynamoDB

Bob (2) Bob (3)

Basics



Alice Bob (1)

DynamoDB

Bob (2) Bob (3)

Basics



Bob (1)

DynamoDB

Bob (2)Bob (3)

State : STARTED,Turn : Bob,Top-Right : O

Basics



Bob (1)

DynamoDB

Bob (2)Bob (3)

Update: Turn : Alice Top-Left : X

Update: Turn : Alice Low-Right : X

Update: Turn : Alice Mid : X

State : STARTED,Turn : Bob,Top-Right : O

Basics



Bob (1)

DynamoDB

Bob (2)Bob (3)

Update: Turn : Alice Top-Left : X

Update: Turn : Alice Low-Right : X

Update: Turn : Alice Mid : X

State : STARTED,Turn : Alice,Top-Right : O,Top-Left : X,Mid: X,Low-Right: X

Basics


Conditional Writes

• Apply an update only if values are as expected • Otherwise reject the write

Basics


Conditional Writes

{ Id : abecd, Players : [ Alice, Bob ], State : STARTED, Turn : Bob, Top-Right: O}

Game Item Updates: { Turn : Alice, Top-Left: X}

Expected: { Turn : Bob, Top-Left : null, State : STARTED}

UpdateItem Id=abecd

Basics



Bob (1)

DynamoDB

Bob (2)Bob (3)

Update: Turn : Alice Top-Left : XExpect: Turn : Bob Top-Left : null

State : STARTED, Turn : Bob, Top-Right : O

Update: Turn : Alice Low-Right : XExpect: Turn : Bob Low-Right : null

Update: Turn : Alice Mid : XExpect: Turn : Bob Mid : null

Basics



Bob (1)

DynamoDB

Bob (2)Bob (3)

State : STARTED, Turn : Bob, Top-Right : O




Basics



Bob (1)

DynamoDB

Bob (2)Bob (3)

State : STARTED, Turn : Alice, Top-Right : O, Top-Left : X




Basics


Alternative: Read / Modify / Write

{ Id : abecd, Players : [ Alice, Bob ], State : STARTED, Turn : Bob, Top-Right: O, Version : 2}

Basics


Pattern: Read / Modify / Write

1. Read item, remember Version (Vo)2. Validate state transition3. Construct new Item, with Version = V1

4. Replace item– Expected: Version = Vo

5. If ConditionalCheckFailed, go to 1

Basics


Read / Modify / Write Example

Basics

Quality: Bad

Quality: Good

Value: ?

Value >= 0?

Value < 0


Read / Modify / Write

Client 1

Client 2 Time

Basics

Version: 1Value: 15



Client 1

Client 2 Time

Read

Read

Basics

Version: 1Value: 15

Version: 1Value: 15

Version: 1Value: 15



Client 1

Client 2 Time

Read

Read

Basics

Version: 1Value: 15

Version: 2Value: 15

Quality: Good

Version: 1Value: 15

Version: 2Value: 15

Quality: Good

Version: 1Value: 15



Client 1

Client 2 Time

ReadPut

If V=1

ReadPut

If V=1

Basics

Version: 1Value: 15

Version: 2Value: 15

Quality: Good

Version: 1Value: 15

Version: 2Value: 15

Quality: Good

Version: 2Value: 15

Quality: Good

Version: 1Value: 15


Read / Modify / Write with Deletes

Client 1

Client 2 Time

Basics

Version: 1Value: 15



Client 1

Client 2 Time

Read

UpdateQuality=Good

If V=1

Read

Basics

Version: 2Value: 15

Quality: Good

Version: 1Value: 15



(Deleted)

Client 1

Client 2 Time

Read

UpdateQuality=Good

If V=1 Read DeleteIf V=2

Read

Basics

Version: 2Value: 15

Quality: Good

Version: 1Value: 15



(Deleted)

Client 1

Client 2 Time

Read

UpdateQuality=Good

If V=1 Read DeleteIf V=2 Read

PutIf Not Exists

Read

Basics

Version: 2Value: 15

Quality: Good

Version: 1Value: -20

Version: 1Value: 15



(Deleted)

Client 1

Client 2 Time

Read

UpdateQuality=Good


PutIf Not Exists

Read

Version: 1Value: 15

Basics

Version: 2Value: 15

Quality: Good


Version: 1Value: 15



(Deleted)

Client 1

Client 2 Time

Read

UpdateQuality=Good


PutIf Not Exists

Read

Version: 1Value: 15

Version: 2Value: 15

Quality: Good

Basics

Version: 2Value: 15

Quality: Good


Version: 1Value: 15



(Deleted)

Version: 2Value: 15

Quality: Good


Version: 2Value: 15

Quality: Good

Client 1

Client 2 Time

Read

UpdateQuality=Good


PutIf Not Exists

Read PutIf V=1

Version: 1Value: 15

Version: 2Value: 15

Quality: Good

Basics

Version: 1Value: 15



• Version can be numeric or GUID– Version: 1– Version: 550e8400-e29b-41d4-a716-446655440000

• If Numeric, choose random seed or introduce an “epoch” GUID– Version: 1– Epoch: 550e8400-e29b-41d4-a716-446655440000

Basics


Read / Modify / Write with Epoch

(Deleted)

Client 1

Client 2 Time

ReadPut Quality=Good

If V=1, Epoch=ab4f ReadDelete if V=2,Epoch=ab4f Read

Put Epoch=39daIf Not Exists

Read PutIf V=1, Epoch=ab4f

Basics

Version: 1Value: 15

Epoch: ab4f

Version: 2Value: 15

Quality: GoodEpoch: ab4f

Version: 2Value: 15

Quality: GoodEpoch: ab4f


Epoch: 39da

Version: 1Value: 15

Epoch: ab4f


Save Gameshash + range

Save Games


Save Games

Save Games


Primary Key Schemas





Primary Key

Hash Key Schema


Primary Key Schemas

Id Turn Players Turn State IsTie Winner Data

abecd 0 [ Alice, Bob ] Alice STARTED …

abecd 1 [ Alice, Bob ] Bob STARTED …



abecd 4 [ Alice, Bob ] Alice DONE Alice …

dbace 0 [ Alice, Bob ] Bob STARTED

dbace 1 [ Alice, Bob ] Alice STARTED …

Primary Key

Hash and Range Key Schema

Save Games


Primary Key Schemas









Primary Key

Save Games


Primary Key Schemas

• Hash-only– Key/value lookups only

• Hash and Range– Given a hash key value, query for items by range key– Items are sorted by range key within each hash key

Save Games


Primary Key Schemas









Primary Key

Query WHERE Id=abecd, ORDER BY Turn DESC, LIMIT 2

Save Games


Social Gaminglocal secondary indexes

Social Gaming


Social Gaming

• Host games• Invite friends to play• Find friends’ games to play• See history of games

Social Gaming


Social Gaming

HostedGame Table

Hash: UserIdRange: GameIdAttributes: OpponentId, Date, (rest of game state)

UserId GameId Date OpponentId …Carol e23f5a 2013-10-08 Charlie …

Alice d4e2dc 2013-10-01 Bob …

Alice e9cba3 2013-09-27 Bob …

Alice f6a3bd 2013-10-08

Social Gaming


Social Gaming

• Host games• Invite friends to play• Find friends’ games to play• See history of games

Social Gaming


Social Gaming: find recent games




Alice f6a3bd 2013-10-08

Query UserId=Alice

Social Gaming


Query cost

• Provisioned Throughput: Work / sec allowed on your table

• Capacity Units: Amount of provisioned throughput consumed by an operation

Social Gaming


Query costUserId GameId Date OpponentId …Carol e23f5a 2013-10-08 Charlie …



Alice f6a3bd 2013-10-08

(1 item = 600 bytes)

(397 more games for Alice)

Social Gaming


Query costUserId GameId Date OpponentId …Carol e23f5a 2013-10-08 Charlie …



Alice f6a3bd 2013-10-08

(1 item = 600 bytes)

(397 more games for Alice)

400 X 600 / 1024 / 4 = 60 Read Capacity Units

(bytes per item) (KB per byte)

(KB per Read Capacity Unit)(Items evaluated by Query)

Social Gaming


Local Secondary Indexes

• An alternate range key on a table

UserId GameId DateCarol e23f5a 2013-10-08

Alice d4e2dc 2013-10-01

Alice e9cba3 2013-09-27

Alice f6a3bd 2013-10-01

UserId Date GameIdCarol 2013-10-08 e23f5a

Alice 2013-09-27 e9cba3

Alice 2013-10-01 d4e2dc

Alice 2013-10-01 f6a3bd

HostedGame Table LocalSecondaryIndex on Date

Social Gaming


Query cost on Local Secondary Indexes

UserId Date GameId …Carol 2013-10-08 e23f5a …

Alice (397 older games)

Alice 2013-09-27 e9cba3 …

Alice 2013-10-01 d4e2dc …

Alice 2013-10-01 f6a3bd …

Query for the 10 most recent games

Social Gaming


Query cost on Local Secondary Indexes

UserId Date GameId …Carol 2013-10-08 e23f5a …

Alice (397 older games)

Alice 2013-09-27 e9cba3 …

Alice 2013-10-01 d4e2dc …

Alice 2013-10-01 f6a3bd …

10 X 600 / 1024 / 4 = 2 Read Capacity Units

(bytes per item) (KB per byte)

(KB per Read Capacity Unit)(Items evaluated by Query)

Query for the 10 most recent games

Social Gaming


Example Local Secondary Indexes

• Find 10 recent matches between Alice and Bob

Social Gaming


Example Local Secondary Indexes

• Find 10 recent matches between Alice and Bob– Hash: UserId– Range: OpponentId + Date

Social Gaming

Query WHERE UserId=Alice AND OpponentAndDate STARTS_WITH “Bob-” LIMIT 10 DESC


More example Local Secondary Indexes

• Find a host’s matches without an opponent

Social Gaming


More example Local Secondary Indexes

• Find a host’s matches without an opponent– Hash: UserId– Range: UnmatchedDate

(sparse index)

Social Gaming

Query WHERE UserId=Alice LIMIT 10 DESC


Local Secondary Index Projections

• Choose what attributes are copied into the index– ALL, SPECIFIC, KEYS

• Substantially cheaper to Query only projection• Project the attributes that your use case requires• Can make writes cheaper too

Social Gaming


Write cost for Local Secondary Index

• Insert new item– 1 additional write

• Setting index range key to / from null– 1 additional write

• Updating a projected attribute– 1 additional write

• Updating a non-projected attribute– 0 additional writes

• Updating the index range key– 2 additional writes

Social Gaming


Read cost for Query of non-projected attributes

• Regular Query cost+

• Single-item Get cost for each evaluated item

Social Gaming


Example Local Secondary Index Projections

• Query Alice’s 10 most recent Games

Social Gaming




Alice f6a3bd 2013-10-08


Example Local Secondary Index Projections

• Query Alice’s 10 most recent Games– Opponent, Winner, (UserId, GameId, Date)– Projected item size from 600 bytes to 40 bytes

• Write cost:– 1 Write Capacity Unit for insert, opponent joining, and

completion– 0 Write Capacity Units for other state transitions

Social Gaming


Social Gamingtransactions

Social Gaming


Social Gaming: Friends

• Query who you are friends with• Ask to be friends with someone• Acknowledge (or decline) friend request

Social Gaming


Social Gaming: Friends

FriendsTable

Hash: UserIdRange: FriendIdAttributes: Status, Date, etc

UserId FriendId Status Date …Alice Bob FRIENDS 2013-08-20 …

Bob Alice FRIENDS 2013-08-20 …

Bob Chuck INCOMING 2013-10-08 …

Chuck Bob SENT 2013-10-08 …

Social Gaming


Friends: Local Secondary Index Possibilities

• Query for unacknowledged friend requests– Hash: UserId– Range: RequestDate + FriendId

Social Gaming

(set to null once friends)


Becoming Friends: Multi-item Atomic Writes

UserId FriendId StatusAlice Bob FRIENDS

Bob Alice FRIENDS

Bob Chuck INCOMING

Chuck Bob SENT

Bob

A friend request!

Social Gaming




Bob Alice FRIENDS

Bob Chuck INCOMING

Chuck Bob SENT

Bob

1. Update Bob/Chuck record2. Update Chuck/Bob record

Social Gaming




Bob Alice FRIENDS

Bob Chuck FRIENDS

Chuck Bob SENT

Bob

UpdateItemStatus=FRIENDS


Social Gaming




Bob Alice FRIENDS

Bob Chuck FRIENDS

Chuck Bob FRIENDS

Bob



Social Gaming


When things go wrong

Social Gaming


Becoming Friends: When things go wrong


Bob Alice FRIENDS

Bob Chuck INCOMING

Chuck Bob SENT

Bob

A friend request!


Social Gaming




Bob Alice FRIENDS

Bob Chuck FRIENDS

Chuck Bob SENT

Bob



Social Gaming




Bob Alice FRIENDS

Bob Chuck FRIENDS

Chuck Bob SENT

Bob



Social Gaming


Multi-item transaction in DynamoDB

• Scan for “stuck” transactions• Use the Client Transactions Library on the AWS

SDK for Java• Roll your own scheme

Social Gaming


Replayable state machines

INCOMING ACCEPTING FRIENDS

SENT FRIENDSSENDING

Bob/Chuck

Chuck/Bob

Social Gaming


Client Transactions Library

PutItemRequest acceptBob; PutItemRequest acknowledgeChuck;

Transaction t = txManager.newTransaction();

t.putItem(acceptBob);t.putItem(acknowledgeChuck);

t.commit();

Social Gaming


Client Transactions Library

Friends TableTransactions Table

Transaction ImagesTable

TransactionClient

Bob

Social Gaming


Client Transactions Usage

• Low contention only• Don’t mix Tx Client writes with normal writes• No Query support• Expensive, slower• But, easy to use

Social Gaming


Specialized Transactions

• Keep an “in-flight transactions” table• Transaction item primary key locks its items• Write all transaction data to that table• Then apply writes to the actual items• Use Version numbers to ensure consistency

Social Gaming



UserId FriendId Status VAlice Bob FRIENDS 3

Bob Alice FRIENDS 3

Bob Chuck INCOMING 2

Chuck Bob SENT 2

Id Status V1 V2

Bob

1. Read items2. Write to Tx table3. Apply writes4. Delete from Tx table

Transactions Table

Social Gaming

A friend request!




Bob Alice FRIENDS 3


Chuck Bob SENT 2

Id Status V1 V2

Bob BatchGetItem


Transactions Table

Social Gaming




Bob Alice FRIENDS 3


Chuck Bob SENT 2

Id Status V1 V2Bob-Chuck Bob: FRIENDS

Chuck: FRIENDS2 2

Bob PutItem,Expect not exists


Transactions Table

Social Gaming




Bob Alice FRIENDS 3

Bob Chuck FRIENDS 3

Chuck Bob FRIENDS 3


Chuck: FRIENDS2 2

Bob UpdateItem,Expect V=Vprev


Transactions Table

Social Gaming




Bob Alice FRIENDS 3

Bob Chuck FRIENDS 3

Chuck Bob FRIENDS 3

Id Status V1 V2

Bob DeleteItem,Expect V1=V1prev,

V2=V2prev,1. Read items2. Write to Tx table3. Apply writes4. Delete from Tx table

Transactions Table

Social Gaming


When things go wrong

Social Gaming




Bob Alice FRIENDS 3


Chuck Bob SENT 2

Id Status V1 V2

Bob BatchGetItem


Transactions Table

Social Gaming




Bob Alice FRIENDS 3


Chuck Bob SENT 2


Chuck: FRIENDS2 2

Bob PutItem,Expect not exists


Transactions Table

Social Gaming




Bob Alice FRIENDS 3

Bob Chuck FRIENDS 3

Chuck Bob SENT 2


Chuck: FRIENDS2 2

Bob UpdateItem,Expect V=Vprev


Transactions Table

Social Gaming

Basics Save Games Social Gaming Replication Voting LeaderboardsSocial Gaming




Bob Alice FRIENDS 3

Bob Chuck FRIENDS 3

Chuck Bob SENT 2


Chuck: FRIENDS2 2

Sweeper Scan

1. Scan for stuck Tx2. Apply writes3. Delete from Tx table

Transactions Table

Social Gaming




Bob Alice FRIENDS 3

Bob Chuck FRIENDS 3

Chuck Bob FRIENDS 3


Chuck: FRIENDS2 2

UpdateItem,Expect V=Vprev

Transactions Table

Sweeper


Social Gaming




Bob Alice FRIENDS 3

Bob Chuck FRIENDS 3

Chuck Bob FRIENDS 3

Id Status V1 V2

DeleteItem,Expect V1=V1prev,

V2=V2prev,

Transactions Table

Sweeper


Social Gaming


Transaction advice

• Lock items before modifying– Including items that don’t exist yet

• Don’t stomp on future writes (use versions)• Sweep for stuck transactions• Avoid deadlock

Social Gaming


Replicationcross-region, cross-data-store

Replication


Motivation for cross-region replication

• Get data close to the user• Keep up-to-date backups• Regional isolation• Replicate to other data stores

Replication


Cross-region replication

us-west-2 region

FriendsMaster Table

App Instance

Replication

Friends Replica Table

ap-southeast-1 region


ap-northeast-1 region



us-west-2 region

FriendsMaster Table

App Instance

Replication







us-west-2 region

FriendsMaster Table

App Instance

Replication







us-west-2 region

FriendsMaster Table

Transactions Table

App Instance

Replication

ReplicationQueues







us-west-2 region

FriendsMaster Table

Transactions Table

App Instance

Replication Receiver Instance

Replication

ReplicationQueues







Corporate Data center

On-Premise Database

Cross-data store replication

us-west-2 region

FriendsMaster Table

Transactions Table

App Instance

Replication

ReplicationQueues



MySQL DB Instance

Traditional Server


Replication to other data stores

• On-premise datacenter• Other data store technology (relational db)• Populate search indexes• Archival / cold storage• Feed to analytics engine• Cache invalidation

Replication


Replication best practices

• Isolate failure with SQS Queues• Schema must handle out of order updates• Must have transactional guarantee around

replication

Replication


High-Throughput Votingwrite sharding

Voting


Voting

Votes Table

Voter

Candidate AVotes: 20

Candidate BVotes: 30

Voting


Voting

Votes Table

Voter

Candidate AVotes: 21

Candidate BVotes: 30

UpdateItemADD 1 to “Candidate A”(aka Atomic Increment)

Voting


Scaling on DynamoDB

Votes Table

YouNeed to scale for the election

Voting


Scaling on DynamoDB

Votes Table

You

Provision 1200 Write Capacity Units

Voting


Scaling on DynamoDB

Votes Table

Partition 1 Partition 2

You

600 Write Capacity Units (each)


Voting


Scaling on DynamoDB

Votes Table

Partition 1 Partition 2

You

(no sharing)


Voting


Scaling on DynamoDB

Votes Table

You

Provision 200,000 Write Capacity Units

Partition 1(600 WCU)

Partition K(600 WCU)

Partition M(600 WCU)

Partition N(600 WCU)

Voting


Scaling bottlenecks

Votes Table


Candidate A




Candidate B

Voters

Voting


Scaling bottlenecks

Votes Table


Candidate A




Candidate B

Voters

50,000 / sec

70,000 / sec

Voting


Best Practice: Uniform Workloads

“To achieve the full amount of request throughput you have provisioned for a table, keep your workload spread evenly across the hash key values.”

– DynamoDB Developer Guide

Voting


Scaling on DynamoDB

Votes 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

Voter

Candidate A_6 Candidate A_8

Candidate A_5

Voting


Scaling on DynamoDB

Votes 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

Voter

UpdateItem: “CandidateA_” + rand(0, 10)ADD 1 to Votes


Candidate A_5

Voting


Scaling on DynamoDB

Votes 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_4

Candidate A_5


Candidate A_7 Candidate B_8

Periodic Process

Candidate ATotal: 2.5M

1. Sum2. Store Voter

Voting


Scaling Reads

Votes Table


Candidate A_TotalVotes: 2.5M




50,000 reads / sec

70,00

0 rea

ds / s

ec

Candidate B_TotalVotes: 2.1M

Voters

Voting


Scaling Reads

Votes Table


Candidate A_TotalVotes: 2.5M




100 reads / sec

100 r

eads /

sec

Candidate B_TotalVotes: 2.1M

Voters

Voting


Requirements for Voting

• Allow each person to vote only once• No changing votes• Real-time aggregation (approximate)• End-of-election perfect count• Voter statistics, demographics


Correctness in Voting

UserId Candidate DateAlice A 2013-10-02

Bob B 2013-10-02

Eve B 2013-10-02

Chuck A 2013-10-02

RawVotes Table

Segment VotesA_1 23

B_2 12

B_1 14

A_2 25

AggregateVotes Table

Voter

1. Record vote and dedupe, retry 2. Increment candidate counter


Aggregating Votes Architecture

Voters

RawVotes Table

AggregateVotesTable

Voting App

Amazon Redshift

Amazon EMR


Social Leaderboardhash + range, transactions

Leaderboards


Friends Leaderboard

• Find friends playing the same game• See where you stack up against your friends

Leaderboards


Friends Leaderboard

User HighScoreChuck 20

Alice 1000

Bob 470

Dave 850

Erin 580

Friends Table HighScores Table

User FriendBob Alice

Bob Chuck

Alice Bob

Alice Chuck

Alice Erin

Leaderboards


Friends Leaderboard


Alice 1000

Bob 470

Dave 850

Erin 580



Bob Chuck

Alice Bob

Alice Chuck

Alice Erin

Alice

Leaderboards


Friends Leaderboard


Alice 1000

Bob 470

Dave 850

Erin 580



Bob Chuck

Alice Bob

Alice Chuck

Alice Erin

1. Query 2. BatchGetItemAlice

Leaderboards


Inefficiencies in friends leaderboard

• Always retrieve all friends– Some friends don’t play– Might care about top 10 scores only

• Single-item operations for each friend– Query charges 1 RCU per 4 KB of data– GetItem rounds up each item to nearest 1 RCU

Leaderboards


Improved Friends Leaderboard: Reads

User Friend H.S.Bob Alice 1000

Bob Chuck 20

Alice Bob 470

Alice Chuck 20

Alice Erin 580


Alice 1000

Bob 470

Dave 850

Erin 580Table

FriendScores Table HighScores Table

Leaderboards




Bob Chuck 20

Alice Bob 470

Alice Chuck 20

Alice Erin 580


Alice 1000

Bob 470

Dave 850

Erin 580

User H.S. FriendBob 20 Chuck

Bob 1000 Alice

Alice 20 Chuck

Alice 470 Bob

Alice 580 ErinTable Local Secondary Index


Leaderboards




Bob Chuck 20

Alice Bob 470

Alice Chuck 20

Alice Erin 580


Alice 1000

Bob 470

Dave 850

Erin 580

User H.S. FriendBob 20 Chuck

Bob 1000 Alice

Alice 20 Chuck

Alice 470 Bob

Alice 580 ErinTable Local Secondary Index


Query FROM FriendScores-IndexWHERE User=Alice, DESC, LIMIT 10Alice

Leaderboards



Alice 1000

Bob 470

Dave 850

Erin 580

Improved Friends Leaderboard: Writes


Bob Chuck 30

Alice Bob 470

Alice Chuck 30

Alice Erin 580


Chuck 1. UpdateItem

2. UpdateItem(s)

Leaderboards


Complicating writes

• Updating your high score requires 1 write per friend

• Friends can be added while updating your high score

Leaderboards


Complicating writes

• AddFriend needs to detect when new high scores are updated concurrently

• ReportHighScore needs to detect when new friendships added concurrently

Leaderboards


Global Leaderboardscatter-gather

Leaderboards


Game-Wide Leaderboard

• Find the top 10 scores game-wideHighScore User1000 Alice

850 Dave

580 Erin

470 Bob

30 Chuck

Leaderboards



• Find the top 10 scores game-wideHighScore User1000 Alice

850 Dave

580 Erin

470 Bob

30 Chuck

Table Schemas must beginwith a Hash Key

Leaderboards



• Find the top 10 scores game-wide

Cannot be Queriedthe way we want


Alice 1000

Bob 470

Dave 850

Erin 580

Leaderboards



• Use a constant Hash key?Constant HighScore-User1 0001000-Alice

1 0000850-Dave

1 0000580-Erin

1 0000470-Bob

1 0000030-ChuckZero-pad strings for sortstability

Leaderboards



• Use a constant Hash key?Constant HighScore-User1 0001000-Alice

1 0000850-Dave

1 0000580-Erin

1 0000470-Bob

1 0000030-Chuck

Extremely non-uniform workload

Leaderboards


Scatter-Gather Leading Range Key

HighScores Table

Shard HighScore-User

1 0001000-Alice

1 0000850-Dave

1 0000580-Erin


3 0000900-Dan

3 0000850-Wendy

3 0000080-Trent


2 0000980-Eve

2 0000600-Frank

2 0000581-Trent


4 0000500-Merlin

4 0000350-Carole

4 0000280-Paul


5 0000999-Oscar

5 0000700-Craig

5 0000030-Chuck

Leaderboards



HighScores Table


1 0001000-Alice

1 0000850-Dave

1 0000580-Erin


3 0000900-Dan

3 0000850-Wendy

3 0000080-Trent


2 0000980-Eve

2 0000600-Frank

2 0000581-Trent


4 0000500-Merlin

4 0000350-Carole

4 0000280-Paul


5 0000999-Oscar

5 0000700-Craig

5 0000030-Chuck

1. Periodically Query each Shard DESC, LIMIT N

Leaderboards



HighScores Table


1 0001000-Alice

1 0000850-Dave

1 0000580-Erin


3 0000900-Dan

3 0000850-Wendy

3 0000080-Trent


2 0000980-Eve

2 0000600-Frank

2 0000581-Trent


4 0000500-Merlin

4 0000350-Carole

4 0000280-Paul


5 0000999-Oscar

5 0000700-Craig

5 0000030-Chuck

2. Keep only the top N, Store somewhere

HighScore User

1000 Alice

999 Oscar

Leaderboards



HighScores Table


1 0001000-Alice

1 0000850-Dave

1 0000580-Erin


3 0000900-Dan

3 0000850-Wendy

3 0000080-Trent


2 0000980-Eve

2 0000600-Frank

2 0000581-Trent


4 0000500-Merlin

4 0000350-Carole

4 0000280-Paul


5 0000999-Oscar

5 0000700-Craig

5 0000030-Chuck

Store the Shard id by User for high score updatesUser Shard

Alice 1

Oscar 5

Carole 4

Leaderboards


Recap

• Basics– Basic Game State (conditional writes)– Save Games (hash + range)– Social Gaming (secondary indexes)

• Advanced– Social Gaming (transactions)– Replication (cross-region, cross-data-store)– Voting (write sharding)– Social Leaderboard (hash + range, complex transactions)– Global Leaderboard (scatter-gather query)


Thanks!

aws.amazon.com/dynamodb/resources

Documents

Data Modeling and Best Practices on Amazon DynamoDB