Letos v květnu
Tradičním termínem konání konference Prague PostgreSQL Developers' Day (P2D2) bývá únor, v letošním roce se konference výjimečně konala až v květnu. Souviselo to s tím, že Praha koncem loňského října přivítala velkou, celoevropskou konferenci PostgreSQL Conference Europe. Její přípravy znamenaly pro CSPUG (Czech and Slovak PostgreSQL Users Group) a zejména pro její představitele Tomáše Vondru a Pavla Stěhuleho velké nasazení. Příští P2D2 už se bude konat opět v tradičním únorovém termínu.
Přečtěte si reportáž z pražské PostgreSQL Conference Europe: středa, čtvrtek, pátek, související rozhovory.
Konference začíná
Konference P2D2 se konala na obvyklém místě, tedy v budově Matematicko-fyzikální fakulty Univerzity Karlovy na Malostranském náměstí (bývalý Profesní dům postavený Jezuity). Program začal ranním workshopem ještě před prezencí. Při prezenci každý účastník „vyfasoval“ skleněný hrnek – jak jinak, než se slonem typickým pro PostgreSQL. Po celý den byla možnost zakoupit trička a další propagační předměty.
Samotnou konferenci zahájil příchod modrého slona do téměř zcela zaplněného sálu. Slon zcela zaslouženě získal velký potlesk, který pokračoval i poté, že se uvnitř slona nachází Tomáš Vondra. Ten se vzápětí – ještě částečně ve „sloním“ – ujal úvodního slova. Kromě organizačních záležitostí se věnoval hlavně zhodnocení podzimního pořadatelství evropské konference (považoval tuto konferenci za velmi povedenou, s čímž z pohledu účastníka zcela jednoznačně souhlasím).
Přednášky
Novinky a vylepšení v PostgreSQL 9.3
Rychlým tempem se blíží vydání PostgreSQL verze 9.3 (v době konference je ve fázi Beta 1) a proto Pavel Stěhule představil to nejvýznamnější, co tato verze přináší. Z provozního hlediska jsou to tři věci. V první řadě je to vylepšení zamykání s rozlišení na klíčové a neklíčové atributy. Cílem je zvýšit výkon v případech, kdy se používá referenční integrita a zabránit situacím, kdy by mohlo dojít k deadlocku.
Druhou provozní novinkou jsou kontrolní součty datových stránek. Řada databázových systémů je má už dávno, u PostgreSQL to byla věc nízké priority, protože integritu na této úrovni běžně řeší úložné zařízení a souborový systém. Nicméně vzhledem k tomu, že po této funkci byla poptávka, dočkala se implementace. Třetí z těchto novinek je mnohem jednodušší rekonfigurace slaves v případě výpadku mastera (u master-slave replikace, kdy je více než jeden slave). Dosud to znamenalo relativně složité ruční nastavování.
Z pohledu vývojářského je ve verzi 9.3 novinek ještě podstatně víc. Například aktualizovatelné a materializovatelné pohledy jsou věci, které v PostgreSQL dlouhodobě chyběly a musely se určitým způsobem emulovat (aktualizovatelné pohledy pomocí triggerů INSTEAD, materializovatelné pomocí CREATE TABLE AS apod.). Přibyla také klauzule LATERAL (umožňující použít výsledek jednoho dotazu v jiném na stejné úrovni vnoření), DDL triggery (reagující na změny v definici dat, např. vytvoření tabulky), parser pro JSON (výhodný pro přímý přístup k datům v JSON notaci uvnitř atributu), pracovní procesy běžící na pozadí (odpadá nutnost volat databázové operace např. z cronu) nebo podpora aktualizace dat ve FDW (dosud byly jen ke čtení).
Změny se odehrály i směrem ke většímu výkonu – byly zrychleny operace s typem NUMERIC, přibyly statitiky pro typ RANGE, indexy pro regulární výrazy a unlogged (tj. nejdoucí přes transakční log – při havárii jsou odstraněny) GiST indexy.
Na závěr přednášky přišla i krátká ukázka toho, co se očekává pro verzi 9.4. Kromě různých výkonových optimalizací je to například zabezpečení na řádkové úrovni nebo možnost vnořování typu HSTORE (hashová mapa v atributu, zatím je jen jednoúrovňová).
Verzování a publikace dat na webu za pomoci PostgreSQL
Na druhou přednášku nastoupil Jan Pěček s cílem ukázat řešení, které se v mediální skupině MAFRA implementuje pro účely katalogu firem TOPkontakt.cz. Katalog funguje tak, že může změny v datech provádět buď operátor nebo přímo daná firma, přičemž každá změna podléhá schvalovacímu procesu (kdy je možné ji schválit nebo zamítnout) a je třeba ukládat kompletní historii změn. Data se nepublikují na web přímo, exportují se do jiné databáze s tím, že se ještě slučují z daty z jiných zdrojů.
Při implementaci bylo třeba řešit několik významných problémů. První je tzv. „problém uživatele“ – tedy jak zajistit, aby spouštěné triggery věděly, kdo aktuálně provádí změny. Řešení je několik, například namapování aplikačních uživatelů na databázové, dočasná tabulka, použití PL/Perl nebo custom_variable_classes. Každé řešení má své výhody a nevýhody, každé se hodí v jiné situaci.
Druhým problémem, s nímž se vývojáři potýkali, byl výběr vhodného řešení pro ukládání verzí. Opět je tu více možností, zvoleno bylo ukládání jednotlivých hodnot (z různých sloupců v různých tabulkách) do jediné „žurnálové“ tabulky, a to ve formě nově deklarovaného typu changeset, skládajícího se z názvu sloupce, ze staré a nové hodnoty. Pro tento typ byla vytvořena funkce na test rovnosti a nadeklarován příslušný operátor.
Při implementaci bylo potřeba si dát pozor hlavně u revertování změn (vrácení zpět při neschválení apod.) – na zajištění integrity a konzistence dat, řádnou implementaci výjimek z obecných pravidel atd. Do budoucna se také počítá s tím, že současný stav, kdy se z takto fungující databáze PostgreSQL data k publikaci na web přenášejí do MySQL, změní na výhradní použití PostgreSQL a celý systém bude snadněji spravovatelný (úplně původní řešení dokonce mělo MySQL jako základí databázi a na web se publikovat přes Firebird, později proběhlo několik změn do současného stavu).
Pagination Done the PostgreSQL Way
Jediným zahraničním hostem konference byl letos Markus Winand (v dřívějších letech bývali obvykle dva přednášející ze zemí mimo ČR a SR). Je mimo jiné autorem knihy SQL Performance Explained, která se neváže ke konkrétní databázi a je zajímavá pro každého, kdo to myslí vážně s laděním výkonu databází. Markus přednášel samozřejmě anglicky, ale drtivá většina účastníků zjevně neměla žádné problémy s porozuměním přednášce.
Přednáška byla věnována problematice stránkování výsledků dotazů z hlediska výkonu. Oblíbené klauzule LIMIT a OFFSET vedou totiž na doslova prachbídný výkon, což se projevuje při dotazech na tabulky s větším množstvím dat. Příčinou je způsob, jakým se s daty pracuje. Ani příliš nepomáhá, pokud je k dispozici index (přestože k určitému zrychlení dojde) – operační složitost je vždy v zásadě lineární a na reálných datech mohou dotazy trvat skutečně dlouho.
Stránkování lze podstatně vylepšit tím, že se pomocí WHERE z výsledků předem odstraní ta data, která se objevila na předchozích stránkách (např. pokud se řadí podle času vzestupně, odstraní se všechny řádky se starší časovou hodnotou). Lze využít i porovnávání tzv. řádkových neboli kompozitních hodnot (podpora v PostgreSQL je od verze 8.0; výrazně se tím zjednodušuje zápis složitějších podmínek).
Toto řešení přináší výrazné zvýšení rychlosti i bez indexu na řadicích sloupcích (i když lineární složitost zůstává), zvlášť dobré výsledky však dosahuje v kombinaci s indexem. Má však také nevýhody – tou hlavní je, že ho lze použít pouze při postupném stránkování. Nelze libovolně skákat po stránkách, protože pak neznáme hodnoty z předchozích stránek.
Co s tím? Jednou z „elegantních“ možností je nahradit klasické stránkování postupným rozbalováním obsahu, jak ho známe například ze sociálních sítí a mnohých dalších webů. Tam se další stránky načítají vždy postupně a není potřeba se vracet zpět (předchozí stránky jsou již načteny výše).
Na závěr přišlo malé rýpnutí do jiných databází (než je PostgreSQL). Z matic podpory různých funkcí v různých databázových systémech bylo vidět, že z hlediska řádkových hodnot a indexů na řadicích sloupcích je na tom PostgreSQL nejlépe a ostatní mají co dohánět (zejména systém MySQL dopadl dost nelichotivě).
Užitečné, ale opomíjené extenze
Po obědě (který má na P2D2 v posledních letech formu rautu) přišlo „odpočinkové“ téma v podání Tomáše Vondry. PostgreSQL má již v základu k dispozici pořádný balík rozšíření, další lze potom získat od jiných tvůrců (například přes repozitář pgxn.org). Tato rozšíření přidávají různé více či méně užitečné funkce, často takové, které by leckdo očekával v základním systému (kam ale nebyly z nějakého důvodu přidány).
Například rozšíření btree_gin a btree_gist umožňují vytvořit GIN, resp. GiST index nad skalárními typy (běžně se používají B-stromové indexy nad skaláry a GIN/GiST nad vektory). Rozšíření hstore přidává datový typ HSTORE (hashovou mapu klíč–hodnota) jakožto hodnotu atributu. S klíči a hodnotami lze pracovat přímo, bez nutnosti celou tabulku nejdřív extrahovat.
Rozšíření ltree se hodí pro situace, kdy je potřeba ukládat do databáze stromovou strukturu (například hierarchii kategorií). S klasickým řešením se velmi obtížně pracuje a ani není efektivní. Zde se však hierarchie ukládá jako cesta k uzlu a dá se s ní přímo pracovat v dotazech (klasicky i fulltextově).
pg_stats_statements odstraňuje některé neduhy monitorovacího nástroje pg_stat_activity, kterým prakticky nelze sledovat krátké dotazy. pg_stats_statements umožňuje sledovat celou řadu parametrů při provádění dotazů. Rozšíření pg_trgm pracuje s tzv. trigramy, tedy trojicemi písmen ve slovech. Umožňuje například zjišťovat podobnost/odlišnost různých slov.
Rozšíření quantile již patří k těm „externím“ (mimo PostgreSQL) a jeho autorem je sám Tomáš Vondra. Zavádí nové agregační funkce, kterými lze zjednodušit psaní dotazů pro výpočet statistických kvantilů. pg_reorg je rozšíření pro údržbu databáze – dokáže odstranit i běžně neodstranitelný balast (po aktualizaci indexů) a navíc neprovádí agresivní zamykání (pozor však na to, že není kompatibilní s DDL operacemi).
pg_partman je rozšíření snažící se trochu vylepšit zatím nepříliš pohodlnou práci s partitioningem. Stará se o správu partitioningu a zajišťuje dědění vlastností z rodičovské tabulky (v PostgreSQL je partitioning řešen pomocí dědičnosti tabulek). Pokud jeho vlastnosti pasují na konkrétní případ použití, může být dobrým pomocníkem.
Tomáš Vondra zmínil i další užitečné extenze, například plv8 (javascriptový engine V8), semver (sémantické verzování), s3_fdw (Foreign Data Wrapper pro úložiště Amazon S3) a pár dalších. Vzhledem k počtu existujících rozšíření samozřejmě nemohla být přednáška ani zdaleka vyčerpávající.
Co jsou základy databází a jak je učit?
Následující přednáška se stala – a měla stát – spíše diskusí. Michal Valenta, odborný asistent z FIT ČVUT (dříve působící na FEL ČVUT), chtěl totiž rozpoutat diskusi ohledně toho, jak v dnešní době učit základy databázových systémů. Ve své výuce zatím vychází především z klasického přístupu, kdy se věnuje poměrně hodně času konceptuálnímu modelování a relační algebře, o něco méně jazyku SQL a úplně nejméně pak připadne na „ostatní“ databáze (klíč–hodnota, proudové, grafové...).
A právě v rámci diskuse se mělo dojít k tomu, co případně přidat, co vypustit a co učit jinak. Povedlo se to? To je samozřejmě věc názoru. Nicméně panovala vcelku shoda, že (nejen) studenti zhusta přistupují k databázím jako k černé skříňce a nevědí, co (a proč) se děje uvnitř. V praxi to pak vede k nevhodné práci s databázemi, kdy trpí zejméně výkon. Proto by součástí výuky mělo být v určité míře i to, jak databázové systémy vlastně fungují (třeba co je to prováděcí plán apod.) a co od nich očekávat. Neuškodilo by také, aby byli studenti konfrontováni s velkou databází, která na rozdíl od malých výukových příkladů „potrestá“ každý poklesek ohledně správného používání.
Load dat do PostgreSQL
Po diskusi bylo možnost načerpat ztracené síly při coffee breaku a pak se opět soustředit na prezentované téma. Tím bylo velkoobjemové načítání dat do PostgreSQL. Kdo se účastnil podzimní mezinárodní konference, mohl v tom mít už docela jasno (resp. přednášku úplně vynechat, protože byla obsahově stejná jako ta podzimní). Pro ostatní šlo ale o téma navýsost zajímavé, byť nenabídlo žádné dokonalé, univerzální řešení.
Základními metodami jsou samozřejmě ty nativní, tedy INSERT+UPDATE a COPY. Mají ale řadu nevýhod – například nedokáží očistit data od chybných hodnot, navíc při první chybě skončí celá transakce a nic se nenačtě. Příkazy INSERT a UPDATE navíc vyžadují pouze klasickou syntaxi, čili data ve formátu CSV nelze bez předzpracování přímo vkládat (COPY je vkládat umí, ale ostatní nevýhody zůstávají a navíc je problém, pokud už v tabulce data jsou). Nelze zapomenout ani na nepříliš vysokou rychlost; vkládání lze sice urychlit vypnutím indexů, ale pokud na téže databázi současně probíhají dotazy, může to přinést jejich neúnosné zpomalení.
Další metodou je využití FDW (konkrétně file_fdw) a zapisovatelných CTE. Ale i tato metoda trpí nízkým výkonem. A konečně posledním způsobem je externí nástroj: pg_bulkload. Ten je v současné době nejrychlejší metodou, jak dostat data ze souboru do databáze. Největší rychlosti lze dosáhnout v režimu direct, kdy data nejdou přes transakční log. Nevýhodou je ale riziko poškození dat (pokud by načítání selhalo například kvůli výpadku napájení).
Elasticsearch
Poslední přednáška byla „dvoumužná“ – vystoupili totiž hned dva přednášející najednou (Jan Král a Karel Minařík). Na rozdíl od jiných podobných případů, kdy si více lidí rozdělí přednášku na ucelené bloky prezentované jedním člověkem, tady se odehrávalo něco podobného, jako třeba v televizních zprávách se dvěma moderátory. Na škodu to nebylo, spíše to na konci dne přispělo k lepšímu udržení pozornosti.
elastic
Elasticsearch není databáze, nýbrž vyhledávací a analytický engine pro velké objemy dat v cloudu. Je postaven nad Apache Lucene, jeho datovým formátem je JSON a komunikačním rozhraním protokol HTTP (REST). Hlavní doménou Elasticsearch jsou jednoduché i složité dotazy, které lze snadno formulovat v URL. Umožňuje také snadno realizovat všelijaké ty vyhledávací pomůcky (našeptávače, nápovědy při zřejmě chybných dotazech apod.), které potkáváme ve vyhledávačích.
„Cloudovost“ Elasticsearch se projevuje tím, že když se spustí další instance, v závislosti na konfiguraci se na ni rozdistribuují data a lze tak bez většího úsilí snadno nastolit stav vysoké dostupnosti dat. Při výpadku uzlů se automaticky reorganizuje tak, aby byla zachována nastavená dostupnost a bezpečnost dat.
Lightning talks
Častou součástí konferencí bývají tzv. lightning talks, tedy krátké přednášky na určité téma. Na P2D2 byl stanoven časový limit 7 minut na přednášku, přičemž snad nikdo ho nevyčerpal celý. Naplánovány byly čtyři přednášky, během nich se přihlásil ještě pátý řečník.
Jako první vystoupil David Turoň a v rychlosti popsal využití datového typu HSTORE pro logování. Tento typ je pro dané účely zvlášť vhodný díky pružnosti použití za současné možnosti snadno přistupovat k datům.
Marek Sušický potom s rychlostí (slovního) kulometu představil vizualizační nástroj SVAT. Ten umožňuje získávat data z mnoha datových zdrojů (databázových i jiných) a přehledně je zobrazovat v grafech podle souvislostí. Typickým příkladem použití je třeba vizualizace vztahů mezi firmami a osobami.
Třetí minipřednášku měl Jan Horák a týkala se (nejen) PostgreSQL v Software Collections. Tento nástroj řeší problém s tím, že při běžném používání balíčkových systémů většinou nelze mít nainstalováno více verzí téhož softwaru. SC instaluje software do samostatných podadresářů /opt a může ještě zajišťovat takové speciality, jako že se u PostgreSQL používá pro všechny verze společná klientská knihovna (ta z nejvyšší verze).
Chcete-li si zkoušet práci se SQL (definice tabulek, vkládání dat, dotazy...) bez nutnosti instalovat si danou databázi, můžete využít webový nástroj SQL Fiddle, který představil Markus Winand. Dotazy lze nejen zkoušet, ale například si také prohlédnout jejich prováděcí plán.
Poslední lightning talk (nad původní plán) byl zaměřený na hardwarovou podporu databázových operací – ta se v poslední době objevuje nejen v procesorech, ale také například v diskových polích. Výkon databázových systémů tak bude zřejmě do významné míry záviset na tom, jak budou toto schopny využít.
Zhodnocení konference
Konference P2D2 se stala významným bodem na mapě českých odborných konferencí. Kvalitní přednášky a dobře fungující organizace se odrážejí ve velkém zájmu účastníků a kapacita sálu je omezujícím faktorem, který brání v účasti ještě většího počtu zájemců. Současně by konference jistě „snesla“ větší počet přednášek (a také workshopů, o jejichž přidání již organizátoři uvažovali), nejspíš by se pro ně našli i přednášející. Je tedy otázkou, zda by třeba konferenci neprospělo rozdělení do dvou streamů, jednoho teoretičtějšího a druhého praktičtěji zaměřeného.
