Cluster and node specification

This page describes the cluster and node specifications for Memorystore for Redis Cluster instances. For instructions on how to create an instance, see Create instances.

Choosing a node type

The shards in your cluster all use the same node type of your choosing. The best node type for your cluster depends on your requirements for price, performance, and keyspace capacity.

The redis-standard-small node type lets you provision small clusters, and grow your cluster by smaller increments at potentially lower costs than other node types. redis-standard-small also offers the advantage of distributing your keyspace across more nodes with a higher total vCPU count. This offers improved price-performance compared to redis-highmem-medium, as long as the total keyspace capacity of the smaller nodes is sufficient for your data needs.

We only recommend choosing the redis-highmem-xlarge node type if you need more cluster capacity than what redis-highmem-medium provides. Although the redis-highmem-xlarge node type is four times greater than the redis-highmem-medium type in size, the performance is not four times greater, as Redis performance does not scale linearly when vCPUs are added to increasingly larger nodes (scaling up). Instead, to get better price performance, you should scale out by adding more nodes to a cluster.

Node type specification

The node capacity and characteristics depend on which of the four available node types you choose:

Keyspace capacity and reserved overhead

Node type Default writable keyspace capacity Total node capacity
redis-shared-core-nano 1.12 GB 1.4 GB
redis-standard-small 5.2 GB 6.5 GB
redis-highmem-medium 10.4 GB 13 GB
redis-highmem-xlarge 46.4 GB 58 GB

Memorystore automatically sets aside a portion of your instance capacity to help prevent Out Of Memory (OOM) errors. This ensures a smooth experience reading and writing keys. Memory limits and storage details are as follows:

  • Customizing your storage: While we recommend using the default settings, you have the option to adjust the amount of reserved storage using the maxmemory configuration. For information about maxmemory, see Supported instance configurations.

  • How much storage do you get? Refer to the previous table's Default writable keyspace capacity column. This shows how much storage is available for your keys by default.

  • Maximizing storage If you want the maximum possible storage, the total node capacity column shows the storage limit when you set the maxmemory config to 100%. However, don't recommend choosing a maxmemory value higher than the default setting.

  • The redis-shared-core-nano node type has a hard limit of 1.12 GB, and can't be changed with the maxmemory configuration.

Node characteristics

Node type vCPU count SLA offered Max clients
redis-shared-core-nano 0.5 No 5,000
redis-standard-small 2 Yes 16,000 (default). Max value is 32,000
redis-highmem-medium 2 Yes 32,000 (default). Max value is 64,000
redis-highmem-xlarge 8 Yes 64,000

Cluster specification

This section shows minimum and maximum cluster capacities given the cluster shape, node type, and replica count.

Minimum writable capacity given minimum cluster shape

Node type and size Minimum writable capacity using the minimum cluster shape of 3 nodes1
redis-shared-core-nano - 1.4 GB 4.2 GB
redis-standard-small - 6.5 GB 19.5 GB
redis-highmem-medium - 13 GB 39 GB
redis-highmem-xlarge - 58 GB 174 GB

1 Writiable capacity is the amount of storage available for writing keys. The minimum writable capacity isn't affected by the number of replicas you choose.

Maximum writable capacity given cluster shape

Node type and size Max capacity given cluster shape of 250 primary nodes and 0 replicas per node Max capacity given cluster shape of 125 primary nodes and 1 replicas per node Max capacity given cluster shape of 83 primary nodes and 2 replicas per node
redis-shared-core-nano - 1.4 GB 350 GB 175 GB 116.2 GB
redis-standard-small - 6.5 GB 1,625 GB 812.5 GB 539.5 GB
redis-highmem-medium - 13 GB 3,250 GB 1,625 GB 1,079 GB
redis-highmem-xlarge - 58 GB 14,500 GB 7,250 GB 4,814 GB

Unsupported cluster shape

You can't have a Memorystore cluster with only 4 nodes. This cluster shape isn't supported to ensure high availability across multiple zones such as automatic handling of zonal outages.

Performance

Using the OSS memtier benchmarking tool in the us-central1 region yielded 120,000 - 130,000 operations per second per 2 vCPU node (redis-standard-small and redis-highmem-medium) with microseconds latency and 1KiB data size.

We recommend that you perform your own benchmarking with real workloads or synthetic workloads that resemble your production traffic. In addition, we recommend that you size your clusters with a buffer (or "headroom") for workload spikes or unexpected traffic. For more guidance, see best practices.