On Aug 1, 2008, at 18:50, Adam Jacob wrote:
On Fri, Aug 1, 2008 at 12:37 AM, Johan Liseborn
<[EMAIL PROTECTED]> wrote:
AFAIU, when you add new documents and then evaluate a view including
those documents, indexing will happen, but only for the newly added
documents (i.e. already indexed documents will not be re-indexed). I
believe this means that the time to index will be, in some way,
proportional to the number of *new* documents. I believe I have
seen a
big-O "number" for this somewhere, but I don't remember right now if
it is O(n), O(log n), or something else (I am sure someone else on
the
list can answer that :-).
As can be seen from the results, when CouchDB had to index the 10.000
new documents, it took about 13 minutes to get the result, but when
all the documents had been indexed, the answer came back in 0.7
seconds. Having to index 10 documents did not take that long, giving
an answer in 1.2 seconds.
I did some totally off-the-cuff benchmarking with Varnish (a caching
HTTP reverse proxy) in front of CouchDB. It works entirely as
expected - Varnish returns lightning fast (<30ms) very consistently
(20ms in the 50%, 35ms in the longest.)
With Varnish, you can also add PURGE support for a given URL.
This means that, if those compute times are egregious, and you can
suffer your data being a bit out of date, it would be trivial to
create a system that does:
Reads...
User -> Varnish -> CouchDB
Writes...
User->Varnish->CouchDB->PURGE for entry->Queue for view
re-indexing->PURGE for views
Essentially ensuring that all your reads always return as quickly as
possible, masking any possible delay in index queries on bulk updates
(assuming stale data for 10 minutes is ok.)
?update=false would be the CouchDB-only solution for that.
Cheers
Jan
--
