Use Redis. You can decide exactly when a key is expired. But it's not a documental database, it's key/value store. They are different products.
On Jul 24, 2013, at 6:59 AM, 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 [mailto:[email protected]] > Sent: Wednesday, 24 July 2013 3:29 p.m. > To: [email protected] > Subject: Re: Is this use case correct for Couchdb > > > 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
