Let's see. 1000 documents 1KB sized added in the beginning of each day and updates every hour. So for single day we have 1MB of initial data +23MB from revisions. 24MB per day gives us 720 MB per average month and 8.7 GB per year. However, for each day you accumulates 23MB of overhead data for previous revisions which could be cleaned up during compaction. So if you'll run compaction at the end of day, 1MB per day will be the grow rate.
Also worth to take into account the fact that while CouchDB cleans up old revisions on compaction, it doesn't removes their ids from document to preserve his history: this will give you also small size overhead on top, but not significant. Additionally it's worth to know that CouchDB grows db by 4KiB chunks no matter if stored document is even smaller then. Also take into account that file system may preallocate more space for a file than it actually contains. -- ,,,^..^,,, On Thu, Sep 25, 2014 at 12:43 PM, Panny Wang <[email protected]> wrote: > Hi, > > We are using CouchDB in our new project but there's question raised that > how much space should I prepare for a couchdb database? > > My simple example is: > 1000 * 1KB document that will be appended to database in the beginning of > each day and each document will be updated every hour a day (i.e. 24 > revisions are kept for a document). > So can I know how much disk space at most will be used in this case? > > I understand that the disk space is not as expensive as before and > compaction can be done every day to save the disk space. But if we don't > have a basis to know how much the disk space will be used, then the whole > system may run into a 'out of space' situation and it is unpredictable when > the space will be run out. > > It is appreciated if you can shed some light on the rule about how estimate > the maximum disk space for a couchdb database. > > Thank you! > > Regards, > Panny
