couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Couchdb Wiki] Update of "Compactage" by BenoitC
Date Sun, 29 Jun 2008 09:08:53 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for change notification.

The following page has been changed by BenoitC:
http://wiki.apache.org/couchdb/Compactage

The comment on the change is:
traduction démarrée

New page:
#language fr
== Présentation ==

Le compactage réecrit le fichier de base de données en supprimant les anciennes révisions
de documments et les documents effacés. C'est disponible dans CouchDB dans SVN depuis 2008-04-07
et depuis la version 0.8-incubating dans les sources téléchargeables.

Le compactage est géré manuellement par base de données. La gestion de queue compactage
sur plusieurs bases de données est prévu.

=== Exemple ===

Le compactage est initié par une requête HTTP post sur la sous-resource _compact de la base
de données. En cas de succès un code HTTP 200 est retourné.

{{{
    # POST http://localhost/ma_db/_compact via curl
    curl -X POST http://localhost/ma_db/_compact
    #=> {"ok":true}
}}}

une requête HTTP GET sur l'url de la base de données ( http://localhost/ma_db ) renvoie
un tableau(hash) des états sous la forme suivante :

{{{
    curl http://localhost/ma_db
    #=> {"db_name":"ma_db","doc_count":0,"doc_del_count":1,"update_seq":3,"compact_running":false,"disk_size":14341}
}}}

La clé compact_running est à true pendant le compactage.

=== Compaction of write-heavy databases ===
Note, it is not a good idea to attempt compaction on a database node that is near full capacity
for its write load. The problem is the compaction process may never catch up with the writes
if they never let up, and eventually it will run out of disk space.

Compaction should be attempted when the write load is less than full capacity. Read load won't
affect its ability to complete however.
CouchDB works like this to have the least impact possible on clients,  the database remains
online and fully functional to readers and  
writers. It is a design limitation that database compaction can't complete when at capacity
for write load. It may be reasonable to schedule compactions during off-peak hours. 

In a clustered environment the write load can be switched off for any node before compaction
and brought back up to date with replication once complete. 

In the future, a single CouchDB node can be changed to stop or fail other updates if the write
load is too heavy for it to complete in a reasonable time.

Mime
View raw message