Příspěvky

346

Server / Re:MariaDB vs Postgres vs SQL Server

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

347

Server / Re:MariaDB vs Postgres vs SQL Server

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

348

Server / Re:MariaDB vs Postgres vs SQL Server

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

349

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 25. 04. 2021, 02:14:41 »

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.

350

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 25. 04. 2021, 02:10:30 »

Vytvoření kopie range řešení není, když ten objekt už bude menší.

hluboké kopie

Každopádně tento problém má řekl bych celkem snadné řešení. Pokud se tedy bavíme o těch kanálech. Když objekt opustí instanci, tak už jej instance nevlastní. Vyřešeno dvacet.

Pokud se bavíme čistě jen o tom "kloudu" instancí, tak prostě klasický problém jako kdyby to byla databáze. Co se stane když někdo smaže prvek z kolekce v jiné instanci?:

Kód: [Vybrat]

trx = conn.startTransaction()
for x in range(trx.query(....)) { .... }
trx.commit()

A jsou na to už provařené odpovědi. Řekl bych.

351

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 25. 04. 2021, 01:46:21 »

Kód: [Vybrat]

let obj = ... // fetch somehow an object
remoteChannel <- obj
for i in range(0, obj.size) { ... }

A teď mi příjemce na druhé straně síťového kanálu změní size (řekněme, že hodnotu zmenší). Co se stane s tím for-cyklem?

Jako že za běhu cyklu změní size použitý v podmínce cyklu? Stane se IMHO to stejné jako pokud na tu size sáhnu z jiného vlákna?

Viděl bych to tak.

Některé jazyky pro foreach vytvoří kopii té kolekce (varianta optimistické transakce).

352

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 25. 04. 2021, 01:22:48 »

Co když třeba najdu objekt v kolekci, pošlu ho kanálem (CSP) na jiný stroj a tam ho změním?

Když ho pošlu tím kanálem, ztratím nad ním vlastnictví? Pokud ne, tak se mi změní v instanci, ze které jsem jej poslal, i v druhé instanci.

No právě, když chci, aby se změnil, není úplně jednoduché to naimplementovat. Teoreticky to vypadá hezky, ale všichni víme, jak spolehlivé jsou sítě.

To je jistě problém. Ale nesouvisí s mou vizí. Má vize je: udělá to engine/jazyk. Aktuální situace: musím si to naprogramovat sám.

353

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 25. 04. 2021, 01:12:10 »

Jde o styl uvažování. Dneska, díky okolnostem, je ten způsob uvažování následující:
- vytáhni z persistence
- uprav
- ulož zpět do persistence

Což je naprosto umělé. A správně by to mělo být:
- najdi v poli ^[1] požadovaný záznam
- uprav v něm co potřebuješ

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

Transakce je v pohodě, o tom není řeč. Co považuji za umělé je to vytahování odněkud a pak to tam opět vracení.

1/ úplně obyčejném, nespeciálním, v žádném ORM nasledovaném

Jo, to se mi líbí. Tak ještě jak implementovat ten commit? Tím se ta Kitova špinavá cache přesune do ... transakčního manažera? A ten si udělá tu dočasnou kopii?

Jeho boj.
Atomický blok definuje, že dokavad ty změny nejsou provedeny všechny, tak žádné vlákno, a v našem případě ani žádná další instance aplikace sdílející stav, o tom nesmí vědět.
Stejně tak, když jsou transakce zanořené.

Jako je to úplná klasika, nic nového pod sluncem. Kdo dělá s DB, tak to určitě zná. Rozdíl je v tom, že tu máme transakčnost na úrovni jazyka, a nepracujeme (explicitně) s žádnou databází.

354

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 25. 04. 2021, 01:07:22 »

Tahle tvá úvaha o transparentní perzistenci mě vrací o 15 let zpátky, kdy jsem objektové databáze řešil v projektech. Těch problémů bylo víc, třeba existence více kopií stejného objektu v paměti (tehdy ještě nebyl Rust zajišťující unikátní měnitelné reference). Třeba ty typově bezpečné dotazy se běžně řešily přetěžováním operátorů.

Pojďme si o těch problémech pokecat. Zajímá mě to.

Celá ta má úvaha je postavená na tom, že data persisteuju implicitně. Jinak všechny techniky, které známe se budou používat podobně.

třeba existence více kopií stejného objektu v paměti

Úplně nevím, v čem by měl být problém...
Pět referencí na stejný objekt? (jsme v OOP), ok, bude pět referencí na stejný objekt i v jiné instanci. Změním hodnotu v první referenci, změní se i v těch devíti ostatních.
Čtyři kopie jednoho objektu? ok, bude pět separé objektů i v druhé instanci. Změním hodnotu jednoho objektu, změní se hodnota právě toho stejného objektu v druhé instanci.

Co když třeba najdu objekt v kolekci, pošlu ho kanálem (CSP) na jiný stroj a tam ho změním?

Když ho pošlu tím kanálem, ztratím nad ním vlastnictví? Pokud ne, tak se mi změní v instanci, ze které jsem jej poslal, i v druhé instanci.

355

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 25. 04. 2021, 00:42:18 »

Právě, ta atomicita vyžaduje kód navíc, okolo jádra kódu. Co jazyk bez výjimek?

Transakce slouží k tomu, aby vytvořili atomický blok. Mohu na to vytvořit spešl syntax, nebo zneužít třeba ty výjimky. Ta atomicita způsobí, že dokud není dokončeno, tak se změna neprojeví nikde, ani v jiném vláknu té samé instance, ani v jiné instanci sdílící stejný stav.

Kód: [Vybrat]

posts = Collection<Post>
users = Collection<User>
transaction {
    author = User("John", "Dee")
    item = Post(author, "title", "content")
    item.discuss.add(Comment("author 1", "lorem ipsum 1"))
    item.discuss.add(Comment("author 2", "lorem ipsum 2"))
    posts.add(item)
    users.add(author)
}
fail (Error e) {
    console.log(e.message)
}

To jsou přejmenované výjimky

Vypadá to podobně, že jo? :-)

356

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 25. 04. 2021, 00:34:01 »

Právě, ta atomicita vyžaduje kód navíc, okolo jádra kódu. Co jazyk bez výjimek?

Transakce slouží k tomu, aby vytvořili atomický blok. Mohu na to vytvořit spešl syntax, nebo zneužít třeba ty výjimky. Ta atomicita způsobí, že dokud není dokončeno, tak se změna neprojeví nikde, ani v jiném vláknu té samé instance, ani v jiné instanci sdílící stejný stav.

Kód: [Vybrat]

posts = Collection<Post>
users = Collection<User>
transaction {
    author = User("John", "Dee")
    item = Post(author, "title", "content")
    item.discuss.add(Comment("author 1", "lorem ipsum 1"))
    item.discuss.add(Comment("author 2", "lorem ipsum 2"))
    posts.add(item)
    users.add(author)
}
fail (Error e) {
    console.log(e.message)
}

357

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 25. 04. 2021, 00:24:33 »

Takže když změním instanci objektu z jednoho procesu, co uvidí druhý proces (co by sdílel stejný stav)? Uvidí hned změnu, sdílejí stejnou instanci?

Uvidí změnněnou hodnotu toho objektu. Když změním třeba Person.name = "Jozef", uvidí taky "Jozef". Když přidám, nebo odeberu prvek z kolekce, přidá se či odebere i u toho druhého. (Případně ve všech ostatních.)

A to takhle někde jde? A není to náhodou to stejné jako když se dva klienti připojují do SQL? Taky vidí stejné hodnoty... ...až na ty okolnosti při různém transaction isolation levels. Ale pokud uvažujeme úplně netransakčně -  kdo přijde, ten čte/mění - tam můžu sdílet paměť a při každé změně objektu tam zapsat novou hodnotu a při každém dotazu ji zase číst. A třeba může být ten zápis mezi klienty synchronizovaný (takže zapisovat budou vždy jeden po druhém, nikdy současně) Neuvažuju teď změny třídy jako takové, řekněme že se jejich definice za běhu nemění a mění se jen její fieldy (datové položky - třídní proměnné). Tak takový systém určitě bude fungovat. Ale zase k čemu vlastně bude? Typicky chci načíst objekt, nějak ho měnit, validovat a až nakonec naráz uložit. Pokud to bude dělat vše hned naživo, nechám ho v rozdrbaném stavu. Chtěl jsem takhle nějak použít ZooDB a došel jsem k tomu, že to asi nechci. Teda ještě si můžu objekt naklonovat, udělat změny, validovat a pak promítnout do původní instance. Ale to už jsme u toho attachování, které jsme vlastně nechtěli. Čili při běžném aplikačním programování se skrytě obvykle uvažují cca dvě verze instance - před změnou a po změně. Je to důsledek SQL/ORM architektury nebo obecný problém? Třeba active record pattern v ebean.io nemá attach/detach sémantiku (jede v jediné persistentní session, kterou asi ani neumí opustit), ale save() tam má. A ten si nedokážu představit bez řešení kolizí a bez transakčnosti, kterou naopak ebean.io má. Takže v praxi se podle mě naráží na stejné problémy, které mi přijdou jako obecné problémy při sdílení stavu mezi více procesy. Ale jeden benefit by tam u objektové databáze byt - absence mapování. Pokud by tam byly všechna ta synchronizační bižuterie okolo a pracovalo se přímo s object graphem bez ORM mappingu, bylo by to to co asi hledám.

Jde o styl uvažování. Dneska, díky okolnostem, je ten způsob uvažování následující:
- vytáhni z persistence
- uprav
- ulož zpět do persistence

Což je naprosto umělé. A správně by to mělo být:
- najdi v poli ^[1] požadovaný záznam
- uprav v něm co potřebuješ

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

Transakce je v pohodě, o tom není řeč. Co považuji za umělé je to vytahování odněkud a pak to tam opět vracení.

1/ úplně obyčejném, nespeciálním, v žádném ORM nasledovaném

358

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 25. 04. 2021, 00:12:50 »

Hlavně tam nesmí být takové to:

Kód: [Vybrat]

entity = connection.query(anything)
entity.name = "Jozef"
connection.persist(entity)

Jak bys řešil transakce?

Vycházíš z ne úplně odůvodněného předpokladu, že to mám promyšlené.

cca takhle, asi, možná:

Kód: [Vybrat]

posts = Collection<Post>
users = Collection<User>
try {
    author = User("John", "Dee")
    item = Post(author, "title", "content")
    item.discuss.add(Comment("author 1", "lorem ipsum 1"))
    item.discuss.add(Comment("author 2", "lorem ipsum 2"))
    posts.add(item)
    users.add(author)
}
catch (Exception e) {
    console.log(e.message)
}

Transakce slouží k tomu, aby vytvořili atomický blok. Mohu na to vytvořit spešl syntax, nebo zneužít třeba ty výjimky. Ta atomicita způsobí, že dokud není dokončeno, tak se změna neprojeví nikde, ani v jiném vláknu té samé instance, ani v jiné instanci sdílící stejný stav.


Shodou okolností reálný kód na neidealistické platformě (pseudokod):

Kód: [Vybrat]

posts = Collection<Post>
users = Collection<User>
conn.transaction(conn => {
    author = User("John", "Dee")
    item = Post(author, "title", "content")
    item.discuss.add(Comment("author 1", "lorem ipsum 1"))
    item.discuss.add(Comment("author 2", "lorem ipsum 2"))
    posts.add(item)
    users.add(author)
    conn.flush(posts)
    conn.flush(users)
}, e => {
    console.log(e.message)
})

Výše uvedený kód by pak měl vypadat takto:

Kód: [Vybrat]

try {
    entity = users.find(anything)
    entity.name = "Jozef"
}
catch (Exception e) {
    console.log(e.message)
}

359

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 24. 04. 2021, 23:26:24 »

nějakému distribuovanému systému s mapováním, řešením verzí, kolizí, s attache a detached persistentním stavem atd., tedy vše co se řeší v SQL příp. ORM.

Tak přesně takto to není. Vše, co jsi uvedl je problematika čistě toho našeho nám známého řešení. A ani náhodou to není univerzální problematika. Snad jedině řešení kolizí stojí za úvahu.

Takže když změním instanci objektu z jednoho procesu, co uvidí druhý proces (co by sdílel stejný stav)? Uvidí hned změnu, sdílejí stejnou instanci?

Uvidí změnněnou hodnotu toho objektu. Když změním třeba Person.name = "Jozef", uvidí taky "Jozef". Když přidám, nebo odeberu prvek z kolekce, přidá se či odebere i u toho druhého. (Případně ve všech ostatních.)

PS: Jasně, SQL je taky způsob jak sdílet stav, ale otázka asi zněla zda to jde nějak víc napřímo.

Ani ne. Postgresql jako správce stavu může být klidně dobrý nápad. Ale je to implementační detail. Hlavně tam nesmí být takové to:

Kód: [Vybrat]

entity = connection.query(anything)
entity.name = "Jozef"
connection.persist(entity)

360

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 24. 04. 2021, 23:09:41 »

že se o to nemusel vývojář starat. Byla to vlastnost toho systému. Takže, čistě teoreticky, není problém aby si ten systém distribuovanost řešil sám, a všechno fungovalo naprosto transparentně.

Jako JavaSpaces?

Úplně dobře to neznám, ale přijde mi, že je to taky jen trochu vymazlenější Client/Server.