novembre
2009
Un article de Skyounet
Alors tout d’abord veuillez m’excuser pour ce post sans accent, j’ecris ce post sur mon nouveau tablet PC qui possede un clavier qwerty !
Nouvelle session consacree a Windows Azure et plus specialement les Tables et les Queues.
En realite cette session nous presentait les best pratices a adopter.
Tables
Une entite dans une table possede plusieurs proprietes comme une PartitionKey et une RowKey.
La Partition Key est utilisee pour repartir les donnees sur plusieurs serveurs pour permettre un acces plus rapide aux donnes les plus demandees par exemple.
Le speaker nous montre ainsi une exemple avec une application de gestion de film ou tous les films sont stockes dans une table Azure.
Le speaker commence par un cas ou la PartitionKey est statique (nomme movie) et la RowKey est le nom du film. Resultat : toutes les donnes se retrouve sur le meme serveur, vu que les PartitionKey sont identiques.
Deuxieme cas, la PartitionKey est la categorie du film : les donnees peuvent etre stockees sur differents serveurs en fonction de leur categorie (PartitionKey).
Concernant la RowKey, cette derniere est utilisee pour acceder a une entite unique. Via le couple PartitionKey/RowKey, Azure retrouve le serveur ainsi que l’entite recherchee.
Maintenant imagineons que nous voulions recuperer tous les films dont le rating est superieur a 4.
Une requete serait donc : select * from movies where rating > 4
Le probleme ici est que Azure va parcourir notre table entiere serveur par serveur.
L’idee est donc de decouper cette requete en plusieurs requete basee par exemple sur la premiere lettre la categorie : where Category > ‘A’ and Category < ‘F’
On se retrouve donc avec plusieurs requetes qui peuvent etre lancees en paralleles ! Donc plus rapide.
La vitesse de la requete depend des champs utilisees
- Rapide : PartitionKey & RowKey
- Moyen : une seule partition mais un range de RowKey limite
- Lent : scan complet de la table, par exemple avec l’exemple montre plus haut
Queues
Les Queues permettent d’empiler/depiler des messages pour des traitements divers et asynchrones (plusieurs reader peuvent lire la meme queue). Les messages doivent avoir une taille < 8 Ko.
Les consommateurs, typiquement un Worker Azure, vont ensuite depiler ces messages et les traiter. Lorsqu’un message est lu et traite, si le worker plante le message est remis en pile. Un second worker va alors depiler ce message et le traiter. Dans le cas ou c’est le message qui pose probleme (le worker 2 plante egalement) un systeme permet de detecter le probleme et de supprimer ce message.
Le SDK inclus plusieurs exemples utilisant les Tables et les Queues.
Je reviens egalement d’un Hands On Lab sur le stockage Azure sur lequel je ferais un retour plus tard.
Merci à Techtra, pour cet évènement.
Partenaire Or Microsoft et membre prestige du Excellence Gold Partner Program de Microsoft, Techtra est une entreprise privée qui se démarque par son expertise inégalée dans les domaines de la gestion de documents, de contenus, d’automatisation de processus d’affaires, d’intranets, d’intelligence d’affaires et de développement d’applicatifs avec la plateforme SharePoint de Microsoft. Fort de ses 19 années d’expérience dans ces domaines d’affaires, Techtra offre des services de développement, de consultation d’intégration et de développement applicatifs sur Sharepoint. Ses services, produits et solutions d’affaires sont disponibles à travers le monde via un réseau de partenaires stratégiques. http://www.techtra.ca
Et voila, un de plus sur un clavier qwerty ;)…et a quand les videos avec la camera ?
Sinon, ca a l’air pas mal comme solution, aussi bien pour contourner la limite de taille des bases que pour avoir des vitesses de traitement de ouf..