La PaaS Microsoft Windows Azure est l’une des plateformes « as a service » les plus abouties. Cependant, pour éviter les déceptions, il est important de bien comprendre les caractéristiques clés afin d’en faire le meilleur usage possible. Voici les éléments que je vais aborder :
o Que peut-on faire ou ne pas faire avec une instance de calcul ?
o Comment gérer la persistance des données ?
o Peut-on installer d’autres SGBD / Systèmes clé/valeur ?
Je n’ai pu résister à l’envie de poster cette vidéo, publiée il y a déjà quelques temps sur highscalability.com et issue à l’origine du site MyNoSQL, que je ne peux m’empêcher de revoir avec plaisir et que je trouve toujours aussi drôle. Vous n’y apprendrez probablement pas comment scaler votre infrastructure, mais, en tout cas, elle n’est pas dénuée de sens. :o)
Je ne traduirai pas les termes fleuris issus de la langue de Shakespeare, mais je peux vous citer notamment cette perle : « You read the latest post on HighScalability.com and think you are a f*cking Google and architect and parrot slogans like Web Scale and Sharding but you have no idea what the f*ck you are talking about. ». Je trouve que cela résume bien les difficultés, qui ne sont pas d’ordre technique, que l’on peut rencontrer dans le domaine de l’architecture.
A noter également la solution qui consiste à écrire dans « /dev/null » : très intéressante ! :o) Encore plus efficace que l’écriture sur raw device !
Et si vous vous dites après cela que SQL et NoSQL ne peuvent résolument pas cohabiter, rassurez-vous et regardez SQL + NoSQL = Yes !. Vous verrez dans cet article que les 2 modèles peuvent être utilisés ensemble pour obtenir de très bonnes performances.
Data storage has always been one of the most difficult problems to address, especially as the quantity of stored data is constantly increasing. This is not simply due to the growing numbers of people regularly using the Internet, particularly with all the social networks, games and gizmos now available. Companies are also amassing more and more meticulous information relevant to their business, in order to optimize productivity and ROI (Return On Investment). I find the positioning of SQL and NoSQL (Not Only SQL) as opposites rather a shame: it’s true that the marketing wave of NoSQL has enabled the renewed promotion of a system that’s been around for quite a while, but which was only rarely considered in most cases, as after all, everything could be fitted into the « good old SQL model ». The reverse trend of wanting to make everything fit the NoSQL model is not very profitable either.
Le stockage des données est depuis toujours une des problématiques les plus difficiles à adresser, surtout depuis que les quantités de données enregistrées ne cessent d’augmenter. Cela n’est pas simplement dû à la population grandissante qui utilise de façon plus assidue le Net, notamment avec tous les réseaux/jeux/machins sociaux. Les sociétés amassent également de plus en plus d’informations précises sur leur métier dans des objectifs de productivité et de ROI. Je trouve l’opposition SQL et NoSQL (Not Only SQL) un peu dommage : il est vrai que la vague marketing sur le NoSQL a permis de remettre en valeur un système qui ne date pas d’aujourd’hui, mais qui n’était que très rarement envisagé dans la plupart des cas où, après tout, tout rentrait dans le « bon vieux modèle SQL ». La tendance inverse à vouloir tout faire rentrer dans le modèle NoSQL n’est pas très profitable non plus.
How do you scale an AWS (Amazon Web Services) infrastructure? In Part Two of the article, I describe the architecture model and the underlying technical components you should use in order to implement a scalable infrastructure. We will look in particular at the optimisation of data access in scale-out-type architectures suitable for implementation as a distributed system, as much at the data model level as the lower layers for I/O optimisation. We will also examine the recommended development concepts such as Stateless, in the finest REST tradition. I will end the article with some tips and tricks. My aim is to help you set up and optimise your infrastructure by understanding how Amazon tools operate and to get the most benefit from them.
Comment scaler une infrastructure AWS (Amazon Web Services) ? Je vais décrire dans cette deuxième partie de l’article le modèle de l’architecture et les composants techniques sous-jacents à adopter afin de mettre en place une infrastructure scalable. Nous aborderons tout particulièrement le sujet de l’optimisation de l’accès aux données dans les architectures de type scale-out propices à la distribution, autant au niveau du modèle de données que des couches basses pour l’optimisation des I/O. Nous verrons également les concepts de développement à privilégier tel que le stateless dans la plus pure tradition REST. Je terminerai par quelques trucs et astuces en fin d’article. Le but est de vous permettre de constituer et d’optimiser votre infrastructure en comprenant le fonctionnement des outils proposés par Amazon pour en tirer le meilleur parti.
Facebook… En voilà une architecture qui fait rêver et qui laisse songeur au vue du volume de connexions simultanées et de données stockées. J’ai récemment regardé une vidéo très intéressante d’une conférence données par Aditya Agarwal (Director of Engineering chez Facebook) durant le QCon SF 2008 (San Fransisco) sur l’architecture de Facebook et plus exactement la couche logicielle utilisée, basée sur le modèle LAMP (Linux, Apache, MySQL, PHP). C’est essentiellement de MySQL et PHP que la conférence traite sur ce modèle. Une belle part est également faite à Memcache. Memcache, cache mémoire réseau qui n’est plus à présenter, et qui a été optimisé par les développeurs de Facebook pour l’occasion. Une brève présentation d’outils « maison » tels que Thrift, Scribe, … est également effectuée en fin de conférence.
Le sharding ou partitionnement de données entre dans le cadre plus global de la scalabilité. Il s’agit tout simplement du découpage des données d’une base afin d’avoir à requêter sur moins d’occurrences et donc d’avoir un résultat plus rapide donc de meilleures performances. Le sharding est une solution à part entière, mais qui ne convient pas dans tous les cas. Nous verrons également quelles sont les solutions alternatives pour une amélioration des temps de réponse au niveau d’une base de données.
[...]
Decrypt, Le Forum
Decrypt, Le Forum est ouvert ! Venez échanger avec nous et avec la communauté.
ExpertYse
Besoin d'aide ou de conseils sur un de ces sujets ? Contactez-nous !
Besoin d'une formation sur le Cloud Computing ? Contactez-nous !
Vous êtes expert vous-même et souhaitez nous rejoindre ? Contactez-nous !
Commentaires récents