[ZODB-Dev] relstorage - memcached - noSQL(?)

[Adam Groszer]

Hey Shane,

Well, first feasibility. But I think it's doable. The question is how
much cruft it will require.
(I think on the high level a KVDB is a perfect match for a ZODB
backend. oid -> pickle is the mapping. If it's oid_tid -> pickle it's
still not bad.)
So if the story about a KVDB being superfast is true, that should
bring some speed.

I'd start with a single process multithreaded scaffolded something
with locally implemented locking, that should be rather easy to build
together from the various storages.
But still make sure with some dumb requests that the locking and other
"left out" features take their own time and benchmark this against the
other storages out there.
Then we'll see whether it's still worth chasing this.

- Reliability might be the next thing as (most) KVDBs seem to support
(some sort of) replication.
- Scalability is a tough question. First problem is the commit lock.
And the CAP theorem - I think a ZODB backend cannot get by without all
3 properties.
But about the latter two I did not think yet in depth and there are
just too many KVDBs out there to explore.

On Wed, Nov 25, 2009 at 2:29 PM, Shane Hathaway <shane at hathawaymix.org> wrote:
> Adam GROSZER wrote:
>>
>> This is some tinkering about whether/how it is possible to make a ZODB
>> storage that uses a simple kev-value database (KVDB) (e.g. tokyo tyrant).
>> A KVDB that is persistent on disk or even replicated should not be
>> less fault tolerant as MySQL.
>
> I don't quite understand.  What do you hope to accomplish with Tokyo Tyrant
> or some other key/value store as a ZODB backend?  Speed? Reliability?
>  Scalability?
>
>> I'd like to personally chase these ideas, but I don't think I'll get
>> some time soon. Also I guess you have a deeper knowledge about
>> storages.
>
> Well, I like to hear ideas, but I can't chase them all either.
>
> Shane
>



-- 
Best regards,
Adam