- [Morgan] Let's talk some more about Amazon DynamoDB. At the most basic level, DynamoDB is a database. It's a serverless database, meaning you don't need to manage the underlying instances, or infrastructure powering it. With DynamoDB, you don't create a database with tables that relate to each other, like a relational database. Instead, you create standalone tables. A DynamoDB table is just a place where you can store and query your data. Data is organized into items, and items have attributes. If you have one item in your table, or two million items in your table, DynamoDB manages the underlying storage for you, and you don't need to worry about scaling the system up or down for storage. DynamoDB stores the data redundantly across Availability Zones, and mirrors the data across multiple drives for you, under the hood. This lessens the burden of operating a highly available database. DynamoDB, beyond being massively scalable, is also highly performant. DynamoDB has a millisecond response time, and when you have applications with potentially millions of users, like an online game, having scalability and reliable, lightning-fast response times is important. Now, DynamoDB isn't a normal database, in the sense that DynamoDB doesn't require a rigid schema or manage complex relationships or constraints. Relational databases work great for a lot of use cases, and have been the standard type of database historically. However, these types of rigid SQL databases can have performance and scaling issues when under stress. The rigid schema also makes it so that you cannot have any variation in the types of data that you store in a single table, so it might not be the best fit for a dataset that is a little bit less rigid and is being accessed at a very high rate. This is where non-relational databases like DynamoDB come in handy. Non-relational databases have flexible schemas. With DynamoDB, you can add or remove attributes from items in the table at any time, and not every item in the table has to have the same attributes. This is great for datasets that do have some natural variation from item to item. The types of queries you run on non-relational databases tend to be simpler, and focus on a collection of items from one table, not queries that span multiple tables. This, along with other factors, including the way the underlying system is designed, allows DynamoDB to be very quick in response time and highly scalable. So things to remember: DynamoDB is non-relational. It is purpose-built, meaning it has specific use cases, and it isn't the best fit for every single workload out there. Taking a look at our architecture, we modified it to be using DynamoDB. We are now going to need to create an employee's table for the app to write to and read from. We will create this DynamoDB table using the console, and you know what, let's call them Alana in here for this one. Hey Alana, can I get some help in here? - [Alana] Hey, y'all! - [Morgan] We changed our minds about using RDS, and decided to change it over to DynamoDB. It's only one table, and it's essentially a lookup table for the employees. How hard do you think it would be to make this change? - [Alana] Well, our app is actually designed to handle either RDS or DynamoDB as the backend database, so this won't take long at all. Here, I'll show you how. I'm in the console, and I'll go ahead and navigate to the DynamoDB service. From here, all you need to do is create a new table. Tables in DynamoDB require you to designate certain attributes as keys that make an item unique. We will select Employee ID as the unique identifier for the items in this table. So we'll call the table name Employees, and the primary key will be ID. Then we will just accept the defaults and create the table. Our app was coded to look for a table specifically called Employees, so this actually should all work now that the table was created. To test it out, let's head over to the website, hosted on EC2, and try to add a new employee. Click Add, and I'll go ahead and add myself. My name is Alana Layton. My location is Seattle. My job is a Cloud Technologist, and then, let's see, I'm a Mac user. We'll say I'm employee of the month. Sorry, Morgan. And I am also a Seattle fan. Then we'll go ahead and add my picture, click Open, and then click Save. All right, so now I'm added on the website. Now let's go back into DynamoDB and refresh the page. Then we'll click on Items to view all the items in the table, and there you can see my item. It's really that simple for a lookup table like this one. Back to you, Morgan. - [Morgan] Well then, that was easy. Nice. Now not every use case is this simple. In the readings after this video, there will be more information about how DynamoDB works, use cases, how to create indexes, some information on table design, and links to further learning materials on DynamoDB.
