@nobody01: a więc tak- co do artykułu który podlinkowałeś to zdecydowanie należy brać na niego ogromną poprawkę z prostego powodu. Artykuł był napisany w roku 2016, więc autor używał wersji 3.5 lub starszej. Wersja 4.0 RavenDB wypuszczona w 2018 wprowadziła ogromne zmiany (co częściowo się nie spodobało społeczności bo zdecydowano się ubić wsteczną kompatybilność) takie jak całkowite przepisanie silnika bazy (Voron), poprawa stabilności, wydajności, oraz pójście na rękę społeczności i porzucenie pewnych narzuconych ograniczeń (mimo że podyktowanych dobrymi intencjami, to jednak narzuconych i powodujących często więcej szkody niż pożytku). Dziś jest wersja 5 z kolejnym szeregiem usprawnień (oraz ze wsteczną kompatybilnością), a prawie wszystko jest konfigurowalne- często do wyboru jest konfiguracja na poziomie serwera, poszczególnej bazy danych, połączenia klienta (document store) lub tylko sesji.
Poza tym konkretnym artykułem można również natknąć się na kilka innych, starych które również wymieniają pewne problemy. Część z nich jest już nieaktualna, część z nich brała się z nierozumienia pewnych kwestii lub brakiem ich akceptacji, a część może być nadal aktualna- ale nic nie jest idealne. Niektóre punkty z w/w artykułu w ogóle nie mają sensu, np:
Most importantly, if there’s something in Marten you don’t like, you can either do a pull request or at least raise an issue in GitHub where I’ll see it and we can get it fixed. OSS FTW!
RavenDB jest open source, i o ile się nie mylę zawsze był.
Nie chcę tutaj bawić się w porównywanie RavenDB ze wsparciem blobów JSON w PostgreSQL ponieważ tego drugiego zwyczajnie nie znam. To co z mojej perspektywy przemawia na plus RavenDB na pierwszy rzut oka to coś całkowicie subiektywnego- składnia. W PostgreSQL jest zwyczajnie brzydka. Tutaj przykład selecta który znalazłem na StackOverflow który wyciąga wartości konkretnej właściwości z zagnieżdżonej tablicy w dokumencie JSON (czyli np. select wszystkich nazw produktów z zamówienia):
select j.value->>'lable'
from your_table
join lateral json_array_elements(meta->'pages'->0->'fields') j
on true
W RQL (który już sam wymieniłeś więc zapewne dostrzegasz jego zalety) wygląda to tak (zakładamy dokument Order który zawiera array OrderItems)
from Orders o
select o.OrderItems[].ProductName
W dodatku używając jednego z oficjalnie (lub nie) wspieranych API można to zrobić używając standardowej biblioteki języka. Np. w C# przy pomocy LINQ
session.Query<Order>().Select(o => o.OrderItems.Select(i => i.ProductName));
Nie mówiąc już o tym że do czegoś takiego w RavenDB zapewne i tak użyje się indeksów. Indeksy z kolei to oddzielny temat bo chyba żadna inna baza nie robi tego tak jak RavenDB. A przynajmniej ja nigdy z taką się nie spotkałem ani o takiej nie słyszałem. Ogólnie rzecz biorąc indeksy w Raven to bardziej funkcje mapujące dokument (rekord) na wartości po których chcemy wyszukiwać. Dodatkowo Raven inaczej podchodzi do spójności danych jeśli chodzi o indeksy. Tutaj cytat z mojej wypowiedzi w innym wątku:
Baza [RavenDB] zapewnia właściwości ACID przy zapisach oraz BASE przy zapytaniach. Jest to umyślne działanie ponieważ indeksy (raz jeszcze powtarzam że zapytania MUSZĄ korzystać z indeksów) są budowane asynchronicznie, a więc nie wpływają na prędkość zapisu. Oznacza to jednak że wyniki zapytań mogą zawierać "stare" informacje, w związku z czym korzystając z RavenDB trzeba naprawdę rozumieć eventual consistency. Dodatkowo baza ma naprawdę potężny mechanizm MapReduce który pozwala budować zagregowane widoki i czytać je w locie- bez żadnego spadku wydajności.
Ale o indeksach radzę poczytać samemu żeby je dobrze zrozumieć. RavenDB ma bardzo przystępną dokumentację oraz mini-kursy na stronie RavenDB Demo.
Jeśli chodzi o Twoje wymagania to ja widzę dwa- nauka NoSQL oraz baza pod DDD/agregaty.
W tym pierwszym przypadku zdecydowanie odradzam półśrodki takie jak bloby JSON w PostgreSQL. NoSQL (a konkretnie bazy dokumentowe) to nie tylko możliwość zapisywania poszczególnych obiektów jako całość (dokument), ale również cały ekosystem z tym związany. Każda baza NoSQL ma innych tenże ekosystem, ale i tak warto wybrać właśnie baza która jest od zera zbudowana w celach wspierania NoSQL/operacji na dokumentach. Moim zdaniem w to należy celować jeśli chce się uczyć NoSQL. W przeciwnym razie to jak uczyć się robić pizzę robiąc zapiekanki, lub uczyć się od zera czystego programowania funkcyjnego w języku który pozwala na miszmasz paradygmatów.
W drugim przypadku to podstawową sprawą jest możliwość zapisywania agregatów jako całość, ponieważ muszą one tworzyć transakcyjną spójność. Tutaj każda baza pozwalająca na wrzucenie obiektu JSON się sprawdzi, w tym również PostgreSQL. Rzecz w tym że do tego dochodzą dodatkowe kwestie takie jak tworzenie projekcji czy subskrypcje. Tutaj znów sięgnął bym po RavenDB. Tym bardziej z perspektywy aplikacji .Net, ponieważ RavenDB był pisany jako .Net-first.
RavenDB ma ograniczenia w darmowej licencji o ile wiem
Tym bym się w ogóle nie przejmował. Do nauki masz licencję Developer która nie ma żadnych ograniczeń. a do drobniejszych zastosowań produkcyjnych masz licencję Community.
@KamilAdam
Jakie ma on zalety w stosunku do klasycznego Mongo? Bo mongo chyba stabilniejsze i bardziej znane?
Od razu zaznaczam że Mongo tylko liznąłem, więc pewne zalety Ravena które wymienię być może Mongo również ma. Pierwsze co na myśl przychodzi to natywne wsparcie unit of work, transakcje na poziomie klastra (cluster-wide transactions), brak kontrowersji z transakcjami jak w przypadku Mongo, Raven to w domyśle baza rozproszona a więc nawet jak tworzysz jeden node to jest on częścią klastra do którego możesz dodać więcej nodes, wszystkie natywne bajery takie jak wsparcie dla LINQ w .Net, w/w RQL, świetny portal do zarządzania serwerem (RavenDB Studio), w/w całkowicie inne podejście do indeksów oraz zwyczajna przyjemność i łatwość użytkowania. Trzeba po prostu poużywać kilka dni żeby zrozumieć co mam przez to na myśli.
Podsumowując
Sam przygodę z NoSQL i RavenDB zacząłem kilka lat temu w zasadzie od zera. Od tamtego czasu miałem styczność z innymi bazami- głównie Azure Tables i Cosmos DB z natywnym SQL API (nie mylić z relacyjnym SQL!). Raven używam po dziś dzień. Mam jedną drobną aplikację produkcyjną postawioną właśnie na RavenDB (wcześniej postawiona na SQL Server z Entity Framework) oraz aktualnie pracuję nad projektem komercyjnym który również będzie używał RavenDB (na razie produkcyjnie oparty o licencję Community). Napisałem również bibliotekę/framework do event sourcingu korzystając z RavenDB jako event store. Z baz z których korzystałem (wliczając w to bazy SQL) z RavenDB pracuje mi się najprzyjemniej i uważam że wiele z decyzji zaimplementowanych w tej bezie danych jest bardzo dobra. Trzeba po prostu być otwartym na porzucenie strefy komfortu i nauczenia się czegoś nowego. Jeśli chodzi o NoSQL ogólnie to trzeba przede wszystkim przerzucić się na inny tok myślowy, inne podejście do kwestii modelowania danych. Tutaj fajna prezentacja na ten temat, dostarczona przez człowieka stojącego za (a jakże ;)) RavenDB.
Z góry przepraszam za ścianę tekstu i błędy ale nie chce mi się wszystkiego poprawiać...