1 00:00:00,250 --> 00:00:01,380 ‫Okay, so now let's talk 2 00:00:01,380 --> 00:00:04,770 ‫about Read and Write Capacity Modes for DynamoDB. 3 00:00:04,770 --> 00:00:06,950 ‫So this is how you control your table's capacity. 4 00:00:06,950 --> 00:00:08,167 ‫So you have to specify in advance 5 00:00:08,167 --> 00:00:09,280 ‫the read and write throughput. 6 00:00:09,280 --> 00:00:10,810 ‫So you have two modes actually. 7 00:00:10,810 --> 00:00:12,500 ‫The first one is called Provisioned Mode, 8 00:00:12,500 --> 00:00:13,580 ‫which is the default mode, 9 00:00:13,580 --> 00:00:16,610 ‫in which we specify the read and write per second, 10 00:00:16,610 --> 00:00:18,960 ‫so also called Read Capacity Unit and Write Capacity Unit. 11 00:00:18,960 --> 00:00:21,490 ‫You need to plan your capacity beforehand. 12 00:00:21,490 --> 00:00:24,290 ‫You're going to pay for whatever is going to be provisioned. 13 00:00:24,290 --> 00:00:26,530 ‫So if you say I want 10 read capacity units 14 00:00:26,530 --> 00:00:27,900 ‫and five write capacity units, 15 00:00:27,900 --> 00:00:30,140 ‫you're going to pay for that every hour. 16 00:00:30,140 --> 00:00:31,750 ‫And you have option to do auto-scaling 17 00:00:31,750 --> 00:00:33,140 ‫as we'll see very soon. 18 00:00:33,140 --> 00:00:35,570 ‫There is the second mode called the On-Demand Mode. 19 00:00:35,570 --> 00:00:38,010 ‫And this one will automatically have 20 00:00:38,010 --> 00:00:39,970 ‫the reads and the write scale up and down 21 00:00:39,970 --> 00:00:41,290 ‫based on your workloads, 22 00:00:41,290 --> 00:00:42,770 ‫and there's no capacity planning needed. 23 00:00:42,770 --> 00:00:44,680 ‫So you don't need to provision capacity units. 24 00:00:44,680 --> 00:00:46,240 ‫It will just be there. 25 00:00:46,240 --> 00:00:48,400 ‫And you're going to pay exactly for what you use, 26 00:00:48,400 --> 00:00:50,300 ‫but it's going to be a lot more expensive 27 00:00:50,300 --> 00:00:51,610 ‫than Provisioned Mode. 28 00:00:51,610 --> 00:00:53,200 ‫So the idea is that you have different use cases, 29 00:00:53,200 --> 00:00:55,670 ‫and we'll see them in this lecture in details. 30 00:00:55,670 --> 00:00:57,140 ‫So you can switch between the two modes, 31 00:00:57,140 --> 00:01:00,030 ‫Provisioned and On-Demand, once every 24 hours. 32 00:01:00,030 --> 00:01:01,580 ‫So we're going to do a deep dive on both of them, 33 00:01:01,580 --> 00:01:03,930 ‫so do not worry right now, it's just an introduction. 34 00:01:03,930 --> 00:01:06,020 ‫But now let's do a long deep dive 35 00:01:06,020 --> 00:01:08,140 ‫on Provisioned Read Capacity Mode. 36 00:01:08,140 --> 00:01:10,840 ‫So you must provision Read and Write Capacity Units, 37 00:01:10,840 --> 00:01:13,590 ‫also called RCU, which is a throughput for reads, 38 00:01:13,590 --> 00:01:17,120 ‫and WCU which is the throughput for writes. 39 00:01:17,120 --> 00:01:18,110 ‫Now, you have the option 40 00:01:18,110 --> 00:01:20,640 ‫to setup auto-scaling of throughput to meet demands. 41 00:01:20,640 --> 00:01:22,040 ‫So don't you think too hard 42 00:01:22,040 --> 00:01:24,530 ‫about your RCU and your WCU value. 43 00:01:24,530 --> 00:01:26,930 ‫You just say what's your target capacity usage, 44 00:01:26,930 --> 00:01:30,070 ‫and DynamoDB will scale those for you. 45 00:01:30,070 --> 00:01:33,930 ‫Now, in case you go over the RCU and over the WCU 46 00:01:33,930 --> 00:01:36,030 ‫because you're consuming more or writing more 47 00:01:36,030 --> 00:01:37,290 ‫than what you provisioned, 48 00:01:37,290 --> 00:01:39,430 ‫it's completely fine because you can tap 49 00:01:39,430 --> 00:01:43,110 ‫into temporarily what's called a Burst Capacity. 50 00:01:43,110 --> 00:01:45,040 ‫But if you exhaust the Burst Capacity 51 00:01:45,040 --> 00:01:46,650 ‫because it's been fully consumed, 52 00:01:46,650 --> 00:01:48,170 ‫then you're going to get an exception 53 00:01:48,170 --> 00:01:50,940 ‫called the ProvisionedThroughputExceededException 54 00:01:50,940 --> 00:01:53,720 ‫which is very obvious about what it is. 55 00:01:53,720 --> 00:01:55,310 ‫Then in case you get these things, 56 00:01:55,310 --> 00:01:56,990 ‫you need to obviously retry, 57 00:01:56,990 --> 00:01:59,540 ‫and the strategy to retry your write or your read 58 00:01:59,540 --> 00:02:02,990 ‫is called the exponential backoff retry strategy. 59 00:02:02,990 --> 00:02:04,680 ‫Now, let's look at WCU in detail. 60 00:02:04,680 --> 00:02:07,720 ‫So the exam will ask you to perform some computations, 61 00:02:07,720 --> 00:02:09,870 ‫and so therefore you need to understand the formulas 62 00:02:09,870 --> 00:02:12,440 ‫to compute WCU and RCU. 63 00:02:12,440 --> 00:02:15,160 ‫So one Write Capacity Unit, WCU, 64 00:02:15,160 --> 00:02:17,120 ‫will represent one write per second 65 00:02:17,120 --> 00:02:20,270 ‫for an item of up to one kilobyte in size. 66 00:02:20,270 --> 00:02:23,350 ‫And if your item is obviously larger than one kilobyte, 67 00:02:23,350 --> 00:02:26,220 ‫then you're going to consume more WCUs. 68 00:02:26,220 --> 00:02:28,470 ‫So let's go through examples to understand the computation. 69 00:02:28,470 --> 00:02:29,750 ‫And you can pause this video 70 00:02:29,750 --> 00:02:32,120 ‫if you want to do the computation on your own. 71 00:02:32,120 --> 00:02:34,640 ‫So if we write 10 items per second, 72 00:02:34,640 --> 00:02:37,900 ‫and the item size is on average two kilobytes, 73 00:02:37,900 --> 00:02:39,520 ‫how many WCUs do we need? 74 00:02:39,520 --> 00:02:41,220 ‫When we do the math, 75 00:02:41,220 --> 00:02:45,070 ‫we need 10 items per second, so 10 times, 76 00:02:45,070 --> 00:02:47,160 ‫and then the item size is two kilobytes 77 00:02:47,160 --> 00:02:48,930 ‫which we divide by one kilobyte 78 00:02:48,930 --> 00:02:51,720 ‫which is a number of WC unit for one kilobyte, 79 00:02:51,720 --> 00:02:54,700 ‫and you get a result of 20 WCUs. 80 00:02:54,700 --> 00:02:57,330 ‫So this was a very easy example. 81 00:02:57,330 --> 00:03:00,850 ‫Now, in example two, we write six items per second, 82 00:03:00,850 --> 00:03:04,390 ‫and this time the item size is 4.5 kilobytes. 83 00:03:04,390 --> 00:03:06,530 ‫It's a little bit trickier, this one. 84 00:03:06,530 --> 00:03:09,090 ‫So we need six times five divided by one 85 00:03:09,090 --> 00:03:11,220 ‫which is 30 RCU, why? 86 00:03:11,220 --> 00:03:12,920 ‫Well, because the 4.5 kilobytes 87 00:03:12,920 --> 00:03:14,440 ‫is always going to be rounded 88 00:03:14,440 --> 00:03:16,350 ‫to the upper kilobyte by DynamoDB 89 00:03:16,350 --> 00:03:20,410 ‫to get an idea of how many WCUs you've consumed. 90 00:03:20,410 --> 00:03:22,260 ‫So remember you need to round 91 00:03:22,260 --> 00:03:25,240 ‫to the upper kilobytes for WCUs. 92 00:03:25,240 --> 00:03:27,880 ‫Now, if you write 120 items per minute, 93 00:03:27,880 --> 00:03:29,930 ‫and the item size is two kilobytes, 94 00:03:29,930 --> 00:03:32,110 ‫the trick here is that we have items per minute. 95 00:03:32,110 --> 00:03:33,600 ‫We need to do a small computation 96 00:03:33,600 --> 00:03:38,110 ‫which is 120 divided by 60 to get items per second, 97 00:03:38,110 --> 00:03:40,623 ‫and then this gives us four WCUs. 98 00:03:41,460 --> 00:03:43,700 ‫Okay, so Write Capacity Units are very basic 99 00:03:43,700 --> 00:03:45,990 ‫and honestly very easy to understand. 100 00:03:45,990 --> 00:03:47,750 ‫The more complicated ones should be around reads. 101 00:03:47,750 --> 00:03:49,360 ‫So, first, we need to define 102 00:03:49,360 --> 00:03:52,260 ‫two kind of read modes for DynamoDB, 103 00:03:52,260 --> 00:03:54,050 ‫which is the Strongly Consistent Read 104 00:03:54,050 --> 00:03:56,690 ‫and the Eventually Consistent Read. 105 00:03:56,690 --> 00:03:58,220 ‫So if you consider DynamoDB, 106 00:03:58,220 --> 00:03:59,870 ‫it's a serverless database, of course, 107 00:03:59,870 --> 00:04:02,230 ‫but behind the scenes, there are servers. 108 00:04:02,230 --> 00:04:04,620 ‫You just don't see them or manage them. 109 00:04:04,620 --> 00:04:05,820 ‫So we have servers, 110 00:04:05,820 --> 00:04:07,680 ‫and let's just consider three servers right now 111 00:04:07,680 --> 00:04:10,570 ‫to make it very, very simple, but obviously a lot more, 112 00:04:10,570 --> 00:04:12,940 ‫and your data is going to be distributed and replicated 113 00:04:12,940 --> 00:04:14,590 ‫across all the servers. 114 00:04:14,590 --> 00:04:16,500 ‫Now, if you consider your application, 115 00:04:16,500 --> 00:04:18,500 ‫your application is going to do writes 116 00:04:18,500 --> 00:04:20,220 ‫to one of these servers, 117 00:04:20,220 --> 00:04:23,630 ‫and internally DynamoDB is going to replicate these writes 118 00:04:23,630 --> 00:04:27,800 ‫across different servers, such as Server 2 and Server 3. 119 00:04:27,800 --> 00:04:30,410 ‫Now, when your application reads from DynamoDB, 120 00:04:30,410 --> 00:04:32,140 ‫there is a chance that you're going to read 121 00:04:32,140 --> 00:04:35,280 ‫not from Server 1 but from Server 2. 122 00:04:35,280 --> 00:04:37,030 ‫Now, two things can happen, right? 123 00:04:37,030 --> 00:04:38,970 ‫If we are in Eventually Consistent Read, 124 00:04:38,970 --> 00:04:40,320 ‫which is the default mode, 125 00:04:40,320 --> 00:04:42,670 ‫then if we do a read just after a write, 126 00:04:42,670 --> 00:04:44,860 ‫it's possible that we'll get stale data 127 00:04:44,860 --> 00:04:47,250 ‫because the replication has not happened yet 128 00:04:47,250 --> 00:04:49,010 ‫if we're very, very quick. 129 00:04:49,010 --> 00:04:50,850 ‫But after, say, 100 milliseconds, 130 00:04:50,850 --> 00:04:52,290 ‫you're good to go obviously. 131 00:04:52,290 --> 00:04:55,177 ‫But if you do a Strongly Consistent Read, you're saying, 132 00:04:55,177 --> 00:04:58,630 ‫"Hey, I want to read the data just after the write," 133 00:04:58,630 --> 00:05:00,310 ‫and you're going to get for sure 134 00:05:00,310 --> 00:05:02,940 ‫the correct data that was just written. 135 00:05:02,940 --> 00:05:04,430 ‫For this, we need to set a parameter 136 00:05:04,430 --> 00:05:07,730 ‫called ConsistentRead in our API to True, 137 00:05:07,730 --> 00:05:08,810 ‫and it could be applied 138 00:05:08,810 --> 00:05:12,030 ‫to GetItem, BatchGetItem, Query, and Scan. 139 00:05:12,030 --> 00:05:13,970 ‫And why we want to do this all the time? 140 00:05:13,970 --> 00:05:15,600 ‫Why wouldn't we want to have 141 00:05:15,600 --> 00:05:17,400 ‫Strongly Consistent Reads all the time? 142 00:05:17,400 --> 00:05:19,633 ‫Well, it's going to consume twice the RCUs, 143 00:05:19,633 --> 00:05:22,310 ‫so it's going to be a more expensive query 144 00:05:22,310 --> 00:05:25,860 ‫and also may have a slightly higher latency. 145 00:05:25,860 --> 00:05:26,927 ‫So you need to ask yourself, 146 00:05:26,927 --> 00:05:28,500 ‫"Do I need Eventually Consistent Reads, 147 00:05:28,500 --> 00:05:31,310 ‫or do I need Strongly Consistent Reads?" 148 00:05:31,310 --> 00:05:33,900 ‫Now, let's talk about RCU regarding these two things. 149 00:05:33,900 --> 00:05:36,900 ‫One Read Capacity Unit, RCU, represents 150 00:05:36,900 --> 00:05:40,090 ‫one Strongly Consistent Read per second, 151 00:05:40,090 --> 00:05:42,570 ‫or two Eventually Consistent Reads per second, 152 00:05:42,570 --> 00:05:46,040 ‫for an item of up to four kilobytes in size 153 00:05:46,040 --> 00:05:48,350 ‫which makes the computations a little bit trickier. 154 00:05:48,350 --> 00:05:50,860 ‫And if your items are larger than four kilobytes, 155 00:05:50,860 --> 00:05:52,500 ‫more RCUs are going to be consumed, 156 00:05:52,500 --> 00:05:54,100 ‫and, again, it's going to be rounded up 157 00:05:54,100 --> 00:05:56,770 ‫to the nearest upper four kilobytes. 158 00:05:56,770 --> 00:05:58,060 ‫So let's go through examples again, 159 00:05:58,060 --> 00:05:59,800 ‫and feel free to pause the video. 160 00:05:59,800 --> 00:06:03,500 ‫So if you have 10 Strongly Consistent Reads per second, 161 00:06:03,500 --> 00:06:05,830 ‫and the item size is four kilobytes, 162 00:06:05,830 --> 00:06:07,650 ‫how many RCUs do we need? 163 00:06:07,650 --> 00:06:11,200 ‫We'll need 10 times four kilobytes divided by four 164 00:06:11,200 --> 00:06:14,240 ‫which is equal to 10 RCUs, okay? 165 00:06:14,240 --> 00:06:18,240 ‫Now, if you have 16 Eventually Consistent Reads per second, 166 00:06:18,240 --> 00:06:20,220 ‫and the item size is 12 kilobytes, 167 00:06:20,220 --> 00:06:22,480 ‫so this is a bit more complicated, this one, 168 00:06:22,480 --> 00:06:25,050 ‫we're going to get 16 divided by two 169 00:06:25,050 --> 00:06:27,010 ‫times 12 divided by four 170 00:06:27,010 --> 00:06:29,700 ‫which is 24 RCUs. 171 00:06:29,700 --> 00:06:31,420 ‫So in this example, obviously, 172 00:06:31,420 --> 00:06:34,350 ‫we need to divide 16 divided by two because we don't need, 173 00:06:34,350 --> 00:06:37,250 ‫because we have two Eventually Consistent Reads per second 174 00:06:38,120 --> 00:06:39,540 ‫in one RCU, 175 00:06:39,540 --> 00:06:43,640 ‫and then we divide 12 by four which gives us 24 RCUs. 176 00:06:43,640 --> 00:06:45,040 ‫And last example, 177 00:06:45,040 --> 00:06:47,980 ‫which is 10 Strongly Consistent Reads per second, 178 00:06:47,980 --> 00:06:50,660 ‫with an item size of six kilobytes, okay? 179 00:06:50,660 --> 00:06:53,820 ‫So this one's a little bit trickier. So what is it? 180 00:06:53,820 --> 00:06:57,300 ‫Well, it's 10 times eight divided by four. And why eight? 181 00:06:57,300 --> 00:06:59,060 ‫Well, we round up six kilobytes 182 00:06:59,060 --> 00:07:00,710 ‫to the nearest four kilobytes, 183 00:07:00,710 --> 00:07:02,410 ‫so it's going to be eight kilobyte, 184 00:07:02,410 --> 00:07:04,440 ‫and you have to always go up, okay? 185 00:07:04,440 --> 00:07:07,220 ‫And in this case we get 10 times eight divided by four 186 00:07:07,220 --> 00:07:09,850 ‫which is two, so 20 RCUs. 187 00:07:10,830 --> 00:07:13,190 ‫So now that we know about WCUs and RCUs, 188 00:07:13,190 --> 00:07:15,150 ‫let's talk about how DynamoDB works 189 00:07:15,150 --> 00:07:17,340 ‫in the backend with partitions. 190 00:07:17,340 --> 00:07:20,040 ‫So DynamoDB is made of tables, 191 00:07:20,040 --> 00:07:21,800 ‫and each table has partitions, 192 00:07:21,800 --> 00:07:23,800 ‫and partitions are just copies of your data 193 00:07:23,800 --> 00:07:26,080 ‫that live on specific servers. 194 00:07:26,080 --> 00:07:28,910 ‫Now, when your application does writes into DynamoDB, 195 00:07:28,910 --> 00:07:30,710 ‫what's going to happen is that your application will send 196 00:07:30,710 --> 00:07:34,180 ‫a partition key, a sort key maybe, and some attributes. 197 00:07:34,180 --> 00:07:35,830 ‫And all this data is going to go 198 00:07:35,830 --> 00:07:37,320 ‫through a hashing algorithm. 199 00:07:37,320 --> 00:07:38,910 ‫So only the partition key actually is going to go 200 00:07:38,910 --> 00:07:40,400 ‫through a hashing algorithm 201 00:07:40,400 --> 00:07:42,650 ‫to understand which partition to go to. 202 00:07:42,650 --> 00:07:45,710 ‫So if we take the partition key of ID_13, it's going to go 203 00:07:45,710 --> 00:07:48,360 ‫through this internal hash function of DynamoDB 204 00:07:48,360 --> 00:07:51,450 ‫and it's going to say, "Hey, any time I see ID_13, 205 00:07:51,450 --> 00:07:54,000 ‫this is going to go into Partition 1." 206 00:07:54,000 --> 00:07:56,640 ‫And if you have ID_45 in the second row, 207 00:07:56,640 --> 00:07:59,570 ‫then ID_45 is going to go through the hash function, 208 00:07:59,570 --> 00:08:00,403 ‫and the hash function will say, 209 00:08:00,403 --> 00:08:02,800 ‫"Hey, this ID_45 should go to Partition 2." 210 00:08:02,800 --> 00:08:05,100 ‫And this is how your data gets distributed. 211 00:08:05,100 --> 00:08:07,270 ‫So, obviously, if you have what's called a hot partition, 212 00:08:07,270 --> 00:08:09,600 ‫the data is always going to be the hot key, 213 00:08:09,600 --> 00:08:13,070 ‫the data is always going to be into the same partition. 214 00:08:13,070 --> 00:08:14,500 ‫So to compute the number of partitions, 215 00:08:14,500 --> 00:08:15,333 ‫there are some intense formulas 216 00:08:15,333 --> 00:08:17,240 ‫that you do not need to know for the exam, 217 00:08:17,240 --> 00:08:18,970 ‫so let's go over them very quickly. 218 00:08:18,970 --> 00:08:20,830 ‫But you compute the number of partitions 219 00:08:20,830 --> 00:08:24,320 ‫by dividing the RCUs by 3,000 and WCU by 1,000, 220 00:08:24,320 --> 00:08:26,040 ‫and adding those up. 221 00:08:26,040 --> 00:08:28,640 ‫You can also have a look at how much data you have, 222 00:08:28,640 --> 00:08:31,570 ‫so total size of your dataset divided by 10 gigabytes, 223 00:08:31,570 --> 00:08:32,820 ‫and then the number of partition 224 00:08:32,820 --> 00:08:35,170 ‫is going to be the max of these two things. 225 00:08:35,170 --> 00:08:36,850 ‫Now, you don't need to know these formulas, 226 00:08:36,850 --> 00:08:38,850 ‫so do not worry about it at all, okay? 227 00:08:38,850 --> 00:08:40,040 ‫But what you need to understand, though, 228 00:08:40,040 --> 00:08:42,497 ‫is that if you have 10 partitions, 229 00:08:42,497 --> 00:08:46,970 ‫and you provide a new provision 10 WCUs and 10 RCUs, 230 00:08:46,970 --> 00:08:49,150 ‫then they're going to be spread evenly across partitions. 231 00:08:49,150 --> 00:08:51,570 ‫That mean that each partition is going to get 232 00:08:51,570 --> 00:08:53,710 ‫one WCU and one RCU, 233 00:08:53,710 --> 00:08:55,980 ‫and this is the point I want you to remember, okay? 234 00:08:55,980 --> 00:08:58,300 ‫WCUs and RCU are going to be divided 235 00:08:58,300 --> 00:09:00,983 ‫and spread evenly across partitions, 236 00:09:01,840 --> 00:09:04,020 ‫which brings us into throttling. 237 00:09:04,020 --> 00:09:08,137 ‫So in case you exceed the RCUs or WCUs, 238 00:09:08,137 --> 00:09:10,030 ‫and this is at the partition level, 239 00:09:10,030 --> 00:09:10,863 ‫then you're going to get 240 00:09:10,863 --> 00:09:12,880 ‫a ProvisionedThroughputExceededException. 241 00:09:12,880 --> 00:09:14,880 ‫So maybe because you have a hot key, 242 00:09:14,880 --> 00:09:17,390 ‫so one partition key is being read too many times 243 00:09:17,390 --> 00:09:19,550 ‫from a specific partition, 244 00:09:19,550 --> 00:09:21,870 ‫which is because maybe you have a popular item, 245 00:09:21,870 --> 00:09:24,390 ‫or hot partitions, or very large items 246 00:09:24,390 --> 00:09:27,410 ‫because, obviously, when WCU and RCU is computed, 247 00:09:27,410 --> 00:09:28,610 ‫it depends on the item size, 248 00:09:28,610 --> 00:09:31,330 ‫and so if you read or write a very large item, 249 00:09:31,330 --> 00:09:35,210 ‫you're going to consume a lot of RCU or WCUs. 250 00:09:35,210 --> 00:09:37,140 ‫Now, solutions for attacking 251 00:09:37,140 --> 00:09:39,440 ‫this ProvisionedThroughputExceededException 252 00:09:39,440 --> 00:09:41,780 ‫is, number one, to do exponential backoff 253 00:09:41,780 --> 00:09:42,890 ‫when the exception is encountered, 254 00:09:42,890 --> 00:09:44,560 ‫which is, if you're using the SDK, 255 00:09:44,560 --> 00:09:46,360 ‫something that's already included. 256 00:09:46,360 --> 00:09:48,080 ‫You have to distribute the partition keys 257 00:09:48,080 --> 00:09:48,930 ‫as much as possible 258 00:09:48,930 --> 00:09:51,040 ‫which was the exercise we did in the first lecture 259 00:09:51,040 --> 00:09:54,040 ‫to understand how we can choose a really good partition key. 260 00:09:54,040 --> 00:09:55,800 ‫And if this is an RCU issue, 261 00:09:55,800 --> 00:09:58,420 ‫because you're reading one data point 262 00:09:58,420 --> 00:10:00,410 ‫and were partitioned very, very heavily, 263 00:10:00,410 --> 00:10:02,210 ‫then we'll have a look at the feature 264 00:10:02,210 --> 00:10:05,496 ‫called DynamoDB Accelerator or DAX. 265 00:10:05,496 --> 00:10:07,810 ‫Now, the last mode we need to understand, 266 00:10:07,810 --> 00:10:09,800 ‫and this is a much easier mode to understand, 267 00:10:09,800 --> 00:10:12,450 ‫is the On-Demand Read/Write Capacity Mode, 268 00:10:12,450 --> 00:10:16,010 ‫which is going to automatically accept any reads and writes, 269 00:10:16,010 --> 00:10:18,270 ‫and it's going to scale up and down based on your workload. 270 00:10:18,270 --> 00:10:19,970 ‫So there is no capacity planning needed. 271 00:10:19,970 --> 00:10:24,090 ‫You do not specify the RCU or the WCU. It's unlimited. 272 00:10:24,090 --> 00:10:27,200 ‫There's no throttling, but obviously this is more expensive. 273 00:10:27,200 --> 00:10:30,070 ‫And you're going to charge for the actual reads and writes. 274 00:10:30,070 --> 00:10:33,000 ‫It's why it's called Read Request Units, so RRUs, 275 00:10:33,000 --> 00:10:36,450 ‫and Write Request Units which is WRUs. 276 00:10:36,450 --> 00:10:38,460 ‫The computations are the same, but the idea 277 00:10:38,460 --> 00:10:41,170 ‫is that because we have every request that succeeds, 278 00:10:41,170 --> 00:10:42,510 ‫it's not a capacity we talk about. 279 00:10:42,510 --> 00:10:44,210 ‫It's just on the request. 280 00:10:44,210 --> 00:10:45,880 ‫Now, to give you some overview, 281 00:10:45,880 --> 00:10:48,500 ‫On Demand is about 2.5x more expensive 282 00:10:48,500 --> 00:10:49,760 ‫than provisioned capacity, 283 00:10:49,760 --> 00:10:51,380 ‫so make sure that you have it 284 00:10:51,380 --> 00:10:53,470 ‫only for specific kind of use cases. 285 00:10:53,470 --> 00:10:55,580 ‫For example, unknown workloads 286 00:10:55,580 --> 00:10:59,000 ‫or when it's unpredictable application traffic. 287 00:10:59,000 --> 00:11:02,930 ‫So that's it for capacity modes in DynamoDB. 288 00:11:02,930 --> 00:11:05,863 ‫I hope you liked it, and I will see you in the next lecture.