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.
