Hi Michi, On 31 May 2014 14:29, Michi Mutsuzaki <mi...@cs.stanford.edu> wrote:
> Hi, > > I'm hosting an intern this summer. One project I've been thinking > about is to decouple zab from zookeeper. There are many use cases > where you need a quorum based replication, but the hierarchical data > model doesn't work well. A smallish (~1GB?) replicated key-value store > with millions of entires is one such example. The goal of the project > is to decouple the consensus algorithm (zab) from the data model > (zookeeper) more cleanly so that the users can define their own data > models and use zab to replicate the data. > > I have 2 questions: > > 1. Are there any caveats that I should be aware of? For example, > transactions need to be idempotent to allow fuzzy snapshotting. > 2. Is this useful? Personally I've seen many use cases where this > would be very useful, but I'd like to hear what you guys think. > I think this is super useful. As Flavio said, I think there are two approaches: having ZAB as a library first or carving out the ZAB bits and having a generic interface to plug in other protocols. >From the ZooKeeper's project PoV, I think that the latter would be awesome, because we can clean up a lot of code as it happens. >From an intern project's PoV, it sounds like working on an independent ZAB implementation (libzab?) from scratch is easier to target (and will have no impedance, getting huge changes merged into ZooKeeper takes times...). -rgs
