přejít na obsah přejít na navigaci

Linux E X P R E S, Reportáž z Prague PostgreSQL Developers' Day 2011: Odpoledne

Reportáž z Prague PostgreSQL Developers' Day 2011: Odpoledne

p2d2.png

Ve čtvrtek 10. února proběhl v prostorách MFF UK na Malostranském náměstí již čtvrtý ročník konference věnované svobodnému databázovému systému PostgreSQL. Ohlédněte se spolu s námi za odpoledními přednáškami.


Asynchronous Notifications for Fun and Profit

Marc Balmer

Po vysvětlení rozdílu ve jménech a spojitosti se stavem konta (Ballmer vs. Balmer) se Marc pustil do přednášky (opět v anglickém jazyce a opět velmi vtipné) o dalším nekonvenčním použití PostgreSQL serveru, tentokrát pro asynchronní zasílání zpráv mezi aplikacemi.

Ballmer vs. Balmer Ballmer vs. Balmer

Asi by bylo příliš laciné napsat, že Marc používá PostgreSQL server jako IM server pro „chat“ jedné aplikace s druhou, ale tak to v podstatě je. Má k centrálnímu serveru připojeno mnoho pokladem (tvoří systém pro pokladny v basilejské ZOO) a také pokladních terminálů pro zákazníky. Potřeboval nějakým způsobem upozornit terminál o změně dat na pokladně pro zobrazení údajů platícímu zákazníkovi v reálném čase.

Na místo vlastního aplikačního protokolu použil Marc příkazy LISTEN a NOTIFY, kdy zákaznické terminály poslouchají na vybraném kanále (registrace ke kanálu příkazem LISTEN) a jiná aplikace jim potom může poslat informaci o změně dat (příkazem NOTIFY) a terminál si z databáze načte aktuální data. V objektově orientovaném jazyce se jedná o návrhový vzor observer.

Marc Balmer Marc Balmer

Velmi zajímavým použitím této techniky je také možnost změny rozmístění jednotlivých zobrazovaných údajů na dotykovém displeji manažerem zahrady, která se díky NOTIFY projeví téměř v reálném čase na všech terminálech.

Každá nekonvenčnost je po zásluze potrestána, a tak Marc vysvětlil problémy s něčím, co nazval „notify injection“, což chce v následujících verzích řešit šifrováním zasílaných zpráv apod. Tak si říkám, jestli není lepší používat aplikační vrstvu a vlastní protokol.

Implementace funkcí v jazyce C

Pavel Stěhule

Předpokládá se, že většina účastníků konference o PostgreSQL ji navštívila především proto, aby se dozvěděla něco o tom, jak databázový systém lépe využít. Do této oblasti spadá i to, jak řešit situace, kdy samotný PostgreSQL něco nedokáže a je tedy třeba si poradit jinak. Jednou z takových možností je napsat si potřebné funkce v jazyce C, který je na všech platformách k dispozici a kód v něm napsaný (a zkompilovaný do nativního strojového kódu) je velmi rychlý.

O implementaci funkcí v jazyce C přednášel Pavel Stěhule ze sdružení CZ.NIC, který se databázovému systému PostgreSQL věnuje již od roku 1999. Jak sám řekl, kód v C pro PostgreSQL je něco, u čeho může leckdo zpočátku propadnout zděšení, že vůbec nejde o jazyk C – a to především proto, že se výrazně používají makra a celkově neobvyklý způsob práce s API.

Je jasné, že jedna třičtvrtěhodinová přednáška nemůže nikoho naučit novou technologii, přesto mohl být i takto krátký čas dostatečný pro poznání možnosti, jak výrazně zvětšit schopnosti PostgreSQL pro plnění zvláštních úkolů. Lze totiž nejen přidávat nové funkce, ale také nové datové typy nebo zpřístupnit funkce z nějakých specializovaných knihoven (využívá se např. u libxml2). První důležitou věcí však je uvědomění si, jaký styl programování se používá.

Namísto klasické volací konvence funkcí se využívá tzv. konvence V1, kdy se všechny parametry předávají vždy ve zvláštní struktuře, která umožňuje například snadno odlišit číslo nula od hodnoty NULL. Pro ukládání dat do této struktury a pro extrakci z ní se využívá sada maker. V některých případech (tehdy, pokud nelze přenést přímo hodnotu) se data přenášejí přes datový typ varlena, což je struktura obsahující délku dat a pak samotná data.

Další záležitostí související s implementací v C je alokace a uvolňování paměti. Zde se u PostgreSQL využívá mechanismus umožňující automatické uvolňování, který odstraňuje hrozbu úniků paměti v situacích, kdy někdo něco přehlédne. Toto řešení však podle Pavla Stěhuleho nebývá vždy správně pochopeno a občas se někdo ozve s hlášením „máte tam memory leaky“. Alokace paměti je vždy svázána s paměťovým kontextem – a když zanikne tento kontext, veškerá alokovaná paměť spojená s tímto kontextem se uvolní.

Na první pohled podivné a složité, přitom ale vlastně strašlivě jednoduché, takové je psaní funkcí pro PostgreSQL v jazyce C. Kdo udržel při přednášce pozornost (což samozřejmě může někdy být odpoledne před pauzou na kávu poněkud obtížnější), jistě získal dobré předpoklady k tomu, aby byl schopen zahrnout tuto oblast do škály toho, co lze s PostgreSQL dělat.

Firebird

Jiří Činčura

Stalo se na konferenci P2D2 již tradicí, že je jedna přednáška věnována některému z „konkurenčních“ databázových systémů. V ročníku 2011 to byl systém Firebird a pohovořil o něm Jiří Činčura. Databázový systém Firebird je svobodný software (šířený pod licencí IDPL, podobnou MPL) vycházející původně z databáze InterBase firmy Borland.

Jiří Činčura Jiří Činčura

Celá přednáška byla zaměřena na ty aspekty, kterými Firebird vyniká oproti jiným databázím, tedy v tomto případě hlavně PostgreSQL. Přednášející vše hned ukazoval na živých příkladech (co se týkalo použití v kódu, využíval kód v C# pro .NET, neboť je vedoucím týmu vyvíjejícího databázový ovladač právě pro tuto platformu).

První z popisovaných oblastí byla instalace systému, zejména její jednoduchost. Firebird totiž není potřeba instalovat, stačí ho stáhnout, rozbalit a spustit. Jiří Činčura představil všechny tři edice systému - Super Server (vláknový server sdílející většinu dat, nenáročný na paměť, bez možnosti využití SMP), Classic (procesový server, náročnější, využívající SMP) a nový Super Classic (vláknový server s omezeným sdílením, středně náročný, využívající SMP). Hned také ukázal, jak se Firebird spouští, a to jak jako běžná aplikace, tak jako služba (v systému Microsoft Windows).

Další část přednášky byla věnována edici Firebird Embedded, což je knihovna, kterou lze přilinkovat k aplikaci a plnohodnotně využívat databázi Firebird bez nutnosti mít spuštěný samostatný databázový server. Přednášející ukázal, jak se tato edice v programu používá a jak se použití liší od práce se samostatně běžícím serverem.

Účastníky konference nejvíce zajímalo, jak je na tom Firebird z hlediska podpory SQL standardů a jaká je jeho škála funkcí v porovnání se systémem PostgreSQL. Přišla odpověď: škála funkcí je menší (existují ale další knihovny s funkcemi), ze standardů SQL počínaje SQL-92 je implementováno jen něco, konkrétně to, na co byly požadavky od uživatelů. Nevýhodou také je, že není implementováno šifrování databázových souborů a že v systému není nativní podpora SSL/TLS.

Každý si tak mohl udělat poměrně dobrý obrázek o tom, v jakých případech by právě databáze Firebird mohla být tou správnou volbou. Nic na tom nemění ani pár vět Jiřího Činčury, které řada účastníků raději ani neslyšela: to když zdůvodňoval nepřítomnost šifrování tím, že jde o software s otevřeným kódem (jinak řečeno, že nelze realizovat „security through obscurity“).

SQL Puzzlers

Tomáš Vondra

Když už začala být za okny přednáškové místnosti Katedry softwarového inženýrství Univerzity Karlovy tma, pobavil nás Tomáš Vondra sadou takzvaných puzzlers, které můžete v PostgreSQL najít.

Puzzler je nějaký případ, kdy se například programovací jazyk chová jinak, než bychom očekávali. Pozor, nejedná se ale o bug, divné chování je způsobeno například požadavkem standardu, v tomto případě SQL standardu.

Tomáš předváděl na plátně ukázky SQL dotazů (od těch jednodušších po ty obskurní) a nabízel publiku několik možností výsledku. Při jeho přednášce se hodně zapojovalo publikum, šlo spíš o otevřenou diskuzi. Kdo uhodl správný výsledek, dostal od Pavla Háka (který je rozdával) slona. Přestože vše probíhalo česky, do hádání se zapojil i Magnus, který dokonce dva slony vyhrál. Nakonec jeden z návštěvníků vyhrál knihu PostgreSQL 9 Administration Cookbook.

Takto nějak vypadalo zadání Takto nějak vypadalo zadání

A zde je nečekané řešení A zde je nečekané řešení

Velice přínosné bylo to, že Tomáš neukazoval pouze, co se jak chová, ale především vysvětlil, čím je to způsobeno.

Pár slov závěrem

Letošní ročník P2D2 se rozhodně vydařil, přednášky byly zajímavé, přednášející v žádném případě nenudili. Musím poznamenat, že celá akce působila uvolněným dojmem, publikum bylo hodně aktivní a často na konci přednášek věcně diskutovalo s přednášejícími. Pokud se alespoň trochu zajímáte o PostgreSQL, rozhodně nevynechejte příští ročníky.

Autory článku jsou Tomáš Crhonek (Asynchronous Notifications for Fun and Profit), Lukáš Jelínek (Implementace funkcí v jazyce C, Firebird) a Miroslav Hrončok (SQL Puzzlers, Pár slov závěrem). Autory fotografií jsou Tomáš Vondra a Matěj Humpál (více fotografií). LinuxEXPRES je mediálním partnerem akce.

Nahoru

Odkazy

(Jako ve škole)
Průměr: 1.00 | Hodnotilo: 2
 

Příspěvky

Lukáš Jelínek Reportáž z Prague PostgreSQL Developers' Day 2011: Odpoledne
Lukáš Jelínek 19. 02. 2011, 15:58:14
Odpovědět  Odkaz 
Ta změna údajů na dotykovém displeji byla zvlášť dobrá. Úplně učebnicový příklad toho, když se řekne „měnit něco někomu pod rukama“ :-)
Tomáš Crhonek Re:Reportáž z Prague PostgreSQL Developers' Day 2011: Odpoledne
Tomáš Crhonek 19. 02. 2011, 19:02:15
Odpovědět  Odkaz 
To ano :-). Mě ale stále vrtá hlavou, jak se vlastně ten terminál dostal k datům. Pokladna má rozjetou nepotvrzenou transakci a PostgreSQL nemá transakční izolaci "read uncomited". Tedy buď tam Marc nepoužívá transakce (autocommit=true), což je na pokladně prasárna a nebo si jednotlivé položky pokladny ještě ukládá extra pro ten terminál. Další způsob, jak by se terminál mohl přes SQL dotaz do serveru dostat k pokladním položkám mě nenapadá.
Lukáš Jelínek Re:Re:Reportáž z Prague PostgreSQL Developers' Day 2011: Odpoledne
Lukáš Jelínek 19. 02. 2011, 20:05:06
Odpovědět  Odkaz 
Vzhledem k tomu, že neznáme strukturu té databáze a způsob práce s ní (hlavně ve smyslu toho, jak se přesně vystavuje vstupenka), tak je těžké vynášet nějaké soudy. Faktem je, že pokud by vystavování vstupenky probíhalo celé v jedné transakci, tak by ke změně dojít nemohlo, protože z té transakce je vidět původní stav.
Re:Re:Reportáž z Prague PostgreSQL Developers' Day 2011: Odpoledne
Pavel Stěhule 20. 02. 2011, 15:23:01
Odpovědět  Odkaz 
Je to jednoduché - pokud se spustí NOTICE uvnitř transakce, tak se odloží a čeká se na konec transakce. Teprve tehdy, když je transakce úspěšně potvrzena, tak se pošle echo na stranu klienta. A ten pak už samozřejmě vidí potvrzená data. Díky NOTICE mohu informovat libovolný počet klientů, že došlo k potvrzené změně dat - a že to, co mají v cache, v recordsetech atd není validní - díky tomu není nutné periodicky se dotazovat databázového serveru. NOTICE slouží k tomu, aby se informace rozšířila mezi všechny zainteresované klienty. Myslím si, že Marc používá autocommit=true i z důvodu externího dohledu nad pokladnami - tipoval bych, že každá pokladna bude mít svou tabulku, případně několik tabulek a záznamy se budou přelévat mezi nimi.

Je tu ještě pár technik pro drsňáky - což Marc není - jednak mohu komunikovat asynchronně v jedné session pomocí debug rozhraní - ale už nelze použít vzor observer - protože v tu chvíli může klient pouze zobrazit hlášku, nemůže provést žádnou činnost a také může existovat pouze jeden příjemce. Další technikou může být změna identity session - jistými technikami mohu obejít izolaci transakcí - samozřejmě, že je to hodně nebezpečná záležitost - ale v některých případech se může hodit.

Přidat názor

Nejsou podporovány žádné značky, komentáře jsou jen čistě textové. Více o diskuzích a pravidlech najdete v nápovědě.
Diskuzi můžete sledovat pomocí RSS kanálu rss



 
 

Top články z OpenOffice.cz