Scenariusze przypadków użycia NoSQL lub KIEDY używać NoSQL [zamknięte]

Przy całym szumie znalezienie wiarygodnych informacji o tym, kiedy tego użyć, wydaje się naprawdę trudne. Zadaję więc następujące pytania i przepraszam, jeśli są to naprawdę głupie pytania z góry:

1. Czy powinienem używać NoSQL do danych użytkownika? Np. Profile, nazwy użytkowników + hasła itp.
2. Czy powinienem używać NoSQL do ważnej zawartości? Np. Artykuły, posty na blogu, spis produktów itp.

Zakładam, że nie? Wydaje mi się, że NoSQL służy tylko do szybkiego dostępu do rzeczy, z których można utracić dane. Ale czytam również, że aplikacje NoSQL mają wbudowaną redundancję, aby nie tracić danych?

Również jeśli powyższe 2 przykłady są złe, czy możesz podać mi konkretne przypadki użycia biznesowego, w których użyłbym NoSQL? Widzę wiele ogólnych opisów, ale niewiele przykładów z prawdziwego świata. Jedyne, co mogę wymyślić, to wiadomości i analizy między użytkownikami.

Dzięki!

To naprawdę jest pytanie „to zależy”. Kilka ogólnych punktów:

• NoSQL jest zwykle dobry dla danych nieustrukturyzowanych / „bez schematów” - zwykle nie musisz jawnie definiować swojego schematu z góry i możesz po prostu zawierać nowe pola bez żadnej ceremonii
• NoSQL zazwyczaj faworyzuje schemat zdenormalizowany ze względu na brak obsługi JOIN w świecie RDBMS. Więc zwykle miałbyś spłaszczoną, zdormalizowaną reprezentację swoich danych.
• Korzystanie z NoSQL nie oznacza, że ​​możesz stracić dane. Różne bazy danych mają różne strategie. np. MongoDB - możesz w zasadzie wybrać poziom, na którym chcesz zmniejszyć wydajność a potencjalną utratę danych - najlepsza wydajność = większy zakres utraty danych.
• Często bardzo łatwo jest skalować rozwiązania NoSQL. Dodanie większej liczby węzłów w celu replikacji danych to jeden ze sposobów na a) zaoferowanie większej skalowalności i b) zaoferowanie większej ochrony przed utratą danych w przypadku awarii jednego węzła. Ale znowu, zależy od konfiguracji DB / NoSQL. NoSQL niekoniecznie oznacza „utratę danych”, tak jak wnioskujesz.
• IMHO, złożone / dynamiczne zapytania / raportowanie najlepiej obsługiwać z RDBMS. Często funkcjonalność zapytania dla bazy danych NoSQL jest ograniczona.
• To nie musi być 1 lub inny wybór. Z moich doświadczeń wynika, że ​​używam RDBMS w połączeniu z NoSQL do niektórych przypadków użycia.
• Bazy danych NoSQL często nie mają możliwości wykonywania operacji atomowych w wielu „tabelach”.

Naprawdę musisz przyjrzeć się i zrozumieć, jakie są różne typy sklepów NoSQL i jak one zapewniają skalowalność / bezpieczeństwo danych itp. Trudno jest udzielić kompleksowej odpowiedzi, ponieważ tak naprawdę wszystkie są różne i zajmują się różnymi sprawami .

Na przykład dla MongoDb sprawdź ich przypadki użycia, aby zobaczyć, co sugerują jako „dobrze dopasowane” i „mniej dobrze dopasowane” zastosowania MongoDb.

Myślę, że Nosql jest co najmniej „bardziej odpowiedni” w tych scenariuszach (mile widziane jest dodatkowe uzupełnienie)

1. Łatwo skalować w poziomie, dodając więcej węzłów.

2. Zapytanie o duży zestaw danych

   Wyobraź sobie mnóstwo tweetów publikowanych na Twitterze każdego dnia. W RDMS mogą istnieć tabele z milionami (lub miliardami?) Wierszy i nie chcesz wykonywać zapytań bezpośrednio na tych tabelach, nawet nie wspominając, że przez większość czasu połączenia tabel są również potrzebne w przypadku złożonych zapytań.

3. Wąskie gardło dysku I / O

   Jeśli strona internetowa musi wysyłać wyniki do różnych użytkowników w oparciu o informacje w czasie rzeczywistym użytkowników, prawdopodobnie mówimy o dziesiątkach lub setkach tysięcy żądań odczytu / zapisu SQL na sekundę. Wtedy dysk we / wy będzie poważnym wąskim gardłem.