‫Okay, so now let's talk
‫about Read and Write Capacity Modes for DynamoDB.
‫So this is how you control your table's capacity.
‫So you have to specify in advance
‫the read and write throughput.
‫So you have two modes actually.
‫The first one is called Provisioned Mode,
‫which is the default mode,
‫in which we specify the read and write per second,
‫so also called Read Capacity Unit and Write Capacity Unit.
‫You need to plan your capacity beforehand.
‫You're going to pay for whatever is going to be provisioned.
‫So if you say I want 10 read capacity units
‫and five write capacity units,
‫you're going to pay for that every hour.
‫And you have option to do auto-scaling
‫as we'll see very soon.
‫There is the second mode called the On-Demand Mode.
‫And this one will automatically have
‫the reads and the write scale up and down
‫based on your workloads,
‫and there's no capacity planning needed.
‫So you don't need to provision capacity units.
‫It will just be there.
‫And you're going to pay exactly for what you use,
‫but it's going to be a lot more expensive
‫than Provisioned Mode.
‫So the idea is that you have different use cases,
‫and we'll see them in this lecture in details.
‫So you can switch between the two modes,
‫Provisioned and On-Demand, once every 24 hours.
‫So we're going to do a deep dive on both of them,
‫so do not worry right now, it's just an introduction.
‫But now let's do a long deep dive
‫on Provisioned Read Capacity Mode.
‫So you must provision Read and Write Capacity Units,
‫also called RCU, which is a throughput for reads,
‫and WCU which is the throughput for writes.
‫Now, you have the option
‫to setup auto-scaling of throughput to meet demands.
‫So don't you think too hard
‫about your RCU and your WCU value.
‫You just say what's your target capacity usage,
‫and DynamoDB will scale those for you.
‫Now, in case you go over the RCU and over the WCU
‫because you're consuming more or writing more
‫than what you provisioned,
‫it's completely fine because you can tap
‫into temporarily what's called a Burst Capacity.
‫But if you exhaust the Burst Capacity
‫because it's been fully consumed,
‫then you're going to get an exception
‫called the ProvisionedThroughputExceededException
‫which is very obvious about what it is.
‫Then in case you get these things,
‫you need to obviously retry,
‫and the strategy to retry your write or your read
‫is called the exponential backoff retry strategy.
‫Now, let's look at WCU in detail.
‫So the exam will ask you to perform some computations,
‫and so therefore you need to understand the formulas
‫to compute WCU and RCU.
‫So one Write Capacity Unit, WCU,
‫will represent one write per second
‫for an item of up to one kilobyte in size.
‫And if your item is obviously larger than one kilobyte,
‫then you're going to consume more WCUs.
‫So let's go through examples to understand the computation.
‫And you can pause this video
‫if you want to do the computation on your own.
‫So if we write 10 items per second,
‫and the item size is on average two kilobytes,
‫how many WCUs do we need?
‫When we do the math,
‫we need 10 items per second, so 10 times,
‫and then the item size is two kilobytes
‫which we divide by one kilobyte
‫which is a number of WC unit for one kilobyte,
‫and you get a result of 20 WCUs.
‫So this was a very easy example.
‫Now, in example two, we write six items per second,
‫and this time the item size is 4.5 kilobytes.
‫It's a little bit trickier, this one.
‫So we need six times five divided by one
‫which is 30 RCU, why?
‫Well, because the 4.5 kilobytes
‫is always going to be rounded
‫to the upper kilobyte by DynamoDB
‫to get an idea of how many WCUs you've consumed.
‫So remember you need to round
‫to the upper kilobytes for WCUs.
‫Now, if you write 120 items per minute,
‫and the item size is two kilobytes,
‫the trick here is that we have items per minute.
‫We need to do a small computation
‫which is 120 divided by 60 to get items per second,
‫and then this gives us four WCUs.
‫Okay, so Write Capacity Units are very basic
‫and honestly very easy to understand.
‫The more complicated ones should be around reads.
‫So, first, we need to define
‫two kind of read modes for DynamoDB,
‫which is the Strongly Consistent Read
‫and the Eventually Consistent Read.
‫So if you consider DynamoDB,
‫it's a serverless database, of course,
‫but behind the scenes, there are servers.
‫You just don't see them or manage them.
‫So we have servers,
‫and let's just consider three servers right now
‫to make it very, very simple, but obviously a lot more,
‫and your data is going to be distributed and replicated
‫across all the servers.
‫Now, if you consider your application,
‫your application is going to do writes
‫to one of these servers,
‫and internally DynamoDB is going to replicate these writes
‫across different servers, such as Server 2 and Server 3.
‫Now, when your application reads from DynamoDB,
‫there is a chance that you're going to read
‫not from Server 1 but from Server 2.
‫Now, two things can happen, right?
‫If we are in Eventually Consistent Read,
‫which is the default mode,
‫then if we do a read just after a write,
‫it's possible that we'll get stale data
‫because the replication has not happened yet
‫if we're very, very quick.
‫But after, say, 100 milliseconds,
‫you're good to go obviously.
‫But if you do a Strongly Consistent Read, you're saying,
‫"Hey, I want to read the data just after the write,"
‫and you're going to get for sure
‫the correct data that was just written.
‫For this, we need to set a parameter
‫called ConsistentRead in our API to True,
‫and it could be applied
‫to GetItem, BatchGetItem, Query, and Scan.
‫And why we want to do this all the time?
‫Why wouldn't we want to have
‫Strongly Consistent Reads all the time?
‫Well, it's going to consume twice the RCUs,
‫so it's going to be a more expensive query
‫and also may have a slightly higher latency.
‫So you need to ask yourself,
‫"Do I need Eventually Consistent Reads,
‫or do I need Strongly Consistent Reads?"
‫Now, let's talk about RCU regarding these two things.
‫One Read Capacity Unit, RCU, represents
‫one Strongly Consistent Read per second,
‫or two Eventually Consistent Reads per second,
‫for an item of up to four kilobytes in size
‫which makes the computations a little bit trickier.
‫And if your items are larger than four kilobytes,
‫more RCUs are going to be consumed,
‫and, again, it's going to be rounded up
‫to the nearest upper four kilobytes.
‫So let's go through examples again,
‫and feel free to pause the video.
‫So if you have 10 Strongly Consistent Reads per second,
‫and the item size is four kilobytes,
‫how many RCUs do we need?
‫We'll need 10 times four kilobytes divided by four
‫which is equal to 10 RCUs, okay?
‫Now, if you have 16 Eventually Consistent Reads per second,
‫and the item size is 12 kilobytes,
‫so this is a bit more complicated, this one,
‫we're going to get 16 divided by two
‫times 12 divided by four
‫which is 24 RCUs.
‫So in this example, obviously,
‫we need to divide 16 divided by two because we don't need,
‫because we have two Eventually Consistent Reads per second
‫in one RCU,
‫and then we divide 12 by four which gives us 24 RCUs.
‫And last example,
‫which is 10 Strongly Consistent Reads per second,
‫with an item size of six kilobytes, okay?
‫So this one's a little bit trickier. So what is it?
‫Well, it's 10 times eight divided by four. And why eight?
‫Well, we round up six kilobytes
‫to the nearest four kilobytes,
‫so it's going to be eight kilobyte,
‫and you have to always go up, okay?
‫And in this case we get 10 times eight divided by four
‫which is two, so 20 RCUs.
‫So now that we know about WCUs and RCUs,
‫let's talk about how DynamoDB works
‫in the backend with partitions.
‫So DynamoDB is made of tables,
‫and each table has partitions,
‫and partitions are just copies of your data
‫that live on specific servers.
‫Now, when your application does writes into DynamoDB,
‫what's going to happen is that your application will send
‫a partition key, a sort key maybe, and some attributes.
‫And all this data is going to go
‫through a hashing algorithm.
‫So only the partition key actually is going to go
‫through a hashing algorithm
‫to understand which partition to go to.
‫So if we take the partition key of ID_13, it's going to go
‫through this internal hash function of DynamoDB
‫and it's going to say, "Hey, any time I see ID_13,
‫this is going to go into Partition 1."
‫And if you have ID_45 in the second row,
‫then ID_45 is going to go through the hash function,
‫and the hash function will say,
‫"Hey, this ID_45 should go to Partition 2."
‫And this is how your data gets distributed.
‫So, obviously, if you have what's called a hot partition,
‫the data is always going to be the hot key,
‫the data is always going to be into the same partition.
‫So to compute the number of partitions,
‫there are some intense formulas
‫that you do not need to know for the exam,
‫so let's go over them very quickly.
‫But you compute the number of partitions
‫by dividing the RCUs by 3,000 and WCU by 1,000,
‫and adding those up.
‫You can also have a look at how much data you have,
‫so total size of your dataset divided by 10 gigabytes,
‫and then the number of partition
‫is going to be the max of these two things.
‫Now, you don't need to know these formulas,
‫so do not worry about it at all, okay?
‫But what you need to understand, though,
‫is that if you have 10 partitions,
‫and you provide a new provision 10 WCUs and 10 RCUs,
‫then they're going to be spread evenly across partitions.
‫That mean that each partition is going to get
‫one WCU and one RCU,
‫and this is the point I want you to remember, okay?
‫WCUs and RCU are going to be divided
‫and spread evenly across partitions,
‫which brings us into throttling.
‫So in case you exceed the RCUs or WCUs,
‫and this is at the partition level,
‫then you're going to get
‫a ProvisionedThroughputExceededException.
‫So maybe because you have a hot key,
‫so one partition key is being read too many times
‫from a specific partition,
‫which is because maybe you have a popular item,
‫or hot partitions, or very large items
‫because, obviously, when WCU and RCU is computed,
‫it depends on the item size,
‫and so if you read or write a very large item,
‫you're going to consume a lot of RCU or WCUs.
‫Now, solutions for attacking
‫this ProvisionedThroughputExceededException
‫is, number one, to do exponential backoff
‫when the exception is encountered,
‫which is, if you're using the SDK,
‫something that's already included.
‫You have to distribute the partition keys
‫as much as possible
‫which was the exercise we did in the first lecture
‫to understand how we can choose a really good partition key.
‫And if this is an RCU issue,
‫because you're reading one data point
‫and were partitioned very, very heavily,
‫then we'll have a look at the feature
‫called DynamoDB Accelerator or DAX.
‫Now, the last mode we need to understand,
‫and this is a much easier mode to understand,
‫is the On-Demand Read/Write Capacity Mode,
‫which is going to automatically accept any reads and writes,
‫and it's going to scale up and down based on your workload.
‫So there is no capacity planning needed.
‫You do not specify the RCU or the WCU. It's unlimited.
‫There's no throttling, but obviously this is more expensive.
‫And you're going to charge for the actual reads and writes.
‫It's why it's called Read Request Units, so RRUs,
‫and Write Request Units which is WRUs.
‫The computations are the same, but the idea
‫is that because we have every request that succeeds,
‫it's not a capacity we talk about.
‫It's just on the request.
‫Now, to give you some overview,
‫On Demand is about 2.5x more expensive
‫than provisioned capacity,
‫so make sure that you have it
‫only for specific kind of use cases.
‫For example, unknown workloads
‫or when it's unpredictable application traffic.
‫So that's it for capacity modes in DynamoDB.
‫I hope you liked it, and I will see you in the next lecture.