Najlepsza* baza danych ktora bedzie przechowywac dokumenty

Wiec baza danych nie zawiera miedzy soba relacji, znaczy sie zawiera, bo zawsze mozna znalezc jakas relacje, ale ogolnie w kazdej tabeli masz JSON ktory definiuje co tam jest a w tym JSONie moze byc wszystko

Pytanie, znacie jakies benchmarki / artukuly gdzie jest cos wyjanionego ktora baze danych najlepiej wybrac?
Moze macie jakies wlasne doswiadczenia / opinie na ten temat?

@Marcin.Miga jako ze uwazam Cie za eksperta odnosnie baz :)

Mysle o MongoDB, ale jakos mam wrazenie ze to kiepski pomysl. Slyszalem o CouchBase, Elassandra i wiele wiele innych... i sie gubie bo najlepiej jakby byl jakis benchmark do tego czy cos...

Sorry, nie zajmuję się przechowywaniem dokumentów. Ja to tylko relacyjne... Nie pomogę

Tu masz ranking bazujący na popularności:

• document: https://db-engines.com/en/ranking/document+store
• key-value: https://db-engines.com/en/ranking/key-value+store

Jedynym sensownym i szybkim rozwiązaniem dla przechowywania dokumentów w db jakie udało mi się osiągnąć było tak na prawdę trzymanie plików na dyskach, a w samej bazie była procedura która to wszystko obrabiala i wyluskiwala. Wszystkie inne próby przechowywania dokumentów w db kończyły się tym że baza nie wydalała.

Jeśli nie masz jakiś specyficznych wymagań, tylko zależy Ci na tym by była dokumentowa, to bym wybrał najpopularniejszą. Im baza danych przetestowana na większej liczbie użytkowników tym lepiej i można liczyć na większe wsparcie w razie czego. Alternatywnie jak nie potrzebujesz nie wiadomo jakie skalowalności to bym się zastanowił nad relacyjną która wspiera jsona jak np PostgreSQL.

Ja od jakiegoś czasu eksperymentuje z RavenDB i jestem zachwycony. Nie daj się zwieść tym że została napisana pod .Net ponieważ ma oficjalne wsparcie dla kilku języków jak i również nieoficjalne biblioteki. Baza jak wszystkie inne ma swoje wady i zalety oraz pewne "pułapki" bez których znajomości można się naciąć. Co ciekawe była to pierwsza w pełni transakcyjna baza NoSQL. Twórcy reklamują bazę jako super szybką, zarówno pod względem zapisów jak i czytania (1milion zapytań/sek, 150k zapisów/sek). Co ciekawe, ponieważ wszelkie zapytania muszą używać indeksów (których budowanie nie spowalnia zapisów, o tym za chwilę) to zapytania nie trwają dłużej ze zwiększająca się ilością danych w bazie.

Baza 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.

Ogólnie polecam, fajna sprawa.

https://ravendb.net/

fasadin napisał(a):

Wiec baza danych nie zawiera miedzy soba relacji, znaczy sie zawiera, bo zawsze mozna znalezc jakas relacje, ale ogolnie w kazdej tabeli masz JSON ktory definiuje co tam jest a w tym JSONie moze byc wszystko

Za mało informacji. Jak zagnieżdzone będą dokumenty? Jakie zapytania będą odpalane? Ile tych danych? Jaki ruch? Jakieś preferencje co do języka zapytań? Z jakim językiem ma to współpracować? Jak będą relacje to jak skomplikowane? Transakcje będą? Darmowa? Płatna?

Bazy dokumentów są OK do robienia prototypów, ten filmik wzorowo to pokazuje:

Natomiast w normalnych zastosowaniach bałbym się ich używać nawet jeśli pracowałbym z bazą dokumentową, która ma najwyższe noty. Jak masz bazę dokumentową to musisz liczyć się z tym, że wraz z kolejnym taskiem jakie robisz w ramach systemu może pojawić się potrzeba wykonania zapytania na które Twój model danych w ogóle nie jest przygotowany i wtedy jest słabo.

@nohtyp: Tylko że bazy NoSQL są szeroko używane, również w bardzo rozbudowanych systemach. Ok, możesz się bać. Tylko że inni się nie boją, i używają :)

Jak masz bazę dokumentową to musisz liczyć się z tym, że wraz z kolejnym taskiem jakie robisz w ramach systemu może pojawić się potrzeba wykonania zapytania na które Twój model danych w ogóle nie jest przygotowany i wtedy jest słabo.

Problem tej natury może wystąpić niezależnie od używanej technologii przechowywania danych czy architektury systemu. Dokładnie ten sam problem może wystąpić przy korzystaniu z bazy relacyjnej.

Good For:
Because of the structured nature of relational databases, they make sense
when the layout of the data is known in advance but how you plan to use
that data later may not be. Or, in other words, you pay the organizational
complexity up front to achieve query flexibility later. Many business problems
are aptly modeled this way, from orders to shipments and from inventory to
shopping carts. You may not know in advance how you’ll want to query the
data later—how many orders did we process in February?—but the data is
quite regular in nature, so enforcing that regularity is helpful.

**Not-So-Good For:
**When your data is highly variable or deeply hierarchical, relational databases
aren’t the best fit. Because you must specify a schema up front, data problems
that exhibit a high degree of record-to-record variation will be problematic.
Consider developing a database to describe all the creatures in nature. Creating a full list of all features to account for (hasHair, numLegs, laysEggs, and
so on) would be intractable. In such a case, you’d want a database that makes
less restrictions in advance on what you can put into it.

Źródło: https://www.amazon.com/Seven-Databases-Weeks-Modern-Movement/dp/1934356921

Aventus napisał(a):

@nohtyp: Tylko że bazy NoSQL są szeroko używane, również w bardzo rozbudowanych systemach. Ok, możesz się bać. Tylko że inni się nie boją, i używają :)

Nie mogę się powstrzymać i podzielę historią o bazie NoSQL, gdzie się nie bali i używają... Dostawca zewnętrzny wybrał Cassandrę jako jedną z baz w swoim rozwiązaniu (klasy 24/7). Klient skończył z produkcyjnym klastrem, gdzie węzły mają po 5 TB i to strasznie muli. DataStax rozkłada ręce i mówi, sorry, ale na jeden węzeł góra 2.5TB.

Jak teraz te dane zbalansować? ;) Pomysły były różne, wybrać dane z tabelki i pominąć "stare", drop tabeli & insert "aktualnych" wybranych. Wszystko fajnie, tylko jak zadziała drop tabeli na klastrze? Jak wybrać te dane? Na szczęście ustawili retencję na pół roku, więc pół roku cierpień i może na gwiazdkę okaże się, że jest szybciej. Żeby było śmieszniej to jeszcze do tej Cassandry zrobili mirroring na poziomie storage...

Jak pytałem "Czemu zgodziliście się na bazę NoSQL dla typowo relacyjnych danych?", "Bo jest skalowalna" hehe ;-) Zero wątpliwości czy krytycyzmu, po prostu developerzy wybrali nową technologię.

Częściej spotykam się z traktowaniem NoSQLi jako magicznego rozwiązania, gdzie nikt nie przejmuje się aspektami operacyjnymi i kosztami, czy złożonością utrzymania rozwiązań opartych o NoSQL. Kto by się tam martwił o konsekwencje :)

@yarel no tak, tylko to znów przykład złego podejścia do tematu a nie wina technologii samej w sobie. To tak jakbym ja zaczął nowy projekt, próbował zamodelować zagnieżdżone dane w jednej tabeli i mówił że SQL zawalił mi projekt bo relacje są płaskie. Ja nie twierdzę że NoSQL to złoty środek. Nic nim nie jest. Zdecydowanie nie zgadzam się jednak z obarczaniem winą technologii gdzie źródłem problemu jest czynnik ludzki. Brak przygotowania oraz zrozumienia z czym się pracuje i jak się to różni od tego z czym miał się do czynienia wcześniej.

@fasadin: bez wskazania wymagań ciężko coś doradzić. Nie wiem czy te dokumenty będą tylko do odczytu, czy też do aktualizacji, czy może chciałbyś aktualizować ich wybrane części, kompresować w locie, etc. Ale jest trochę opcji:

1. można takie dokumenty pchać do bazy relacyjnej + trzymać metadane w osobnych tabelkach
2. można dokumenty trzymać na systemie plików jak pisała @kate87 + trzymać w bazie metadane (Oracle ma dedykowany typ: BFILE, MSSQL ma FILESTREAMa)
3. można dokumenty trzymać gdziekolwiek + indeksować zewnętrznie (elasticsearch / solr)
4. można wrzucać do bazy NoSQL (mam ograniczoną wiedzę w tym obszarze i bez wymagań ciężko weryfikować czy funkcjonalność wybranej bazy wspiera wymagania)

@yarel: ale autorowi chodziło o dokumenty w sensie struktury danych a nie pliki (tekstowe, pdf itp). Co z tego że wrzucisz taki dokument (zserializowany obiekt) jako blob czy też string w bazie relacyjnej skoro nie będziesz mógł optymalnie wykonywać zapytań na danych?

Jeszcze tak w temacie pozwolę sobie dodać że ogólnie problem z bazami NoSQL jest taki że nie ma jakiegoś standardu bo technologie są nowe, każde podchodzą do sprawy po swojemu i poza jakimiś wspólnymi cechami należy je traktować jak zupełnie różne, wymagające zrozumienia narzędzia. W przypadku baz relacyjnych (SQL) sprawa jest dużo prostsza ponieważ istnieje pewien standard i poszczególne technologie różnią się w detalach. Mimo wszystko spierałbym się czy jest to wada baz NoSQL- jest to pewna cecha która może być ich mocna ale i słabą stroną, zależnie od kontekstu.

Już chyba gdzieś był ten link podawany, ale gazeta z UK - The Guardian przeszła z Mongo DB na Postgresa:
https://www.theguardian.com/info/2018/nov/30/bye-bye-mongo-hello-postgres

ile odpowiedzi :) Dzieki wszystkim, teraz doprecyzuje wszystkie szczegoly

• Jest to produkt enterprise. Jest juz postgres, ale nie wrabia na wyswietlaniu danych. Danych jest na prawde duzo.
• Skalowalne rozwiazanie to jest na prawde cos co szukam. Watpie zebysmy zmieniali baze danych w projekcie juz pozniej

@ralf dzieki za ranking ;)

@kate87, @yarel
Dokumenty chodzilo mi o bardziej cos innego, ze po prostu schemat danych bedzie trzymany w jsonie i trzeba szukac po jsonie. Dokumentow typu pdf czy doc nie trzymamy, ale nasz model danych jest nierelacyjny, tak wiec dzieki za sugestie, przepraszam ze nie sprecyzowalem lepiej :)

@neves
korzystamy z postgresa i jest za wolny. Jest to

@Aventus
wlasnie takich postow potrzebuje! :) wielka lapka w gore

@Maciej Cąderek

Za mało informacji. Jak zagnieżdzone będą dokumenty? Jakie zapytania będą odpalane? Ile tych danych? Jaki ruch? Jakieś preferencje co do języka zapytań? Z jakim językiem ma to współpracować? Jak będą relacje to jak skomplikowane? Transakcje będą? Darmowa? Płatna?

• dokument (a raczej json) teoretycznie moze sie nie konczyc, ma jakas forme, ale bardzo szybko sie zmienia. Moze inaczej
  Przewaznie jest to to json ktory ma wyglad A, ale na prawde nic nie stoi przeszkodzie by to A bylo nagle podzbiorem lub nadzbiorem czegos innego. Dane sa w pelni dynamiczne (i ich modele)
• Jeden z przykladow, mamy Job ktore ma wykonac cos (co moze byc zdefiniowane jako http request, czekanie iles H, wyslanie maila etc) Teraz chce sprawdzic czy Job zostal wykonany. On zostaje wykonany jezeli konkretny event uruchomil konkretne dane w bazie danych (maja zaleznosc taka, ze jezeli event sie pojawi w systemie to uruchamia dane Joby. Dosc mocno skomplikowane by napisac w paru zdaniach :D) Tak wiec musimy robic zapytania co event o wszystkie Joby jaki maja warunek by Job zostal spelniony np. Job ma "relacje" na innej tabeli w ktorej sa informacje o eventcie ktore skladaja sie z innych 3 tabel. Ale to wszystko trzeba wyszukac w danych by ta "relacje" zbudowac. Bardziej to dziala jak Dictionary na zasadzie key - value
• Bardzo duzo tych danych. W jednej tabeli mowimy o 5 mln rekordach dla jednej bazy w jednej tabeli, a baz jest kilkadziesiat
• 500 000 skomplikowanych requestow do przetworzenia. To jest w tym momencie jezeli ktos zrobi bulk upload to troche to wszystko jest powolne
• Preferencja jest klasyczny SQL, ale jezeli bedzie cos nowego to nie widze w tym zadnego problemu
• C#
• Relacje sa, ale sa skomplikowane, bo sa czasami powiazane na kolumnach, czasami na wartosciach co znajduje sie w jsonie, JSON moze wygladac za kazdym razem inaczej
• Fajnie by bylo jakby byly transakcje, jezeli nie to zapewne napiszemy cos wlasnego... Ale bardzo fajnie jakby byly transakcje juz wbudowane w framework
• Darmowa lepsza, ale jezeli platna (jak couchbase) to nie bedzie problemu

@Kristof
a my zapewne pojdziemy w druga strone ;) bo postgres jest slabym rozwiazanie jezeli chodzi o czytanie jsona i nakladania indeksow na to wszystko + ich mechanizm lockowania jest tak dziwny ze... ale to nie o tym

Dzieki jeszcze raz wszystkim za odpowiedzi

Mam nadzieje, ze troche rozjasnilem do czego bedzie uzywana i co potrzebuje i dlaczego.

macie repliki tylko do odczytu? sharding? ile GB ramu mają maszyny, a ile GB bazy? 5 mln rekordów per tabela to nie wydaje się dużo. W ogóle wszystkie metryki którymi jesteś w stanie się podzielić byłoby ciekawie zobaczyć, na czym postgress nie wyrabia.

fasadin napisał(a):

• Jest to produkt enterprise. Jest juz postgres, ale nie wrabia na wyswietlaniu danych. Danych jest na prawde duzo.

To można rozwiązać na kilka sposobów. Można np. zastosować CQRS na poziomie infrastruktury i mieć oddzielną bazę oraz serwis który będzie zapisywał modele widoku do bazy. No ale to wymagało by również publikowania eventów żeby to jakoś rozsądnie współpracowało. Jeśli chciałbyś jednak wykorzystać bazę NoSQL to jak już wspomniałem RavenDB buduje indeksy asynchronicznie, wszystkie pola używane w zapytaniach są indeksowane więc odczyt powinien być bardzo szybki.

• dokument (a raczej json) teoretycznie moze sie nie konczyc, ma jakas forme, ale bardzo szybko sie zmienia. Moze inaczej

Ogólnie to brzmi jak typowy wymóg dla document database. Oczywiście jakąkolwiek byś nie użył to i tak na pewnym etapie rozmiar dokumentu zacznie mieć znaczenie, i wypadałoby trzymać go w rozsądnych granicach. Jeśli za bardzo się rozrasta warto zastanowić się nad przemodelowaniem struktury, np. rozbiciem go na kilka dokumentów.

• 500 000 skomplikowanych requestow do przetworzenia. To jest w tym momencie jezeli ktos zrobi bulk upload to troche to wszystko jest powolne

W RavenDB Asynchroniczne indeksy z czasem sobie same nadgonią wszystko nie wpływając na prędkość zapisu. Kosztem tego jest oczywiście eventual consistency.

• C#

RavenDB jest w pewnym sensie "C# first".

• Relacje sa, ale sa skomplikowane, bo sa czasami powiazane na kolumnach, czasami na wartosciach co znajduje sie w jsonie, JSON moze wygladac za kazdym razem inaczej

W RavenDB dokumenty mają unikalne ID (w skali bazy a nie tabeli/kolekcji). W związku z tym jakiekolwiek zagnieżdżone pole może trzymać ID innego dokumentu (rekordu) i załadowane w indeksie.

• Fajnie by bylo jakby byly transakcje, jezeli nie to zapewne napiszemy cos wlasnego... Ale bardzo fajnie jakby byly transakcje juz wbudowane w framework

RavenDB jest transakcyjna.

• Darmowa lepsza, ale jezeli platna (jak couchbase) to nie bedzie problemu
  RavenDB ma wersję community którą można wykorzystywać komercyjnie. Ma również wersje płatne, w tym oczywiście profesjonalne wsparcie.

Swoją drogą nie chcę być źle odebrany jako ktoś siejący propagandę o RavenDB. Zaznaczam że jeszcze nie miałem okazji używać go produkcyjnie, po prostu od jakiegoś czasu używam hobbistycznie, trochę o tym czytam i podoba mi się. Jeśli bardziej zainteresujesz się temat warto sięgnąć po Inside RavenDB 4.0 napisaną przez CEO i de facto ojca tej bazy danych.

To można rozwiązać na kilka sposobów. Można np. zastosować CQRS na poziomie infrastruktury i mieć oddzielną bazę oraz serwis który będzie zapisywał modele widoku do bazy. No ale to wymagało by również publikowania eventów żeby to jakoś rozsądnie współpracowało

dokladnie tak jest. Mamy RabbitMQ pomiedzy, ale to sa troche szczegoly implemetacyjne, ktore nie powinny miec wplywu na decyzje (mam nadzieje :D)

@Aventus masz moze jakis benchmark ktory jest wiarygodny z uzyciem RavenDB?

Czyli wygląda na to, że te dokumenty JSONowe są głównie do odczytu (przychodzi, jest zapisywany w bazie, a później używany w trybie do odczytu do obsługi innych zdarzeń), często zmienia się struktura JSONa, ale zapisany content pozostaje bez zmian?

Jeśli tak, to nawet jak będziesz miał inną bazę, to ciężko ogarnąć jak miałaby poprawić wydajność w opisanym scenariuszu. np. grupowanie na bazie jakiejś wartość (trzeba by indeksować ścieżki albo przetwarzać wszystko, ale które indeksować jak chcemy szukać po dowolnej? ;) ) Baza musiałby przechowywać JSONy w specyficzny sposób (ścieżka w JSON + wartość) w osobnym "czymś".

Optymalizacja pod odczyty wymagałaby redukcji fizycznych I/O (buforowanie w RAM -> więcej RAM), partycjonowanie tabeli z dokumentami po jakimś kluczu odcinającym sporo danych, które nie muszą być przetwarzane.

Ewentualnie zupełnie inna architektura :)

Taki drobny przykład problemów jakie można rozwiązać w RavenDB. Potrzebowałem załadować dokument na podstawie zagnieżdżonych informacji. Konkretnie każdy Order posiada kolekcję OrderLines, z których każdy posiada unikalny ID. Jak optymalnie załadować dokument Order na podstawie ID OrderLine? Stworzyłem statyczny indeks:

 class Orders_ByOrderLine : AbstractIndexCreationTask<Order>
    {
        public class Result
        {
            public IEnumerable<string> OrderLineIds { get; set; }
        }

        public Orders_ByOrderLine()
        {
            Map = orders => orders.Select(order => new Result
            {
                OrderLineIds = Recurse(order, o => o.OrderLines).Select(ol => ol.Id)
            });
        }
    }

Zapytanie wykonuję tak:

var order = session.Query<Orders_ByOrderLine.Result, Orders_ByOrderLine>()
                    .Where(r => r.OrderLineIds.Any(i => i == id))
                    .ProjectInto<Order>()
                    .ToList()
                    .First();

Ponieważ używam indeksu to zapytanie nie jest wymagające wydajnościowo. Wszelkie informacje są już dostępne. RavenDB musi jedynie wykonać r.OrderLineIds.Any(i => i == id) na indeksie, a następnie po znalezieniu pasujących dokumentów załadować je, Wszelkie "ciężkie" obliczenia są wykonane asynchronicznie podczas budowania indeksu.

@Aventus:
O takie coś ci chodzi?

-- begin
/*
create temp table o
(
id int not null primary key,
opis varchar(10) not null
)
on commit drop
;

insert into o values(1, 'order 1'), (2, 'order two'), (3, 'order next'), (4, 'order last');

create temp table ol
(
id bigserial not null primary key,
order_id int not null references o(id),
opis varchar(10) not null
)
on commit drop;

insert into ol(order_id, opis) values
(1, 'poz1 o1'), (1, 'poz2 o1'),
(2, 'poz1 o2'), (2, 'poz2 o2'),(2, 'poz3 o2'), (1, 'poz4 o2'),
(3, 'poz1 o3');
*/

select * from (
select *, max((id=5)::int) over(partition by order_id) war from ol 
) x
where war=1

-- commit

podzapytanie tylko dlatego, że postgresql (na razie) nie obsługuje window-functions we WHERE

@Marcin.Miga: Oczywiście ja nie twierdzę że przykład który podałem jest niewykonalny w innych technologiach :D Poza tym zauważ że Ty podałeś model relacyjny, ja natomiast wskazałem jak w przypadku RavenDB to wygląda w strukturze dokumentu. Podałem umyślnie prosty przykład aby przedstawić zagadnienie. Jest to tylko wierzchołek góry i można wykonywać operacje na bardzo złożonych, zagnieżdżonych strukturach jeśli zajdzie taka potrzeba. Również zaznaczam że zapytanie jest wykonywane na indeksie- można w indeksie umieścić obliczone pola, np. złożyć FullName z Name i Surname (znów prosty przykład) i wykonać zapytanie na całym imieniu. A to wszystko przy indeksach które nie wpływają na prędkość zapisu danych.

Reasumując: Twój przykład jest dobry w kontekście relacyjnym. Nie odpowiada na pytanie co jeśli mam model nie-relacyjny, z zagnieżdżoną hierarchią w dokumencie.

@Aventus: Wez Ty mi powiedz, jak z RavenDB zrobic query na dynamic object?

    public class Foo
    {
        public Guid Id { set; get; }
        public dynamic ObjectJson { get; set; }
        public string MetadataJson { get; set; }
        public Guid FooId { get; set; }
        public Guid RunId { get; set; }
        public object ParentFooId { get; set; }
        public object ParentFooId { get; set; }

    }

Wiec ObjectJson moze miec na prawde wszystko

Chcialbym zbudowac query na podstawie FooId, RunId i konkretnych rzeczy ktore sa w ObjectJson. Poki co jest to string (zaimportowalem jako CSV i wrzucil jsona jako string) ale w przyszlosci bedzie to JSON wiec nested proprety powinno dzialac.

Nie moge doprowadzic klienta C#owego do tego by uruchomil to query

@fasadin: a co konkretnie się dzieje? Wydaje mi się że klient RavenDB powinien to spokojnie obsłużyć. Możesz utworzyć statyczny indeks używając właściwości z dynamicznego obiektu?

Ps: później wieczorem będę mógł to spróbować odtworzyć.

Ps2: teraz załapałem. Skoro jest to string to nie masz dostępu do jego właściwości, ponieważ nie jest złożonym obiektem (dynamicznym) z właściwościami a jedynie... stringiem. To nie jest problem RavenDB a natury silnego typowania w .Net. Jedna z opcji jaka przychodzi mi na myśl to zejście poziom niżej i stworzenie indeksu/napisanie query przy użyciu JS lub RQL, a więc ominięcie silnego typowania.

Jeszcze coś takiego możesz spróbować: https://stackoverflow.com/questions/3142495/deserialize-json-into-c-sharp-dynamic-object

Error CS1963 An expression tree may not contain a dynamic operation

Gdy probuje zrobic where jako dynamic, ale na to sa odpowiednie paczki/sztuczki z expression by sobie poradzic. Bo chodzi mi o drugi blad

jezeli wysylam do RavenDB dynamiczny obiekt to

Could not understand how to translate '[Dynamic]' to a RavenDB query.

musze miec mozliwosc robic query po JSONie ktory nie ma definicji (bo za kazdym razem moze wygladac inaczej)

to ze jest string i co to wiaze ze soba, to (mam nadzieje) zdaje sobie sprawe, ale w tym przypadku nie powinno miec to znaczenia. Bo szukam po calym stringu

Mam dokladnie ten problem
https://stackoverflow.com/questions/57409422/create-ravendb-index-based-on-dynamic-properties

@fasadin: ale kiedy to się dzieje? Kiedy budujesz statyczny indeks czy bezpośrednio w zapytaniu? Jeśli to drugie to sprobowales stworzyć indeks tak jak wczesniej pisałem? Było by łatwiej gdybyś pokazał cały kod.

juz go nie mam :D niestety nie pracuje na gitcie w tym projekcie. :ups: ale link ktory podalem jest w miare bliski co chce osiagnac a dokladnie to

public StepsIndex()
    {
        Map = steps => 
            from block in blocks
            from detection in blocks.Detections
            from step in detection.Steps

            select new Result
            {
                // extract property name (key), like 'domain_name'
                TargetKey = step.Object.target.GetType().GetProperties()[0].Name,

                // extract property value, like 'foobar.com'
                TargetValue = step.Object.target.GetType().GetProperty(s.Object.target.GetType().GetProperties()[0].Name).GetValue(s.Object.target, null)
            };
    }

tylko bez mapowania.

Gdy robie dynamiczny obiekt w where to wlasnie wtedy ravendb nie wie jak przetlumaczyc dynamic na swoj obiekt.
Znalazlem juz jakies rozwiazania do tego gdzies gleboko w google / stackoverflow bo rozwiazania z dokumentacji srednio dzialaly...

Jakos ten RavenDB do mnie nie przemawia.

wrzucam wlasnie mala tabele (400k rekordow) i bulk insert nie dziala (nie moge nawet stworzyc obiektu) wiec wrzucilem jako wszystko naraz (dobrze ze mam sporo ramu bo VS wzrosl do 7 GB :D) i chce wtedy sprawdzic robienie query jako, ze nie bedzie to juz string tylko json.

Potrzebuje zaimportowac 10x wieksza tabele i... jakos nie usmiecha mi sie poki co tego robic. od 15 minut ravendb jest zamulony.

Tak, wiem ze to co robie to glupie (wrzucam 400mb danych jedna transkacja). Ale wlasnie chce glupio testowac.

Poki co czuje ze obchodze problem a go nie rozwiazuje :(

TL;DR, ale "Danych jest naprawdę dużo" - to mi przypomina pewną lokalizację gdzie SQL był zasadniczo nie w modzie.
@fasadin: Może brakuje Wam kogoś od architektury bazy, np. DBA-ja?
Sharding na pewno jest dobrym pomysłem.
Można też podzielić bazę na mikroserwisy.
Odciążyć bazą key-value: https://medium.com/@amangoeliitb/improving-database-performance-with-redis-dbd38fdf3cb
Użyć typu jsonb zamiast json: https://www.compose.com/articles/faster-operations-with-the-jsonb-data-type-in-postgresql/
Cluster jakiś macie?

Co do tych indeksów to należy pamiętać że Client API jest jedynie warstwą abstrakcji i ma za zadanie pozwolić użytkownikom wykorzystać cechy C#, a więc silne typowanie itp. Koniec końców to musi zostać przetłumaczone do JS, a więc trzeba uważać czego się używa bo np. bardziej zaawansowane operacje (np. parsowanie DateTime) zwyczajnie nie będą działać po stronie serwera.

Co z propozycjami które podałem wcześniej? Np. parsowanie stringa json na dynamiczny obiekt. Ewentualnie zejście poziom niżej i użycie "surowych" indeksów napisanych w RQL.

O bulk insert się nie wypowiem bo nie używałem jeszcze.

Ps: ogólnie to mam wrażenie że próbujesz rozwiązać problem niewłaściwym metodami. Niestety ostatnio nie mam czasu żeby bardziej przysiąść, przeanalizować i pobawić się z tym w kodzie.