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 ... 26
1
Server / Re:Co už je v MariaDB veliká tabulka?
« kdy: 14. 01. 2022, 14:12:30 »

To i MyISAM umí indexy :-)

Samozřejmě ;), měl jsem napsat "umí pořádně indexy", narážel jsem na vylomeniny se správným nastavením key_cache_block_size a key_cache_size podle velikotí .MYI souborů a běžné velikosti vrácených datasetů, ve výchozím nastavení hodnoty byly příliš malé a u velkých tabulek dělaly dost podstatné problémy, už je to ale hodně dávno. Jen jsem odhadoval podle čeho oss odvozuje, že MySQL nezvládá více než 10k řádků.

To bych tipoval, že je ironie. Obecně se bere 10K řádků jako limit pro ještě funkční aplikaci nad špatně navrženou databází nebo pokud chybí indexy. Do 10K řádků jsou i ty fullscany stále ještě dostatečně rychlé. MySQL i MariaDB bezproblémově zvládnou desítky, možná stovky miliónů řádků. A to zvládnou všechny databáze. Co se liší je chování. Rychlost zápisů, rychlost čtení, zpracování jednoduchých SQL, zpracování komplexních SQL, provoz při 1 nebo 10 nebo 100 vkách uživatelů, atd atd.

2
Server / Re:Co už je v MariaDB veliká tabulka?
« kdy: 14. 01. 2022, 13:01:00 »
Ono sa lisia viac menej v nazve.

kdy naposledy jsi ty databáze viděl? Po několika letech práce Oraclu na MySQL 8 bych mu neříkal, že se to pořád liší jen v názvu. Rozdílů je tam už více než dost, nemluvě o tom, že se nám rozrostl počet dostupný enginů.

Všiml jsis, že tady máme InnoDB, které umí indexy a nikoliv jen MyISAM?

To i MyISAM umí indexy :-)

3
Vývoj / Re:Normalizace databáze
« kdy: 13. 01. 2022, 11:57:40 »
Jaky stupen Normalni formy rika, ze se to tak nesmi delat?

Tohle neřeší normalizace, ale transaction isolation levels

4
To by som asi dlho nevydrzal. Takze moja rada je utekat.

Presne odhady na tickety sa davaju vylucne iba na kod ktory velmi dobre poznam a robim s nim kazdy den ale aj tam sa vzdy zapocitava rezerva na "prestoje". Dost casto sa mi stavalo, ze som musel kontaktovat a komunikovat so zakaznikom co mi casto zobralo kludne aj cez 30-40% rozpoctu pretoze raz nemal cas, potom sa nevedel rozhodnut ked sa nieco prehodnocovalo a pod. V kazdom pripade to vzdy zerie cas, takze si treba davat "casovu manazersku prirazku". Ak robim s kodom, ktory nepoznam tak odhady jednoducho nedavam. Klamal by som bud seba alebo zakaznika. Skor to robievam ze si dam nejaky mensi budget na analyzu stavu a ak to dopadne OK tak idem na dalsi mensi budget a ono sa to bud naimplementuje alebo implementacia zlyha cim ale zakaznik nepride o vela penazi a ja nemusim zo seba robit hlupaka.

Dělám to zrovna tak. Když pracuji na kódu, který je hodně experimentální, což je většina mých projektů, tak se domlouvám se zákazníkem na určitých etapách, přičemž je tam i možnost, že nenajdu řešení, a každá etapa má svůj "rozpočet". Mám pocit, že je to asi jediné korektní řešení. Se zákazníky se kterými pracuji trvale, a známe se, tak tam už řeším jen odpracované hodiny (ale spolupracujeme 10 let a je tam už nějaká důvěra). Napsat prototyp patche do pg nebo privátní extenzi je záležitost týdne. Dostat ale nějaký kód do upstreamu může trvat bohužel i roky (samozřejmě nejedná se o čistý čas). A většina času padne na maily, lobbing a aktualizaci patchů - není to jen vlastní programování. Ale čas to zabere a stojí to peníze (i když to není tak intenzivní jako vlastní vývoj).

5
Studium a uplatnění / Re:Lhaní recruiterů
« kdy: 11. 01. 2022, 08:08:26 »
Ak to po mne chcu, tak fajn, ale ja chcem potom za kazdu z tych cinnosti mzdu adekvatnu danej pozicii kde zapadaju tieto cinnosti, lenze to je nonsens samozrejme.

To je nonsense hlavně pro vás, protože tyhle pozice mají typicky nižší mzdu, než programátor. Takže byste dostal třeba 0.9 úvazku programátora a 0.1 úvazku admina, což by bylo méně, než 1 úvazek programátora ;)

Kdykoliv jsem byl zaměstnaný, tak jsem měl pevnou hodinovou mzdu + prémie (prémie v dobrých časech, takže si moc nevybavuju, že bych je kdy dostával - možná 2x jsem dostal 13 plat (roční bonus v GD)). Nikdy nebylo řečeno, že jako programátor bych dostával x a jako admin y. A pokud by mne firma (proti mé chuti) víc používala jako admina, tak je to primárně mínus té firmy, protože jako programátor jsem samozřejmě v roli admina méně efektivní). Já osobně jsem dostával peníze stejné.

V low cost firmách je možná trend, že se přesně vykazují minuty, a přesně činnosti. V IT jsem už od 91 roku, a když vidím něco takového, ve smlouvách, v provozu, tak je to hodně varující signál. Většinou jsou tam špatné peníze ve špatných podmínkách. Dobrý management dokáže zajistit dost peněz nebo alespoň nebuzerující podmínky. Peníze nejsou všechno, znám firmy, kde peníze (na IT nejsou hvězdný), ale máte tam pohodu, a když uděláte svoje, tak vás nikdo nebuzeruje (a také to funguje). Pořád vůči průměrnému platu, to jsou nadprůměrné peníze. Co je nejhorší, když máte malé peníze a ještě vás buzerují. Tam je nutnost co nejdřív odejít (ideálně ve zkušebce nebo po roce). To je pak opravdu o zdraví. Pod neschopným managmentem nemáte šanci si vydělat slušnější peníze, nic se nenaučíte, a ještě to oser.

6
Studium a uplatnění / Re:Lhaní recruiterů
« kdy: 10. 01. 2022, 21:10:46 »
Skutocne by ma zaujimalo ako to vnimaju ostatni to zahrnanie vyvojarov nesuvisiacov pracou s touto poziciou. Mozno je problem u mna (mozno som neschopny), ale skutocne som teraz presvedceny, ze softverovy vyvojar ma hlavne vediet programovat, navrhove vzory, best practices, vediet osetrit maximum chyb sposobom ktory dava zmysel, vyznat sa vo frameworkoch, poznat svoj jazyk do hlbky atd. Rozhodne si nemyslim, ze napr. je normalne od C++ alebo Java programatora ocakavat, ze vie databazy v zmysle ich nasadenia, odhadov kolko HW bude potreba atd. Rovnako si nemyslim, ze pre vyvojara je normalne starat sa o infrastrukturu, riesit nejake balickovanie, kontajnery atd. Ak to po mne chcu, tak fajn, ale ja chcem potom za kazdu z tych cinnosti mzdu adekvatnu danej pozicii kde zapadaju tieto cinnosti, lenze to je nonsens samozrejme.

V menších firmách to vše vývojáři musí zvládnout. To, že programátoři jsou někdy příliš odizolovaní od provozu (hardware) pak vede k tomu, že program sice běží, ale administrace je nepraktická nebo je neadekvátně hw náročný. Striktní rozdělení na adminy, programátory, a architekty je dost šílená korporátní zrůdnost podmíněná potřebou zastupitelnosti a bezpečnosti, ale občas to může být dost šílený. Viděl jsem programátory, kteří programovali podle zadání, a vůbec se nezajímali o provoz, a ani neměli žádnou zpětnou vazbu, a snad v životě jsem neviděl větší zombíky. Což se snaží trochu opravit devops. Pro mne to neznamená, že programátor dělá admina, ale znamená to, že programátor i admin sedí vedle sebe, a že programátor má živě vidí provoz aplikace, kterou programoval, a že admin alespoň tuší, co ten kód dělá, a jaké má závislosti a neadminuje blackbox.

7
Studium a uplatnění / Re:Lhaní recruiterů
« kdy: 09. 01. 2022, 20:20:27 »
Vím, že následující názor by byl dnešní většinovou společností považován za staromodní, ale já věřím, že každý má svojí profesi a té by se měl držet. Ty dnešní maistreamové kecy, že každý může být čímkoli, stačí chtít a když ho to přestane bavit, tak začne dělat zase něco úplně jiného... Když se jedná o alespoň trochu příbuzné obory, tak nic proti, ale představa, že teď bude někdo chvíli programovat, až ho to přestane bavit tak se rekvalifikuje na lékaře, potom uvidí dokument o Černobylu, tak se přihlásí na operátora reaktoru a nakonec začne létat jako pilot letadla, protože má chuť cestovat...
Než jsem vydělal první korunu jako programátor, tak jsem se tomu oboru třeba 10 let alespoň nějak okrajově věnoval, ať už ve škole nebo volném čase a myslím, že to tak má většina.
Jenže někdo si nechá nabulíkovat, že stačí udělat nějaké kurzy v rozsahu desítek možná nižších stovek hodin a bez jakéhokoli předchozího backgroundu se tomu může plnohodnotně věnovat. Koneckonců je to práce v teple a prý dobře platí, tak proč ne.
Možná staromódní, ale pravdivý. Já to zastávám také. Bohužel taková je dnes doba, řeší se "rasismus", "80 sex. pohlaví" a další stupni věci. Na druhou stranu, ono to všichni tak reklamují, že uděláš bootcamp a je z Vás programátor. To jsou jen bludy, kecy prdy beďary. Určitě existují lidé, kteří třeba ze kolbenky mohou jít programovat a budou lepší než nekteří senioři, ale je to tak 2%.

Bohužel to, že Vám "kurzy" i školy tlačí do hlavy, jak z Vás udělají experta hned, je dnes trend. Jak jsem psal, mám pár zkušeností z firem, než jsem začal se svou firmou a vždy to byla katastrofa. Chápu, že junior nemůže znát vše, ale na druhou stranu musí umět a chápat základy. Pak si už jen rozšiřuje obzory. Ale dnešní junioři, po kurzech co mi chodí na pohovory, chtějí 80-90% mít seniora za pr**lí a mentoring vyžadují. Osobně mi přijde, že na těch kurzech je tak leda naučí copy & paste z StackOverflow, co neví najdou na netu a zkopírují, aniž by věděl co daný kus kódu dělá. Z "moderních" juniorů snad nikdo nezná ani debugger... ;-(

Je to marketing, který osobně nesnáším. Zase na druhou stranu, pokud je někdo chytrej, a chce, a baví ho to, tak není důvod, aby po 3 měsíčním kurzu nešel dělat do IT na nějakou začátečnickou pozici. Většina technologií je primitivních - problém je spíš rozsah a komplexita a neskutečná zabordelenost většiny projektů.

8
Studium a uplatnění / Re:Lhaní recruiterů
« kdy: 09. 01. 2022, 20:13:22 »
...Pro to aby člověk mohl navrhovat formuláře v čemkoliv a zapsal je do db, na to nepotřebujete žádný extra zkušenosti a ani znalosti...
tak to je hodně odvážný nesmysl... Pak chápu, že jsou oblíbené sr**čky typu Wordpress

Ano, ono to bude fungovat, ale pokud člověk neví, co a jak, tak jak pak vypadá kvalita?

Máte hromadu aplikací napsaných v Delphi, Visual Basicu, Power Buildru - a co se týče kvality, případně znalostí - motám se kolem migrací z Oraclu do Postgresu - nejednalo se o low cost soft, a viděl jsem takový zvěrstva. Tunil jsem dotazy (databázi) po lidech z předního českého korporátu. Viděl jsem design, který navrhlo HP, a chtělo se mi brečet. Každý rok proškolím kolem mezi 100-200 prográmátory napříč celým spektrem IT - startupy, malé firmy, korporát a průmysl, a co se týče znalostí - je to prostě klasický gaus. Pár procent vývojářů má špičkové znalosti, pak je tu možná čtvrtina se slušnýma znalostma, a pak masa, která netuší pořádně, co je index, co je isolation level, a čím se liší checkpoint od savepointu. Narazíte na dost vývojářů, kteří jsou netknutí vědomostmi


9
Studium a uplatnění / Re:Lhaní recruiterů
« kdy: 09. 01. 2022, 19:08:32 »
Může být, ale jak člověk pozná, co je “jeho profese”, aniž by si vyzkoušel aspoň to, co ho nejvíc baví?

Jednoduše - prostě syn zdědí řemeslo svého otce. Ano, je to staromódní názor, nad kterým spousta frikulínů z "moderní" společnosti ohrne nos, ale je to systém prověřený staletími.

Proboha :-/

10
Studium a uplatnění / Re:Lhaní recruiterů
« kdy: 09. 01. 2022, 19:07:50 »
Jenže někdo si nechá nabulíkovat, že stačí udělat nějaké kurzy v rozsahu desítek možná nižších stovek hodin a bez jakéhokoli předchozího backgroundu se tomu může plnohodnotně věnovat. Koneckonců je to práce v teple a prý dobře platí, tak proč ne.

IT má ohromný rozsah, a hromadu práce mohou provést proškolení neIT specialisté. Koneckonců v 90 letech, když jsme začínali, tak jedinou kvalifikací mnoha vývojářů, byly stovky hodin propařených v doomu nebo ve warcraftech. Pro datovou analytiku potřebujete primárně znalost domény, a SQL a databáze jako technologie jsou relativně jednoduché a není to ani moc rozsáhlá tematika. Pro to aby člověk mohl navrhovat formuláře v čemkoliv a zapsal je do db, na to nepotřebujete žádný extra zkušenosti a ani znalosti. Samozřejmě, že je dobré mít dohled seniora, který dokáže člověka nakopnout správným směrem.

To, že to hromada lidí zkouší bez zkušeností nebo bez většího prechozího kontaktu s IT je správně.  V IT chybí šikovný lidi. Samozřejmě, měli by být realisti ohledně mzdy a podmínek. První projekty (kolem roku 95) jsem dělal prakticky za hubičku, jen abych se dostal k technologiím a měl možnost si osahat skutečnou práci. Jako stěhovák jsem si možná vydělal (na hodinu) víc.

11
Server / Re:PostgreSQL - zvládne 400m řádků?
« kdy: 28. 12. 2021, 14:42:44 »
Zdar,

mam jednu PostgreSQL tabulku s touhle strukturou a 400 miliony radku:

id (autoinc), 10x text (max 256zn.), 10x jsonb (max par tisic znaku)

Na par text sloupeccich je dany index.

Jaky potrebuji HW, nebo co a jak tam nastavit, aby to zvladalo kolem 1k SELECT/UPDATE/INSERT dotazu (tj. 3k dotazu) za vterinu soucasne (a tohle bude muset bezet "nonstop").

Dotazy se vazi na jeden text sloupecek jako identifikator (je unikatni ale je na nem index), zadne slozite veci u toho dotazu nejsou.
Zkousel jsem to na serveru se ssd disky a 64gb ram a... tfujky, absolutne to nedava.
S ohledem na obsah tabulky by ji asi neslo rozdelit do vice tabulek.

Co s tim? Klidne muzu vymenit za jinou db, ale radeji bych zustal u PostgreSQL.

U téhle velikosti to už chce používat partitioning, a při nonstop zátěži 1K DML a 3K SELECTů za sec to už chce i vymyslet nějaké horizontální škálování. Minimálně potřebujete vacuovat tabulky, a budete potřebovat reindexaci. Update velkých tabulek je dost drahá záležitost - zvlášť pak když jsou bloatlý indexy. 1000 DML za sec nekolika kb jsonu - to musí být peklo. To vám pomalu nemůžou dát ani ta SSDčka.

Můžete zkusit MySQL - UPDATE tabulky s větším množstvím oindexovaných sloupců je na MySQL rychlejší. Nicméně je otázkou, co se vám vejde do paměti, a jak často budete muset hrabat na disk. I pro MySQL platí, že pro rychlý přístup musí být drtivá většina dat v RAMce. Pro ten požadovaný výkon musíte mít dotazy hodně pod 10 ms, spíš pod ms, takže to chce hodně RAM, hodně IOPS, a hodně CPU.

12
Server / Re:Pomohl vám Elasticsearch?
« kdy: 24. 12. 2021, 13:29:32 »
Z 20K položek musí libovolná sql databáze našeptávat realtime :) 
Jde o to, zda chcete jenom hloupě našeptávat přesně ty položky, které v databázi jsou, nebo jestli chcete řešit překlepy, psaní bez diakritiky, synonyma apod.
Tohle všechno umí fulltext v pg (MySQL neznám, takže tam nevím).

13
Server / Re:Pomohl vám Elasticsearch?
« kdy: 23. 12. 2021, 13:15:16 »
Dále je tu parametrické vyhledávání produktů.
V ES je rovněž možné takové vyhledávání použít, ale nevím jestli je ES pro tento účel vhodný.

Áno, ES je pre tento účel vhodný, má na to špecializované indexy.

Je tu někdo kdo řešil podobnou migraci a byl by ochotný sdílet zkušenosti před/po?
Měla taková migrace smysl?
Zaznamenali jste lepší odezvy svých vyhledávačů?

Špecializované fulltextové vyhľadávače spravidla prinášajú nasledovné výhody:
- podpora skloňovania (stemming alebo lematizácia) - pri dátach, kde je dôležité hľadať podľa obsahu neštruktúrovaného textu (napr. články) je dôležité, aby vyhľadávač našiel aj skloňované tvary hľadaných výrazov (niektoré relačné databázy už na to majú podporu, neviem, či aj MariaDB)
- podpora zvýrazňovania nájdených slov v texte - uľahčuje používateľom posúdenie, či ponúkané výsledky vyhľadávania naozaj zodpovedajú tomu, čo chcel nájsť
- podpora generovania krátkych sumárov z textu pre potreby zobrazenia ukážky vo výsledkoch vyhľadávania, ideálne z tej časti textu, kde sa našli hľadané výrazy (a so zvýraznením nájdených výrazov)
- možnosť automaticky ponúknuť používateľom obsahovo podobné dokumenty
- vyššia rýchlosť vyhľadávania v porovnaní s fulltextovým vyhľadávaním v relačných db

V závislosti od konkrétneho usecase-u odporúčam zvážiť aj použitie fulltextového engine-u Solr - pokiaľ nepotrebujete špecializované výpočty nad dátami, tak je IMHO jednoduchší na implementáciu, pričom má rovnaké jadro ako ES.

Dost ze zde uvedeného seznamu mají dnešní fulltexty v databázích (třeba i ten z Postgresu). Co je potřeba říct, je že Elastic je inmemory databáze, a inmemory indexy z podstaty mají jinou strukturu než klasické indexy, a operace nad nimi jsou rychlejší. U vyšší zátěže - nad 1000 req. za sec to svůj význam má. U méně zatížených systémů to může být zbytečný a drahý kanón na vrabce.  V GD na údržbě elasticku, který běžel jako podvozek splunku dělal jeden člověk na fulltime, aby to udržel při životě. A v případě identifikace problémů byl splunk extra užitečný.

14
Pracovní neschopnost trvala v průměru 42,4 dne

ty bláho, tak to by měl zajímalo kdo ten průměr dělá... Osobně jsem nebyl nemocný více jak 20 let, ani ve svém okolí neznám moc lidí, kteří by byly nemocní.

Přes 40 pracovních dnů, to je šíleně moc...

to číslo ale řiká úplně něco jiného a ty v něm tedy nejsi. Ta věta se vztahuje pouze na ty nemocné (neříká ani kolik jich bylo z celku) a pro ně nemocenská byla v průměru 42 dní za rok. Pozor počítají se i toho případy ošetřovačky, kdy jsi doma s dětmi, když jsou nemocní, stejně tak v tom jsou započteno těhotenství. Právě ošetřovačky a chronicky nemocní tohle číslo takhle zvedají. Nezapomeň na vážné úrazy či hospitalizace, tam to snadno skáče do měsíců.

Navíc, je to průměr, který je citlivý na extrémy. Něco jiného by byl medián.

15
(Tady je vidět, k čemu je alespoň základní IT vzdělání, tohle se bere na VŠ snad hned v prváku.)
Tak třeba na informatice na matfyzu byly databáze doporučené ve druháku a o vacuumu se tam nemluvilo (samozřejmě si to nemůžu s jistotou 7 let pamatovat, ale ve slidech se slovo vacuum nevyskytuje a slidy k tomuto předmětu jsou celkem verbose).

To, o čem je zde řeč, je shrink. Většinou se o tom mluví v momentě, kdy se mluví o implementaci DELETE, který fyzicky nemaže záznamy ze souboru, a tudíž je zřejmé, že na shrinknutí musí být speciální operace - rebuild ať už podporovaný databází nebo ruční dump/load. Taky se o tom může mluvit, když se řeší, jak se fyzicky data ukládají na disk.

Stran: [1] 2 3 ... 26