1. Introduction to DynamoDB
So what is DynamoDB? Well, it’s a fast and flexible NoSQL database service for all applications that need consistent single-digit millisecond latency at any scale. It’s a fully managed database, and it supports both document and key-value data models. Its flexible data model and reliable performance make it a great fit for mobile web gaming, ad tech, Iota, and many other applications. So essentially, DynamoDB is an Amazon NoSQL database in the cloud, and it’s used by enterprises all throughout the world. It’s pretty much one of the most popular database technologies on Amazon, apart from maybe RDS. So almost everyone uses DynamoDB. Okay, so what makes DynamoDB so popular around the world? Well, it’s stored on SSD storage, so it’s super-fast, and it’s spread across three geographically distinct data centers. Technically, there aren’t three different availability zones. It does say in the FAQs and the documentation that there are geographically distinct data centers.
I never understood what the distinction was, but apparently it’s not availability zones. But in any case, it is stored in three different locations. So what happens when you write a piece of data to a DynamoDB table? What is going to be written in one location first, and then replicated to the other two locations. So how do you maintain data consistency? Well, there are two different data consistency models. You’ve got the eventual consistent read model, and this basically says that consistency across all copies of data is usually reached within a second. Repeating a read after a short time should return the updated data. And this gives you the best reading performance. And then we have the strongly consistent readings. And this is basically going to guarantee you that when you go and read some data, the result that reflects that is going to reflect all rights that received a successful response prior to the read.
So the rule of thumb is that if your application can wait up to a second for the data to basically spread out across all the different data centers, then you want eventual consistent reads. If your application needs that data to always be consistent across the three facilities, then you want strongly consistent reads. So that’s the key difference between the two. Eventual consistency means that the data will be updated within a second. So long as you can wait a second for all copies of that data to be in sync, then you should be fine. If you need that data to be updated and in sync all the time, you’ll want strongly consistent reads. You will not get the same reading performance from strongly consistent readers as you will from eventual consistency. So just remember that going into the exam. Okay, so let’s talk about what makes up a DynamoDB environment. So we’ll start with tables.
So basically, you create a new DynamoDB table, which you load data into, and then inside your table, you have items. So I’d like you to think of a traditional relational database. An item is basically just a row of data in the table. So let’s say you’ve got a table that’s about students. Your individual students would be items, and then you would have attributes. Consider it to be similar to a data column within a table. So an attribute might be the student’s first name. It might be their surname. It might be their address, their phone number, or what course they’re taking.
So we’ve got a little diagram here. We’ve got our students table, and inside our students table, we’ve got some JSONs. So we have unique identification 1975 and 1976. So this is Alan Brown and Riyadh Romanov. And so Alan Brown is item number one, and Riyadh Romanov is item number two. and then you can see the different attributes. So we always start with a primary key, and that primary key just uniquely identifies our student. So it could be your student ID. And then we have things like their first name, their surname, their phone number, et cetera. You’ll notice that we have some nested attributes with the address for Riyadh.
So we’ve got an address, and then within that, we’re nesting the number 15, and then the street, which is River Road. And you can actually have DynamoDB support nesting up to 35 different nests. So that’s quite interesting. You can actually have 35 levels of nesting within a DynamoDB table currently. So, in terms of pricing, the way DynamoDB pricing works is that it’s based on a couple of things. So we’ll start with provisioning throughput capacity. So this is basically what you need to figure out: your write throughput and your read throughput. So you’re being charged in terms of your right throughput, which is currently zero. $65 per hour for every ten units of write throughput. And with read throughput, you’ll charge zero points per hour for every 50 units of read throughput. So you’re also charged by how much data you’re storing on DynamoDB. So the first 25 gigabytes of data that you store in DynamoDB are free. And then after that, your storage costs are twenty-five cents per gigabyte per month thereafter. Okay? So the best way to understand DynamoDB pricing is to go through an example.
So let’s assume that our application needs to perform a million writes and a million reads per day while storing 28 gigabytes of data. The first thing you need to do is calculate how many writes and reads per second you’re going to need. So 1 million evenly distributed writers and readers is the equivalent of 1 million. Divide by 24 hours, divide by 60 for the number of minutes in the day, divide by 60 seconds, and then that’s equal to 11.6 words per second. So if you’re going to spread those reads and those writes out across the entire day, you’re going to be getting 11.6 reads and writes per second. So the DynamoDB write capacity unit can handle one write per second. So you take that 11.6, and you’re going to round it up to twelve. So you’re going to need twelve large-capacity units throughout the day. For the appropriate capacity throughput, you are now charged $65 for every ten units. So let’s break that down and move it to a per-unit basis, and then we can calculate how much it’s going to cost us.
So zero point 65 divided by ten gives it to us on a per-unit basis. We then multiply that by twelve for the number of right-capacity units that we need, and we then multiply that by 24 because this is on a per-hour basis, so it’s going to cost us basically $0.18 or 18 $0.1872 per day. Likewise, to do 1 million strongly consistent reads per day, we’re going to need twelve capacity units, and we’re basically going to be charged the same amount. For every 50 units, 0 points equals $65. So we break that down on a unit-by-unit basis. So it’s $0.0065 divided by 50, multiplied by twelve, multiplied by 24. That comes to about three cents per day, or zero points $374 per day. Then we had to consider our storage costs. They are thus 25 cents per gigabyte per month. So let’s assume our database is 28 gigabytes. We’re going to get the first 25 gigs for free, and we’re only going to pay for the three gigs of storage thereafter. So it will be 75 cents per month. So adding it all up, the total cost is going to be $0.1872 per day plus zero points 34 per day. So that’s our right capacity units and our read capacity units, plus our storage for the month. And that’s basically going to cost us. Host this on DynamoDB for the month. And that’s a database that can take a million reads and a million writes per day. Now that’s pretty impressive. It’s even more impressive when you look at the free tier and realise that we actually get 25 high-capacity units for free.
We get 25 write-capacity units for free. So in reality, if we didn’t have any other Dynamo DB tables on here and we were still within our free tier eligibility period, then you’d actually only be paying seventy-five cents. Now, we haven’t mentioned DynamoDB streams in this lecture at all. That has its own cost, and I don’t want to overcomplicate things. So we’re going to talk about DynamoDB streams in another lecture. So that’s really it for this lecture, guys. I know it’s at a very high level at this stage. So what’s the easiest way to learn DynamoDB? Well, it’s to get our hands dirty and to start our first lab. So in the next lab, what we’re going to do is create a role in IAM that will give us full access to DynamoDB. We’re then going to assign that role to an EC2 instance, and we’re going to go into that EC2 instance and launch it with that role. We’re going to run a bootstrapping script, which I’ve supplied with the course, and that’s going to basically set up our environment. We’re then going to SSH into that EC2 instance and install the PHP SDKs, and then we are going to use some scripts to create some DynamoDB tables and to load DynamoDB data into those tables. So if you’ve got the time, please join me for the next extra. Thank you.
2. Creating a DynamoDB Table
So the very first thing we need to do after we’ve logged into the console is go in and create our role. So we go over to Identity Access Management, and we click on Roles, and we’re going to create a new role. Now, as you can see here from one of the last lectures, we’ve got my S-3 access, and that gave us full access to S-3 when we assigned that role to an EC-2 instance. I’ve also got another role here called DynamoDB S-3 Three super user. And this is what we do as a role to communicate with both DynamoDB and S3 at the same time. So what we’re going to do now is just create a DynamoDB role for you. So we go in and hit “create a new role.” We’re going to call this DynamoDB. DynamoDB, go ahead and hit next. And we’re going to use our service role for Amazon EC Two. Take note, however, that we have a role for identity provider Access down here. We will be covering that in more detail in the next lecture in this section of the course.
So I’m just going to go ahead and hit Eco, and then I’m going to type in here. If you can’t see it, just type in DynamoDB. You see, there are two of them: DynamoDB full access and DynamoDB full access with data pipelines. So I want DynamoDB. Full access. Just go ahead and select that one, and then go ahead and hit next and create the role. Now that we’ve got the role created, let’s browse on over to EC 2. Do take a note of what region you’re in before we do that. Actually, though, let’s just go over to DynamoDB, and you can see there is nothing there right now. So it’s the typical DynamoDB splash screen. So what we’re going to do is go over to EC2 and create a new instance. So, launch an instance here, and then cross here to Amazon Linux, AMI. We’ll just use a T2-micro, and I’m going to assign the DynamoDB role to it.
So, with DynamoDB now down in the advanced details, I want you to cut and paste a bootstrap script that I’ve got in the resources section of this course. So I’ve got it saved on my clipboard. I’m just going to paste it in, and essentially, if we just have a quick look at what it does, So we’ve got our shebang with our path to our interpreter. So get rid of Bash. We’re then running a Yum update. We’re then installing the newest version of Apache and the newest version of PHP. We’re installing Git, and then we’re starting the Apache service. We’re making sure that if our EC2 instance reboots, the Apache service will restart. We’re then going to the varw HTML directory. We’re creating a little test page in PHP that runs the PHP information, and we’re calling it Test PHP. And then we’re cloning this repository, so it’s https GitHub comiclouddynamodb. So go ahead and hit next to add our storage and next to tag our instance. And we’ll call this instance DynamoDB and press the next button. just going to use an existing security group. So my web DMZ, which has got HTTP and SSH open to the world, is going to go ahead and hit launch, and I’m going to select an existing key pair, my EC-2 key. So that’s it; it’s been entered and launched.
So I’m just going to pause the video now while we wait for a public IP address to be issued to this EC2 instance. And then we’re going to log in and install the PHP SDK. Okay, so my EC2 instance has been provisioned, and I’ve got a public IP address, which I’m just going to copy. And now I’m going to go over to my terminal window. Okay, so I’m in my terminal window, so I’m going to SSH EC-2 hyphenuser at, and then the public IP address, then minus i, and then the name of my key, which is my EC two.You can also probably tab across key PM. So I’m going to hit enter, and it’s going to add this to the fingerprints. And so we arrive at the list of known hosts. And now I’m just going to elevate my privileges to root. And I’ll go to my CDVdubdub HTML directory to fix any typos. And I’m going to LS, and in here we can see my DynamoDB directory, which we’ve cloned from Git, and we can also see my test PHP page. So I’m just going to clear the screen. Now, if you remember from the previous three sections where we were installing the PHP SDK, we had to install these two commands. So I’m just going to go ahead and copy them and run them in this directory. So the first thing we need to do is get composer, which has already been done. And now I’m going to install the PHP SDK. And it does say running this at root or as the superuser is highly discouraged, so don’t do this in a production environment. We’re just doing this as part of the lab. So it’s going ahead and running Composer and installing everything. And there we go. So I’m going to clear the screen again. Okay, so the first thing I’m going to do is go into my DynamoDB directory, DynamoDB. And here you’ll see two files. We’ve got the create tables file, and we’ve got the upload data file. And these are two PHP files. So it’s pretty simple.
The create tables command creates four DynamoDB tables, and then the upload data command uploads data into those. So if we go into the createtables file, then nano createtables PHP So, as you’ll see here, the code is actually provided by AWS. I’ve done a few tweaks, but you can get it from the latest developers guide on the DynamoDB section of the AWS website. If we go down here, the thing I need to show you that’s most important is where to set your regions. So you can set your region here. I’ve set this for EU West 1, and this is where it’s going to create our DynamoDB tables. You now change that to your desired region. If you want a list of regions, I’ve just dumped the URL in here. So it’s Docs, AWS, Amazon.com, General Grade, HTML, and that will give you all your different regions. Make sure to edit the region you’re in. So, if you’re in the east or west, simply change it. Just make sure you update the code to the region that best suits you, okay?
So, once you’ve completed that, exit it, and you’re basically ready to go. So what we need to do is go over to our web browser, and just to see this work in my web browser right now on the console, I’m going to DynamoDB, and you can see here that it is just an empty splash screen. And so what I’m going to do now is just go across to another console window that I’ve got open, EC 2, and just get my public IP address again. So it’s 50 216, 56 158. So all you have to do now is open a new tab, type this in, then go forward slash, type in DynamoDB, then forward slash, and it’s createtables PHP, and hit enter. And now it’s going to take a little while for this to load. And what it’s essentially doing is running a PHP script that is going to create four DynamoDB tables. It should take about 30 seconds or so while it goes in and creates these tables. And what we’re going to do is we’re going to refresh the DynamoDB screen, and hopefully we will be able to see these tables being created. So there we go. It says “creating table product catalogues,” “creating table forums,” “creating table threads,” et cetera. So it’s all done, and it’s all been successfully created. So if we tap across to here and just hit the refresh button, you can see the splash screen has now changed. So it’s no longer the standard splash screen. If I click over here and go to tables, I can see that I’ve got four tables, and if I actually click into them, if I go into the product catalog, I can see right now that it doesn’t have any items in it. It’s basically empty.
All it’s got is an ID. So the next thing we want to do is load data into these tables. So we go across here and we change the URL to upload data in PHP. So we type upload data into PHP and press enter. And again, this can take a little bit of time. Not too long, though. There we go. Adding information to the product catalogue Done. Done. So if we go back over to our DynamoDB table and, again, refresh, we go into the product catalogue and go into items. We can now see that it’s been populated with different items. So we’ve got our ID column here. We’ve got our price. We know what the product category is. Is it a book? Is it a bicycle? We’ve got the title, and then we’ve got some fields that are blank. And then, essentially, we’ve got other columns that are only used by some rows and some columns that are not being used by other rows, et cetera. So it’s gone out and populated our DynamoDB table. So now that we’ve got populated tables, we can start to learn more about DynamoDB and how to go in and manipulate it. And we’re going to go do that in the next few lectures of the course. So that’s it for this lecture, guys. Hopefully, everything has worked out for you. You haven’t had any issues. Please let me know if you have. But if not, feel free to move on to the next section. Of course. Thank you.
3. DynamoDB Indexes
Okay, so let’s start by talking about primary keys. Now, there are different types of primary keys. You know, I was a PHP developer back in the day, and we used to always use unique IDs. So when somebody signed up for my site, they would have a unique ID. It would auto-increment, and we’d start at, say, 100 and then start incrementing. So, as you know, one more person signed up, so it would be 101, 102, etc. Um, so with DynamoDB, there are two types of primary keys available. So there’s the first, which is the most common. And this is where you’ve got a single attribute. You’ve just got a single piece of data. So think of something like a unique ID. This is known as the partition key. In 2015, it was actually called the hash key. And so if you read some of the documentation, sometimes it will say partition key, sometimes it will say hash key. It’s exactly the same thing. I don’t know if they’ve updated the exam. So if you do see a hash key there, just think partition key.
So your partition key is basically composed of one attribute. It makes up one single piece of data. So it would be like the user ID. You couldn’t have nested data in here; you couldn’t have, like, an address and then your street name and then your postcode, et cetera. It has to be composed of one attribute. So this is the most common one, and it’s called a partition key when you’ve got multiple attributes. So this is basically called “composite.” So think of something like a unique ID and a date range. and it consists of two attributes. So think of, like, your unique ID and then the date that a user signed up. So you’re using these two pieces of data to create your key. This is referred to as a partition key and a sort key. So the partition key would be your user ID, and the sort key would be something by which you sort from.As an example, consider the word date. And the sort key used to be called a range key.
So if you see a range key in the exam, think of a sort key. If you see a hash key in the exam, it’s a partition key. So basically, a composite primary key is made up of a partition key and a sort key. It’s made up of an item with a single attribute, such as the user ID. And it’s also made up of the sort key, which is typically going to be a range. So it’s going to be a range of dates from when they first signed up. So it’s pretty simple, but it does sound quite complicated. We will go in after a few slides and go into DynamoDB and look at the data that we’ve created in the last lecture. But it’s just really important to remember the two key terms, which are a partition key (just think of a partition key as an ID) and your sort key. And your sort key is always going to be something that’s going to be sorted. So it’s going to be a range of data. And the most common sort key is going to be the date that a user signed up or the date that a user did something. So let’s talk about why this is important. Why is it important to have a single attribute or composite attribute? Well, it’s all about the way DynamoDB actually stores the data.
So with our partition key, this is our primary key, where we’ve just got a single attribute. DynamoDB uses the partition key value as an input to an internal hash function. So basically, it passes the value to an internal function that turns out a hash, and the output from this hash function determines the partition. And a partition is simply the physical location in which the data is stored. Now, it’s important to know that no two items in a table can have the same partition key value if you’re just using your partition key as your primary key. Okay, so that’s really important. So you can’t have the same unique ID. if you’re only using a single attribute or if you’re just using a partition key. Now, let’s talk about another scenario. Maybe you want to use that unique ID multiple times in a single table. Maybe it’s a forum and somebody is posting to the forum. So they’ve got their unique ID, and every time they create a post, it creates a new row in DynamoDB. So how do we do that? Well, we’re going to use composite keys, so we’re going to use a partition key and a sort key. So the partition key would be their unique ID, and the sort key would be the date that they posted or the timestamp in which they’re posting that particular message in a forum. So in this case, DynamoDB uses the partition key value as an input to an internal hash function, just like it did in the last one. And the output from this hash function is going to again determine where this data is going to be located.
So it determines the partition. It’s just the physical location where the data is stored. But in this case, the two items can have the same partition key, but they must have a different sort key. So a user in a forum cannot post two messages at the same nanosecond or millisecond. That would create a clash. So the two items can definitely have the same partition key, which would be like the unique ID, but the timestamp has to be different. So the sort key has to be different. And all items with the same partition key are going to be stored together in sorted order by the sort key value. So essentially, all items with the same unique ID would be stored together. And then that data is actually sorted by a timestamp. So it’s sorted in either a sending order or a descending order, depending on how it’s configured. But it’s going to be sorted by the key value, so that’s quite important to remember. So think of just two tables. One table might be your master user table. So that would just have a single primary key, and basically you just need a partition key.
So it would be your user ID, and then it might contain their first name, their surname, their email address, et cetera. Then your second table might be a table about a particular thread in a forum. And that table is going to have two primary keys. Essentially, it’s going to have a partition key and a sort key. The partition key is the user’s ID, and the sort key is the date that the user is posting to that particular thread in a forum. And when you think of it as a forum, it makes a lot more sense. So, moving on to indexes, and this is also a really key part of the exam, you’re going to need to know the two different types of indexes and what can be created after you create a table and what needs to be created when you create a table.
So we’ll start with a local secondary index, and this is basically where you’ve got the same partition key but a different sort key, so you can create a local secondary index. Let’s go back to our example of a forum. So we’ve got the same partition key, which is always going to be the user’s ID, and a different sort key. So the sort key might not be available when the user is posting to a particular thread. It’d be a totally different sort key. It might be something like when they last logged on, for example. So you can organise the data this way or organise it the index-style way, and that’s called a local secondary index. Now, it’s important to remember that a local secondary index can only be created when you’re creating a table. It cannot be removed or modified later. So you have to plan in advance if you’re going to have local secondary indexes. We then have global secondary indexes. Now, these are pretty cool because you can have a different partition key and a different sort key. So you might have the partition key be the user’s email address as opposed to their unique ID, and the different sort key might be when they last logged in rather than when they’re posting to a particular thread. Now, global secondary indexes can be created at table creation or they can be added later. So again, going into the exam, remember the two different indexes.
So the local secondary index has the same partition key but a different sort key, and it can only be created when creating a table. And then a global secondary index has a different partition key and a different sort key. And it can be created during table creation or it can be added later, whereas a local secondary index cannot be added later. and we’ll see that in a few minutes in the lab. Okay, so let’s move on to DynamoDB streams. This is actually fairly new, and it may not feature in the exam. I’m sure they’re going to add some questions to it, so it’s just important to know what it is. Basically, it’s pretty simple. It’s used to capture any kind of modification to the DynamoDB tables. And the changes can be one of three types. So if a new item is added to the table, the stream captures an image of the entire item, including all of its attributes. So it basically takes, let’s say, a snapshot of the item and all of the attributes that consist of that item. If an item is updated, the stream captures the before and after images of any attributes that were modified in the item. So it basically allows you to track changes to the table. And then, if an item is deleted from the table, the string catches an image of the entire item before it was deleted. So let’s again use a practical example of DynamoDBstreams, and let’s have a look at our user. So this is our user, Alan Brown. He’s signed up for our website, and so when he signed up, he hit the submit button. We’ve generated a customer ID for him. We’ve captured his first name, his surname, and then the email address. So the email address is alan [email protected], so this is then loaded up into DynamoDB. Now, DynamoDB streams will immediately recognise this newly created data and store it in DynamoDB streams for 24 hours. Now, for DynamoDB streams, it’s a maximum of 24 hours. It’s not a safe place to store persistent data. It’s not like SQL Server or DynamoDB itself. It’s literally going to store these changes for 24 hours. So you have 24 hours to do something with that data or it will be lost. Now, once you have stored it there, you can actually configure what’s called a trigger. This will call a lambda function. And you can write a lambda function to do any kind of thing with this data.
So you might write a lambda function to replicate this new data to a replica table that is in another region for disaster recovery. So Lambda sees that you’ve got a new user signed up to your site. Basically, it takes this new user data and adds it to an exact replica table of your DynamoDB table, but in another region. So you’re prepared for a disaster. Lambda could then also generate an email and send it, or basically use a simple email service to fire off an email to our user, basically saying, “Congratulations!” or “Thank you!” for joining our website. So this is the way DynamoDB streams work. Essentially, all it’s doing is capturing changes to DynamoDB stores. It was in DynamoDB streams for 24 hours. It can then trigger lambda functions, and your lambda functions can do all kinds of different things with that data. Okay, so to put this all together, let’s go into the AWS console and go over to DynamoDB. And if you have successfully completed the last lab, if you click here on tables, you should now see four newly created tables.
So we’ve got a forum, we’ve got a product catalog, we’ve got replies, and we’ve got threads. If we look over here, we can see the status. So right now, our tables are active. We can see our partition key. So our product catalogue and our forum only have a single partition key, whereas replies and threads have both a partition key as well as a sort key. So you can see here we’ve got our reply date and time, and here we’ve got a sort key for our subject in our threads. We can see the number of indexes here, and we can see our read and write capacity units down here. So if we go over to the product catalogue and have a quick look, we can see an overview. So we can see any recent alerts for which CloudWatch alarms have been triggered for this table. So Cloud Watch can monitor DynamoDB, and you can set alarms similar to how you do in EC Two.You can see different streams here. So we don’t have streaming enabled on this particular product. If we wanted to go in, we could enable streams. We’ve got different view types, so we’ve got keys for only new images, old images, and new and old images. I’m not going to enable streams. We’re going to keep this quite quick. And if we go across here, we can see the different items.
So these are the different items in our catalog. So here we’ve got our partition key, which is basically just our item ID number. And you’ll notice that none of these numbers are identical. They are all distinct. And because of this, they’re actually all going to be stored in different areas within DynamoDB. Then we have our price. We have our product categories. So is it a bicycle? Is it a book, et cetera? We then got our title; we’ve got our bicycle type, which would only be used for bicycles. It wouldn’t be used for books, for example; it would have our brand color, et cetera. So you can actually go in. And if we create a new item, I’m going to give it a unique idea of three, four, three. And I’m going to basically append a number below it. So this might be the price. Now. I’m going to create a new price, and it’s going to be the price in, let’s say, sterling. So there we go. I’ve got the pound sign, and then it’s going to ask us to enter an attribute value. So I’m going to say that this is £450. Because DynamoDB is not a sequel, It is a list of schema. I can do this, and it will create an entirely new column.
So if I go through and just rescan this table, and we’ll learn about what scans are in the next lecture, you can see it’s created a new column, which is the price in pounds. So you can go through and do that. If you want to edit an individual item, you can click in here because those are blank. Because the other columns are blank, it’s not going to show up, but you can add them in. So if we go over to like 205, for example, it’s going to start filling the columns and the data in there, so you can go through and edit it. Now, something quite key to remember for the exam is that you can export to a CSV. You can simply export in this manner. And that’s exported every single item in my table to a CSV file, which has just been saved on my desktop. You can also export individual items. We continue on up here. We can take a look at our metrics. So this will give us some Cloud Watchmetrics, which basically track our read capacity units, our write capacity units, et cetera. And you can go in here and basically go to Actions. So let’s say we’re starting to max out our read capacity or our write capacity. We can set alarms that would alert us about that, but we can actually go over here to capacity and change this on the fly.
So I can change this up to 20. I can change this up to 10. It’s going to give me an estimated cost per month, and I can go ahead and hit save. Now, this will actually change the status of my table. So if I come back here, it will say “updating.” It’s important to remember, though, that that table is still available, so you can still read from and write to it. That’s why DynamoDB is known as “push button scalability,” because you can literally scale your database with the push of a button to handle additional load. So it’s great for things like Black Friday, for example. If your database is getting absolutely hammered, you can scale it really, really quickly. Whereas with things like RDS, you’re going to have some downtime, depending on how you architect the solution. So that’s going to go ahead and be updated. Oh, there we go; it’s already finished. So that was quite quick. And if we go ahead over here to the indexes, we can see there are no indexes in this one. Currently. We go over to reply, and we’ll see the index type is LSI, so that’s our local secondary index. Now, remember what I said: you can only create a local secondary index at the time of table creation, and you can’t modify or delete it. So you can see here that I can’t hit the delete index.
So this has to be created when you first create the table. You can have up to five local secondary indexes and five global secondary indexes per table. So if I go here, I can create a new global secondary index, and you can use an existing primary key or you can create a primary key. So I could just type in “cloud gurus” over here, and then I could also add a sort key if I wanted for it, and then that again could be something completely new; we could call it “Datecloud Gurus” or, let’s say, we’re still going by a number. So we say item number; go ahead and hit number, and we’ll leave the rest alone. Go ahead and create the index. Now, I just invented those fields, and what it’s actually going to do is update this replytable with new attributes, as we can see now that it’s actually just changed its status to “active.” So we’ve got a new partition key, which is mycloudgurus, and it’s going to be a string. Then we’ve got a new sort key, which is the item number, and I can actually go in here because there are no current items with those values. I can go in here and just add, so we can go in here and go append and add strings.
So this is cloud gurus, and I can write “hello” and then the item number. Again, I can append, and this time it’s going to be a number. We’ll call it an item number, and then we’ll just put a fictitious item number in here. Now, as soon as I update that row, you can see that the new attributes have been added. So we’ve got cloud gurus and an item number, and we’ve built a global secondary index of this. So the partition key and the sort key are always going to be different from the main primary key. So the main primary key in this one is going to be the ID you see in the partition key. So for the global secondary index, it’s important to remember that your partition key and your sort key are different, and you can add this at any time. For the local secondary index, you’re always going to have the same partition key but a different sort key.
And a local secondary index can only be added when you’re creating the table; you cannot delete it. See here, it doesn’t give me the option to delete, whereas it does give me the option to delete this index now, so go ahead and hit delete. Okay, let’s move on to triggers quickly. Triggers are basically what we talked about earlier with DynamoDB triggers. So we are basically connecting a DynamoDB stream to a lambda function. So if an item in the table is modified, a new stream record is written, which in turn triggers the lambda function and causes it to execute. So it might be that a new user signed up, and we need to both replicate that new user’s data to a DynamoDB table in another region for disaster recovery. And then, at the same time, we want to send that new user a welcome email. So that’s where we would configure it all here. And then finally, we have access control.
This is pretty cool. I’m making a new course right now that teaches you how to develop iOS apps and use AWS services on the back end. And we actually get into this in a fair bit of detail. I’ll let you know when that course is out. But basically, in here, you can create fine-grained access control for web identity providers. So you could say, “Okay, I’ve got a Facebook app that’s going to be connecting to this DynamoDB table.” I want it to be able to do queries to get an item, to put an item, and maybe batch get items and batch write items. But we don’t want it to be able to delete items. So we go ahead and hit “Create policy,” and that’s going to create a policy document. Then we simply click here. It gives you instructions on how to implement this policy. So you’re basically going into items, and you’re creating a new role. So that’s really it for this lecture, guys. In the next lecture, we’re going to discuss the difference between a scan and a query operation, which is quite key to know for the exam. But if you have any questions, please let me know. If not, feel free to move on to the next lecture. Thank you.
