16
16
* External activity (file system operations etc.) is relayed through a virtual interface so users can customize the operating system interactions.
17
17
18
18
# Documentation
19
- [ LevelDB library documentation] ( https://rawgit.com/google/leveldb/master/doc/index.html ) is online and bundled with the source code.
19
+ [ LevelDB library documentation] ( https://rawgit.com/google/leveldb/master/doc/index.md ) is online and bundled with the source code.
20
20
21
21
22
22
# Limitations
@@ -113,29 +113,30 @@ by the one or two disk seeks needed to fetch the data from disk.
113
113
Write performance will be mostly unaffected by whether or not the
114
114
working set fits in memory.
115
115
116
- readrandom : 16.677 micros/op; (approximately 60,000 reads per second)
117
- readseq : 0.476 micros/op; 232.3 MB/s
118
- readreverse : 0.724 micros/op; 152.9 MB/s
116
+ readrandom : 16.677 micros/op; (approximately 60,000 reads per second)
117
+ readseq : 0.476 micros/op; 232.3 MB/s
118
+ readreverse : 0.724 micros/op; 152.9 MB/s
119
119
120
120
LevelDB compacts its underlying storage data in the background to
121
121
improve read performance. The results listed above were done
122
122
immediately after a lot of random writes. The results after
123
123
compactions (which are usually triggered automatically) are better.
124
124
125
- readrandom : 11.602 micros/op; (approximately 85,000 reads per second)
126
- readseq : 0.423 micros/op; 261.8 MB/s
127
- readreverse : 0.663 micros/op; 166.9 MB/s
125
+ readrandom : 11.602 micros/op; (approximately 85,000 reads per second)
126
+ readseq : 0.423 micros/op; 261.8 MB/s
127
+ readreverse : 0.663 micros/op; 166.9 MB/s
128
128
129
129
Some of the high cost of reads comes from repeated decompression of blocks
130
130
read from disk. If we supply enough cache to the leveldb so it can hold the
131
131
uncompressed blocks in memory, the read performance improves again:
132
132
133
- readrandom : 9.775 micros/op; (approximately 100,000 reads per second before compaction)
134
- readrandom : 5.215 micros/op; (approximately 190,000 reads per second after compaction)
133
+ readrandom : 9.775 micros/op; (approximately 100,000 reads per second before compaction)
134
+ readrandom : 5.215 micros/op; (approximately 190,000 reads per second after compaction)
135
135
136
136
## Repository contents
137
137
138
- See doc/index.html for more explanation. See doc/impl.html for a brief overview of the implementation.
138
+ See [ doc/index.md] ( doc/index.md ) for more explanation. See
139
+ [ doc/impl.md] ( doc/impl.md ) for a brief overview of the implementation.
139
140
140
141
The public interface is in include/* .h. Callers should not include or
141
142
rely on the details of any other header files in this package. Those
@@ -148,7 +149,7 @@ Guide to header files:
148
149
* ** include/options.h** : Control over the behavior of an entire database,
149
150
and also control over the behavior of individual reads and writes.
150
151
151
- * ** include/comparator.h** : Abstraction for user-specified comparison function.
152
+ * ** include/comparator.h** : Abstraction for user-specified comparison function.
152
153
If you want just bytewise comparison of keys, you can use the default
153
154
comparator, but clients can write their own comparator implementations if they
154
155
want custom ordering (e.g. to handle different character encodings, etc.)
@@ -165,7 +166,7 @@ length into some other byte array.
165
166
* ** include/status.h** : Status is returned from many of the public interfaces
166
167
and is used to report success and various kinds of errors.
167
168
168
- * ** include/env.h** :
169
+ * ** include/env.h** :
169
170
Abstraction of the OS environment. A posix implementation of this interface is
170
171
in util/env_posix.cc
171
172
0 commit comments