this is a golang binding for kissdb C api. repo : https://bitbucket.org/8ox86/kissdb
KISSDB 是一个最简单的 key/value 存储，使用纯 C 开发, gti repo url为: https://github.com/adamierymenko/kissdb
我给它写了个go语言绑定: go doc: https://godoc.org/bitbucket.org/8ox86/kissdb
benchmark (Intel(R) Core(TM) i7-8700K CPU @ 4.50GHz, 6 core 12 thread):
goos: linux goarch: amd64 pkg: bitbucket.org/8ox86/kissdb BenchmarkOpen100-12 100000 21585 ns/op BenchmarkOpen1000-12 50000 29218 ns/op BenchmarkGet-12 1000000 1299 ns/op BenchmarkSet-12 300000 16986 ns/op BenchmarkSave100-12 30000 47847 ns/op BenchmarkSave10000-12 30000 47690 ns/op PASS ok bitbucket.org/8ox86/kissdb 14.630s
(Keep It) Simple Stupid Database
KISSDB is about the simplest key/value store you'll ever see, anywhere. It's written in plain vanilla C using only the standard string and FILE I/O functions, and should port to just about anything with a disk or something that acts like one.
It stores keys and values of fixed length in a stupid-simple file format based on fixed-size hash tables. If a hash collision occurrs, a new "page" of hash table is appended to the database. The format is append-only. There is no delete. Puts that replace an existing value, however, will not grow the file as they will overwrite the existing entry.
Hash table size is a space/speed trade-off parameter. Larger hash tables will reduce collisions and speed things up a bit, at the expense of memory and disk space. A good size is usually about 1/2 the average number of entries you expect.
Tiny, compiles to ~4k on an x86_64 Linux system Small memory footprint (only caches hash tables) Very space-efficient (on disk) if small hash tables are used Makes a decent effort to be robust on power loss Pretty respectably fast, especially given its simplicity 64-bit, file size limit is 2^64 bytes Ports to anything with a C compiler and stdlib/stdio Public domain Limitations:
Fixed-size keys and values, must recreate and copy to change any init size parameter Add/update only, no delete Iteration is supported but key order is undefined No search for subsets of keys/values No indexes No transactions No special recovery features if a database gets corrupted No built-in thread-safety (guard it with a mutex in MT code) No built-in caching of data (only hash tables are cached for lookup speed) No endian-awareness (currently), so big-endian DBs won't read on little-endian machines