Common Single-Table design modeling mistakes with DynamoDB
Вставка
- Опубліковано 16 чер 2024
- Advanced DynamoDB Techniques: Designing your access patterns is hard, designing your keys for scale is even harder! Learn these advanced techniques to modeling your DynamoDB keys before you write records to your database. I have been working with DynamoDB for years and have seen a lot of pitfalls from naively designed keys, in this video I go over every trick I have to model modeling DynamoDB keys with a focus on single-table design.
If you use TypeScript/JavaScript, checkout the library ElectroDB at electrodb.dev for a type-safe way to accomplish all of these techniques out of the box!
00:00:00 Introduction
00:00:56 Agenda/Overview
00:01:27 Partition and Sort keys
00:05:48 Single-Table design pros/cons
00:07:32 Our challenge
00:07:55 Presentation conventions
00:08:40 The "Course" entity
00:11:47 Identify natural keys
00:13:06 Separate your attributres from key fields
00:15:28 Standize casing and spacing
00:18:18 Use delimiters after each composite attribute
00:18:58 Why delimiters matter
00:24:29 Zero pad composite attribute numbers
00:26:16 Order composite attribures by hierarchy
00:29:18 Revisit "Course" entity access patterns
00:31:41 The "Certificate" entity
00:31:52 "Certificate" and "Course" entity comparison
00:34:06 Cross entity access patterns
00:39:35 Entity Isolation
00:42:03 Include static prefixes
00:46:23 High Volume of records per partition
00:47:38 High relationship density per partition
00:50:01 Isolating entity versions with keys
00:53:03 Partition key distribution with sharding
01:01:49 Final access patterns
01:05:13 ElectroDB for TypeScript users - Наука та технологія
Interesting way to look at design
The best explanation of the design concept. I can see you must have spent a lot of time and effort to produce such a coherent presentation.
Gained lots from this video. I have been watching UA-cam videos for DynamoDB.
Your method of 'Show and Why' went that little bit further of 'Show and Do This Way'.
Your explanations help me understand why things are done as best practices.
Great presentation. Practical callouts and commentary added so much to these otherwise familiar concepts.
Thanks Tyler, great talk
this is a really great explanation, thanks for taking the time to put it together!
Tyler is gonna be a leader in this space within the next decade, hear him out!
Great explanation!!
Do you have plans to make some videos on ElectroDB? especially advanced concepts.
This was excellent. Thank you Tyler. It's too bad you don't offer modeling services as a freelancer.
How would I get all courses that are in building01 and building02 etc
Great question, you can use the `between` sort key operator for that 👍
I have a controversy about this design.
There is too much duplication.
It forces the use of a unique name. It doesn't allow to use of non-uniq names
I prefer to use ulid. It keeps unique and ordered.
ulid ID has date in ID, ulid keeps an ordering
theres nothing stopping you from building a composite key with timestamps.
This is all very cool. But seems like a lot of contortions and conventions to make up for the absence of things that something like mongo does out of the box with indexes, $lookup, ...