[chef] Re: couchdb question

[Adam Jacob < >]

On Tue, Aug 4, 2009 at 12:10 PM, Joe Van 
Dyk<
 >
 wrote:
> Why was couchdb chosen as the data store for chef-server?

Because it fit the model we needed very well.  We needed it to be
lightweight, extensible, and schema-free. (Mapping Ohai data into a
relational database is not fun, and it doesn't scale well at all.)  We
met most/all of the requirements for using CouchDB well - the data
changes with a fairly low frequency (even in the largest of
infrastructures updating constantly,) we know exactly how we want to
query it, and we don't need transactional consistency above the level
of a single object.  Also, the data itself translates almost directly
to CouchDB - we just serialize objects as JSON, and store them.

It also is, in essence, just another HTTP application - which means
when you learn how to scale the rest of Chef, you are also learning
how to scale it's data store.  Things like proxies, caches, etc. are
all right there, waiting to make both Chef and CouchDB faster in a
pretty trivial way.

Basically, we chose CouchDB because it was exactly the way we wanted
to relate to the data-store for this sort of data.  Flexible, fast
(enough), queryable (enough) and trivial to scale for our use case.

Regards,
Adam

-- 
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-7449 E: