Internet services, in most scenarios, will use cache services.
"Choose redis or memcache, how do you say the source code? "
Choose redis or mc, what does the interviewer want to investigate? "
Knowledge points of memcache kernel, worth collecting"
But sometimes, the process memory cache/database is indeed used. At this time, LevelDB can come in handy.
What is LevelDB?
LevelDB is developed by Google, a very fast KV storage library (storage library), it supports string key and string value, and this mapping relationship is sorted by key (ordered mapping).
What are the characteristics of LevelDB?
(1) Key and value can be strings or byte streams;
(2) The data is arranged by key by default and stored in order;
Voice-over: The caller can override the sorting method to achieve custom sorting.
(3) Simple and easy to use, there are only 3 basic operations:
- Put(key, value)
- Get(key)
- Delete(key)
(4) Provide atomic batch modification interface;
(5) Support data snapshot;
(6) Support automatic data compression;
Voice-over: use snappy compression algorithm.
(7) Open source, the documentation is very detailed, and the Google product is very reliable;
What are the limitations of LevelDB?
(1) LevelDB is not a SQL database, it has no relational storage model, does not support SQL statements, and does not support indexes;
(2) Only one process (of course, this process can be multi-threaded) accesses a specific database at the same time ;
(3) LevelDB just a lib library did not achieve what client-server network communications or something, of course, users can own the lib packing layer, to realize their server;
What is the performance of LevelDB?
The characteristic of memory cache is fast.
Google also conducted a series of tests: the test library has a total of 100w rows of records, each record has a 16-byte key, a 100-byte value, and the compressed value is about 50 bytes.
Write performance
Sequential writing: the average time per operation is 1.765 microseconds, that is, it supports about 55w sequential write operations per second;
sequential writing + flashing each time: the average time per operation is 268.409 microseconds, which supports about 3700 times per second Flash disk write operation;
random write: the average time per operation is 2.460 microseconds, which supports about 40w random write operations per second;
update write: the average time per operation takes 2.380 microseconds, and the performance is similar to random write;
Read performance
Random read: the average time per operation is 16.677 microseconds, which supports about 6w random read operations per second;
sequential read: the average time per operation is 0.476 microseconds, which supports about 210w sequential read operations per second;
reverse read : On average, each operation takes 0.724 microseconds, that is, it supports about 130w reverse read operations per second;
The above performance is the result of not opening the "compression" function. If the "compression" option is turned on, the performance will be improved.
Voiceover: Google mentioned very honestly that since the amount of data in 100w rows is very small, these data can be completely put into memory.
If you are only limited to program research, the above content should be enough; if you want to understand the details of LevelDB, write an article in the future. 
Knowledge Planet-Just started playing
related suggestion:
"Back to table query? Index coverage? | 1 minute series"
"Optimization tool, rapid positioning of inefficient SQL | 1 minute series"
"Database allows null values (null) is the beginning of tragedy | 1 minute series"
"two types of very hidden full table scan | 1 minute series"
Research:
What do you use to implement memory KV caching, do you play with "Map+Lock" by yourself?