On Mon, Jan 25, 2010 at 11:30 AM, Sean Clark Hess <[email protected]> wrote: > I love Couch, but I keep running into things I don't understand, and seem > like they would cause problems in the long run. > > One of those is the idea that you dump a whole bunch of related information > into the same database, then build design documents and views for it. I > believe the docs say normally you have one design document per application? > > Under the hood then, don't we have to run a map function on each document in > the database for each view in each design document? Eventually, it seems > quite reasonable to expect that I'd have 20 or so views of the same data. > Wouldn't that slow down inserts a lot? What is the practical upper limit of > views? > > Write speed is pretty important for one part of our system - should I put > that data in another database so it doesn't get slowed down by the rest of > the data's views? > > Thanks! >
Couple points: * One design doc per app is somewhat misleading. I prefer the more general form of "One design doc per group of related views and supporting code." The term "application" is kind of hard to pin down exactly so its hard to use it in a rule of thumb style quote. * Generally speaking, views won't slow down inserts because views aren't updated until you query them. * In terms of limits, its hard to say other than 20 isn't approaching it. I'd expect at least thousands depending on access patterns on so on. And the first limit that comes to mind would be the number of open file descriptors. * Its hard to know when you should split data between databases versus not. I would say that you'd probably just need to measure for your expected workload to see how it shakes out. HTH, Paul Davis
