NoSQL?
- Détails
- Catégorie : News
- Publié le mercredi 3 avril 2013 21:20
- Écrit par Administrator
- Affichages : 47036
Il n’y a pas longtemps encore, j’étais persuadé qu’Amazon utilisait une base de données Oracle… et je me disais : « ouah, les performances ! Toutes les requêtes répondent instantanément, je peux même aller voir dans toutes mes commandes depuis 2002, tout remonte en une fraction de seconde avec la facture plus la description de l’article et son image, même pour des articles plus vendu depuis longtemps!!!!. Et pourtant il doit y avoir des millions de million de commande depuis la création d’Amazon, et le nombre d’article différent vendu depuis la création d’Amazon doit être énorme !! »…
Puis j’ai appris... Amazon avait développé son propre SGBD, et c’est une base de données de type NoSQL. Je pense alors à Google… pareil… son propre SGBD de type NoSQL.
Mais que signifie donc NoSQL et c’est quoi un SGBD NoSQL ? Et mon gagne-pain Oracle, il fait quoi ?
NoSQL veux dire Not Only SQL. Ce sont des SGBD développés pour des bases de données volumineuses en privilégiant la performance au détriment de la mise en œuvre stricte de la règle ACID (Atomique, Cohérente, Isolée et Durable) d’une transaction. C’est entre autre le mécanisme de transaction ACID qui, dans un SGBD relationnels comme Oracle Database, DB2, SQLServer…, pénalise les performances à matériel équivalent.
Ce sont les géants du Web (Amazon, Google, Facebook…) qui, au vu des volumétries toujours croissantes qu’ils ont à traiter, et au temps de réponse rapide attendu par les utilisateurs (dont moi ) , ont mis en avant ces SGBD en développant leur propre moteur.
Les bases NoSQL ainsi développées sont des bases de données fortement distribuées pour être fortement scalable (besoin de puissance en plus, un serveur en plus what else ?). Or le théorème de Brewer (théorème de CAP) dit qu’il est impossible sur un système informatique de calcul distribué de garantir en même temps les 3 contraintes suivantes :
- Cohérence (Consistency) : tous les clients voient les mêmes données à un instant t.
- Haute Disponibilité (Availability) : En cas de panne, les données continuent à être disponibles aux requêtes.
- Tolérance au Partitionnement (PartitionToleranc ): Le système est tolérant au partitionnement (au morcellement) c'est-à-dire à part une panne totale de réseau, si il y a un morcellement en sous-réseaux chaque partie de sous-réseaux (partie du sgbd en fait) doit pouvoir fonctionner de manière autonome.
Et c’est souvent la cohérence qui est sacrifiée au profit de la disponibilité et de la tolérance au partitionnement. Cela peut s’illustrer par l’exemple suivant :
Que tous les utilisateurs n’aient pas forcement le même résultat sur une recherche google à un instant t (pas de cohérence) mais qu’ils aient un résultat non NULL et rapide, est bien plus important que, d’ assurer une cohérence de résultat mais un résultat NULL en cas de crash d’un sous-système (pas de Haute Dispo).
Amazon applique aussi le même principe pour chercher des articles et remplir son panier, en revanche au moment de payer, nous sommes basculé sur une base relationnel de type ACID… enfin j’ose espérer .
Ces bases de données peuvent être classé en 4 types. Cela est très bien expliqué sur le blog http://blog.neoxia.com/nosql-5-minutes-pour-comprendre/
Et pour ne pas paraphraser, et gagner du temps, citons le :
- Clé / valeur : Ce modèle peut être assimilé à une hashmap distribuée. Les données sont, donc, simplement représentées par un couple clé/valeur. La valeur peut être une simple chaîne de caractères, un objet sérialisé… Cette absence de structure ou de typage ont un impact important sur le requêtage. En effet, toute l’intelligence portée auparavant par les requêtes SQL devra être portée par l’applicatif qui interroge la BD.. […]
- Orienté colonne : Ce modèle ressemble à première vue à une table dans un SGBDR à la différence qu’avec une BD NoSQL orientée colonne, le nombre de colonnes est dynamique. En effet, dans une table relationnelle, le nombre de colonnes est fixé dès la création du schéma de la table et ce nombre reste le même pour tous les enregistrements dans cette table. Par contre, avec ce modèle, le nombre de colonnes peut varier d’un enregistrement à un autre ce qui évite de retrouver des colonnes ayant des valeurs NULL. […]
- Orienté document : Ce modèle se base sur le paradigme clé valeur. La valeur, dans ce cas, est un document de type JSON ou XML. L’avantage est de pouvoir récupérer, via une seule clé, un ensemble d’informations structurées de manière hiérarchique. La même opération dans le monde relationnel impliquerait plusieurs jointures. […]
- Orienté graphe : Ce modèle de représentation des données se base sur la théorie des graphes. Il s’appuie sur la notion de noeuds, de relations et de propriétés qui leur sont rattachées. Ce modèle facilite la représentation du monde réel, ce qui le rend adapté au traitement des données des réseaux sociaux. […]
Les bases de données NoSQL ne remplacent donc pas les « classiques », elles ne répondent pas aux mêmes besoins. De plus les bases NoSQL sont relativement jeunes comparés aux SGBD classiques, il n’y a pas de norme comme JDBC ou SQL, seulement un début de travail de normalisation de langage commun (UnQL : unstructured Query Language).
… et Oracle dans tout ça ?...
Oracle après avoir dénigré le mouvement NoSQL dans le white paper… : "An Oracle White Paper May 2011 Debunking the NoSQL Hype" qui n'est plus trouvable sur le site d'Oracle, et dont les 2 dernières phrases résument ce qu'Oracle Corporate pense du NoSQL:
Go for the tried and true path. Don't be risking your data on NoSQL databases.
... sort sa version, nommé Oracle NoSQL (tout simplement), et dans un beau white paper, toujours en ligne celui-là (nosql-database-498041.pdf), écrit que cela fait plus de 8 ans qu'il en fait et en vend du NoSQL avec sa version Oracle Berkley DB Java Edition. Et la conclusion du document est à l'opposé du premier:
Oracle’s NoSQL Database brings enterprise quality storage and performance to the highly-available, widely distributed NoSQL environment. Its commercially proven, write-optimized storage system delivers outstanding performance as well as robustness and reliability, and its “No Single Point of Failure” design ensures that the system continues to run and data remain available after any failure.
... j'achète!!!
Plus sérieusement, j'ai très envie d'essayer. Je vais essayer de monter un banc de test et je mettrais la procédure (si j'y arrive et/ou ait le temps) dans la rubrique "about testbed"
Sources :
http://www.oracle.com/technetwork/database/nosqldb/learnmore/nosql-database-498041.pdf
http://blog.neoxia.com/nosql-5-minutes-pour-comprendre/
http://davidmasclet.gisgraphy.com/post/2010/06/09/10-minutes-pour-comprendre...NoSQL
http://fr.wikipedia.org/wiki/NoSQL
http://fr.wikipedia.org/wiki/Th%C3%A9or%C3%A8me_CAP