couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: struggling with couchdb in production
Date Mon, 25 May 2009 19:36:11 GMT
On Mon, May 25, 2009 at 12:18 PM, Jurg van Vliet <> wrote:
> guys and girls,
> i am a 'real' user of couchdb, and i am having a lot of fun with it in
> addition to creating real value! but it is far from easy, especially in
> combination with a framework that is built around relational databases like
> rails. and still, after 4 months of intensively working with couchdb i am
> still a big fan.
> but couchdb is not finished yet. and i don't mean not finished in the sense
> of the software program that you can run, or the community that is building
> this. what i mean is that there is no documented approach to model real
> world problems in a couchdb way. you can search but the most interesting
> examples are to clarify the idea, or to show that it is possible. but
> nothing that helps me think about when to use a document, when a database,
> when a view, etc. etc.
> we have taken a couple of wrong design decisions the last couple of months.
> you can call it ignorance, or hindsight, or something else. i think it is
> just the lack of a good framework for thinking couchdb.
> when you make your relational database model, your tables, your rows, your
> indexes, etc. there is a large body of documentation that helps you approach
> the problem. and even with years of practice, and people having the word
> database and administrator in their jobtitle, designing your database models
> is just difficult. (there are really not many people i want to have thinking
> about tables and rows and indexes.)
> so now we have to make this paradigm shift. how are WE managing to struggle
> through this?
> one of my personal insights is that couchdb is so different from a
> relational database that it is best approached as if it is the opposite. in
> a rdb you 'minimize' the entity of information, you normalize until it is
> small enough to still have meaning. once everything is deconstructed you add
> rules (validations) your data must adhere to. having done that you start to
> put it back together using joins.

 yes, there's a lot of "unlearning" that needs to be done, and that takes time.

> in couchdb this pattern doesn't work very well, at least not for us. we
> learned it is easier to put as much data together in one document as
> possible. my rule of thumb of when to stop is in distribution. i often ask
> myself 'do i want to keep this together when i move it to another database?'
> once you have your documents views are very convenient to take your
> documents apart.

My rule of thumb is that you want documents to contain their own
context. An individual document should make sense even if you don't
have any others that it may refer to.

The main pressure getting you to split data into multiple documents is
update contention. If a lot of people are editing a list
simultaneously, then you need to make each list item it's own
document. If only one person ever edits the list, and the list is
relatively short, than putting it in one document may be easier.

> a database in couchdb is the place where work comes together, in our case
> this is the location where a group of people shares. combining information
> from different databases will be necessary. and i really have no clue yet
> how to approach this problem. so anyone?

The easiest thing is to merge the databases with replication.

> today i found myself in a sort of discussion with jchris and jan (i am sorry
> for the other jchris' and jans, but everyone knows who i mean.) guys, what i
> mean to say is that i am happy with your work. but your work is very very
> important to me. i think my work along with all the work of your users is
> what is going to make this movement great. if you help us succeed, you will
> have what you want.

If you're interested we'll be hosting a CouchDB tutorial in London
next month:

'scuse the plug :)

> (the reason i sent it to both lists is that i think this 'couchdb way' of
> working is something that is not the problem of use OR development. it is
> necessary to make everyone work together and find out where couchdb's future
> lies.)
> groet,
> jurg.

Chris Anderson

View raw message