AWS re:Invent 2020: Data modeling with Amazon DynamoDB

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

Рет қаралды 25,348

Күн бұрын

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

Пікірлер: 22

@lucasterable Жыл бұрын

"Understand you application", "identify the access patterns"... yeah, right. However, applications change over the years. New use cases are added and existing ones change as well. Therefore, new access patterns arise and the relations among entities evolve as well. This is a hard, advanced problem, but all panels, talks and videos seem to only focus on the basics and slow balls. Can someone direct me to a video/article/book that tackles the issue of rearranging an established DynamoDB data model to accommodate new access patterns and domain evolution?

@juhishelar6630 2 жыл бұрын

Thanks a lot Alex! Got to learn a lot about DynaboDB data modelling from your talk.

@ediancomachio2783 3 жыл бұрын

What a great talk! Thanks Alex!

@jay_s9645 Ай бұрын

Thanks Alex for this gr8 video. In the Sparse Index topic, (16:15 position in the video) I didnt understand how come you will fetch all Customers by keeping user name in the Partition key of GSI. Are you trying to do that by Scanning items? As by Querying items I think its not possible. Does Scanning item is efficient than Querying items?

@takisho5003 2 жыл бұрын

Very helpful, thank you

@JanekBogucki 3 жыл бұрын

Very good presentation. I do wonder if all the big design upfront which the single table approach requires is an indication DynamoDB is not the best choice for the problem. If there was a relational database that also had the scale out features of DynamoDB then the case for the single table approach would be diminished.

@brutusmaximumus 2 жыл бұрын

Relational requires quite a bit of BUFD if not more. Rick has another video where he discusses how to evolve a single table design. I've refactored large relational DBs in the past and it is no fun, hours to almost a day of outages, etc. Not every problem is ideal for a document DB, but the same is true for relational.

@xN811x Жыл бұрын

How is the partition key different from mysql's PARTITION BY HASH?

@awssupport Жыл бұрын

Great question! You may find what you're looking for here: go.aws/3ln9gla & go.aws/3YlfsZp. ⬅️ Additionally, you can reach out to our community of experts on re:Post for a possible answer: go.aws/aws-repost. 📮 ^TE

@theacid1 2 жыл бұрын

One thing all proposed dynamodb models are missing is the ability to query for specific entity types. In many of my applications I need to get all (or at least some) instances of a specific entity. I always add another GSI for the entity type but I'm not sure if this is the right way to go.

@thedrivendev7855 Жыл бұрын

You'll need a sparse GSI for each entity type that has a list all access pattern. Otherwise you'll be forced to use a scan operation or use a common partition key which will likely lead to a hot partition and will have size limitations when scaling.

@lucasterable Жыл бұрын

You can use the entity type as prefix to the PK, for example: USER#12345, ORDER#abcdef, QUESTION#sfwu9fuwe09. Then in the query you go: "WHERE PK > 'QUESTION#'" to get all the Question entities.

@wtfcartman 21 күн бұрын

@@thedrivendev7855 Will this not create hot partitions if an entity type (say, an AuditLog entity) has too many (millions of billions) items? > You'll need a sparse GSI for each entity type that has a list all access pattern

@praveenprasad9477 2 жыл бұрын

00:07 I can do sports commentary too...in the list things "Who I am"

@prerakhere Жыл бұрын

that's hilarious haha. Rick op though

@rickharold7884 2 жыл бұрын

Nice

@kresnofatihimani5073 2 жыл бұрын

nice

@cabo087 3 жыл бұрын

Although it still feels strange to me i'm willing to try this at my next customer. Though i'm scared that it might become a mess. My question: will this approach still be valid for the upcoming 5 years?

@timothyanderson2166 2 жыл бұрын

The only thing I haven’t been able to find in a DynamoDB tutorial/presentation is someone describing Dynamo without mentioning RDS. This honestly just confuses me (maybe I’m being difficult) but I’d so much rather learn Dynamo as a completely separate tool with no tie-ins to RDS concepts. Mentioning relational database systems, to me, just conflates my understanding, and therefor limits my understanding as a basic mapping from one system to another, completely separate system.

@jaspreetmodi 2 жыл бұрын

Please don't say this. Most real world use cases of organizations are to migrate from legacy rds to nosql and also, most, possibly 100% of people come from an rds background ... also, relational is extremely extremely matured, directly maps to a functional requirements .. e.g. sorting and filtering from video are not relational but real world functional use cases ... transaction handling, integrity of data etc are all functional issues.

@wk1781 Жыл бұрын

Hi. Is there a typo or do I miss something regarding the technique? Please see: kzfaq.info/get/bejne/sMmChpR0yLqplH0.html

@alexeyalexandrov7583 3 жыл бұрын

Are there still people who don't know how to design data in DynamoDB using single table approach? AWS does the same kind of talk every Re-invent, it's all described in Documentation and Best Practices ...