CODEWITHSUNDEEP
couchdb
Elf Sternberg
Elf Sternberg

Reputation: 16381

Do many design documents bog down Couchdb?

My company is using CouchDB, and I'm going to have to interact with it soon, so I'm getting a crash course in it, and as I was reading through various tutorials and examples, I came across one that made wonder: Do many design documents bog down CouchDB?

The specific example I read, which mirrored my own use-case, is one where the middle tier creates a new design document for every customer, limiting all queries and the associated generated b-trees to that customer.

But doesn't this mean that you'll have, at a best-case scenario (from a business point of view) thousands of design documents? It occurs to me that since every single one of those design documents has to be run for every insert, if only to emit nothing, that would end up being a heck of a strain on the server.

Am I missing something essential about the design of CouchDB that makes this a non-issue? Or is there a smarter way to handle this?

Upvotes: 4

Views: 346

Answers (2)

Ryan Ramage
Ryan Ramage

Reputation: 2616

I probably would not recommend this approach. Lets consider some cases:

A new customer

You would create a new design doc, and add it to your db. In this case, when the first view requested from that design doc, it will run through all the docs in the db to create the index. So every new customer will scan all the docs.

A new record/or record change

Every other document change will be run through all the design doc view functions.

Alternative

Create a db for each customer. One design doc in each db. Have a master db for aggregation that all the customer db's replicate to.

Upvotes: 7

wizzard0
wizzard0

Reputation: 1938

AFAIK CouchDB updates views only when results are first requested (that's why they have a "stale views" option).

So, this type of load should not be a problem for you. But you'd better be aware of the disk space consumption if the views output a lot of data.

Upvotes: 3

Related Questions