AMAZON ELASTICACHE

#amazon #elasticache #datastores #database

An in-memory database (IMDB) stores computer data in a computer’s main memory instead of a disk drive to produce quicker response times.
Accessing data stored in memory eliminates the time needed to query data from a disk.
In-memory databases are used by applications that depend on rapid response times and real-time data management.
An in-memory database is also referred to as a main memory database (MMDB), real-time database (RTDB) or in-memory database system (IMDS.

THE STRUCTURE

The downside is the volatility of RAM. The data is lost when an in-memory database crashes. The development of non-volatile random-access memory (NVRAM) can help in-memory databases maintain data after a power loss or crash.
NVRAM chips are being developed that provide a more persistent memory than flash.
THE NEED FOR IN-MEMORY DATABASES

COMPARING DISK-BASED AND IN-MEMORY DATABASES

ELASTICACHE NODES

A node is the smallest building block of an ElastiCache deployment.
A node is a fixed-size chunk of secure, network-attached RAM. Each node runs an instance of the engine and version that was chosen when you created your cluster.
Every node within a cluster is the same instance type and runs the same cache engine.
Multiple types of cache nodes are supported, each with varying amounts of associated memory.
If necessary, you can scale the nodes in a cluster up or down to a different instance type can exist in isolation form or in some relationship to other nodes. Every node within a cluster is the same instance type and runs the same cache engine.

ELASTICACHE FOR MEMCACHED ARCHITECTURE

ELASTICACHE FOR MEMCACHED

When you deploy an ElastiCache Memcached cluster, it sits in your application as a separate tier alongside your database.
When you launch an ElastiCache cluster, you can choose the Availability Zones where the cluster lives.
For best performance, you should configure your cluster to use the same Availability Zones as your application servers. To launch an ElastiCache cluster in a specific Availability Zone, make sure to specify the Preferred Zone(s) option during cache cluster creation.
The Availability Zones that you specify will be where ElastiCache will launch your cache nodes.
We recommend that you select Spread Nodes Across Zones, which tells ElastiCache to distribute cache nodes across these zones as evenly as possible. This distribution will mitigate the impact of an Availability Zone disruption on your ElastiCache nodes.
The trade-off is that some of the requests from your application to ElastiCache will go to a node in a different Availability Zone, meaning latency will be slightly higher.

ELASTICACHE FOR REDIS ARCHITECTURE

ELASTICACHE FOR REDIS

As with Memcached, when you deploy an ElastiCache for Redis cluster, it is an additional tier in your app.
Unlike Memcached, ElastiCache clusters for Redis only contain a single primary node.
After you create the primary node, you can configure one or more replica nodes and attach them to the primary Redis node.
An ElastiCache for Redis replication group consists of a primary and up to five read replicas. Redis asynchronously replicates the data from the primary to the read replicas.
Because Redis supports persistence, it is technically possible to use Redis as your only datastore
ElastiCache for Redis has the concept of a primary endpoint, which is a DNS(Domain Name Service) name that always points to the current Redis primary node. If a failover event occurs, the DNS entry will be updated to point to the new Redis primary node.

THE TWO ENGINES – MEMCACHED VERSUS REDIS