On 14 Mar 2009, at 12:32, howard chen wrote:
Hi,
On Sat, Mar 14, 2009 at 6:57 PM, Jason Davies
<[email protected]> wrote:
CouchDB gives you a lot more for
free (flexible schema, replication and in general designed for high
scalability) so I would recommend giving it a try.
Sure will have a try later on.
2. Is Memcached useless if I am using couchdb?
I'm guessing memcached would still be useful as a caching layer to
squeeze
that extra bit of speed if you have the RAM, but maybe someone else
can
speak from experience.
The reason I ask is since couchdb output JSON, so ideal case is to let
users contact couchdb directly in term of scalability. If adding a
cache layer using Memcached which eat data from HTTP response seems
too much overhead involved as Memcached is a also key-value store.
Don't know if couchdb has some kind of query cache and how to tune?
Oh..maybe I should use squid?
CouchDB uses the filesystem buffer as a cache. CouchDB's b-tree storage
is a fairly thin layer on top of the filesystem and you should get
decent caching
characteristics out of the box. Of course, no requests are better than
cached
requests. View results come with HTTP ETags that allow you to find out
if a
client would need to re-fetch an item.
Squid* and Varnish do file caching as well where there might be faster
than
CouchDB but probably not magnitudes. A memory-based HTTP cache might
help you (nginx & memcache), but I think you can go a long way with pure
CouchDB and HTTP caching alone.
(* There is an anecdote on the web where Squid tries to outsmart the
filesystem
buffer cache and ends up doing two disk-to-memory operations where one
would do, I can't seem to find the reference right now).
Cheers
Jan
--
