Hi Cgs, I suppose I could come up with a partition strategy that distributes the load: I could do what you suggest, or I could also use separate hosts. But all this would transfer complexity to my application, and I want to avoid that.
Thanks Daniel On Thu, Mar 15, 2012 at 12:41 AM, CGS <[email protected]> wrote: > Hi, > > Sorry for interfering, Daniel, but do you really need all those documents > in a single database? I mean is it mandatory to have them there? Because if > not, one can split that 3M database in 10 - 100 smaller databases, each > with its own view, and concatenate the result after that (if you cannot use > pagination, otherwise, instruct your view to take only a certain number of > results per displayed page) using JS or whatever else if you have an > application which needs that result. In this way you can have a certain > level of parallelism which may speed the overall process. > > Just a 2c idea. > > CGS > > > > > > On Thu, Mar 15, 2012 at 12:13 AM, Matthieu Rakotojaona < > [email protected]> wrote: > >> On Wed, Mar 14, 2012 at 10:19 PM, Christopher Sebastian >> <[email protected]> wrote: >> > I am also new to couchdb, but I don't believe the information from >> Matthieu >> > Rakotojaona is correct. It is my understanding that pretty much >> everything >> > in CouchDB (including views) uses incremental updates. So adding new >> > documents to the database does NOT cause all view leaves to be traversed >> -- >> > the view is updated incrementally. >> > >> > Is this correct? >> > >> > ~Christopher Sebastian >> >> I might have spoken a little bit too fast. Indeed when you add new >> documents, they are automatically passed (or rather they will be when >> the next query comes) to the map function, which doesn't traverse the >> already indexed db. >> >> But when (and if) you have a reduce function, all the intermediary >> rereduce results will have to be updated, right ? >> >> -- >> Matthieu RAKOTOJAONA >>
