Cześć,
MongoDB to coraz popularniejsza baza. Jest coraz częściej stosowana jako alternatywa dla baz relacyjnych w środowisku mikrousług (nawet bez map-reduce).
Zalety:
Moje obawy:
Dlaczego warto używać MongoDB w połączeniu z Java zamiast baz relacyjnych, nawet jak się nie robi agregacji map-reduce? Bo można?
Mongo jest super, gdy pracujesz nad prototypem aplikacji i tniesz koszty na maksa.. Jeśli pomysł się przyjmie wówczas przepisujesz z NodeJS na normalny język i przechodzisz z MongoDB na normalną bazę. Innego i tym samym zdrowego zastosowania i wyjścia nie widzę ;-)
Sorry, ale jaki jest koszt zainstalowania postgreSQL? Że musisz go ciąć?
Nie musisz zastanawiać się nad modelami/migracjami. W małych aplikacjach 8 tabelek możesz zastąpić w 2 kolekcje. No i operowanie tym jest prostsze, bo zmieniasz w json ;-)
To nie ja podejmuje decyzje o użyciu technologii. Dlatego chcę zrozumieć zalety korzystania z alternatywy (a, że mogę się w pracy nauczyć i dostać za to pieniądze to fajnie)
Lepiej na tym skorzystasz jak zaczniesz od drugiej strony, czyli wady. W tym celu zaczep królika, bo często mongo hejtuje; Dobra rada: wcześniej poczytaj o wadach cassandry :-D
MongoDB prawdopodobnie stosowane jest właśnie na początku, gdy nie chce się komuś definiować struktury i transakcje są niepotrzebne.
Po wdrożeniu może się okazać, że jednak są potrzebne - wtedy polecam PostgreSQL.
Największą zaletą MongoDB z tego co czytam (nie mam praktyki) jest jego skalowalność na wiele komputerów - co jest trudniej osiągalne przy bazach relacyjnych.
Przy czym są lepsze bazy NoSQL w tej dziedzinie (ponoć Apache Cassandra).
Wywołania asynchroniczne bazy przy udziale PostgreSQL i nie tylko (znalezione teraz):
https://dzone.com/articles/asynchronous-non-blocking
https://github.com/alaisi/postgres-async-driver
https://github.com/mauricio/postgresql-async
https://jdbc.postgresql.org/documentation/91/listennotify.html
https://github.com/davidmoten/rxjava-jdbc#asynchronous-queries
Brak struktury to nie jest duża zaleta, bo można sobie nawet to zaimplementować w bazie relacyjnej, która wspiera XML lub (lepiej) JSON.
https://www.postgresql.org/docs/9.4/static/datatype-json.html
http://blog.sznapka.pl/using-xml-and-xpath-in-postgresql-database/
To jest właśnie ten case - na początku. Ogólnie jest to system czasu rzeczywistego, który ma przechowywać dane tylko podczas wykonywania tej operacji czasu rzeczywistego.
Ponieważ akurat mam taką jedną aplikację - gdzie JSONy trzymamy w Oraclu, mniej więcej wygląda to tak:
Ale działa :-)
Ja dorzucę swoje 3 grosze. Od paru lat korzystam z MongoDB i sobie chwalę. Jest to poboczna baza danych, do ściśle określonych celów.
W jednym projekcie potrzebowałem składować JSONa. Każdy JSON mógł mieć różną strukturę więc istotna była tutaj zaleta MongoDB w postaci braku określonego schematu. Konieczny był też szyki zapis ponieważ 90% zapytań to był zapis. Wydaje mi się że tego celu MongoDB pasował bardzo dobrze. I tak mamy już w kolekcji ~1 mld dokumentów i działa to fajnie. Nie jest to natomiast nic skomplikowanego: odczyt, zapis, jakieś filtrowanie.
A teraz wady:
Tak, wiem, że PostgreSQL ma od wersji 9.4 obsługę typu JSON. Ale jakbym musiał coś w tym JSON-ie uaktualnić, filtrować, wyszukać to bym się załamał ;)
Czytałem również benchmarki w których Postgres wygrywa z MongoDB pod względem szybkości zapisu. Nie wiem jednak czy dotyczyły one nowego silnika Wiretiger.
Chętnie poczytam jednak powody dla którego MongoDB jest tak hejtowany. Mówmy tutaj o wersji 3.x.
Chętnie również bym spróbował skorzystać z Cassandry, bo w benchmarkach bije wszystkie bazy NoSQL na głowę. Nie miałem jeszcze okazji, ale nie wiem czy nie jest to baza przystosowana na wiele większe potrzeby niż moje.