This Total Seminars course covers the exam certification topics. For information on additional study resources—including practice tests, lab simulations, books, and discounted exam vouchers—visit totalsem.com/linkedin. LinkedIn Learning members receive special pricing.
This course was created by Total Seminars. We are pleased to offer this training in our library.
- Relational databases
- High-availability solutions in AWS
- Database security
- Creating DynamoDB tables
- Configuring and backing up AWS RDS
- Restoring a database
- Database monitoring in AWS
Skill Level Intermediate
- We're moving on now to the chapter on database understanding. Our goal here is to understand or comprehend the database concepts, so that when we're architecting an AWS solution that requires database access, we can choose the right databases for our needs, and make sure they're implemented in the right way. This begins by understanding the different types of databases that we can employ within AWS. Let's start right there. First of all, you can have hosted services databases. So these are databases that are actually hosted and the service is managed by AWS. You don't have to do all the work of building out the operating system and so forth. You just have to build a database. This would include relational databases and non-relational, or NoSQL databases. The relational databases are many and the NoSQL database is called DynamoDB. We can also do custom instance installs. With custom instance installs, we're really accomplishing something we call BYOL, bring your own license. So what we're going to do is actually build out an instance and use it for our database. Let's talk first of all about the hosted services in a little more detail. The hosted services for relational databases fall under the umbrella of what's called AWS Relational Database Services. This is the set of services that give you relational database capabilities from a managed services or hosted services perspective. This includes Aurora with both MySQL and PostgreSQL. It includes Oracle, Microsoft SQL Server, MySQL, and also PostgreSQL by itself, and MariaDB. All of these are in that relational database category. And we'll understand a little bit more about relational databases as we go along. When it comes to custom instances, the basic process you employ is to first of all, start an instance with the required operating system for whatever database you want to run. So you could either start from scratch and launch an instance running Linux or Windows, and then manually install the database system, or you can select an AMI, an Amazon Machine Image that already has the database as part of that AMI, and simply launch that instance. Once you've done that, then you can actually create the database. So you have two choices. Start an instance that is an AMI, that already has the database service in it, or start an instance without it and then install the database service, and create the database. Now big question people often ask is if I go this route and I launch an instance that doesn't have the database application installed, how do I get it installed? The answer is that you can install it in a couple of ways. One, many of the database providers such as Microsoft and Oracle will give you downloadable executables you can use to install the database. So you could download it into your instance and then install it from there. The other option would be to use an ISO image. And you could simply place your ISO image in an S3 bucket, grant access to that S3 bucket to the EC2 instance, and then mount that ISO image and install it that way. So there are few different ways you could accomplish it. But the end goal is the same, to get that database system installed on top of your operating system, so you can start creating databases. Now a general concept that's important to understand is the concept of flat file versus relational databases. Flat file databases are really the oldest that we have. They were the original databases if you will. They basically have one line per record. And that record may be filled with repeated information and redundancies, and it may not be the most optimized record, but it's the way we did it with flat file databases. It doesn't contain multiple tables. So you can think of it kind of like an Excel spreadsheet with just one worksheet, and everything's on that one worksheet. That's kind of the structure of a flat file database. A relational database is different. We store portions of the data in designated tables. For example, the sample that's often given is customers in one table, products in another table, orders in another table, and so forth. So we split things across into different tables. These tables then are related to each other based on unique identifiers. So the customer table might be related to the orders table, in that the customer placed an order. And the orders table might be related to the products table, in that the customer placed an order for the product. So this is the general concept of a relational database. In the next episode, we'll talk about the concepts of relational databases in more detail. Now the NoSQL database is really kind of a modern thing, really coming on the scene in the late 90s. It's not based on SQL or relational design theory. Now I'm using a term here I need to define for you and that's SQL, if you're not familiar with it. SQL is a language that is used to talk to databases and it's a common structural model of databases. So they're two ways to think about the SQL language. If we say it's an SQL database, we mean it's a database that supports the SQL language. And guess what, those databases are sometimes also called SQL databases. So SQL is just a language defined by ANSI that is used to talk to databases. Now the design of NoSQL supports fast transactions. It's all about speeding things up, making it as quick as possible to both read and write. DynamoDB is an example of one. And actually what happened was long time ago, back in 2004, Amazon itself you know, the store website where you go to buy stuff, had a real problem keeping up with the load in the 2004 holiday season around Christmas time. And so to resolve the issue, they said "We've got to come up with a better database." And they built DynamoDB for that reason. And then of course, eventually it made its way into AWS for us. So it's now part of the AWS system and you could use the DynamoDB database. We also have the concept in database world of data warehouses. Data warehouses, as the name implies, are large, central repositories for data. So a data warehouse, think about it like the warehouse you put a bunch of your data in, just like you put a bunch of stuff in warehouses. The data is aggregated usually from one or more sources. So we build a data warehouse by pulling data in from different sources, aggregating it together, and getting it into that one place. The reason we build them is usually because we want to do online analytical processing, or OLAP, which means we're doing business intelligence, big data, working on decision support, these kinds of things that require massive amounts of data to be centralized, instead of distributed. Within AWS, Redshift is your go-to solution for a data warehouse database. Well as you can see, there are a lot of database options when it comes to implementing databases in AWS. In this episode, we explored the fundamental concepts of the different databases, and looked at some of the database types that are provided in AWS. In the next episode, I want to go a little deeper into relational databases because remember, the vast majority of databases that are hosted services or manage services databases in AWS are relational databases. So we certainly need to understand this concept a little better.