On Jul 23, 2013, at 8:07 PM, Richard Schmidt <[email protected]> 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
