incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Schmidt <>
Subject RE: Is this use case correct for Couchdb
Date Wed, 24 Jul 2013 04:59:07 GMT
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.
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

> 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

> 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.


View raw message