couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Duchâteau <aduch...@gmail.com>
Subject Re: Space used to Compaction
Date Thu, 27 Aug 2015 14:25:10 GMT
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:kxepal@gmail.com>
> 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:cep_forum@icloud.com>
> 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.


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message