Cloud Magazine

Tout d'abord comment définir la notion de NoSQL ? Olivier Mallassi (Octo) écrivait sur le blog Octo (11 novembre 2009) : "L’avènement du Cloud et la transparence (maitrisée) de ses acteurs nous permet de découvrir quelques-uns systèmes mis en œuvre chez des acteurs comme Amazon ou Google. Les offres de type SimpleDB, Google Data Store nous font certes rêver mais permettent également de découvrir des solutions utilisées en interne des grands sites web avec par exemple la BigTable du côté de Google ou bien Dynamo du côté d’Amazon.
Ces systèmes innovants ont été développés sur mesure pour répondre à des enjeux de charge quasi hors normes (à titre d’exemple, pour eBay, on parlait il y a quelques années de 1 milliard de pages vues et de 44 milliards de requêtes par jour) tout en étant fortement adaptés aux spécificités de chacune de ces plateformes et de leur utilisation : Amazon et eBay – avec des notions de stock, facturation, consultations et recherches de produits… – utilisant leur espace de stockage de façon différente de Google – qui propose un moteur de recherche – .

Sur Wikipedia nous avons : "NoSQL (« Not Only SQL ») est une technologie relative aux bases de données, qui a émergé à partir du printemps 2009. Le terme se réfère au stockage non relationnel de données en vue d'améliorer les bases de données dans une direction nécessitant une évolutivité horizontale. NoSQL tente de répondre à cette exigence. Google BigTable et Amazon Dynamo (en) exploitent des bases de données de type NoSQL.

Le noSQL User Group Paris écrit sur sa page officielle : "noSql (Not Only SQL) regroupe l'ensemble des technologies alternatives aux technologies classiques de bases de données relationnelles. "

Bref, noSQL concerne toutes les bases n'utilisant pas SQL. Mais on oppose souvent SGBDR et noSQL alors que ce n'est pas tout à fait vrai. Une base SGBDR n'est pas forcément SQL même si la plupart le sont. Car on peut attaquer une base de données par un langage non SQL, regardez l'approche Linq de Microsoft. Mais les bases noSQL cible les énormes volumes de données et les contraintes de montée en charge telles que l'on peut en avoir sur le cloud. Et les bases noSQL sont non relationnelles et autorisent des montées en charge très haute car leur structure est plus légère et plus réactive. Mais on aurait pas forcément la même idée de persistance, de consistance de la donnée.

Qui a besoin d'une approche noSQL et quand ? La question se pose depuis quelques mois. Car les données de type spatiales ont tout de même besoin d'une structure forte et ces données ont besoin d'être persistance cependant, on peut arguer qu'il faut de la performance, de la réactivité. donc une approche noSQL même si on peut sur la qualité (?) des données au final. Ainsi Azure Storage peut être vu un noSQL car non relationnel, contrairement à SQL Azure.

basiquement, une base noSQL aura 4 types de bases : orientées colonnes, basées sur la théorie des graphes, orientées clé-valeur et orientée document. Nous y reviendrons dans un futur post plus complet.

Mais finalement pourquoi adopter un noSQL ? Voici quelques arguments publiés sur le site highscalability.com :
- noSQL est fait pour les grosses données, le grand nombre d'utilisation. Bref pour des volumétries colossales. Sa structure est en effet très souple
- haute performance dans l'écrire : c'est important, il faut que la base stocke en temps réel ou quasi la donnée. (voir Twitter, facebook)
- accès rapide à la donnée
- les différents de base constitue un avantage.
- idéal pour le parallèlisme et simplifie le travail du développeur

le post complet : passionnant à lire ! ICI

Et vous qu'en pensez-vous ?