Since version 6.15 last year, RocksDB supports Ribbon filters, a new alternative to Bloom filters that save space, especially memory, at the cost of more CPU usage, mostly in constructing the filters in the background. Most applications with long-lived data (many hours or longer) will likely benefit from adopting a Ribbon+Bloom hybrid filter policy. Here we explain why and how.
Problem & background
Bloom filters play a critical role in optimizing point queries and
some range queries in LSM-tree storage systems like RocksDB. Very
large DBs can use 10% or more of their RAM memory for (Bloom) filters,
so that (average case) read performance can be very good despite high
(worst case) read amplification, which is useful for lowering write
format_version=5 Bloom filter in RocksDB is extremely
fast, all Bloom filters use around 50% more space than is
theoretically possible for a hashed structure configured for the same
false positive (FP) rate and number of keys added. What would it take
to save that significant share of “wasted” filter memory, and when
does it make sense to use such a Bloom alternative?
A number of alternatives to Bloom filters were known, especially for static filters (not modified after construction), but all the previously known structures were unsatisfying for SSTs because of some combination of
- Not enough space savings for CPU increase. For example, Xor filters use 3-4x more CPU than Bloom but only save 15-20% of space. GOV can save around 30% space but requires around 10x more CPU than Bloom.
- Inconsistent space savings. Cuckoo filters and Xor+ filters offer significant space savings for very low FP rates (high bits per key) but little or no savings for higher FP rates (low bits per key). (Higher FP rates are considered best for largest levels of LSM.) Spatially-coupled Xor filters require very large number of keys per filter for large space savings.
- Inflexible configuration. No published alternatives offered the same
continuous configurability of Bloom filters, where any FP rate and
any fractional bits per key could be chosen. This flexibility
improves memory efficiency with the
optimize_filters_for_memoryoption that minimizes internal fragmentation on filters.
Ribbon filter development and implementation
The Ribbon filter came about when I developed a faster, simpler, and more adaptable algorithm for constructing a little-known Xor-based structure from Dietzfelbinger and Walzer. It has very good space usage for required CPU time (~30% space savings for 3-4x CPU) and, with some engineering, Bloom-like configurability. The complications were managable for use in RocksDB:
- Ribbon space efficiency does not naturally scale to very large number of keys in a single filter (whole SST file or partition), but with the current 128-bit Ribbon implementation in RocksDB, even 100 million keys in one filter saves 27% space vs. Bloom rather than 30% for 100,000 keys in a filter.
- More temporary memory is required during construction, ~230 bits per
key for 128-bit Ribbon vs. ~75 bits per key for Bloom filter. A
quick calculation shows that if you are saving 3 bits per key on the
generated filter, you only need about 50 generated filters in memory
to offset this temporary memory usage. (Thousands of filters in
memory is typical.) Starting in RocksDB version 6.27, this temporary
memory can be accounted for under block cache using
- Ribbon filter queries use relatively more CPU for lower FP rates (but still O(1) relative to number of keys added to filter). This should be OK because lower FP rates are only appropriate when then cost of a false positive is very high (worth extra query time) or memory is not so constrained (can use Bloom instead).
Ribbon vs. Bloom in RocksDB configuration
Different applications and hardware configurations have different constraints, but we can use hardware costs to examine and better understand the trade-off between Bloom and Ribbon.
Same FP rate, RAM vs. CPU hardware cost
Under ideal conditions where we can adjust our hardware to suit the application, in terms of dollars, how much does it cost to construct, query, and keep in memory a Bloom filter vs. a Ribbon filter? The Ribbon filter costs more for CPU but less for RAM. Importantly, the RAM cost directly depends on how long the filter is kept in memory, which in RocksDB is essentially the lifetime of the filter. (Temporary RAM during construction is so short-lived that it is ignored.) Using some consumer hardware and electricity prices and a predicted balance between construction and queries, we can compute a “break even” duration in memory. To minimize cost, filters with a lifetime shorter than this should be Bloom and filters with a lifetime longer than this should be Ribbon. (Python code)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 # Commodity prices based roughly on consumer prices and rough guesses # Upfront cost of a CPU per hardware thread upfront_dollars_per_cpu_thread = 30.0 # CPU average power usage per hardware thread watts_per_cpu_thread = 3.5 # Upfront cost of a GB of RAM upfront_dollars_per_gb_ram = 8.0 # RAM average power usage per GB # https://www.crucial.com/support/articles-faq-memory/how-much-power-does-memory-use watts_per_gb_ram = 0.375 # Estimated price of power per kilowatt-hour, including overheads like conversion losses and cooling dollars_per_kwh = 0.35 # Assume 3 year hardware lifetime hours_per_lifetime = 3 * 365 * 24 seconds_per_lifetime = hours_per_lifetime * 60 * 60 # Number of filter queries per key added in filter construction is heavily dependent on workload. # When replication is in layer above RocksDB, it will be low, likely < 1. When replication is in # storage layer below RocksDB, it will likely be > 1. Using a rough and general guesstimate. key_query_per_construct = 1.0 #================================== # Bloom & Ribbon filter performance typical_bloom_bits_per_key = 10.0 typical_ribbon_bits_per_key = 7.0 # Speeds here are sensitive to many variables, especially query speed because it # is so dependent on memory latency. Using this benchmark here: # for IMPL in 2 3; do # ./filter_bench -impl=$IMPL -quick -m_keys_total_max=200 -use_full_block_reader # done # and "Random filter" queries. nanoseconds_per_construct_bloom_key = 32.0 nanoseconds_per_construct_ribbon_key = 140.0 nanoseconds_per_query_bloom_key = 500.0 nanoseconds_per_query_ribbon_key = 600.0 #================================== # Some constants kwh_per_watt_lifetime = hours_per_lifetime / 1000.0 bits_per_gb = 8 * 1024 * 1024 * 1024 #================================== # Crunching the numbers # on CPU for constructing filters dollars_per_cpu_thread_lifetime = upfront_dollars_per_cpu_thread + watts_per_cpu_thread * kwh_per_watt_lifetime * dollars_per_kwh dollars_per_cpu_thread_second = dollars_per_cpu_thread_lifetime / seconds_per_lifetime dollars_per_construct_bloom_key = dollars_per_cpu_thread_second * nanoseconds_per_construct_bloom_key / 10**9 dollars_per_construct_ribbon_key = dollars_per_cpu_thread_second * nanoseconds_per_construct_ribbon_key / 10**9 dollars_per_query_bloom_key = dollars_per_cpu_thread_second * nanoseconds_per_query_bloom_key / 10**9 dollars_per_query_ribbon_key = dollars_per_cpu_thread_second * nanoseconds_per_query_ribbon_key / 10**9 dollars_per_bloom_key_cpu = dollars_per_construct_bloom_key + key_query_per_construct * dollars_per_query_bloom_key dollars_per_ribbon_key_cpu = dollars_per_construct_ribbon_key + key_query_per_construct * dollars_per_query_ribbon_key # on holding filters in RAM dollars_per_gb_ram_lifetime = upfront_dollars_per_gb_ram + watts_per_gb_ram * kwh_per_watt_lifetime * dollars_per_kwh dollars_per_gb_ram_second = dollars_per_gb_ram_lifetime / seconds_per_lifetime dollars_per_bloom_key_in_ram_second = dollars_per_gb_ram_second / bits_per_gb * typical_bloom_bits_per_key dollars_per_ribbon_key_in_ram_second = dollars_per_gb_ram_second / bits_per_gb * typical_ribbon_bits_per_key #================================== # How many seconds does it take for the added cost of constructing a ribbon filter instead # of bloom to be offset by the added cost of holding the bloom filter in memory? break_even_seconds = (dollars_per_ribbon_key_cpu - dollars_per_bloom_key_cpu) / (dollars_per_bloom_key_in_ram_second - dollars_per_ribbon_key_in_ram_second) print(break_even_seconds) # -> 3235.1647730256936
So roughly speaking, filters that live in memory for more than an hour should be Ribbon, and filters that live less than an hour should be Bloom. This is very interesting, but how long do filters live in RocksDB?
First let’s consider the average case. Write-heavy RocksDB loads are often backed by flash storage, which has some specified write endurance for its intended lifetime. This can be expressed as device writes per day (DWPD), and supported DWPD is typically < 10.0 even for high end devices (excluding NVRAM). Roughly speaking, the DB would need to be writing at a rate of 20+ DWPD for data to have an average lifetime of less than one hour. Thus, unless you are prematurely burning out your flash or massively under-utilizing available storage, using the Ribbon filter has the better cost profile on average.
But we can do even better than optimizing for the average case. LSM
levels give us very strong data lifetime hints. Data in L0 might live
for minutes or a small number of hours. Data in Lmax might live for
days or weeks. So even if Ribbon filters weren’t the best choice on
average for a workload, they almost certainly make sense for the
larger, longer-lived levels of the LSM. As of RocksDB 6.24, you can
specify a minimum LSM level for Ribbon filters with
NewRibbonFilterPolicy, and earlier levels will use Bloom filters.
Resident filter memory
The above analysis assumes that nearly all filters for all live SST
files are resident in memory. This is true if using
cache_index_and_filter_blocks=1 is popular. In that case,
if you use
optimize_filters_for_hits=1 and non-partitioned filters
(a popular MyRocks configuration), it is also likely that nearly all
live filters are in memory. However, if you don’t use
optimize_filters_for_hits and use partitioned filters, then
cold data (by age or by key range) can lead to only a portion of
filters being resident in memory. In that case, benefit from Ribbon
filter is not as clear, though because Ribbon filters are smaller,
they are more efficient to read into memory.
RocksDB version 6.21 and later include a rough feature to determine
block cache usage for data blocks, filter blocks, index blocks, etc.
Data like this is periodically dumped to LOG file
1 2 Block cache entry stats(count,size,portion): DataBlock(441761,6.82 GB,75.765%) FilterBlock(3002,1.27 GB,14.1387%) IndexBlock(17777,887.75 MB,9.63267%) Misc(1,0.00 KB,0%) Block cache LRUCache@0x7fdd08104290#7004432 capacity: 9.00 GB collections: 2573 last_copies: 10 last_secs: 0.143248 secs_since: 0
This indicates that at this moment in time, the block cache object
LRUCache@0x7fdd08104290#7004432 (potentially used
by multiple DBs) uses roughly 14% of its 9GB, about 1.27 GB, on filter
blocks. This same data is available through
DB::Properties::kBlockCacheEntryStats, and (with some effort) can
be compared to total size of all filters (not necessarily in memory)
Sanity checking lifetime
Can we be sure that using filters even makes sense for such long-lived data? We can apply the current 5 minute rule for caching SSD data in RAM. A 4KB filter page holds data for roughly 4K keys. If we assume at least one negative (useful) filter query in its lifetime per added key, it can satisfy the 5 minute rule with a lifetime of up to about two weeks. Thus, the lifetime threshold for “no filter” is about 300x higher than the lifetime threshold for Ribbon filter.
What to do with saved memory
The default way to improve overall RocksDB performance with more
available memory is to use more space for caching, which improves
latency, CPU load, read IOs, etc. With
cache_index_and_filter_blocks=1, savings in filters will
automatically make room for caching more data blocks in block
cache_index_and_filter_blocks=0, consider increasing
block cache size.
Using the space savings to lower filter FP rates is also an option, but there is less evidence for this commonly improving existing optimized configurations.
NewBloomFilterPolicy(bpk) for a large persistent DB using
compression, try using
NewRibbonFilterPolicy(bpk) instead, which
will generate Ribbon filters during compaction and Bloom filters
for flush, both with the same FP rate as the old setting. Once new SST
files are generated under the new policy, this should free up some
memory for more caching without much effect on burst or sustained
write speed. Both kinds of filters can be read under either policy, so
there’s always an option to adjust settings or gracefully roll back to
using Bloom filter only (keeping in mind that SST files must be
replaced to see effect of that change).