Comment peut un grand spécialiste de location par correspondance nord américain croître sa capacité de gestion de la relation par Internet sans agrandir ni multiplier son centre de traitement informatique ? Et pourquoi préfère-t-il ne pas agrandir sa capacité propre de traitement ?
Netflix arrivait à une ampleur d'affaires et un taux de croissance qui l' obligeaient à faire croître sa capacité de traitement interactif. Et ils ne le savaient pas encore, mais les supports d'interactivité allaient aussi se multiplier avec arrivée des smartphones, iPad, netbooks, créant de nouveaux besoins d'applications. Jusque là, il réalisé tous ses traitements informatiques dans un seul centre avec les RDBMS Oracle et MySQL. Comment croître rapidement, de façon extensible, sans prendre trop de risque ?
Multiplier les RDB, faire des grappes avec réplication est une solution, mais qui atteint des limites assez rapidement. Une variante de cette stratégie est celle choisie par eBay, décrite dans l'article Netflix’s Transition to High Availability Storage Systems par Siddarth Anand. Chez eBay, ils ont dénormalisée les données pour éviter des opérations couteuses (jointures, notamment) au moment de fournir une page (ou morceau de page par AJAX), répliqué les données et multiplié les indices, et pris encore d'autres mesures pour assurer la rapidité des lectures. Il peut subsister un peu de latence pour lecture-après-écriture, quoique ils charge ces opérations sur les bases maîtres, pas vers les répliques.
Et si, raison numéro 4 pour s'intéresser aux bases de données “nosql” dans la liste de Richard Jones
You hate MySQL, and although PostgreSQL is much better, it still doesn't have decent replication. There's no chance you're buying Oracle licenses.
Le choix de Netflix était similaire à celle de eBay, mais au lieu de stocker les données dénormalisées dans des RDBMS additionnels, ils ont préféré un stockage en magasins clef-valeur en location chez Amazon. Ces magasins, S3 et SimpleDB, sont décrits par Anand dans des termes très compréhensibles, surtout pour des lecteurs ayant des connaissance en RDBMS. SimpleDB permet de stocker des listes des paires clef-valeur pour des valeurs de petite taille. S3 permet de stocker des paires clef-objet, pour des objets pouvant être grands; la gestions des propriétés des objets est la responsabilité des applications, lecture-écriture se fait par objet entier. Amazon assure une réplication de ces magasins pour qu'ils demeurent disponibles. La réplication n'est pas toujours instantanée mais aboutit toujours rétablissant la cohérence des données. C'est le système dit “Eventually Consistent.”
Ces petites incohérences provisoires sont le prix à payer pour haute disponibilité et tolérance de pannes des répliques : c'est affirmé par le théorem CAP de Brewer, expliqué et démontré par Gilbert et Lynch avec conseils de C. Leiserson. C'est un résultat pas très étonnant pour les étudiants de fiabilité, car plus on augmente la nombre de répliques, plus on a de chances d'en avoir en panne à chaque instant.
L'article ne mentionne pas des alternatives que Netflix aurait étudié. Il analyse de façon critique la solution RDBMS d'eBay, vulnerable à des problèmes de blocage en cas d'échec d'une des deux répliques, mais n'explique pas comment Netflix aurait évité ce problème pour le RDBS “backoffice” qu'ils ont gardé.
En somme, un abord intéressant d'une partie de l'offre AWS, mais pas la présentation d'un “role model.”