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/