incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Alfke <j...@couchbase.com>
Subject Re: Is this use case correct for Couchdb
Date Wed, 24 Jul 2013 03:29:26 GMT

On Jul 23, 2013, at 8:07 PM, Richard Schmidt <Richard.Schmidt@metservice.com> 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
Mime
View raw message