Příspěvky

196

Server / Re:Optimalizacia RDS AWS (PostgreSQL)

« kdy: 03. 05. 2020, 06:04:31 »

Nevím jak nyní, ale pokud člověk chtěl na AWS (pravděpodobně všude) slušnější IO, tak si musel připlatit za garantované IOPS. Což může vyjít dráž než více RAM, kdy data zůstanou v cache, a IO se používá primárně pro zápis. Pokud by aplikace sama nebyla v AWS, tak můžete mít vysoké latence, což může také způsobovat problémy. AWS pro provoz databází není nic ideálního. Amazon sám doporučuje Auroru Postgres.

197

Studium a uplatnění / Re:SQL - literatura

« kdy: 05. 04. 2020, 18:27:13 »

Základy jsou hrozně jednoduché - celé se to dá vysvětlit za hodinu -  z literatury mám pocit, že se trochu z SQL dělá zbytečná věda, a zapomíná se na praktičnost - a drtivá většina dotazů nejsou žádná magie. K základům patří umět spojovat tabulky a používat agregační funkce. V případě zájmu můžu vysvětlit po skype - Pavel Stěhule

198

Studium a uplatnění / Re:Dobrý zdroj pro studium PostgreSQL

« kdy: 08. 05. 2019, 21:47:45 »

https://docplayer.cz/8946291-Zaklady-sql-a-databaze-postgresql.html

juju - Skripta prof Cepka mohu jedine doporucit

199

Studium a uplatnění / Re:Dobrý zdroj pro studium PostgreSQL

« kdy: 07. 05. 2019, 17:46:26 »

Zdrojů k Postgresu je docela dost - začnu webem pgsql.cz - https://postgres.cz/wiki/Kategorie:%C4%8Cl%C3%A1nky. Z blogů kolektor blogů Planet Postgres - https://planet.postgresql.org/. Zajímavé články o implementaci např. indexů pěkný seriál https://habr.com/en/company/postgrespro/

200

Vývoj / Re:Přidání jazykové sady (snowball) do PostgreSQL

« kdy: 07. 03. 2019, 14:01:20 »

viz https://postgres.cz/wiki/Instalace_PostgreSQL#Instalace_Fulltextu

201

Vývoj / Re:Jak se resi deadlock v databazi, ktery vzniknul na urovni requestu v komponente?

« kdy: 22. 02. 2019, 10:33:58 »

No tím, že vyblokuji jakékoliv čekání na zámek se toho moc nenaučím  . Hodně záleží na kontextu, použité databázi, izolačním levelu, atd. Osobně bych určitě NOWAIT nedoporučil genericky používat - ale beru, že neznám prostředí, technologie, které používáte. V Postgresu jde případně nastavit lock wait timeout.

Ano, vím. Mluvím o tom, že naopak přes NOWAIT se mi lépe učí nováčci. Nevím, jakou zkušenost máte Vy, ale ke mně se dostávají "SQL" programátoři, kteří umějí udělat jeden select v MySQL, vlastnosti transakcí neznají a lock je pro ně něco, co v životě neslyšeli a nechápou ani význam. Prostě taková schola ludus v Postgresu.

Popravdě řečeno, s tímhle levelem programátorů se moc nepotkávám. U běžných uživatelů, kteří primárně řeší reporty tyto znalosti nečekám, a databáze tím, že řeší konzistenci a izolaci, je odstíní od detailů. U aplikačních programátorů naopak předpokládám, že znají základy - race condition, izolační levely, atd. pokud chtějí dělat s db. Pokud ne, tak je to pak těžké.

202

Vývoj / Re:Jak se resi deadlock v databazi, ktery vzniknul na urovni requestu v komponente?

« kdy: 22. 02. 2019, 09:30:06 »

Alternativou je pesimistické zamykání, případně používání klauzulí NOWAIT, případně SKIP_LOCKED a ošetřování si zámků vlastními silami. To určitě ale běžnému uživateli nedoporučuji.

Já konkrétně NOWAIT naopak doporučuji, zjistil jsem, že pro začínající programátory je to lépe představitelná cesta, jak se naučit fungování lockování. Začínající programátoři v praxi moc často na problém s locky nenarazí (testovací data jsou malá, i souběh locků trvá milisekundy, ...). Na častou chybu, na kterou narážím je tendence programátorů volat script minutovým cronem (setkal jsem se i se sekundovým), kde už se bez NOWAIT pracovat nedá.

No tím, že vyblokuji jakékoliv čekání na zámek se toho moc nenaučím  . Hodně záleží na kontextu, použité databázi, izolačním levelu, atd. Osobně bych určitě NOWAIT nedoporučil genericky používat - ale beru, že neznám prostředí, technologie, které používáte. V Postgresu jde případně nastavit lock wait timeout.

203

Vývoj / Re:Jak se resi deadlock v databazi, ktery vzniknul na urovni requestu v komponente?

« kdy: 22. 02. 2019, 09:16:25 »

I v korektní aplikaci může dojít  v databázi k deadlockům - pokud k nim nedochází extrémně často, tak nejsou problém. Databáze deadlock dokáží identifikovat a řešit. Zrovna  u úrovně serializable by klient měl být napsán takovým způsobem, aby dokázal zopakovat poslední transakci - kromě jiného může chybu vrátit i COMMIT z důvodu nemožnosti serializace transakcí.

Ohledně designu platí doporučení, aby často referencované tabulky (na které se často odkazujete cizími klíči) neměly extrémně nestabilní položky (např. last_update atd). Pak samozřejmě klasika - pokud držím blokovací zámky (po modifikaci řádků), tak bych měl dokončit transakci co nejdříve. Pak klesá riziko souběhu a tudíž i riziko deadlocků.

Alternativou je pesimistické zamykání, případně používání klauzulí NOWAIT, případně SKIP_LOCKED a ošetřování si zámků vlastními silami. To určitě ale běžnému uživateli nedoporučuji.

Ještě jednou - není potřeba se bát deadlocků, pokud mám korektně napsanou aplikaci, a pokud jich není příliš. Pokud je jich příliš - stovky za hodinu a výš, tak něco je špatně - od použití špatné technologie, frameworku, db designu, těžko říct co - problém může být kdekoliv.

204

Vývoj / Re:Viděli už jste někde distribuované transakce?

« kdy: 20. 02. 2019, 07:12:29 »

V databázovém světě se 2PC transakce používají, tam kde jsou nezbytně nutné - pokud potřebujete sesynchronizovat dva datové zdroje. Jinak se to moc nepoužívá - musí se počítat s latencemi, zvyšuje to nároky na obsluhu, relativně jednoduše lze vyrobit nesmrtelné transakce, které mohou držet zámky, a dělat další neplechu. Navíc to zvyšuje komplexitu systému. Bere se to jako nutné zlo. V 90 letech se čekalo, že vše se bude programovat skrz distribuované objekty - viz např. DCOM, CORBA nicméně moc se to neosvědčilo, ukázalo se, že přístup přes API - SOAP, REST je mnohem praktičtější.

205

Server / Re:Jak databáze řeší indexy?

« kdy: 19. 02. 2019, 17:56:27 »

... Pokud nestačí cache, tak přepisuji nejdéle nepoužité stránky...

To by byl poněkud neefektivní algoritmus. Doufám, že v Pg je jiný.

Přesněji https://madusudanan.com/blog/understanding-postgres-caching-in-depth/

206

Server / Re:DB - ako riesia indexy?

« kdy: 19. 02. 2019, 17:53:25 »

Předpokládám, že se tady bavíme o indexech nad jednou tabulkou.

Index nad více tabulkami? Tím máte na mysli co? Napadá mě snad jedině index nad zhmotněným pohledem..?

V rámci jednoho dotazu můžete mít více indexů nad různými tabulkami. Některé databáze umí, pro urychlení JOINu, jeden index pro více tabulek, ale to jsem tady nemyslel. Jak jsem psal - upřesňoval jsem situaci, kdy se v dotazu nad jednou tabulkou má aplikovat více indexů.

207

Server / Re:DB - ako riesia indexy?

« kdy: 18. 02. 2019, 19:01:52 »

Ideální je, když databáze může pro porovnávání nebo řazení použít právě index. Pokud je dotaz napsaný tak, že databáze musí použít dva různé indexy, které vrátí zhruba stejné množství řádků, a následně je musí spojit (najít jen ty řádky, které jsou v obou indexech), je to jedna z nejnáročnějších operací, které může databáze s indexy dělat.

Předpokládám, že se tady bavíme o indexech nad jednou tabulkou. Samozřejmě, více sloupcový index je efektivnější než dva jednousloupcové - nicméně spojení indexů zas až tak drahá operace není - v Postgresu se používá bitmap heap scan. To už kdysi umělo FoxPro. Tam hodně zaleží na datech, jak spolu korelují hodnoty ve sloupcích. Jsou situace, kdy je bitmap heap scan pomalý, ale ve většině případů je postačující. Každý index něco stojí - zpomaluje inserty, update, a je dobré jich mít co nejméně.

208

Server / Re:Jak databáze řeší indexy?

« kdy: 18. 02. 2019, 18:52:36 »

Jak indexy, tak tabulky jsou na disku organizované pomocí stránek - vždy se načítají celé stránky a ukládají se do interní cache datových stránek - v Postgresu shared buffers, která je omezena počtem. Zpracování probíhá často po stránkách, načtu minimální sadu indexových stránek, abych se dostal k listům, získám adresy, a pro každou adresu dohledám záznam ve stránce, která už je v cache, nebo kterou musím načíst do cache. Pokud nestačí cache, tak přepisuji nejdéle nepoužité stránky. Díky tomu mohu provést operace nad tabulkami, které se mi ani náhodou nevejdou do RAM - za cenu, že některé stránky načítám z disku opakovaně. U datových stránek to nemusí být až takový problém. Naopak u klíčových (kořenových) stránek indexu to může mít fatální dopad na výkon.

I z tohoto důvodu má Postgres horní omezení velikosti použitého indexu. Pokud by hrozilo velké riziko, že index se nevejde do cache Pg případně FS cache, tak se prostě nepoužije, a úloha se provede sekvenčně - na což v podstatě není potřeba skoro žádná RAM.

209

Distribuce / Re:Distroturizmus na desktopu

« kdy: 12. 01. 2019, 19:33:08 »

Když jsem ještě gamesil, tak moje typická konfigurace byla RH na serveru, Win na desktopu + Putty. Od 2003/2004 v podstatě na všem, co jsem měl, jsem měl RH nebo Fedoru už v roli desktopu - jsem asi typický spokojený Gnomista - u Gnome 2 jsem si ještě hrál s tématy, u Gnome 3 už mi i default vyhovuje. Na noteboocích, které mám - Toshiba a T520 v současnosti nemám jediný problém - uznávám ale, že co se týče desktopu jsem nenáročný. Zkusil jsem párkrát KDE, ale to není moje krevní skupina. A když mám nabootovat do Win10, tak mám husí kůži.

210

Vývoj / Re:Proč je syntaxe programovacích jazyků tak složitá?

« kdy: 06. 01. 2019, 21:40:41 »

skoda ze Wirth nedotahnul PL/O do stavu plnohodnotneho jazyka, kompletni ucebnice na 17 strankach je uzasna ale k nicemu (je to hodne osekana verze pascalu)


https://www.dropbox.com/s/iy1xm8bhd38x8r0/PL0%20User%27s%20Manual.pdf?dl=0

Tím dotaženým jazykem je Oberon nebo Oberon/0