Yes, both attachments and documents are accounted as they both stored within the same database. -- ,,,^..^,,,
On Thu, Aug 27, 2015 at 5:25 PM, Antoine Duchâteau <[email protected]> wrote: > When compaction does occur, is the extra size needed the sum of the > attachment size + documents size or just the documents size? > > If it is the former, then I see no other way to do it that using your > suggestion but if it is the latter, the binary files could simply be stored > as attachment and the extra space needed will be related to metadata size > only. > > Antoine > >> Alexander Shorin <mailto:[email protected]> >> 27 août 2015 14:20 >> No, there isn't. That's a common trap for databases that needs in from >> time to time compaction. >> >> You can try to split your database into multiple ones, but general >> into two parts: the biggest one that rarely changed which wouldn't >> require any compaction and the one that have high updates rate and >> need to be compacted often. So, for your case it would be database >> for metadata and database for binary files, linked by sharing document >> ids. >> >> >> -- >> ,,,^..^,,, >> >> Carlos Pacheco <mailto:[email protected]> >> 27 août 2015 13:45 >> Hi ! >> >> I’m planing to create a ECM system using CouchDB to store metadata and >> binary files. >> >> Nowadays I use PostgreSQL to metadata and filesystem to binary files. >> >> My preoccupation is that I have databases (metadata + binary files) up to >> 10TB. >> >> If I store all on CouchDB, when it compact database, I will need twice >> this space in disk ("available disk space - it should be twice greater than >> the compacted file’s data) !!! >> >> This is very expensive to have. >> >> Are There another way ? >> >> Do you have some tip or trick about this (store binary files) on database >> ? >> >> Please Advice welcome !!! >> >> Thank’s >> Carlos - Brazil. > >
