在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
开源软件名称:Leveldb_old1开源软件地址:https://gitee.com/mirrors/Leveldb_old1开源软件介绍:LevelDB is a fast key-value storage library written at Google that provides an ordered mapping from string keys to string values. Authors: Sanjay Ghemawat ([email protected]) and Jeff Dean ([email protected]) Features
DocumentationLevelDB library documentation is online and bundled with the source code. Limitations
Getting the Sourcegit clone --recurse-submodules https://github.com/google/leveldb.git BuildingThis project supports CMake out of the box. Build for POSIXQuick start: mkdir -p build && cd buildcmake -DCMAKE_BUILD_TYPE=Release .. && cmake --build . Building for WindowsFirst generate the Visual Studio 2017 project/solution files: mkdir buildcd buildcmake -G "Visual Studio 15" .. The default default will build for x86. For 64-bit run: cmake -G "Visual Studio 15 Win64" .. To compile the Windows solution from the command-line: devenv /build Debug leveldb.sln or open leveldb.sln in Visual Studio and build from within. Please see the CMake documentation and Contributing to the leveldb ProjectThe leveldb project welcomes contributions. leveldb's primary goal is to bea reliable and fast key/value store. Changes that are in line with thefeatures/limitations outlined above, and meet the requirements below,will be considered. Contribution requirements:
We are unlikely to accept contributions to the build configuration files, suchas Submitting a Pull RequestBefore any pull request will be accepted the author must first sign aContributor License Agreement (CLA) at https://cla.developers.google.com/. In order to keep the commit timeline linearsquashyour changes down to a single commit and rebaseon google/leveldb/main. This keeps the commit timeline linear and more easily sync'edwith the internal repository at Google. More information at GitHub'sAbout Git rebase page. PerformanceHere is a performance report (with explanations) from the run of theincluded db_bench program. The results are somewhat noisy, but shouldbe enough to get a ballpark performance estimate. SetupWe use a database with a million entries. Each entry has a 16 bytekey, and a 100 byte value. Values used by the benchmark compress toabout half their original size. LevelDB: version 1.1Date: Sun May 1 12:11:26 2011CPU: 4 x Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHzCPUCache: 4096 KBKeys: 16 bytes eachValues: 100 bytes each (50 bytes after compression)Entries: 1000000Raw Size: 110.6 MB (estimated)File Size: 62.9 MB (estimated) Write performanceThe "fill" benchmarks create a brand new database, in eithersequential, or random order. The "fillsync" benchmark flushes datafrom the operating system to the disk after every operation; the otherwrite operations leave the data sitting in the operating system buffercache for a while. The "overwrite" benchmark does random writes thatupdate existing keys in the database. fillseq : 1.765 micros/op; 62.7 MB/sfillsync : 268.409 micros/op; 0.4 MB/s (10000 ops)fillrandom : 2.460 micros/op; 45.0 MB/soverwrite : 2.380 micros/op; 46.5 MB/s Each "op" above corresponds to a write of a single key/value pair.I.e., a random write benchmark goes at approximately 400,000 writes per second. Each "fillsync" operation costs much less (0.3 millisecond)than a disk seek (typically 10 milliseconds). We suspect that this isbecause the hard disk itself is buffering the update in its memory andresponding before the data has been written to the platter. This mayor may not be safe based on whether or not the hard disk has enoughpower to save its memory in the event of a power failure. Read performanceWe list the performance of reading sequentially in both the forwardand reverse direction, and also the performance of a random lookup.Note that the database created by the benchmark is quite small.Therefore the report characterizes the performance of leveldb when theworking set fits in memory. The cost of reading a piece of data thatis not present in the operating system buffer cache will be dominatedby the one or two disk seeks needed to fetch the data from disk.Write performance will be mostly unaffected by whether or not theworking set fits in memory. readrandom : 16.677 micros/op; (approximately 60,000 reads per second)readseq : 0.476 micros/op; 232.3 MB/sreadreverse : 0.724 micros/op; 152.9 MB/s LevelDB compacts its underlying storage data in the background toimprove read performance. The results listed above were doneimmediately after a lot of random writes. The results aftercompactions (which are usually triggered automatically) are better. readrandom : 11.602 micros/op; (approximately 85,000 reads per second)readseq : 0.423 micros/op; 261.8 MB/sreadreverse : 0.663 micros/op; 166.9 MB/s Some of the high cost of reads comes from repeated decompression of blocksread from disk. If we supply enough cache to the leveldb so it can hold theuncompressed blocks in memory, the read performance improves again: readrandom : 9.775 micros/op; (approximately 100,000 reads per second before compaction)readrandom : 5.215 micros/op; (approximately 190,000 reads per second after compaction) Repository contentsSee doc/index.md for more explanation. Seedoc/impl.md for a brief overview of the implementation. The public interface is in include/leveldb/*.h. Callers should not include orrely on the details of any other header files in this package. Thoseinternal APIs may be changed without warning. Guide to header files:
|
请发表评论