Hey, thanks for the video; it's very helpful! I have a question regarding the order and order items and the way you modeled them in DynamoDB. I understand the reason for moving orderItem to a different partition key, as you don't need to fetch all order items when fetching a customer with orders. But why did you use the following partition key (PK) for the order item: ORDER##ITEM#, and not just create a PK with ORDER# and two sort keys (SK) with ITEM#? For example, instead of this PK: ORDER#1#ITEM#1, SK:ORDER#1#ITEM#1, , GSI1PK: ORDER#1, GSI1SK: ITEM#1 PK: ORDER#1#ITEM#2, SK: ORDER#1#ITEM#2, , GSI1PK: ORDER#1, GSI1SK: ITEM#2 do this PK: ORDER#1 SK: ITEM#1, , GSI1PK: ORDER#1, GSI1SK: ITEM#1 PK: ORDER#1 SK: ITEM#2, , GSI1PK: ORDER#1, GSI1SK: ITEM#2
This video is amazing, however I've been trying to implement this code using Java Spring Boot but I don't know how could I implement this transaction to display the message 'Customer with this username already exists.' and 'Customer with this email already exists'. In my implementation if i send the same username and email nothing happended.
Hi Alex, Awesome Content!! I have 2 questions. 1. Will you be adding the additional examples from the DynamoDB Book (I only see 3 videos currently)? 2. Are you making the node.js code available? :) Thanks Alex
Thanks, Rick! These videos are just a preview of what you get in The DynamoDB Book. If you want all the videos, they are included in the Premium package of the book. Likewise, the Node.js code for all 5 examples in the book is available in both the Plus and the Premium packages.
Good question! DynamoDB excels at OLTP-like queries where you're operating on a specific, limited number of rows -- create an Order for this Customer, or view the 10 most recent Orders for this Customer. These queries partition well and are narrowly focused based on fixed parameteres. DynamoDB is not as good at 'table-wide queries', such as 'Give me all the Customers in my application'. There are some ways to do that, but it's tricky. It's usually best done in an OLAP database (if used for internal analytics) or something else like ElasticSearch
Thanks, Ori! This is from The DynamoDB Book. You can get the source code with the Plus or Premium package, and this video (plus videos for all chapters) are available in the Premium Package. www.dynamodbbook.com/
Great video, how to handle the same order for mutiples entries in dynamodb, like PK = store#id, SK=order#id and customer in your example customer#id, SK=order#id because store and customer will share the same order, how to handle it, to avoid duplication data and unneeded WUC consume? thanks a lot.
Hi, Alex. I'm starting to learn AWS and your videos and writing is helping me to better understand the DB on AWS. Do you recommend to use the Single-Table design for apps made with AWS Amplify?
Great to hear! I generally recommend a similar philosophy with GraphQL. It can add complexity to your resolvers but will be more performant. That said, I've seen many folks that have opted to use more isolated resolvers and a waterfall strategy for resolving a big graph in a GraphQL query, and that can work as well.
Hi Alex these are great content and i have gone through almost all of your videos. We have a use case where we have to retrieve all customers or all orders. But whatever i have seen there we have customer or order as pk or sk. To serve this use case we have to scan whole table which is not a good idea. is there anyway to do that ?
Hey there, it's a good question and one I get a lot. I need to write up the different options on these. It's tricky because you can give them the same partition key in a secondary index, but that can often result in a hot partition that hits partition throughput limits. What is the use case for this? Is this a production, user-facing use case, or more for internal processing?
@@alexbdebrie we are designing it for production from scratch and we had seperate table earlier but now we moving on single table design. We are able to cover almost all use cases but this get all customer, get all orders and there sub tasks are difficult to approach. It would be really great if you can put some light on this. Thanks you so much alex for your prompt reply btw
@@shailendraacharya I probably won't have a blog post in the next week or so. If you send me an email (alexdebrie1@gmail.com) and tell me the basic overview, I can point you in the right direction.
@@alexbdebrie thank you so much alex and I really appreciate your prompt response for helping me in design db. I will write you email today with all details.
Thanks Alex, enjoyed this and your talk at reInvent 2019. I have a question. In this example you have created GSI1PK, and GSI1SK, while in your talk at reInvent for a similar example, you used inverted index (swapping PK and SK). Is there any particular reason for indexing of separate fields here?
Good question! I changed my mind on that as I went. I almost never recommend re-using attributes across indexes anymore. In my opinion, it causes more headache than it's worth. If you're using overloaded primary keys and indexes, it's too hard to make sure they overlap correctly when you're re-using them. It also limits your flexibility if you need to add additional access patterns in the future. Stick with the pattern in this video, rather than the re:Invent one :)
