NoSQL, NewSQL, évolution des bases de données
Les principaux sites du Web utilisent une base de données NoSQL. Cela a commencé avec Google et Facebook.
L'extensibilité requise et la grande quantité de données et de mises à jour rendent le modèle relationnel inefficace ce qui a obligé à trouver un nouveau modèle.
Le mot NoSQL est apparu en 2009 pour désigner le nombre croissant de logiciels n'utilisant pas le modèle relationnel classique. Le nom est un raccourci pour "Not Only SQL", en français "Pas Seulement SQL", pour exprimer le fait que l'on veut aller au-delà du modèle classique d'accès aux données, comme cela est expliqué plus loin.
On peut considérer que BigTable créé par Google pour son index est le moteur du mouvement NoSQL, puisque le modèle a été repris par les principaux grands sites du Web.
Pourquoi NoSQL?
Le modèle classique est inopérant face à certains types de traitement:
- Indexation d'une quantité de documents.
- Sites à fort trafic.
- Données de taille variables selon les enregistrements.
- Réécritures fréquentes (le modèle classique prévoit plus de lectures que d'écritures).
- Extensibilité de la base.
- Quand la rapidité est importante.
- Meilleure productivité, c'est plus simple.
Certaines entreprises ne sont pas satisfaites de leur expérience NoSQL et reviennent à MySQL ou MariaDB. C'est le cas de Arstechnica, de Google avec le projet Spanner. Cela est dû aux progrès réalisés quand aux performances de ces BD. Mais d'autres préfèrent NoSQL.
SQL vs. NoSQL
NoSQL est orienté colonnes: entendons par là que l'on peut ajouter des colonnes à chaque enregistrement aussi facilement qu'on ajoute des lignes (par INSERT/UPDATE) dans le modèle relationnel.
NoSQL n'a pas de schéma conceptuel et peut évoluer avec le temps en nombre de colonnes comme de lignes.
Mais qu'est-ce qui fait que NoSQL soit beaucoup plus rapide? Cela tient surtout à la façon dont on traite les colonnes variables.
Prenons un exemple.
Supposons que l'on gère le trafic d'un aéroport avec la liste de tous les vols.
Une table classique aura la forme suivante:
Numéro de vol | Avion | Pilote | Itinéraire |
---|---|---|---|
001 | Airbus | Joe | NY-Delhi |
Mais on ne peut avoir une colonne pour le nom de chaque passager. Et les avions et les vols ont un nombre de passagers très variable, la table contiendrait une quantité de trous et la recherche de données en serait ralentie d'autant.
Voilà comment le modèle relationnel classique traite le problème. On crée une table "Passagers" de la forme suivante.
Numéro de vol | Nom passager |
---|---|
001 | x |
001 | y |
001 | z |
La même table contiendra tous les vols et tous les noms de passagers. Il va de soi qu'accèder aux données suppose le traitement d'une quantité d'informations avant de parvenir à l'information cherchée.
Une ligne de table NoSQL quand à elle aura la forme suivante:
Numéro de vol | Avion | Pilote | Itinéraire | |||
---|---|---|---|---|---|---|
001 | Airbus | Joe | NY-Delhi | x | y | z |
Le nombre de colonnes pour chaque vol dépend du nombre de passagers.
Trouver un passager sur un vol sera évidemment beaucoup plus rapide dans un tel modèle mais surtout, modifier les données sera infiniment plus facile.
NewSQL, une autre approche
Ce n'est pas un format mais une nouvelle approche dans la mise en oeuvre. Le nom originel était "ScalableSQL" et son objectif est la gestion de données à hautes performances.
On reproche à NoSQL de sacrifier le principe ACID (Atomicity, Consistency, Isolation, Durability) , atomicité, consistence, isolation, durabilité, donc d'offrir une moins grande sureté dans l'accès aux données.
Une base de données NewSQL conserve la structure classique en colonnes mais fait appel à différents procédés pour conserver la rapidité même sur de larges volumes.
VoltDB est un nouveau gestionnaire de BD basé sur NewSQL: il est conçu pour fonctionner entièrement en mémoire ce qui lui procure une rapidité sans égale et rend Oracle obsolète.
Base de donnée orientée graphe
Conçue spécialement pour stocker et retrouver les relations entre objets ou personnes, elle est plus efficace que la base de données relationnelle (malgré le nom), pour faire des requêtes sur ces liens. Elle n'a pas de table.
La structure de la base est composée de noeuds et propriétés, qui sont similaires aux objets des LOO, et d'arêtes, des données qui représentent un lien entre deux objets, avec une valeur qui représente le poids du lien. Le nombre de liens est variable et la base évolue sur deux niveaux, les objets ajoutés ou supprimés, et les liens.
Neo4J est peut-être le meilleur outil disponible pour une telle base de données, même s'il y a d'autres logiciels propriétaires ici ou là, tel que Pregel de Google.
Voir aussi...
ArangoDB, pour les indécis.
Parfait example d'outil NoSQL, il combine le modèle Document, Graphs et Clé/Valeur. L'article décrit les différents modèles ainsi que le modèle en table et le modèle relationnel classique pour comparaison.
Cassandra de Facebook. Dérivé de BigTable.
Les logiciels NoSQL
- Percolator de Google. Succède à BigTable pour l'index du moteur.
- MongoDB. Base de données orientée document. Utilisé par exemple par Sourceforge.
- ElasticSearch. Même s'il se présente comme un système de stockage de documents et de recherche dans ces documents, ES est en fait un SGBD et est assez similaire à MongoDB. Il est facile à déployer et utiliser et mis en pratique dans de grands sites, d'eCommerce notamment.
- Hadoop. Un framework implémentant MapReduce de Google, logiciel de traitement distribué de grandes quantités de données. Le project inclut HBase, qui est un gestionnaire de base de données utilisant le framework et conçu d'après BigTable.
- Aerospike. Basé sur le modèle clé-valeur comme aussi Redis, prétend être cent fois plus rapide que tout autre BD telle que MySQL. Utilise le langage Aerospike Query Language. (Licence Apache).