-
Viele unterschiedliche Autoren. Insbesondere wenn die Schreiber aufgrund von Unterbrechungen im Netzwerk segmentiert werden können und später Daten, die auf beiden Seiten der Verzweigung geschrieben wurden, erneut synchronisieren müssen. Dies bricht ACID, und obwohl Sie das Problem mit expliziter Geschäftslogik lösen können, befinden Sie sich jetzt auf NoSQL-Territorium. Dies ist in militärischen Situationen sehr üblich, aber jedes System, in dem jeder ein produktiver Schreiber ist, wird eine Schreibkonfliktsperre auf einem ACID-System haben.
-
Fließschemata. Das Ändern eines Schemas in einer herkömmlichen Datenbank ist ein teurer Vorgang, der oft eine Art Serverausfallzeit oder andere komplizierte Prozesse erfordert. Bei den meisten NoSQL-Systemen ist es trivial. Wenn Sie also Daten aus vielen unterschiedlichen Quellen zusammenführen müssen und/oder Situationen haben, in denen Sie möglicherweise zu einem späteren Zeitpunkt mit der Verfolgung neuer Informationen beginnen möchten, sind NoSQL-Systeme viel einfacher zu handhaben. Das Zusammenführen von zwei Datenquellen, damit sie grafisch dargestellt werden können, ist ein gutes Beispiel, das mir einfällt.
-
Replikation mit geringer Bandbreite. Sobald Sie ACID gebrochen haben, können Sie Leser und Schreiber auf Blattknoten eines Netzwerkdiagramms mit Teildaten haben, die keine vollständigen Repliken der Datenbank benötigen. Das Produkt meiner eigenen Firma, der Command Post of the Future der Armee, verwendet dies.
-
Dateninteroperabilität. Die meisten NoSQL-Datenbanken ermöglichen es Ihnen, die Daten selbst zu prüfen, ohne das Schema im Voraus zu kennen, wodurch Verbindungen zwischen unterschiedlichen Systemen einfacher hergestellt werden können.
-
Massive Skalierung. Dies wird am häufigsten diskutiert und am häufigsten von NoSQL-Befürwortern missbraucht. Wenn dies der einzige Grund ist, warum Sie sich für NoSQL entscheiden, beginnen Sie stattdessen mit MySQL und skalieren Sie später.
