Hi Ivan, The use case this project is going after is to durably replicate in-memory state. I think this project can differentiate itself from BookKeeper.
1. BookKeeper is pretty heavyweight, as you need to deploy ZooKeeper and bookies. I think there are use cases where you don't need the horizontal scalability BookKeeper provides, and you prefer to have a light-weight library for replicating state. ZooKeeper is one such example :) 2. Please correct me if I'm wrong, but BookKeeper is not designed for maintaining multiple in-memory replicas. A ledger can't be opened for reading if it's already open for writing, and you need to recover by restoring from a snapshot and replaying log entries if the writer goes down. 3. ZOOKEEPER-30, which I wasn't initially aware of, is another motivation. I think there is a value in having a common interface for consensus algorithms so that services can plug in different implementations. This makes it easier to benchmark and test correctness of various implementations. On Sun, Jun 1, 2014 at 3:05 AM, Ivan Kelly <iv...@apache.org> wrote: > On Sat, May 31, 2014 at 02:29:34PM -0700, Michi Mutsuzaki wrote: >> 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. > So you want a replicated log which give you the guarantees of zab. How > would this be very different from Bookkeeper? > > -Ivan
