On 13 Apr 2009, at 08:15, Thomas Heller wrote:
Hey there,
My CouchDB Project is coming along nicely but I came about one concern
recently. While my Database is quite small at the moment (only about
500kb
in docs) I already have 7 design docs, 12 map only views, 6 map/reduce
views. Now my "concern" is when traffic picks up and "write" activity
increases that certain parts of the site will become "slow".
For example I have a Forum on the Site which uses 3 views (list
categories,
list posts with last comment for each category, list comments for each
post), basic stuff and works fine right now. But since every updated/
new doc
has to pass any view (when called) I fear that many "writes" to the
forum
may force constant updates for other views on the site. I know its
superficial but still.
Basically what I'm asking: Does anyone have any experience how many
design
docs/views per Database is a "good" value? I could move any
"module" (forum,
wiki pages, etc) to its own database but that would add a little
maintenance
overhead which might be totally unneeded. I expect to have about 15
design
docs with about 30 views when I'm done. Should I move each view
function to
its own design doc? Like I said my Database currently has about 150
docs so
any testing I do is kinda pointless since everything will be fast
enough,
guess I'll have to write some "noise" simulator which just adds
documents
over time and see where it leads me.
Having more views in a design document makes better use of your
resources.
For each design document, CouchDB fetches a document from the databases,
serializes it into JSON, sends it to the view server, the view server
deserializes
it into a native JavaScript object and sends it through all map
functions.
The (de-) serialization is expensive. Executing a bunch of map
functions is not.
You should only separate out views into their own design docs when
they are
truly separate. Say you have a very complex map function (including
parsing
and whatnot), you might want to trigger the building of that view from
a cronjob
or message bus instead of the live application.
But mostly, all views that belong to a single application can go into
a single
design document.
CouchDB's internal architecture is designed to batch-update views on-
read
and there are ways to make that even faster in the future.
One option you might be interested in is the `?stale=ok` option for view
queries. It will return whatever is in your view index right now
instead of
triggering an update (or waiting for one to finish). That way you can
get
slightly not-recent data faster.
Cheers
Jan
--
