13

I'm designing a system based around CouchDB. It will have a handful of different components - a list of users, a main data store, logging, etc. What I want to get a feel for is, what should the scope of a CouchDB database be? Should I have separate databases for each component, or just chuck everything into one and use a 'type' property for each document? I know individual databases can get very large quite happily, but is the performance of views impacted by keeping everything in one database, as opposed to splitting databases out? Essentially, what are the trade-offs involved?

Cheers all.

stompydan
  • 233
  • 1
  • 7

1 Answers1

14

Good question, Dan.

I think this is basically an optimization problem. A good idea is not to optimize (separate into multiple databases) too soon. (One exception might be logs, which can quickly dominiate all other data, requiring compaction often. I might split the logs off immediately.)

View performance will not be impacted. In exchange for pre-defined queries (view definitions), CouchDB guarantees fast view results, always.

Whether to split into multiple databases typically depends on authentication and permission concerns. If you use a normal web server front-end, that is less of a concern.

As with all views, they are fine if you query often. Queries keep the view up-to-date, with fast response time. Delays in the query cause processing to build up for the next one. In production, this is not much of a problem.

JasonSmith
  • 72,674
  • 22
  • 123
  • 149
  • 1
    Thank you, that's just the answer I was after! My instinct was against premature optimisation, and I've started with keeping it all in one database, but the suggestion to split off the logs sounds good. – stompydan Feb 10 '11 at 09:24