Mam rację czy się mylę?
Wydaje mi się, że baza gdzie są wpisywane opinie na temat zakupionych przedmiotów, gdzie ktoś może kliknąć tylko ilość gwiazdek, ktoś może napisać recenzję, a ktoś inny tylko wybrać opcję dotyczącą tego, czy rozmiar zgodny z deklarowanym jest dobrym przypadkiem do użycia MongoDB a nie bazy SQL.
Jakiekolwiek agregacje mogą być nie do końca dokładne, to czy zadowolonych jest 80 czy 86 procent klientów to nie jest aż taka wielka różnica.
Ale może się mylę, może po prostu chcę mieć pretekst żeby tę bazę poćwiczyć?
Jakieś argumenty za jedną lub drugą opcją?
0
2
Ma sens aby recenzje były przypisane do konta (ponieważ użytkownik może chcieć pobrać wszystkie swoje recenzje lub chcemy podejrzeć wszystkie recenzje użytkownika X), który już pewnie jest zaimplementowany w RDMS wraz z całym majdanem (zamówienia, etc.) więc opinie/komentarze pasują raczej jako rozszerzenie istniejącej bazy, a nie coś do trzymania w osobnej. Inaczej trzeba by utrzymywać spójność między identyfikatorami userów w głównej bazie i identyfikatorami komentujących w drugiej, co wprowadza tylko niepotrzebne komplikacje.
6
Jeśli uprawiasz CV driven development, to oczywiście że dobre rozwiązanie, bierz i nie pytaj bo jeszcze cię ktoś zniechęci :)
Zadałbym pytanie, co mi da Mongo czego nie da baza SQL typu Postgres. Potrzebujesz super szybkości, shardingu, mapreduce itp? Może tak - wtedy jest to argument. Jak dla mnie to raczej gra niewarta świeczki. Co więcej, masz 99% szans że kiedyś pojawią się relacje (nawet niejawne, biznes to wymusi) i ficzer "wyświetl mi emaile wszystkich userów mających więcej niż X recenzji" okaże się babraniem w ręczne joiny (chyba że to już jest w mongo) i walką ze spójnością danych.
btw - "to czy zadowolonych jest 80 czy 86 procent klientów to nie jest aż taka wielka różnica" - to wymaganie przyszło z biznesu? Bardzo podejrzane, mam wrażenie że zwykle jest dokładnie odwrotnie - biznes raczej chce mieć dokładne analityki.
http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/ - nie wiem czy aktualne, ale nadal warte obczajenia
3
ktoś może kliknąć tylko ilość gwiazdek, ktoś może napisać recenzję, a ktoś inny tylko wybrać opcję dotyczącą tego, czy rozmiar zgodny z deklarowanym
Ale to możesz zrobić spokojnie w SQL, jak pisali przedmówcy - nie widzę tutaj żadnego zysku przy przejściu na Mongo.
W sensie - tworzysz tablę recenzje gdzie masz kolumny iloscGwiazdek (int), recenzja (text), czyRozmiarZgodny (bool) (plus oczywiście takie pola techniczne jak ID autora recenzji, ID recenzowanego produktu, może jakaś data wystawienia tp) . I po prostu - jak ktoś da jedynie 3 gwiazdki, to wstawiasz 3 do pierwszej kolumny, a na dwie pozostałe wrzucasz null.
Oczywiście - jeśli chcesz się nauczyć czegoś nowego to się chwali i kombinuj, ale tak w oderwaniu od nauki, nie widzę tutaj żadnego biznesowego/wydajnościowego/jakiegokolwiek innego plusa. To trochę jak tekst z Twojej sygnaturki - dzisiaj programiści uwielbiają przepisywać kod z jednego języka do drugiego, tylko po to by z projektem nadal stać w miejscu ale na nowej technologii :P
3
Z Mongo nie pracowałem i jestem skażony relacyjnymi bazami dlatego widzę:
Relacje do produktu, bo przecież recenzja produktu bez niego samego nie ma sensu.
Funkcje agregacji, bo przecież dobrze mieć minimalną, średnią, maksymalną są chyba wydajniejsze (a przynajmniej tak kiedyś czytałem) w bazach relacyjnych vs Mongo.
3
Czym mniej operacji aktualizacji rekordów/danych i ich usuwania, tym większy sens ma baza nierelacyjna, i trzymanie wszystkiego w dokumentach / obiektach.
Bazy nierelacyjne idealnie nadają się jako bazy tylko/głównie do odczytu.
Dlatego np. jest to świetny wbór dla serwisów typu Twitter, gdzie nie ma możliwości edycji wiadomości, jedynie usunięcia, a edytować można tylko swój profil.
Za to jest to gorszy wybór np. dla systemu magazynowego, gdzie co chwile coś do magazynu wchodzi albo wychodzi, albo do obsługi zamówień gdzie np. kilka razy zmienia się jego status (czyli mamy edycję danych).
Najgorzej kiedy dodawanie lub zmiana danych w typowej bazie relacyjnej wymaga transakcji i w jej ramach jest przeprowadzana w wielu relacjach na raz powiązanych między sobą kluczami obcymi. Przeniesienie tego do bazy nierelacyjnej jest możliwe ale często oznacza więcej problemów niż korzyści.
3
Jeśli masz architekturę mikroserwisową w której występuje usługa o nazwie Recenzje, która jest autonomiczna i nie wymaga innych usług do tego by zwrócić dane, do tego masz elastyczny schemat, duży ruch i prawie żadnych modyfikacji danych to baza NoSQL będzie dobrym wyborem.
Jeżeli masz archiekturę monolityczną i 90% ficzerów twojej aplikacji rozmawia z bazą relacyjną, to dodawanie kolejnej bazy danych żeby obsłużyć te 10% wymagań nie ma większego sensu. Współczesne bazy relacyjne dobrze sobie radzą z trzymaniem dynamicznych struktur typu JSON czy XML.
0
Z opisu problemu trochę wynika, że implementujesz jakiś read model dla produktów. Zauważ, że masz wiele domen na jednym ekranie - jakieś recenzje, opis, etc. Zakładam wiec, że ta baza nie będzie źródłem prawdy w systemie, wiec wymaganie spójności można obniżyć do eventual consistency.
Taki model rzeczywiście obsługuje Mongo i nadawałoby się do tego use case - nie trzeba robić N joinów, żeby wyświetlić dane z wielu kontekstów i jakieś listy typu recenzje - przy mikroserwisach w ogole nie byłoby to nawet możliwe, przy wielu modułach co najmniej niezalecane ze względów wydajnościowych (locki).
Jeżeli potrzebujesz funkcjonalności full text search, to rozważyłbym Elastica.
2
TomRZ napisał(a):
Za to jest to gorszy wybór np. dla systemu magazynowego, gdzie co chwile coś do magazynu wchodzi albo wychodzi, albo do obsługi zamówień gdzie np. kilka razy zmienia się jego status (czyli mamy edycję danych).
Status zamówienia nie musi być kolumną tabeli. Takie rzeczy można modelować inaczej.
Najgorzej kiedy dodawanie lub zmiana danych w typowej bazie relacyjnej wymaga transakcji i w jej ramach jest przeprowadzana w wielu relacjach na raz powiązanych między sobą kluczami obcymi. Przeniesienie tego do bazy nierelacyjnej jest możliwe ale często oznacza więcej problemów niż korzyści.
Problemy są tylko wówczas, gdy ktoś w bazie nierelacyjnej próbuje odzwierciedlać relacje.
Przy normalnym użytkowaniu nie ma problemów z aktualizacją powiązanych rekordów w jednej transakcji, bo nie ma powiązanych rekordów. Wszystkie dane są w jednym dokumencie, którego aktualizacja jest operacją atomową.
2
Problemy są tylko wówczas, gdy ktoś w bazie nierelacyjnej próbuje odzwierciedlać relacje.
Przy normalnym użytkowaniu nie ma problemów z aktualizacją powiązanych rekordów w jednej transakcji, bo nie ma powiązanych rekordów. Wszystkie dane są w jednym dokumencie, którego aktualizacja jest operacją atomową.
Ja wiem jak się to robi, ale to nie znaczy, że to ma zawsze sens. Czasem ma, czasem nie ma. Wśród tych projektów które ja robiłem, bazy relacyjne najczęściej były lepszym rozwiązaniem, niż denormalizacja wszystkiego w bazie danych.
Samo pisanie CRUDów / formularzy jest np. prostsze kiedy masz ustaloną strukturę tabeli, a nie dokument który może różnie wyglądać. I to już wskazuje na to, ze NoSQLe są lepsze do read only - nie trzeba robić do tego całego CRUD-a (wystarczy R często bez D i C), bo nie ma edycji danych.
I jesze jeden edit: ja u siebie w projektach NoSQL-e traktuje jako log różnych zdarzeń które chcę potem analizować to mogą być np. logowania adminów do panelu, jakie dane kiedy i gdzie zmieniali w bazie, logowanie błędów systemowych etc. To jest dobre bo tych zdarzeń jest dużo, a MongoDB ma np. mechanizmy kolekcji gdzie określamy Cap żeby za bardzo kolekcja nie urosła, albo możemy sobie zrobić sharding - do tego typu rzeczy jest to fajne.
0
TomRZ napisał(a):
Ja wiem jak się to robi, ale to nie znaczy, że to ma zawsze sens. Czasem ma, czasem nie ma.
Nie, próby modelowania relacyjnego w bazach nierelacyjnych nigdy nie mają sensu. Trzeba się wyzbyć manii mapowania obiektów na relacje, i zapisywania jednego obiektu do dziesiątek "tabel". W przeciwnym razie człowiek sobie bardzo mocno utrudni życie. (A potem zapewne będzie gadał, że bazy nierelacyjne są bez sensu, bo joiny są niewydajne.)
Samo pisanie CRUDów / formularzy jest np. prostsze kiedy masz ustaloną strukturę tabeli, a nie dokument który może różnie wyglądać.
Strukturę ustalają obiekty, a zapis do nierelacyjnej nie wymaga mapowania obiektów na relacje, więc jest to dużo prostsze.
1
somekind napisał(a):
TomRZ napisał(a):
Ja wiem jak się to robi, ale to nie znaczy, że to ma zawsze sens. Czasem ma, czasem nie ma.
Nie, próby modelowania relacyjnego w bazach nierelacyjnych nigdy nie mają sensu.
Nigdzie nie napisałem, żeby w taki sposób to robić.