Great to see you back on RUclips after so long time. I think DDB limits are also it's biggest pros when you measure it in terms of performance. I wish DAX could have also been serverless in terms of pricing like pay per usage but it's charged in per hour. But for 90% of the time I don't think we really need it..
Thanks! Agreed on DAX, thought it's definitely tricky. Given the situations where you need that performance, you're probably not in a fully serverless environment anyway as you'll want a persistent TCP connection to DAX rather than using Lambda.
On the page size limit, since dynamodb has throttling on provisioned iops, 1MB or any other practical limit helps customers that their request once accepted will be served and won't be throttled in between. In order to achieve this, they need some practical limit on the total data returned.
There are updates on partitions limit to make it less real but overall great content 👏👏👏 what i realised after 2 decades of using sql & then mongodb is once you hit any kind of scale you tend to be forced to use any database with very similar limits as dynamodb or you end up with huge spikes in lag, or bills, or both. It's easier with sql/mongo at first but usually people tend to build app with expectation of high usage and if that happens, those databases may hit you hard at worst time - during the traffic spike, when people actually try to use your app.
Generally, there's not a hard limit on the size of a partition. DDB will usually keep them around 10GB, but it's not something you need to think about. This is true for main table and GSIs. *However*, if you have a local secondary index (LSI) on your table, then item collections (the set of keys with the same partition key value) cannot exceed 10GB. This is a hard limit and a hard wall to run into! :)
Hey Rohit, glad you liked it. Interactions with DynamoDB are over an HTTP API, so your connection will be like other HTTP clients. The big thing here is to ensure you're using HTTP Keep-Alive to reuse the connection across requests.
@@alexbdebrie Maybe a video in which you go through how you would structure your dynamodb tables giving some non-trivial (yet a common) situtation (e.g. a dating website). Each user have a list of images, chat messages, comments, e.tc.
@@asdfasdfuhf Good call! I have some like this already. :) You can see an e-commerce example here: ruclips.net/video/nsAJmyg2QU8/видео.html&ab_channel=AlexDeBrie Also, that example is from my book, which has a bunch of data modeling techniques plus 5 full walkthrough examples: www.dynamodbbook.com/
![I.N "HALLUCINATION" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/n5B5q1Hwt_U/mqdefault.jpg)
Love that you took the leap into creating videos! Looking forward to watching more of your content!
Thanks! I'll be adding more :)
simplified, amazing and precise
nice video man, explained well!!
Thanks, Syed! :)
Great to see you back on RUclips after so long time. I think DDB limits are also it's biggest pros when you measure it in terms of performance.
I wish DAX could have also been serverless in terms of pricing like pay per usage but it's charged in per hour. But for 90% of the time I don't think we really need it..
Thanks!
Agreed on DAX, thought it's definitely tricky. Given the situations where you need that performance, you're probably not in a fully serverless environment anyway as you'll want a persistent TCP connection to DAX rather than using Lambda.
On the page size limit, since dynamodb has throttling on provisioned iops, 1MB or any other practical limit helps customers that their request once accepted will be served and won't be throttled in between. In order to achieve this, they need some practical limit on the total data returned.
There are updates on partitions limit to make it less real but overall great content 👏👏👏 what i realised after 2 decades of using sql & then mongodb is once you hit any kind of scale you tend to be forced to use any database with very similar limits as dynamodb or you end up with huge spikes in lag, or bills, or both. It's easier with sql/mongo at first but usually people tend to build app with expectation of high usage and if that happens, those databases may hit you hard at worst time - during the traffic spike, when people actually try to use your app.
Is there a limitation on the size of a partition for GSI like there is in the 10gb main table?
Generally, there's not a hard limit on the size of a partition. DDB will usually keep them around 10GB, but it's not something you need to think about. This is true for main table and GSIs.
*However*, if you have a local secondary index (LSI) on your table, then item collections (the set of keys with the same partition key value) cannot exceed 10GB. This is a hard limit and a hard wall to run into! :)
Hi Alex, Nice lecture. I have one question. How DynamoDB manages connection pools? Can you please explain.
Hey Rohit, glad you liked it.
Interactions with DynamoDB are over an HTTP API, so your connection will be like other HTTP clients. The big thing here is to ensure you're using HTTP Keep-Alive to reuse the connection across requests.
Want to see your new video!
Any requests?? Always looking for topic ideas :)
@@alexbdebrie Maybe a video in which you go through how you would structure your dynamodb tables giving some non-trivial (yet a common) situtation (e.g. a dating website). Each user have a list of images, chat messages, comments, e.tc.
@@asdfasdfuhf Good call! I have some like this already. :)
You can see an e-commerce example here: ruclips.net/video/nsAJmyg2QU8/видео.html&ab_channel=AlexDeBrie
Also, that example is from my book, which has a bunch of data modeling techniques plus 5 full walkthrough examples: www.dynamodbbook.com/