On Tue, Jan 10, 2012 at 12:10 AM, Dustin <[email protected]> wrote:
>> By taking a quick browse on the source, it seems only "default_engine"
>> is included (?) that uses RAM as a backend. Is this right ? So I
>> assume for other type of backends, we have to supply our own engine by
>> implementing the "ENGINE_HANDLE_V1" interface ?
>
>
> Yes, default_engine is the only one that's included. Trond wrote a blog
> series on writing storage engines:
> http://trondn.blogspot.com/2010/10/writing-your-own-storage-engine-for.html
> I don't know of any really ultra trivial ones at the moment, though I've
> seen some floating around the past (lua engine, black hole -- probably even
> a malloc engine).
The write-up helps - as I was lost in the wrapper script ("memcached")
yesterday. Many thanks here !
It seems the engine operations (hooks) are invoked as part of the
network request processing logic (e.g. process_bin_set() etc) (is this
right ?). Did the community ever discuss to place the hooks somewhere
around (or inside) the "item" structure ? Intuitively this would allow
each "item" being processed individually depending on where it is
located (RAM or another device).
I'm trying out a hybrid environment where RAM serves as the primary
hash store but the entries could be offloaded into another device. For
this purpose, the code from the master branch seems to be easier to
hack as it already have item data+key and item meta-data separated.
Yes ?
-- Wendy
