1 00:00:07,470 --> 00:00:11,253 - Now let's review an introduction to Amazon DynamoDB. 2 00:00:12,160 --> 00:00:14,070 Now, of course, with DynamoDB, 3 00:00:14,070 --> 00:00:17,620 we gain access to a fully managed NoSQL Data store. 4 00:00:17,620 --> 00:00:20,480 Again, like we've talked about earlier, 5 00:00:20,480 --> 00:00:22,860 DynamoDB is in the same family 6 00:00:23,820 --> 00:00:26,920 as systems like Cassandra and MongoDB 7 00:00:26,920 --> 00:00:31,720 and others in that NoSQL, you know, type of database. 8 00:00:31,720 --> 00:00:36,590 Now of course, DynamoDB is exclusively backed by SSDs. 9 00:00:36,590 --> 00:00:38,700 So we know that when we write... 10 00:00:38,700 --> 00:00:41,870 Any data written to this table 11 00:00:41,870 --> 00:00:44,400 is written to multiple nodes 12 00:00:44,400 --> 00:00:46,770 exclusively backed by SSD storage 13 00:00:46,770 --> 00:00:49,980 to help ensure that our reads and writes 14 00:00:49,980 --> 00:00:51,560 are as fast as they can be. 15 00:00:51,560 --> 00:00:54,300 And of course, DynamoDB is capable 16 00:00:54,300 --> 00:00:57,040 of single-digit millisecond response 17 00:00:57,040 --> 00:01:00,370 if we are using an index based query. 18 00:01:00,370 --> 00:01:02,050 If we're doing a full table scan, 19 00:01:02,050 --> 00:01:05,630 then we can't expect a single-digit millisecond response. 20 00:01:05,630 --> 00:01:09,313 But we can if we are using an index based query. 21 00:01:10,230 --> 00:01:11,528 And of course, 22 00:01:11,528 --> 00:01:15,300 DynamoDB, like most managed services, 23 00:01:15,300 --> 00:01:18,560 is inherently highly available and fault tolerant. 24 00:01:18,560 --> 00:01:21,830 Those kinds of things are already built in. 25 00:01:21,830 --> 00:01:25,030 Unlike RDS where we have to opt-in 26 00:01:25,030 --> 00:01:27,200 to Multi-AZ deployments 27 00:01:27,200 --> 00:01:29,220 in order to gain fault tolerance. 28 00:01:29,220 --> 00:01:32,070 With DynamoDB, it's already built in. 29 00:01:32,070 --> 00:01:33,900 There's nothing for us to opt-in to. 30 00:01:33,900 --> 00:01:35,850 It's just a part of the service. 31 00:01:35,850 --> 00:01:37,460 And so, 32 00:01:37,460 --> 00:01:40,420 one of the ways that DynamoDB achieves that 33 00:01:40,420 --> 00:01:42,560 is to replicate the data 34 00:01:42,560 --> 00:01:44,850 not only across numerous drives 35 00:01:44,850 --> 00:01:47,980 but across numerous Availability Zones. 36 00:01:47,980 --> 00:01:50,750 Or essentially, numerous data centers. 37 00:01:50,750 --> 00:01:51,850 And so that, 38 00:01:51,850 --> 00:01:54,780 the DynamoDB service is resilient 39 00:01:54,780 --> 00:01:56,940 not only to the loss of a device 40 00:01:56,940 --> 00:01:59,493 but also to the loss of a data center. 41 00:02:00,670 --> 00:02:02,940 Now, with DynamoDB, 42 00:02:02,940 --> 00:02:05,360 we don't need to provision storage. 43 00:02:05,360 --> 00:02:07,920 Storage just grows automatically. 44 00:02:07,920 --> 00:02:10,630 But we do need to provision the throughput. 45 00:02:10,630 --> 00:02:12,420 And throughput is essentially 46 00:02:12,420 --> 00:02:14,930 measured in terms of reads per second 47 00:02:14,930 --> 00:02:16,240 and writes per second. 48 00:02:16,240 --> 00:02:17,270 Right, so. 49 00:02:17,270 --> 00:02:18,560 What is our workload? 50 00:02:18,560 --> 00:02:20,120 Some tables may be read heavy, 51 00:02:20,120 --> 00:02:21,650 some may be write heavy, 52 00:02:21,650 --> 00:02:23,340 some may be balanced. 53 00:02:23,340 --> 00:02:25,590 But every table will do 54 00:02:25,590 --> 00:02:29,200 a certain number of reads per second and writes per second. 55 00:02:29,200 --> 00:02:30,790 And that really is probably 56 00:02:30,790 --> 00:02:33,730 the greatest thing that contributes to our cost. 57 00:02:33,730 --> 00:02:35,070 Yes, we pay for storage, 58 00:02:35,070 --> 00:02:39,150 but we also pay for the provisioned throughput. 59 00:02:39,150 --> 00:02:43,290 Now, as far as data models in Amazon DynamoDB go, 60 00:02:43,290 --> 00:02:45,360 we have tables 61 00:02:45,360 --> 00:02:47,530 that are comprised of items 62 00:02:47,530 --> 00:02:49,620 that are comprised of attributes. 63 00:02:49,620 --> 00:02:51,040 And that's basically it. 64 00:02:51,040 --> 00:02:51,873 That's what we have. 65 00:02:51,873 --> 00:02:54,720 We don't have any foreign keys or anything like that. 66 00:02:54,720 --> 00:02:58,020 There are no joins and no relationships. 67 00:02:58,020 --> 00:03:01,010 Now of course, you could within your own application, 68 00:03:01,010 --> 00:03:03,030 you could pull data from two different tables 69 00:03:03,030 --> 00:03:05,280 and join that within your application. 70 00:03:05,280 --> 00:03:08,010 But again, DynamoDB will not do that for you. 71 00:03:08,010 --> 00:03:11,460 It inherently has no 72 00:03:11,460 --> 00:03:14,730 knowledge of any relationships or foreign keys. 73 00:03:14,730 --> 00:03:17,360 It's also a schema-less design. 74 00:03:17,360 --> 00:03:21,330 Right, DynamoDB does not support any kind of a schema 75 00:03:21,330 --> 00:03:23,700 except for maybe the primary key. 76 00:03:23,700 --> 00:03:24,700 Right, the primary key is 77 00:03:24,700 --> 00:03:26,720 the only thing that you have to specify 78 00:03:29,201 --> 00:03:33,060 what attribute for that item will be the primary key 79 00:03:33,060 --> 00:03:36,110 and the data type for that attribute. 80 00:03:36,110 --> 00:03:37,870 But beyond that, 81 00:03:37,870 --> 00:03:38,850 if you wanted to, 82 00:03:38,850 --> 00:03:40,960 you could have every item in that table 83 00:03:40,960 --> 00:03:44,820 have completely different set of attributes, right. 84 00:03:44,820 --> 00:03:45,653 Your app-- 85 00:03:45,653 --> 00:03:47,560 If your application needs a schema, 86 00:03:47,560 --> 00:03:50,910 then your application would have to enforce that schema. 87 00:03:50,910 --> 00:03:54,250 But DynamoDB will not enforce any kind of a schema 88 00:03:54,250 --> 00:03:57,233 outside of the primary key or an index. 89 00:03:58,460 --> 00:03:59,603 And so, 90 00:04:01,320 --> 00:04:02,980 speaking of the primary key, 91 00:04:02,980 --> 00:04:06,440 every item does require a unique primary key. 92 00:04:06,440 --> 00:04:07,880 And that is indexed. 93 00:04:07,880 --> 00:04:10,310 And that's one of the ways that we can achieve 94 00:04:10,310 --> 00:04:12,470 that single-digit millisecond response 95 00:04:12,470 --> 00:04:16,120 is by querying based on the primary key. 96 00:04:16,120 --> 00:04:19,300 And then of course, if we need to be able to query 97 00:04:20,250 --> 00:04:23,800 on some other attribute other than the primary key, 98 00:04:23,800 --> 00:04:26,110 we can create secondary indexes. 99 00:04:26,110 --> 00:04:28,330 We have local secondary indexes 100 00:04:28,330 --> 00:04:30,820 and global secondary indexes. 101 00:04:30,820 --> 00:04:34,320 And those give us a way, again, to query, 102 00:04:34,320 --> 00:04:37,810 to make fast single-digit millisecond queries 103 00:04:37,810 --> 00:04:41,123 based on an attribute other than the primary key. 104 00:04:43,400 --> 00:04:45,100 Another nice thing about DynamoDB 105 00:04:45,100 --> 00:04:48,730 is that there is no limit to the size of a table. 106 00:04:48,730 --> 00:04:51,000 You can just throw data at this table 107 00:04:52,250 --> 00:04:55,700 and it can grow into the petabytes and beyond 108 00:04:55,700 --> 00:04:58,190 and there's nothing you need to do. 109 00:04:58,190 --> 00:05:00,410 Amazon will not impose a limit on that 110 00:05:00,410 --> 00:05:01,780 and there's nothing we need to do 111 00:05:01,780 --> 00:05:03,490 to go and provision more storage. 112 00:05:03,490 --> 00:05:05,660 It just happens automatically. 113 00:05:05,660 --> 00:05:07,090 There is 114 00:05:07,090 --> 00:05:10,430 a 400K limit per item. 115 00:05:10,430 --> 00:05:12,180 So that is something to keep in mind. 116 00:05:12,180 --> 00:05:16,070 You will not be storing blobs within DynamoDB. 117 00:05:16,070 --> 00:05:18,510 If you do have something larger than that, 118 00:05:18,510 --> 00:05:20,530 maybe a large document of some kind, 119 00:05:20,530 --> 00:05:24,550 that's in the megs or gigs. 120 00:05:24,550 --> 00:05:28,705 Then a common practice would be to store that large blob 121 00:05:28,705 --> 00:05:30,840 in something like S3 122 00:05:30,840 --> 00:05:34,260 and then store metadata about that in DynamoDB. 123 00:05:34,260 --> 00:05:38,730 So that you can form your searches in DynamoDB, 124 00:05:38,730 --> 00:05:43,003 reference the key and then download that blob from S3. 125 00:05:44,080 --> 00:05:45,340 DynamoDB, 126 00:05:45,340 --> 00:05:50,340 a recent addition to DynamoDB in late 2018 127 00:05:50,350 --> 00:05:52,950 was the ability to support transactions. 128 00:05:52,950 --> 00:05:55,280 Right, so DynamoDB can be, 129 00:05:55,280 --> 00:05:56,920 you know, asset compliant 130 00:05:56,920 --> 00:05:58,500 if you need transactions. 131 00:05:58,500 --> 00:06:00,500 So with DynamoDB transactions, 132 00:06:00,500 --> 00:06:02,670 this will allow you to write 133 00:06:02,670 --> 00:06:07,390 multiple updates or inserts across multiple tables 134 00:06:07,390 --> 00:06:10,773 and then give you ability to roll back 135 00:06:10,773 --> 00:06:15,600 if any modification to any one table fails. 136 00:06:15,600 --> 00:06:16,433 Right? 137 00:06:16,433 --> 00:06:18,890 So that's a very powerful feature that was 138 00:06:18,890 --> 00:06:23,273 released fairly recently, again, here in late 2018. 139 00:06:24,580 --> 00:06:29,010 Now, taking a closer look at the data model within DynamoDB. 140 00:06:29,010 --> 00:06:30,360 Again, like we've talked about, 141 00:06:30,360 --> 00:06:32,320 we have a table. 142 00:06:32,320 --> 00:06:35,180 Now, in terms of data models in Amazon DynamoDB, 143 00:06:35,180 --> 00:06:36,550 taking a closer look here again, 144 00:06:36,550 --> 00:06:40,240 we've talked about how we have tables, right? 145 00:06:40,240 --> 00:06:43,810 And here in this example, we have a user's table 146 00:06:43,810 --> 00:06:47,063 and of course, this would be an item. 147 00:06:48,420 --> 00:06:50,120 And then each one of these things, 148 00:06:50,120 --> 00:06:52,920 we would have an attribute. 149 00:06:52,920 --> 00:06:54,340 A Zip attribute, 150 00:06:54,340 --> 00:06:55,940 a date of birth attribute 151 00:06:55,940 --> 00:06:58,140 and a name attribute. 152 00:06:58,140 --> 00:07:01,073 Now, because DynamoDB is schema-less, 153 00:07:02,330 --> 00:07:04,650 it's possible that each item here 154 00:07:04,650 --> 00:07:07,670 could have a completely different set of attributes. 155 00:07:07,670 --> 00:07:09,820 That is probably not necessarily 156 00:07:09,820 --> 00:07:11,300 the best for our application 157 00:07:11,300 --> 00:07:13,910 if our application needs something predictable. 158 00:07:13,910 --> 00:07:16,190 But as far as DynamoDB is concerned, 159 00:07:16,190 --> 00:07:17,680 it doesn't care, right? 160 00:07:17,680 --> 00:07:20,190 If you want to do that, you can. 161 00:07:20,190 --> 00:07:23,610 The only thing in this example that we have to do 162 00:07:23,610 --> 00:07:28,550 would be to ensure that all of our items 163 00:07:28,550 --> 00:07:31,783 have the name attribute. 164 00:07:32,880 --> 00:07:35,643 In this example, as a streamed value. 165 00:07:36,580 --> 00:07:37,890 Right, because that, 166 00:07:37,890 --> 00:07:40,453 in this example we've set as the primary key. 167 00:07:41,990 --> 00:07:44,070 Now, we have different options 168 00:07:44,070 --> 00:07:47,810 when it comes to primary keys in DynamoDB. 169 00:07:47,810 --> 00:07:48,980 Now here in this example, 170 00:07:48,980 --> 00:07:52,550 where the primary key is a partition key. 171 00:07:52,550 --> 00:07:55,520 You'll notice that it's just one value. 172 00:07:55,520 --> 00:07:57,890 It's only the name attribute. 173 00:07:57,890 --> 00:08:00,270 But in another table, 174 00:08:00,270 --> 00:08:04,010 we could also create a primary key 175 00:08:04,010 --> 00:08:06,830 as a composite, right? 176 00:08:06,830 --> 00:08:09,160 Remember that a composite key 177 00:08:09,160 --> 00:08:11,950 is the combination of two different attributes 178 00:08:11,950 --> 00:08:12,900 or two different fields. 179 00:08:12,900 --> 00:08:15,200 And it's the unique combination 180 00:08:15,200 --> 00:08:16,590 of those two things 181 00:08:17,440 --> 00:08:20,170 that make that primary key unique. 182 00:08:20,170 --> 00:08:23,310 And so, with DynamoDB, we have the ability to 183 00:08:24,720 --> 00:08:28,930 create a primary key that is the combination 184 00:08:28,930 --> 00:08:33,010 of a partition key and a sort key. 185 00:08:33,010 --> 00:08:34,560 So you'll see here, 186 00:08:34,560 --> 00:08:36,240 in the top table, 187 00:08:36,240 --> 00:08:39,620 jane.doe would have to be unique. 188 00:08:39,620 --> 00:08:42,053 But in this bottom table in Relationships, 189 00:08:43,060 --> 00:08:47,000 jane.doe is not unique but the combination of jane.doe 190 00:08:47,000 --> 00:08:51,580 and amy and the combination of jane.doe and bob.smith 191 00:08:51,580 --> 00:08:52,970 are each unique, right? 192 00:08:52,970 --> 00:08:55,490 So that's a composite key. 193 00:08:55,490 --> 00:08:58,750 And so the ability to do this 194 00:08:58,750 --> 00:09:02,650 or what this gives us is the ability to query 195 00:09:02,650 --> 00:09:05,710 this table and say well show me all of 196 00:09:07,160 --> 00:09:08,560 the records 197 00:09:08,560 --> 00:09:10,430 where name equals jane.doe. 198 00:09:10,430 --> 00:09:14,670 So that would give me all of jane.doe's friends. 199 00:09:14,670 --> 00:09:17,040 And then of course as the name suggests, 200 00:09:17,040 --> 00:09:18,700 the sort key here, 201 00:09:18,700 --> 00:09:20,160 as the sort key suggests, 202 00:09:20,160 --> 00:09:23,570 we can then use that friend attribute 203 00:09:23,570 --> 00:09:26,410 to sort that list in alphabetical order. 204 00:09:26,410 --> 00:09:28,160 And of course, we will take a closer look 205 00:09:28,160 --> 00:09:29,330 at some of these things 206 00:09:29,330 --> 00:09:30,680 as the course progresses. 207 00:09:30,680 --> 00:09:33,610 As we get into the demo and other things, right? 208 00:09:33,610 --> 00:09:36,510 So again, Amazon DynamoDB 209 00:09:36,510 --> 00:09:40,460 is Amazon's fully managed NoSQL data store. 210 00:09:40,460 --> 00:09:43,363 And we'll take a closer look at it as we move along.