couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nitin Borwankar" <>
Subject Re: Is this use case correct for Couchdb
Date Wed, 24 Jul 2013 05:30:57 GMT
Hi Richard,

Sounds like you want a caching solution like memcache.
You could write behind to CouchDB just to have a persistent copy.
Then the compacting of CouchDB would not interfere with that particular 
days work as you are reading from cache.
You don't say what you are doing with the read - do you expect to do 
analytics on it in the db?
If not hand it's just a simple read of say a JSON object or a set of k-v 
pairs then something like Redis or memcache should do just fine with 
CouchDB as a backing store, written to lazily.


On 23 Jul 2013, at 21:59, Richard Schmidt wrote:

> Thanks for that - is sounds like CouchDb is not a good solution.
> Can you recommend a Nosql db that is a better fit?
> -----Original Message-----
> From: Jens Alfke []
> Sent: Wednesday, 24 July 2013 3:29 p.m.
> To:
> Subject: Re: Is this use case correct for Couchdb
> On Jul 23, 2013, at 8:07 PM, Richard Schmidt 
> <> wrote:
>> 1)      Store a forecast in the database
>> 2)      Read a number of  times over the next day or so.
>> 3)      From then on there are almost no further reads of the 
>> forecast.
>> 4)      After a month or so the forecast is deleted as no one cares 
>> about an old forecast.
> IMHO CouchDB isn't a terribly good fit for this. Sounds like you just 
> want some data analysis, not any of the multiversioning / replication 
> / conflict handling features CouchDB is good at.
>> How will couchDB perform if you are continually deleting old data?
> This is a weak point. Deleting basically just means adding a new 
> revision with a "_deleted" property, so it doesn't free up any space. 
> Compacting frees up the space occupied by old revisions but leaves the 
> revision tree
> metadata, so you don't get all the space back. To really get rid of 
> old data completely requires the "_purge" command.
>> How often would you need to run the compacting command? Does it have 
>> an effect on the database performance?
> You won't recover any disk space until you compact. The file format is 
> append-only, so a database can only grow until it's rewritten by a 
> compact. Compaction is highly I/O intensive since it copies all of the 
> remaining data, so if I/O is a bottleneck in your setup it can affect 
> performance.
>> What would happen if you (say) simply removed the old data files from 
>> the couchdb data directory? (I suspect all hell will break loose)
> This question doesn't make sense, because database records/documents 
> aren't stored in individual files. There is one file that stores the 
> entire database.
> -Jens

View raw message