Hi Somnath, On Fri, 12 Sep 2014, Somnath Roy wrote: > > Hi Sage/Haomai, > > If I have a key/value backend that support transaction, range queries (and I > don?t need any explicit caching etc.) and I want to replace filestore (and > leveldb omap) with that, which interface you recommend me to derive from , > directly ObjectStore or KeyValueDB ? > > I have already integrated this backend by deriving from ObjectStore > interfaces earlier (pre keyvalueinteface days) but not tested thoroughly > enough to see what functionality is broken (Basic functionalities of RGW/RBD > are working fine). > > Basically, I want to know what are the advantages (and disadvantages) of > deriving it from the new key/value interfaces ? > > Also, what state is it in ? Is it feature complete and supporting all the > ObjectStore interfaces like clone and all ? Everything is supported, I think, for perhaps some IO hints that don't make sense in a k/v context. The big things that you get by using KeyValueStore and plugging into the lower-level interface are: - striping of file data across keys - efficient clone - a zillion smaller methods that aren't conceptually difficult to implement bug tedious and to do so. The other nice thing about reusing this code is that you can use a leveldb or rocksdb backend as a reference for testing or performance or whatever. The main thing that will be a challenge going forward, I predict, is making storage of the object byte payload in key/value pairs efficient. I think KeyValuestore is doing some simple striping, but it will suffer for small overwrites (like 512-byte or 4k writes from an RBD). There are probably some pretty simple heuristics and tricks that can be done to mitigate the most common patterns, but there is no simple solution since the backends generally don't support partial value updates (I assume yours doesn't either?). But, any work done here will benefit the other backends too so that would be a win.. sage
