Another thing that might be useful is having 'rotating' databases. E.g. for today things are stored at the second level, for the proceeding week things are stored at the 30s level, for last week things are stored at the 5 min level etc. This can be accomplished by hitting an appropriate view and dumping the result into a new database. It works if you're interested in aggregated data over the time period, if you always need the second-level granularity then it's (obviously) not so hot. Cheers Simon
On Tuesday, 10 January 2012 at 23:50, Rogutės Sparnuotos wrote: > Mark Hahn (2012-01-10 15:08): > > > I could have one document per metric, leading to a small number of > > > documents, but with each document containing ticks for every 5-second > > > interval of any given day, these documents would quickly become huge. > > > > > > > > > This would not only make the docs large, but you'd have a trail of huge > > outdated docs. You would get n-squared storage problems quickly. Remember > > that all versions of a doc are stored until you do a compaction. > > > > > Usually metrics don't need to be updated. If this is the case, then there > should be no storage problems with huge docs (compared to tiny ones). > > > I'd suggest one doc per second containing all the metric values for that > > second. > > > > > I would say do not dump more data than you need, i.e. don't use 1s > intervals if 5s is enough for you application. > > Regarding doc size, my guess is that CouchDB's architecture does not care, > and the decision must be made based on intended usage, but the original > poster did not describe how he is going to use the data (what kind of > views, list and show functions will be needed). > > -- > -- Rogutės Sparnuotos > >
