MariaDB vs Postgres vs SQL Server

Idris

  • *****
  • 1 565
    • Zobrazit profil
    • E-mail
Re:MariaDB vs Postgres vs SQL Server
« Odpověď #165 kdy: 25. 04. 2021, 02:34:11 »
Ano, nejspíš to tak je. Ale distr. transakce jsou celkem velká komplikace. Možná právě tento typ problémů tenhle typ řešení persistence zazdil? Na mě to působí jako málo muziky za hodně peněz. Každopádně nevím o žádné implementaci, která by nebyla jen akademickým experimentem. Ale úvahy to jsou bezpochyby zajímavé.
Mě se to nezdá. Na základě kanálů, které se začali používat v posledním roce dokazuješ, že se to proto neujalo?

IMHO se to neujalo proto, páč na začátku jsme u C byli rádi, když přišel GC. Pozdějc přišla móda dynamický jazyků se svým "hele jak hezky se to dá napsat". A pak už se usadil ten mindset, že data se vytahují a vrací z/do persistence. Technické obtíže bych v tom nehledal.
Nic nedokazuju, ani na to nemám vyhraněný názor a nejspíš vůbec nejde říct jeden důvod neúspěchu. Nicméně v tomto případě je mnoho technických komplikací, které nějakou dostatečně robustní implementaci sabotují. Už jen u těch distr. objektů (bez úložiště) vznikaly problémy se správou paměti, asynchronním zpracováním apod.

Enterprise Objects Framework je asi jediná technologie, která ty největší problémy se ctí překonala.


Re:MariaDB vs Postgres vs SQL Server
« Odpověď #166 kdy: 25. 04. 2021, 08:05:09 »
Případně, pokud chci transakčnost, tak:
- začni atomický blok
- najdi v poli požadovaný záznam
- uprav v něm co potřebuješ
- commit
Tohle zní slibně. Takhle nějak fungoval jeden z módů db4objects.

Tenhle postup je důvod, proč jsou objektové databáze i vlastně i věci napsané nad ORM pomalé. Pokud objekt není už v paměti, tak načtení objektů po jednom je drahé (počínaje diskovými operacemi a konče sítí). Částečným řešením je držet si objekty v RAMce - ale tím se dostanete do problémů s udržením konzistence, zamykáním a se správou cache. A navíc potřebujete kopii databáze v paměti. V momentě, kdy se mi hromadná operace změní na cyklus nad individuálními operacemi, tak jde výkon do háje.

Oproti objektovému přístupu SQL popisuje pouze hromadné operace (operace nad relacemi). Operace nad jedním záznamem je jen jeden speciální případ. Díky tomu má optimalizátor prostor pro výběr z implementací vhodné pro zpracování většího množství záznamů (seq scan, merge join) nebo naopak menšího množství (index scan, nested loop). Podle mne je tohle základní problém.

Když se pracuje s izolovanými hodnotami, tak objektové databáze nebo ORMka nemají jediný problém. Ale pro hromadné operace, tam vlastně není moc prostoru jak je implementovat efektivně (neduplikovat objekty v RAM, redukovat síťové operace, redukovat diskové operace). Řešitelné by to podle mne bylo - tytéž operace, které dělám nad objektem bych měl být schopen udělat nad kolekcí objektů - a mohlo by to fungovat pokud by vývojář použil tento interface. Jakmile programátor ale použije cyklus, tak tam není možná optimalizace - ledaže by se reimplementoval cyklus, a že by klient dokázal distribuovat volání operací na databázový server - a že by databáze dokázala pro implementaci cyklu použít vlastní optimální algoritmus (seq scan nebo index scan).

Chápu, že programátor chce být odizolován od implementace uložení dat. Nicméně je potřeba počítat, že data se mezi storage a aplikací nepřesouvají nekonečně rychle, a že je vždy režie na záznam, a na operaci. A totéž platí i o načítání dat. Pokud pak používám interface, který určuje, že mám pracovat s konkrétním záznamem, tak už neumožňuji efektivní implementaci (rozdíl v rychlostech v přístupech k izolovaným hodnotám a v hromadných operacích) může být i o řád nebo o dva. Pokud máte v datech milióny, desítky miliónů záznamů, tak rozdíl v efektivním a neefektivním zpracování bude v hodinách.

Co zaznělo v diskuzi, tak se vývojáři objektových databází zaměřili na co nejlepší bezešvou integraci databáze s objektovým prostředím. Ale pak naráží na  efektivitu přístupu ke uložišti. SQL databáze na to jdou úplně z druhé strany. V prvé řadě řeší efektivitu přístupu k datům (minimalizace random IO, minimalizace přenesených dat po síti). Pokud mám data uložená lokálně (nedochází ke sdílení, nemusím řešit síťovou komunikaci, data jsou na ssd - nemusím řešit random IO), tak ten objektový přístup může fungovat. V opačném případě si to moc nedovedu představit. SQL databáze se snaží vývojáře izolovat od některých implementačních detailů (nemusí řešit jestli se použije seq io nebo random IO, nemusí řešit síťovou komunikaci) - a tím končí. Vůbec se nesnaží o nějakou integraci s vývojovým prostředím. To ani nejde. Nemám a ani nechci Postgres pro Javu, a jiný pro C#.

Idris

  • *****
  • 1 565
    • Zobrazit profil
    • E-mail
Re:MariaDB vs Postgres vs SQL Server
« Odpověď #167 kdy: 25. 04. 2021, 10:14:06 »
Co zaznělo v diskuzi, tak se vývojáři objektových databází zaměřili na co nejlepší bezešvou integraci databáze s objektovým prostředím. Ale pak naráží na  efektivitu přístupu ke uložišti. SQL databáze na to jdou úplně z druhé strany. V prvé řadě řeší efektivitu přístupu k datům (minimalizace random IO, minimalizace přenesených dat po síti). Pokud mám data uložená lokálně (nedochází ke sdílení, nemusím řešit síťovou komunikaci, data jsou na ssd - nemusím řešit random IO), tak ten objektový přístup může fungovat. V opačném případě si to moc nedovedu představit. SQL databáze se snaží vývojáře izolovat od některých implementačních detailů (nemusí řešit jestli se použije seq io nebo random IO, nemusí řešit síťovou komunikaci) - a tím končí. Vůbec se nesnaží o nějakou integraci s vývojovým prostředím. To ani nejde. Nemám a ani nechci Postgres pro Javu, a jiný pro C#.
Většina objektových databází, co se aspoň trochu chytly, fungovala lokálně (embedded). DB servery, co se nabízely, byly často nadstavbou nad tím lokálním řešením. Co si tak matně pamatuju db4objects, tak si v paměti držela výsledky dotazů v kolekci proxy objektů, které se nahrály do paměti, jakmile k nim chtěl kód přistupovat.

Re:MariaDB vs Postgres vs SQL Server
« Odpověď #168 kdy: 25. 04. 2021, 17:26:15 »
(...)

Když se pracuje s izolovanými hodnotami, tak objektové databáze nebo ORMka nemají jediný problém. Ale pro hromadné operace, tam vlastně není moc prostoru jak je implementovat efektivně (neduplikovat objekty v RAM, redukovat síťové operace, redukovat diskové operace). Řešitelné by to podle mne bylo - tytéž operace, které dělám nad objektem bych měl být schopen udělat nad kolekcí objektů - a mohlo by to fungovat pokud by vývojář použil tento interface.

(...)

Takže pokud je objektový graf v paměti, nebude mít ani objektové databáze s hromadnou operací nějaký zásadní výkonnostní problém (cyklus se změnou nějaké hodnoty u kolekce objektů může být docela rychlá operace, navíc to asi půjde v řadě případů i paralelizovat). Hlavní benefit by přitom byl nulový object-relational impedance mismatch (neznám český ekvivalent tohoto pojmu). Ten sám o sobě přináší výkonnostní problémy, takže v reálných projektech by pak mohla být objektová databáze naopak rychlejší než neoptimálně použité ORM, kde navíc hrozí  i nekonzistence (při neobratném použití), což zase eliminuje další killer feature sql databází (konzistenci).

Konceptem in-memory objektové databáze se pohybujeme cca někde na úrovni toho Smalltalku, který taky ukládá image na disk až na ruční vyžádání. Čili se nakonec celá debata vede o tom, co z ACID (atomicity, consistency, isolation, durability) mohou objektové (či NoSQL) databáze vlastně nabídnout. A téma o možnosti objektovou databázi provozovat distribuovaně napříč stroji je další level téhož.

Re:MariaDB vs Postgres vs SQL Server
« Odpověď #169 kdy: 25. 04. 2021, 17:51:23 »
Takže pokud je objektový graf v paměti, nebude mít ani objektové databáze s hromadnou operací nějaký zásadní výkonnostní problém (cyklus se změnou nějaké hodnoty u kolekce objektů může být docela rychlá operace, navíc to asi půjde v řadě případů i paralelizovat). Hlavní benefit by přitom byl nulový object-relational impedance mismatch (neznám český ekvivalent tohoto pojmu). Ten sám o sobě přináší výkonnostní problémy, takže v reálných projektech by pak mohla být objektová databáze naopak rychlejší než neoptimálně použité ORM, kde navíc hrozí  i nekonzistence (při neobratném použití), což zase eliminuje další killer feature sql databází (konzistenci).

Konceptem in-memory objektové databáze se pohybujeme cca někde na úrovni toho Smalltalku, který taky ukládá image na disk až na ruční vyžádání. Čili se nakonec celá debata vede o tom, co z ACID (atomicity, consistency, isolation, durability) mohou objektové (či NoSQL) databáze vlastně nabídnout. A téma o možnosti objektovou databázi provozovat distribuovaně napříč stroji je další level téhož.

Pokud to bude inmemory a na aplikačním serveru, tak by výkon mohl být ok. Nicméně asi stejně potřebujete něco ve smyslu indexů (ať už nějaké stromy nebo hash tabulky). Je otázkou, jak by se to chovalo po studeném startu. Jinak samozřejmě, výkon a chování by mělo být +/- srovnatelné s ostatními inmemory databázemi. Ale i mezi inmemory databázemi mohou být výkonnostní rozdíly - v extrému se řeší i design, který minimalizuje výpadky CPU cache - on random access nesvědčí ani RAMce


BoneFlute

  • *****
  • 1 731
    • Zobrazit profil
Re:MariaDB vs Postgres vs SQL Server
« Odpověď #170 kdy: 25. 04. 2021, 21:25:08 »
Případně, pokud chci transakčnost, tak:
- začni atomický blok
- najdi v poli požadovaný záznam
- uprav v něm co potřebuješ
- commit
Tohle zní slibně. Takhle nějak fungoval jeden z módů db4objects.

Tenhle postup je důvod, proč jsou objektové databáze i vlastně i věci napsané nad ORM pomalé. Pokud objekt není už v paměti, tak načtení objektů po jednom je drahé (počínaje diskovými operacemi a konče sítí). Částečným řešením je držet si objekty v RAMce - ale tím se dostanete do problémů s udržením konzistence, zamykáním a se správou cache. A navíc potřebujete kopii databáze v paměti. V momentě, kdy se mi hromadná operace změní na cyklus nad individuálními operacemi, tak jde výkon do háje.

Oproti objektovému přístupu SQL popisuje pouze hromadné operace (operace nad relacemi). Operace nad jedním záznamem je jen jeden speciální případ. Díky tomu má optimalizátor prostor pro výběr z implementací vhodné pro zpracování většího množství záznamů (seq scan, merge join) nebo naopak menšího množství (index scan, nested loop). Podle mne je tohle základní problém.

Když se pracuje s izolovanými hodnotami, tak objektové databáze nebo ORMka nemají jediný problém. Ale pro hromadné operace, tam vlastně není moc prostoru jak je implementovat efektivně (neduplikovat objekty v RAM, redukovat síťové operace, redukovat diskové operace). Řešitelné by to podle mne bylo - tytéž operace, které dělám nad objektem bych měl být schopen udělat nad kolekcí objektů - a mohlo by to fungovat pokud by vývojář použil tento interface. Jakmile programátor ale použije cyklus, tak tam není možná optimalizace - ledaže by se reimplementoval cyklus, a že by klient dokázal distribuovat volání operací na databázový server - a že by databáze dokázala pro implementaci cyklu použít vlastní optimální algoritmus (seq scan nebo index scan).

Chápu, že programátor chce být odizolován od implementace uložení dat. Nicméně je potřeba počítat, že data se mezi storage a aplikací nepřesouvají nekonečně rychle, a že je vždy režie na záznam, a na operaci. A totéž platí i o načítání dat. Pokud pak používám interface, který určuje, že mám pracovat s konkrétním záznamem, tak už neumožňuji efektivní implementaci (rozdíl v rychlostech v přístupech k izolovaným hodnotám a v hromadných operacích) může být i o řád nebo o dva. Pokud máte v datech milióny, desítky miliónů záznamů, tak rozdíl v efektivním a neefektivním zpracování bude v hodinách.

Co zaznělo v diskuzi, tak se vývojáři objektových databází zaměřili na co nejlepší bezešvou integraci databáze s objektovým prostředím. Ale pak naráží na  efektivitu přístupu ke uložišti. SQL databáze na to jdou úplně z druhé strany. V prvé řadě řeší efektivitu přístupu k datům (minimalizace random IO, minimalizace přenesených dat po síti). Pokud mám data uložená lokálně (nedochází ke sdílení, nemusím řešit síťovou komunikaci, data jsou na ssd - nemusím řešit random IO), tak ten objektový přístup může fungovat. V opačném případě si to moc nedovedu představit. SQL databáze se snaží vývojáře izolovat od některých implementačních detailů (nemusí řešit jestli se použije seq io nebo random IO, nemusí řešit síťovou komunikaci) - a tím končí. Vůbec se nesnaží o nějakou integraci s vývojovým prostředím. To ani nejde. Nemám a ani nechci Postgres pro Javu, a jiný pro C#.

Ano, to je další výhoda databáze jako externího řešení. Snadnější implementace.

Každopádně, abych spojil tvé připomínky s mou vizí:

Klasické řešení:
Kód: [Vybrat]
foreach (x in conn.query('SELECT * FROM post WHERE name LIKE ?', "Jozef%")) {
  format(map2object(x))
}

ORM řešení:
Kód: [Vybrat]
foreach (x in orm.find<Post>(type(Post).name.like("%Jozef%"))) {
   format(x)
}

se přeloží na:
Kód: [Vybrat]
foreach (x in conn.query('SELECT * FROM post WHERE name LIKE ?', "Jozef%")) {
  format(map2object(x))
}


Moje vize:
Kód: [Vybrat]
foreach (x in posts) {
    if startWith(x.name, "Jozef") {
        format(x)
    }
}

se přeloží na:
Kód: [Vybrat]
foreach (x in conn.query('SELECT * FROM post WHERE name LIKE ?', "Jozef%")) {
  format(map2object(x))
}

ORM jsou pomalé svině. Ale ne proto, že by pomalé být musely. Není důvod, aby se načítali po jednom. A v mnoha případech se i načítají velice chytře. Vůbec, obecně vzato není důvod si myslet, že by ORM neměli být stejně chytré, jako ručně psané SQL. IMHO je to stejný vývoj, jako ruční správa paměti -> GC -> escape analýza. Ručně psané ASM -> C -> JustInTime. Je to jen otázka času.
« Poslední změna: 25. 04. 2021, 21:29:17 od BoneFlute »

BoneFlute

  • *****
  • 1 731
    • Zobrazit profil
Re:MariaDB vs Postgres vs SQL Server
« Odpověď #171 kdy: 25. 04. 2021, 21:27:39 »
Čili se nakonec celá debata vede o tom, co z ACID (atomicity, consistency, isolation, durability) mohou objektové (či NoSQL) databáze vlastně nabídnout.
No, já bych prosil komplet. Jinak nemám důvod PostgreSQL opouštět.

Idris

  • *****
  • 1 565
    • Zobrazit profil
    • E-mail
Re:MariaDB vs Postgres vs SQL Server
« Odpověď #172 kdy: 25. 04. 2021, 21:29:31 »
ORM jsou pomalé svině. Ale ne proto, že by pomalé být musely. Není důvod, aby se načítali po jednom. A v mnoha případech se i načítají velice chytře. Vůbec, obecně vzato není důvod si myslet, že by ORM neměli být stejně chytré, jako ručně psané SQL. IMHO je to stejný vývoj, jako ruční správa paměti -> GC -> escape analýza. Ručně psané ASM -> C -> JustInTime. Je to jen otázka času.
Tak mě v této souvislosti napadá, že místo kolekcí s proxy objekty, používaných v současných objektových databázích, by byly efektivnější streamy (bez proxy objektů).

Re:MariaDB vs Postgres vs SQL Server
« Odpověď #173 kdy: 25. 04. 2021, 22:01:27 »
ORM jsou pomalé svině. Ale ne proto, že by pomalé být musely. Není důvod, aby se načítali po jednom. A v mnoha případech se i načítají velice chytře. Vůbec, obecně vzato není důvod si myslet, že by ORM neměli být stejně chytré, jako ručně psané SQL. IMHO je to stejný vývoj, jako ruční správa paměti -> GC -> escape analýza. Ručně psané ASM -> C -> JustInTime. Je to jen otázka času.

Tohle nejde rozporovat :-). Koneckonců SQL je vlastně něco podobného. Funkcionalitu už tady zmíňeného ADABASu defacto představuje executor, a program napsaný v jazyku prováděcích plánů. Takže do jisté míry platí ADABAS (ISAM)->SQL. Jde jen o to, jak to udělat, aby z toho nelezl ten ISAM, případně aby nevznikl interface ještě komplikovanější než SQL. Aby došlo ke skutečnému technologickému progresu.

Re:MariaDB vs Postgres vs SQL Server
« Odpověď #174 kdy: 25. 04. 2021, 22:08:48 »
ORM jsou pomalé svině. Ale ne proto, že by pomalé být musely. Není důvod, aby se načítali po jednom. A v mnoha případech se i načítají velice chytře. Vůbec, obecně vzato není důvod si myslet, že by ORM neměli být stejně chytré, jako ručně psané SQL. IMHO je to stejný vývoj, jako ruční správa paměti -> GC -> escape analýza. Ručně psané ASM -> C -> JustInTime. Je to jen otázka času.

ORM (např. jOOQ) mají API na zápis SQL 1:1, takže v dotazech asi hlavní problém nebude. Spíš jde o to že se leckdy kopíruje zbytečně sem a tam. Anebo teda, že se nepoužije join ale traversuje nějaká struktura s postupným načítáním závislých položek kus po kusu. A programátor si to nemusí uvědomit, protože z kódu není na první pohled vidět, co se děje pod kapotou.

Tak mě v této souvislosti napadá, že místo kolekcí s proxy objekty, používaných v současných objektových databázích, by byly efektivnější streamy (bez proxy objektů).

Ve kterých databázích? Je vůbec nějaků důvod, proč by funkcionální API (streamy, map, reduce) nemělo být pro objekty v paměti  dostatečné?

Idris

  • *****
  • 1 565
    • Zobrazit profil
    • E-mail
Re:MariaDB vs Postgres vs SQL Server
« Odpověď #175 kdy: 25. 04. 2021, 22:15:06 »
Ve kterých databázích? Je vůbec nějaků důvod, proč by funkcionální API (streamy, map, reduce) nemělo být pro objekty v paměti  dostatečné?
Například db4objects nebo Realm. Ono to právě není pro objekty v paměti, je to pro objekty na disku v embedded databázi. Proto tam mají ty proxy objekty. No a podle mě jsou lepším řešením streamy, ale možná mi uniká nějaký zásadní důvod, proč jsou proxy objekty lepší.

BoneFlute

  • *****
  • 1 731
    • Zobrazit profil
Re:MariaDB vs Postgres vs SQL Server
« Odpověď #176 kdy: 25. 04. 2021, 23:46:45 »
ORM jsou pomalé svině. Ale ne proto, že by pomalé být musely. Není důvod, aby se načítali po jednom. A v mnoha případech se i načítají velice chytře. Vůbec, obecně vzato není důvod si myslet, že by ORM neměli být stejně chytré, jako ručně psané SQL. IMHO je to stejný vývoj, jako ruční správa paměti -> GC -> escape analýza. Ručně psané ASM -> C -> JustInTime. Je to jen otázka času.

Tohle nejde rozporovat :-). Koneckonců SQL je vlastně něco podobného. Funkcionalitu už tady zmíňeného ADABASu defacto představuje executor, a program napsaný v jazyku prováděcích plánů. Takže do jisté míry platí ADABAS (ISAM)->SQL. Jde jen o to, jak to udělat, aby z toho nelezl ten ISAM, případně aby nevznikl interface ještě komplikovanější než SQL. Aby došlo ke skutečnému technologickému progresu.
Moje idea je, že se to celé převrátí. Nebudeme se z aplikace dotazovat na data do databáze, ale budeme mít databázi, ve které bude napsaná aplikace. Další generace smalltalku.

Idris

  • *****
  • 1 565
    • Zobrazit profil
    • E-mail
Re:MariaDB vs Postgres vs SQL Server
« Odpověď #177 kdy: 26. 04. 2021, 00:07:24 »
ORM jsou pomalé svině. Ale ne proto, že by pomalé být musely. Není důvod, aby se načítali po jednom. A v mnoha případech se i načítají velice chytře. Vůbec, obecně vzato není důvod si myslet, že by ORM neměli být stejně chytré, jako ručně psané SQL. IMHO je to stejný vývoj, jako ruční správa paměti -> GC -> escape analýza. Ručně psané ASM -> C -> JustInTime. Je to jen otázka času.

Tohle nejde rozporovat :-). Koneckonců SQL je vlastně něco podobného. Funkcionalitu už tady zmíňeného ADABASu defacto představuje executor, a program napsaný v jazyku prováděcích plánů. Takže do jisté míry platí ADABAS (ISAM)->SQL. Jde jen o to, jak to udělat, aby z toho nelezl ten ISAM, případně aby nevznikl interface ještě komplikovanější než SQL. Aby došlo ke skutečnému technologickému progresu.
Moje idea je, že se to celé převrátí. Nebudeme se z aplikace dotazovat na data do databáze, ale budeme mít databázi, ve které bude napsaná aplikace. Další generace smalltalku.
A nechceš si napsat prototyp, ať se máme nad čím bavit? ;) Nevím, jestli přímo ve Smalltalku, ale určitě by to bylo zajímavé.

Re:MariaDB vs Postgres vs SQL Server
« Odpověď #178 kdy: 26. 04. 2021, 00:25:40 »
Moje idea je, že se to celé převrátí. Nebudeme se z aplikace dotazovat na data do databáze, ale budeme mít databázi, ve které bude napsaná aplikace. Další generace smalltalku.
A nechceš si napsat prototyp, ať se máme nad čím bavit? ;) Nevím, jestli přímo ve Smalltalku, ale určitě by to bylo zajímavé.

Squeak Magma? Persistence by reachability, transparent access, multiple users via optimistic locking, transactions, proxies are used to truncate the portions of the domain model that are not currently in memory,  pretty good performance, robust querying with indexes... and more  :D



BoneFlute

  • *****
  • 1 731
    • Zobrazit profil
Re:MariaDB vs Postgres vs SQL Server
« Odpověď #179 kdy: 26. 04. 2021, 00:52:16 »
ORM jsou pomalé svině. Ale ne proto, že by pomalé být musely. Není důvod, aby se načítali po jednom. A v mnoha případech se i načítají velice chytře. Vůbec, obecně vzato není důvod si myslet, že by ORM neměli být stejně chytré, jako ručně psané SQL. IMHO je to stejný vývoj, jako ruční správa paměti -> GC -> escape analýza. Ručně psané ASM -> C -> JustInTime. Je to jen otázka času.

Tohle nejde rozporovat :-). Koneckonců SQL je vlastně něco podobného. Funkcionalitu už tady zmíňeného ADABASu defacto představuje executor, a program napsaný v jazyku prováděcích plánů. Takže do jisté míry platí ADABAS (ISAM)->SQL. Jde jen o to, jak to udělat, aby z toho nelezl ten ISAM, případně aby nevznikl interface ještě komplikovanější než SQL. Aby došlo ke skutečnému technologickému progresu.
Moje idea je, že se to celé převrátí. Nebudeme se z aplikace dotazovat na data do databáze, ale budeme mít databázi, ve které bude napsaná aplikace. Další generace smalltalku.
A nechceš si napsat prototyp, ať se máme nad čím bavit? ;) Nevím, jestli přímo ve Smalltalku, ale určitě by to bylo zajímavé.

Chci. Je to aktuálně můj primární hobby projekt. Ale je málo času, tak o tom maximálně žvaním tady na rootu :-)