MongoDB jako baza dla agregatów

Cześć

Tak sobie myślę, że warto byłoby rozpocząć pewien projekt według paradygmatu DDD. Zakładam, że będę miał jakieś agregaty i tak sobie myślałem jak to przechowywać w bazie danych. Doszedłem do wniosku, że przechowywanie obiektów domenowych w relacyjnej bazie danych może okazać się nieco uciążliwe (przy założeniu, że nie próbujemy z relacyjnej bazy danych zrobić bazę dokumentową). Po wstępnej analizie doszedłem do wniosku, że implementacje repozytoriów lepiej byłoby oprzeć o zapisywanie dokumentów w formie JSON (wstępnie wydaje się to być bardziej wygodne).

Nie mam doświadczenia z bazami NoSQL, ale jak mowa o bazie przechowującej JSON-y to od razu mam pewne skojarzenia z MongoDB. Jednak spotkałem się z krytyką tej bazy i zastanawiam się na ile hejt na MongoDB jest uzasadniony. Mam więc następujące pytania:

1. Czy baza MongoDB jest naprawdę taka zła czy może jest to efekt jej popularności? Wiadomo, że więcej będzie krytycznych uwag w stosunku do czegoś co jest popularne niż w stosunku do czegoś czego nikt nie używa.
2. Czy narzekania na MongoDB są spowodowane tym, że w starych wersjach były jakieś problemy, które zostały rozwiązane w nowszych wersjach?
3. Czy uważacie, że osoby krytykujące MongoDB to osoby, które źle używają tą bazę danych? Na przykład modelują domenę biznesową myśląc (ze względu na przyzwyczajenia) w kategoriach relacyjnych baz danych?
4. Czy zapis stanu obiektów domenowych (podejście DDD) to właściwy sposób wykorzystania bazy MongoDB?

Poza tym zastanawiam się dość mocno nad wykorzystaniem PostgreSQL jako bazy danych do przechowywania dokumentów (JSON). Z jednej strony wydaje mi się to dziwny pomysł ponieważ PostgreSQL ze swojej natury jest raczej bazą zorientowaną na relacje, ale z drugiej strony to nie chciałbym się zamykać na niestandardowe rozwiązania o ile działają dobrze.

Pytanie, czego się chcesz nauczyć? Jak chcesz iść Mongo to sie pobaw Mongo. Jak baza ma być tylko workiem na dane to użyj tego, co umiesz. Z moich doświadczeń z to Mongo ma racje bytu jak rzeczywiście będziesz miał duże ilości danych. Nie wiem jak jest teraz, ale kiedyś był problem podpięcia się jakąś sensowną analityką do takie bazy - bo nie wspierały połączeń do Mongo.
Postgres tez sobie całkiem dobrze radzi z JOSNami, ale rzeczywiście jak mają tam być tylko JSONy to takie mało sensowne, no chyba, że znasz. Bo może sie ze zamiast robić projket, bedziesz stroił konfigurował i ogarniał bazę przez kolejne pół roku.

Też myślę, że za dużo rzeczy chcesz naraz ogarnąć.
Chcesz się nauczyć podstaw paradygmatu DDD czy postawić produkcyjną apkę używając DDD?
Bo podstaw paradygmatu możesz się nauczyć nawet nie mając żadnej bazy danych w projekcie.

Bo tak wychodzi na to, że chcesz zrobić ala produkcyjną (tj. taką jak na produkcji, nawet jeśli to do szuflady) apkę w paradygmacie, którego nie znasz używając bazy danych, której nie znasz.

LukeJL napisał(a):

Chcesz się nauczyć podstaw paradygmatu DDD czy postawić produkcyjną apkę używając DDD?

Prawdę mówiąc to jedno i drugie z tym, że system który chce stworzyć nie jest ani jakiś duży ani krytyczny. Taki dodatkowy projekt. Z tego powodu uważam, że jest to dobra okazja do poszerzenia horyzontów czy wypróbowania nowych narzędzi. Jeżeli chodzi o rozwój to jestem bardziej ukierunkowany na DDD niż na MongoDB, ale prawdę mówiąc to chętnie tam wcisnę szereg różnych bibliotek / technologii / narzędzi, których nie znam (po to żeby poznać).

Bo podstaw paradygmatu możesz się nauczyć nawet nie mając żadnej bazy danych w projekcie.

Prawdę mówiąc to jestem przeciwnikiem takiego podejścia do sprawy. W realnym świecie trwałe przechowywanie danych w bazach danych jest standardem, więc jak się rozwijać to lepiej w sposób, który jak najbardziej przypomina realne środowisko. Takie jest moje zdanie.

Bo tak wychodzi na to, że chcesz zrobić ala produkcyjną (tj. taką jak na produkcji, nawet jeśli to do szuflady) apkę w paradygmacie, którego nie znasz używając bazy danych, której nie znasz.

Ja tam nie widzę w tym nic złego. Wręcz przeciwnie. Uważam, że takie podejście jest prorozwojowe.

Zarówno w modelu relacyjnym jaki dokumentowym ogarniesz agregaty.

W modelu relacyjnym po prostu musisz potem złożyć agregat z kilku tabelek i zapewnić że usunięcie korzenia agregatu będzie caskadowało też na usunięcie wszystkich relacji z silną asocjacją.

W modelu dokumentowym jest to oczywiście prościej - dokument to Twój agregat.

Natomiast pytania są inne - do czego potrzebuje bazy danych.

Mongo bardzo dobrze się skaluje via sharding i wydajnie może zapewnić Ci atomiczne operacje w zakresie 1 dokumentu. Od jakiegoś czasu niby wspiera transakcje obejmujące wiele dokumentów ale jest to raczej special case, który jakbyś zaczął korzystać za ochoczo to zabije Ci wydajność. poza tym Mongo jest bardzo specyficzny w utrzymaniu. W standardowej konfiguracji jak masz mniej niż 3 serwery to padnięcie jednego może spowodować utratę ostatnich zapisów.

Postgres natomiast mocno trzyma się ACID - jeżeli dostałeś potwierdzenie transakcji to wiesz że jest na dysku (a nie tylko w RAM). Setup z 1 serwerem jest prosty i bardzo stabilny. Transakcje mogą obejmować wiele wierszy z różnych tabel - choć i tutaj dobrą praktyką jest nie nadużywanie tego. Zbyt szeroko idąca transakcja może Ci alockować sporo danych i wpaść w deadlock'i