[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-09-04 (世界標準時間)。"],[],[],null,["# Cluster and node specification\n\nThis page describes the cluster and node specifications for Memorystore for Redis Cluster\ninstances. For instructions on how to create an instance, see\n[Create instances](/memorystore/docs/cluster/create-instances).\n| **Note:** The terms *node* and *shard* are used interchangeably on this page to refer to a single Redis shard.\n\nChoose a node type\n------------------\n\nThe 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.\n\nThe `redis-shared-core-nano` node type is for small workloads. This node type\nprovides variable [performance](/compute/docs/general-purpose-machines#sharedcore) and doesn't have an SLA, making it unsuitable for production workloads.\n\nThe `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.\n\nWe only recommend choosing the `redis-highmem-xlarge` node type if you need\nmore cluster capacity than what `redis-highmem-medium` provides. Although the\n`redis-highmem-xlarge` node type is four times greater than the\n`redis-highmem-medium` type in size, the performance is not four times greater,\nas Redis performance does not scale linearly when vCPUs are added to\nincreasingly larger nodes (scaling up). Instead, to get better price\nperformance, you should scale out by adding more nodes to a cluster.\n| **Caution** : We recommend that you use the `redis-shared-core-nano` node type for development or testing purposes only. If you run Memorystore for Redis Cluster in a production environment, then we recommend using the `redis-standard-small`, `redis-highmem-medium`, or `redis-highmem-xlarge` node types.\n\nNode type specification\n-----------------------\n\nThe node capacity and characteristics depend on which of the four available\nnode types you choose:\n\n### Keyspace capacity and reserved overhead\n\nMemorystore automatically sets aside a portion of your instance\ncapacity to help prevent Out Of Memory (OOM) errors. This ensures a smooth\nexperience reading and writing keys. Memory limits and storage details are as\nfollows:\n\n- **Customizing your storage:** While we recommend using the default settings,\n you have the option to adjust the amount of reserved storage using the\n `maxmemory` configuration. For information about `maxmemory`,\n see [Supported instance configurations](/memorystore/docs/cluster/supported-instance-configurations).\n\n- **How much storage do you get?** Refer to the previous table's *Default writable keyspace capacity*\n column. This shows how much storage is available for your keys by default.\n\n- **Maximizing storage** If you want the maximum possible storage, the *total node capacity*\n column shows the storage limit when you set the `maxmemory` config to 100%.\n However, don't recommend choosing a `maxmemory` value higher than the default\n setting.\n\n- The `redis-shared-core-nano` node type has a hard limit of 1.12 GB, and can't\n be changed with the `maxmemory` configuration.\n\n### Node characteristics\n\nThe more virtual CPUs (vCPUs) that you select for your cluster, the better the\nperformance. If your cluster runs resource-intensive workloads, then select a\nnode type with a higher vCPU (for example, `redis-highmem-xlarge`). If your\ncluster performs less-demanding tasks, then select a node type with a lower vCPU\n(for example, `redis-highmem-medium`).\n\nScale an instance\n-----------------\n\nAs part of creating a Memorystore for Redis Cluster instance, you choose a\nnode type for the instance and specify the number of shards for the instance.\nAfter you create the instance, and as the capacity needs for your instance\nchange, you might need to scale the instance in the following ways:\n\n- Change the number of shards for your instance. This is *horizontal scaling* . You scale an instance horizontally by performing one of the following actions:\n - Add shards to the instance. This is scaling the instance *out*.\n - Remove shards from the instance. This is scaling the instance *in*.\n- Change the node type for your instance. This is *vertical scaling* . To scale an instance vertically, change the node type of the instance to one of the following node types:\n - Change to a larger node type. This is scaling the instance *up*.\n - Change to a smaller node type. This is scaling the instance *down*.\n\n| **Note:** For more information about horizontal and vertical scaling, see [About scaling instance capacity](/memorystore/docs/cluster/about-scaling-instance-capacity). For more information about changing the capacity of your instance by scaling the node type or the shard count, see [Scale instance capacity](/memorystore/docs/cluster/scale-instance-capacity).\n\nCluster specification\n---------------------\n\nThis section shows minimum and maximum cluster capacities given the cluster\nshape, node type, and replica count.\n\n### Minimum writable capacity\n\nWritable capacity is the amount of storage available for writing keys. It is\nequal to the size of one instance node. Therefore, depending on the node type,\nthe minimum writable capacity is 1.4 GB, 6.5 GB, 13 GB, or 58 GB. The minimum\nwritable capacity isn't affected by the number of replicas you choose.\n\n### Maximum writable capacity\n\nPerformance\n-----------\n\nUsing the [OSS memtier benchmarking tool](https://github.com/RedisLabs/memtier_benchmark) 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.\n\nWe 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 for Memorystore for Redis Cluster](/memorystore/docs/cluster/general-best-practices).\n\nCluster endpoints\n-----------------\n\nThis section explains the two endpoints each instance has.\n\n### Discovery endpoint\n\nEach instance has a discovery endpoint to which your client connects. It is\na combination of an IP address and port number. For instructions on how to find your cluster's discovery endpoint, see [View your cluster's discovery endpoint](/memorystore/docs/cluster/connect-cluster-instance#view_your_clusters_discovery_endpoint).\n\nYour client also uses it for node discovery. Your client uses the discovery endpoint to retrieve your instance's cluster topology to bootstrap OSS Redis cluster clients, and keep them updated in steady state. The resulting cluster topology provides Redis node endpoints (IP and port combinations) to be cached in-memory by the Redis cluster client. Your client then takes care of the updates and redirections automatically with no other application change required. For information on client discovery behavior and best practices, see [Client discovery](/memorystore/docs/cluster/general-best-practices#client_discovery).\n\nThe discovery endpoint is highly available because it is backed by multiple Redis nodes across multiple-zones to serve the cluster topology. Serving topology through the endpoint is robust even when faced with backend node failures or node updates.\n\nYour discovery endpoint has the following behavior:\n\n1. Your cluster's discovery endpoint remains unchanged throughout the lifecycle of the cluster instance, even during maintenance, or by any other action you take such as scaling in or out or changing replica counts.\n\n2. Redis node endpoints can change and can be recycled as nodes are added and removed over time. Ideally, you should use a Redis cluster client that can handle these changes automatically through topology refreshes and redirections. Examples of Redis cluster clients can be found at [Client library code samples](/memorystore/docs/cluster/client-library-code-samples). Your application shouldn't have dependencies or assumptions that node endpoints will remain unchanged for a given cluster.\n\n### Data endpoint\n\nEach instance also has a Private Service Connect data endpoint that\nMemorystore for Redis Cluster uses for client connection. You shouldn't connect to\nthis directly, however Memorystore for Redis Cluster uses this endpoint for connecting\nyour client to cluster nodes."]]