Le service de stockage et de partage de photos en ligne Flickr n’a plus autant la côte qu’il y a quelques années mais reste un des services de photos les plus utilisés avec plusieurs centaines de milliers d’utilisateurs et des milliards de photos stockées et correctement rangées autour de profils utilisateurs, groupes et collections. Au total cela représente des To et des To de données. Le site doit fonctionner avec plus de 4 milliards de requêtes et plus de 400000 nouvelles photos ajoutées chaque jour.
Pour organiser toutes ces données, il y a forcément des bases de données derrière et même s’il est difficile d’avoir des données très récentes sur Flickr, l’infrastructure de Flickr se compose comme suit (en 2007 – c’est très vieux) :
- plus de 50 bases de données MySQL réparties sur plus de 100 serveurs ;
- plus de 800000 comptes par serveur ;
- Tout, à part les fichiers médias, est stocké en base de données.
Le principal défi avec les bases de données a été de gérer la forte croissance sans impacter ni les performances ni les coûts opérationnels. Pour cela, Flickr utilise le partitionnement des données. Depuis la base de données centrales qui gère les données principales des utilisateurs, toutes les données d’un même utilisateur se retrouvent déportées dans un « shard » (base de données de taille réduite) permettant un traitement plus simple et plus rapide.
Pour des raisons de coûts, Flickr a aussi mis en place une structure « Dual Tree » qui permet de grossir en ajoutant des serveurs maîtres sans avoir besoin de doubler les serveurs physiques. La croissance se fait de façon horizontal en ajoutant « simplement » des machines.
Pour en savoir plus :
