Dans le cadre d'un travail d'environ 15-20 pages, je parle de la différence des ces 2 bases de données, et que les bases noSql sont plus intéressantes dans l'utilisation de big data. Mais la question que je me pose, c'est en quoi les bases noSql sont plus utilisées dans le cadre d'application big data, et pourquoi ?

merci d'avance !

Partager les informations sans souci, SI (Système d'information interne/externe entreprise), Acessibilité a tous les rangs sans risques etc

Big data = App réseaux sociaux par exemple

Je vais essayer de te donner une réponse complète. Peut-être elle est trop complète/avancée, mais peut-être ça te permettra de comprendre quelques détails

en base de données, il y a un théorème qui s'appelle le "CAP theorem". Il stipule qu'un gestionnaire de base de données (SGBD) (et distribué) ne peut avoir que 2 des 3 propriétés suivantes :

• Consistency : Chaque requête reçoit la dernière version du tuple lu
• Availability : Chaque requête effectuée à un noeud qui n'a pas crashé, doit retourner un résultat (pas forcément la dernière version de l'information)
• Partition-tolerance : Le système continue à fonctionner même si la communication entre différents partitions est interrompue. Après tu as 2 choix, soit tu attends que les partitions retrouvent la communication entre eux, mais en sacrifiant l'availability. Soit chaque partition se développe indépendamment et dans ce cas, tu sacrifie la consistence.

A la base, une base de données "normale" (donc non "nosql") respecte les propriétés ACID (atomicity, consistency, isolation, durability voir [1] pour plus d'info). Concrètement, cela veut dire que soit tu as les propriétés C+A soit C+P, mais tu privilégies la consistency dans les 2 cas.

Dans le cas du big data, tu as beaucoup de noeuds (on va dire des milliers) et énormément de données (ce qui explique le nombre de noeuds).

Imagine que tu aies une requête qui modifie une information puis après tu reçois un paquet de requêtes qui va utiliser cette information. Prenons un exemple Facebook, tu mets à jour ton statut et tout à coup, 1000 personnes consultent ton profil tout de suite après. Pour respecter la propriété C, tu devrais faire attendre les 1000 personnes en attendant que ta modification soit bien prise en compte, puis ensuite partager cette information. Il s'agit d'un seul exemple, mais des cas similaires à celui là il y en a des centaines par secondes. Donc d'un point de vue response-time, est-ce que tu penses que, si tu veux assurer que TOUTES les personnes voient immédiatement le changement de ton statut, ton temps de response-time sera bas ? C'est là qu'on s'est rendu compte que maintenir la consistency à ce niveau est extrêmement difficile, et qu'au final est-ce que c'est si important que tout le monde voit ton nouveau statut Facebook à la milliseconde près ?

Pourquoi c'est difficile à maintenant ? Je ne vais pas te donner la réponse, mais si ça t'intéresse, regarde le protocol 2-Phase-Commit, et tu remarqueras que pour assurer une strong consistency, un grand nombre de messages est nécessaire (~4*N où N est le nombre de machine). Ce qui fait qu'à grande échelle, ce n'est pas possible d'avoir des response-times correctes.

L'idée des bases de données NoSql, est de ne plus assurer la propriété C, mais d'assurer A+P. Le vrai nom de la propriété C est strong consistency. Dans les cas NoSql, on ne pourra garantir la garantir (on peut garantir la weak consistency par exemple, tu peux utiliser le protocol Paxos qui est fait pour ça et qui est similaire au 2-Phase-Commit).

Répondre à ta question, il faut se dire que si tu as un grand nombre de machine, beaucoup de données, tu aimerais un système scalable (-> avoir des temps de réponses correctes) pour traiter tes données, et malheureusement ceci n'est pas possible avec SGBD. Donc pour obtenir cette scalability, tu sacrifies qqch (le fameux no free lunch theorem, on n'a rien sans rien).

Pour résumer, les systèmes NoSQL ont été créé dans le but d'avoir une grande élasticité et scalabitiy, fault-tolerance et high availabability. En revanche, pour atteindre ces objectifs, on a dû sacrifier les modèles relationnels, les requêtes compliquées, diminuer la "strongness" de certaines propriétés telles que la consistency par exemple.

Pour finir, il est d'intéressant de noter l'existence du NewSQL, où l'on recherche à combiner les propriétés ACID avec les propriétés du NoSQL -> Garantir ACID de manière scalable. e.g. Google Spanner, VoltDB

Si quelqu'un veut me corriger ou compléter, il est là bienvenu

[1] https://en.wikipedia.org/wiki/ACID

J'ai oublié mais une dernière chose à ajouter, programmer des applications qui utilisent des transactions ACID est simple (et en principe infaillible). En revanche, programmer des applications qui utilisent la weak consistency par exemple, est beaucoup plus compliquée et susceptible d'avoir des erreurs.

Et si tu as des questions, n'hésite pas

Voici quelques liens wikipedias si tu veux en savoir plus (j'ai survolé, ils ont l'air complets)

https://en.wikipedia.org/wiki/NoSQL
https://en.wikipedia.org/wiki/NewSQL
https://en.wikipedia.org/wiki/Two-phase_commit_protocol
https://en.wikipedia.org//wiki/Paxos_(computer_science)
https://en.wikipedia.org/wiki/Concurrency_control
https://en.wikipedia.org/g/wiki/Distributed_transaction

merci beaucoup vive_cod4 d'avoir investi ton temps pour me faire ce petit pavé ! avec ton résumé, je me suis rendu compte que finalement j'avais mal compris le problème, mais maintenant c'est très clair ! je vais continuer de bosser, et je te redis sur le topic si j'ai encore quelques questions, mais ça devrait aller maintenant !

Pas de souci, content si ça a pu t'aider. Je sais pas à quel niveau d'études tu es, mais peut-être tu ne devrais pas parler de tout ce que j'ai dit.

Ce qu'il faut vraiment souligner, c'est que big data implique beaucoup de données, tu as besoin de beaucoup de machines pour traiter ça et que malheureusement si tu utilises une base de données ACID, pour garantir la consistency tu vas prendre un temps fou (4*N messages par requêtes) et que si une machine pète, tu es dans la merde.

D'un autre côté, les bases de données NoSQL, permettent d'avoir cette scalability (on parle d'horizontal scalability pour info, donc accroître le nombre de machines) mais en revanche, pour offrir ça, tu dois sacrifier un certain nombre de choses comme la strong consistency et des opérations complexes comme les joins.

Mentionner NewSQL est une bonne chose, pour dire qu'on essaie d'intégrer les 2 avantages en un seul système, mais ça a demandé une refonte complète d'une architecture de base de données.

Pour finir, ce qui est vrai dans beaucoup de domaines, on n'a rien sans rien et il faut savoir faire des concessions, tout définissant clairement les objectifs que l'on doit atteindre.

Au niveau métier, tes données vont être "mieux" répartie (cad que tu vas pas avoir une table sur un serveur A qui va faire une jointure sur une table du serveur B...)
Aussi, les bases NoSQL s'intègrent bien avec des framework de data processing de masse comme hadoop

A noter que jusqu'à un certain point (difficile à atteindre) tu peux t'en sortir avec du SQL

Merci vive_cod4 pour se resumer. C'est probablement la meilleure explication que j'ai lu ou entendu depuis un bon bout de temps.

Le 18 septembre 2016 à 16:37:34 godrik a écrit :
Merci vive_cod4 pour se resumer. C'est probablement la meilleure explication que j'ai lu ou entendu depuis un bon bout de temps.

Avec plaisir, merci pour ton commentaire. Content que ça soit compréhensible, c'est pas forcément évident de donner une réponse "complète" sans trop entrer dans les détails et les calculs.

Le 18 septembre 2016 à 19:38:55 vive_cod4 a écrit :

Le 18 septembre 2016 à 16:37:34 godrik a écrit :
Merci vive_cod4 pour se resumer. C'est probablement la meilleure explication que j'ai lu ou entendu depuis un bon bout de temps.

Avec plaisir, merci pour ton commentaire. Content que ça soit compréhensible, c'est pas forcément évident de donner une réponse "complète" sans trop entrer dans les détails et les calculs.

Merci pour cette explication. Pas forcément accessible aux néophytes mais très instructive pour ceux qui ne connaissent que les avantages et inconvénients sans savoir le pourquoi du comment (ce qui était mon cas).