If you're new to AWS, it can be a little daunting to determine which database service is the right option for your solution. This is the first course in a two-part series on database fundamentals for AWS, which will help you make the right decision when choosing an AWS database service.
This course covers Amazon RDS, Amazon DynamoDB, Amazon ElastiCache, and Amazon Neptune. As well as getting a theoretical understanding of these, you will also watch guided demonstrations from the AWS platform showing you how to use each database service.
If you have any feedback relating to this course, feel free to share your thoughts with us at support@cloudacademy.com. The second course in this two-part series covers Amazon Redshift, Amazon Quantum Ledger Database, Amazon DocumentDB, and Amazon Keyspaces. You can find that course here.
Learning Objectives
- Obtain a solid understanding of the following Amazon database services: Amazon RDS, DynamoDB, ElastiCache, and Neptune
- Create an Amazon RDS database
- Create a DynamoDB database
- Create an ElastiCache cluster
- Create an Amazon Neptune database
Intended Audience
- Individuals responsible for designing, operating, and optimizing AWS database solutions
- Anyone preparing to take the AWS Certified Database Specialty exam
Prerequisites
To get the most out of this course, you should have a basic understanding of database architectures and the AWS global infrastructure. For more information on this, please see our existing blog post here. You should also have a general understanding of the principles behind different EC2 Instance families.
Hello and welcome to this lecture dedicated to an overview of Amazon ElastiCache. Amazon ElastiCache is a service that makes it easy to deploy, operate, and scale open-source, in-memory data stores in the cloud. This service improves the performance through caching, where web applications allow you to retrieve information from fast managed in-memory data stores instead of relying entirely on slower disk-based solutions.
Let me take a closer look at caching and then expand our discussion to in-memory caching environments in the cloud.
If you think about your own computing devices, your laptop, for example, you may have a huge capacity from a persistent storage perspective via your hard drives with lots of applications installed, allowing you to work on a variety of documents at the same time. However, over time, you may notice a degradation in performance, and certain operations might start to become sluggish, especially as more and more files are opened and accessed to carry out different functions and tasks. When this happens, how can we make the computer perform faster and serve up our information quicker and enhance our response times? One solution is to install additional random access memory, known as RAM. With this additional memory, it enables our device to store frequently accessed information in memory instead of having to request the information from the hard drive, which is much slower than RAM. This process is known as caching.
Now let's take this approach and relate it to how a web application uses in-memory caching. To be clear, ElastiCache is not just used for web applications. It can be used for any application that can benefit from increased performance using in-memory cache. But to explain the process, I shall focus on a web application as an example.
A common scenario is to have a web application that reads and writes data to persistent storage, for example, to a relational database such as RDS or a NoSQL database such as DynamoDB. However, persistent storage, like hard disk storage, tends to experience some fluctuations in latency as each piece of data needs to be written to or retrieved from a permanent media store, and this can affect the overall performance.
This is where an in-memory cache is useful. It's generally used to improve read-only performance. Many websites get a high percentage of read hits, but less write hits. An in-memory cache can store frequently accessed read-only information and serve it up much quicker than having the application continually request it from a persistent data store.
Now imagine that your app becomes more popular and you need to scale up. Adding more web servers is not that difficult. However, instead of vertically scaling your data store for your database, you could instead add an in-memory caching layer with sub-millisecond response times, which will of course make a considerable difference. By adding more web servers along with an ElastiCache cluster, you can automatically grow your caching layer based on the increased demand. This can eliminate or reduce the need to scale up on your persistent data store.
ElastiCache supports both Memcached and the Redis engines, so existing applications can be easily moved to ElastiCache. But what is Memcached and Redis and which cache engine should we choose? Amazon ElastiCache for Memcached is a high-performance sub-millisecond latency Memcached-compatible in-memory key store service that can either be used as a cache in addition to a data store. Amazon ElastiCache for Redis is purely an in-memory data store designed for high performance and again providing sub-millisecond latency on a huge scale to real-time applications.
As we can see, both engines provide a great cache solution and are both easily provisioned using the ElastiCache service. In this table, we can see some of the primary use cases for each.
Generally Redis offers a more robust set of features to that of Memcached. In broad terms, Redis has more features, whereas Memcached is often recognized for its simplicity and speed of performance. Memcached really suits workloads where memory allocation is going to be consistent and the increased performance is more important than the additional features that Redis offers.
As you can see from this screenshot during the configuration of ElastiCache, Redis also offers an option to enable cluster mode. When Redis cluster mode is disabled, each cluster will have just a single shard. However, with cluster mode enabled, each cluster can have up to 90 shards. So now's a good time to run through at a high level some of these fundamental elements of ElastiCache. These include nodes, shards, and clusters.
ElastiCache nodes. A cache node is a fixed sized chunk of secure network attached RAM, essentially the building block of the ElastiCache service, and supports a clustered configuration. As you can see here, the nodes themselves can be launched using a variety of different instance types.
ElastiCache for Redis shards. A Redis shard, also known as a node group when working with the API and CLI, is a group of up to 6 ElastiCache nodes.
ElastiCache for Redis clusters. A Redis cluster contains between one and 90 Redis shards, depending on if cluster mode is enabled or disabled. Data is then partitioned across all of the shards in that cluster.
ElastiCache for Memcached clusters. Clusters are a collection of one or more cache nodes. Once you've provisioned a cluster, Amazon ElastiCache automatically detects and replaces failed nodes, which helps reduce the risk of overloaded database, and therefore reduces the website and application load times.
Before I finish this lecture covering ElastiCache, I just want to point out some of the common use cases where you might use Amazon ElastiCache. Due to its incredibly fast performance and scaling abilities, this is commonly used in the online gaming industry where it's vital that statistical information like a scoreboard is presented as quickly and as consistently as possible to all the players in the game.
Another common use is for social networking sites, where they need a way to store temporary session information in session management.
Real-time analytics is also a great use for ElastiCache, as it can be used in conjunction with other services such as Amazon Kinesis to ingest, process, and analyze data at scale. This could help with personalized ads and recommendations with sub-millisecond latency.
As you can see, these are applications that have lots of read-only content that would benefit from an in-memory cache. Often users are scanning these websites for information like who currently has the high score in a game, what are your friends up to, looking for how-tos, or guidance on the best restaurant. Obviously there is information written to these sites, as well, like when something is updated or changed, so that information will be sent to a permanent data store.
Now we've discussed when ElastiCache is a great solution, but when is it best to consider using something else? ElastiCache should never be used to store your only version of data records, since a cache is designed to be a temporary data store. So when data persistence is necessary, like when working with primary data records, or when we need write performance rather than read performance, a persistent data store should be used instead of an ElastiCache.
Amazon ElastiCache can be a very useful tool for developers. Application developers are always looking for ways to ensure the best performance and availability for their application. Databases and other permanent storage options are relatively slow and users are impatient today. Waiting a few more seconds for an app to respond can mean losing business to a competitor. Developers are thrilled when an app becomes popular, but then there is a challenge of scaling. Adding front end support like more web servers is fairly simple, but when it comes to scaling persistent storage, it starts getting complicated and messy. Then there are a number of management tasks to consider. Updating, patching, monitoring, and securing data takes time. Using ElastiCache allows the developer to focus on building and improving apps by simplifying and reducing administrative tasks.
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.
Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.