Reprise du message précédent :

Tu vas faire une v1, bien, avec des outils solides et quand tu trouves les limites d'un outil tu le remplaces

Parceque node/mongo pas trop mal codé ça monte déjà bien en charge
Au pire tu loue quelques serveurs de plus

C'est pas de la merde en cube Mongo ?

Ça s'est amélioré il paraît. Mais partir directement sur un document store distribué me semble pas être une grande idée.

Tu t'en tapes, surtout avec les stacks classiques modernes qui tiennent déjà énormément.

Voila

Ben si tu veux une base de données faut prendre autre chose
 
Un des projets principaux qu'on a monté ici (qu'on a surtout réécrit quand je suis arrivé ), c'est du Symfony + MySQL en stockage primaire et Elastic search pour le search en front. Avec du bootstrap et du JS classique (jQuery & co, pas de SPA).
On héberge ça sur 2 dédibox pour un total de moins de 100€ par mois
On fait quelques millions de pages/vues (ou appels API qu'on expose) par mois et les serveurs se tournent les pouces grosso modo
 
Pour moi ton risque principal il est pas technique, c'est surtout d'avoir des expressions de besoins fonctionnels qui tiennent la route.

J'ai rien fait pour l'instant. Je suis en phase de recherche. Mais I dig what you are saying    
J'en ai un. Je n'ai jamais essayé avec les jeux que j'ai par contre.
 

Oh bordel

j'ai dis ça parce que je bosse avec en ce moment, mais un mysql /postgresql pas trop mal paramétré tiens largement la charge. Tu peux utiliser n'importe quel outil que tu maitrisew pour 99% des projets (sauf si tu ne maitrise que windev) si le but est de sortir un produit qui marche plutot que de s'amuser a apprendre de nouveaux trucs

on a choisi mongo/node/react ici, hebergé chez ovh.

 
Oui, c'est l'approche que j'aurais par défaut, mais ce que je veux dire c'est que j'ai vraiment beaucoup entendu de mal de Mongo et que c'est inhabituel par rapport à d'autres solutions de bases document ou clé/valeur distribuées.

déjà on ne l'utilise pas en distribué ( ce sera uniquement quaand on touchera les limites de perfs qui sont loin)

aucun soucis pour l'instant pour notre usage ( des documents avec des formes très variables, quelque Go de données)

Perso, j'aurai préféré postgresql + JSONStore, mais mon collègue est a fond mongo. Il faut choisir ses combats

 
ça dépend si t'es sur la full ou la Light Edition

 
 
L'idée de la V1 c'est déjà de faire du cash et d'avoir pas mal d'utilisateurs et selon eux ca peut monter très vite, ils ont déjà beaucoup de gens interessé.
 
Donc je vais pas tout redev en me disant "merde j'aurais du penser à ca".
 
Pour la stack oui ça sera du Node côté back ou Symfony. Front avec React et MySQL pour la BDD. Du classique.

Fait du modulable.  
 
Tu VAS te dire " oh merde, j'aurai du penser à ça", fait en sorte que l'impact soit faible. Livre un truc qui marche maintenant, ne crame pas ton énergie a préparer une scalabilité dont tu ne sais pas les besoins. Il y aura probablement des pivots plus ou moins important au début de l'histoire. Difficile de faire pivoter une usine
 
Et au pire, je te rappelle que facebook est en PHP et à scalé un moment comme ça  
Leboncoin c'est UNE base postgresql  
Stackoverflow c'est UN sql server
Twitter a longtemps été en RoR
 
est ce que tu penses que tu vas être plus gros que ça à court terme ?

Ouais.
 
 
Non pas du tout. Merci de ta réponse.

Ils ont tenu quoi... 2 ans avant que ça leur pète à la gueule ?

C'est quand même un bon exemple de ce qu'il faut pas faire.
Après avec d'autres contraintes, si ton framework web ne fait que du middleware, peu importe en effet.

Il étaient déjà a plusieurs centaines de millions d'utilisateurs quand ils ont viré ror de mémoire. Ca laisse un peu de marge.
 
 
 

Ils ont monté un truc qui leur a permis de devenir populaire, et de toute manière leur revirement c'est parce-qu'ils ont réalisé qu'ils étaient un système de broadcasting pas une application web, ils auraient pu utiliser n'importe quoi d'autre ça aurait pas changé grand chose, parce fondamentalement leur corp de métier tenait juste pas dans une logique "framework web".

Et IIRC le "frontend web" est resté en ror, c'est le backend/la logique de routing qui a été transformée après avoir réalisé quels étaient leurs besoins.

Sauf que potentiellement ils auraient pas utilisé ror ils auraient pas progressé aussi vite, ils seraient pas devenus populaires, et ils auraient jamais découvert ce qu'ils étaient censés être

C'est beau la scalabilité

Ici je me retrouve seul à gérer une stack d'un front répliqué 2 fois, une DB répliquée 3 fois, un load balancer, un elasticsearch, un CDN (unique hein... v'la l'intérêt) et j'en passe.

Tout ça a été monté avec le cul, pour un site web qui aurait largement tenu la charge sans.

Résultat, ça pète tous les 4 matins, et c'est une merde sans nom à remettre en route quand un des éléments décide de partir en couille.

Y'a eu une panne Scaleway hier, résultat, 6h d'intervention pour remettre en route le bouzin

C'est franchement pas un truc à prendre à la légère, et si tu veux VRAIMENT un truc scalable bien comme il faut... t'as plutôt intérêt à le faire HYPER correctement, parce que ça fait rapidement plus de mal que de bien à ce stade du projet.

flo: En 2008 ils étaient pas à des centaines de millions, loin de la, quelques dizaines tout au plus.
 

Ils auraient pu réaliser un peu plus tôt que leur monolithe en Rails allait pas tenir, c'est tout ce que je dis.
Alors qu'au début ils étaient un peu dans le déni, cf. les confs RoR où ils expliquaient gaiement comment ils géraient (ou pas) la mise à l'échelle.
 
Selon les développeurs de Finagle qui en discutent publiquement aujourd'hui, leur épiphanie a quand même été une période de gros stress, et les instabilités à répétition auraient pu faire plus de mal à la popularité du produit justement.
 
D'autres, dont Facebook par exemple, ont beaucoup mieux géré, et pour moi c'est intéressant de comprendre comment et pourquoi, même si tu atteindras jamais des volumes comparables.

Ce que j'ai appris avec le temps, c'est qu'il vaut mieux pondre un POC rapidement, voir si ça prend et se poser les questions ensuite.
 
Quand je vois le nombre de projets que j'ai pu monter en essayant de faire "tout bien comme il faut" pour qu'au final ça ne fonctionne pas... ce sont des semaines foutues en l'air.
 
Alors oui, le jour où ça fonctionne et qu'il faut tout migrer petit à petit on se dit "merde, si j'avais pensé à ceci/cela avant...", mais personnellement je préfère me casser le cul a posteriori en me disant "là je bosse pour quelque chose... je bosse parce que ça marche", plutôt qu'a priori et me rendre compte que j'ai bossé pour rien

La boite a été fondée en 2006 et le virage a été pris circa 2009

Les gens qui ont développé un compilateur, une VM et un cousin à leur langage de base pour pas en changer?

 
 
Au pire, on duplique les serveurs et on mets des HA proxy.

Ils avaient déjà conscience de leurs problèmes architecturaux en 2008 pendant la coupe du monde.
Un an pour se dire, allez on engage une équipe pour écrire un système de RPC distribué qui tiendra mieux la charge, remis dans le contexte ça me semble assez long quand même.
 

C'est sale mais ça marché.
 
De ce que je sais ils ont eu pas mal de soucis avec Memcache et MySQL aussi.

un concurrent se fait défoncer sur tripadvisor  
 
schadenfreude ++

 
Toi, tu dois relire l'histoire de Youtube.
 

 
YAGNI, premature optimization, etc...
 
1/ la plupart des trucs qui marchent ont utilisé une techno avec lesquels ils pouvaient itérer rapidement pour sortir des features.
2/ la scalabilité tu peux quasiment jamais prédire où le problème sera, ni comment le résoudre (et je parle en ayant géré un site dont le traffic a explosé, et qui drive 2 milliards de CA online). C'est toujours le maillon le plus faible qui pète, et tu sais rarement où il est précisément (on a eu des pet de charge pour de la contention sur les IO de la base, les caches web, des problèmes de query mal écrites, des problèmes d'algo, des problèmes de cache applicatifs, des problèmes d'ORM, des problèmes de tuning de JVM, etc...
 
Prend un truc avec lequel tu es productif et où tu peux itérer vite.
 

ditto
 

Pas 1 an pour se dire ça, 1 an pour le faire, sans interruption de service et que ça fonctionne aux échelles qu'ils avaient déjà

Bah Twitter aussi, t'es un peu beaucoup 2 poids 2 mesures.

Morale de l'histoire, montez vos projets avec de la techno simple, éprouvée et vous résoudrez vos problèmes de scaling quand vous en aurez.

C'est un bon résumé. Pour XO, on aurait pas crée le produit aussi vite si on avait su qu'il serait déployé dans des archi de 4k+ VMs…

Mais pendant ce temps la fail whale était un running gag d'un côté, et de l'autre les utilisateurs avaient un service stable.

Les besoins/contraintes et la vitesse de croissance étaient pas exactement les mêmes non plus

C'est pas exactement comparable bien sûr, mais si tu regardes les courbes de croissance jusqu'à ~100 MMAU, elles sont très très similaires.
 
On va pas faire 3 pages là-dessus, je pense que Twitter reste un bon cas d'étude, qu'on soit d'accord ou pas sur leur capacité d'anticipation.

Sauf qu'elle a pas le même impact sur les besoins. Sur twitter chaque utilisateur reçoit potentiellement une large fraction des productions du site, pas sur fb (d'autant moins à l'époque, les biz commençaient juste à arriver sur fb), et d'autant moins avec une certaine attente de bas délai.

Sure.

https://googlesystem.blogspot.ch/20 [...] #gsc.tab=0

J'avais lu une interview d un gars qui bossait sur GVideo à l'époque et qui disait qu'en fait ils arrivaient pas à suivre le rythme de nouvelles features imposé par Youtube, qui bossait en Python (qui n'est pas le langage qui vient en premier quand on pense perf et scalabilité, en tout cas pas en 2006)

Bilan : fonctionalités > perf, quand tu lances

PS : sauf erreur, il y a toujours des bouts de Youtube en Python

Me rappelle qu'Eve Online, quand ils ont voulu scale leur infra (notamment la base de donnée des inventaires) qui n'était pas "shardée" (i.e. tous les joueurs jouent dans le même univers), ils ont simplement tout foutu en RAM. Genre toute la putain de base de données, dans un disque virtuel massif.

aujourd'hui il n'est pas hors de question d'avoir 1To de ram.

alors évidemment, il faut pas se prendre les pieds dans la multiprise

Chez supermicro ça monte à 6

chez AWS tu as 4 To de ram  https://aws.amazon.com/fr/ec2/instance-types/ pour les plus grosse instances  
 

http://highscalability.com/eve-online-architecture mais c'est trop vieux, le coup de la DB en RAM ça devait être 2006.

edit edit : > http://www.datacenterknowledge.com [...] rver-shard

Bon j'ai du mal me souvenir ou lire un article de merde à l'époque, c'était sur des SSD.

 
Oui oui je me doute, mais j'ai juste un ptit peu la pression sur les devs à produire quoi.
 
Après je suis archi motivé.

Donc tu as la réponse à ta question : tu vas y aller, et ça va plutôt bien se passer malgré des moments de doute  
 
Et sinon un client nous a demander de mettre en place une confirmation sur la confirmation. Je commence à douter de mes choix de vie

 
Êtes vous sûr ?
 
Vraiment ?

Oui pareil. On en parlait encore cet a-m.
Mais il semblerait que les problèmes techniques les plus importants ont été plus ou moins résolus (heureusement, depuis le temps et avec tout le cash qu'ils ont).
Mais le use case de Mongo reste bien particulier:
- pas de relationnel
- pas de transactionnel
- document store plutôt en lecture qu'en écriture (ou avec un seul écrivain, à cause du point 2)
C'est un use case assez courant somme toute. Les deux premiers points sont communs à pas mal de bases NoSQL. Je vois plus Mongo comme une couche d'accélération que comme un data store principal à cause de ces limitations. C'est comme ça qu'il est utilisé la plupart du temps, je pense.
Il y a aussi le fait que ça va vite tant que les index se trouvent en RAM (du moins c'était le cas quand j'avais regardé, il y a des années). S'ils ne tiennent pas en RAM, il faut sharder pour qu'ils tiennent dans la RAM des shards. Sinon les perfs s'écroulent, - enfin ne sont pas fondamentalement différentes de celles des SGBDR -.
Je vois que la version 4 en développement prévoit une sorte de transactionnel. A ce moment-la, je pense que Mongo sera une alternative sérieuse aux SGDBR, puisque le transactionnel garantira une certaine intégrité des états.
 
 
Un comparatif de perf entre MongoDB 3.4 et Postgres 9.6
Sur une seule box, Postgres est plus rapide et bcp plus stable. Par contre Mongo est shardable, il n'a d'intérêt que si on sharde 3 ou 4 instances minimum. A ce moment-la, les perfs et les facilités de maintenance peuvent emporter la décision.
 
(Ah et puis accessoirement il y a les histoires horribles des bases MongoDB qui étaient cryptées par des ransomwares )