-
Molti scrittori disparati. Soprattutto quando i writer possono essere segmentati a causa di disconnessioni nella rete e in seguito dovranno risincronizzare i dati che sono stati scritti su entrambi i lati della biforcazione. Questo interrompe ACID e, sebbene tu possa risolvere il problema con una logica aziendale esplicita, ora sei nel territorio di NoSQL. Questo è molto comune nelle situazioni militari, ma qualsiasi sistema in cui tutti sono uno scrittore prolifico avrà un blocco della contesa di scrittura su un sistema ACID.
-
Schemi fluidi. La modifica di uno schema in un DB tradizionale è un'operazione costosa che spesso richiede una sorta di downtime del server o altri processi complicati. Con la maggior parte dei sistemi NoSQL è banale. Quindi, se hai dati da molte fonti disparate da unire e/o hai situazioni in cui potresti voler iniziare a tracciare nuove informazioni in un secondo momento, i sistemi NoSQL saranno molto più facili da gestire. L'unione di due origini dati in modo che possano essere tracciate l'una con l'altra è un buon esempio che mi viene in mente.
-
Replica a bassa larghezza di banda. Una volta che hai rotto ACID, puoi avere lettori e scrittori su nodi foglia di un grafo di rete con dati parziali che non necessitano di repliche complete del database. Il prodotto della mia azienda, il posto di comando dell'esercito del futuro, lo usa.
-
Interoperabilità dei dati. La maggior parte dei database NoSQL ti consente di introspezione dei dati senza conoscere lo schema in anticipo, facilitando le connessioni tra sistemi disparati.
-
Ridimensionamento massiccio. Questo è quello che è più spesso dibattuto e più spesso abusato dai sostenitori di NoSQL. Se questo è l'unico motivo per cui scegli NoSQL, inizia invece con MySQL e scala in un secondo momento.
