PostgreSQL 15 Beta 1

PostgreSQL

Tesztelhető a népszerű, nyílt forráskódú adatbázis-kezelő, a PostgreSQL 15-ös kiadásának első bétája. Az újdonságokról a kiadási megjegyzések dokumentum ad tájékoztatást. Bejelentés itt.

( hory v | 2022. 05. 19., cs – 20:52 )

Vajon mikor jut el oda az atlag dev, hogy excel tablakat bonyolult modon join-olgatni jocskan macerasabb, mint ugyanazt az adatot egy fa adatszerkezetben (json,yaml) tarolni rogton?

Iszonyat boilerplate van a sql alapu DB-k szerver oldalan, kivetel nelkul.

Az Excel számolótáblákat biztosít neked, ráadásul reaktív módon. Ha egy input megváltozik, akkor a tőle függő cellák is. Az SQL teljesen más téma, relációkról van ott szó, a relációk közötti kapcsolatokról, az azokban definiált megszorításokról.

 

Persze mindkettőt lehet kockásfüzetként használni, sor-oszlop nyilvántartásokra, de egyik sem arra való. Arra a kockásfüzet való. Vagy a CSV.

sql-ben is van trigger.

az excel tablazat egy pelda volt, hogy mennyire osdi modszert is hasznalunk. konkretan egy excel tabla/csv kevesbe merev, mint egy sql tabla; elobbiben nincs kotott schema ugyanis.

es erre epitkeznek, mint adattarolasi modszerre az IT-ban legtobb helyen.

ez gaz.

Igen. Van az a komplexitási szint, ami ha a db-t használó dev oldalán jelenik meg, akkor hiába tud sokat a szoftver, az esetek nagy részében kerülni fogják és egy memória struktúra betöltése és kiírása egyben tényleg sokkal egyszerűbb lesz sok feladatra. Főként hogy változott a hardver is. Szinte már nem probléma a gigás adat méret memóriában és ágyúval verébre lövésnek tűnik a relációs db kisebb cuccokhoz.

Kár, hogy nem belsőleg növelik a db motorok a komplexitást külső helyett. Értem ez alatt, hogy maradjon ugyanolyan kívülről évtizedekre és okosítsák belülről modern matematikai optimalizációkkal. Így nagy gravitációja lehetne a piacon ebből a sajátos szemszögből és vonzó lehetne a hosszú távon bebetonozott külső működés. De nem ez történik, hanem általában mindig a fordítottja, mert az az egyszerűbb. Ez sok szoftver szintjén megfigyelhető érthető okokból.

Ráadásul túl gyors a felépítés változása. Mindenki előre rohan, mutogatva a sok újítást. Persze jók a feature-ök, de ami igazán ütne - és ezt sokan nem látják - az a sokkal bátrabban sokkal egyszerűbbre tervezett működés és kommunikációs protokoll. Ezt nem merik meglépni sokan sajnos.

alapvetoen, amit irtam, az szinten 'kulso' komplexitas. az igazsag az, hogy a feladatok 99%-ara kb. egy sima index eleg. az a szintu komplexitas, amivel egy sql db jon, teljesen felesleges.

emelle jon, hogy igazabol a legtobb devnek lovese sincs, mi tortenik egy sql db-ben. mar siman a sql megtanulasa kihivas, plane egy komplex ORM. kovetkezmeny:

- lassu es bugos development alatt
- lassu es bugos futasidoben
- par ev alatt osszevissza lesz hack-elve, mert adat migracio sql alatt egy remalom, ugyhogy meghagyjak a regi schema-t es azt hekkelgetik evekig

 

... es nem megy at, hogy ez igy szar, csinaljak tovabb

 

most ez nem a psql-rol szol - a psql azt teszi, amire programoztak, es egesz hatekony kis cucc amugy. de hasznalni tudni kell, ahogy par nosql DB ismerete is teljesen alapveto igy anno 2022.

+ az adatbázis fejlesztők telibe leszarják devops felől az egészet.

Vagy csak én nem tudok olyan egyszerű db-t ami opensource, többgépes replikációt, snapshotot tartlamaz úgy, csak meg kelljen adni a többi géphez a tokent és a többit elintézi? (Tehát a terheléselosztást, adatduplikációt, uram bocsá automata index létrehozást vagy javaslattételet)

Ha már ORM, és erős gondolatok: a JPA szerintem az egyik legnagyobb baklövés a Java világban (közvetlenül "a garbage collectionnél nem kell törődni a memóriakezeléssel" marketingszöveg után). Az a remek ötlet, hogy megpróbálunk úgy tenni, mintha a DB-ben levő adatok egy in-memory objektumgráf lennének, mindezt persze "trükkök százaival", kezdve bytekódinstrumentálással, nagyon durván bevitte az ipart az erdőbe úgy 10 - 15 évre és szerintem milliárd USD nagyságrendben lett kidobva a pénz a semmire. 

Elkezdtem leírni, hogy hogy kellene jól megcsinálni, de rájöttem, hogy sok idő lenne, meg persze konkrétumok birtokában sokkal kevésbé élvezetes a flamelés... :)

Szerintem kicsit fordítva lovon ülés esete forog fenn. A JPA-nál nem az a cél, hogy adatbázis jelenjen meg mint objektumgráf, hanem fordítva. Objektumokat mint perzisztens entitásokat (DDD szerint) tudjunk kezelni, nem foglalkozva azzal, hogy az alacsony rétegben lévő adatbázisban ez hogyan valósul meg valójában. Nem adatbázist építünk, ami fölé felhúzunk egy objektum-réteget, hanem van egy objektummodellünk, amely objektumok állapotát két programfutás között perzisztálni akarjuk. Strukturált adat perzisztenciára a relációs adatbázisok kéenfekvők, nosza, csináljuk.

Az öntökönlövés az volt, amikor ez a gondolat felborult, és mindenki elkezdett fordítva ülni a lovon, majd jött mindenféle kényelmetlen dolog, Criteria API, metamodel és társai. Amikor az adatbázis strukturális elemei (indexek, szekvenciák stb) elkezdtek megjelenni az objektumgráf absztrakciós szintjén, ott romlott ez el.

Strukturált adat perzisztenciára a relációs adatbázisok kéenfekvők, nosza, csináljuk.

hogyan?

strukturalt adat perzisztenciara pont, hogy abszolut nem jo. strukturalt adat json/yaml -szeru fa szerkezetbe perzisztalhato kenyelmesen, mint a document store/nosql DB-k.

azert olyan fajdalmas az ORM es a SQL generalisan, mert strukturalt adatot elobb szejjel kell szabdalni tablazatokra, aztan meg valahogy osszekapcsolni ujra, hogy mukodjon. es mindezt jol megfejelik egy teljesen merev schema-val, hogy meg nehezebb legyen mindenfele valtoztatas.

es ez senkit se zavar. dev-ek tobbsege elvan vele. indoktrinacio vagy ignorancia?

A strukturált adattal ott jön képbe a relációs adatbázis, hogy az egyes objektumok legtöbb esetben rengeteg hivatkozást tartalmaznak más objektumokra, sokszor ugyanazt az objektumot sok más meghivatkozza. Ezt a hierarchikus DB-k úgy jó 15-20 évvel ezelőtt még nem, vagy csak nagyon korlátozottan kezelték. Relációs adatbázisban pedig a kulcsok használata mindig is triviális volt. Objektumgráf van, nem objektumfa. 

 

A merev séma nem tudom miért probléma, az objektumok felépítése egy osztályon belül nem változik. Rossz is lenne, ha egy osztály példányai eltérő struktúrával rendelkeznének. 

jol csinalni? IMHO vegletesen egyszeru, 2 alapveto dologra surusodik ossze:

- kritikus gondolkozas;
- torodes/odafigyeles.

nem csak a dev-ek, az emberek tobbsegenek egyik vagy mindketto hianyzik. aztan lehet, hogy elvegez egy egyetemet, megtanul ezt-azt, de jo dev, na az sose lesz. jo munkaero se, ha mar itt tartunk.

iszonyu keves ember van, akinek mindketto megvan. pedig nem nehez dolog ez.

Ez tökre fasza, ha van egyértelmű tartalmazásviszony az elemek közt, nem csak “osztozkodnak” egymáson (kompozit helyett aggregált kapcsolat), mert akkor ezt kb. bszhatod.

Még ha egyetlen dokumentum is van, néha lekérdezni egyszerűbb star schema alapján, mintha egy nagy fában keresnéd a tutit.

persze vannak graph adatbázisok, meg dokumentum alapú adatbázisok, de az a tapasztalat, hogy a dokumentum-adatbázisokból előbb-utóbb hiányozni kezd a tábla szerkezet, és elkezdenek először mindenféle workaroundot kitalálni rá, majd visszaállnak SQL-re.

Ja, hát ott elterjedt, nem mellékesen leimplementálják a fél Oracle-t NodeJS-ben (ld. Microservices patterns könyv, nagyon tudok röhögni, amikor elmondja, hogy ezt akkor használd, ha nem lehet 2-phased commit, majd bemutat egy 2-phased commit implementációt átnevezve, a DB helyett az imperatív nyelven). 

Én még fiktív SQL-ben írom a query-ket, hogy a programozók hogy dobálják szét, az nekem másodlagos, a fontos, hogy implementálás előtt tudja, milyen query-k fognak naponta százezerszer lemenni rajt, és vegye figyelembe szétszedéskor.

Amikor nagy ritkán nálam kötnek ki adatbázisok, azok még mind óriási SQL behemótok voltak a kezdeti (2008-2012 mondjuk) fellángolást követően, de valószínűleg azért is köt ki nálam, mert nincs rájuk táblánként egy team, aki simogassa :)

( gelei v | 2022. 05. 20., p – 10:17 )

subscribe, mert igen erős gondolatok vannak már most is a threadben :)