Bases de données dans le cloud : une évolutivité sous conditions

A lire sur: http://www.zdnet.fr/actualites/bases-de-donnees-dans-le-cloud-une-evolutivite-sous-conditions-39797054.htm

Cloud Computing : Les offres de bases de données relationnelles dans le cloud se banalisent depuis peu mais leur "scalabilité" reste limitée. Pour lever cet obstacle, il faut généralement passer aux offres noSQL qui imposent d’autres contraintes.

Par Thierry Lévy-Abégnoli | Mardi 14 Janvier 2014

Le stockage dans le Cloud recouvre tout d’abord des services de stockage brut comme Amazon S3 ou Microsoft Azure Block Storage. Dans la perspective d’une application traditionnelle, on s’intéressera davantage aux moteurs relationnels et aux bases de données noSQL. Au moins pour des questions de latence, l'application sera presque toujours dans le cloud, près des données.

Bases SQL : des contraintes inhérentes au modèle relationnel

L’offre SQL dans le cloud s’est grandement étoffée depuis 2012. SQL Azure, rebaptisé Microsoft Azure SQL Database, a ainsi été rejoint, entre autres, par Amazon RDS et Google Cloud SQL. Argument premier : la conservation du modèle relationnel limite l’impact sur les applications.

Les offres de Google et d’Amazon reposent d’ailleurs sur un MySQL presque standard. « Parmi les différences avec MySQL, dans le cloud, les possibilités limitées de contrôle et d'administration interdisent un tuning fin », note Dimitri Savineau, ingénieur systèmes et applications chez eNovance.

Quant à la "scalabilité" (ou évolutivité) en principe inhérente au cloud, elle n’est pas au rendez-vous car la taille de la base est limitée (1 To chez Amazon, 100 Go chez Google) et les performances plafonnent également. Sur Amazon, les capacités d’entrées/sorties sont modulées selon la taille de la base mais sans garantie de performances. « On peut allouer davantage de ressources - processeurs et mémoire -  mais on atteint vite un maximum car les acteurs du cloud utilisent des matériels banalisés de faible puissance », explique Djamel Zouaoui, responsable de la R&D noSQL chez Octo Technology.

Ces limites inhérentes au modèle relationnel sont toutefois contournées par SQL Database qui est pourtant une version épurée de SQL-Server. Les bases sont limitées à 150 Go mais un mécanisme de fédération de bases de données permet de partitionner les tables, en colonnes. « On peut ainsi segmenter d’énormes tables et obtenir une élasticité presque infinie », affirme Damien Cudel, chef de marché plate-forme applicative SQL dans le cloud chez Microsoft.

Une "scalabilité" pratiquement infinie grâce au noSQL

Sans artifice de ce genre, les bases noSQL offrent cette élasticité illimitée par simple ajout de nœuds, qui peuvent être très nombreux et de faible puissance, ce qui est justement le cas dans le Cloud. « En contrepartie, il faut refondre le modèle de données pour le "dé-normaliser" », prévient Eric K'Dual, directeur technique chez Neoxia. Les offres se nomment DynamoDB d’Amazon ou HANA Cloud de SAP. Microsoft Azure comprend également un volet noSQL (baptisé Tables) mais on se tournera plus volontiers vers des acteurs comme MongoDB ou Hortonworks, qui ont déployé leurs services dans Azure Block Storage.

Des mécanismes de sauvegarde et de réplication

Les bases dans le cloud sont dotées de services de réplication, au sein du nuage ou vers le datacenter. Les services SQL d’Amazon et Google proposent ainsi une réplication asynchrone. Amazon RDS permet même de répliquer en mode synchrone une instance MySQL, sur différents sites d’une même région. « Cette fonction génère une perte de performances de l’ordre de 80 % », regrette toutefois Dimitri Savineau.

Amazon RDS et DynamoDB permettent en outre de réaliser des sauvegardes vers le service S3 ou vers des supports physiques. Microsoft autorise pour sa part une réplication dans un même datacenter Azure ou entre datacenters distants. L’éditeur favorise également des scénarios hybrides – synchronisation ou migration entre un SQL-Server et le nuage, ou sauvegarde vers le cloud, par exemple à partir de l’outil System Center Data Protection Manager.

Une tarification simple mais une facture souvent non prédictible

Chez Amazon ou Google, le coût est essentiellement fonction de la taille de la base et du nombre d’entrées/sorties. « Malgré cette simplicité, la facture n’est guère prévisible car elle dépend beaucoup du trafic », note Djamel Zouaoui. En noSQL, les coûts sont toutefois moins élevés car la mutualisation des ressources est plus facile, et ils peuvent être modulés plus finement.

« Avec DynamoDB, on peut monter et descendre à volonté avec une granularité d'une heure », précise Eric K'Dual. Pour sa part, Microsoft ne facture SQL-Database qu’en fonction du nombre de bases de données et de leur taille, ce qui assure une meilleure visibilité.