Na Fakultě informačních technologií ČVUT v Praze se 12. února konala tradiční konference Prague PostgreSQL Developers Day (P2D2), zaměřená na databázový systém PostgreSQL a další témata, která s ním souvisejí. Konferenci každoročně pořádá sdružení CSPUG.
Tentokrát se konference konala v prostředí letos hojně využívaném pro konference tohoto typu: na Fakultě informačních technologií ČVUT. Vlastní konferenci tentokrát předcházel ještě jeden „výukový den“, do něhož organizátoři umístili čtyři workshopy (v předchozích letech býval krátký workshop ráno před konferencí).
Registrace na P2D2
Hlavní novinky v PostgreSQL 9.4
Po oficiálním zahájení ukázal Tomáš Vondra nejvýznamnější novinky v PostgreSQL 9.4. Patří k nim například vylepšené agregační funkce, paralelní aktualizace materializovaných pohledů, vylepšení indexů GIN, podpora ALTER SYSTEM (namísto nutnosti měnit ručně konfigurační soubor), nové konfigurační parametry, rozšíření pg_stat_statements, nové možnosti replikace nebo infrastrukturní změny (např. pracovní vlákna nebo replikační sloty).
Účastníci konference P2D2
Tomáš Vondra též připomněl, že je řadě 9.4 už k dispozici i první opravná verze: 9.4.1. Pozval také účastníky na evropskou konferenci PostgreSQL Conference Europe, která se letos bude konat ve Vídni.
JSONB / ukládání nestrukturovaných dat
Binární JSON (BSON, JSONB) je velkou chloubou nové verze 9.4 a proto byla tomuto datovému typu a ukládání nestrukturovaných dat věnována přednáška Pavla Stěhuleho. Cesta do PostgreSQL však byla dlouhá a znamenala postupně řadu kroků, například zavedení TOAST (verze 7.1, rok 2001), typ hstore, přidání XML a indexů GIN nebo přidání podpory pro JSON.
Přednáška o binárním JSON
Pavel Stěhule zdůraznil, že i když je podpora pro JSONB k dispozici a umožňuje práci nejen variabilní a flexibilní, nýbrž i relativně rychlou, pro strukturovaná data by se měl vždy přednostně používat klasický relační přístup (a že NoSQL už znamená spíše "not only SQL" než "no SQL"). "Variabilita je smrtelná zbraň," řekl doslova. Nemělo by se zapomínat ani na datový typ hstore, jenž je v PostgreSQL už poměrně dlouho a umožňuje efektivně pracovat s daty typu klíč-hodnota.
Nestrukturovaná a senzorová data
Na předchozí přednášku navázal tou svou Vratislav Beneš. Hovořil o projektu, kde se kromě různých vlastních řešení zkoušela i databáze MongoDB a po vydání PostgreSQL 9.4 se otestovala i tato databáze. Ukázalo se, že MongoDB byla vždy pomalejší při vkládání dat. Při čtení dat byla rychlá v případě, že se data vešla do paměti; jakmile tato podmínka nebyla splněna, zvítězila v rychlosti databáze PostgreSQL.
Vratislav Beneš: Nestrukturovaná a senzorová data
Architektura daného řešení byla navržena jako dvouúrovňová, kde byla různá data uložena na samostatných uzlech, ke kterým se přistupuje z aplikačního serveru přes společný uzel prostřednictvím postgres_fdw (jedná se o "mrtvá" analytická data, není třeba řešit transakce).
Nestrukturovaná data vznikají dnes z mnoha zdrojů (např. síťových prvků, zařízení pro automatizaci nebo počítačového vidění) a je důležité vědět, co a jak v nich hledat a jak informace měřit. Od toho se pak odvíjí, jak se s daty pracuje (fulltext, regulární výrazy...). Pokud se pro uložení využívá JSON, je potřeba definovat atributy, jejich hodnoty a metriky.
Jak přežít sharding
Sharding je horizontální dělení databáze a má za cíl rozkládat zátěž na více strojů prostřednictvím samostatných databázových systémů. Existují různé přístupy, například jednoduchý používaný u NoSQL nebo přístup MapReduce (známý například u Apache Hadoop). Při distribuci dat napříč uzly (shardy) lze dát všude všechno (vhodné pro číselníky), distribuovat podle klíče apod.
Jak přežít sharding
Aliaksandr Aliashkevich popsal, jak sharding funguje a jaké jsou technologické možnosti pro PostgreSQL (co je aktuálně dostupné). Mezi rozšířená rešení patří například Pl/Proxy, Pgbouncer a Skytools, z "alternativních" pak například PgPool, Pg_shard, Postgres XL a další. Databáze se shardingem je však třeba také nastavit a monitorovat - i tady existuje mnoho nástrojů, například Ansible, Collectd, Graphite nebo Graphana, z obecných monitorovacích nástrojů pak třeba Zabbix nebo Munin (které ale často nelze efektivně použít).
Securing your PostgreSQL application
Po obědě přišel čas na první přednášku v angličtině. Marc Balmer (podobnost se Stevem Ballmerem, jenž dříve šéfoval firmě Microsoft, je čistě náhodná) hovořil o zabezpečování PostgreSQL z pohledu aplikačního programátora. U dat v databázích je riziko jejich úniku, nechtěné manipulace nebo jejich zničení. K útoku může dojít například přes SQL injection nebo přes získání shellového přístupu (administrátorského, ale i obyčejného) ke stroji s databází.
Marc Balmer hovoří o zabezpečení databáze
Pro prevenci SQL injection je třeba důkladně ošetřovat všechny vstupy (pomocí prepared statements, parametrizovaných příkazů, případně escapování), které se použití v SQL příkazech. Nebezpečné řetězce mohou přijít například i z webových cookies nebo z čárových kódů.
V PostgreSQL clusteru je třeba si dát pozor na to, že jakékoli uživatelské role v clusteru se mohou připojovat k databázím a mít přístup ke schématu public, které je standardně veřejné. Pokud se přístup řeší až na aplikační úrovni, může chyba v aplikaci vést k umožnění neoprávněné operace. Přístup by se měl řešit na úrovni databáze, různé části aplikace by měly využívat modelové role s právy definovanými na nejmenší možné úrovni a využívat schémata pro oddělení samostatných částí databáze. Podobně je žádoucí omezit i samotný přístup k databázi. Při přístupu anonymního uživatele je vhodné nedávat aplikační roli vůbec práva pro SELECT, nýbrž vytvořit přístupovou funkci a zpřístupňovat data na základě řetězce relace (session).
BDR - Bi Directional Replication
Obousměrná replikace patří k často poptávaným databázovým funkcím. O jednom takovém řešení, nazvaném BDR, hovořil ve své přednášce Petr Jelínek. Toto řešení je implementováno jako rozšíření PostgreSQL a mezi jeho hlavní vlastnosti patří asynchronní chování, relativně snadné nastavení, nízká režie, snadný failover/failback nebo podpora geograficky distribuovaných databází (tedy s velkou latencí).
BDR - Bi Directional Replication
V porovnání s jinými replikačními řešeními (Slony, Londiste, Bucardo) je BDR výrazně výkonnější. Konfigurace spočívá prakticky jen z vytvoření skupiny, resp. přidání do skupiny pro replikaci. Pro prevenci konfliktů BDR využívá globální sekvence a UPSERT logiku. Pokud už ke konfliktu dojde, použije se vestavěná funkce "poslední změna vyhrává", případně uživatelsky definované funkce (konflikty včetně dat lze zapisovat do tabulky).
BDR zatím vyžaduje patch PostgreSQL, v budoucnu by se mohly potřebné změny dostat přímo do PostgreSQL. Verze bez patchů (UDR) nepodporuje multi-master replikaci, transparentní DDL replikaci a některé další věci. V budoucnu by měla technologie BDR podporovat plně synchronní replikaci, filtraci akcí pro jednotlivé tabulky a možnost komplexní topologie uzlů.
Lehký úvod do PostgreSQL na Amazon Web Services
Cloudová řešení jsou trendem dneška a tomu, aby využívání PostgreSQL bylo v cloudovém prostředí snazší, se pokusil svou přednáškou pomoci Štěpán Bechyňský. Řeč byla o "databázi jako službě" (tj. jedné z forem platformy jako služby, PaaS), kdy poskytovatel cloudu - tedy v tomto případě Amazon - nabízí přístup k databázovému systému definovaných parametrů.
PostgreSQL lze provozovat i formou PaaS v cloudu AWS
Především je třeba správně naložit s právy uživatelů v rámci infrastruktury (nejedná se o databázové uživatele) - lze, a je vhodné to udělat, vytvořit uživatele s omezenými právy pro určité úkony. Co se týká vlastní databáze PostgreSQL, AWS aktuálně nabízí dvě verze řady 9.3 (alternativou je si v rámci EC2 spustit virtuální server s databází, pokud je potřeba něco speciálního, například nějaká rozšíření).
Při vytváření databáze je potřeba vybrat virtuální stroj (počet jader CPU a paměť). Je dobré začít od nejslabšího stroje a pak případně navyšovat. "To je podstata cloudu," říká Štěpán Bechyňský a připomíná, že opačné myšlení (nesprávné, začínající u nejvýkonnějších strojů) je stále hojně rozšířené. Mezi stroji lze prakticky volně přecházet, některé parametry databáze ale měnit nejtde a například při zapnutém šifrování nelze přesouvat databázi do jiného komuunikaci navenek.
Spravovat (nejen) databáze PostgreSQL v AWS lze nejen ve webové konzoli, ale také prostřednictvím nástrojů pro příkazovou řádku nebo i z aplikací (Amazon SDK).
When PostgreSQL Can't You Can
Tam, kde PostgreSQL končí, nastupujete vy. Takové bylo heslo, s nímž před účastníky konference předstoupil Keith Fiske. Občas je totiž potřeba něco, co v PostgreSQL není, ale přitom to potřebujete - pak často nezbývá, než se do toho pustit vlastnoručně.
PostgreSQL už nemůže dál? Vy ale určitě můžete...
Typickou možností jsou například rozšíření. Keith Fiske na přednášce prezentoval rozšíření, která takto vytvořil. Pg_extractor je něco jako "chytřejší pg_dump", přidávající především velmi silné filtrační schopnosti. Pg_partman je správce oddílů, který zvládne spravovat oddíly založené na čase i na serial ID. Rozšíření pg_jobmon umožňuje sledovat běh funkcí (po definovaných krocích) a pokud tyto selžou, zjistit kde a proč se tak stalo. Mimeo je nástroj pro logickou replikaci na tabulkové úrovni, který například nevyžaduje administrátorská práva, snadno se zprovozňuje a podporuje více typů replikace.
cstore_fdw
Poslední přednáška byla zaměřena na rozšíření cstore_fdw, tedy na wrapper pro přístup ke sloupcové databázi ukládané do modifikovaného formátu ORC (Optimized Row Columnar). O rozšíření hovořil Jan Holčapek, s tím, že ho ve firmě GoodData nepoužívají produkčně (pro ostrý provoz), ale že ví o ostrém nasazení v praxi (u jednoho z účastníků konference).
Sloupcová databáze v PostgreSQL
Zprovoznění cstore_fdw se v zásadě neliší od jiných FDW. Wrapper zatím nemám implementovány běžné DML operace, data se musí vkládat pomocí COPY. Sloupcová databáze je pro určité typy dotazů výrazně rychlejší než ta klasická relační, navíc zabírá podstatně méně místa na disku. Své zkušenosti s tímto wrapperem popsal také Pavel Chocholouš, který si chválí jak kompresi a díky tomu výraznou úsporu místa, tak i rychlost, která je podle něj někdy až stokrát vyšší než u nativního způsobu uložení, běžně však zhruba třikrát. Naopak jsou problémy s paměťovou náročností.
Organizace, občerstvení ... a celkové zhodnocení
Po organizační stránce byla konference výborně zvládnuta, jako ostatně i v předchozích letech (CSPUG pořádala v roce 2012 i velkou, celoevropskou konferenci PostgreSQL Conference Europe). Účastníci měli po celou dobu k dispozici bohaté občerstvení (a v poledne oběd), prostředí nabízelo dostatek prostoru pro setkávání.
Z hlediska celkového dojmu není ke konferenci moc co říci. Letošní ročník zcela udržel laťku vysoko nastavenou z minulých let. Skvělá organizace, kvalitní výběr i obsah přednášek a v neposlední řadě rozšíření workshopů – to jsou základní body, kterými lze letošní P2D2 charakterizovat. Lze právem očekávat, že i další ročníky budou přinejmenším stejně dobré.
Poznámka autora: Kdo se nechal vyfotit s maskotem PostgreSQL (modrým slonem) a měl by o fotografii zájem, nechť se ozve na adresu redakce@linuxexpres
cz.
