Nejnovější stabilní verze oblíbeného databázového systému PostgreSQL 9.2 byla vydána 10. září a mnoho uživatelů jistě potěší, že se stihla dostat i do připravované Fedory 18. Pojďme se v krátkosti podívat, jaké novinky nás čekají.

Nové datové typy

V nové minoritní verzi nalezneme datový typ JSON, který můžeme použít jak pro uložení dat, tak pro přístup ke klasickým strukturovaným datovým typům. Pro jednoduchý převod dat do formátu JSON můžeme např. použít funkci row_to_json. Pro komplexnější práci s daty JSON lze použít dodávaná rozšíření a práce tak do jisté míry může vypadat jako práce s databází NoSQL.

Uživatelé mají dále možnost definovat tzv. range types, tedy typy pro rozsahy hodnot. Některé typy jsou předdefinované (int4range, daterange, timerange), nicméně uživatelé si mohou definovat vlastní. Můžeme mít rozsahy otevřené i uzavřené a pro případy, kdy to nedává smysl, umožňuje index vypustit některé operátory a tím na data definovat určitá omezení.

Index-only scans

Další vlastnost je označena jako Index-only scans. Pokud v dotazu používáme jen zaindexované sloupce, není teoreticky nutné přistupovat k záznamům a všechna potřebná data můžeme brát z indexů. Problém ovšem je, že v indexu není informace o tom, zda je prvek viditelný danému uživateli. Pro tuto informaci se dříve muselo přistupovat k záznamu.

Ani v PostgreSQL 9.2 není tato informace o viditelnosti ukládána do indexu, ale je využito tzv. visibility maps, které říkají, zda je daný obsah viditelný všem transakcím - potom je možné vypustit přístup k záznamu. Tímto můžeme docílit urychlení až o dva řády, což ovšem platí pro ideální případ a pro aktualizovanou mapu. Pro aktualizaci visibility map se používá příkaz VACUUM, který většinou není spouštěn příliš často, takže reálné výsledky budou horší. Stejně tak musíme vždy pamatovat, že přidání nového indexu znamená nutnost ho aktualizovat při každé aktualizaci dat.

Kaskádová replikace

Nejen ve virtualizovaném prostředí můžeme nově využít tzv. kaskádovou replikaci. Dříve bylo možné všechny slave servery připojit pouze k jednomu master serveru. To mělo nepěkné důsledky při jeho výpadku a zároveň byl s vyšším počtem slave serverů znatelně zatížen. V nové verzi se může ke každému slave serveru připojit další slave server a zmírnit nebo vyřešit tak zmíněné problémy. Velmi užitečné to může být i pro případ, kdy streamujeme xlog, což je vlastně archivace s nižší granularitou, zatímco master server není vůbec zatížen (pg_receivexlog).

Další zrychlení přináší možnost nečekat na slave server, který zapisuje data na disk. Master může pokračovat ihned po potvrzení, že slave server data v pořádku přijal. Znamená to, že je sice možné ztratit data na slave serveru, nicméně v některých případech tento kompromis může mít své odůvodnění.

Další zlepšení výkonu

V neposlední řadě byly implementovány změny, které výrazně zlepšují výkon. Jmenovitě se jedná o zlepšení řazení in-memory, byly přidány statistiky pro obsahy polí a tím pádem se dosáhlo zrychlení v selektivnosti.

Byl přidán tzv. single-row režim pro zpracování velkých výsledků do klientské knihovny, která mj. nově dovoluje použít URI jako connection string. Dále můžeme použít režim "CONCURRENTLY" při DROP INDEX, stejně jako je tomu u CREATE INDEX. Toho můžeme využít, zejména pokud tato operace může trvat déle a my potřebujeme se zamčenými daty mezitím pracovat, třeba pomocí operace SELECT.

Vývojáři provedli i několik optimalizací plánovače a "prepared statements" se mohou optimalizovat pouze jednou. Je vytvořen tzv. generický plán, který může být následně parametrizovaný, což vykazuje znatelně lepší výsledky pro specifické vnořené dotazy, které ve vnitřním dotazu prohledávají indexy.

Škálovatelnost a spotřeba

I škálovatelnost doznala změn, a to u systémů s 32 a více jádry díky tzv. big locks. Nyní je možné lineárně škálovat až do 64 jader, což o sobě nemůže říct jen tak nějaký systém a už vůbec ne databázový.

Méně wake-ups zase znamená nižší spotřebu energie, což uvítají nejen administrátoři virtualizovaných systémů. Pro optimalizaci dále může posloužit trackování doby trvání IO operací, ovšem administrátor by měl být opatrný, protože na některých systémech může být zjištění této informace relativně drahé. Nově je možné zrychlit operaci EXPLAIN pomocí zamezení měření času.

Jak upgradovat

Stačil vás dosavadní výčet novinek přesvědčit pro upgrade? Provést to ve Fedoře můžeme standardním způsobem poté, co po aktualizaci balíčku RPM s novou verzí a pokusu o spuštění postgresql.service služba oznámí, že datový stack odpovídá nižší verzi. Pro upgrade můžeme použít jako vždy pg_dump/pg_restore, přímo utilitku pg_upgrade nebo speciálně ve Fedoře preferovaný způsob postgresql-setup upgrade.

Po upgradu mohou mít aplikace jisté potíže, neboť developeři PostgreSQL se nebojí udělat nekompatibilní změny, pokud je to ovšem vykoupeno dobrým důvodem. Mezi změny, které nejsou kompatibilní, patří chování funkce xpath, která nyní escapuje speciální znaky. Dále byl odebrán operátor '=>' (hstore), ovšem pouze při použití jako operátoru, takže select hstore('a=>b') je stále v pořádku. Důvodem bylo přidání '=>' mezi rezervovaná slova.

Utilita createuser nyní není ve výchozím nastavení interaktivní a pro zpětně kompatibilní chování je potřeba použít přepínač '--interactive'.

Změna, která je specifická pro Fedoru, souvisí s funkcí PrivateTmp init systému systemd. Díky ní mohou mít služby svůj vlastní privátní prostor pod cestou /tmp. Výhodou je, že služby získají vyšší bezpečnost, nevýhodou je ovšem ztráta možnosti použít /tmp pro komunikaci se službou. Z tohoto důvodu byl přesunut socket pro komunikaci s databází PostgreSQL do /var/run, kde je pro takové komunikační prostředky daleko lepší místo. Pro některé aplikace, které obchází klientskou knihovnu nebo používají pro komunikaci s verzí 9.2 starší verzi klienta, bude ovšem tato změna nekompatibilní. Pro jednodušší řešení nyní PostgreSQL nabízí možnost definovat více unix socketů, na kterých bude služba naslouchat zároveň.

Snažil jsem se vytáhnout nejzajímavější novinky v PostgreSQL 9.2, které dělají z dobrého systému ještě rychlejší a lepší databázi. Určitě lze najít ještě řadu dalších důležitých změn, pro jejich popis odkazuji čtenáře na upstreamové stránky postgresql.org nebo obsáhlý mailing-list.

Zdroje a kde hledat více informací:

http://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.2
http://www.postgresql.org/about/news/1415/
http://www.postgresql.org/docs/9.2/static/release-9-2.html