Re,

On est déjà dans MISC, donc je me permets une digression "software".

Backend sur une base repliquée / shardée type MongoDB, un truc du genre, et
ça doit pouvoir scaller des milliards de mapping.

MongoDB : At scale, y en a qu'ont essayé... ils ont eut des problèmes (et pas qu'un peu).

La version (3.41) qui a priori ne perd plus systématiquement de data (embêtant pour une db) et fonctionne enfin correctement date de (seulement) fin Décembre 2016... (on est à la 3.6)... avant cela nombre d'utilisateurs ont eu de très très gros problèmes (google it...) avec ce bout de code faussement "open-source". En effet, la boîte qui édite le soft n'en avait rien à faire des problèmes évidents (pendant des années... les premiers rapports de problèmes sérieux que tu peux trouver datent de 2013) qui lui ont été reportés, même par leurs clients... et cela même quand ceux-ci proposaient des patchs pour résoudre les problèmes en question (du coup ca sert à quoi de se prétendre open-source ?).

IMHO, les mecs ont fini par fournir leur db "dans le cloud", peut-être parce qu'ils sont les seuls à avoir réussi à la faire tourner "at scale" (on parle de centaines et milliers de serveurs). Le minimum que tu puisses exiger d'un système en cluster c'est de pouvoir auto-scaler en mode "fire and forget"... Hors, la majorité de leurs témoignages clients c'est sur du use-case "embedded" avec un framework JS... donc sans aucun cluster.

Alors certes, ce qu'ils ont fait dans le passé ne présage pas la qualité de leur travail actuel, mais donne une bonne idée de l'état d'esprit. Du coup c'est pour cela que j'ai plutôt parlé précédemment de redis et couchbase qui eux ont un track record sans tâches d'huiles, pour faire la même chose, mieux (multi-master, répli cross-DC...) et avec de meilleurs perfs (de par leur historique "in-memory"). Et côté devs couchbase = devs de memcached + couchdb et redis = antirez, auteur de hping... :)

Par contre, comme toi, je confirme qu'avec quelques serveurs, tu peux faire tenir largement toute la db FR sans problème de perf (surtout vu le très faible nombre de writes/sec)... et avec quelques centaines de serveurs, toute la db worldwide des numéros de téléphones de la planète. En plus, ce qui est cool avec une db sans schéma/NoSQL, c'est que tu peux ajouter une feature (un record dans chaque json) en mettant à jour au fil de l'eau et sans rien casser sur les softs existants...

C'était la minute software/NoSQL at scale...


Cordialement,
--
Philippe Bourcier
web : http://sysctl.org/
blog : https://www.linkedin.com/today/author/philippebourcier


---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/

Répondre à