Alors, pourquoi écrire ce sujet sur facebook et git?
Simplement, parce que je pense que c'est une actualité qui vaut son pesant d'or pour des passionnés de veille comme moi.
Simplement, parce que je pense que c'est une actualité qui vaut son pesant d'or pour des passionnés de veille comme moi.
Jusque il y a deux ans, facebook, déjà présent sur Github, utilisait subersion comme CVS (Control Versioning System).
Mais voilà, avec une base de données ultra volumineuse de fichiers sources, à peu près 17 millions de lignes de code pour 44000 fichiers vérifiés, modifiés toutes les semaines, facebook avait besoin d'un cvs beaucoup plus puissant que Subversion.
Mais voilà, avec une base de données ultra volumineuse de fichiers sources, à peu près 17 millions de lignes de code pour 44000 fichiers vérifiés, modifiés toutes les semaines, facebook avait besoin d'un cvs beaucoup plus puissant que Subversion.
Le choix, Git ou Mercurial?
Sachant qu'aucun de ces deux outils n'a la puissance nécessaire pour tenir de tels builds, le choix s'est tout de même porté sur Mercurial.
Les raisons sont encore inconnues, mais nos amis de chez facebook, ont beaucoup contribué à son amélioration.
Sachant qu'aucun de ces deux outils n'a la puissance nécessaire pour tenir de tels builds, le choix s'est tout de même porté sur Mercurial.
Les raisons sont encore inconnues, mais nos amis de chez facebook, ont beaucoup contribué à son amélioration.
Les stratégies?
1. Améliorer le système de reconnaissance d'update de fichiers.
Au lieu de parcourir tous les fichiers d'un repository afin de détecter les mises à jour de fichiers, ce calcul est réservé à un outil de monitoring, appelé watchman, qui est spécialement chargé de sauvegarder et stocker les modifications sur fichiers.
Cela engendre un gain en performance signifiant surtout sur des bases de données Big data, de la qualité de facebook.
Au lieu de parcourir tous les fichiers d'un repository afin de détecter les mises à jour de fichiers, ce calcul est réservé à un outil de monitoring, appelé watchman, qui est spécialement chargé de sauvegarder et stocker les modifications sur fichiers.
Cela engendre un gain en performance signifiant surtout sur des bases de données Big data, de la qualité de facebook.
2. La seconde solution d'optimisation consiste à la réduire le volume des données lors des opérations de clonage et de récupération, en n'utilisant que les dernières versions de build.
Les développeurs désirant récupérer des fichiers d'anciennes versions seront invités à les télécharger depuis le RFL (Remotefilelog), conçu également par facebook.
Les développeurs désirant récupérer des fichiers d'anciennes versions seront invités à les télécharger depuis le RFL (Remotefilelog), conçu également par facebook.
3. La dernière optimisation est plus subtile.
Le principal avantage d'un cvs, est de ne pas avoir recours à un serveur distant. Les fichiers de commit sont mis en cache grâce à remotefilelog, outil de mise en cache des commits crée par facebook. De plus, facebook utilise sa distribution MemCache en frontal du serveur Mercurial, ce qui permet un backup immédiat en cas de chute de la plateforme.
Le principal avantage d'un cvs, est de ne pas avoir recours à un serveur distant. Les fichiers de commit sont mis en cache grâce à remotefilelog, outil de mise en cache des commits crée par facebook. De plus, facebook utilise sa distribution MemCache en frontal du serveur Mercurial, ce qui permet un backup immédiat en cas de chute de la plateforme.
Alors, l'avenir appartient-il à Mercurial, ou Github gardera t'il son monopole?
Aucun commentaire:
Enregistrer un commentaire