První CSPUG večerní databázové setkání

První večerní setkání organizované CSPUGem se uskuteční 19. 4. od 19.00 na MFF v S4 (Malostranské nám. 25, Praha). Na programu jsou tyto dvě přednášky: 19.00–19.45 Replikace a její stav v PostgreSQL (Tomáš Vondra) a 19.55–20.40 Záludnosti PostgreSQL (Jakub Ouhrabka). Krátké anotace a další informace najdete na této wiki stránce. Setkání jsou zdarma s volným vstupem, nicméně i tak prosíme o registraci pomocí formuláře a to zejména kvůli objednávce pizzy, sponzorované firmou ComGate.

25.3.2011 12:28 | TomasVondra | Pozvánky

Komentáře

[Shadow]

Vypadá to pěkně, nejspíš se půjdu podívat. Postgresu není nikdy dost.

[pht]

No např. já ho mám plný zuby :)

[Shadow]

To mě mrzí. Můžu se zeptat proč?

[pht]

Je to součet všech malejch bolestí co jsem s tím zažil:

1. Default konfigurace nastavená na výkon i486
2. Plánovač používá statistiky o tabulkách které jsou o několik řádů mimo realitu
3. Plánovač neumí kloudně rozhodnout o složitějších případech, musíme používat dočasné tabulky místo joinů
4. Mizivá podpora partitions
5. Nemožnost uchovávat data v indexu

[okbob]

1 je záměr - BFU v případě, že mu Pg nenaběhne je v ..., tudíž má PG nastaven bezpečný a exttrémně nízký shared_buffers. DBA si kdekoliv přečte, že tuto hodnotu je třeba změnit a dokáže změnit i SHMMAX.

2-3 to je více-méně problém všech SQL db - tady záleží na homogenitě dat, která zpravováváte, vzájemných závislostech - bezpochyby lze hodně vylepšovat UI v PostgreSQL - nyní jsem přepsal dotaz a zkrátil jej z 8000 ms na 30 ms - ale každá optimalizace stojí čas při připravě dotazu - čím sofistikovanější planner, tím je pomalejší. Z Open Source databází je pg, jak do přesnosti odhadů tak do kvality planeru o generaci před MySQL nebo Firebirdem - s komerčními db je srovnatelný s MSSQL. Co chybí je optimalizace pro OLAP nebo ROLAP. Takže na např. star schématu pg se nijak zvlášť nepochlapí ve srovnání s Oraclem nebo DB2.

4 - je tam základ, v 9.1 už funguje docela dobře (včetně indexování např. partišnama) - ale není to příliš user friendly

5 - by se občas hodilo.

[pht]

1 je záměr - BFU v případě, že mu Pg nenaběhne je v ..., tudíž má PG nastaven bezpečný a exttrémně nízký shared_buffers. DBA si kdekoliv přečte, že tuto hodnotu je třeba změnit a dokáže změnit i SHMMAX.

Ne -- není to jen buffers, jsou to všechny hodnoty a těch je asi 10 nebo 20. Na půlku z nich člověk potřebuje toho znát opravdu hodně, aby s nima dokázal efektivně pracovat. Na internetu se povalují stovky konfigurací typu "tohle mi funguje", ale já bych ocenil, kdyby člověk dostal několik oficiálních variant, ze kterých by si vybral.

Tím jak to je udělané teď se to řadí do kategorie programů, u kterých hned po instalaci musím do settings a všechno předělat, což je relikvie.

2-3 to je více-méně problém všech SQL db - tady záleží na homogenitě dat, která zpravováváte, vzájemných závislostech - bezpochyby lze hodně vylepšovat UI v PostgreSQL - nyní jsem přepsal dotaz a zkrátil jej z 8000 ms na 30 ms

No a my jsme zkrátili z 80 000 ms na 500 ms a to tak že před dotaz se dalo "set enable_seqscan off" a to podle mě není moc dobrá vizitka plánovače.

jak do přesnosti odhadů tak do kvality planeru o generaci před MySQL nebo Firebirdem

Ze svých znalostí internálií MySQL mám tušení že kdybych to zkusil tam tak to dopadne lépe, ale nezkusil jsem to.

4 - je tam základ, v 9.1 už funguje docela dobře (včetně indexování např. partišnama) - ale není to příliš user friendly

Máte k tomu nějaký link? Naposled co jsem četl (9.0) tak to neumělo skoro nic. Nebyly to partitions které by se chovaly jako tabulky včetně FK, ale byly to prostě rozkopírované tabulky (které si člověk musel rozkopírovat sám), neumělo to FK, a na plánovač se muselo s citem, aby pochopil kde nemusí prohledávat.

[okbob]

Myslím si, že PostgreSQL hodně dobře znám a pro základní konfiguraci stačí změnit cca 5 parametrů a je to posané v desateru konfigurace PostgreSQL. Ve složitějších případech - replikace či specifická zátěž je možné nastavit dalších 5-10 parametrů. Komentářů k parametrům je víc než dost, ale to asi není to co chcete. konkrétní čísla jsou problém - záleží na hw, zátěži, datech, jak je napsaná aplikace. Databázi nelze nastavit obecně bez znalosti aplikace. A musíte tomu rozumět, abyste věděl, čeho si všímat. Teď si dělám reklamu - nicméně PostgreSQL neškolím pouze já. V ČR je několik školení, kde se můžete naučit, tomu co je podstatné pro administraci databází.

Důvodů, proč se použije nebo nepoužije index je celá řada - primárně, že Vám nesedí statistiky nebo že je nešikovně napsaný dotaz, sekundárně že máte třeba dojebanou konfiguraci. Zase je řada důvodů, proč Vám nemusí sedět statistiky. Je vždycky nutné řešit konkrétní problém.

Neznám moc situací, kdyby MySQL lépe optimalizovala než Postgres. Ale ve většině případů bude MySQL optimalizovat hůře - dotazy na primární klíč budou v MySQL rychlejší díky clustrovanému indexu. Poddotazy, pohledy, korelované poddotazy budou rychlejší v PostgreSQL. V případě, že Vám hodně nesedí statistiky, tak jednodušší planer v MySQL může být výhodnější.

Partitioning - viz dokumentace PostgreSQL. Ohledně SELECTů si myslím, že je PA už v 9.1 bez problémů. Problémy jsou v INSERTech, UPDATEch, které rozhodně nejsou user friendly, a kde člověk můsí vědět, kam chce databázi dostat. pokud tomu člověk nerozumí, tak vymyslí pí....

[pht]

konkrétní čísla jsou problém - záleží na hw, zátěži, datech, jak je napsaná aplikace. Databázi nelze nastavit obecně bez znalosti aplikace. A musíte tomu rozumět, abyste věděl, čeho si všímat.

Zase je řada důvodů, proč Vám nemusí sedět statistiky. Je vždycky nutné řešit konkrétní problém.

člověk můsí vědět, kam chce databázi dostat. pokud tomu člověk nerozumí, tak vymyslí pí

S tím vším já souhlasím, ale to neznamená že bych měl být uvrhnut do doby kamenné a všechno si řešit sám - to je mi pak ta databáze k ničemu. Když ten program dělá chybu v jedné věci, tak si řeknu jasně, nic není dokonalé, ale když je to 5 věcí, tak to je zoufalství. A všechny hluboké znalosti o databázích, kromě toho, jít a přeprogramovat to, jsou k ničemu.

[okbob]

Když je aplikace napsaná na pytel, tak s tím nic moc neuděláte :(

Bohužel realita je taková, že programátoři toho moc o databázích a performance nevědí, takže nijak zvlášť netestují kritické operace na výkon při objemu dat, kdy už se uživatelé přetahují o cache nebo kdy už se musí používat external sort. Na začátku, kdy mají tabulky 100 000 a méně řádků, tak jsou všichni happy. Jenomže pak se překročí rubikon, a pak už se aplikace jenom zpomaluje, tak jak přibývají data. S tím ale DBA nic moc bohužel nenadělá. To podstatné z hlediska výkonu je zadrátováno v aplikaci, případně v návrhu aplikace.

[okbob]

Špatně jsem pochopil Váš nářek :)

Ideální databáze neexistuje. Třeba na predikci založenou na statistikách ani pořádně neexistuje teoretický model, který by neměl chyby (a jehož údržba by nezacyklila db natolik, že by už nic jiného nezvládla). To samé platí o planeru - při trochu větším počtu tabulek v JOINu se už musí používat heuristiky, které nemusí dohledat optimální plán. Malé databáze jsou v pohodě, ale optimalizace velkých databází je docela alchymie, která vyžaduje zkušenosti a intuici.

[pht]

Malé databáze jsou v pohodě, ale optimalizace velkých databází je docela alchymie, která vyžaduje zkušenosti a intuici.

No a to je přesně můj případ. Mám velkou databázi. Plánovač dělá kraviny, protože má špatně statistiky. Lze statistiky upravit? Ne. Lze použít partitions? Ne. Lze něco jiného? Ne. Jediná alchymie je znásilnit plánovač nastaveníma které hraničí spíše s kacířstvím.

[okbob]

Právě, že znásilňovat statistiky je špatně - i když v novějších verzích pg to v určitých případech lze. Partitioning používat lze. Tou správnou cestou je ovšem úprava dotazů, tak aby nedošlo k rozhození statistik. To, že nesedí statistiky má vždy svůj důvod - buď v konstrukci dotazu nebo v datech.

p.s. Někdy je člověk v pr... třeba na EAV prostě statistiky sedět nebudou nikdy poněvadž se míchají jabka s hruškama. Ale to je problém EAV, což je mimochodem jeden z nejhloupějších nápadů, které s kterými přišli programátoři a nikoliv problém SQL databází.

[JoHnY2]

Tím jak to je udělané teď se to řadí do kategorie programů, u kterých hned po instalaci musím do settings a všechno předělat, což je relikvie.

Oracle mi taky zrovna neprisel jako soft, kterej se jen nainstaluje a pracuje sam od sebe.

[s0]

na druhou stranu se ten jejich instalátor zeptá jestli chceš první DB instanci vytvořit jako OLTP nebo OLAP/DWH co si tak pamatuju. Jasně, pak se to stejně musí poladit, ale prvotní nastavení už máš.

[EtDirloth]

Budu z jednotlivych stretnuti podcasty? Potesilo by ma to uz len preto, ze som zmeskal P2D2 2011.