LevelDB

LevelDB is a fast key-value storage library written at Google that provides an ordered mapping from string keys to string values. This repository is receiving very limited maintenance. We will only review the following types of changes. Fixes for critical bugs, such as data loss or memory corruption Changes absolutely needed by internally supported leveldb clients. These typically fix breakage introduced by a language/standard library/OS update Keys and values are arbitrary byte arrays. Data is stored sorted by key. Callers can provide a custom comparison function to override the sort order. The basic operations are Put(key,value) , Get(key) , Delete(key) . Multiple changes can be made in one atomic batch. Users can create a transient snapshot to get a consistent view of data. Forward and backward iteration is supported over the data. Data is automatically compressed using the Snappy compression library, but Zstd compression is also supported. External activity (file system operations etc.) is relayed through a virtual interface so users can customize the operating system interactions. This is not a SQL database. It does not have a relational data model, it does not support SQL queries, and it has no support for indexes. Only a single process (possibly multi-threaded) can access a particular database at a time. There is no client-server support builtin to the library. An application that needs such support will have to wrap their own server around the library. This repository is receiving very limited maintenance. We will only review the following types of changes. Bug fixes Changes absolutely needed by internally supported leveldb clients. These typically fix breakage introduced by a language/standard library/OS update The leveldb project welcomes contributions. leveldb's primary goal is to be a reliable and fast key/value store. Changes that are in line with the features/limitations outlined above, and meet the requirements below, will be considered. 1. Tested platforms only . We generally will only accept changes for platforms that are compiled and tested. This means POSIX (for Linux and macOS) or Windows. Very small changes will sometimes be accepted, but consider that more of an exception than the rule. 2. Stable API . We strive very hard to maintain a stable API. Changes that require changes for projects using leveldb might be rejected without sufficient benefit to the project. 4. Consistent Style : This project conforms to the Google C++ Style Guide. To ensure your changes are properly formatted please run: In order to keep the commit timeline linear squash your changes down to a single commit and rebase on google/leveldb/main. This keeps the commit timeline linear and more easily sync'ed with the internal repository at Google. More information at GitHub's About Git rebase page. Here is a performance report (with explanations) from the run of the included db bench program. The results are somewhat noisy, but should be enough to get a ballpark performance estimate. We use a database with a million entries. Each entry has a 16 byte key, and a 100 byte value. Values used by the benchmark compress to about half their original size. The "fill" benchmarks create a brand new database, in either sequential, or random order. The "fillsync" benchmark flushes data from the operating system to the disk after every operation; the other write operations leave the data sitting in the operating system buffer cache for a while. The "overwrite" benchmark does random writes that update existing keys in the database. Each "fillsync" operation costs much less (0.3 millisecond) than a disk seek (typically 10 milliseconds). We suspect that this is because the hard disk itself is buffering the update in its memory and responding before the data has been written to the platter. This may or may not be safe based on whether or not the hard disk has enough power to save its memory in the event of a power failure. We list the perfor