Dokumentové databáze a relační data

[registrovany123]

Má smysl používat dokumentové databáze pro psaní webový servis, když vím, že data budu chtít ukládat relačně? Ulehčím si tím něco, když vím, že s relační DB můžu použít třeba Hibernate nebo Sqlalchemy?

Příklad relace:

Kód: [Vybrat]

Food  (id, name, calories, author_user_id)
Entry (id, day_id, food_id)
Day   (id, date, user_id)
User  (id, email)

Ty dokumentové databáze se někdy zdají lákavé, protože se zdá, že se s nimi snadněji pracuje, ale je otázka, do jaké šlamastiky se s nimi člověk dostane, když se do nich bude pokoušet cpát relační data.

Jaké máte jsou vaše zkušenosti s dokumentovými databázemi?

[Reklama]

[_Tomáš_]

já bych jako velkou nevýhodu dokumentové databáze viděl evoluce struktur a spousty různých runtime checků, aby ti aplikace nespadla, když tam je něco jiného než kód čeká. Pokud se k projektu vrátíš po nějaké době, relační model ti řekne hodně, obsah dokumentové databáze nic.

[anonacct]

Podle mě se na tento dotaz nedá odpovědět, protože není jasné, jak se ta DB bude používat.

Na jednoduché věci je to podle mě úplně jedno a spíš se jedná o osobní preference.

[snugar_i]

Zkušenosti nemám žádné, takže si jen cucám z prstu:
Pokud popisuješ svůj use-case takhle relačně a jsi zvyklý pracovat relačními databázemi, použil bych spíš ty.
Dokumentové mi přijdou lepší jenom když jsou hodně veliká data anebo když člověk, co aplikaci píše, relačním databázím nerozumí. Na druhou stranu na dokumentové žádný Hibernate nebo Sqlalchemy nepotřebuješ, protože se tam ukládá rovnou celý objekt (a to klidně i několikrát rozkopírovaný, pokud vím).

[oss]

Má smysl používat dokumentové databáze pro psaní webový servis, když vím, že data budu chtít ukládat relačně? Ulehčím si tím něco, když vím, že s relační DB můžu použít třeba Hibernate nebo Sqlalchemy?

Příklad relace:

Kód: [Vybrat]

Food  (id, name, calories, author_user_id)
Entry (id, day_id, food_id)
Day   (id, date, user_id)
User  (id, email)

Ty dokumentové databáze se někdy zdají lákavé, protože se zdá, že se s nimi snadněji pracuje, ale je otázka, do jaké šlamastiky se s nimi člověk dostane, když se do nich bude pokoušet cpát relační data.

Jaké máte jsou vaše zkušenosti s dokumentovými databázemi?

Je to jednoduche.

Ked mas relacne data pouzi relacnu databazu, inak budes trpiet. Pokial mas dokumentove data (samostatne dokumenty, ktore su uplne nezavisle na inach dokumentoch) tiez mozes pouzit relacnu datazu - to plati ale do isteho objemu dat (projekty ako Marten).

Ked su tvoje data samostatne dokumenty (dolezite je samostatne - ziadne relacie, ani suvislosti) tak iba vtedy pouzi dokumentovu databazu. Ale radsej sa vyhni mongu, to je ta najhorsia dokumentova databaza s akou som robil.

[Reklama]

[Filip Jirsák]

Má smysl používat dokumentové databáze pro psaní webový servis, když vím, že data budu chtít ukládat relačně?

Ne. Když chcete používat relační databázi, používejte relační databázi. Jestli se k databázi přistupuje webovými službami nebo nějak jinak je úplně jedno. Rozdíly jsou v tom, jaká máte data (jestli se snáze modelují jako relační databáze, dokumentová, grafová, sloupcová apod.) a jak s nimi chcete pracovat (třeba relační databáze se těžko horizontálně škálují, ale zase mají ACID).

[_Tomáš_]

třeba relační databáze se těžko horizontálně škálují, ale zase mají ACID

Ne, škálují se stejně jako nerelační (dokumentové), když mi stačí je mít jako key-value uložiště. Problém se škálováním právě nastává, když chci využít jeji ACID, transakčnost, spolehlivost, pak se to škáluje špatně, ale to je dáno teoretickým omezením (CAP).

Jsem fanouškem všech různých druhý neklasických databází, u spousty z nich jsem si tak prohloubil znalosti, až konzultace a správu nabízím jako službu. Pořád ale platí, že pokud si nechci hrát a nechci mít starosti, mariadb/postgresql mi poskytnou rychlejší odezvu, lepší správu, nižší HW nároky, stabilnější provoz než většina nerelačních databází a obě mohu vždy používat jako dokumentové, pokud chci.

Lámat se to začne až s velkým provozem (např. ustát 1M qps nebo 99th do 5ms či uložit 100 TB dat) chce už jiný přístup a tady relační databáze ztrácí, ztrácí hodně a bývá levnější je nepoužít. Pokud je někdo použije, je nutné investovat do mikrooptimalizací, úpravy kódu, přizpůsobení aplikace a struktury dat, už tu není ta efektivita a flexibilita. O tom se ale nebavíme, jen většina argumentů se právě o tyhle vlastnosti opírá (viz tvoje výtka se škálováním).

[Filip Jirsák]

Ne, škálují se stejně jako nerelační (dokumentové), když mi stačí je mít jako key-value uložiště. Problém se škálováním právě nastává, když chci využít jeji ACID, transakčnost, spolehlivost, pak se to škáluje špatně, ale to je dáno teoretickým omezením (CAP).

Když chci key-value úložiště, použiju key-value úložiště a ne relační databázi. U které relační databáze lze vypnout ACID a používat ji jako dobře škálovatelné key-value úložiště? Ne-ACID chování asi nebude problém získat u MySQL, ale o fungování MySQL v clusteru se vyprávějí hrůzostrašné historky.

Ale jak jsem psal, důležité je co je to za data a jak se s nimi pracuje. Je úplně jedno, jestli forma přístupu jsou webové služby nebo něco jiného.