Hello,

My 2ct :

Il y a deux ans j’ai monté une infra avec du CouchDB, qui d’ailleurs tourne
toujours.

Il me semble que ce que tu souhaite faire est possible avec cette techno
(ou les dérivés genre CouchBase), voir même avec Riak (jamais testé).

En vrac :

* Plusieurs groupes de 2+ noeuds CouchDB en multi-master réparties dans plusieurs
zones
* Du load balancing HTTP devant les groupes (CouchDB est RESTful …), avec du
sticky session au cas ou la replication aurait un léger lag.
* Du routage basé sur la latence vers les LB (R53, par exemple)
*Optionnellement du sharding; #BIGDATAS #BUZZWORDZ

Quelques avantages que j’ai trouvé à Couch (d’un point de vue Ops) :

* Simple de scale up : snapshot à chaud d’une DB + démarrage de la réplication
(qui va rattraper son retard). En plus archaïque : rsync/scp des db vers la nouvelle
machine + démarrage de la réplication pour rattraper le retard.
* Simple à backup à chaud : snapshot du FS etc …
* Ça s’industrialise bien …
* Plusieurs type de réplication : One-Shot, continue …

Inconvénients :

* La compaction/Décompaction d’une DB : attention à l’espace disque.
* La ré-indexation d’une vue peut être « longue »
* Compacter une DB : attention les I/O

Si ça t’intéresse, une présentation (scolaire donc « vulgarisé ») est disponible
ici : -http://bdossantos.github.com/TOM-infrastructure-slides/#29

Il y a quelques chiffres pour te donner une idée de la volumétrie, le schéma
de l’infra etc …

Disponible si tu as des questions.