Limites des SGBDR pour le Big Data, NoSQL et NewSQL

Bon, comme je vous en avais parlé, je suis le MOOC sur le Big Data et c’est pas de la tarte – pas certain d’avoir le “diplôme” au final… Bref, il y avait une partie très intéressante sur les SGBD, leurs limites, et les avantages des nouvelles approches comme NoSQL et NewSQL. Ca m’a donné envie de vous en toucher un mot 😉

je ne vais pas revenir sur le pourquoi du Big Data sur un blog parlant principalement de jeux vidéo ? Dans les Jeux, on a de l’IA, et l’IA se nourrit de plus en plus de Deep Learning… et le Deep Learning utilise massivement le Big Data… Le raccourci est rapide, mais l’essentiel est là. Pis d’abord, j’aime bien ça, et quand j’aime, je partage !

Qu’est-ce qu’un SGBDR et ACID ?

Bon, en gros un SGBD (Système de Gestion de Base de Données)  est un logiciel (en mode client/serveur pour la plupart) permettant de partager des infos et de les stocker dans une base de données.

Une base de données, c’est composé de plusieurs choses, mais essentiellement d’un ensemble de tables (comme les feuille de calculs sous excels). Ces tables ont des relations entre-elles, comme la liste des clients et la liste des commandes. A chaque client, une ou plusieurs commandes. A chaque commande un client. C’est ce qu’on appelle une relation, d’où le terme SGBDR, “R” pour relationnel.

code-sql-database-595x335

Si ça ne vous parle pas, je vous conseille cette vidéo:

https://www.youtube.com/watch?v=LM0TG0xVy5s

Imaginons que vous souhaitiez faire une commande en ligne: vous achetez tel objet, et au même moment il sort du stock. Et puis souvent, un tas d’autres choses. Chaque sous-action entraine des modifications sur plusieurs tables de la base: ces actions, nous appelons cela des requêtes: “ajoute telle ligne de commande, enregistre ou modifie tel client, retire tel produit du stock”. Ces requêtes sont écrites dans un langage dédié à cet effet qu’on appelle le SQL (Structured Query Language). C’est un langage assez simple à maitriser, mais qui peut s’avérer assez difficile à manipuler quelques fois. Je me rappelle avoir bossé avec des gars qui n’étaient pas des informaticiens et qui m’avaient créées des requêtes de plusieurs pages A4, interrogeant de multiples tables, avec des liaisons dans tous les sens !!! Bref, l’horreur à déboguer et des pertes de perf incroyables. Mais nous reviendrons sur cet aspect 😉

Donc, restons sur notre exemple: on lance les différentes requêtes et hop… y-a un problème réseau ou je ne sais quoi, et seulement une partie des tables est modifiée. Galère ! On se retrouve avec des données faussées… le client est créé, il a une commande, un produit… ce dernier n’est pas sorti de stock… on va se retrouver avec des problèmes d’inventaire.. Ce n’est ni gérable, ni souhaitable. Pour cela, les SGBDR supportent le mécanisme de transaction:  on ouvre une transaction, on lance une série de requête, on ferme la transaction. Si la moindre chose intervient entre les deux, il y a une erreur (on peut relancer) et surtout, la base reste dans son état d’avant la transaction.

joemeal

Autre point, l’intégrité des données. Une fois les relations établies entre les tables, si on supprime un client par exemple, le système doit alerter: attention, ce client a des commandes, voulez-vous supprimer ces commandes également ? Ben oui, car au final, ces commandes ne seraient plus exploitable car la relation au client pointerait dans le vide. Ces mécanismes d’intégrité sont donc “programmés” au niveau des relations: certaines choses peuvent être automatisées (oui, on supprime en auto tout ce qui touche à ce client supprimés) ou interdite, ou passant par une confirmation.

Il faut aussi que si plusieurs internautes passent une commande, tout ne soit pas mélangé ! ça parait évident, mais les accès concurrentiels à une base c’est quelque chose que le SGBDR doit gérér. Prenons le cas du stock. Si le client A achète le même produit que le B, au même moment. Le système va essayer de modifier le stock au même moment, la même table, mais aussi la même ligne (même produit). Alors que fait-on ? Bon, en règle général, c’est un poil plus compliqué, mais il faut imaginer que les accès doivent être séquentiel. Si A arrive en premier, il “vérouille” la ligne. B ne peut entrer en modification, donc il rentre dans une file d’attente. A termine sa modif et dévérouille la ligne. B peut entrer, vérouille à son tour… Bref, le mécanisme habituel des accès concurrentiels. Dans les faits, ce n’est pas A ou B qui choisi, mais le SGBDR qui impose.

Enfin, il faut aussi garantir la sauvegarde des données, voir sa journalisation (sauver différents états et pouvoir remonter le temps en cas de problème).

Ces différents mécanismes qui garantissent le bon fonctionne de l’ensemble, on les désigne sous l’appellation ACID = Atomicité (transaction), Cohérence (intégrité), Isolation (// des appels), Durabilité(sauvegarde).

acid

Une des richesses des SGBD relationnels est leur capacité à gérer des requêtes complexes et à imposer des contraintes d’intégrité sur les données. Les systèmes relationnels classiques n’ont évidemment aucun mal à s’interfacer avec une application Web.

Si vous ne connaissez pas le SQL et que vous souhaitez en savoir un peu plus, et si vous supportez les polytechniciens, il y a ces cours:

Inconvénients pour le Big Data

Mais il n’y a pas que des avantages à cette approche. Cela entraine aussi des inconvénients:

  • incapacité àe gérer de très grands volumes de données à des débits extrêmes
  • certains types de données ne sont pas adaptés
  • Acid => Surcouts en latence (verrous, journalisation, etc.).

On ne peut pas avoir le beurre et l’argent du beurre (quoi que… on verra un peu plus loin).

Les SGBD relationnels montrent leur limite avec de très hauts débits et des données de types qui ne sont pas compatibles avec les schémas rigides du modèle relationnel. Par contre, un SGBD relationnel n’a aucun mal à gérer des données de plusieurs centaines de giga-octets (voir plusieurs téra-octets), qui tiennent sur un disque dur ou peuvent être distribués sur une petite collection de serveurs.

En Big Data, non seulement on gère des quantités très importantes de données, mais des données qui peuvent aussi avoir une taille très importante, et souvent on veut un résultat très rapidement ! Les SGBDR traditionnels atteignent ici leurs limites.

NoSQL

NoSQL (prononcez “Nosicouall”) ou Not Only SQL. Cela reste un SGBD, mais cela ne respecte pas les garanties ACID.

sql-nosql

Les systèmes NoSQL ont des inconvénients majeurs par rapport au SGBD classiques, en particulier les requêtes très limitées. En revanche, ils sont utiles quand les SGBD classiques atteignent leur limite, en termes de volumes de données ou de débits.

Ces systèmes sont basés sur des modèles de données différents (XML, graphe, triplets). Ils ont à part ça une architecture relativement similaire aux SGBD relationnels classiques, permettent les requêtes complexes mais, en particulier, ne passent pas à l’échelle de manière  transparente.

En fonction des types de données que l’on manipule, il y a plusieurs modèles possibles, tout comme les SGBD classiques. Voyons seulement ceux qui échappent à cela:

  • XML: XQuery permet de travailler à partir de données XML.
  • Objet: stock d’informations groupées sous formes de collections d’objets persistants. Exemple: Versant
  • Graphe: pour les données graphiques, réseaux sociaux – Comme Neo4J
  • Triplets: triplet RDF (Sujet, prédicat, Objet) comme SPARQL

NoSQL-&-NewSQL

Il y a aussi la façon de stocker les données qui est importante:

  • Systèmes Clé-Valeur (get/put) – très simple. Exemple: une table de hachage distribuée. Ex: Amazon DynamoDB, Chord ou MemcacheDB – voir aussi cette liste. Ces systèmes sont des systèmes clef-valeur, qui mettent l’accent sur les performances, en ayant à l’opposé un modèle de données et un modèle de requêtes extrêmement simpliste.
  • Les système orientés documents: mongoDB. Permettent de récupérer facilement les documents associés à une clef, de gérer les différentes versions d’un document. Ils mettent l’accent sur la facilité d’intégration au sein d’un environnement de  développement. Le passage à l’échelle n’est pas une force de ces systèmes.
  • Les systèmes orientés colonnes: Vertica, Apache Cassandra, Google BigTable, Apache HBase. Ces systèmes, orientés colonnes, fournissent une organisation des données un peu plus complexe que les systèmes clef-valeur, et mettent l’accent sur le passage à l’échelle, avec des performances légèrement moindres que les systèmes clef-valeur, notamment en terme de latence. Ils ne permettent pas d’interrogation complexe des données (par exemple, jointure).

Petite intro rapide qui résume bien ce que nous avons vu:

Si vous souhaitez en savoir plus sur l’apparition du NoSQL, en ayant une présentation de MongoDB, vous avez celle-ci:
https://www.youtube.com/watch?v=z8bd0XTtJLg

NewSQL

Les systèmes NewSQL proposent des architectures différentes des architectures classiques, tout en supportant des langages de requêtes complexes.

En gros: New-SQL: Requêtes  complexes, ACID, mais perf supérieures – vous vous rappelez le beurre ? les miches de la laitière avec (là je m’égare).

On pourrait presque dire que SGDB classique+NoSQL = NewSQL, mais là on abuse…

Certains vont fonctionner uniquement en mémoire, sans passer par une mémoire de masse, et ce afin de gagner en vitesse. D’autres vont être dépourvus de verrous (couteux en ressources).

Ex: Google Spanner, CLustrix, VoltDB

Les systèmes NewSQL ne visent pas à améliorer les performances ou le passage à l’échelle des systèmes clef-valeur ou orientés colonnes, qui sont déjà très bons. Ils visent au contraire à ajouter des fonctionnalités de gestion de transaction, ou d’enrichir le type de requêtes supportées. Il n’y a pas de différence de complexité d’interface.

Conclusion

En gros, ce qu’il faut retenir, c’est que pour faire du Big Data, il faut sortir du schéma classique, s’adapte non seulement à la structure des données manipulées, mais aussi à la façon de les stocker, ainsi que ce qu’on souhaite en tirer au final.

Pour optimiser les temps de traitement sur des bases de données géantes, plusieurs solutions peuvent entrer en jeu :

  • Des bases de données NoSQL (comme MongoDB, Cassandra ou Redis) qui implémentent des systèmes de stockage considérés comme plus performants que le traditionnel SQL pour l’analyse de données en masse (orienté clé/valeur, document, colonne ou graphe).
  • Des infrastructures de serveurs pour distribuer les traitements sur des dizaines, centaines, voire milliers de nœuds. C’est ce qu’on appelle le traitement massivement parallèle. Le framework Hadoop (rien à voir avec Hadopi n’ayez crainte) est sans doute le plus connu d’entre eux. Il combine le système de fichiers distribué HDFS, la base NoSQL HBase et l’algorithme MapReduce (rien que là dessus, y-a matière faire un bon article).
  • Le stockage des données en mémoire (Memtables) permet d’accélérer les temps de traitement des requêtes.

Quels sont les impératifs en terme de débits, d’intégrité, etc ? Après, plusieurs solutions existent et on ne peut pas légitimement se dire: ah, ben je vais devenir expert en big data et je vais travailler uniquement avec tel base de données… Non, clairement, cette approche qui fonctionnait pour un SGBD classique, n’est pas valable dans le cadre du Big Data. Il faut savoir que ces différentes bases existent et les choisir en fonction du besoin. Ça parait tellement évident, mais on a souvent tendance à vouloir revenir vers ce qu’on connait, ce qu’on maitrise, et moi le premier.

 

Ces articles pourraient aussi vous intéresser …