Skip to content

Commit 96aae49

Browse files
authored
Merge pull request #1976 from redis/1971-feedback-clustering-redis-databases
RC: Clarify use of hashing policies
2 parents 945cbda + 540716b commit 96aae49

File tree

1 file changed

+6
-4
lines changed

1 file changed

+6
-4
lines changed

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

Lines changed: 6 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -120,10 +120,6 @@ The Standard hashing policy is mostly consistent with the Redis hashing policy,
120120
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.
121121
1. Keys without a hashtag: when a key doesn't contain the '{...}' pattern, the entire key's name is used for hashing
122122

123-
However, this policy is less recommended and you should select it only if any of the following conditions apply:
124-
- Your application uses empty hashtags to hash different keys to the same hashslot
125-
- Your application uses multiple curly brackets within a key’s name
126-
127123
In some cases, the Standard hashing policy behaves differently from the Redis hashing policy:
128124
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).
129125
For example: given 2 keys {}foo and {}bar, hashing would be:
@@ -134,6 +130,12 @@ In some cases, the Standard hashing policy behaves differently from the Redis ha
134130
- 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.
135131
- Redis hashing policy: the substring “foo” will be used for both keys, hashing them to the same slot.
136132

133+
{{< note >}}
134+
To allow seamless transition between hashing policies, the following techniques are not recommended:
135+
- Using empty hashtags to hash different keys to the same hashslot
136+
- Using multiple curly brackets within a key’s name
137+
{{< /note >}}
138+
137139
### Custom hashing policy
138140

139141
{{< note >}}

0 commit comments

Comments
 (0)