Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Pavel Stěhule

Stran: [1] 2 3 ... 25
1
Server / Re:Postgresql - SPI-Trigger nebo udf-funkce
« kdy: 10. 11. 2021, 04:16:17 »
Obecne bych jeste rad znal nazor, zda se to SPI programovani stale nejak vubec pouziva -> na internetu je toho relativne malo. Aby to nebyla slepa ulicka.

SPI API se normálně používá pro psaní postgresových extenzí. A pokud chcete pracovat přímo s pamětí, tak C je víceméně jediná cesta. Vlastní extenze nejsou v Postgresu něco až tak neobvyklého. Samozřejmě, že většina uživatelů nic takového nedělá, ale ti zase většinou nemusí dělat přímo s pamětí. Omezení je jediné. Vaše extenzi určitě nanajdete v cloudu, pokud byste chtěl provozovat pg jako službu.

O psaní extenzí je toho na netu docela dost. Není to nic komplikovaného, i když pro vetšinu uživatelů je to raketová věda, ale to je i lateral join nebo CTE.

2
Server / Re:Postgres - nekompletni restore pres pg_dump
« kdy: 16. 09. 2021, 08:49:57 »
pg_dump backupuje i prazdne tabulky.

Je mozne, ze originalni databaze byla poskozena, a ze pg_dump nedobehl kvuli chybe. Pripadne pg_dump mohl nedobehnout kvuli chybejicim pristupovym pravum k databazovym objektum. U pg_dumpu je vzdy (jako u kazde aplikace) sledovat result code. Duvodu proc nemusi dobehnout muze byt cela rada. Obcas se take stane, ze se backupuji jine db na jinych serverech, nez uzivatel myslel, a prijde se na to az pri restore. pg_dump je natolik jednoducha a overena aplikace, ze bych spis tipoval na nejake prehlednuti nebo opomenuti uzivatele, ale zpetne tezko rict, o co se jednalo.

3
Server / Re:Spolehlivá databáze jako náhrada Oracle AQ
« kdy: 23. 08. 2021, 09:46:07 »
Ahoj, k plne spokojenosti na jednom projektu provozujeme Oracle AQ kde pres to bez nejmensich problemu protekly miliardy msg. Ted uvazujeme o prechodu ( jako alternativu ) na jinou DB platformu.

Problem je ze nevim (resp. nenasel jsem)  jestli pro MySQL, PgSQL apod existuje neco podobneho. Nepotrebuji zadne silene HA reseni, staci mi neco co bude spolehlive frontovat jednoduche msg (enqueue, dequeue, single-consumer).

Pro PostgreSQL existuje https://github.com/pgq/pgq - roky nad tím byl postavený Skype, tak to asi bude použitelné.

4
Vývoj / Re:Rada při návrhu db tabulek
« kdy: 07. 07. 2021, 08:50:22 »

treba casto k nejake tabulce joinujete jinou tabulku s nejakou netrivialni podminkou, nad hodnotami z te jine tabulky provadite nejake netrivialni mapovani

takovych operaci je vic a chcete je ruzne kombinovat

muzete vytvorit pro kazdy pripad zvlastni pohled, nebo nechat ORM ty dotazy generovat

Jinak v SQL mám pro tento účel pohledy (kdybych chtěl udělat tyto vazby perzistentní) anebo CTE pro semi pohledy.

Ale je to jedno, jestli pohledy si vytváříte aplikačně nebo databázově. Dneska i 8 řada MySQL už umí nematerializované pohledy, takže není důvod obcházet databázi.

5
Vývoj / Re:Rada při návrhu db tabulek
« kdy: 07. 07. 2021, 08:46:08 »
ORM ma vic informaci nez schema, ma treba vic moznosti jak preddefinovat ruzne implicitni joiny.

???

treba casto k nejake tabulce joinujete jinou tabulku s nejakou netrivialni podminkou, nad hodnotami z te jine tabulky provadite nejake netrivialni mapovani

takovych operaci je vic a chcete je ruzne kombinovat

muzete vytvorit pro kazdy pripad zvlastni pohled, nebo nechat ORM ty dotazy generovat

Jasně, ale a) je to statická věc - nepodchytíte tím žádnou dynamiku, b) není to nic, co by ORM získalo samo, musí to programátor explicitně napsat - a je funkčně jedno jestli to programátor udělá ručně SQL nebo přes definici v aplikaci, a pak to SQL vygeneruje query builder.  ORM nikdy nemůže získat žádnou znalost samo. A minimálně v tuto chvíli neexistuje samoučící se (adaptabilní) ORM systém - všechno to jsou statické systémy.

Je velký rozdíl jestli píšete aplikaci vůči velké databázi s netriviální zátěží nebo s malou databází s malou zátěží. U velké databáze by měl komplexní SQL dotaz programátora "bolet". Chtěnou vlastností různých ORM systémů je maskování komplexity dotazů - jenomže to způsobuje dva problémy - umožňuje dlouhodobě pracovat s špatně navržený datovým modelem, aniž by se programátor pozvracel - ale špatně navržený datový model nutně vede k pomalým dotazům a slabému výkonu - a v pozdější době, kdy už programátor musí psát některé dotazy ručně, tak zvrací každý den, nebo striktně odmítne jakýkoliv zásah - a pak tam máte dotazy, které ručně trvají 20ms, a generované 20000ms - a pokud takových dotazů máte víc, tak hezky tavíte CPU.

6
Vývoj / Re:Rada při návrhu db tabulek
« kdy: 07. 07. 2021, 07:43:09 »
ORM ma vic informaci nez schema, ma treba vic moznosti jak preddefinovat ruzne implicitni joiny.

???

7
Vývoj / Re:Rada při návrhu db tabulek
« kdy: 07. 07. 2021, 06:50:09 »
To je tak vágně položený příspěvek, že na něj nejsem schopen šikovně reagovat. Obecně v něm tuším názorový vzor, stejně jako u @Miroslav Šilhavý, že ORM nemůže (z principu) něco vidět, co vývojář může. S tím kategoricky nesouhlasím. Jistě, jsou určité okrajové oblasti které může vědět pouze vývojář - například, že nějaká tabulka se nemá z iracionálních důvodů optimalizovat. Ale to jsou okrajové případy řešitelné natvrdo hintem. Cokoliv dokáže vývojář vyčíst z databáze, dokáže ORM vyčíst taky a to lépe.

V databázi (ve schématu) nemáte žádné informace o procesech - o tom, jak se data mění, v jakých proporcích, jak a kde dochází k zámkům, atd atd. Schéma je statická záležitost - minimálně v tuto chvíli neumí popsat dynamiku dat a dynamické (chronologické) závislosti. Schéma například neobsahuje žádnou informaci o frekvenci update, kterou já jako vývojář beru v potaz už při návrhu schématu. Jelikož sleduji vývoj zpracování statistik (práce Tomáše Vondry), tak vím, jak je náročné vysledovat něco, co není explicitně zadáno v datech databáze (například závislosti mezi sloupci, korelace mezi tabulkami). Ne, že by to nebylo technicky realizovatelné - ale ta úloha je náročná - příliš dat, příliš kombinací. Takže větu "Cokoliv dokáže vývojář vyčíst z databáze, dokáže ORM vyčíst taky a to lépe." považuji za úplně odtrženou od reality. Databáze je model, popisuje zjednodušenou realitu, a tudíž nemůže principiálně obsahovat vše, a je potřeba brát v potaz výpočetní náročnost optimalizačních úloh.

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


9
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).

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

11
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/

12
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, ..

13
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, ...

14
Vývoj / Re:Rada při návrhu db tabulek
« kdy: 28. 06. 2021, 00:23:18 »
300 dotazů na jeden refresh stránky :o  :o :o
WTF (?)
Bavíme se o jedné jediné běžné webové stránce? :o
Tři sta dotazů :o
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ů.

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

Stran: [1] 2 3 ... 25