Une session présentée par David Robinson (après une introduction musicale: “it’s time to change”)

Cette session va se focaliser sur l’évolutivité horizontale, notamment en rapport avec la taille maximale d’une base SQL Azure (10 Go) mais également en termes de gestion de la montée en charge.

David reprend le cas de Kelly Blue Book:

  • 13 millions de visiteurs par mois,
  • 2.5 Go de données,
  • données rafraîchies toutes les semaines,
  • données répliquées sur 5 bases,
  • incrémente/décrémente le nombre de bases à la demande.

L’on aura le code source de la session sur CodePlex comme Startup Kit.

Chris Auld monte sur scène pour décrire l’architecture TicketDirect: montée en charge en partitionnant les bases de données sur une centaine d’instances SQL Azure pour gérer les pics de demande.

IMG_0041La montée en charge va dépendre de la nature de la base; l’on va soit partitionner les données en morceaux basés sur des intervalles (temps par exemple), soit via des principes de hachage (hashing). Il faut choisir la bonne méthode avec précaution par rapport au type d’usage.

David prend un exemple type e-commerce. On a deux schémas: Produits et Clients.

Produits n’a pas énormément de données mais peut devenir très “chaud”; on divise donc ce schéma sur plusieurs petites bases de 1 Go. L’on peut voir toutes les bases avec SQL Server Management Studio: Product_1, Product_2, etc.

Dave montre le code qui permet de charger les données avec l’API SqlBulkCopy.

Ensuite, on regarde l’application Web (http://fabrikamfish.cloudapp.net/) qui permet de choisir une famille, un élément, etc. Si l’on demande un produit spécifique, l’application va directement diriger la requête sur la bonne base ou “partition”. Si l’on fait une recherche, l’on va effectuer une requête qui va balayer toutes les données et doncva devoir interroger toutes les bases.

On a typiquement une boucle qui répète la requête SQL sur l’ensemble de bases, puis fusionne l’ensemble des résultats. Cela permet donc de répartir la charge sur l’ensemble des noeuds. Ce code sera sur CodePlex.

On passe à la base Clients. Là on a choisit un système de hachage basé sur l’adresse e-mail de l’utilisateur pour partitionner les données sur plusieurs bases, là aussi de 1 Go, sachant que l’on peut passer sur des instances de 10 Go plus tard si nécessaire.

Dans le code de chargement, l’on voit qu’on utiliser une méthode GetInt64HashCode() qui utilise un hash MD5 pour hacher les données clients.

Conception du schéma

  • SQL Azure ne supporte pas les transactions distribuées. Il faut donc éviter les jointures et transactions entre bases.
  • Le DDL doit être conçu pour supporter les évolutions.
  • Pour gérer les évolutions applicatives, l’on doit pouvoir savoir gérer plusieurs versions du schéma à un instant t

Routage des requêtes

  • L’application doit gérer ce partionnement

Data de référence & synchronisation

  • Eviter les jointures entre bases: pour les données de référence type “code postal”, on les réplique dans toutes les bases
    • Sync Framework pour SQL Azure annoncé mardi; l’on peut l’héberger dans un Worker Role
    • Scripts de mise à jour manuels

Requêtes “fan out”

  • Envoyer les requêtes en parallèle à la base
  • Utiliser des connexions multiples et du multithreading

Support du fan-out dans le futur

L’on aura de meilleurs outils pour les développeurs et les administrateurs.

  • Division dynamique de partitions
  • Possibilité de fusionner des partitions
  • Améliorer la gestion du schéma sur toutes les partitions

Et des fonctionnalités:

  • Gestion de connexions
  • Support des requêtes de type fan-out