mirror of
https://github.com/facebook/rocksdb.git
synced 2024-11-26 16:30:56 +00:00
0050a73a4f
Summary: This change standardizes on a new 16-byte cache key format for block cache (incl compressed and secondary) and persistent cache (but not table cache and row cache). The goal is a really fast cache key with practically ideal stability and uniqueness properties without external dependencies (e.g. from FileSystem). A fixed key size of 16 bytes should enable future optimizations to the concurrent hash table for block cache, which is a heavy CPU user / bottleneck, but there appears to be measurable performance improvement even with no changes to LRUCache. This change replaces a lot of disjointed and ugly code handling cache keys with calls to a simple, clean new internal API (cache_key.h). (Preserving the old cache key logic under an option would be very ugly and likely negate the performance gain of the new approach. Complete replacement carries some inherent risk, but I think that's acceptable with sufficient analysis and testing.) The scheme for encoding new cache keys is complicated but explained in cache_key.cc. Also: EndianSwapValue is moved to math.h to be next to other bit operations. (Explains some new include "math.h".) ReverseBits operation added and unit tests added to hash_test for both. Fixes https://github.com/facebook/rocksdb/issues/7405 (presuming a root cause) Pull Request resolved: https://github.com/facebook/rocksdb/pull/9126 Test Plan: ### Basic correctness Several tests needed updates to work with the new functionality, mostly because we are no longer relying on filesystem for stable cache keys so table builders & readers need more context info to agree on cache keys. This functionality is so core, a huge number of existing tests exercise the cache key functionality. ### Performance Create db with `TEST_TMPDIR=/dev/shm ./db_bench -bloom_bits=10 -benchmarks=fillrandom -num=3000000 -partition_index_and_filters` And test performance with `TEST_TMPDIR=/dev/shm ./db_bench -readonly -use_existing_db -bloom_bits=10 -benchmarks=readrandom -num=3000000 -duration=30 -cache_index_and_filter_blocks -cache_size=250000 -threads=4` using DEBUG_LEVEL=0 and simultaneous before & after runs. Before ops/sec, avg over 100 runs: 121924 After ops/sec, avg over 100 runs: 125385 (+2.8%) ### Collision probability I have built a tool, ./cache_bench -stress_cache_key to broadly simulate host-wide cache activity over many months, by making some pessimistic simplifying assumptions: * Every generated file has a cache entry for every byte offset in the file (contiguous range of cache keys) * All of every file is cached for its entire lifetime We use a simple table with skewed address assignment and replacement on address collision to simulate files coming & going, with quite a variance (super-Poisson) in ages. Some output with `./cache_bench -stress_cache_key -sck_keep_bits=40`: ``` Total cache or DBs size: 32TiB Writing 925.926 MiB/s or 76.2939TiB/day Multiply by 9.22337e+18 to correct for simulation losses (but still assume whole file cached) ``` These come from default settings of 2.5M files per day of 32 MB each, and `-sck_keep_bits=40` means that to represent a single file, we are only keeping 40 bits of the 128-bit cache key. With file size of 2\*\*25 contiguous keys (pessimistic), our simulation is about 2\*\*(128-40-25) or about 9 billion billion times more prone to collision than reality. More default assumptions, relatively pessimistic: * 100 DBs in same process (doesn't matter much) * Re-open DB in same process (new session ID related to old session ID) on average every 100 files generated * Restart process (all new session IDs unrelated to old) 24 times per day After enough data, we get a result at the end: ``` (keep 40 bits) 17 collisions after 2 x 90 days, est 10.5882 days between (9.76592e+19 corrected) ``` If we believe the (pessimistic) simulation and the mathematical generalization, we would need to run a billion machines all for 97 billion days to expect a cache key collision. To help verify that our generalization ("corrected") is robust, we can make our simulation more precise with `-sck_keep_bits=41` and `42`, which takes more running time to get enough data: ``` (keep 41 bits) 16 collisions after 4 x 90 days, est 22.5 days between (1.03763e+20 corrected) (keep 42 bits) 19 collisions after 10 x 90 days, est 47.3684 days between (1.09224e+20 corrected) ``` The generalized prediction still holds. With the `-sck_randomize` option, we can see that we are beating "random" cache keys (except offsets still non-randomized) by a modest amount (roughly 20x less collision prone than random), which should make us reasonably comfortable even in "degenerate" cases: ``` 197 collisions after 1 x 90 days, est 0.456853 days between (4.21372e+18 corrected) ``` I've run other tests to validate other conditions behave as expected, never behaving "worse than random" unless we start chopping off structured data. Reviewed By: zhichao-cao Differential Revision: D33171746 Pulled By: pdillinger fbshipit-source-id: f16a57e369ed37be5e7e33525ace848d0537c88f
165 lines
5.1 KiB
C++
165 lines
5.1 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).
|
|
|
|
#include "env/unique_id_gen.h"
|
|
|
|
#include <algorithm>
|
|
#include <array>
|
|
#include <cstring>
|
|
#include <random>
|
|
|
|
#include "port/port.h"
|
|
#include "rocksdb/env.h"
|
|
#include "rocksdb/version.h"
|
|
#include "util/hash.h"
|
|
|
|
namespace ROCKSDB_NAMESPACE {
|
|
|
|
namespace {
|
|
|
|
struct GenerateRawUniqueIdOpts {
|
|
Env* env = Env::Default();
|
|
bool exclude_port_uuid = false;
|
|
bool exclude_env_details = false;
|
|
bool exclude_random_device = false;
|
|
};
|
|
|
|
// Each of these "tracks" below should be sufficient for generating 128 bits
|
|
// of entropy, after hashing the raw bytes. The tracks are separable for
|
|
// testing purposes, but in production we combine as many tracks as possible
|
|
// to ensure quality results even if some environments have degraded
|
|
// capabilities or quality in some APIs.
|
|
//
|
|
// This approach has not been validated for use in cryptography. The goal is
|
|
// generating globally unique values with high probability without coordination
|
|
// between instances.
|
|
//
|
|
// Linux performance: EntropyTrackRandomDevice is much faster than
|
|
// EntropyTrackEnvDetails, which is much faster than EntropyTrackPortUuid.
|
|
|
|
struct EntropyTrackPortUuid {
|
|
std::array<char, 36> uuid;
|
|
|
|
void Populate(const GenerateRawUniqueIdOpts& opts) {
|
|
if (opts.exclude_port_uuid) {
|
|
return;
|
|
}
|
|
std::string s;
|
|
port::GenerateRfcUuid(&s);
|
|
if (s.size() >= uuid.size()) {
|
|
std::copy_n(s.begin(), uuid.size(), uuid.begin());
|
|
}
|
|
}
|
|
};
|
|
|
|
struct EntropyTrackEnvDetails {
|
|
std::array<char, 64> hostname_buf;
|
|
int64_t process_id;
|
|
uint64_t thread_id;
|
|
int64_t unix_time;
|
|
uint64_t nano_time;
|
|
|
|
void Populate(const GenerateRawUniqueIdOpts& opts) {
|
|
if (opts.exclude_env_details) {
|
|
return;
|
|
}
|
|
opts.env->GetHostName(hostname_buf.data(), hostname_buf.size())
|
|
.PermitUncheckedError();
|
|
process_id = port::GetProcessID();
|
|
thread_id = opts.env->GetThreadID();
|
|
opts.env->GetCurrentTime(&unix_time).PermitUncheckedError();
|
|
nano_time = opts.env->NowNanos();
|
|
}
|
|
};
|
|
|
|
struct EntropyTrackRandomDevice {
|
|
using RandType = std::random_device::result_type;
|
|
static constexpr size_t kNumRandVals =
|
|
/* generous bits */ 192U / (8U * sizeof(RandType));
|
|
std::array<RandType, kNumRandVals> rand_vals;
|
|
|
|
void Populate(const GenerateRawUniqueIdOpts& opts) {
|
|
if (opts.exclude_random_device) {
|
|
return;
|
|
}
|
|
std::random_device r;
|
|
for (auto& val : rand_vals) {
|
|
val = r();
|
|
}
|
|
}
|
|
};
|
|
|
|
struct Entropy {
|
|
uint64_t version_identifier;
|
|
EntropyTrackRandomDevice et1;
|
|
EntropyTrackEnvDetails et2;
|
|
EntropyTrackPortUuid et3;
|
|
|
|
void Populate(const GenerateRawUniqueIdOpts& opts) {
|
|
// If we change the format of what goes into the entropy inputs, it's
|
|
// conceivable there could be a physical collision in the hash input
|
|
// even though they are logically different. This value should change
|
|
// if there's a change to the "schema" here, including byte order.
|
|
version_identifier = (uint64_t{ROCKSDB_MAJOR} << 32) +
|
|
(uint64_t{ROCKSDB_MINOR} << 16) +
|
|
uint64_t{ROCKSDB_PATCH};
|
|
et1.Populate(opts);
|
|
et2.Populate(opts);
|
|
et3.Populate(opts);
|
|
}
|
|
};
|
|
|
|
void GenerateRawUniqueIdImpl(uint64_t* a, uint64_t* b,
|
|
const GenerateRawUniqueIdOpts& opts) {
|
|
Entropy e;
|
|
std::memset(&e, 0, sizeof(e));
|
|
e.Populate(opts);
|
|
Hash2x64(reinterpret_cast<const char*>(&e), sizeof(e), a, b);
|
|
}
|
|
|
|
} // namespace
|
|
|
|
void GenerateRawUniqueId(uint64_t* a, uint64_t* b, bool exclude_port_uuid) {
|
|
GenerateRawUniqueIdOpts opts;
|
|
opts.exclude_port_uuid = exclude_port_uuid;
|
|
assert(!opts.exclude_env_details);
|
|
assert(!opts.exclude_random_device);
|
|
GenerateRawUniqueIdImpl(a, b, opts);
|
|
}
|
|
|
|
#ifndef NDEBUG
|
|
void TEST_GenerateRawUniqueId(uint64_t* a, uint64_t* b, bool exclude_port_uuid,
|
|
bool exclude_env_details,
|
|
bool exclude_random_device) {
|
|
GenerateRawUniqueIdOpts opts;
|
|
opts.exclude_port_uuid = exclude_port_uuid;
|
|
opts.exclude_env_details = exclude_env_details;
|
|
opts.exclude_random_device = exclude_random_device;
|
|
GenerateRawUniqueIdImpl(a, b, opts);
|
|
}
|
|
#endif
|
|
|
|
void SemiStructuredUniqueIdGen::Reset() {
|
|
saved_process_id_ = port::GetProcessID();
|
|
GenerateRawUniqueId(&base_upper_, &base_lower_);
|
|
counter_ = 0;
|
|
}
|
|
|
|
void SemiStructuredUniqueIdGen::GenerateNext(uint64_t* upper, uint64_t* lower) {
|
|
if (port::GetProcessID() == saved_process_id_) {
|
|
// Safe to increment the atomic for guaranteed uniqueness within this
|
|
// process lifetime. Xor slightly better than +. See
|
|
// https://github.com/pdillinger/unique_id
|
|
*lower = base_lower_ ^ counter_.fetch_add(1);
|
|
*upper = base_upper_;
|
|
} else {
|
|
// There must have been a fork() or something. Rather than attempting to
|
|
// update in a thread-safe way, simply fall back on GenerateRawUniqueId.
|
|
GenerateRawUniqueId(upper, lower);
|
|
}
|
|
}
|
|
|
|
} // namespace ROCKSDB_NAMESPACE
|