Il y a des mecanismes de transaction, oui, mais pas au meme sens que les RDBMS. Par exemple, pour BigTable de Google, tu peux definir un groupe d'objets. La transaction consiste a sauver l'ensemble du groupe, ou rien du tout. Mais il y a des subtilites, par exemple, toujours avec BigTable, ils ont une notion de transaction optimiste. Ce qui veut dire qu'ils vont essayer 5 fois de faire la transaction, avant de retourner en erreur, car le noeud peut etre trop occupe a faire une autre operation.

Et pour ce qui est des clefs etrangeres, si pour la plupart, il n'y a pas de CONTRAINTES referenciels, il n'empeche que beaucoup ont la notion de reference a un objet.

C'est un autre mode de pensee. Essayer d'appliquer les principe des RDBMS a ce type de DB est une heresie.

Benh euh non, des transactions t'es fou? Déjà que ça gère plus les concepts de clé étrangère, alors une transaction faut pas rire

bonjour,

petite question : il n'y a donc pas de mécanisme de transaction avec les DB NoSQL !?
l'intégrité des données est garantie par des mécanismes de réplication !?

en fait, je pense que c'est une affirmation, mais je pose quand même la question au cas ou.

Merci Gizmo

Même chose. Je ne prétend pas avoir tout compris, mais je serai content d'avoir appris quelque chose aujourd'hui

On avance, on avance

Au moins je m'endormirai moins con

Bon philfr a deja apporter un element de reponse, je continue donc ( y a de la redoncance, j'avais commence a ecrire avant d'aller manger):

Avec l'arrivee des sites "sociaux" de grande envergure, ainsi que l'emergence des systemes de could computing, on a vu apparaitre au grand jour une serie de base de donnes non relationnelles (bon, les mauvaises langues diront que c'etait deja le cas avec MySQL, et ils n'auront pas tout a fait tord )

Il y a principalement deux idees derrieres tout cela:

* "One-size-fits-all", c'est ce que pas mal de marketteux essayent encore de faire croire a beaucoup de gens, mais on sait que dans la pratique, ca ne marche pas des masses. Les gants a taille unique, on flotte un peu dedans quand on a de petites mains, et c'est pas super confort quand on est dote de grosses paluches.
C'est pareil pour le SQL et les DBs relationnels. Le concept est tres bien, fonctionne dans toute une serie de cas, mais dans d'autres y a mieux. Par exemple, creer et interroger une DB pour gerer les graphes d'amis, c'est pas ce qu'il y a de plus evident. Les requetes recursives ne font pas partie du standard, et leur support est plutot limite dans les RDBMS actuels.

* Les RDBMS montent bien en puissance verticale, mais tres mal en horizontale. Par vertical, on entends plus grosse machine, plus de ram, processeur plus puissant. Par horizontale, on entend replication, cluster de DB, services distribues. Il existe un theoreme, dit du "CAP" (Consistency, Availability, Partition), qui demontre qu'il est impossible d'obtenir les 3 caracteristiques en meme temps. Deux au maximum. Des lors, comme pour tout une serie de service, comme le partitionnement devient primordial, on accepte de se separer d'un des deux autres aspects. Et c'est sur ce point que les DB "NoSQL" sont generalement avantageues, car elles sont construite avec l'objectif d'etre facilement repliquee et synchronisee.


Bon, ensuite, on a surtout parler des HashTable ici, ce qui est le cas pour pas mal de DB NoSQL (la plus connue etant S3 d'Amazon), mais a celles-la, on rajoute d'autres types de DB:

* Les DBs orientees colonnes, comme BigTable de Google. Leur point fort est dans la recherche d'information a travers une colonne donnee, et non une ligne, comme pour les RDBMS
* Les DBs de documents, comme MongoDB ou couchDB, qui offrent une grande souplesse quand au format des donnees stockees (il n'y a pas de schema).
* Les DBs de graphe, comme Neo4J, qui sont particulierement adaptee a la recherche... dans les graphes

Sinon, pour les questions de persistence des donnees, ca reste un choix d'implementation. Le backup n'est pas pense de la meme maniere, vu que dans certains cas, ces DBs fonctionnent un peu comme un Raid 5, si un noeud claque, l'info existe dispersee dans d'autres noeuds.
De meme, pour le stockage, chaque serveur n'est pas oblige de se faire un fichier par cle, tout comme les DNS ne contiennent pas tous les sites du monde.

J'espere que c'est un peu plus clair

(et moi je suis déjà largué )

Ok, je commence à comprendre un peu le principe, merci.

Mais dans leur système de base ils garantissent pas la pérénité de l'info, si le node avec les infos sur la clé claque, tes données sont foutues, donc tu dois en plus répliquer le tout ou backuper...

Deuxième point, si pour le stockage chaque serveur se fait un fichier par clé, par exemple, y a bien un nombre maximum d'inode de toute façon sur la machine, donc on va se bloquer aussi à un omment, non?

Je délire?

Distributed hash tables

Le SQL/relationnel est impossible à distribuer massivement, et beaucoup de problèmes d'atomicité/intégrité/... peuvent être résolus côté client plutôt que côté serveur avec une telle soluion beaucoup plus légère.