libkv icon indicating copy to clipboard operation
libkv copied to clipboard

Filesystem backend

Open thegrumpylion opened this issue 6 years ago • 0 comments

Hi,

while ago i've started implementing a local backend driver for libkv using the filesystem. I'm doing this mostly to learn the insides of the codebase (aka for fun) but also some interesting concepts have emerged.

First. What's wrong with boltdb backend?

  • No watching
  • Backed by a binary file

With an FS backend you can utilize inotify to implement watching and you can have plain files as "values". If are accessing your etcd, zk, et. using libkv having a backend like this you can have versioned test/mock data for development and testing. Or, for example, speed development by having direct access to your "DB".

Some issues.

  • Should i treat the key space as flat or as tree. This will affect if i do recursive inotify watch on the dir or not
  • There is some weird normalization stuff for keys that if you follow the functions at the end you just get "/" prepended to your string. So the question is, as a user, should "myKey" be equal to "/myKey" when i call libkv api?
  • File locking. Using fcntl_flock can prevent other process but not the goroutines. sync.Map maybe?

How does this concept sound to you? Will it be useful?

Cheers

thegrumpylion avatar Dec 16 '17 15:12 thegrumpylion