mirror of
https://github.com/facebook/rocksdb.git
synced 2024-12-04 20:02:50 +00:00
a8b3b9a20c
Summary: This change only affects non-schema-critical aspects of the production candidate Ribbon filter. Specifically, it refines choice of internal configuration parameters based on inputs. The changes are minor enough that the schema tests in bloom_test, some of which depend on this, are unaffected. There are also some minor optimizations and refactorings. This would be a schema change for "smash" Ribbon, to fix some known issues with small filters, but "smash" Ribbon is not accessible in public APIs. Unit test CompactnessAndBacktrackAndFpRate updated to test small and medium-large filters. Run with --thoroughness=100 or so for much better detection power (not appropriate for continuous regression testing). Homogenous Ribbon: This change adds internally a Ribbon filter variant we call Homogeneous Ribbon, in collaboration with Stefan Walzer. The expected "result" value for every key is zero, instead of computed from a hash. Entropy for queries not to be false positives comes from free variables ("overhead") in the solution structure, which are populated pseudorandomly. Construction is slightly faster for not tracking result values, and never fails. Instead, FP rate can jump up whenever and whereever entries are packed too tightly. For small structures, we can choose overhead to make this FP rate jump unlikely, as seen in updated unit test CompactnessAndBacktrackAndFpRate. Unlike standard Ribbon, Homogeneous Ribbon seems to scale to arbitrary number of keys when accepting an FP rate penalty for small pockets of high FP rate in the structure. For example, 64-bit ribbon with 8 solution columns and 10% allocated space overhead for slots seems to achieve about 10.5% space overhead vs. information-theoretic minimum based on its observed FP rate with expected pockets of degradation. (FP rate is close to 1/256.) If targeting a higher FP rate with fewer solution columns, Homogeneous Ribbon can be even more space efficient, because the penalty from degradation is relatively smaller. If targeting a lower FP rate, Homogeneous Ribbon is less space efficient, as more allocated overhead is needed to keep the FP rate impact of degradation relatively under control. The new OptimizeHomogAtScale tool in ribbon_test helps to find these optimal allocation overheads for different numbers of solution columns. And Ribbon widths, with 128-bit Ribbon apparently cutting space overheads in half vs. 64-bit. Other misc item specifics: * Ribbon APIs in util/ribbon_config.h now provide configuration data for not just 5% construction failure rate (95% success), but also 50% and 0.1%. * Note that the Ribbon structure does not exhibit "threshold" behavior as standard Xor filter does, so there is a roughly fixed space penalty to cut construction failure rate in half. Thus, there isn't really an "almost sure" setting. * Although we can extrapolate settings for large filters, we don't have a good formula for configuring smaller filters (< 2^17 slots or so), and efforts to summarize with a formula have failed. Thus, small data is hard-coded from updated FindOccupancy tool. * Enhances ApproximateNumEntries for public API Ribbon using more precise data (new API GetNumToAdd), thus a more accurate but not perfect reversal of CalculateSpace. (bloom_test updated to expect the greater precision) * Move EndianSwapValue from coding.h to coding_lean.h to keep Ribbon code easily transferable from RocksDB * Add some missing 'const' to member functions * Small optimization to 128-bit BitParity * Small refactoring of BandingStorage in ribbon_alg.h to support Homogeneous Ribbon * CompactnessAndBacktrackAndFpRate now has an "expand" test: on construction failure, a possible alternative to re-seeding hash functions is simply to increase the number of slots (allocated space overhead) and try again with essentially the same hash values. (Start locations will be different roundings of the same scaled hash values--because fastrange not mod.) This seems to be as effective or more effective than re-seeding, as long as we increase the number of slots (m) by roughly m += m/w where w is the Ribbon width. This way, there is effectively an expansion by one slot for each ribbon-width window in the banding. (This approach assumes that getting "bad data" from your hash function is as unlikely as it naturally should be, e.g. no adversary.) * 32-bit and 16-bit Ribbon configurations are added to ribbon_test for understanding their behavior, e.g. with FindOccupancy. They are not considered useful at this time and not tested with CompactnessAndBacktrackAndFpRate. Pull Request resolved: https://github.com/facebook/rocksdb/pull/7879 Test Plan: unit test updates included Reviewed By: jay-zhuang Differential Revision: D26371245 Pulled By: pdillinger fbshipit-source-id: da6600d90a3785b99ad17a88b2a3027710b4ea3a
183 lines
6.2 KiB
C++
183 lines
6.2 KiB
C++
// Copyright (c) Facebook, Inc. and its affiliates. All Rights Reserved.
|
|
// This source code is licensed under both the GPLv2 (found in the
|
|
// COPYING file in the root directory) and Apache 2.0 License
|
|
// (found in the LICENSE.Apache file in the root directory).
|
|
|
|
#pragma once
|
|
|
|
#include <array>
|
|
#include <cassert>
|
|
#include <cmath>
|
|
#include <cstdint>
|
|
|
|
#include "port/lang.h" // for FALLTHROUGH_INTENDED
|
|
#include "rocksdb/rocksdb_namespace.h"
|
|
|
|
namespace ROCKSDB_NAMESPACE {
|
|
|
|
namespace ribbon {
|
|
|
|
// RIBBON PHSF & RIBBON Filter (Rapid Incremental Boolean Banding ON-the-fly)
|
|
//
|
|
// ribbon_config.h: APIs for relating numbers of slots with numbers of
|
|
// additions for tolerable construction failure probabilities. This is
|
|
// separate from ribbon_impl.h because it might not be needed for
|
|
// some applications.
|
|
//
|
|
// This API assumes uint32_t for number of slots, as a single Ribbon
|
|
// linear system should not normally overflow that without big penalties.
|
|
//
|
|
// Template parameter kCoeffBits uses uint64_t for convenience in case it
|
|
// comes from size_t.
|
|
//
|
|
// Most of the complexity here is trying to optimize speed and
|
|
// compiled code size, using templates to minimize table look-ups and
|
|
// the compiled size of all linked look-up tables. Look-up tables are
|
|
// required because we don't have good formulas, and the data comes
|
|
// from running FindOccupancy in ribbon_test.
|
|
|
|
// Represents a chosen chance of successful Ribbon construction for a single
|
|
// seed. Allowing higher chance of failed construction can reduce space
|
|
// overhead but takes extra time in construction.
|
|
enum ConstructionFailureChance {
|
|
kOneIn2,
|
|
kOneIn20,
|
|
// When using kHomogeneous==true, construction failure chance should
|
|
// not generally exceed target FP rate, so it unlikely useful to
|
|
// allow a higher "failure" chance. In some cases, even more overhead
|
|
// is appropriate. (TODO)
|
|
kOneIn1000,
|
|
};
|
|
|
|
namespace detail {
|
|
|
|
// It is useful to compile ribbon_test linking to BandingConfigHelper with
|
|
// settings for which we do not have configuration data, as long as we don't
|
|
// run the code. This template hack supports that.
|
|
template <ConstructionFailureChance kCfc, uint64_t kCoeffBits, bool kUseSmash,
|
|
bool kHomogeneous, bool kIsSupported>
|
|
struct BandingConfigHelper1MaybeSupported {
|
|
public:
|
|
static uint32_t GetNumToAdd(uint32_t num_slots) {
|
|
// Unsupported
|
|
assert(num_slots == 0);
|
|
(void)num_slots;
|
|
return 0;
|
|
}
|
|
|
|
static uint32_t GetNumSlots(uint32_t num_to_add) {
|
|
// Unsupported
|
|
assert(num_to_add == 0);
|
|
(void)num_to_add;
|
|
return 0;
|
|
}
|
|
};
|
|
|
|
// Base class for BandingConfigHelper1 and helper for BandingConfigHelper
|
|
// with core implementations built on above data
|
|
template <ConstructionFailureChance kCfc, uint64_t kCoeffBits, bool kUseSmash,
|
|
bool kHomogeneous>
|
|
struct BandingConfigHelper1MaybeSupported<
|
|
kCfc, kCoeffBits, kUseSmash, kHomogeneous, true /* kIsSupported */> {
|
|
public:
|
|
// See BandingConfigHelper1. Implementation in ribbon_config.cc
|
|
static uint32_t GetNumToAdd(uint32_t num_slots);
|
|
|
|
// See BandingConfigHelper1. Implementation in ribbon_config.cc
|
|
static uint32_t GetNumSlots(uint32_t num_to_add);
|
|
};
|
|
|
|
} // namespace detail
|
|
|
|
template <ConstructionFailureChance kCfc, uint64_t kCoeffBits, bool kUseSmash,
|
|
bool kHomogeneous>
|
|
struct BandingConfigHelper1
|
|
: public detail::BandingConfigHelper1MaybeSupported<
|
|
kCfc, kCoeffBits, kUseSmash, kHomogeneous,
|
|
/* kIsSupported */ kCoeffBits == 64 || kCoeffBits == 128> {
|
|
public:
|
|
// Returns a number of entries that can be added to a given number of
|
|
// slots, with roughly kCfc chance of construction failure per seed,
|
|
// or better. Does NOT do rounding for InterleavedSoln; call
|
|
// RoundUpNumSlots for that.
|
|
//
|
|
// inherited:
|
|
// static uint32_t GetNumToAdd(uint32_t num_slots);
|
|
|
|
// Returns a number of slots for a given number of entries to add
|
|
// that should have roughly kCfc chance of construction failure per
|
|
// seed, or better. Does NOT do rounding for InterleavedSoln; call
|
|
// RoundUpNumSlots for that.
|
|
//
|
|
// num_to_add should not exceed roughly 2/3rds of the maximum value
|
|
// of the uint32_t type to avoid overflow.
|
|
//
|
|
// inherited:
|
|
// static uint32_t GetNumSlots(uint32_t num_to_add);
|
|
};
|
|
|
|
// Configured using TypesAndSettings as in ribbon_impl.h
|
|
template <ConstructionFailureChance kCfc, class TypesAndSettings>
|
|
struct BandingConfigHelper1TS
|
|
: public BandingConfigHelper1<
|
|
kCfc,
|
|
/* kCoeffBits */ sizeof(typename TypesAndSettings::CoeffRow) * 8U,
|
|
TypesAndSettings::kUseSmash, TypesAndSettings::kHomogeneous> {};
|
|
|
|
// Like BandingConfigHelper1TS except failure chance can be a runtime rather
|
|
// than compile time value.
|
|
template <class TypesAndSettings>
|
|
struct BandingConfigHelper {
|
|
public:
|
|
static constexpr ConstructionFailureChance kDefaultFailureChance =
|
|
TypesAndSettings::kHomogeneous ? kOneIn1000 : kOneIn20;
|
|
|
|
static uint32_t GetNumToAdd(
|
|
uint32_t num_slots,
|
|
ConstructionFailureChance max_failure = kDefaultFailureChance) {
|
|
switch (max_failure) {
|
|
default:
|
|
assert(false);
|
|
FALLTHROUGH_INTENDED;
|
|
case kOneIn20: {
|
|
using H1 = BandingConfigHelper1TS<kOneIn20, TypesAndSettings>;
|
|
return H1::GetNumToAdd(num_slots);
|
|
}
|
|
case kOneIn2: {
|
|
using H1 = BandingConfigHelper1TS<kOneIn2, TypesAndSettings>;
|
|
return H1::GetNumToAdd(num_slots);
|
|
}
|
|
case kOneIn1000: {
|
|
using H1 = BandingConfigHelper1TS<kOneIn1000, TypesAndSettings>;
|
|
return H1::GetNumToAdd(num_slots);
|
|
}
|
|
}
|
|
}
|
|
|
|
static uint32_t GetNumSlots(
|
|
uint32_t num_to_add,
|
|
ConstructionFailureChance max_failure = kDefaultFailureChance) {
|
|
switch (max_failure) {
|
|
default:
|
|
assert(false);
|
|
FALLTHROUGH_INTENDED;
|
|
case kOneIn20: {
|
|
using H1 = BandingConfigHelper1TS<kOneIn20, TypesAndSettings>;
|
|
return H1::GetNumSlots(num_to_add);
|
|
}
|
|
case kOneIn2: {
|
|
using H1 = BandingConfigHelper1TS<kOneIn2, TypesAndSettings>;
|
|
return H1::GetNumSlots(num_to_add);
|
|
}
|
|
case kOneIn1000: {
|
|
using H1 = BandingConfigHelper1TS<kOneIn1000, TypesAndSettings>;
|
|
return H1::GetNumSlots(num_to_add);
|
|
}
|
|
}
|
|
}
|
|
};
|
|
|
|
} // namespace ribbon
|
|
|
|
} // namespace ROCKSDB_NAMESPACE
|