Je me permet de mettre un petit bémol à cette réponse.
Les problématiques de "gros volume" sont très rarement atteintes dans la réalité.
Pour justifier l'emploi d'une techno comme Hadoop, il faut au moins quelques TO de données, ce qui représente généralement plusieurs centaines de milliards de lignes en base de données.
Alors, effectivement, ça scale (dans certains cas), et ça fonctionne, donc on pourrait très bien mettre ça en place, comme on pourrait faire de la livraison de sushi avec un 35 tonnes, en se disant que si jamais on a énormément de clients, on pourra scaler.
Le problème, c'est que Hadoop est beaucoup plus compliqué à utiliser que des technos "classiques" comme SQL. Du coup, partir sur une techno de ce genre va considérablement augmenter le cout du projet (les experts Hadoop sont chers, et ils passent (parfois beaucoup) plus de temps à mettre en place des fonctionalités relativement simples.
Plus d'infos (en anglais, par un Data Scientist qui connait bien Hadoop):
www.chrisstucchio.com/blog/2013/hadoop_hatred....
Par ailleurs, des sites comme YouTube et Facebook utilisent toujours MySQL en stockage principal (il me semble). Une société pour laquelle je travaillais avec un volume d'environ 100 milliards de requêtes/mois utilisait MS SQL Server. Les techniques d'optimisation et de scaling sont souvent assez basiques (calcul de tables temporaires, cache...).
Un autre bémol, plus petit toute fois, concernant le NoSQL.
C'est une approche très intéressante, qui effectivement de stocker de grandes quantités de données efficacement, et qui offre une souplesse de part son absence de schéma (pour la plupart).
En revanche, le changement de paradigme est assez fort pour quelqu'un qui a l'habitude de tables SQL. Notamment sur l'absence de liaisons, le besoin de redondance, et les problématiques de maintenance que ça implique, notamment dans le cas de données absentes/altérées.
Donc je ne démarrerais pas un projet en NoSQL si je n'avais pas d'expérience de mise en place de cette techno. En fait, si, je l'ai fait... et j'en ai payé les conséquences : problèmes de performances liés à une utilisation inefficace des liaisons entre des collections, nombreuses migrations pour ajouter de la redondance et avoir accès à ce qu'on veut,...
D'ailleurs si la plupart des projets sont réalisables en NoSQL, certains se retrouvent vraiment bloqués par le principe. Voici un exemple très intéressant (en anglais):
www.sarahmei.com/blog/2013/11/11/why-you-should...
Encore plus grave, dans le sens "ne pas utiliser quelque chose qu'on ne connait pas", le cas de Flexcoin qui s'est fait hacker 896 bitcoins parce qu'ils ne maitrisaient pas l'aspect "sécurité" de MongoDB:
hackingdistributed.com/2014/04/06/another-one-b...
Et enfin, avoir une "couche" qui utilise une techno différente, ça veut dire une configuration supplémentaire du serveur, de la RAM, du CPU une logique différente à avoir en tête,.... alors que l'on a déjà une techno qui fait le boulot (SQL ou logs).