Merge pull request #1139 from redis/DOC-4745

RC: Redis hashing policy

Author: cmilesb

content/operate/rc/changelog/february-2025.md

@@ -7,7 +7,7 @@ categories:
 - rc
 description: New features, enhancements, and other changes added to Redis Cloud during
   February 2025.
-highlights: Pico billing unit
+highlights: Pico billing unit, Redis hashing policy
 linktitle: February 2025
 weight: 36
 ---

content/operate/rc/changelog/march-2025.md

@@ -7,7 +7,7 @@ categories:
 - rc
 description: New features, enhancements, and other changes added to Redis Cloud during
   March 2025.
-highlights: Redis Insight on Redis Cloud
+highlights: Redis Insight on Redis Cloud, Redis Hashing policy
 linktitle: March 2025
 weight: 34
 ---
@@ -18,4 +18,20 @@ weight: 34
 
 Users with select Redis Cloud Essentials databases can now open a browser-based version of [Redis Insight]({{< relref "/operate/rc/databases/connect/insight-cloud" >}}) directly from Redis Cloud. See [Connect to your database]({{< relref "/operate/rc/databases/connect#ri-browser" >}}) to learn how to open Redis Insight from Redis Cloud.
 
-This browser-based version of Redis Insight has a subset of the features of Redis Insight on desktop. For more information, see [Open with Redis Insight on Redis Cloud]({{< relref "/operate/rc/databases/connect/insight-cloud" >}}).
+This browser-based version of Redis Insight has a subset of the features of Redis Insight on desktop. For more information, see [Open with Redis Insight on Redis Cloud]({{< relref "/operate/rc/databases/connect/insight-cloud" >}}).
+
+### Redis hashing policy
+
+Accounts created after March 31, 2025, can select the new [Redis hashing policy]({{< relref "/operate/rc/databases/configuration/clustering#redis-hashing-policy" >}}) for their databases when creating a new database. 
+
+The Redis hashing policy is identical to the [hashing policy used by Redis Community Edition]({{< relref "/operate/oss_and_stack/reference/cluster-spec#hash-tags" >}}). This policy is recommended for most users. Select it if any of the following conditions apply:
+- This is your first Redis Cloud account, and you are starting fresh.
+- You are migrating data from Redis Community Edition or other Redis-managed platforms.
+- Your application does not use hashtags in database key names.
+- Your application uses binary data as key names.
+
+See [Clustering]({{< relref "/operate/rc/databases/configuration/clustering#manage-the-hashing-policy" >}}) for more information.
+
+## Deprecations
+
+- The [Custom hashing policy]({{< relref "/operate/rc/databases/configuration/clustering#custom-hashing-policy" >}}) is no longer available for accounts created after March 31, 2025. For all other accounts, this policy is not recommended and will be deprecated in the future. Only select a custom hashing policy if you are already using a custom hashing policy with your existing Redis Cloud databases.

content/operate/rc/databases/configuration/clustering.md

@@ -38,7 +38,7 @@ Redis server.
 An instance that belongs to a cluster can manage multiple hash
 slots. This division of the key space, known as _sharding_, is achieved by
 hashing the key names, or parts of these (key hash tags), in order to
-obtain the hash slot in which a key should reside.
+obtain the hash slot in which a key should reside. Redis Cloud supports several [hashing policies](#manage-the-hashing-policy).
 
 Even when using multiple Redis processes, the use of a Redis
 Enterprise Cloud cluster is nearly transparent to the application that
@@ -86,46 +86,60 @@ are supported, with the following limitations:
     and pipelining are supported with Redis Cloud cluster
     like if it were a non-cluster DB.
 
-## Manage the hashing policy
+## Hashing policies and hash tags {#manage-the-hashing-policy}
 
-Redis defaults to the [standard hashing policy](#standard-hashing-policy). 
-The clustering configuration of a Redis Cloud instance can be changed. 
-However, hashing policy changes delete existing data 
-(FLUSHDB) before they're applied. 
+The hashing policy determines how data is distributed across multiple Redis processes of a database. It uses a hashing function to map keys to hash slots in these processes, ensuring an even distribution of data for optimal performance and scalability.
 
-These changes include:
+The hashing function uses the entire key name to calculate the hash slot, unless the key name contains a **hash tag**, represented by a `{...}` pattern.
 
-1. Changing the hashing policy, either from standard to custom or vice versa.
-1. Changing the order of custom hashing policy rules.
-1. Adding rules before existing ones in the custom hashing policy.
-1. Deleting rules from the custom hashing policy.
-1. Disabling clustering for the database.
+If the key contains a `{...}` pattern, only the substring between `{` and `}` is hashed in order to obtain the hash slot.
+
+You can use the `{...}` pattern to direct related keys to the same hash slot, so that multi-key operations are supported on them. On the other hand, not using a hashtag in the key's name results in a (statistically) even distribution of keys across the keyspace's shards, which improves resource utilization. If your application does not perform multi-key operations, you don't need to construct key names with hashtags.
+
+Redis Cloud offers 3 hashing policies, which differ in how hash tags are processed. These hashing policies are not always available.
+
+For accounts created after March 31, 2025, Redis defaults to the [Redis hashing policy](#redis-hashing-policy) **when creating a new database**. For all other accounts, Redis defaults to the [standard hashing policy](#standard-hashing-policy). 
+
+### Redis hashing policy
+
+{{< note >}}
+This policy is available for selected accounts and will be rolled out gradually to other accounts in the future.
+{{< /note >}}
+
+The Redis hashing policy is identical to the [hashing policy used by Redis Community Edition]({{< relref "/operate/oss_and_stack/reference/cluster-spec#hash-tags" >}}). This policy is recommended for most users and you should select it if any of the following conditions apply:
+- This is your first Redis Cloud account, and you are starting fresh.
+- You are migrating data from Redis Community Edition or other Redis-managed platforms.
+- Your application does not use hashtags in database key names.
+- Your application uses binary data as key names.
 
 ### Standard hashing policy
 
-When using the standard hashing policy, a Redis Cloud cluster
-behaves like a standard Redis cluster, and hashing is
-performed as follows:
-
-1. Keys with a hashtag: a key's hashtag is any substring between '{'
-    and '}' in the key's name. That means that when a key's name
-    includes the pattern '{...}', the hashtag is used as input for the
-    hashing function. For example, the following key names have the same
-    hashtag and are mapped to the same slot: foo{bar},
-    {bar}baz & foo{bar}baz.
-1. Keys without a hashtag: when a key doesn't contain the '{...}'
-    pattern, the entire key's name is used for hashing.
-
-You can use the '{...}' pattern to direct related keys to the same hash
-slot, so that multi-key operations are supported on them. On the other
-hand, not using a hashtag in the key's name results in a
-(statistically) even distribution of keys across the keyspace's shards, 
-which improves resource utilization. 
-If your application does not perform multi-key operations, you don't
-need to construct key names with hashtags.
+The Standard hashing policy is mostly consistent with the Redis hashing policy, and will generate the same hash-slot calculation in the following cases:
+1. Keys with a single hashtag: a key's hashtag is any substring between '{' and '}' in the key's name. That means that when a key's name includes the pattern '{...}', the hashtag is used as input for the hashing function. For example, the following key names have the same hashtag and are mapped to the same slot: foo{bar}, {bar}baz & foo{bar}baz.
+1. Keys without a hashtag: when a key doesn't contain the '{...}' pattern, the entire key's name is used for hashing
+
+However, this policy is less recommended and you should select it only if any of the following conditions apply:
+- Your application uses empty hashtags to hash different keys to the same hashslot
+- Your application uses multiple curly brackets within a key’s name
+
+In some cases, the Standard hashing policy behaves differently from the Redis hashing policy:
+1. Using empty hashtags (“{}”): the Standard hashing policy does not ignore empty hashtags, so two keys that start with empty hashtags will be hashed to the same hashslot (while the Redis hashing policy would ignore them). 
+    For example: given 2 keys {}foo and {}bar, hashing would be:
+    - Standard hashing policy: to the same hash slot
+    - Redis hashing policy: to different hash slots
+2. Using multiple curly brackets: when a key’s name contains multiple curly brackets, the Standard hashing calculation might be different than the Redis hashing policy. 
+    For example: given 2 keys {foo}bar} and {foo}qux}:
+    - Standard hashing policy: substrings “foo}bar” and “foo}qux” will be used for the 1st and 2nd key respectively, hashed each key to a different hash-slot.
+    - Redis hashing policy: the substring “foo” will be used for both keys, hashing them to the same slot.
 
 ### Custom hashing policy
 
+{{< note >}}
+The custom hashing policy is not available for accounts created after March 31, 2025.
+
+For all other accounts, this policy is not recommended and will be deprecated in the future. Select this option only if you are already using a custom hashing policy with your existing Redis Cloud databases.
+{{< /note >}}
+
 A Redis Cloud  cluster can be configured to use a custom hashing
 policy. A custom hashing policy is required when different keys need to
 be kept together on the same shard to allow multi-key operations. Redis
@@ -150,6 +164,19 @@ default RegEx rules that implement the standard hashing policy are:
 You can modify existing rules, add new ones, delete rules, or change
 their order to suit your application's requirements.
 
+{{< warning >}}
+If the Custom hashing policy is available, you can change the hashing policy between Standard and Custom after you create your database. However, hashing policy changes delete existing data 
+(using [`FLUSHDB`]({{< relref "/commands/flushdb" >}})) before they're applied. 
+
+These changes include:
+
+1. Changing the hashing policy, either from standard to custom or vice versa.
+1. Changing the order of custom hashing policy rules.
+1. Adding rules before existing ones in the custom hashing policy.
+1. Deleting rules from the custom hashing policy.
+1. Disabling clustering for the database.
+{{< /warning >}}
+
 ### Custom hashing policy notes and limitations
 
 1. You can define up to 32 RegEx rules, each up to 256 characters.

content/operate/rc/databases/create-database/create-pro-database-new.md

@@ -162,7 +162,8 @@ By default, you're shown basic settings, which include:
 | **Name** | A custom name for your database (_required_) |
 | **Dataset size (GB)** | The amount of data for your dataset. Specify small sizes as decimals of 1.0&nbsp;GB; example: `0.1` GB (minimum). We calculate the total memory limit for you based on the other settings you choose for your database. <br/> Databases with Search and query have specific sizing requirements, see [Search and query sizing]({{< relref "/operate/rc/databases/configuration/advanced-capabilities#search-and-query-sizing" >}}) for more information. |
 | **High Availability** | Indicates whether a replica copy of the database is maintained in case the primary database becomes unavailable.  (Warning: Doubles memory consumption). See [High Availability]({{< relref "/operate/rc/databases/configuration/high-availability" >}}).  |
-| **Throughput** | Identifies maximum throughput for the database, which is specified in terms of operations per second (**Ops/sec**). See [Throughput]({{< relref "/operate/rc/databases/configuration/clustering#throughput" >}}) for more information. <br/> Databases with Search and query have specific throughput requirements, see [Search and query sizing]({{< relref "/operate/rc/databases/configuration/advanced-capabilities#search-and-query-sizing" >}}) for more information. |
+| **Throughput** | Identifies maximum throughput for the database, which is specified in terms of operations per second (**Ops/sec**). See [Throughput]({{< relref "/operate/rc/databases/configuration/sizing#throughput" >}}) for more information. <br/> Databases with Search and query have specific throughput requirements. See [Search and query sizing]({{< relref "/operate/rc/databases/configuration/advanced-capabilities#search-and-query-sizing" >}}) for more information. |
+| **Hashing policy** | Determines how data is distributed across multiple Redis processes of a database. Available options depend on your account creation date. See [Clustering]({{< relref "/operate/rc/databases/configuration/clustering#manage-the-hashing-policy" >}}) for more information.  |
 | **Query performance factor** | *(Search and query databases on Redis 7.2 or later only)* Adds additional compute power to process your query and vector search workloads and boost your queries per second. See [Search and query sizing]({{< relref "/operate/rc/databases/configuration/advanced-capabilities#search-and-query-sizing" >}}) for more information. |
 | **Data Persistence** | Defines the data persistence policy, if any. See [Data persistence]({{< relref "/operate/rc/databases/configuration/data-persistence.md" >}}). |