Something to consider. If you use the aggregation use case for streams, consider storing the counter columns in a different dynamo table. If you use one table, the update for the counter will trigger your lambda stream again and you can get into an endless loop of lambda execution unless you code for it appropriately, but you have to be careful. Using 2 tables allows you to use one stream on your primary and no streams are necessary on the aggregation table.
This is super cool . Probably the only youtube video [> 1hr ] , which I watched in whole. I took a whole week to watch it ... made sure I understood every idea presented and discussed. Thank you so much. I have a question => The partition placement , is DDB still using consistent hashing , for deciding which partition goes to which node[physical server] ... or there is some other algorithm used now. The original Dynamo paper mentioned consistent hashing [I read half the paper] ... Precisely => 1. How is it decided which key goes to which partition ? 2. How is it decided which partition goes to which node[physical server] ? Consistent hashing ... works in a bit different way ... all of the people watching this video knows how . For example in normal consistent hashing I guess it is hard to keep a limit on partition size ... I have read some part of the original consistent hashing paper ... in my quest to understand that paper ... somehow I reached your video .. and I thank myself for that.
This is so good. Thank you so much, you asked most of the questions I had in mind, and not just glossing over. Also really appreciate your effort on drawing, thank you so much ❤
Kaivalya, This was the second episode I heard from your channel. Hooked to it. Must say that the choice of speakers, the questions you asked was top notch. I can see the efforts you've put in. Keep going 💪
I really enjoyed the deep dive, it helped clarify some DDB limitations (that exist to provide predictable performance). I'm looking forward to a future talk on DDB data modelling!
50:00 when leader node gets down, this may cause inconsistency right? 1. Request arrived to update an item. 2. Leader node updated. 3. Change forwarded to Replica_A. 4. Leader node crashed 5. Change persisted in Replica_A. 6. Replica_B never saw this change and was elected new leader. How DDB handles this?
Thanks for your question. Depends on the read consistency levels. DDB supports strong consistency as well, in which case the update won’t be considered done if the write to replica fails. So basically you need to choose what consistency levels you need. (They provide discounts on low consistency reads, but please confirm this, as things may change). I hope it answers?
@@TheGeekNarrator thanks for answering. Lemme add another complexity here that Replica_A was able to ACK back to leader, whereas Replica_B didn't see this change. Now, if Replica_B is elected the leader, then the new replica spawned, (assuming) will copy from Replica_B. Since, that write succeeded and the client received success response, but the next time same item is fetched, it'll be a stale one. Doesn't this break the notion that DDB is a CP system?
DDB, would never choose a node to be leader in case it is not up to date. This comes when paxos does the leader election it each node has to tell it's state in the election only if it is up to date it gets elected as leader
Have you looked at the Database internals book? Do check it out. A good start can also be the episode I did with Franck Pachot Part 1 - Database Internals with Franck Pachot ua-cam.com/video/DiLA0Ri6RfY/v-deo.html
You're doing a great job with these podcasts, please continue making more such deep dive videos
Thanks a lot 🙏🏻
Thank you for the great podcast 🔥, looking for more like this.
Thank you 🙏🏻😀
Something to consider. If you use the aggregation use case for streams, consider storing the counter columns in a different dynamo table. If you use one table, the update for the counter will trigger your lambda stream again and you can get into an endless loop of lambda execution unless you code for it appropriately, but you have to be careful. Using 2 tables allows you to use one stream on your primary and no streams are necessary on the aggregation table.
This is super cool . Probably the only youtube video [> 1hr ] , which I watched in whole. I took a whole week to watch it ... made sure I understood every idea presented and discussed. Thank you so much.
I have a question =>
The partition placement , is DDB still using consistent hashing , for deciding which partition goes to which node[physical server] ... or there is some other algorithm used now. The original Dynamo paper mentioned consistent hashing [I read half the paper] ...
Precisely =>
1. How is it decided which key goes to which partition ?
2. How is it decided which partition goes to which node[physical server] ?
Consistent hashing ... works in a bit different way ... all of the people watching this video knows how .
For example in normal consistent hashing I guess it is hard to keep a limit on partition size ... I have read some part of the original consistent hashing paper ... in my quest to understand that paper ... somehow I reached your video .. and I thank myself for that.
Great video. Excited for part 2
Thanks for watching 🙏🏻 Part-2 is coming soon.
This is so good. Thank you so much, you asked most of the questions I had in mind, and not just glossing over. Also really appreciate your effort on drawing, thank you so much ❤
Thank you 🙏🏻😀
Great video with simple explanation. Waiting for a podcast on SOLID principles.
Very informative podcast, thank you, especially for the drawings
Thank you 🙏🏻😀
Kaivalya, This was the second episode I heard from your channel. Hooked to it. Must say that the choice of speakers, the questions you asked was top notch. I can see the efforts you've put in.
Keep going 💪
Thanks a lot 🙏🏻😀
I really enjoyed the deep dive, it helped clarify some DDB limitations (that exist to provide predictable performance). I'm looking forward to a future talk on DDB data modelling!
Thanks Chris. Data Modelling episode will be recorded soon.
Amazing session, guys! Thank you so much for the content. I will subscribe and also take a look at Alex's book! Keep up the amazing work!
Thank you so much for watching and subscribe. I am really glad you liked it. 🙏🏻
One of the best dynamodb deep dives I have listened to. Looking forward to the data modelling episode.
50:00 when leader node gets down, this may cause inconsistency right?
1. Request arrived to update an item.
2. Leader node updated.
3. Change forwarded to Replica_A.
4. Leader node crashed
5. Change persisted in Replica_A.
6. Replica_B never saw this change and was elected new leader.
How DDB handles this?
Thanks for your question. Depends on the read consistency levels. DDB supports strong consistency as well, in which case the update won’t be considered done if the write to replica fails. So basically you need to choose what consistency levels you need. (They provide discounts on low consistency reads, but please confirm this, as things may change). I hope it answers?
@@TheGeekNarrator thanks for answering. Lemme add another complexity here that Replica_A was able to ACK back to leader, whereas Replica_B didn't see this change. Now, if Replica_B is elected the leader, then the new replica spawned, (assuming) will copy from Replica_B. Since, that write succeeded and the client received success response, but the next time same item is fetched, it'll be a stale one. Doesn't this break the notion that DDB is a CP system?
Also, since strongly consistent reads go to the leader rather than replica, we'll get stale data in the above scenario.
DDB, would never choose a node to be leader in case it is not up to date. This comes when paxos does the leader election it each node has to tell it's state in the election only if it is up to date it gets elected as leader
Hi, thank you for the contents!!! What is the annotation software you are using, if you don't mind me asking
Thanks. I use excalidraw for diagrams, canva for some visuals and descript for editing.
Alex - what about headless CMS - I tried to create using dynamoDB one year. Has any companies attempted this?
Can you please recommend any resources to understand more about database internals
Have you looked at the Database internals book? Do check it out. A good start can also be the episode I did with Franck Pachot Part 1 - Database Internals with Franck Pachot
ua-cam.com/video/DiLA0Ri6RfY/v-deo.html
Can we have similar video for redshift as well . BTW these videos are really helpful😊
Thank you 🙏🏻 noted.
Subscribed your channel in hope of learning good stuff here.
Thank you 🙏🏻 Hope you find good learnings. Always feel free to provide feedback. 😀
When is the session on jvm? I want to master it.
Coming soon. Possibly in two weeks. Could you elaborate on what exactly you want to learn?
What is the name of the app you using for drawings?
Goodnotes