1 00:00:00,240 --> 00:00:01,073 ‫So now let's talk 2 00:00:01,073 --> 00:00:03,850 ‫about DynamoDB Accelerator or DAX. 3 00:00:03,850 --> 00:00:05,870 ‫DAX is a fully-managed, highly available 4 00:00:05,870 --> 00:00:09,250 ‫and seamless in-memory cache for DynamoDB. 5 00:00:09,250 --> 00:00:10,480 ‫The idea is that you're going to cache 6 00:00:10,480 --> 00:00:11,313 ‫the most popular data, 7 00:00:11,313 --> 00:00:14,010 ‫and therefore you're going to get microsecond latency 8 00:00:14,010 --> 00:00:16,430 ‫for cached reads and queries. 9 00:00:16,430 --> 00:00:17,936 ‫It doesn't require you to change any 10 00:00:17,936 --> 00:00:19,720 ‫of your application logic, 11 00:00:19,720 --> 00:00:22,370 ‫it's compatible with the existing DynamoDB APIs. 12 00:00:22,370 --> 00:00:25,910 ‫And you just create a DAX cluster and you're good to go. 13 00:00:25,910 --> 00:00:27,630 ‫Now, DAX, what does it solve? 14 00:00:27,630 --> 00:00:29,350 ‫It solves the hot key problems. 15 00:00:29,350 --> 00:00:32,370 ‫So if you're reading a very specific key 16 00:00:32,370 --> 00:00:33,760 ‫or a very specific item, 17 00:00:33,760 --> 00:00:37,800 ‫too many times then you may get throttling on your RCU's. 18 00:00:37,800 --> 00:00:39,640 ‫But if it's cached by DAX, 19 00:00:39,640 --> 00:00:41,440 ‫then you've just solved that problem. 20 00:00:41,440 --> 00:00:44,270 ‫So let's have an example, we DynamoDB it's made of tables 21 00:00:44,270 --> 00:00:46,450 ‫and our application is trying to access these tables. 22 00:00:46,450 --> 00:00:48,670 ‫Now in between, we're going to create a DAX cluster, 23 00:00:48,670 --> 00:00:50,420 ‫which is made of cache nodes, 24 00:00:50,420 --> 00:00:52,210 ‫and we have to provision them in advance. 25 00:00:52,210 --> 00:00:55,050 ‫Now the application will directly interact 26 00:00:55,050 --> 00:00:56,240 ‫with the DAX cluster, 27 00:00:56,240 --> 00:00:57,920 ‫and the DAX cluster will fetch the data 28 00:00:57,920 --> 00:00:59,730 ‫from the DynamoDB tables. 29 00:00:59,730 --> 00:01:01,990 ‫So by default, that means that some data 30 00:01:01,990 --> 00:01:03,090 ‫is going to be cached, 31 00:01:03,090 --> 00:01:05,000 ‫and if you think cached, you need to think TTL. 32 00:01:05,000 --> 00:01:07,540 ‫So the TTL is going to be five minutes. 33 00:01:07,540 --> 00:01:10,330 ‫So by default, every cache data will live 34 00:01:10,330 --> 00:01:13,030 ‫for five minutes in your DAX cluster. 35 00:01:13,030 --> 00:01:14,700 ‫Now the DAX cluster is made of nodes, 36 00:01:14,700 --> 00:01:16,260 ‫and so therefore you need to provision them 37 00:01:16,260 --> 00:01:18,780 ‫and you can have up to 10 nodes in the cluster. 38 00:01:18,780 --> 00:01:22,240 ‫And it's a good idea to be in a Multi-AZ kind of setup 39 00:01:22,240 --> 00:01:25,590 ‫to have at least three nodes recommended in production. 40 00:01:25,590 --> 00:01:27,680 ‫So one in each AZ. 41 00:01:27,680 --> 00:01:29,210 ‫And DAX is fully secure, 42 00:01:29,210 --> 00:01:30,730 ‫so you have encrypted at rest. 43 00:01:30,730 --> 00:01:33,430 ‫You have IAM application, VPC security, 44 00:01:33,430 --> 00:01:35,970 ‫CloudTrail integration, and so on. 45 00:01:35,970 --> 00:01:38,300 ‫So remember DAX is here to help you cache 46 00:01:38,300 --> 00:01:42,110 ‫the most popular items or queries from DynamoDB. 47 00:01:42,110 --> 00:01:43,370 ‫Now, the question we have, 48 00:01:43,370 --> 00:01:45,690 ‫is what's the difference between DynamoDB Accelerator, 49 00:01:45,690 --> 00:01:47,730 ‫so DAX and ElastiCache? 50 00:01:47,730 --> 00:01:50,290 ‫Well, they can be used as a combination 51 00:01:50,290 --> 00:01:52,630 ‫and the exam may test you on figuring out 52 00:01:52,630 --> 00:01:54,570 ‫if it's best to use DynamoDB DAX, 53 00:01:54,570 --> 00:01:56,870 ‫or if you wanna use ElastiCache. 54 00:01:56,870 --> 00:01:58,480 ‫So with DAX, what you're going to do 55 00:01:58,480 --> 00:02:00,300 ‫is that you're going to have a cache 56 00:02:00,300 --> 00:02:02,800 ‫for individual objects or for your queries, 57 00:02:02,800 --> 00:02:03,633 ‫or your scans. 58 00:02:03,633 --> 00:02:04,890 ‫This is very, very handy, 59 00:02:04,890 --> 00:02:07,810 ‫and this is what I call simple types of queries. 60 00:02:07,810 --> 00:02:10,550 ‫So your objects, your queries and your scans. 61 00:02:10,550 --> 00:02:13,990 ‫But if you're doing some kind of logic application wise, 62 00:02:13,990 --> 00:02:15,720 ‫you know you're like doing a scan 63 00:02:15,720 --> 00:02:17,310 ‫and then you're doing the sum, 64 00:02:17,310 --> 00:02:19,076 ‫and then you're filtering out some data, and so on. 65 00:02:19,076 --> 00:02:21,490 ‫And you don't want to do this every single time, 66 00:02:21,490 --> 00:02:23,630 ‫because this is computationally expensive. 67 00:02:23,630 --> 00:02:25,540 ‫What you can do, is you can store the results 68 00:02:25,540 --> 00:02:27,138 ‫of whatever your application just did 69 00:02:27,138 --> 00:02:29,060 ‫in Amazon ElastiCache. 70 00:02:29,060 --> 00:02:31,750 ‫And retrieve the data from ElastiCache directly, 71 00:02:31,750 --> 00:02:35,000 ‫instead of re-querying DAX and re-performing 72 00:02:35,000 --> 00:02:36,560 ‫the aggregation client side. 73 00:02:36,560 --> 00:02:37,660 ‫So this could be a good way 74 00:02:37,660 --> 00:02:41,730 ‫to actually use them both together in the architecture. 75 00:02:41,730 --> 00:02:42,563 ‫Okay. 76 00:02:42,563 --> 00:02:43,396 ‫So now let's go ahead 77 00:02:43,396 --> 00:02:45,190 ‫and see how we can create a DAX cluster.