Chapter Summary
Figure 8.5 summarizes ElastiCache basic concepts.
Figure 8.5 ElastiCache Basic Concepts
Analogous to DAX, Amazon ElastiCache is another managed caching service that facilitates the implementation of scalable clusters of cache nodes -- offering the prospect for improving latency by responding to queries with in-memory data and minimizing access to HDDs or SSDs. ElastiCache supports two NoSQL open-source caching strategies: Memcached and Redis . Both implement a key-value store , partitioning across multiple nodes, high availability among multiple availability zones, and capacity scaling.
Redis also flaunts data encryption, read replicas, automatic failover, and backups for recovery of in-memory data. ElastiCache is similar to the DAX but different relating to interfacing with a back-end database. Using a lazy loading strategy, an app requests data from an ElastiCache cluster (Redis or Memcached API commands). A cache hit returns in-memory data to the app. A cache miss (including stale data with TTL expiration) results in the app following up with an additional request for directly accessing the database -- and appropriate API for refreshing cache data. An app using ElastiCache might also issue separate DML statements for accessing a possible back-end database. ElastiCache interfaces only with the application and is oblivious of any back-end database. Using a write through caching strategy, the app inserts/updates data in its database and also updates the cache (i.e., cache is always current).
Redis: Redis focuses on manipulating data within a cache server’s RAM and diminishes the need for a back-end database. Redis also allows for storing in-memory cache data on disk (e.g., via back up snapshots) for persisting in-memory data. Redis CRUD operations are performed in-memory. Redis in-memory changes can also be written to log files. Snapshots and log files serve as the basis for recovering in-memory data for restarting servers or automatic failover to a read replica.
Redis deals with higher level abstract data types (transcending RDBMS table/column concepts). Redis (beyond a conventional key-value store) is a data structures server . Redis provides a set of commands specific to each of its supported data types. Redis abstract data structures include: Strings, Lists, Sets, Sorted Sets, Hashes, and Pub/Sub. Redis equips each data type with a distinct set of CRUD commands (e.g., for Strings, CRUD commands include SET, GET, SETRANGE, GETRANGE, MSET, MGET, INCRBY, DECRBY, and APPEND).
Memcached : Memcached -- not a data structure server -- provides a conventional key-value store (i.e., no abstract data types … strings are the only supported data type). Memcached enables a large in-memory hash table (i.e., a key string value is mapped to another string value). Values moved to Memcached strings must be encoded (e.g., pre-serialized using Base64 ). Like Redis, Memcached APIs for manipulating string values are supported by many programming languages. Examples of Memcached string related commands include: Set Data, Add Data, Replace Data, Append Data, Prepend Data, Get Data, Delete Key, Incr, and Decr.
ElastiCache Clusters: An ElastiCache cluster is a kind of cache cluster which in turn is a kind of cluster. Because an ElastiCache cluster is a kind of cache cluster, an ElastiCache cluster inherits a single instance type (i.e., all nodes in an ElastiCache cluster have the same node type) and an SNS topic for communicating event notifications. An ElastiCache cluster indirectly inherits (because a cache cluster is a kind of cluster) many security groups, a subnet group, a parameter group, an engine version, and is a source for event notifications. Unlike a DAX cluster, an ElastiCache cluster can be associated with a single preferred availability zone in which cluster nodes are desired to be located (i.e., if not in multiple availability zones).
ElastiCache Nodes: An ElastiCache cluster controls a group of one or more ElastiCache node instances but the cardinality rules are subtly different for Memcached clusters( max of 20 nodes) vs. Redis clusters. If two or more nodes for Memcached, data is partitioned among multiple Memcached nodes (i.e., each node contains a subset of key-value pairs -- the concepts of primary and read replica nodes is moot). A hashing algorithm chooses the target node for accessing a key-value pair. For Redis, a cluster of only one node is a Redis standalone cluster .
A Redis cluster of two or more nodes is a Replication Group (i.e., a kind of ElastiCache cluster) which enables replicating in-memory data and partitioning data across multiple Redis nodes . A replication group clusters Redis nodes into one or more node groups (aka shards ). Each node group consists of a max of 6 nodes -- re-introducing the concepts of a primary node and up to 5 read replica nodes . For a Redis (cluster mode disabled ) cluster , a single node group supports replication but disables data partitioning (i.e., partitioning requires at least 2 node groups). A Redis (cluster mode enabled ) cluster partitions a max of 15 node groups. A node group with a primary node and at least one replica node enables automatic failover in the event of primary node failure.