In this video, Jeff Winesett describes using AWS Elasticache to eliminate database data access bottlenecks and speed up application data delivery. Elasticache supports Memcachd and Redis as in-memory caching solutions.
- For applications that read data from a persistent data storage stored on disk, such as a traditional database, few options can add more performance than adding an in-memory caching layer between the application business logic and the database, especially for data that is accessed frequently, sometimes referred to as hot data. Ideally the caching layer should be placed as close to the application servers as possible. And for very simple system architectures consisting of only one server, a caching layer could be achieved by simply adding an in-memory cache solution directly to the single app server.
However, this architecture is not optimized for scaling. If this application tier is ever going to scale horizontally, it would be best not to store the cache data on each individual server. This would result in too many missed cache hits. Data could easily get out of sync, and it would be hard to maintain. Enter Amazon ElastiCache. With just a few lines of code added to an application, a caching layer can be added that would greatly improve speed, increase throughput, and is more cost effective than trying to scale out the database layer.
ElastiCache supports two popular caching engines: Memcached and Redis. Memcached has been around since 2003 and is a tried and true and tested caching engine. It is popular and well-supported in many application languages and frameworks and is very easy to use. It's a relatively flat cache, it has one data type into which to store data, which is a string type, and this string type has a size limitation of up to one megabyte.
Memcached has no persistence, so when adding nodes into a Memcached cluster, if something happens to one of the nodes, that data will be lost. The D in Memcached stands for distributed, which means it's easy to scale. Redis is the other option provided by ElastiCache. Redis supports everything that Memcached does but also has some additional features. It too supports the string data type but allows up to 512 megabytes of data in this data type.
Redis supports persistence, so if you care about that data in the cache and need it to survive a memory failure, Redis can help with this. You can create custom business logic using Lua scripting and have this execute in memory. It is highly available and supports a master read replica architecture. Redis also supports other data types such as sets, sorted sets with scoring, lists, and hashes.
So how does one choose? This, of course, depends on the specific application being built and the use cases and requirements for the project. If you really just need basic caching, Memcached may be enough. If you're using a coding language that already has sophisticated support for Memcached or perhaps it's already baked in to the framework you're using, Memcached may be the right choice. However, because Redis has everything Memcached has, plus many more options and features, it's likely going to add a lot more value to the application in the long run.
Consider using Redis unless there are specific reasons why Memcached is a better fit. It was mentioned with just a few lines of code, a caching layer could be added to an application. There are a couple common patterns used when adding basic caching to an application. One is referred to as write-through. In the write-through approach, the data is first written to a persistence tier, such as a database, and then immediately afterward, written to cache.
In this pattern, the data is stored in the cache every time new data is added, regardless of whether users of the application ever request the data for reading. Another common pattern is called lazy load. The lazy load approach first attempts to retrieve the data from the cache. If not found in cache, the attempt is then made to retrieve the data from the database then set the data in cache. In this approach, there is no data added to the cache until it is first being requested.
There are pros and cons to both approaches. With the write-through approach all data is stored in cache. This has the advantage of increasing a cache hit for requested data, but this approach can require a lot more memory to hold all of that data, even when that data is not being actively requested. With the lazy load approach, only the needed data is being set in cache, but in this case, there's a higher chance of getting a miss, which can have a negative performance impact.
In practice, both approaches are often used. Time to Live settings, known as TTL, can also be used. These are settings that will expire the data after a period of time, which frees up available memory. So if you use a TTL setting, you can use the write-through approach and not have to worry too much about consuming too much memory with unneeded data. Using the ElastiCache service can increase data reads by 10 to 15 times faster than reading from a database.
It can take load off the database and prevent having to scale up or out the database tier, which can save money. With in-memory caching solutions, you can only hold as much data as the available memory will allow, which can present some limitations in some situations. As such, it may not be the only solution to addressing database performance issues, but it's certainly one of the best places to start. Optimize for Performance: Lesson #1: Consider using ElastiCache as an in-memory data access solution to eliminate bottlenecks with database data access and speed up the overall delivery of application data.
- Benefits of cloud services
- Making architectures scalable
- Examining cloud constraints
- Virtual servers, EC2, and Elastic IP
- Using the Amazon machine image
- Elastic load balancing
- Using CloudWatch for monitoring
- Security Models
- Elastic block storage
- S3, CloudFront, and Elastic Beanstalk
- Handling queues, workflows, and notifications
- Caching options and services
- Identity and access management
- Creating a custom server image
- Application deployment strategies
- Serverless architectures