Quand devons-nous passer au NoSQL ? vs RDBMS

Cet article écrit en 2008 par Michael Stonebraker discute les limites des bases de données classiques
http://cs-www.cs.yale.edu/homes/dna/papers/oltpperf-sigmod08.pdf

Cette thèse de 2014 synthétise toute la connaissance à ce jour:
http://www.leonardmeyer.com/wp-content/uploads/2014/06/avenirDuNoSQL.pdf

Extraits
"C’est une évidence de dire qu’il convient de choisir la bonne technologie en fonction du besoin. Il existe cependant certains critères déterminants pour basculer sur du NoSQL.

Taille : Le NoSQL est conçu pour supporter un nombre important d’opérations, de données, d’utilisateurs etc… Quand quelque chose est conçu de manière tellement massive que cela doit devenir distribué. Bien que tous les systèmes NoSQL ne soient pas conçus pour cette problématique, il est possible d’en trouver sans problème.

Performance en écriture : Intérêt principal du géant Google, Facebook (135 milliards de messages par mois), Twitter (7TB de données par jour). Des données qui augmentent chaque année. A 80MB/s cela prend une journée pour stocker 7TB, donc l’écriture doit être distribuée sur un cluster, ce qui implique du MapReduce1, réplication, tolérance aux pannes, consistance… Pour des performances en écriture encore plus puissante, il convient de se tourner vers les systèmes in-memory.

Performance en lecture clé-valeur : Certaines solutions NoSQL ne possèdent pas cet avantage mais comme il s’agit d’un point clé la plupart d’entre elles en sont dotées.

Type de données flexibles : Les solutions NoSQL supportent de nouveaux types de données et c’est une innovation majeure. Les objets complexes peuvent être mappés sans trop de problèmes avec la bonne solution.

Migration modèle de données : L’absence de modèle facilite grandement les migrations. En effet le modèle est en quelque sorte dynamique car il est créé par l’application au run-time.

ACID : Bien que ce ne soit pas le but premier du NoSQL, il existe des solutions permettant de conserver certains (voire tous) aspects des propriétés ACID. Se référer au théorème CAP plus bas et aux propriétés BASE.

Pas de SPOF2 : Toutes les solutions n’en sont pas dotées, mais on dénote la présence d’une configuration relativement simplifiée du load balancing et du cluster sizing. Cela permet d’obtenir une bonne disponibilité.

Simplicité de développement : L’accès aux données est simple. Bien que le modèle relationnel soit simple pour les utilisateurs finaux (les données sont restituées selon la structure de la base), il n’est pas très intuitif pour les développeurs. La réponse pour un problème de base de données ne peut pas toujours être celle d’embauche d’un DBA, le développeur devrait pouvoir être en mesure de le résoudre.

Parallel Computing : On peut également voir que le design pattern MapReduce est souvent embarqué dans les solutions NoSQL, ce qui améliore et facilite les calculs parallèles dans des architectures distribuées.