-
Много различни писатели. Особено когато писателите могат да бъдат сегментирани поради прекъсване на връзката в мрежата и по-късно ще трябва да синхронизират отново данните, които са били записани от двете страни на разклонението. Това нарушава ACID и докато можете да разрешите проблема с изрична бизнес логика, сега сте на територията на NoSQL. Това е много често срещано във военни ситуации, но всяка система, в която всеки е плодовит писател, ще има някакво заключване на конкуренция за запис в ACID система.
-
Течни схеми. Промяната на схема в традиционна база данни е скъпа операция, която често изисква някакъв вид прекъсване на сървъра или други сложни процеси. При повечето NoSQL системи това е тривиално. Така че, ако имате данни от много различни източници за обединяване и/или имате ситуации, в които може да искате да започнете да проследявате нова информация на по-късна дата, NoSQL системите ще бъдат много по-лесни за справяне. Обединяването на два източника на данни, така че да могат да бъдат начертани един с друг, е добър пример, за който се сещам.
-
Репликация с ниска честотна лента. След като разбиете ACID, можете да имате четци и записвачи на листови възли на мрежова графика с частични данни, които не се нуждаят от пълни реплики на базата данни. Продуктът на моята собствена компания, командният пункт на бъдещето на армията, използва това.
-
Оперативна съвместимост на данните. Повечето NoSQL бази данни ви позволяват да изследвате данните, без да знаете предварително схемата, което позволява по-лесно свързване между различни системи.
-
Масивно мащабиране. Това е най-често обсъжданият и най-често злоупотребяван от привържениците на NoSQL. Ако това е единствената причина да изберете NoSQL, вместо това започнете с MySQL и мащабирайте по-късно.
