Příspěvky

106

Studium a uplatnění / Re:Home Office po pandemii

« kdy: 02. 07. 2021, 12:06:46 »

Ale dobrý vývojář pracuje pořád - on nad řešením přemýšlí i ve volném čase, často ho nějaký nový nápad na efektivnější algoritmus napadne třeba před spaním. ...

CHACHACHACHA ...

Takovou píčovinu jsem dlouho neslyšel. Zjevně máš problém s volným časem a nejsi schopen skutečně odreagovat se. Tipl bych, že ještě nemáš ani 25 let., že Nikoho kdo si váží svého soukromého času a života by nikdy ani 1 sekundu nenapadlo nad přemýšlením o práci.  Ani Baťa za 1.republiky nic takového nechtěl, jakmile "padla" tak chtěl zaměstnanci odpočívaly aby druhý den byli odpočatí a mohly zase "MAKAT".

Jako podnikatel bych měl být za takového "týdýta" co ve svém osobním volnu přemýšlí nad prací rád ale z mého úhlu pohledu dokazuješ, že v pracovní době nemakáš na 100%.  Jinak by tě ty myšlenky napadaly v pracovní době anebo jsi tak neschopný že nedokážes usměrnovat/ovlivňovat svou mysl, soustředění tak jak to dokážou všichni schopní. Pokud platí druhá varianta pak jsi zjevně nevhodný pro intelektuální práci neboť tvá intelektuální efektivita je velmi proměnná a nepredikovatelná(tvz. random) a to je dost na hovno.

Nevzpomínám si, že bych někdy potkal špičkového programátora, který by dokázal oddělit práci a volno. Ti nejlepší programováním žijí. Což neznamená, že se nemůžete bavit - ale pokud nejste trénovaný jogín, tak nemůžete mozek vypnout, pokud vás programování baví. Pro někoho je programování práce, pro někoho výzva a hra. Je to stejné jako v jiných oborech - můžete být kameník a dělat schody, nebo můžete se dostat na jiný level, a být sochař a dělat sochy. Programování může být řemeslo, ale může to být i úžasná výzva a snaha o hledání dokonalosti. Ti nejlepší svojí prací žijí, a musíte tomu něco obětovat - minimálně spoustu času. Je to pak vidět - je rozdíl jestli hrajete světový pohár nebo okresní přebor.

107

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 01. 07. 2021, 22:03:51 »

SQL ale optimalizuje pouze jeden dotaz - už neoptimalizuje sekvenci příkazů. Tam se předpokládá invence programátora. Někdy se vám vyplatí načíst data do RAM aplikáče, a pak nad touto RAM dělat komplikovanější operace. Jindy iterujete po řádcích, jindy agregujete, a gró výpočtu udělá databáze a na aplikáč se posílá jen výsledek. Optimální strategii volí programátor se znalostí dat, a znalostí procesu - ví k čemu data bude používat, a kde je potřebuje.

Optimalizace na úrovni SQL ale fungují cca na 70 procent, tak jak fungují statistiky a odhady. Statistiky ale nejsou přesné, a tudíž nejsou přesné odhady. Máte korelace v datech, fyzicky data nejsou rovnoměrně uložena v tabulkách. Někdy dochází ke změně charakteru statistik v čase (což statistický model vubec nedokáže zpracovat). Modelovat se dá velice přesně, ale to vám dost pálí výkon - a ten při optimalizaci dotazu nemáte. Takže chca nechca musíte přidávat dodatečnou informaci, tím jak píšete SQL (ať už jsou to hinty, nebo  použité konstrukce, nebo sekvence příkazů). Pokud je ale databáze navržená pro ORM, tak programátoři nemají znalosti, chybí jim odvaha do kódu sahat, chybí jim zkušenost, a fakt to hodně dře. U větších aplikací (u malých to není problém), pak musíte řešit jednak výkon SQL, a také výkon ORM (pokud jej používáte).

108

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 01. 07. 2021, 21:44:51 »

Jak jsem psal výše, mě zajímají principy. To, že aktuální ORM nejsou ve stavu, kdy by to všechno fungovalo krásně out-of-the-box, to je mi jasné, uvědomuji si to, a uznávám. Ale považuji to za otázku vývoje, nikoliv za principielní problém. Ano, já si pamatuju dobu, kdy to lidem stálo za to a v Delphi psali pasáže v asm.

Takže děkuji za jakékoliv příspěvky, které popisují principielní potíže, se kterými se musí ono ORM vypořádat.

Principiální problém je samozřejmě s výkonem. Tím, že ORM neběží na databázovém serveru, ale na aplikačním, tak máte výrazně větší režii při přístupu k datům (režie sítě, režie protokolu, různých vrstev). Zvlášt u extrémně rychlých dotazů (dotazy, které vrací, modifikují pár řádků nad PK), je tato režie hodně vysoká. A v podstatě pak hrdlem je síť a pálíte výkon konverzí dat a realizací komunikace. Můžete si pomoct aplikační cache. Pokud ale máte víc dat, tak se nevejdete do RAM na aplikáči, a a musíte implementovat ACID nad ACIDem, což zase zvyšuje komplexitu nástroje. Implementace distribuované transakční cache je dost komplikovaná záležitost. Zvyšuje se výkon CPU, zvyšují se přenosové rychlosti, IOPS SSD jsou někde úplně jinde, ale na druhou stranu, roste objem dat, klesá trpělivost uživatelů (nikdo nechce čekat na výsledek minuty), a klesají znalosti programátorů (mění se znalosti programátorů - znají ORM, patterny, buildovací prostředí, a virtualizaci), ale neznají základy toho jak fungují databáze (což dřív také nebyla žádná sláva, ale teď to mají k databázím dál). Tudíž si myslím, že posledních 15 let, jsou u větších projektů stejné problémy (i přes brutální nárůst výkonu).

Další problém ORM je odtržení statistik. Sice mohou mít datový model (a mají), ale nemají statistiky, jak data ve skutečnosti vypadají. V ideálním případě by možná tuto znalost nepotřebovali, kdyby existoval ideální optimalizátor dotazů. Už jednoduchá úloha je docela komplikovaná - rozhodnout, jestli si inicializovat cache blokově (napřed si stáhnu potřebná data) nebo iteračně. Pokud budete mít statistiky na aplikáči, tak duplikujete funkcionalitu db, a navíc asi statistiky budete mít jen z cache (nikoliv ze všech dat). Co vím, tak většina ORM statistiky o datech nemá, proto dynamicky nedokáže měnit strategie zpracování dat (nedokáže se přizpůsobit datům). Relační SQL databáze se o to snaží - máte 3 typy JOINů, máte seq scan, index scan - a optimalizátor hledá způsob, jak co nejrychleji přenést data z disku a jak přitom spotřebovat co nejméně paměti.

SQL ale optimalizuje pouze jeden dotaz - už neoptimalizuje sekvenci příkazů. Tam se předpokládá invence programátora. Někdy se vám vyplatí načíst data do RAM aplikáče, a pak nad touto RAM dělat komplikovanější operace. Jindy iterujete po řádcích, jindy agregujete, a gró výpočtu udělá databáze a na aplikáč se posílá jen výsledek. Optimální strategii volí programátor se znalostí dat, a znalostí procesu - ví k čemu data bude používat, a kde je potřebuje.

109

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 28. 06. 2021, 11:48:58 »

Doplněni: Je skvělé, že tu diskutujete. Ne každý někdy viděl implementovaný fraud detection.

Takových systémů bude mraky - co jsem se bavil s lidma, kteří detekce anomálií používají Postgres, tak existuje detekce komunikace na síti, detekce pohybu osob po budovách, automatická analýza databázového auditu, .. dokonce v novějším ANSI/SQL je pro to funkce - analýza vzorů změn

https://fosdem.org/2021/schedule/event/postgresql_postgres_and_the_artificial_intelligence_landscape/

110

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 28. 06. 2021, 11:20:45 »

fraud detection, ...

Můžete rozvést vzorovou implementaci? Pokud bych provedl úspěšný SQL injection, tak mi to nepomůže ne? Já v jedné aplikaci transakce hashuji.

Tady nerozumím otázce - fraud detection primárně neslouží k detekci SQL injection, i když by to asi mohlo detekovat úspěšný průnik (analýzou auditu). Co myslíte pod "hashováním transakcí" ? Ochranou proti SQL injection je důsledná a správná sanitizace všech parametrů dotazů, případně striktní používání prepared statements nebo parametrized statements. Pak je další kapitola minimalizace impaktu kompromitace účtu - ať zaheshováním citlivých údajů nebo používáním standardních security fíčur databáze - víc uživatelů, přístupová práva, maskování hodnot, ..

111

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 28. 06. 2021, 10:51:14 »

Tak samozřejmě, takovou trivku jsem na mysli neměl.

a co jste mel na mysli? Kdy se podle vas pouziva ORM pro dotazovani v cyklu?

exporty, generovani analytickych reportu, biling,  fraud detection, ...

112

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 28. 06. 2021, 00:23:18 »

300 dotazů na jeden refresh stránky  
WTF (?)
Bavíme se o jedné jediné běžné webové stránce?
Tři sta dotazů
Jako vážně?
Ale to uvádíte jako příklad enormní ouchylnosti ne?

Samozřejmě, že je to extrém - ale ve své době to byla relativně rozšířená aplikace (rok 2009). Firma, kde jsem tehdy pracoval ji používala pro správu tiketů (takový centrální mozek), a pro 300 zaměstnanců už to byl brutus. Nakonec se ukázalo, že největší průser byl vlastně samostatný dedikovaný server - a síťové latence. V tomhle počtu už to dělalo hodně. Paradoxně pomohlo dát na jeden server apache, i databázový server, a zbavit se režie sítě. Nicméně viděl jsem i nějaké portály - které na refresh stránky generovaly vyšší desítky dotazů a bez cache to pro vyšší návštěvnost (v rámci ČR) nedávalo. Na druhou stranu, zrovna oni pak jednoduchou cache vyřešili 95% přístupů.

113

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 27. 06. 2021, 22:51:02 »

Databáze jsou úzké hrdlo, protože spousta lidí je neumí používat. Dejte mi příklad, kde je úzkým hrdlem databáze, můžeme si k tomu napsat.

temer libovolna webova aplikace s vetsim provozem a vypnutym cachovanim, treba i tohle forum, kdyby tu bylo vetsi mnozstvi diskuteru. Netvrdim, ze preneseni aplikacni logiky na server ma vzdy nejaky zasadni negativni vliv, ale urcite neplati opak (databaze je vzdy efektivnejis) jak tvrdite vy.

Cache je dobrá - zvlášť pro webky, které na jeden refresh stránky vygenerují 300 dotazů. Co jsem už také viděl. Dnešní servery dávají cca 3000 - 6000 dotazů za sec na 1  CPU vlákno. Takže, když máte server, který má 32 vláken, tak bez problémů zvládnete 20-40 000 dotazů za sec (většinou tyto web aplikace generují primitivní dotazy).  Nicméně aktivní cache pro web aplikace (pro stránky) je důležitá - ušetříte jednak dotazy, druhak hromadu operací se řetězcema (a navíc se většinou dobře cacheuje).

U databázových aplikací ale většinou negenerujete interface, a také dost často nemůžete použít cache - ale většinou vygenerujete na obrazovku 10 dotazů - a tam pokud neděláte nějaké šílenosti, tak běžné servery utáhnou bezproblémově aplikace pro střední evropu.

114

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 27. 06. 2021, 22:35:37 »

Jinak třeba přenos dat mezi klientem a serverem má také dost velkou režii - lokální výpočet může být v nanosec, výpočet na aplikačním serveru s execem jste v nejlepším případě na desetinách milisec.

pridani validaci na klientu naopak snizi prenos dat mezi klientem a serverem (nevalidni data se na server vubec nedostanou).

jinak databaze je uzke hrdlo temer u vsech aplikaci s trochu vetsim trafikem.

Kontrola na aplikační straně má tu nevýhodu, že se dá "snadno" obejít, zapomenout, ... db server side kontrolu vám nikdo neobejde. Jinak není na škodu mít kontroly implementované 2x - pro interaktivní práci různé validátory na klientovi, a pak na databázové straně, která vám garantují kvalitu dat.

Samozřejmě, že databáze je u databázových aplikací hrdlem - čekáte na disky, případně na zámky, ale to budete čekat tak jako tak. Když ale přidáte správně indexy, tak dnešní servery bezproblémově utáhnou desítky tisíc uživatelů. Před dvěma měsíci jsem pro jednoho zákazníka pomáhal doladit databázi, která měla něco kolem 200GB, a 10K současně pracujících uživatelů nevygenerovalo znatelnou zátěž na CPU. Po přidání správných indexů - trhnul jsem rekord - dotaz jsem zrychlil 10 000 krát.

115

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 27. 06. 2021, 22:06:52 »

Zrovna tyto operace chcete přenést do databáze, protože zrovna na nich je řádově efektivnější.

databaze je vetsinou uzke hrdlo aplikace, aplikacni kod lze snadno horizontalne skalovat.

Pokud nebudete počítat bitcoiny, tak drtivou většinu operací můžete bezproblémově počítat v databázi. Úzkým hrdlem jsou diskové operace, případně přístupy do RAM. CPU většinou u běžných OLTP aplikací se fláká. Jinak třeba přenos dat mezi klientem a serverem má také dost velkou režii - lokální výpočet může být v nanosec, výpočet na aplikačním serveru s execem jste v nejlepším případě na desetinách milisec.

116

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 27. 06. 2021, 21:24:02 »

doporucuji se podivat na http://docs.peewee-orm.com/en/latest/ , coz je podle me ORM udelane spravne, pripadne SQLAlchemy

Trochu mi uniká výhoda. Místo toho abych napsal exec("SELECT ..."), tak píšu cn.select("tablename").where(...)

Tyhle query buildery jsou asi bezproblémové (je to jen manipulace se stringama), jen mi to příšlo jako řešení, aby se vlk nažral (v aplikaci se mi nevyskytuje SQL) a koza zůstala celá (v podstatě programátor musí napsat kompletní SQL).

117

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 27. 06. 2021, 21:17:43 »

Jakmile programátor použije cyklus (protože je tak zvyklý a dobře se mu tak uvažuje a pracuje), tak těžko už ORM může převést tuto operaci na hromadný SQL příkaz.

to podle me v modernim SQL moc nepotrebujete, jde to nahradit window funkcemi

treba ten vas priklad s okresy bych v peeewee napsal nejak tak

Kód: [Vybrat]

class City(Model):
    district = IntegerField()
    inhabitants = IntegerField()

CityAlias = City.alias()

subquery = (CityAlias
            .select(
                CityAlias.district,
                CityAlias.inhabitants,
                fn.ROW_NUMBER().over(
                    partition_by=[CityAlias.district],
                    order_by=[CityAlias.inhabitants.desc()]).alias('rn')))

query = (City.select(subquery.c.district, subquery.c.inhabitants).from_(subquery).where(subquery.c.rn <= 10))

print(query)

vygeneruje takove SQL

Kód: [Vybrat]

 SELECT `t1`.`district`,
       `t1`.`inhabitants`
FROM   (
                SELECT   `t2`.`district`,
                         `t2`.`inhabitants`,
                         ROW_NUMBER() OVER (PARTITION BY `t2`.`district` ORDER BY `t2`.`inhabitants` DESC) AS `rn`
                FROM     `city`                                                                            AS `t2`) AS `t1`
WHERE  (
              `t1`.`rn` <= 10) 

kdybych do toho zacal pridavat nejake joiny, tak ten ORM kod bude kratsi nez generovane SQL, navic si v ORM mohu napsat obecne funkce na vytvareni podobnych dotazu

Tohle je jen použití query buildru. Z mého pohledu je to jen jiné API pro execnutí dotazu. Sice jste explicitně nenapsal SQL, zavolal jste metody, které jednoduše vygenerují SQL. V podstatě jste napsal SQL v bledě modrém. Tady není nic, co by dělalo problém. Problémy jsou při iteraci nad kolekcí komplexnějších objektů, které ORM samo načítá, případně samo serializuje.

118

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 27. 06. 2021, 07:36:28 »

Já nemám zájem řešit, že ORM jsou nekvalitně napsané, a díky tomu jsem schopen napsat lepší dotaz pomocí čistého SQL.
Já nemám zájem řešit, že i dnešní nekvalitní ORM jsou v některých situacích výhodnějších.
Mám zájem řešit, že zda dokáže stroj vytvořit stejně kvalitní dotaz do relační databáze jako člověk; to ale nemáš zájem řešit ty.

Tudíž za mě všechno.

To, že ORM dokáže vygenerovat kvalitní dotaz bych si asi dovedl představit. U ORM vidím, ale i jiné problémy. Tím prvním je, že těžko může ORM vyřešit ISAM (iterační zpracování dat). Jakmile programátor použije cyklus (protože je tak zvyklý a dobře se mu tak uvažuje a pracuje), tak těžko už ORM může převést tuto operaci na hromadný SQL příkaz.

Některá ORM si drží vlastní cache - patrně aby urychlily provádění cyklů nad daty. K tomu potřebují vlastní transakční manager a vlastní lock manager - to už je docela brutálně komplexní, a pokud se to začne nějak tlouct s transakčním a lock managmentem v databázi, tak je to dost komplexní, křehké a programátoři do takových systémů odmítají sáhnout.

Dovedu si představit ideální ORM - ale aby ho někdo uměl správně používat, tak stejně musí hodně do hloubky rozumět SQL a relačním databázím, a u složitějších aplikací komplexnost ORM je brutální. Kdyby si programátoři napsali vlastní vrstvu pro operace a procesy, tak ve výsledku si ušetří mraky času a nervů.

Dost často se napíše prototyp nebo aplikace verze 1.0 s ORM - funguje to nad demo daty a funguje to pro menší zákazníky s pár set uživately a pár desítky GB. Pak se firmě povede protlačit produkt do nějakého většího korporátu (což je byznysově ideální), ale máte  stovky tisíc uživatelů, mnohem větší databáze, a rok - dva se řeší tuning, sizing, s většími nebo menšími úspěchy - spálí se na tom mraky hodin, a pak se napíše verze dvě bez ORM - s výkonem o 2-3 řády vyšším. Ale ten přepis stojí peníze, a nikomu se do toho moc nechce, protože už se spálilo mraky peněz na customizacích, tuningu, horizontálním škálování, ...

ORM fungují pro menší data, pro data, kde nikdy nebudete dělat hromadné operace. V opačném případě jsou s tím pekelné problémy, a to co ušetříte na programování, to 10x zaplatíte na supportu, tuningu, a řešení různých performance issue

119

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 25. 06. 2021, 17:06:51 »

SQL je poměrně primitivním dotazovacím jazykem, Kit měl asi na mysli PL/SQL. To je taky primitivní jazyk, stačí si uvědomit, že nemá jakékoliv složitější datové struktury (např. něco jako struct/record, seznamy!), pouze primitivní typy, takže např. volání procedur či funkcí s nějakým obsahem v parametrech je zoufalé, jakákoliv práce se seznamy znamená opakované čtení dat z tabulek. Ladění otřesné. Vlastně ani žádnou podobnost s vyššími jazyky nevidím.
Naproti tomu vždy jde vytvořit nějaké ORM, které jedním příkazem s pár parametry provést (různě) složitou operaci s mnoha dotazy SQL a jejich sestavením na pozadí. Ale to ORM musí nejdřív někdo vyvinout.

To jste úplně mimo - PL/SQL je přebrandovaná ADA, rozšířená o embedded SQL

https://en.wikipedia.org/wiki/Ada_(programming_language)

Který z výše uvedených problémů to řeší?

PL/SQL je plnohodnotný jazyk - podporující struktury, kolekce, kolekce kompozitních typů, globální proměnné. Takže jednoduše si můžete uložit seznam id, i seznam kompozitních hodnot. A můžete s nimi pracovat v PL/SQL, tak i v SQL. Kolekce je dictionary, hash tabulka, takže můžete dělat rychlé lookupy. I mnohem primitivnější T-SQL má inmemory tabulky - což jsou defakto pole kompozitních hodnot - a PL/pgSQL má pole jak skalárních hodnot, tak kompozitů - a existují konstrukce pro úzkou integraci s SQL. Je to mnohem efektivnější než z aplikačního serveru, protože nepřesouváte data po síti. Jinak, co PL/SQL umožňuje přenášení parametrů odkazem, co je samozřejmě rychlé. V Postgresu znám implementaci - všechny větší objekty se předávají funkcím přes ukazatele. Pouze, když je modifikujete, tak se vytváří kopie.

Jinak ke všem mně známým jazykům uložených procedur existují debuggery. Debugování je úplně v pohodě.

V podstatě nic z toho, co tu píšete o uložených procedurách není tak posledních 20 let pravda.

120

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 25. 06. 2021, 14:45:09 »

SQL je poměrně primitivním dotazovacím jazykem, Kit měl asi na mysli PL/SQL. To je taky primitivní jazyk, stačí si uvědomit, že nemá jakékoliv složitější datové struktury (např. něco jako struct/record, seznamy!), pouze primitivní typy, takže např. volání procedur či funkcí s nějakým obsahem v parametrech je zoufalé, jakákoliv práce se seznamy znamená opakované čtení dat z tabulek. Ladění otřesné. Vlastně ani žádnou podobnost s vyššími jazyky nevidím.
Naproti tomu vždy jde vytvořit nějaké ORM, které jedním příkazem s pár parametry provést (různě) složitou operaci s mnoha dotazy SQL a jejich sestavením na pozadí. Ale to ORM musí nejdřív někdo vyvinout.

To jste úplně mimo - PL/SQL je přebrandovaná ADA, rozšířená o embedded SQL

https://en.wikipedia.org/wiki/Ada_(programming_language)