The course is part of these learning paths
AWS NoSQL databases
AWS Relational Databases
This course will provide you with an introduction to the cloud database services offered by AWS. In this course we will first we explore the fundamentals of cloud databases, outline the cloud databases provided by AWS before exploring how to get started selecting and using the AWS Database Services.
This course suits anyone interested in learning more about the database services offered by AWS.
The course is an introductory level course so there are no specific database skills or experiences required as a pre-requisite. Having a basic understanding of cloud computing will help you gain the most from this course. I recommend completing “what is cloud computing” first if you are new to cloud computing.
On completing this course you will have an understanding of the different types of database services available to you within the AWS cloud platform. You will be able to recognize and explain the various database services offered by AWS, and be able to identify and select which database service might suit a specific use case or requirement.
First we learn to recognize and explain the basics of a cloud database service.
We then learn to recognize and explain the differences between non-relational and relational databases before taking a high level pass over the family of AWS database services available.
We then dive in the Non Relational Databases - Amazon DynamoDB - Amazon Elasticache - and Amazon Neptune exploring use cases for when we might want to use a non-relational database service.
Next we dive in amazon RDS - the AWS Relational Database Service, exploring the database services provided by RDS. We then examine the services and their various use cases in the context of a scenario.
The Basics - What is a Cloud Database?
Overview of the AWS Database Services
AWS Non Relational Databases
- Amazon DynamoDB
- Amazon Elasticache
- Amazon Neptune
AWS Relational Database Service
- The RDS Service
- MySQL for RDS
- Microsoft SQL Server for RDS
- Oracle for RDS
- MariaDB for RDS
- PostGresSQL for RDS
- Amazon Aurora for RDS
If you have thoughts or suggestions for this course, please contact Cloud Academy at firstname.lastname@example.org.
- [Instructor] Hello, and welcome back. Now let's explore the AWS non-relational databases in depth, starting with Amazon DynamoDB. Now Amazon DynamoDB is a cloud native database, and it's designed for managing high volumes of records and transactions, without you needing to provision capacity up front. DynamoDB is a fully managed service, it's simplicity, scalability, and speed has made it the go to database for online services that deal with high volumes of internet-based transactions. DynamoDB supports both document and key store object types, big point, what that means is it can support multiple data types at the same time, without you needing to define a new schema or field type. That makes it a good choice if you need a database that can keep growing to meet demand with many different types of objects stored in it. DynamoDB runs as a web service, which we provision from the AWS console, or via API. AWS also provides a downloadable version of DynamoDB that you can run locally on your computer or server. The downloadable version lets you write and test applications locally without accessing the DynamoDB web service.
So this might be a great fit for our claims management system, it makes it accessible and usable for developers. DynamoDB supports encryption at rest, so it can meet many compliance and security requirements. So to summarize, DynamoDB is speed and performance. If we need to scale something up really quickly, we're not quite sure what type of information we're going to be collecting, that we just need to have a flexible service, then DynamoDB is a fantastic fit. The next in the family of non-relational databases is Amazon ElastiCache. Now Amazon ElastiCache is a managed data cache service built from the open source Redis and Memcached database engines, as a managed service, Amazon ElastiCache can improve your application performance by providing a frontline cache to respond to read requests made to an application or to a database. Let's just delve into the differences between a cache and a permanent data store so we are clear on the distinctions. The purpose of a cache is generally to act as a fast access copy of data that is being read a lot. So lots of read requests. A cache will hold a copy of frequently requested information as a way to reduce load on other parts of a service or application. Now imagine we have a travel alert page within our claims management application. People check this travel alert page frequently to see the state of weather before booking or commencing their travel plans. If there is a storm set to hit the east coast, and many of our customers check this update page to see if their travel insurance would include storm cover during the storm for example, over time we might experience some slowing of this business app, because when there's a storm and the travel update page is being visited frequently, there's a lot of load on the database and on the application. We didn't envisage this would be an issue when we designed the claims management service.
To reduce the load on our claims database, would be to implement a cache between the database and the claims application. A cache is ideal for holding frequently requested data so the web application does not need to read those components from our permanent data store. A cache will generally hold data for a finite period of time, if a record is changed, the cache will compare, flush, and store the latest version of a record. So while ElastiCache is a reliable and durable service by nature, ElastiCache is more about speed than persistence. As a cache, it is different by design from a permanent data store. Using Amazon ElastiCache, we could easily provision and implement ElastiCache to sit between our main database and our web application. Read requests that are made over and over will be stored temporarily within the ElastiCache database. ElastiCache will respond and send that frequently requested data to the web application front end, meaning our main database does not receive so many requests. So which cache engine should we choose? ElastiCache supports two database engines, Memcached and Redis. What's the difference I hear you ask. Now both engines provide a great cache solution, easily provisioned using the ElastiCache service. A simple way I use to remember the difference between them is Memcache for simplicity and speed, Redis for features. Choose Memcache if the following applies to your situation, you need the simplest model possible, you need to run large nodes with multiple cores or threads, you need the ability to scale in and out, adding and removing nodes as demanded by your system. Use Redis if we have complex data types, such as strings, hashes, lists, or sets, or bitmaps for example.
If we need persistence in our data store, or if we need to encrypt our data, if we need to replicate our cache data, or if we need automatic fail over if our primary node should fail, and if we want backup and restore capabilities, if we need support for multiple caches, or we need to sort or rake in memory data sets, it's all about the features, and Redis delivers on those. Amazon Neptune is a graph database service that makes it easy to build and run applications that need to use a lot of queries and look ups to quickly visualize data. Now graphing data can require a complex number of connection strings and related queries. So as a managed service, Amazon Neptune reduces the need for hardware provisioning, and software patching, setting up all the configuration or the backups required generally do get impacted if you have a lot of these queries to run and manage. So Amazon Neptune is an AWS native graph database engine, it's optimize for storing data relationships and querying a graph quickly and efficiently. Neptune suits use cases such as knowledge graphs, recommendation engines, and network security, to name a few examples. Now Neptune supports the popular graph models like Property Graph and W3C's RDF functions, and the respective query languages such as Apache, TinkerPop, Gremlin, and SPARQL, which allows you to easily build queries that efficiently never get very highly connected data sets. Okay, that concludes our dive into the AWS non-relational database services, Amazon DynamoDB, Amazon ElastiCache, and Amazon Neptune. Next we will explore the relational databases provided as part of the Amazon RDS service. See you in the next lecture.
About the Author
Andrew is an AWS certified professional who is passionate about helping others learn how to use and gain benefit from AWS technologies. Andrew has worked for AWS and for AWS technology partners Ooyala and Adobe. His favorite Amazon leadership principle is "Customer Obsession" as everything AWS starts with the customer. Passions around work are cycling and surfing, and having a laugh about the lessons learnt trying to launch two daughters and a few start ups.