advertisement

AWS Webcast - Data Modeling and Best Practices for Scaling your Application with Amazon DynamoDB

56 %
44 %
advertisement
Information about AWS Webcast - Data Modeling and Best Practices for Scaling your...
Technology

Published on February 27, 2014

Author: AmazonWebServices

Source: slideshare.net

Description

Amazon DynamoDB is a fully managed, highly scalable distributed database service. In this technical talk, we will deep dive on how to:
• Use DynamoDB to build high-scale applications like social gaming, chat, and voting.
• Model these applications using DynamoDB, including how to use building blocks such as conditional writes, consistent reads, and batch operations to build the higher-level functionality such as multi-item atomic writes and join queries.
• Incorporate best practices such as index projections, item sharding, and parallel scan for maximum scalability
advertisement

Data Modeling and Best Practices in DynamoDB Peter-Mark Verwoerd Solutions Architect

Traditional Database Architecture Client Tier App/Web Tier RDBMS

One Database for All Workloads • • • • key-value access complex queries transactions analytics Client Tier App/Web Tier RDBMS

Cloud Data Tier Architecture Client Tier App/Web Tier Data Tier Search Cache Blob Store NoSQL RDBMS Data Warehouse

Workload Driven Data Store Selection rich search key/value simple query hot reads transaction processing logging Data Tier Search Cache Blob Store NoSQL RDBMS Data Warehouse analytics

AWS Services for the Data Tier rich search key/value simple query hot reads transaction processing logging Data Tier Amazon CloudSearch Amazon ElastiCache Amazon DynamoDB Amazon RDS Amazon S3 Amazon Redshift analytics

Plan • Basics – Basic Game State – Save Games – Social Gaming • Advanced – Social Gaming – Voting – Global Leaderboard

Plan • Basics – Basic Game State (conditional writes) – Save Games (hash + range) – Social Gaming (secondary indexes) • Advanced – Social Gaming (transactions) – Voting (write sharding) – Global Leaderboard (scatter-gather query)

Basic Game State conditional writes Basics

Tic Tac Toe Basics

Tic Tac Toe Alice Bob Your App DynamoDB Basics

Tic Tac Toe Table Game Table Id O State IsTie abecd [ Alice, Bob ] Alice DONE 1 fbdcc [ Alice, Bob ] Alice DONE dbace Basics Players [ Alice, Bob ] Alice STARTED Winner Data … Alice … …

Tic Tac Toe Table Game Table Id O State IsTie abecd [ Alice, Bob ] Alice DONE 1 fbdcc [ Alice, Bob ] Alice DONE dbace Basics Players [ Alice, Bob ] Alice STARTED Winner Data … Alice … …

Tic Tac Toe Table Id State IsTie [ Alice, Bob ] Alice DONE 1 fbdcc [ Alice, Bob ] Alice DONE dbace Basics O abecd Item Players [ Alice, Bob ] Alice STARTED Winner Data … Alice … …

Tic Tac Toe Table Id Players O State IsTie abecd [ Alice, Bob ] Alice DONE 1 fbdcc [ Alice, Bob ] Alice DONE dbace [ Alice, Bob ] Alice STARTED Data … Alice … … Attribute Basics Winner

Tic Tac Toe Table Primary Key Id O State IsTie abecd [ Alice, Bob ] Alice DONE 1 fbdcc [ Alice, Bob ] Alice DONE dbace Basics Players [ Alice, Bob ] Alice STARTED Winner Data … Alice … …

Tic Tac Toe Table Id Players O State IsTie abecd [ Alice, Bob ] Alice DONE 1 fbdcc [ Alice, Bob ] Alice DONE dbace [ Alice, Bob ] Alice STARTED Set Basics String Winner Data … Alice … … Number Binary

Tic Tac Toe Table { "Data" : [ [ "X", null, "O" ], [ null, "O", null], [ "O", null, "X" ] ] } Id O State IsTie abecd [ Alice, Bob ] Alice DONE 1 fbdcc [ Alice, Bob ] Alice DONE dbace Basics Players [ Alice, Bob ] Alice STARTED Winner Data … Alice … …

State Transitions with Conditional Writes Alice Bob DynamoDB Basics

State Transitions with Conditional Writes Alice Bob UpdateItem: Top-Right = O Turn = Bob DynamoDB Basics

State Transitions with Conditional Writes Alice Bob UpdateItem: Top-Left = X Turn = Alice DynamoDB Basics

State Transitions with Conditional Writes Alice Bob (1) DynamoDB Basics Bob (2) Bob (3)

State Transitions with Conditional Writes Alice Bob (1) DynamoDB Basics Bob (2) Bob (3)

State Transitions with Conditional Writes Alice Bob (1) DynamoDB Basics Bob (2) Bob (3)

State Transitions with Conditional Writes Bob (1) Bob (2) State : STARTED, Turn : Bob, Top-Right : O DynamoDB Basics Bob (3)

State Transitions with Conditional Writes Bob (1) Update: Turn : Alice Top-Left : X Bob (2) Bob (3) Update: Turn : Alice Low-Right : X State : STARTED, Turn : Bob, Top-Right : O DynamoDB Basics Update: Turn : Alice Mid : X

State Transitions with Conditional Writes Bob (1) Update: Turn : Alice Top-Left : X State : STARTED, Turn : Alice, Top-Right : O, Top-Left : X, Mid: X, Low-Right: X Basics Bob (2) Update: Turn : Alice Mid : X Bob (3) Update: Turn : Alice Low-Right : X DynamoDB

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

Conditional Writes UpdateItem Id=abecd Game Item { Id : abecd, Players : [ Alice, Bob ], State : STARTED, Turn : Bob, Top-Right: O } Basics Updates: { Turn : Alice, Top-Left: X } Expected: { Turn : Bob, Top-Left : null, State : STARTED }

State Transitions with Conditional Writes Bob (1) Update: Turn : Alice Top-Left : X Expect: Turn : Bob Top-Left : null State : STARTED, Turn : Bob, Top-Right : O Basics Bob (2) DynamoDB Update: Turn : Alice Mid : X Expect: Turn : Bob Mid : null Bob (3) Update: Turn : Alice Low-Right : X Expect: Turn : Bob Low-Right : null

State Transitions with Conditional Writes Bob (1) Update: Turn : Alice Top-Left : X Expect: Turn : Bob Top-Left : null State : STARTED, Turn : Bob, Top-Right : O Basics Bob (2) DynamoDB Update: Turn : Alice Mid : X Expect: Turn : Bob Mid : null Bob (3) Update: Turn : Alice Low-Right : X Expect: Turn : Bob Low-Right : null

State Transitions with Conditional Writes Bob (1) Update: Turn : Alice Top-Left : X Expect: Turn : Bob Top-Left : null State : STARTED, Turn : Alice, Top-Right : O, Top-Left : X Basics Bob (2) DynamoDB Update: Turn : Alice Mid : X Expect: Turn : Bob Mid : null Bob (3) Update: Turn : Alice Low-Right : X Expect: Turn : Bob Low-Right : null

Save Games hash + range Save Games

Save Games Save Games

Primary Key Schemas Hash Key Schema Primary Key Id Players O State IsTie abecd [ Alice, Bob ] Alice DONE 1 fbdcc [ Alice, Bob ] Alice DONE dbace [ Alice, Bob ] Alice STARTED Winner Data … Alice … …

Primary Key Schemas Hash and Range Key Schema Primary Key Id Turn Players Turn State abecd 0 [ Alice, Bob ] Alice STARTED … abecd 1 [ Alice, Bob ] Bob STARTED … abecd 2 [ Alice, Bob ] Alice STARTED … abecd 3 [ Alice, Bob ] Bob STARTED … abecd 4 [ Alice, Bob ] Alice DONE dbace 0 [ Alice, Bob ] Bob STARTED dbace 1 [ Alice, Bob ] Alice STARTED Save Games IsTie Winner Alice Data … …

Primary Key Schemas Primary Key Id Turn Players Turn State abecd 0 [ Alice, Bob ] Alice STARTED … abecd 1 [ Alice, Bob ] Bob STARTED … abecd 2 [ Alice, Bob ] Alice STARTED … abecd 3 [ Alice, Bob ] Bob STARTED … abecd 4 [ Alice, Bob ] Alice DONE dbace 0 [ Alice, Bob ] Bob STARTED dbace 1 [ Alice, Bob ] Alice STARTED Save Games IsTie Winner Alice Data … …

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 Query WHERE Id=abecd, ORDER BY Turn DESC, LIMIT 2 Primary Key Id Turn Players Turn State abecd 0 [ Alice, Bob ] Alice STARTED … abecd 1 [ Alice, Bob ] Bob STARTED … abecd 2 [ Alice, Bob ] Alice STARTED … abecd 3 [ Alice, Bob ] Bob STARTED … abecd 4 [ Alice, Bob ] Alice DONE dbace 0 [ Alice, Bob ] Bob STARTED dbace 1 [ Alice, Bob ] Alice STARTED Save Games IsTie Winner Alice Data … …

Social Gaming local 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 Hash: UserId Range: GameId Attributes: OpponentId, Date, (rest of game state) HostedGame Table 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 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 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 cost 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 (397 more games for Alice) Social Gaming (1 item = 600 bytes)

Query cost 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 (1 item = 600 bytes) (397 more games for Alice) (Items evaluated by Query) (KB per Read Capacity Unit) 400 X 600 / 1024 / 4 (bytes per item) Social Gaming (KB per byte) = 60 Read Capacity Units

Local Secondary Indexes • An alternate range key on a table HostedGame Table LocalSecondaryIndex on Date UserId GameId Date UserId Date GameId Carol e23f5a 2013-10-08 Carol 2013-10-08 e23f5a Alice d4e2dc 2013-10-01 Alice 2013-09-27 e9cba3 Alice e9cba3 2013-09-27 Alice 2013-10-01 d4e2dc Alice f6a3bd 2013-10-01 Alice 2013-10-01 f6a3bd Social Gaming

Query cost on Local Secondary Indexes UserId … Carol 2013-10-08 e23f5a … Alice (397 older games) 2013-09-27 e9cba3 … Alice 2013-10-01 d4e2dc … Alice Social Gaming GameId Alice Query for the 10 most recent games Date 2013-10-01 f6a3bd …

Query cost on Local Secondary Indexes UserId GameId … Carol 2013-10-08 e23f5a … Alice (397 older games) Alice 2013-09-27 e9cba3 … Alice 2013-10-01 d4e2dc … Alice Query for the 10 most recent games Date 2013-10-01 f6a3bd … (Items evaluated by Query) (KB per Read Capacity Unit) 10 X 600 / 1024 / 4 (bytes per item) Social Gaming (KB per byte) = 2 Read Capacity Units

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 Query WHERE UserId=Alice AND OpponentAndDate STARTS_WITH “Bob-” LIMIT 10 DESC Social Gaming

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) Query WHERE UserId=Alice LIMIT 10 DESC Social Gaming

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

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 Gaming transactions 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 Hash: UserId Range: FriendId Attributes: Status, Date, etc Friends Table 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

Becoming Friends: Multi-item Atomic Writes A friend request! UserId Status Bob FRIENDS Bob Alice FRIENDS Bob Chuck INCOMING Chuck Social Gaming FriendId Alice Bob Bob SENT

Becoming Friends: Multi-item Atomic Writes UserId Social Gaming Status Bob FRIENDS Bob 1. Update Bob/Chuck record 2. Update Chuck/Bob record FriendId Alice Bob Alice FRIENDS Bob Chuck INCOMING Chuck Bob SENT

Becoming Friends: Multi-item Atomic Writes UpdateItem Status=FRIENDS Social Gaming FriendId Status Bob FRIENDS Bob 1. Update Bob/Chuck record 2. Update Chuck/Bob record UserId Alice Bob Alice FRIENDS Bob Chuck FRIENDS Chuck Bob SENT

Becoming Friends: Multi-item Atomic Writes UpdateItem Status=FRIENDS Social Gaming FriendId Status Bob FRIENDS Bob 1. Update Bob/Chuck record 2. Update Chuck/Bob record UserId Alice Bob Alice FRIENDS Bob Chuck FRIENDS Chuck Bob FRIENDS

When things go wrong Social Gaming

Becoming Friends: When things go wrong A friend request! UserId Social Gaming Status Bob FRIENDS Bob 1. Update Bob/Chuck record 2. Update Chuck/Bob record FriendId Alice Bob Alice FRIENDS Bob Chuck INCOMING Chuck Bob SENT

Becoming Friends: When things go wrong UpdateItem Status=FRIENDS Social Gaming FriendId Status Bob FRIENDS Bob 1. Update Bob/Chuck record 2. Update Chuck/Bob record UserId Alice Bob Alice FRIENDS Bob Chuck FRIENDS Chuck Bob SENT

Becoming Friends: When things go wrong UpdateItem Status=FRIENDS Social Gaming FriendId Status Bob FRIENDS Bob 1. Update Bob/Chuck record 2. Update Chuck/Bob record UserId Alice Bob Alice FRIENDS Bob Chuck FRIENDS Chuck Bob SENT

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 SENT FRIENDS Bob/ Chuck SENDING Chuck/ Bob Social Gaming FRIENDS

Client Transactions Library Bob Transactions Table Social Gaming Transaction Client Transaction Images Table Friends Table

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 Transactions Table A friend request! Id Status V1 V2 Bob 1. 2. 3. 4. FriendId Status V Alice Bob FRIENDS 3 Bob Alice FRIENDS 3 Chuck INCOMING 2 Chuck Social Gaming UserId Bob Read items Write to Tx table Apply writes Delete from Tx table Bob SENT 2

Specialized Transactions Transactions Table Id V1 V2 BatchGetItem Bob 1. 2. 3. 4. Status FriendId Status V Alice Bob FRIENDS 3 Bob Alice FRIENDS 3 Chuck INCOMING 2 Chuck Social Gaming UserId Bob Read items Write to Tx table Apply writes Delete from Tx table Bob SENT 2

Specialized Transactions Transactions Table Id V1 V2 Bob-Chuck Bob: FRIENDS Chuck: FRIENDS 2 2 PutItem, Expect not exists Bob 1. 2. 3. 4. Status FriendId Status V Alice Bob FRIENDS 3 Bob Alice FRIENDS 3 Chuck INCOMING 2 Chuck Social Gaming UserId Bob Read items Write to Tx table Apply writes Delete from Tx table Bob SENT 2

Specialized Transactions Transactions Table Id V1 V2 Bob-Chuck Bob: FRIENDS Chuck: FRIENDS 2 2 UpdateItem, Expect V=Vprev Bob 1. 2. 3. 4. Status FriendId Status V Alice Bob FRIENDS 3 Bob Alice FRIENDS 3 Chuck FRIENDS 3 Chuck Social Gaming UserId Bob Read items Write to Tx table Apply writes Delete from Tx table Bob FRIENDS 3

Specialized Transactions Transactions Table Id DeleteItem, Expect V1=V1prev, V2=V2prev, Bob 1. 2. 3. 4. Status V1 V2 FriendId Status V Alice Bob FRIENDS 3 Bob Alice FRIENDS 3 Chuck FRIENDS 3 Chuck Social Gaming UserId Bob Read items Write to Tx table Apply writes Delete from Tx table Bob FRIENDS 3

When things go wrong Social Gaming

Specialized Transactions Transactions Table Id V1 V2 BatchGetItem Bob 1. 2. 3. 4. Status FriendId Status V Alice Bob FRIENDS 3 Bob Alice FRIENDS 3 Chuck INCOMING 2 Chuck Social Gaming UserId Bob Read items Write to Tx table Apply writes Delete from Tx table Bob SENT 2

Specialized Transactions Transactions Table Id V1 V2 Bob-Chuck Bob: FRIENDS Chuck: FRIENDS 2 2 PutItem, Expect not exists Bob 1. 2. 3. 4. Status FriendId Status V Alice Bob FRIENDS 3 Bob Alice FRIENDS 3 Chuck INCOMING 2 Chuck Social Gaming UserId Bob Read items Write to Tx table Apply writes Delete from Tx table Bob SENT 2

Specialized Transactions Transactions Table Id V1 V2 Bob-Chuck Bob: FRIENDS Chuck: FRIENDS 2 2 UpdateItem, Expect V=Vprev Bob 1. 2. 3. 4. Status FriendId Status V Alice Bob FRIENDS 3 Bob Alice FRIENDS 3 Chuck FRIENDS 3 Chuck Social Gaming UserId Bob Read items Write to Tx table Apply writes Delete from Tx table Bob SENT 2

Social Gaming

Specialized Transactions Transactions Table Id Status V1 V2 Bob-Chuck Bob: FRIENDS Chuck: FRIENDS 2 2 Scan Sweeper FriendId Status V Alice Bob FRIENDS 3 Bob Alice FRIENDS 3 Chuck FRIENDS 3 Chuck Social Gaming UserId Bob 1. Scan for stuck Tx 2. Apply writes 3. Delete from Tx table Bob SENT 2

Specialized Transactions Transactions Table Id Status V1 V2 Bob-Chuck Bob: FRIENDS Chuck: FRIENDS 2 2 UpdateItem, Expect V=Vprev Sweeper FriendId Status V Alice Bob FRIENDS 3 Bob Alice FRIENDS 3 Chuck FRIENDS 3 Chuck Social Gaming UserId Bob 1. Scan for stuck Tx 2. Apply writes 3. Delete from Tx table Bob FRIENDS 3

Specialized Transactions Transactions Table Id DeleteItem, Expect V1=V1prev, V2=V2prev, Sweeper Status V1 V2 FriendId Status V Alice Bob FRIENDS 3 Bob Alice FRIENDS 3 Chuck FRIENDS 3 Chuck Social Gaming UserId Bob 1. Scan for stuck Tx 2. Apply writes 3. Delete from Tx table Bob FRIENDS 3

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

High-Throughput Voting write sharding Voting

Voting Voter Candidate A Votes: 20 Candidate B Votes: 30 Votes Table Voting

Voting Voter UpdateItem ADD 1 to “Candidate A” (aka Atomic Increment) Candidate A Votes: 21 Candidate B Votes: 30 Votes Table Voting

Scaling on DynamoDB You Votes Table Voting Need to scale for the election

Scaling on DynamoDB You Provision 1200 Write Capacity Units Votes Table Voting

Scaling on DynamoDB You Provision 1200 Write Capacity Units Partition 1 Partition 2 600 Write Capacity Units (each) Votes Table Voting

Scaling on DynamoDB You Provision 1200 Write Capacity Units Partition 1 Partition 2 (no sharing) Votes Table Voting

Scaling on DynamoDB You Provision 200,000 Write Capacity Units Partition 1 (600 WCU) Partition K (600 WCU) Partition M (600 WCU) Votes Table Voting Partition N (600 WCU)

Scaling bottlenecks Voters Partition 1 (600 WCU) Partition K (600 WCU) Partition M (600 WCU) Candidate B Candidate A Votes Table Voting Partition N (600 WCU)

Scaling bottlenecks Voters Partition 1 (600 WCU) Partition K (600 WCU) Partition M (600 WCU) Candidate B Candidate A Votes Table Voting Partition N (600 WCU)

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 Voter Candidate A_1 Candidate A_4 Candidate A_7 Candidate B_5 Candidate B_1 Candidate A_5 Candidate A_2 Candidate B_8 Candidate B_4 Candidate B_3 Candidate B_7 Candidate A_3 Candidate A_6 Candidate A_8 Voting Votes Table Candidate B_2 Candidate B_6

Scaling on DynamoDB Voter UpdateItem: “CandidateA_” + rand(0, 10) ADD 1 to Votes Candidate A_1 Candidate A_4 Candidate A_7 Candidate B_5 Candidate B_1 Candidate A_5 Candidate A_2 Candidate B_8 Candidate B_4 Candidate B_3 Candidate B_7 Candidate A_3 Candidate A_6 Candidate A_8 Voting Votes Table Candidate B_2 Candidate B_6

Scaling on DynamoDB Periodic Process Voter 2. Store 1. Sum Candidate A_1 Candidate A_4 Candidate A_7 Candidate B_5 Candidate B_1 Candidate A_5 Candidate A_2 Candidate B_8 Candidate B_4 Candidate A Total: 2.5M Candidate B_3 Candidate B_7 Candidate A_3 Candidate A_6 Candidate A_8 Voting Votes Table Candidate B_2 Candidate B_6

Scaling Reads Voters Partition 1 (600 WCU) Partition K (600 WCU) Partition M (600 WCU) Candidate A_Total Votes: 2.5M Partition N (600 WCU) Candidate B_Total Votes: 2.1M Votes Table Voting

Scaling Reads Voters Partition 1 (600 WCU) Partition K (600 WCU) Partition M (600 WCU) Candidate A_Total Votes: 2.5M Partition N (600 WCU) Candidate B_Total Votes: 2.1M Votes Table Voting

Global Leaderboard scatter-gather Leaderboards

Game-Wide Leaderboard • Find the top 10 scores game-wide HighScore User 1000 Alice 850 Dave 580 Erin 470 Bob 30 Chuck Leaderboards

Game-Wide Leaderboard • Find the top 10 scores game-wide HighScore 1000 Table Schemas must begin with a Hash Key User Alice 850 Dave 580 Erin 470 Bob 30 Chuck Leaderboards

Game-Wide Leaderboard • Find the top 10 scores game-wide User Chuck Cannot be Queried the way we want HighScore 20 Alice 1000 Bob 470 Dave 850 Erin 580 Leaderboards

Game-Wide Leaderboard • Use a constant Hash key? Constant HighScore-User 1 0001000-Alice 1 0000850-Dave 1 0000580-Erin 1 0000470-Bob 1 0000030-Chuck Leaderboards Zero-pad strings for sort stability

Game-Wide Leaderboard • Use a constant Hash key? Constant 1 0001000-Alice 1 Extremely non-uniform workload HighScore-User 0000850-Dave 1 0000580-Erin 1 0000470-Bob 1 0000030-Chuck Leaderboards

Scatter-Gather Leading Range Key HighScores Table Shard Shard HighScore-User 2 0000600-Frank 5 0000999-Oscar 2 0000581-Trent 5 0000700-Craig 5 0000030-Chuck 0001000-Alice 1 0000980-Eve HighScore-User 1 HighScore-User 2 Shard 0000850-Dave 1 0000580-Erin Shard HighScore-User 3 0000900-Dan 3 0000850-Wendy 3 0000080-Trent Shard HighScore-User 4 0000500-Merlin 4 0000350-Carole 4 0000280-Paul Leaderboards

Scatter-Gather Leading Range Key 1. Periodically Query each Shard DESC, LIMIT N HighScores Table Shard Shard HighScore-User 2 0000600-Frank 5 0000999-Oscar 2 0000581-Trent 5 0000700-Craig 5 0000030-Chuck 0001000-Alice 1 0000980-Eve HighScore-User 1 HighScore-User 2 Shard 0000850-Dave 1 0000580-Erin Shard HighScore-User 3 0000900-Dan 3 0000850-Wendy 3 0000080-Trent Shard HighScore-User 4 0000500-Merlin 4 0000350-Carole 4 0000280-Paul Leaderboards

Scatter-Gather Leading Range Key HighScore 1000 Alice 999 2. Keep only the top N, Store somewhere User Oscar HighScores Table Shard Shard HighScore-User 2 0000600-Frank 5 0000999-Oscar 2 0000581-Trent 5 0000700-Craig 5 0000030-Chuck 0001000-Alice 1 0000980-Eve HighScore-User 1 HighScore-User 2 Shard 0000850-Dave 1 0000580-Erin Shard HighScore-User 3 0000900-Dan 3 0000850-Wendy 3 0000080-Trent Shard HighScore-User 4 0000500-Merlin 4 0000350-Carole 4 0000280-Paul Leaderboards

Scatter-Gather Leading Range Key User Alice 5 Carole HighScores Table 1 Oscar Store the Shard id by User for high score updates Shard 4 Shard Shard HighScore-User 2 0000600-Frank 5 0000999-Oscar 2 0000581-Trent 5 0000700-Craig 5 0000030-Chuck 0001000-Alice 1 0000980-Eve HighScore-User 1 HighScore-User 2 Shard 0000850-Dave 1 0000580-Erin Shard HighScore-User 3 0000900-Dan 3 0000850-Wendy 3 0000080-Trent Shard HighScore-User 4 0000500-Merlin 4 0000350-Carole 4 0000280-Paul 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) – Global Leaderboard (scatter-gather query)

Thanks! aws.amazon.com/dynamodb/resources

Add a comment

Related presentations

Presentación que realice en el Evento Nacional de Gobierno Abierto, realizado los ...

In this presentation we will describe our experience developing with a highly dyna...

Presentation to the LITA Forum 7th November 2014 Albuquerque, NM

Un recorrido por los cambios que nos generará el wearabletech en el futuro

Um paralelo entre as novidades & mercado em Wearable Computing e Tecnologias Assis...

Microsoft finally joins the smartwatch and fitness tracker game by introducing the...

Related pages

AWS Webcast - Data Modeling and Best Practices for Scaling ...

... Data Modeling and Best Practices for Scaling your Application ... best practices such as index ... Amazon DynamoDB: Data Modeling and ...
Read more

AWS re:Invent 2014 | (SDD407) Amazon DynamoDB: Data ...

... Data Modeling and Scaling Best Practices ... for Scaling your Application with Amazon DynamoDB ... AWS Webcast - Data Modeling for ...
Read more

AWS Webcast - Data Modeling and Best Practices for Scaling ...

AWS Webcast - Data Modeling and Best Practices for Scaling your Application with Amazon DynamoDB Jan 26, 2015 Technology amazon-web-services
Read more

AWS Webcast - Amazon RDS for Oracle: Best Practices and ...

AWS Webcast - Amazon Redshift Best Practices for Data ... AWS Webcast - Data Modeling and Best Practices for Scaling your Application with Amazon DynamoDB.
Read more

AWS Webinars | LA Online School

AWS Webcast - Data Modeling for low cost and high ... AWS Webcast - Scaling on AWS for the ... AWS Webcast - Amazon Redshift Best Practices for Data ...
Read more

Webcast best practices sankar venkatraman - Documents

Talent Solutions7 Best Practices for an Engaging and Productive Webinar/Webcast Sankar ... and be very clear on what your webcast is ... data and humor ...
Read more

AWS Webcast - AWS Kinesis Webinar - slidesearch.net

AWS Webcast - AWS Kinesis Webinar - slidesearch.net
Read more

AWS Partner Webcast - Reporting and Analytics in the Cloud

Do you need to make sense of increasing volumes of data coming from a variety of sources like web logs, sensor data, social media monitoring and mobile ...
Read more