mirror of
https://github.com/facebook/rocksdb.git
synced 2024-12-04 20:02:50 +00:00
86a1e3e0e7
Summary: ... so that cache keys can be derived from DB manifest data before reading the file from storage--so that every part of the file can potentially go in a persistent cache. See updated comments in cache_key.cc for technical details. Importantly, the new cache key encoding uses some fancy but efficient math to pack data into the cache key without depending on the sizes of the various pieces. This simplifies some existing code creating cache keys, like cache warming before the file size is known. This should provide us an essentially permanent mapping between SST unique IDs and base cache keys, with the ability to "upgrade" SST unique IDs (and thus cache keys) with new SST format_versions. These cache keys are of similar, perhaps indistinguishable quality to the previous generation. Before this change (see "corrected" days between collision): ``` ./cache_bench -stress_cache_key -sck_keep_bits=43 18 collisions after 2 x 90 days, est 10 days between (1.15292e+19 corrected) ``` After this change (keep 43 bits, up through 50, to validate "trajectory" is ok on "corrected" days between collision): ``` 19 collisions after 3 x 90 days, est 14.2105 days between (1.63836e+19 corrected) 16 collisions after 5 x 90 days, est 28.125 days between (1.6213e+19 corrected) 15 collisions after 7 x 90 days, est 42 days between (1.21057e+19 corrected) 15 collisions after 17 x 90 days, est 102 days between (1.46997e+19 corrected) 15 collisions after 49 x 90 days, est 294 days between (2.11849e+19 corrected) 15 collisions after 62 x 90 days, est 372 days between (1.34027e+19 corrected) 15 collisions after 53 x 90 days, est 318 days between (5.72858e+18 corrected) 15 collisions after 309 x 90 days, est 1854 days between (1.66994e+19 corrected) ``` However, the change does modify (probably weaken) the "guaranteed unique" promise from this > SST files generated in a single process are guaranteed to have unique cache keys, unless/until number session ids * max file number = 2**86 to this (see https://github.com/facebook/rocksdb/issues/10388) > With the DB id limitation, we only have nice guaranteed unique cache keys for files generated in a single process until biggest session_id_counter and offset_in_file reach combined 64 bits I don't think this is a practical concern, though. Pull Request resolved: https://github.com/facebook/rocksdb/pull/10394 Test Plan: unit tests updated, see simulation results above Reviewed By: jay-zhuang Differential Revision: D38667529 Pulled By: pdillinger fbshipit-source-id: 49af3fe7f47e5b61162809a78b76c769fd519fba
94 lines
3.8 KiB
C++
94 lines
3.8 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 "rocksdb/unique_id.h"
|
|
|
|
namespace ROCKSDB_NAMESPACE {
|
|
|
|
// Standard size unique ID, good enough for almost all practical purposes
|
|
using UniqueId64x2 = std::array<uint64_t, 2>;
|
|
|
|
// Value never used as an actual unique ID so can be used for "null"
|
|
constexpr UniqueId64x2 kNullUniqueId64x2 = {};
|
|
|
|
// Extended size unique ID, for extra certainty of uniqueness among SST files
|
|
// spanning many hosts over a long time (rarely if ever needed)
|
|
using UniqueId64x3 = std::array<uint64_t, 3>;
|
|
|
|
// Value never used as an actual unique ID so can be used for "null"
|
|
constexpr UniqueId64x3 kNullUniqueId64x3 = {};
|
|
|
|
// Dynamic pointer wrapper for one of the two above
|
|
struct UniqueIdPtr {
|
|
uint64_t *ptr = nullptr;
|
|
bool extended = false;
|
|
|
|
/*implicit*/ UniqueIdPtr(UniqueId64x2 *id) {
|
|
ptr = (*id).data();
|
|
extended = false;
|
|
}
|
|
/*implicit*/ UniqueIdPtr(UniqueId64x3 *id) {
|
|
ptr = (*id).data();
|
|
extended = true;
|
|
}
|
|
};
|
|
|
|
// Helper for GetUniqueIdFromTableProperties. This function can also be used
|
|
// for temporary ids for files without sufficient information in table
|
|
// properties. The internal unique id is more structured than the public
|
|
// unique id, so can be manipulated in more ways but very carefully.
|
|
// These must be long term stable to ensure GetUniqueIdFromTableProperties
|
|
// is long term stable.
|
|
Status GetSstInternalUniqueId(const std::string &db_id,
|
|
const std::string &db_session_id,
|
|
uint64_t file_number, UniqueIdPtr out,
|
|
bool force = false);
|
|
|
|
// Helper for GetUniqueIdFromTableProperties. External unique ids go through
|
|
// this extra hashing layer so that prefixes of the unique id have predictable
|
|
// "full" entropy. This hashing layer is 1-to-1 on the first 128 bits and on
|
|
// the full 192 bits.
|
|
// This transformation must be long term stable to ensure
|
|
// GetUniqueIdFromTableProperties is long term stable.
|
|
void InternalUniqueIdToExternal(UniqueIdPtr in_out);
|
|
|
|
// Reverse of InternalUniqueIdToExternal mostly for testing purposes
|
|
// (demonstrably 1-to-1 on the first 128 bits and on the full 192 bits).
|
|
void ExternalUniqueIdToInternal(UniqueIdPtr in_out);
|
|
|
|
// Convert numerical format to byte format for public API
|
|
std::string EncodeUniqueIdBytes(UniqueIdPtr in);
|
|
|
|
// Reverse of EncodeUniqueIdBytes.
|
|
Status DecodeUniqueIdBytes(const std::string &unique_id, UniqueIdPtr out);
|
|
|
|
// For presenting internal IDs for debugging purposes. Visually distinct from
|
|
// UniqueIdToHumanString for external IDs.
|
|
std::string InternalUniqueIdToHumanString(UniqueIdPtr in);
|
|
|
|
// Reformat a random value down to our "DB session id" format,
|
|
// which is intended to be compact and friendly for use in file names.
|
|
// `lower` is fully preserved and data is lost from `upper`.
|
|
//
|
|
// Detail: Encoded into 20 chars in base-36 ([0-9A-Z]), which is ~103 bits of
|
|
// entropy, which is enough to expect no collisions across a billion servers
|
|
// each opening DBs a million times (~2^50). Benefits vs. RFC-4122 unique id:
|
|
// * Save ~ dozen bytes per SST file
|
|
// * Shorter shared backup file names (some platforms have low limits)
|
|
// * Visually distinct from DB id format (usually RFC-4122)
|
|
std::string EncodeSessionId(uint64_t upper, uint64_t lower);
|
|
|
|
// Reverse of EncodeSessionId. Returns NotSupported on error rather than
|
|
// Corruption because non-standard session IDs should be allowed with degraded
|
|
// functionality.
|
|
Status DecodeSessionId(const std::string &db_session_id, uint64_t *upper,
|
|
uint64_t *lower);
|
|
|
|
} // namespace ROCKSDB_NAMESPACE
|