Příspěvky

361

Server / Re:postrges prvni krucky :)

« kdy: 14. 12. 2016, 14:27:16 »

diky moc za rychle reakce, pgadmin jsem nasel
ale nejak nechapu jeho pouziti

libi se mi system admineru nakpiruju na server a jede v php

uz lustim dokumentaci
https://www.pgadmin.org/docs4/dev/getting_started.html


slozitejsi je to, ze mysql proste nainstaluju a prihlasim se root heslo udelam uzivatele zalozim DBa jedu

tady se placam v tech schematech apod ... treba adminer neumi nastavovat prava, to me mrzi

jdu studovat

Na začátku je v Postgresu použivatel postgres a to bez hesla. Je nutné se tam přihlásit přes systémový účet postgres. Pokud Vás schémata matou - tak používejte pouze výchozí schéma public. Schémata jsou něco jako namespaces z php. Slouží pouze k logickému rozčlenění databázových objektů. Pokud své objekty umístíte do publicu, tak se to bude chovat stejně jako v MySQL.

362

Server / Re:MariaDB a práva k uložené proceduře

« kdy: 13. 12. 2016, 17:39:33 »

Díky,  ale aktuálně asi nemám prostor migrovst celý projekt,  ještě zvážim perconu

Percona je drobet opatchovaný MySQL - v tomto ohledu se bude chovat úplně stejně.

363

Server / Re:MariaDB a práva k uložené proceduře

« kdy: 13. 12. 2016, 17:37:52 »

ahoj, objevil jsem kouzlo StoredProc
zkousim jednu vytvorit a funguje to, ale narazil jsem na problem s opravnenim

ma uzivatele kasa, kteremu k databazi pokladna pridelim prava Procedura    Execute
delam to v nastroji adminer

sp ovsem nelze spustit, kdyz ale pridelim prava primo k te dane sp pomoci tabulky procs_priv
tak to slape,

mel jsem za to, ze prava v MySQL funguji tak, ze pokud pridelim uzivateli napr prava Tabulka - Select
a neomezim to v tabulce mysql.db na konkretni databazi, tak to plati pro vsechny database

tak mi to i funguje, ale u sp je to jinak ?

dekuji za pripadne rady

TH

u SP je to jinak - tady MySQL drží basu se zbytkem a v Postgresu je svébytný.

Uvnitř uložené procedury v MySQL běžíte (bydef) s právy vlastníka procedury (kdo tu proceduru vytvořil).  Proto se ještě typicky nastavují práva na spuštění procedury.

V Postgresu je to přesně opačně - defaultně běží s právy volajícího - tudíž se tam typicky nenastavují pak práva na proceduru, jelikož se běžně nemění identita.

364

Server / Re:Jakou DB nasadit: MariaDB nebo Percona?

« kdy: 28. 11. 2016, 22:09:43 »

S Postgre bych byl opatrny.
 Pokud jsou to male data a par klicu na tabulkach, tak asi nebude problem, ale postgre ma, nebo minimalne mela dost neefektivni replikaci(a vubec zapisy dat, z duvodu "divneho" systemu fyzickeho ulozeni na disk). S vice sekundarnimi klici, pripadne vetsimi daty, ta replikace dost zabiji sit a i bezne lokalni zapisy zerou dost IO.

Postgres má vestavěnou fyzickou replikaci, která je náročnější na přenos, ale vždy zachovává konzistenci o jednoduše se nerozpadne. Výkonostně jsem ji viděl nasazenou na intenzivním zápisu desítek gb dat a cca 5000..11k transakcí za sec. Což je hodně atypická aplikace na čr.

Ten divný zapis na disk používá i innodb. Rozdílná je implementace indexů. U mysql je optimalizovaný přístup na primární klíč, ostatní jsou pomalejší. U postgresu není rozdíl mezi primárním a jiným indexem. Postgres rychleji čte data z dalších indexů, MySql rychleji updajtuje. Rozdíly se poznají na aplikaci typu Uber. Tady na čr to asi nebude vůbec poznat.

To se vam nerospadne ani u mysql. To co jste videl nic neznamena, neznamena, ze to nevytizi napr GB sit.
Postgre prenasi v podstate pro kazdy klic na radku cely radek znova. A protoze nepodporuje poradne MVCC, tak v pripade updatu mate na slavech zamknute i cteci transakce. Ja nerikam, ze na vetsinu veci nestaci, jen rikam at si date bacha, ze vytizite jak IO, tak sit vice nez u mysql. A jinak i v CR najdete mista, kde s tim budete mit VELKY problem ;-)

UPDATE na masteru Vám nezamkne čtecí transakce na slave - může dojít ke kolizi, a transakce na slave bude stornovaná - aby se Vám to nestalo, tak lze na slave nastavit hot_standby_feedback.

365

Studium a uplatnění / Re:Nejžádanější programátorské znalosti na českém pracovním trhu.

« kdy: 22. 11. 2016, 11:03:35 »

t.

... - 10 serverů nemá 10x větší výkon - ale vyžaduje 100x větší náklady na vývoj, údržbu infrastruktury.

Dovolim si nesouhlasit, 10 serveru muze klidne prinyst i 100x vetsi vykon ... ovsem za predpokladu, ze tvurce aplikace vi co dela a jak veci funguji. Jednoduse treba proto, ze kdyz neco pristupuje treba k ram, a tech procesu je vic, tak si konkuruji, cimz se vzajemne omezuji. Rozhodne to ale nevyresi tupyho tvurce, v takovym pripade to situaci spis naopak razantne zhorsi.

To už to pak musíte hodně umět - a musíte mít hodně za sebou - a ještě mít štěstí. Ale i kdyby jste dosáhl 100x většího výkonu - stále budete mít výrazně vyšší náklady - napsat, odladit, udržet v provozu, rozvíjet distribuovanou aplikaci je výrazně komplikovanější než klasickou aplikaci - tady potřebujete hodně dobré lidi, kteří už mají znalosti a obyčejně i svou cenu.

366

Studium a uplatnění / Re:Nejžádanější programátorské znalosti na českém pracovním trhu

« kdy: 22. 11. 2016, 10:10:31 »

Ono se tak trochu zapomíná, že v době vzniku Javy, každý programátor ovládal nejméně jeden assembler a běžně programoval v C, kde kritické části kódu psal v in-line assembleru. A proto vznikla Java. Aby se toto odstranilo, protože to bránilo přenositelnosti programů.

Nejsem úplný veterán, ale dobu vzniku Javy pamatuji dost dobře - je možné, že v té době se každý programátor setkal s assamblerem, ale že by běžně programoval v Cčku - tak to ani náhodou - programovalo se v Turbo Pascalu, v Delphi, Visual Basicu, VBScriptu, Cčko, C++ byla pro většinu zdejších programátorů absolutní exotika. Java byla od začátku multiplatformní, ale počítalo se s ní na malé zasíťované systémy - chytré ledničky, adt, pak se začala používat pro web komponenty a až na úplně nakonec se v ní začaly dělat webové služby. Brala se jako chytřejší skriptovací jazyk. K server side programování, k enterprise programování se dostala až skoro nakonec, kdy se C++ ukázalo příliš komplikovaný a špatně uchopitelný pro běžný programátory. Žádný rozumný objektově orientovaný jazyk, který byl rozkročený mezi skriptováním a klasickým programováním nebyl.

367

Studium a uplatnění / Re:Nejžádanější programátorské znalosti na českém pracovním trhu.

« kdy: 22. 11. 2016, 08:41:52 »

Blbostmi myslím běžné zkoušení na VŠ. Projdou hlavně ti hloupí, kterým nevadí umět zbytečnosti.

to máte pravdu
To zalezi na skole. Opravdu nemam pocit, ze kdyz ja byl na CVUT, tak prosel kdejaky blb. Naopak, ti se obvykle nedozili ani druheho rocniku.

To je zajímavý, že v IT je to samý Ing. z ČVUT a jsou obvykle úplně k ničemu jako běžné lopaty. Častokrát jsem slyšel zase historky o tom, jak tam by blbec, který se učí nazpaměť, neprošel. Evidentně jsou to jen kecy těch hloupých lidí, kteří prošli. Je to podobné jako s matfyzem, kde absolvent nemůže být hloupý. Evidentně to také nefunguje, protože znám zase v oboru hromadu lidí z matfyzu, kteří nechápou složitější souvislosti. Typicky design aplikace je pro ně něco nepochopitelného a prasí jako běžná lopata. Efektivita je pro ně absolutně nepodstatná.

Tak teda nevim, kde je pravda. Ale třeba žijeme každý jinde. Pohybuhttp://www.krajskelisty.cz/ji se v IT plném lopat, kde 60 tisíc maji ti nejslabší. Třeba ale právě to je ten problém a Lojza z malé firmy za 35 si to dává po matfyzu jako king.

Ano, kdyby jsi věděl něco o Javě, jako že nevíš, tak by jsi věděl, že efektivita je sprosté slovo. Je to jazyk pro lopaty, který neumí nic jinýho, než nadávat na pomalý HW a výkonnostní problémy řeší jeho upgradem. Je to pochopitelné, protože pro malé lopaťácké projekty je těch pár serverů navíc levnějších, než pořádný vývojář v rozumném jazyce. Ale když potom dojde na pořádné projekty, tak se najednou vyplatí investovat do slušných lidí, místo nákupu a údržby stovek serverů navíc.

To se nevyplatí nikdy, železo bude vždy levnější. Určitě je lepší srozumitelný méně výkonný program, který lze snadno udržovat a výkonu lze dosáhnout pořízením více serverů, než sofistikovaný program, který běží na méně serverech, a nemůže ho rozvíjet a udržovat jen tak někdo. Na produkční server patří normální, nikoliv špičkoví odborníci, ti mají hledat nové cesty a ne ztrácet čas produkční rutinou, když stejného výsledku lze dosáhnout posílením železa.

To už dneska neplatí - nezvyšují se frekvence ani CPU, ani pamětí - pokud máte neefektivně napsaný program, tak Vám lepší železo vůbec nepomůže - prostě se bude flákat, a Vaše aplikace bude dál  pomalá - a od určité ceny serverů se Vám fakt vyplatí si zaplatit někoho technicky a odborně zdatného - u databází je to krásně vidět - 10 serverů nemá 10x větší výkon - ale vyžaduje 100x větší náklady na vývoj, údržbu infrastruktury.

Ano, může být. Ovšem u relačních databází optimalizace spíševede na čitelnou a dobře se udržující strukturu.

Téměř všude vede dobře udělaná optimalizace k čitelnějšímu a lépe udržovatelnému kódu. Dost častou chybou je oprava na špatném místě - bez znalostí se nedá dost dobře najít důvod problémů, a "oprava" pak vede k dost náročnému kódu - jak na hardware, tak na údržbu.

368

Studium a uplatnění / Re:Nejžádanější programátorské znalosti na českém pracovním trhu.

« kdy: 22. 11. 2016, 06:12:42 »

Blbostmi myslím běžné zkoušení na VŠ. Projdou hlavně ti hloupí, kterým nevadí umět zbytečnosti.

To zalezi na skole. Opravdu nemam pocit, ze kdyz ja byl na CVUT, tak prosel kdejaky blb. Naopak, ti se obvykle nedozili ani druheho rocniku.

To je zajímavý, že v IT je to samý Ing. z ČVUT a jsou obvykle úplně k ničemu jako běžné lopaty. Častokrát jsem slyšel zase historky o tom, jak tam by blbec, který se učí nazpaměť, neprošel. Evidentně jsou to jen kecy těch hloupých lidí, kteří prošli. Je to podobné jako s matfyzem, kde absolvent nemůže být hloupý. Evidentně to také nefunguje, protože znám zase v oboru hromadu lidí z matfyzu, kteří nechápou složitější souvislosti. Typicky design aplikace je pro ně něco nepochopitelného a prasí jako běžná lopata. Efektivita je pro ně absolutně nepodstatná.

Tak teda nevim, kde je pravda. Ale třeba žijeme každý jinde. Pohybuji se v IT plném lopat, kde 60 tisíc maji ti nejslabší. Třeba ale právě to je ten problém a Lojza z malé firmy za 35 si to dává po matfyzu jako king.

Ano, kdyby jsi věděl něco o Javě, jako že nevíš, tak by jsi věděl, že efektivita je sprosté slovo. Je to jazyk pro lopaty, který neumí nic jinýho, než nadávat na pomalý HW a výkonnostní problémy řeší jeho upgradem. Je to pochopitelné, protože pro malé lopaťácké projekty je těch pár serverů navíc levnějších, než pořádný vývojář v rozumném jazyce. Ale když potom dojde na pořádné projekty, tak se najednou vyplatí investovat do slušných lidí, místo nákupu a údržby stovek serverů navíc.

To se nevyplatí nikdy, železo bude vždy levnější. Určitě je lepší srozumitelný méně výkonný program, který lze snadno udržovat a výkonu lze dosáhnout pořízením více serverů, než sofistikovaný program, který běží na méně serverech, a nemůže ho rozvíjet a udržovat jen tak někdo. Na produkční server patří normální, nikoliv špičkoví odborníci, ti mají hledat nové cesty a ne ztrácet čas produkční rutinou, když stejného výsledku lze dosáhnout posílením železa.

To už dneska neplatí - nezvyšují se frekvence ani CPU, ani pamětí - pokud máte neefektivně napsaný program, tak Vám lepší železo vůbec nepomůže - prostě se bude flákat, a Vaše aplikace bude dál  pomalá - a od určité ceny serverů se Vám fakt vyplatí si zaplatit někoho technicky a odborně zdatného - u databází je to krásně vidět - 10 serverů nemá 10x větší výkon - ale vyžaduje 100x větší náklady na vývoj, údržbu infrastruktury.

369

Studium a uplatnění / Re:Nejžádanější programátorské znalosti na českém pracovním trhu.

« kdy: 20. 11. 2016, 20:05:12 »

Myslim, ze s embedded programovanim, GPGPU programovanim a machine learningem clovek dneska chybu udelat nemuze. Navic jsou to extremne zajimave veci.

To je Java budoucnosti. Maximum příjmu do pěti let.

Java budoucnosti je Java - bohužel - Jakkolik to jsou zajímavé technologie, tak to nikdy nebude masovka (což může být i výhoda). Na machine learning, i GPU programování jsou potřeba značné teoretické znalosti (v prvém případě statistiky, v druhém pak algoritmů).

370

Vývoj / Re:Co zpomaluje Javu? A co překlad do nativního kódu?

« kdy: 16. 11. 2016, 16:52:51 »

Rekl bych ze java bude o neco malo pomalejsi nez C/C++, nemyslim ze tohle je problem dneska kdyz mame k dispozici vykonne CPU, mnohem vetsi problem je velka spotreba pameti programu napsanych v JAVE.

Kazdopadne nejlepsi argument, lepsi nez nejake benchmarky je tento:

Kdyz se podivam na svuj desktop a v nem nejpouzivanejsou programy ktere ja pouzivam, napr: Chrome, Internet Explorer, Outlook, Excel, Word, Notepad++, uTorrent, Oracle, PostgreSQL, SAP Gui. Tak zadny z nich neni napsan v te uzasne JAVE (uzasne zkurvene pomale a nenazrane) , Proc? Kdyz je tak rychla a uzasne rychle se v ni vyviji?

Většina toho zmíněného sw je starší než Java - některé z těchto aplikací mohou pracovat s dost složitými datovými strukturami - a pak není nad C nebo C++.

371

Server / Re:In memory SQL

« kdy: 30. 10. 2016, 05:44:17 »

A co tkahle použít v postgresu TABLESPACES které umožní umístit určité tabulky na jiný disk nebo RAM disk . Podotýkám, že  u jednotlivé tablespace lze nastavit optimalizace jné než v centrálním clusteru

Pokud se bavíme o Postgresu, tak to je nesmyl - je úplně jedno jestli jsou data ve file system cachi nebo v Pg cache nebo v ramdisku - pokaždé mají stejný formát.

372

Server / Re:In memory SQL

« kdy: 28. 10. 2016, 22:40:22 »

MonetDB ale není klasická in RAM DB, ne (při porovnání s memcached/Redis/...)? Jen s trocou štestí mám data v RAM a jede rychle, ale pořád aktivně jede přes disk.
Když má data v RAM, tak je asi rychlejší jak PotgreSQL s podobně obsazenou a využitou RAM.

Memcached/Redis to jsou více/méně sofistikované cache key/value dat - jedná se o jednoduché jednoúčelové databáze. Oprati tomu je Monet obecnější - s velkou většinou funkcí typických pro paměťové databáze - sloupcové uložení dat, efektivní komprimace, optimalizace CPU, diskové operace jsou nahrazeny virtuální pamětí. Paměťové databáze jsou relativní novinkou, těžko se dá označit nějaká technologie jako klasická. V každém případku je MonetDB jednou z nejstarších databází, které rovnou byly navrhovány jako paměťové - cca 20 a více let. O memchaced pravděpodobně nikdo z jejich tvůrců neuvažoval jako o databázi - byl to jednoduchý jednoúčelový nástroj, který umožňoval sdílený přístup do paměti.

373

Server / Re:In memory SQL

« kdy: 28. 10. 2016, 10:32:49 »

Extrémně rychlá paměťová SQL databáze je monetdb https://www.monetdb.org/Home

Dneska je celá kategorie databází označovaná jako NewSQL - která už pracuje s daty úplně jinak než Postgres - Postgres má data ve formátu, který vyhovuje uložení na disk - nové databáze už si data drží primárně v RAMce a na disk udělají občas backup a na disku si drží transakční log. Když máte štěstí, tak tyto databáze mohou být o řád až dva rychlejší než klasická db (data ale musí být 100% v RAM). Na druhou stranu vzhledem k mládí a k výrazně nižšímu počtu uživatelů musí člověk počítat s větší pravděpodobností výskytu chyb a provozních problémů. Klasické databáze jsou ověřené časem a počtem uživatelů. To u nových db samozřejmě neplatí. Hodně záleží na zátěži, typu a objemu dat - někdy bude benefit větší, někdy menší.

374

Server / Re:Porovnání SQLite vs. MySQL

« kdy: 18. 09. 2016, 21:48:12 »

Ano. K výpadkům proudu docházelo poměrně často. Databáze se pak rozjela nebo nerozjela, pokud se nerozjela, opravit se dala pomocí repair table.

S dnešním odstupem bych to hodnotil jako ukázkově nevhodné použití MySQL.

Určitě pro MyISAM naprosto nevhodné - jinak popisovanou zátěž by zvládla každá db levou zadní.

Jinak ale výpadek proudu může dostat do kolen každou databázi - pokud nemáte dražší hw jištěný vlastní baterií, tak tu vždy máte nenulové riziko poškození filesystému. Samozřejmě, že u netransakční databáze je to horší - tam můžete přijít o data, aniž by došlo k poškození filesystému. Od počítače, kde dochází k výpadkům proudu, samovolným restartům bych vůbec nic nečekal - je jen otázkou času, kdy se filesystém natolik rozpadne, že něco důležitého bude nečitelné.

375

Server / Re:Porovnání SQLite vs. MySQL

« kdy: 18. 09. 2016, 21:15:14 »

To platí, že se změny povede zapsat na disk - MyISAM ale používá file systémovou cache, a v případě havárie se změny vůbec nemusí promítnout do datových souborů, nemusí se stihnout zapsat nic nebo jen něco - to už je záležitost operačního systému. Transakční systém není jen atomičnost a izolace, ale také Durabiilty -- garance, že jsou změny bezpečně zapsané - a to MyISAM také nemá.

Ano, princip ACID znám. Ta databáze ale nehavarovala. Navíc garanci, že jsou změny bezpečně zapsané, po databázi nikdo nutné nepotřeboval - nepřehazovali jsme vidlema peníze. Bohatě by stačilo, kdyby databáze fungovala dle očekávání alespoň v rámci jednoho spuštění.

Jinde píšete, že docházelo k výpadkům proudu - je úplně jedno jestli spadne db, operační systém nebo vypadne proud - prostě havárie. MyISAM může fungovat na relativně hodně stabilním systému nebo s relativně malou frekvencí změn, kdy je dost velká šance, že už data budou fyzicky zapsaná.