reklama

NoSql document databaze

PetrK

  • ****
  • 409
    • Zobrazit profil
NoSql document databaze
« kdy: 28. 03. 2020, 23:34:04 »
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 418
    • Zobrazit profil
Re:NoSql document databaze
« Odpověď #1 kdy: 28. 03. 2020, 23:41:15 »
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.

Re:NoSql document databaze
« Odpověď #2 kdy: 28. 03. 2020, 23:55:52 »
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?

PetrK

  • ****
  • 409
    • Zobrazit profil
Re:NoSql document databaze
« Odpověď #3 kdy: 29. 03. 2020, 00:32:30 »
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.

Re:NoSql document databaze
« Odpověď #4 kdy: 29. 03. 2020, 01:53:04 »
volba technologie je vec vhodnosti, pouzijte technologii co se vam hodi.
klidne si drzte data v RAMce.

reklama


PetrK

  • ****
  • 409
    • Zobrazit profil
Re:NoSql document databaze
« Odpověď #5 kdy: 29. 03. 2020, 03:01:26 »
volba technologie je vec vhodnosti, pouzijte technologii co se vam hodi.
klidne si drzte data v RAMce.

blablabla.

Re:NoSql document databaze
« Odpověď #6 kdy: 29. 03. 2020, 09:57:54 »
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í?

PetrK

  • ****
  • 409
    • Zobrazit profil
Re:NoSql document databaze
« Odpověď #7 kdy: 29. 03. 2020, 11:39:08 »
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???

Re:NoSql document databaze
« Odpověď #8 kdy: 29. 03. 2020, 14:47:32 »
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

  • ***
  • 229
    • Zobrazit profil
    • E-mail
Re:NoSql document databaze
« Odpověď #9 kdy: 29. 03. 2020, 16:54:46 »
volba technologie je vec vhodnosti, pouzijte technologii co se vam hodi.
klidne si drzte data v RAMce.
Spravna odpoved.

Re:NoSql document databaze
« Odpověď #10 kdy: 29. 03. 2020, 17:34:44 »
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?

Re:NoSql document databaze
« Odpověď #11 kdy: 29. 03. 2020, 17:53:58 »
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.

Re:NoSql document databaze
« Odpověď #12 kdy: 29. 03. 2020, 18:48:17 »
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.

Re:NoSql document databaze
« Odpověď #13 kdy: 29. 03. 2020, 19:33:44 »
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.

Re:NoSql document databaze
« Odpověď #14 kdy: 29. 03. 2020, 20:44:50 »
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).

 

reklama