What Would ZODB + Paxos Look Like?

I just learned about the Paxos algorithm. I think we might be able to use it to create a fully distributed version of ZODB. I found a document that explains Paxos in simple terms.  Now I’m interested in learning about any ideas and software that might support integration of Paxos into ZODB.  I would also like to know how much interest people have in such a project.

I think ZODB’s transaction layer already implements a sort of squashed version of Paxos, but it’s not currently possible to separate the pieces to make it distributed.  To me, “distributed ZODB” means multiple servers accept writes while assuring consistency at all times.  I also require sub-millisecond response timing on the majority of read operations, since that is what ZODB applications have come to rely upon.  I suspect the speed requirement disqualifies systems like CouchDB.

3 thoughts on “What Would ZODB + Paxos Look Like?”

  1. Google uses paxos in it’s Chubby Lock Service used in BigTable (useful summary of google tech here: http://www.cse.nd.edu/~dthain/courses/cse60641/fall2007/guest_lecture_OS_fall_07.pdf. Google for the original papers). It’s designed for coarse-grained locks. Generally they seem to favour single master systems, writes are distributed across multiple ‘tablet’ servers through something that looks like flexible partitioning, but without the network overhead required for reaching consensus in a multi-master system.

  3. Howdy Shane,

    I always enjoyed reading your posts on your old HathawayMix site, and now I found this one. Excellent!

    You might investigate Apache QPid for the messaging infrastructure, to support ZODB + Paxos. Or, even better, ZODB + Protocol Buffers + Paxos.

    http://qpid.apache.org

    Qpid is like IBM’s MQ-Series, only cheaper (FREE) and much more versatile. Here’s a practical example. In the next few weeks, I’m going to be
    rolling out a new financial blog. It has a relatively lightweight Django front-end, but it’s going to allow folks to run financial models on (what will eventually be) 100+ GB of data.

    I am using Protocol Buffers and QPid to pass messages between the Django front end and a pure Python server on the back end. That way, I can do the following:

    1. If my site becomes popular (too many requests for my little DSL line), I can toss it onto any Django-friendly hosting service and start n instances. Each instance could connect to my queue manager (on the “home” side of my DSL line) and I could maintain my own hardware for the big databases.

    2. Each request takes a few seconds to complete. Even if I am hosting remotely, I can very easily add new “compute resources” to handle
    additional load. Any Windows or Linux PC with Python and psycopg2 can become a “compute resource”, and it’s as simple as copying over a set of Python scripts (the “server”) and running them.

    I haven’t yet read the Paxos paper, so I don’t know how QPid could help there – maybe you could get a better idea after investigating QPid.

    Cheers,
    -Josh

Comments are closed.