-
Beaucoup d'écrivains disparates. Surtout lorsque les écrivains peuvent être segmentés en raison de déconnexions dans le réseau et devront ensuite resynchroniser les données qui ont été écrites des deux côtés de la bifurcation. Cela casse ACID, et bien que vous puissiez résoudre le problème avec une logique métier explicite, vous êtes maintenant en territoire NoSQL. Ceci est très courant dans les situations militaires, mais tout système dans lequel tout le monde est un écrivain prolifique aura un verrou de contention en écriture sur un système ACID.
-
Schémas fluides. La modification d'un schéma dans une base de données traditionnelle est une opération coûteuse qui nécessite souvent une sorte d'indisponibilité du serveur ou d'autres processus compliqués. Avec la plupart des systèmes NoSQL, c'est trivial. Donc, si vous avez des données provenant de nombreuses sources disparates à fusionner et/ou si vous avez des situations où vous voudrez peut-être commencer à suivre de nouvelles informations à une date ultérieure, les systèmes NoSQL seront beaucoup plus faciles à gérer. La fusion de deux sources de données afin qu'elles puissent être représentées graphiquement l'une avec l'autre est un bon exemple auquel je peux penser.
-
Réplication à faible bande passante. Une fois que vous avez cassé ACID, vous pouvez avoir des lecteurs et des écrivains sur les nœuds feuilles d'un graphe de réseau avec des données partielles qui n'ont pas besoin de répliques complètes de la base de données. Le produit de ma propre entreprise, le poste de commandement du futur de l'armée, l'utilise.
-
Interopérabilité des données. La plupart des bases de données NoSQL vous permettent d'introspecter les données sans connaître le schéma à l'avance, ce qui facilite les connexions entre des systèmes disparates.
-
Mise à l'échelle massive. C'est celui qui est le plus souvent débattu et le plus souvent abusé par les partisans de NoSQL. Si c'est la seule raison pour laquelle vous choisissez NoSQL, commencez plutôt par MySQL et évoluez plus tard.
