You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/commands/bf.reserve/index.md
+7-6Lines changed: 7 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -50,12 +50,13 @@ Though the filter can scale up by creating sub-filters, it is recommended to res
50
50
sub-filters requires additional memory (each sub-filter uses an extra bits and hash function) and consume further CPU time than an equivalent filter that had
51
51
the right capacity at creation time.
52
52
53
-
The number of hash functions is `-log(error)/ln(2)^2`.
54
-
The number of bits per item is `-log(error)/ln(2)` ≈ 1.44.
53
+
The optimal number of hash functions is `ceil(-ln(error_rate) / ln(2))`.
55
54
56
-
***1%** error rate requires 7 hash functions and 10.08 bits per item.
57
-
***0.1%** error rate requires 10 hash functions and 14.4 bits per item.
58
-
***0.01%** error rate requires 14 hash functions and 20.16 bits per item.
55
+
The required number of bits per item, given the desired `error_rate` and the optimal number of hash functions, is `-ln(error_rate) / ln(2)^2`. Hence, the required number of bits in the filter is `capacity * -ln(error_rate) / ln(2)^2`.
56
+
57
+
***1%** error rate requires 7 hash functions and 9.585 bits per item.
58
+
***0.1%** error rate requires 10 hash functions and 14.378 bits per item.
59
+
***0.01%** error rate requires 14 hash functions and 19.170 bits per item.
59
60
60
61
## Required arguments
61
62
@@ -90,7 +91,7 @@ Non-scaling filters requires slightly less memory than their scaling counterpart
90
91
When `capacity` is reached, an additional sub-filter is created.
91
92
The size of the new sub-filter is the size of the last sub-filter multiplied by `expansion`, specified as a positive integer.
92
93
93
-
If the number of elements to be stored in the filter is unknown, you use an `expansion` of `2` or more to reduce the number of sub-filters.
94
+
If the number of items to be stored in the filter is unknown, you use an `expansion` of `2` or more to reduce the number of sub-filters.
94
95
Otherwise, you use an `expansion` of `1` to reduce memory consumption. The default value is `2`.
Copy file name to clipboardExpand all lines: content/commands/json.mget/index.md
+4Lines changed: 4 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -38,6 +38,10 @@ Return the values at `path` from multiple `key` arguments
38
38
39
39
{{% warning %}}
40
40
When cluster mode is enabled, all specified keys must reside on the same [hash slot](https://redis.io/docs/latest/operate/oss_and_stack/reference/cluster-spec/#key-distribution-model).
41
+
42
+
When the database has more than one shard, and the specified keys reside in different shards, Redis will not report a CROSSSLOT error (to avoid breaking changes) and the results may be partial.
Copy file name to clipboardExpand all lines: content/develop/data-types/probabilistic/bloom-filter.md
+15-19Lines changed: 15 additions & 19 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,7 +10,7 @@ categories:
10
10
- kubernetes
11
11
- clients
12
12
description: Bloom filters are a probabilistic data structure that checks for presence
13
-
of an element in a set
13
+
of an item in a set
14
14
linkTitle: Bloom filter
15
15
stack: true
16
16
title: Bloom filter
@@ -19,9 +19,9 @@ weight: 10
19
19
20
20
A Bloom filter is a probabilistic data structure in Redis Community Edition that enables you to check if an element is present in a set using a very small memory space of a fixed size.
21
21
22
-
Instead of storing all of the elements in the set, Bloom Filters store only the elements' hashed representation, thus sacrificing some precision. The trade-off is that Bloom Filters are very space-efficient and fast.
22
+
Instead of storing all the items in a set, a Bloom Filter stores only the items' hashed representations, thus sacrificing some precision. The trade-off is that Bloom Filters are very space-efficient and fast.
23
23
24
-
A Bloom filter can guarantee the absence of an element from a set, but it can only give an estimation about its presence. So when it responds that an element is not present in a set (a negative answer), you can be sure that indeed is the case. But one out of every N positive answers will be wrong. Even though it looks unusual at a first glance, this kind of uncertainty still has its place in computer science. There are many cases out there where a negative answer will prevent more costly operations, for example checking if a username has been taken, if a credit card has been reported as stolen, if a user has already seen an ad and much more.
24
+
A Bloom filter can guarantee the absence of an item from a set, but it can only give an estimation about its presence. So when it responds that an item is not present in a set (a negative answer), you can be sure that indeed is the case. But one out of every N positive answers will be wrong. Even though it looks unusual at first glance, this kind of uncertainty still has its place in computer science. There are many cases out there where a negative answer will prevent more costly operations, for example checking if a username has been taken, if a credit card has been reported as stolen, if a user has already seen an ad and much more.
The rate is a decimal value between 0 and 1. For example, for a desired false positive rate of 0.1% (1 in 1000), error_rate should be set to 0.001.
112
112
113
113
#### 2. Expected capacity (`capacity`)
114
-
This is the number of elements you expect having in your filter in total and is trivial when you have a static set but it becomes more challenging when your set grows over time. It's important to get the number right because if you **oversize** - you'll end up wasting memory. If you **undersize**, the filter will fill up and a new one will have to be stacked on top of it (sub-filter stacking). In the cases when a filter consists of multiple sub-filters stacked on top of each other latency for adds stays the same, but the latency for presence checks increases. The reason for this is the way the checks work: a regular check would first be performed on the top (latest) filter and if a negative answer is returned the next one is checked and so on. That's where the added latency comes from.
114
+
This is the number of items you expect having in your filter in total and is trivial when you have a static set but it becomes more challenging when your set grows over time. It's important to get the number right because if you **oversize** - you'll end up wasting memory. If you **undersize**, the filter will fill up and a new one will have to be stacked on top of it (sub-filter stacking). In the cases when a filter consists of multiple sub-filters stacked on top of each other latency for adds stays the same, but the latency for presence checks increases. The reason for this is the way the checks work: a regular check would first be performed on the top (latest) filter and if a negative answer is returned the next one is checked and so on. That's where the added latency comes from.
115
115
116
116
#### 3. Scaling (`EXPANSION`)
117
-
Adding an element to a Bloom filter never fails due to the data structure "filling up". Instead the error rate starts to grow. To keep the error close to the one set on filter initialisation - the Bloom filter will auto-scale, meaning when capacity is reached an additional sub-filter will be created.
118
-
The size of the new sub-filter is the size of the last sub-filter multiplied by `EXPANSION`. If the number of elements to be stored in the filter is unknown, we recommend that you use an expansion of 2 or more to reduce the number of sub-filters. Otherwise, we recommend that you use an expansion of 1 to reduce memory consumption. The default expansion value is 2.
117
+
Adding an item to a Bloom filter never fails due to the data structure "filling up". Instead, the error rate starts to grow. To keep the error close to the one set on filter initialization, the Bloom filter will auto-scale, meaning, when capacity is reached, an additional sub-filter will be created.
118
+
The size of the new sub-filter is the size of the last sub-filter multiplied by `EXPANSION`. If the number of items to be stored in the filter is unknown, we recommend that you use an expansion of 2 or more to reduce the number of sub-filters. Otherwise, we recommend that you use an expansion of 1 to reduce memory consumption. The default expansion value is 2.
119
119
120
120
The filter will keep adding more hash functions for every new sub-filter in order to keep your desired error rate.
121
121
@@ -127,26 +127,22 @@ If you know you're not going to scale use the `NONSCALING` flag because that way
127
127
128
128
### Total size of a Bloom filter
129
129
The actual memory used by a Bloom filter is a function of the chosen error rate:
130
-
```
131
-
bits_per_item = -log(error)/ln(2)
132
-
memory = capacity * bits_per_item
133
-
134
-
memory = capacity * (-log(error)/ln(2))
135
-
```
136
130
137
-
- 1% error rate requires 10.08 bits per item
138
-
- 0.1% error rate requires 14.4 bits per item
139
-
- 0.01% error rate requires 20.16 bits per item
131
+
The optimal number of hash functions is `ceil(-ln(error_rate) / ln(2))`.
132
+
133
+
The required number of bits per item, given the desired `error_rate` and the optimal number of hash functions, is `-ln(error_rate) / ln(2)^2`. Hence, the required number of bits in the filter is `capacity * -ln(error_rate) / ln(2)^2`.
134
+
135
+
***1%** error rate requires 7 hash functions and 9.585 bits per item.
136
+
***0.1%** error rate requires 10 hash functions and 14.378 bits per item.
137
+
***0.01%** error rate requires 14 hash functions and 19.170 bits per item.
140
138
141
139
Just as a comparison, when using a Redis set for membership testing the memory needed is:
142
140
143
141
```
144
142
memory_with_sets = capacity*(192b + value)
145
143
```
146
144
147
-
For a set of IP addresses, for example, we would have around 40 bytes (320 bits) per element, which is considerably higher than the 20 bits per element we need for a Bloom filter with 0.01% precision.
148
-
149
-
145
+
For a set of IP addresses, for example, we would have around 40 bytes (320 bits) per item - considerably higher than the 19.170 bits we need for a Bloom filter with a 0.01% false positives rate.
150
146
151
147
152
148
## Bloom vs. Cuckoo filters
@@ -159,7 +155,7 @@ Cuckoo filters are quicker on check operations and also allow deletions.
159
155
160
156
Insertion in a Bloom filter is O(K), where `k` is the number of hash functions.
161
157
162
-
Checking for an element is O(K) or O(K*n) for stacked filters, where n is the number of stacked filters.
158
+
Checking for an item is O(K) or O(K*n) for stacked filters, where n is the number of stacked filters.
0 commit comments