J'ai eu l'occasion d'assister au salon Couchbase Live London du 2 avril dernier. Voici quelques notes sur les sessions qui valaient le coup.
TL;DR: Une solution à suivre de près, indéniablement.
Amadeus développe (entre autres) un système de recommendation de voyage mis à disposition des agence et moteurs de recherche de voyages (par ex : Expedia). Ce système brasse une quantité gigantesque de voyages possibles depuis/vers toute destination, à toutes les dates, et est extrêmement sensible à la qualité de l'information sur la disponibilités des places dans les vols proposés. Ils gagnent ou perdent des millions sur la seule qualité de cette information.
Au cours de l'histoire de ce système, ils ont monté une architecture de cache de plus en plus compliquée (basée sur du memcached, au-dessus d'un cluster mysql, au-dessus de la source de donnée elle-même dans Oracle). Cette architecture a été remplacée avantageusement par un cluster Couchbase.
Et ça envoie :-) Les chiffres parlent d'eux-mêmes : 2.6M read/s, 1M write/s sur un cluster de 30 (grosses) machines
Les forces de Couchbase selon lui :
Ils pensent utiliser Couchbase pour de nouveaux use-cases :
Viber a eu une croissance strictement exponentielle, en nombre de users, de messages échangés, etc. Impressionnant. Initialement, ils avaient une architecture MongoDB avec du Redis devant. Redis, utilisé en tant que cache, ou en tant que base in-memory non durable.
Ils ont eu trop de problèmes avec MongoDB :
Et du côté de Redis : ça ne supporte pas le "sharding". Ils ont pendant un temps développé leur propre "sharder" en interne, mais celui-ci avait trop de limitations.
Ils sont passé à Couchbase. Résultat sans appel : les perfs meilleures avec moitié moins de machines.
Elément d'architecture intéressant à noter : ils ont dédiés des clusters entiers à des patterns d'accès. Tel cluster majoritairement en lecture ; tel cluster lecture/écriture, etc.
Ils ont aujourd'hui 7 clusters en parallèle, le plus gros ayant 60 noeuds actifs. Ils ont également mis en oeuvre la réplication inter-datacenter.
Leurs travaux futurs : utiliser les nouveaux connecteurs, basés sur le canal de réplication cross-datacenter de Couchbase XDCR, pour déverser de la donnée dans Hadoop et dans ElasticSearch.
Ticket Master est une société qui fait du ticketing de spectacles, sport, etc. Rien de bien intéressant, si ce n'est le use-case : utiliser Couchbase pour consolider une vision unique de données fréquemment dupliquée entre différents silos du SI. A garder en tête, car le multi-canal est dans l'air du temps, l'intégration de données en provenance de silos disparates est un vrai enjeu.
Concur est une société spécialisée dans la gestion des voyages et frais professionnels des employés.
Je retiens ce qui leur a fait choisir Couchbase :
Couchbase commence à avoir des références vraiment solides sur l'opérabilité et la performance. Nous avons d'ailleurs eu droit à une démonstration assez convaincante des outils d'opération (la "console") sur un cluster live, avec ajout de noeud, ré-équilibrage à chaud, etc.
Dans des cas d'utilisation de type :
Alors vous devez jeter un oeil à Couchbase.