Skip to content
Hallway
0:00 / 0:00

#dynamodb#single-tabledesign#aws

AWS re:Invent 2020: Data modeling with Amazon DynamoDB – Part 2

AWS Events

185K subscribers • 7 videos on Hallway

YouTube
  • Recommended by 1 person: 1 on Stack Overflow and its sister sites.
  • Presented by Alex DeBrie, author of The DynamoDB Book
  • Made by the vendor. The company whose product it covers made or sponsored it.

Intermediate. Assumes working knowledge.

27K views5 years ago1 recommendation

Databases and dataSoftware designNoSQL and document databasesDatabase internalsSoftware architecture

Alex DeBrie explains advanced data modeling strategies for handling complex, highly relational data models in Amazon DynamoDB.

Amazon DynamoDB is popular due to its flexible billing model and ability to scale without performance degradation. It is a common choice in serverless and high-scale applications. But modeling your data with DynamoDB requires a different approach than modeling in traditional relational databases. Alex DeBrie is an AWS Data Hero, recognized for his work with DynamoDB, and author of The DynamoDB Book, a comprehensive guide to data modeling. In Part 2 of this two-part session, learn more advanced guiding principles, including strategies on how to handle complex, highly relational data models that don’t slow down as your application scales. Learn more about re:Invent 2020 at bit.ly/3c4NSdY Subscribe: More AWS videos bit.ly/2O3zS75 More AWS events videos bit.ly/316g9t4 #AWS #AWSEvents

Why it's here

1 person recommends this

What people say. Recommended as a guide to understanding DynamoDB's partition keys and single-table design patterns.

Sandeep Dixiton Stack Overflow • Recommends

On “Choice PK and SK in DynamoDB”

DynamoDb is a very different world from the SQL world. There are trade-offs for getting unlimited scalability. Do not rush to model your Db if the following appears absurd or new to you. Take your time to read more to understand. DynamoDb Tables have Partitions Keys which are used to automatically determine which physical partition data will be stored in. Do not mistake these with Primary Keys (also called PK). Partitions Keys are not generally unique. Single table is supposed to have store multiple entities (unlike SQL world). For example, user profile and user orders can be stored like this. PK: User#1 , SK: PROFILE# , username:dixitsandeep , addresses:[] PK : User#1 , SK: ORDER#…
6View the answer