-
Wielu różnych pisarzy. Zwłaszcza, gdy zapisujący mogą zostać podzieleni na segmenty z powodu rozłączeń w sieci, a później będą musieli ponownie zsynchronizować dane, które zostały zapisane po obu stronach bifurkacji. To łamie ACID i chociaż możesz rozwiązać problem za pomocą jawnej logiki biznesowej, jesteś teraz na terytorium NoSQL. Jest to bardzo powszechne w sytuacjach wojskowych, ale każdy system, w którym każdy jest płodnym pisarzem, będzie miał pewną blokadę zapisu w systemie ACID.
-
Schematy płynów. Zmiana schematu w tradycyjnej bazie danych jest kosztowną operacją, która często wymaga pewnego rodzaju przestoju serwera lub innych skomplikowanych procesów. W przypadku większości systemów NoSQL jest to trywialne. Więc jeśli masz dane z wielu różnych źródeł do scalenia i/lub masz sytuacje, w których możesz chcieć zacząć śledzić nowe informacje w późniejszym terminie, systemy NoSQL będą o wiele łatwiejsze w obsłudze. Dobrym przykładem, jaki mogę sobie wyobrazić, jest połączenie dwóch źródeł danych, aby można było je ze sobą sporządzić na wykresach.
-
Replikacja o niskiej przepustowości. Po złamaniu ACID możesz mieć czytniki i pisarzy na węzłach liści grafu sieci z częściowymi danymi, które nie wymagają pełnych replik bazy danych. Korzysta z tego produkt mojej własnej firmy, Wojskowe Stanowisko Dowództwa Przyszłości.
-
Interoperacyjność danych. Większość baz danych NoSQL pozwala na introspekcję danych bez wcześniejszego poznania schematu, co ułatwia nawiązywanie połączeń między różnymi systemami.
-
Masywne skalowanie. To jest ten, który jest najczęściej dyskutowany i najczęściej nadużywany przez zwolenników NoSQL. Jeśli to jedyny powód, dla którego wybierasz NoSQL, zacznij od MySQL i skaluj później.
