mirror of
https://github.com/facebook/rocksdb.git
synced 2024-11-27 02:44:18 +00:00
9a357847eb
Summary: LevelDB should delete almost-new keys when a long-open snapshot exists. The previous behavior is to keep all versions that were created after the oldest open snapshot. This can lead to database size bloat for high-update workloads when there are long-open snapshots and long-open snapshot will be used for logical backup. By "almost new" I mean that the key was updated more than once after the oldest snapshot. If there were two snapshots with seq numbers s1 and s2 (s1 < s2), and if we find two instances of the same key k1 that lie entirely within s1 and s2 (i.e. s1 < k1 < s2), then the earlier version of k1 can be safely deleted because that version is not visible in any snapshot. Test Plan: unit test attached make clean check Differential Revision: https://reviews.facebook.net/D6999 |
||
---|---|---|
db | ||
doc | ||
hdfs | ||
helpers/memenv | ||
include/leveldb | ||
java | ||
linters/src | ||
port | ||
scribe | ||
snappy | ||
table | ||
thrift | ||
tools | ||
util | ||
.arcconfig | ||
.gitignore | ||
AUTHORS | ||
build_detect_platform | ||
build_detect_version | ||
fbcode.gcc471.sh | ||
LICENSE | ||
Makefile | ||
NEWS | ||
README | ||
README.fb | ||
TODO |
leveldb: A key-value store Authors: Sanjay Ghemawat (sanjay@google.com) and Jeff Dean (jeff@google.com) The code under this directory implements a system for maintaining a persistent key/value store. See doc/index.html for more explanation. See doc/impl.html for a brief overview of the implementation. The public interface is in include/*.h. Callers should not include or rely on the details of any other header files in this package. Those internal APIs may be changed without warning. Guide to header files: include/db.h Main interface to the DB: Start here include/options.h Control over the behavior of an entire database, and also control over the behavior of individual reads and writes. include/comparator.h Abstraction for user-specified comparison function. If you want just bytewise comparison of keys, you can use the default comparator, but clients can write their own comparator implementations if they want custom ordering (e.g. to handle different character encodings, etc.) include/iterator.h Interface for iterating over data. You can get an iterator from a DB object. include/write_batch.h Interface for atomically applying multiple updates to a database. include/slice.h A simple module for maintaining a pointer and a length into some other byte array. include/status.h Status is returned from many of the public interfaces and is used to report success and various kinds of errors. include/env.h Abstraction of the OS environment. A posix implementation of this interface is in util/env_posix.cc include/table.h include/table_builder.h Lower-level modules that most clients probably won't use directly