Limites des SGBDR pour le Big Data, NoSQL et NewSQL

Bon, comme je vous en avais par­lé, je suis le MOOC sur le Big Data et c’est pas de la tarte — pas cer­tain d’avoir le “diplôme” au final… Bref, il y avait une par­tie très intéres­sante sur les SGBD, leurs lim­ites, et les avan­tages des nou­velles approches comme NoSQL et NewSQL. Ca m’a don­né envie de vous en touch­er un mot 😉

je ne vais pas revenir sur le pourquoi du Big Data sur un blog par­lant prin­ci­pale­ment de jeux vidéo ? Dans les Jeux, on a de l’IA, et l’IA se nour­rit de plus en plus de Deep Learn­ing… et le Deep Learn­ing utilise mas­sive­ment le Big Data… Le rac­cour­ci est rapi­de, mais l’essen­tiel 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 (Sys­tème de Ges­tion de Base de Don­nées)  est un logi­ciel (en mode client/serveur pour la plu­part) per­me­t­tant de partager des infos et de les stock­er dans une base de données.

Une base de don­nées, c’est com­posé de plusieurs choses, mais essen­tielle­ment d’un ensem­ble de tables (comme les feuille de cal­culs sous excels). Ces tables ont des rela­tions entre-elles, comme la liste des clients et la liste des com­man­des. A chaque client, une ou plusieurs com­man­des. A chaque com­mande un client. C’est ce qu’on appelle une rela­tion, d’où le terme SGBDR, “R” pour relationnel.

code-sql-database-595x335

Si ça ne vous par­le pas, je vous con­seille cette vidéo:

Imag­i­nons que vous souhaitiez faire une com­mande en ligne: vous achetez tel objet, et au même moment il sort du stock. Et puis sou­vent, un tas d’autres choses. Chaque sous-action entraine des mod­i­fi­ca­tions sur plusieurs tables de la base: ces actions, nous appelons cela des requêtes: “ajoute telle ligne de com­mande, enreg­istre ou mod­i­fie tel client, retire tel pro­duit du stock”. Ces requêtes sont écrites dans un lan­gage dédié à cet effet qu’on appelle le SQL (Struc­tured Query Lan­guage). C’est un lan­gage assez sim­ple à maitris­er, mais qui peut s’avér­er assez dif­fi­cile à manip­uler quelques fois. Je me rap­pelle avoir bossé avec des gars qui n’é­taient pas des infor­mati­ciens et qui m’avaient créées des requêtes de plusieurs pages A4, inter­ro­geant de mul­ti­ples tables, avec des liaisons dans tous les sens !!! Bref, l’hor­reur à déboguer et des pertes de perf incroy­ables. Mais nous revien­drons sur cet aspect 😉

Donc, restons sur notre exem­ple: on lance les dif­férentes requêtes et hop… y‑a un prob­lème réseau ou je ne sais quoi, et seule­ment une par­tie des tables est mod­i­fiée. Galère ! On se retrou­ve avec des don­nées faussées… le client est créé, il a une com­mande, un pro­duit… ce dernier n’est pas sor­ti de stock… on va se retrou­ver avec des prob­lèmes d’in­ven­taire.. Ce n’est ni gérable, ni souhaitable. Pour cela, les SGBDR sup­por­t­ent le mécan­isme de trans­ac­tion:  on ouvre une trans­ac­tion, on lance une série de requête, on ferme la trans­ac­tion. Si la moin­dre chose inter­vient entre les deux, il y a une erreur (on peut relancer) et surtout, la base reste dans son état d’a­vant la transaction.

joemeal

Autre point, l’in­tégrité des don­nées. Une fois les rela­tions établies entre les tables, si on sup­prime un client par exem­ple, le sys­tème doit alert­er: atten­tion, ce client a des com­man­des, voulez-vous sup­primer ces com­man­des égale­ment ? Ben oui, car au final, ces com­man­des ne seraient plus exploitable car la rela­tion au client point­erait dans le vide. Ces mécan­ismes d’in­tégrité sont donc “pro­gram­més” au niveau des rela­tions: cer­taines choses peu­vent être automa­tisées (oui, on sup­prime en auto tout ce qui touche à ce client sup­primés) ou inter­dite, ou pas­sant par une confirmation.

Il faut aus­si que si plusieurs inter­nautes passent une com­mande, tout ne soit pas mélangé ! ça parait évi­dent, mais les accès con­cur­ren­tiels à 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 pro­duit que le B, au même moment. Le sys­tème va essay­er de mod­i­fi­er le stock au même moment, la même table, mais aus­si la même ligne (même pro­duit). Alors que fait-on ? Bon, en règle général, c’est un poil plus com­pliqué, mais il faut imag­in­er que les accès doivent être séquen­tiel. Si A arrive en pre­mier, il “vérouille” la ligne. B ne peut entr­er en mod­i­fi­ca­tion, donc il ren­tre dans une file d’at­tente. A ter­mine sa modif et dévérouille la ligne. B peut entr­er, vérouille à son tour… Bref, le mécan­isme habituel des accès con­cur­ren­tiels. Dans les faits, ce n’est pas A ou B qui choisi, mais le SGBDR qui impose.

Enfin, il faut aus­si garan­tir la sauve­g­arde des don­nées, voir sa jour­nal­i­sa­tion (sauver dif­férents états et pou­voir remon­ter le temps en cas de problème).

Ces dif­férents mécan­ismes qui garan­tis­sent le bon fonc­tionne de l’ensem­ble, on les désigne sous l’appellation ACID = Atom­ic­ité (trans­ac­tion), Cohérence (intégrité), Iso­la­tion (// des appels), Durabilité(sauvegarde).

acid

Une des richess­es des SGBD rela­tion­nels est leur capac­ité à gér­er des requêtes com­plex­es et à impos­er des con­traintes d’in­tégrité sur les don­nées. Les sys­tèmes rela­tion­nels clas­siques n’ont évidem­ment aucun mal à s’in­ter­fac­er avec une appli­ca­tion Web.

Si vous ne con­nais­sez pas le SQL et que vous souhaitez en savoir un peu plus, et si vous sup­port­ez les poly­tech­ni­ciens, il y a ces cours:

Inconvénients pour le Big Data

Mais il n’y a pas que des avan­tages à cette approche. Cela entraine aus­si des inconvénients:

  • inca­pac­ité àe gér­er de très grands vol­umes de don­nées à des débits extrêmes
  • cer­tains types de don­nées ne sont pas adaptés
  • Acid => Sur­couts en latence (ver­rous, jour­nal­i­sa­tion, etc.).

On ne peut pas avoir le beurre et l’ar­gent du beurre (quoi que… on ver­ra un peu plus loin).

Les SGBD rela­tion­nels mon­trent leur lim­ite avec de très hauts débits et des don­nées de types qui ne sont pas com­pat­i­bles avec les sché­mas rigides du mod­èle rela­tion­nel. Par con­tre, un SGBD rela­tion­nel n’a aucun mal à gér­er des don­nées de plusieurs cen­taines de giga-octets (voir plusieurs téra-octets), qui tien­nent sur un disque dur ou peu­vent être dis­tribués sur une petite col­lec­tion de serveurs.

En Big Data, non seule­ment on gère des quan­tités très impor­tantes de don­nées, mais des don­nées qui peu­vent aus­si avoir une taille très impor­tante, et sou­vent on veut un résul­tat très rapi­de­ment ! Les SGBDR tra­di­tion­nels atteignent ici leurs limites.

NoSQL

NoSQL (pronon­cez “Nosi­couall”) ou Not Only SQL. Cela reste un SGBD, mais cela ne respecte pas les garanties ACID.

sql-nosql

Les sys­tèmes NoSQL ont des incon­vénients majeurs par rap­port au SGBD clas­siques, en par­ti­c­uli­er les requêtes très lim­itées. En revanche, ils sont utiles quand les SGBD clas­siques atteignent leur lim­ite, en ter­mes de vol­umes de don­nées ou de débits.

Ces sys­tèmes sont basés sur des mod­èles de don­nées dif­férents (XML, graphe, triplets). Ils ont à part ça une archi­tec­ture rel­a­tive­ment sim­i­laire aux SGBD rela­tion­nels clas­siques, per­me­t­tent les requêtes com­plex­es mais, en par­ti­c­uli­er, ne passent pas à l’échelle de manière  transparente.

En fonc­tion des types de don­nées que l’on manip­ule, il y a plusieurs mod­èles pos­si­bles, tout comme les SGBD clas­siques. Voyons seule­ment ceux qui échap­pent à cela:

  • XML: XQuery per­met de tra­vailler à par­tir de don­nées XML.
  • Objet: stock d’in­for­ma­tions groupées sous formes de col­lec­tions d’ob­jets per­sis­tants. Exem­ple: Ver­sant
  • Graphe: pour les don­nées graphiques, réseaux soci­aux — Comme Neo4J
  • Triplets: triplet RDF (Sujet, prédi­cat, Objet) comme SPARQL

NoSQL-&-NewSQL

Il y a aus­si la façon de stock­er les don­nées qui est importante:

  • Sys­tèmes Clé-Valeur (get/put) — très sim­ple. Exem­ple: une table de hachage dis­tribuée. Ex: Ama­zon DynamoDB, Chord ou Mem­cacheDB - voir aus­si cette liste. Ces sys­tèmes sont des sys­tèmes clef-valeur, qui met­tent l’ac­cent sur les per­for­mances, en ayant à l’op­posé un mod­èle de don­nées et un mod­èle de requêtes extrême­ment simpliste.
  • Les sys­tème ori­en­tés doc­u­ments: mon­goDB. Per­me­t­tent de récupér­er facile­ment les doc­u­ments asso­ciés à une clef, de gér­er les dif­férentes ver­sions d’un doc­u­ment. Ils met­tent l’ac­cent sur la facil­ité d’in­té­gra­tion au sein d’un envi­ron­nement de  développe­ment. Le pas­sage à l’échelle n’est pas une force de ces systèmes.
  • Les sys­tèmes ori­en­tés colonnes: Ver­ti­ca, Apache Cas­san­dra, Google BigTable, Apache HBase. Ces sys­tèmes, ori­en­tés colonnes, four­nissent une organ­i­sa­tion des don­nées un peu plus com­plexe que les sys­tèmes clef-valeur, et met­tent l’ac­cent sur le pas­sage à l’échelle, avec des per­for­mances légère­ment moin­dres que les sys­tèmes clef-valeur, notam­ment en terme de latence. Ils ne per­me­t­tent pas d’in­ter­ro­ga­tion com­plexe des don­nées (par exem­ple, jointure).

Petite intro rapi­de qui résume bien ce que nous avons vu:

Si vous souhaitez en savoir plus sur l’ap­pari­tion du NoSQL, en ayant une présen­ta­tion de Mon­goDB, vous avez celle-ci:

NewSQL

Les sys­tèmes NewSQL pro­posent des archi­tec­tures dif­férentes des archi­tec­tures clas­siques, tout en sup­por­t­ant des lan­gages de requêtes complexes.

En gros: New-SQL: Requêtes  com­plex­es, ACID, mais perf supérieures — vous vous rap­pelez le beurre ? les mich­es de la laitière avec (là je m’égare).

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

Cer­tains vont fonc­tion­ner unique­ment en mémoire, sans pass­er par une mémoire de masse, et ce afin de gag­n­er en vitesse. D’autres vont être dépourvus de ver­rous (cou­teux en ressources).

Ex: Google Span­ner, CLus­trix, Volt­DB

Les sys­tèmes NewSQL ne visent pas à amélior­er les per­for­mances ou le pas­sage à l’échelle des sys­tèmes clef-valeur ou ori­en­tés colonnes, qui sont déjà très bons. Ils visent au con­traire à ajouter des fonc­tion­nal­ités de ges­tion de trans­ac­tion, ou d’en­richir le type de requêtes sup­port­ées. Il n’y a pas de dif­férence de com­plex­ité d’interface.

Conclusion

En gros, ce qu’il faut retenir, c’est que pour faire du Big Data, il faut sor­tir du sché­ma clas­sique, s’adapte non seule­ment à la struc­ture des don­nées manip­ulées, mais aus­si à la façon de les stock­er, ain­si que ce qu’on souhaite en tir­er au final.

Pour opti­miser les temps de traite­ment sur des bases de don­nées géantes, plusieurs solu­tions peu­vent entr­er en jeu :

  • Des bases de don­nées NoSQL (comme Mon­goDB, Cas­san­dra ou Redis) qui implé­mentent des sys­tèmes de stock­age con­sid­érés comme plus per­for­mants que le tra­di­tion­nel SQL pour l’analyse de don­nées en masse (ori­en­té clé/valeur, doc­u­ment, colonne ou graphe).
  • Des infra­struc­tures de serveurs pour dis­tribuer les traite­ments sur des dizaines, cen­taines, voire mil­liers de nœuds. C’est ce qu’on appelle le traite­ment mas­sive­ment par­al­lèle. Le frame­work Hadoop (rien à voir avec Hadopi n’ayez crainte) est sans doute le plus con­nu d’en­tre eux. Il com­bine le sys­tème de fichiers dis­tribué HDFS, la base NoSQL HBase et l’al­go­rithme MapRe­duce (rien que là dessus, y‑a matière faire un bon article).
  • Le stock­age des don­nées en mémoire (Memta­bles) per­met d’ac­célér­er les temps de traite­ment des requêtes.

Quels sont les impérat­ifs en terme de débits, d’in­tégrité, etc ? Après, plusieurs solu­tions exis­tent et on ne peut pas légitime­ment se dire: ah, ben je vais devenir expert en big data et je vais tra­vailler unique­ment avec tel base de don­nées… Non, claire­ment, cette approche qui fonc­tion­nait pour un SGBD clas­sique, n’est pas val­able dans le cadre du Big Data. Il faut savoir que ces dif­férentes bases exis­tent et les choisir en fonc­tion du besoin. Ça parait telle­ment évi­dent, mais on a sou­vent ten­dance à vouloir revenir vers ce qu’on con­nait, ce qu’on maitrise, et moi le premier.

 

2 commentaires sur “Limites des SGBDR pour le Big Data, NoSQL et NewSQL

Ajouter un commentaire

    1. NoSQL… newSQL… ce sont déjà des évo­lu­tions en vue de pren­dre en charge le Big Data — ça restera en con­stante évo­lu­tion et prob­a­ble­ment qu’on abouti­ra à un type par­ti­c­uli­er par util­i­sa­tion… je ne vois pas point­er de stan­dard dans ce domaine pour le moment (et d’ailleurs, fon­da­men­tale­ment je ne vois pas trop com­ment cela sera possible).

Laisser un commentaire

Fièrement propulsé par WordPress | Thème : Baskerville 2 par Anders Noren.

Retour en haut ↑

%d blogueurs aiment cette page :