NoSql document databaze

[Zabanovaný Anonymní Troll]

Mam dotaz na vsechny mistni no-typed-language a no-sql fandy. Muze mi nekdo z vas vysvetlit, proc, kdyz mam potrebu ukladat ve sve aplikaci rovnez i data typu "document", bych mel pouzit NoSql databazi namisto klsicke Postgres, kde si document-like data muzu strcit do sloupce s formatem JSON? Jdou nad tim normalne delat queries, muzu si jednotlive libovolne vnorene atributy toho JSONu dokonce i indexovat, pak si ten column muzu i v ORM namapovat na prislusnou tridy. Tak proc bych na to pouzil NoSQL databazi, kdyz muzu pouzit klasicke kombo ORM+SQL, a muzu pak ve sve databazi pouzivat jak relacni data, tak i document data, podle potreby.

[Reklama]

[BoneFlute]

1. NoSQL vznikly v době, kdy podpora pro JSON a XML sloupce a dotazování nad ním nebyly ještě tak rozšířené jak stále nejsou nyní.

2. NoSQL mají (obvykle) dobré vlastnosti co se replikace týče.

[Filip Jirsák]

PostgreSQL budete třeba těžko provozovat v režimu „repliky po celém světě, a dokud vidím n/2+1 repliky, v pohodě funguju“. Nad PostgreSQL musíte ručně stavět indexy. Partitioning a dotazování přes víc serverů také v PostgreSQL nejdou dělat úplně snadno.

Pokud potřebuju v databázi ukládat dokumenty, proč bych se mořil s nějakým SQL nebo dokonce ORM?

[Zabanovaný Anonymní Troll]

1. PostgreSQL budete třeba těžko provozovat v režimu „repliky po celém světě, a dokud vidím n/2+1 repliky, v pohodě funguju“.


2. Nad PostgreSQL musíte ručně stavět indexy.

3. Partitioning a dotazování přes víc serverů také v PostgreSQL nejdou dělat úplně snadno.

4. Pokud potřebuju v databázi ukládat dokumenty, proč bych se mořil s nějakým SQL nebo dokonce ORM?

1. Proc by mi nemel nejaka replika relacni databaze bezet? To prece neni vubec nromalni stav. Vam uz se nekdy na produkci snad stalo, ze vam z niceho nic nebezela replika Oraclu? A to jste na to nadaval, ze to tak je? Databaze ma byt schopna bezet NONSTOP. Takze tuhle vyhodu NoSql neberu, nevim co to je za usecase.

2. Nemusite si delat klidne zadne indexy :-) Date je tam jen kdyz budetep potrebovat. Ale ok, tohle beru, je to vice prace.

3. Podobne jako bod c. 1 - naco?

4. Protoze uz mate projekt kde mate nakonfigurovane ORM? Na to bych vam rekl proc bych se najednou jeste k tomu moril s NoSQL jenom proto ze potrebuju ukladat json a vyrabel k tomu dalsi konfiguraci.

[alex6bbc]

volba technologie je vec vhodnosti, pouzijte technologii co se vam hodi.
klidne si drzte data v RAMce.

[Reklama]

[Zabanovaný Anonymní Troll]

volba technologie je vec vhodnosti, pouzijte technologii co se vam hodi.
klidne si drzte data v RAMce.

blablabla.

[Jiří Havel]

1. Proc by mi nemel nejaka replika relacni databaze bezet? To prece neni vubec nromalni stav. Vam uz se nekdy na produkci snad stalo, ze vam z niceho nic nebezela replika Oraclu? A to jste na to nadaval, ze to tak je? Databaze ma byt schopna bezet NONSTOP. Takze tuhle vyhodu NoSql neberu, nevim co to je za usecase.

Protože spadla, indiáni vytrhali kabely, nebo nějaký jiný neplánovaný průser. Úplně normální stav, jen se děje zřídka.

A ve chvíli, kdy celý systém celý běží i ve chvíli kdy pár strojů ne, mám jako bonus i možnost ty stroje udržovat, aktualizovat a podobně bez jakéhokoliv viditelného výpadku. Tohle se u vás v korporátu nepovažuje za normální?

[Zabanovaný Anonymní Troll]

1. Proc by mi nemel nejaka replika relacni databaze bezet? To prece neni vubec nromalni stav. Vam uz se nekdy na produkci snad stalo, ze vam z niceho nic nebezela replika Oraclu? A to jste na to nadaval, ze to tak je? Databaze ma byt schopna bezet NONSTOP. Takze tuhle vyhodu NoSql neberu, nevim co to je za usecase.

Protože spadla, indiáni vytrhali kabely, nebo nějaký jiný neplánovaný průser. Úplně normální stav, jen se děje zřídka.

A ve chvíli, kdy celý systém celý běží i ve chvíli kdy pár strojů ne, mám jako bonus i možnost ty stroje udržovat, aktualizovat a podobně bez jakéhokoliv viditelného výpadku. Tohle se u vás v korporátu nepovažuje za normální?

1. Tak presmerujete trafic na jinou repliku na jinem stroji
2. Nebo rozjedete svoji relacni databazi v Cloudu a nemusite se uz o udrzovani stroju starat vubec
3. A pokud pouzijete NoSQL abyste mel vyhodu kterou popisujete, tak musite prejit KOMPLETNE NA NOSQL, protoze system vam porad nebude fungovat, kdyz nejste schopni se o nej postarat kvuli relacnim databazim, ikdyz jich mate jen trochu. Proste bud tak, a nebo tak, a nic mezitim.

Takze jeste jednou:

Naco NoSQL???

[Pavel Tišnovský]

Chápu správně, že ten dotaz je na porovnání databáze s ACID (řekněme tedy RDBMS dnes typicky založené na SQL) a dokumentových databází? Asi nejkratší odpověď bude, že databáze s ACID garantují jiné dvě vlastnosti z CAP teorému, než dokumentové databáze - konzistence vs. dostupnost.

[qelurg]

volba technologie je vec vhodnosti, pouzijte technologii co se vam hodi.
klidne si drzte data v RAMce.

Spravna odpoved.

[Johnny]

volba technologie je vec vhodnosti, pouzijte technologii co se vam hodi.
klidne si drzte data v RAMce.

Spravna odpoved.

Neměla by být ale databázová vrstva spíš od aplikace oddělená tak, aby naopak nezáleželo na tom, jakou databázi použiju?

[alex6bbc]

volba technologie je vec vhodnosti, pouzijte technologii co se vam hodi.
klidne si drzte data v RAMce.

Spravna odpoved.

Neměla by být ale databázová vrstva spíš od aplikace oddělená tak, aby naopak nezáleželo na tom, jakou databázi použiju?

no samozrejme :-)

tazatelovi neni jasne, ze muze pouzit jakoukoliv technologii, rozplyval se tam nad sql db a nechapal pouziti no_sql db.
akorat tazatelovi neni jasne, ze to zavisi na situaci jaka technologie je vhodna, klidne lze mit data v RAM, nebo nacistat soubory.

[Miroslav Šilhavý]

volba technologie je vec vhodnosti, pouzijte technologii co se vam hodi.
klidne si drzte data v RAMce.

Spravna odpoved.

Neměla by být ale databázová vrstva spíš od aplikace oddělená tak, aby naopak nezáleželo na tom, jakou databázi použiju?

no samozrejme :-)

Ne, neměla. Každá databáze má svá specifika, svůj vlastní dialekt a je jinak silná v jiných operacích.
Když použijete ORM nebo jiný způsob zuniverzálnění práce s daty, připravíte se o největší sílu databází.

Pokud děláte malou aplikaci s malými daty, stojí za to používat ORM a neřešit to.
Kdykoliv děláte něco většího, je to už koule u nohy a nikdy nic nevyladíte.

[Johnny]

volba technologie je vec vhodnosti, pouzijte technologii co se vam hodi.
klidne si drzte data v RAMce.

Spravna odpoved.

Neměla by být ale databázová vrstva spíš od aplikace oddělená tak, aby naopak nezáleželo na tom, jakou databázi použiju?

no samozrejme :-)

Ne, neměla. Každá databáze má svá specifika, svůj vlastní dialekt a je jinak silná v jiných operacích.
Když použijete ORM nebo jiný způsob zuniverzálnění práce s daty, připravíte se o největší sílu databází.

Pokud děláte malou aplikaci s malými daty, stojí za to používat ORM a neřešit to.
Kdykoliv děláte něco většího, je to už koule u nohy a nikdy nic nevyladíte.

Ale měla, měla. Já jsem ochoten uznat, že nějaká specifika, neboli nějaké takové rozdíly jsou např. mezi db typu key/value vs. relační db vs. grafovou db, (případně relační vs. objektovou, tam má ta odlišnost i teoretický základ), ale i tak jsem to myslel trochu jinak.
Ve chvíli, kdy relační databáze umožní uložit libovolný dokument (json) do jednoho sloupce, tak v tom okamžiku se na ni můžu dívat jako implementaci dokumentové databáze, a v tomto ohledu jsou ekvivalentní v tom smyslu, že nemůžu říct, která je vhodnější, nebo není. Prostě jsou na tom stejně. Pochopitelně jedna implementace bude rychlejší v tom, jedna pomalejší v onom, ale jako koncept umí totéž. Ale proč bych kvůli změně měl přepisovat aplikaci?

Příklad - nejblíž té univerzálnosti má podle mě GraphQL, ne ORM, a jaká je tam databáze je pak jedno.

[Miroslav Šilhavý]

Ale měla, měla. Já jsem ochoten uznat, že nějaká specifika, neboli nějaké takové rozdíly jsou např. mezi db typu key/value vs. relační db vs. grafovou db, (případně relační vs. objektovou, tam má ta odlišnost i teoretický základ), ale i tak jsem to myslel trochu jinak.
Ve chvíli, kdy relační databáze umožní uložit libovolný dokument (json) do jednoho sloupce, tak v tom okamžiku se na ni můžu dívat jako implementaci dokumentové databáze, a v tomto ohledu jsou ekvivalentní v tom smyslu, že nemůžu říct, která je vhodnější, nebo není. Prostě jsou na tom stejně. Pochopitelně jedna implementace bude rychlejší v tom, jedna pomalejší v onom, ale jako koncept umí totéž. Ale proč bych kvůli změně měl přepisovat aplikaci?

Příklad - nejblíž té univerzálnosti má podle mě GraphQL, ne ORM, a jaká je tam databáze je pak jedno.

Uznávám, pokud nevyžadujete relační funkce, tak se to dá zuniverzálnit.
Neumím si představit situaci, kdy potřebujete ukládat dokument a zároveň nepotřebujete relační funkce, ale možné to je. Např. mít jedno spojení na relační databázi (a využívat specifické vlastnosti), a nezávislé spojení na získání dokumentu (a to může být univerzální).

Já jsem spíš (asi off topic) komentoval dnešní snahy o ORM, která databáze výkonově degraduje v podstatě na úroveň dBase nebo FoxPro (a dohání se to rostoucím výkonem hardware).