Okay.
Hello bloggers and welcome to this lecture.
This lecture is on dynamo D.B. Zu dynamo.
D.B. is Amazon's no sequel database solution so the opposite of yes.
So what is dynamo D.B. what's a fast and flexible no sequel database service for all applications that
need consistent single digit millisecond latency at any scale.
It's a fully managed database service and it supports both document and key value data models.
It's flexible data model and reliable performance make it great a great fit for mobile Web gaming ad
tech I.T. and many other applications.
So definitely a lot of mobile developers do use dynamo D.B. in this section of the course were not going
to go in and create a dynamo IDB table.
But we are going to do it in the services section we're basically going to use our dynamo db table to
store some notes that we want to convert into MP 3 files.
So please do take notes throughout this course put them in just plain text and what we will do is we're
going to convert those to an MP 3 file using the poly service and we're even going to build an Alexa
skill to read out our notes to us.
We're going to do that in the service section of the course.
So the basics of dynamo D.B. are as follows it's stored on SSD storage so that's why it is so fast it's
spread across three different geographically distinct data centers.
You're going to always have redundancy and that's got two different types of Reid models so we've got
eventually consistent reads which is what you're going to get by default.
And then we also have strongly consistent read.
So what's the difference between eventual consistent reads and strongly consistent reads well it comes
down to the one second rule.
So with eventually consistent reads consistency across all copies of your data is usually reach within
one second.
Repeating a read after a short time should return the updated data.
So if you've got an application and it's writing to a dynamo db table and then you want to read that
data that's been written to that table you know a couple of seconds later then that's fine you want
eventually consistent reads and this will give you the best read performance.
And this is enabled by default.
However if you have an application that writes to a dynamo db table and it needs to read that data within
or less than one second then you want strongly consistent reads and this will basically return a result
that reflects all rights that received a successful response prior to the read.
So again the one second rule so long as your application is happy that it doesn't need to read that
data that's been written within one second.
Then you want eventually consistent reads.
However if you've got an application that needs to as soon as an update has been done to a dynamo db
table and that application needs to read that update in one second or less then you're going to want
strongly consistent reads.
So just remember the one second rule for Dynamo DP.
So really that's all you need to know for Dynamo IDB in these certified Solutions Architect associate
exam.
Like I said we are going to cover it off in the service section of the course where we'll go in and
provision it in a lab.
But before we learn about dynamo D.B. we really need to understand a whole bunch of different other
service services.
So we're going to go through things like lambda etc. And then what we're going to do is we're going
to build out a lab that does use dynamite D.B..
So going into your exam just remember it's stored on SSD storage.
It's spread across three geographically distinct data centers.
You probably want eventually consistent reads you get this by default so long as your application writes
to the table and then your application won't read that data within the first second.
Then you want eventually consistent reads.
If it is going to read that data within one second of it being written to the table then you want to
strongly consistent reads.
So that is it for this lecture goes if you have any questions please let me know.
If not feel free to move on to the next lecture.
Thank you.