On Jan 7, 12:55 am, Toru Maesaka <[email protected]> wrote: > > BTW, Is the storage engine stackable? If not so, it seems to me we will > > face a tradeoff between persistent storage and access controls. > > No. It's not stackable. If you want to do this you'd have to create an > abstraction layer within the storage engine. There were discussions on > this a while back though (I forget if it was online or offline).
They're not entirely not stackable. The vhosting bucket engine I wrote works by storing connection-private data pointing to another engine instance. That is, you can load pretty much any other engine behind this engine to provide multi-tenancy over it. The connection overhead is a pointer. The bucket overhead is one hashtable entry and whatever an instance of the underlying engine has (e.g. for the default engine, that'd be the hash table plus a slabber). Each underlying engine can be configured differently as well since the initialization occurs for every child instance. You can have two instances of the default engine running with different slabber configs and max memory sizes and have them totally not conflict. One can preallocate its maximum memory at once and disable evictions, the next can dynamically grow and evict when a slab is full. It would be possible to use a similar model for a MAC engine. That said, the API for stacking them... isn't all that clean. If this were more in demand, we could expose the loading and initialization system. That'd kill a good deal of my code. :) The majority of my code is reproducing parts of memcached for things like loading engines and -- most importantly -- providing a unit test framework that can hit all of the aspects of the engine *outside* of memcached.
