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