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