Les bases de données SQL et NoSQL

SL NO SLQ board

Depuis 20 ans, le langage SQL et les bases de données relationnelles (SGBD) sont des standards dans le monde du stockage et de la manipulation de données. Les fonctionnalités des bases de données SQL ont permis de s’adapter aux besoins des entreprises (comme, par exemple, l’intégrité des données et l’implémentation de transactions dans les applications de gestion). Ses outils matures du côté développement en font un outil indispensable pour tout développeurs.

Notons aussi, en passant, que les trois bases de données les plus populaires restent des bases de données relationnelles (Oracle DB, MySQL, SQL Server) !


L’arrivée du NoSQL

L’accroissement exponentiel des données échangées et stockées par les entreprises ainsi que leur grande hétérogénéité (on parle aussi de données semi ou non-structurées) ont fait apparaitre les limites des SGBD relationnels dans un contexte nécessitant des environnements distribués ayant pour caractéristiques :

  • Le traitement intense de données (scaling des traitements) pour résister aux montées en charges importantes.
  • La répartition harmonieuse des données entre plusieurs machines (scaling de données) pour permettre le stockage de grands volumes.
  • L’assurance de la continuité de service en cas d’indisponibilité des datacenters

C’est ici qu’apparait une alternative avec le NoSQL pour Not ONLY SQL (et non pas Not SQL). Certaines de ces bases de données non relationnelle se veulent plus performantes car conçues pour permettre la distribution des données entre plusieurs serveurs (horizontal scaling) et tenir les montées en charge. Attention dans une implémentation fortement distribuée NoSQL, la gestion des contraintes ACID (Atomicity, Consistency, Isolation, Durability) peut aussi représenter une difficulté importante.

Il existe plusieurs types de base de données non relationnelle NoSQL offrant chacune une représentation différente des données :

les bases clef / valeur permettent de stocker des informations sous un couple clef/valeur. Chaque objet est identifié par une clef unique, seule façon de requêter. La simplicité de ce modèle avec seulement quatre opérations possibles Create – Read – Update – Delete (CRUD) permet des performances élevées en lecture et écriture ainsi qu’une grande scalabilité horizontale.Exemple : Redis, Voldemort.

les bases orientées document ont une représentation proche de celle clef/valeur, à ceci près que la valeur est représentée sous la forme d’un document, hiérarchisé (tout l’atout est ici), comme un objet XML ou JSON. Exemple : CouchDB, MongoDB, RavenDB.

les bases orientées colonnes stockent les données par colonnes. Elles sont souvent utilisées pour les traitements d’analyse de données et dans les traitements massifs (au travers l’utilisation de MapReduce notamment). Elles ont pour atout d’être plus évolutives et flexibles, et possède un nombre de colonnes dynamiques pour chaque ligne. Exemple : HBase (Open Source de BigTable de Google), Cassandra (fondation Apache), Simple DB (Amazon, FaceBook).

les bases orientées graphes permettent de pallier à des problèmes insolvables avec une base de données relationnelle. Elles représentent les données sous la forme d’un réseau composé de nœuds et de relations. Exemple : Neo4J, Hypergraph DB, Giraph.

Adieu le SQL ?

nosql-expertLe NoSQL ne se substituera au relationnel : l’un complète l’autre (au besoin) en fonction de la nature de votre projet et de l’existant : vos données, vos serveurs, vos environnements. A titre d’exemple, Tweeter tourne sur MySQL et Memcache. Stackoverflow utilise SQL Server 2008 et Redis !

Base de données relationnelle ou non, la réussite de votre projet dépendra surtout de votre réflexion sur la structure de votre application bien avant le choix final de solutions.

Pour conclure, on peut dire que tout système distribué est unique dans sa conception et répondra différemment aux trois lois fondamentales CAP (Coherence, Availabilty, Partition tolerance) en fonction de votre besoin. En effet, les SGBDR assurent les propriétés de consistance (Coherence), de diponibilité (Availability)  tandis que les SGBD « NoSqL » sont des systèmes soit de type AP (disponible et résistant au partitionnement), soit de type CP (cohérent et résistant au partitionnement).

triangle CAP

Pour le datascientist, le choix n’est pas neutre car ce n’est pas uniquement un choix de performance auquel il sera confronté, ainsi :

  • On ne traite pas d’information structurellement incomplète dans les SGBDR.
  • La structuration des données peut influencer les analyses statistiques et prédictives

N’hésitez pas à nous faire partager votre expérience sur les bases de données , SQL ou NoSQL (on est pas jaloux !), dans le cadre des datasciences.

Eva LAUDE, laboratoire BlueDsX

signature eva laude

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s