-
Många olika författare. Speciellt när skribenterna kan bli segmenterade på grund av avbrott i nätverket och senare kommer att behöva synkronisera om data som har skrivits till på båda sidor av bifurkationen. Detta bryter ACID, och även om du kan lösa problemet med explicit affärslogik, är du nu i NoSQL-territorium. Detta är mycket vanligt i militära situationer, men alla system där alla är en produktiv skribent kommer att ha något skrivstridslås på ett ACID-system.
-
Vätskescheman. Att ändra ett schema i en traditionell DB är en dyr operation som ofta kräver någon form av serverstopp eller andra komplicerade processer. Med de flesta NoSQL-system är det trivialt. Så om du har data från många olika källor att slå samman och/eller har situationer där du kanske vill börja spåra ny information vid ett senare tillfälle, kommer NoSQL-system att vara mycket lättare att hantera. Att slå samman två datakällor så att de kan kartläggas med varandra är ett bra exempel jag kan tänka mig.
-
Replikering med låg bandbredd. När du har brutit ACID kan du ha läsare och skribenter på lövnoder av en nätverksgraf med partiella data som inte behöver fullständiga repliker av databasen. Mitt eget företags produkt, Arméns Framtidens ledningspost använder detta.
-
Datakompatibilitet. De flesta NoSQL-databaser låter dig introspektera data utan att känna till schemat i förväg, vilket gör att anslutningar mellan olika system blir lättare.
-
Massiv skalning. Detta är den som oftast diskuteras och oftast missbrukas av NoSQL-förespråkare. Om detta är den enda anledningen till att du väljer NoSQL, börja med MySQL istället och skala senare.
