Po osmi měsících vývoje a pěti měsících testovaní PostgreSQL Global Development
Group oznámila čtrnáctou verzi PostgreSQL s pořadovým číslem 8.2.5.1.2007 06:00 | Radim Kolář | přečteno 8647×
Po osmi měsících vývoje a pěti měsících testovaní PostgreSQL Global Development
Group oznámila čtrnáctou verzi PostgreSQL s pořadovým číslem 8.2.
5.1.2007 06:00 | Radim Kolář | přečteno 8647×
Tato verze nemá, na rozdíl od verzí předchozích, žádná revoluční zlepšení. Místo toho obsahuje mnoho malých ale důležitých změn. Když přihlédneme k faktu, že PostgreSQL je stabilní databáze, tak lze s úspěchem tvrdit, že v tomto případě budou největším konkurentem PostgreSQL 8.2 jeho starší verze.
Podíváme se trochu do historie PostgreSQL na revoluční změny v posledních major verzích:
| řada | první verze | poslední verze | hlavní rysy |
| 7.3 | 11/2002 | 10/2006 | prepared statementy, DROP COLUMN |
| 7.4 | 11/2003 | 10/2006 | rychlejší IN dotazy, externí autovacuum |
| 8.0 | 01/2005 | 10/2006 | nativní server pro Windows, vnořené transakce, tablespaces, online zálohování. |
| 8.1 | 11/2005 | 10/2006 | dvoufázové potvrzování, table partitioning, interní autovacuum. |
Z tabulky vidíme, že major verze PostgreSQL vycházejí zhruba každých 12 měsíců, což je pro produkční použití příliš často. Při každém upgradu je potřeba u PostgreSQL udělat export/import dat, reinstalaci replikačního systému Slony1 a přinejmenším překompilovat drivery. Navíc je potřeba otestovat aplikaci oproti novému serveru, jelikož některé výrazy vyhodnocují různé verze serveru různě (tento typ chyb se velmi navíc špatně hledá) a novější verze jsou striktnější co se vstupních dat týče. Upgrady mají i příznivější stránky: každá nová verze je rychlejší než předchozí a systémové nároky se prakticky nezvyšují.
V praxi je nutné u aplikací psaných pro PostgreSQL podporovat vždy 3 poslední verze serveru. Vývojáři PostgreSQL podporují co se bezpečnostních a kritických chyb týče v průměru poslední 4 verze.
Pokud se při upgradech PostgreSQL rozhodnete vždy jednu verzi přeskočit a upgradovat například z 8.0 na 8.2, je nutné počítat s tím, že vzhledem ke striktnějším testům vstupních dat nemusí novější verze serveru data načíst. Pro usnadnění případné editace je vhodné si udělat dumpovat schema a data zvlášť. Verzi 8.2 se nelíbí dumpy z 7.4 a 8.0, kde default výraz odkazuje na neexistující objekt, většinou bývají takto dumpovány sekvence.
Pokud se vám nechce editovat dumpy, je možné zkusit použít novější pg_dump pro vydumpování staré databáze. pg_dump z verze 8.2 by měl být teoreticky schopen vydumpovat vše od 7.0 výše. V praxi se to nemusí vždy díky změnám v systémových katalozích podařit. Ačkoliv pg_dump umí měnit většinu katalogových dotazů podle verze serveru u mne si pg_dump 8.2 s vydumpováním 7.4 díky chybnému katalogovému dotazu neporadil.
Pro srovnání se podíváme na Oracle. Databáze Oracle má zhruba dvouroční vývojový cyklus (8i - 1999, 9i - 2001, 10g - 2003, 10g rel2 - 2005), přičemž jsou podporovány vždy dvě poslední verze. Po každé z hlavních verzí 8i, 9i, 10g obvykle následuje tzv. Release 2, což je zhruba na úrovni Windows Service Packu, zejména opravy chyb, optimalizace a sem tam něco nového. Release 2 mívají odlišné End of support date od hlavních verzí, jsou podporovány podstatně déle a tak se doporučuje na tyto verze přejít.
Na rozdíl od PostgreSQL, kde je možné provádět upgrade jen exportem a importem dat, Oracle umí i přímý upgrade, který je rychlejší jelikož není potřeba export/import dat a bývá méně problematický jelikož odpadají starosti s databází odmítající vstupní data k čemuž ale nedochází u Oracle tak často jako u PostgreSQL.
Upgrade na verzi Oracle 10g je možný jen z určitých verzí 8i a 9i. Např. 8i Rel2 je podporována jako 8.1.7. Jako stručný úvod do problematiky upgrade Oraclu bych doporučil tento článek.
Pokud srovnáme uživatele Oracle a PostgreSQL, tak průměrní uživatele Oraclu upgradují tak málo jak je jen možné (ještě dnes se setkáte v provozu setkáte s Oraclem 8i), u uživatelů PostgreSQL je tomu naopak. Toto chování zcela popírá výsledky některých OpenSource vs ClosedSource studií tvrdících že pořizovací cena software je prakticky zanedbatelnou částí TCO.
Ačkoliv verze 8.2 neobsahuje žádný revoluční rys z hlediska systémového, nové rysy SQL z ní dělají zlomovou verzi z hlediska aplikačního. Pokud použijete některý z nových rysů bude vaše aplikace vyžadovat PostgreSQL 8.2 či pozdější.
Konstrukce VALUES nyní umožňuje zadání více řádků. Nejčastěji toho budeme využívat u multi-line INSERTů: INSERT INTO table VALUES (10,'eee'), (20,'zzzz') , ale je možné i využití této konstrukce v SELECTech pro definici konstantních tabulek: SELECT name from (VALUES (10,'eee'), (20,'zzzz')) as alias(id,name)
DML přikazy INSERT/UPDATE/DELETE mohou nyní s využitím klíčového slova RETURNING vracet hodnotu. Ačkoliv lze vracet libovolný výraz, nejčastější použití bude vracení hodnot vložených či aktualizovaných sloupců: INSERT INTO table2 VALUES (DEFAULT,'22') returning id;
Jedná se zejména o rozšíření kompatibility s ostatnímy databázovými systémy, jelikož je tento nestandardní SQL rys v praxi dost často používán zejména u self-joinů.
Namísto klasické (a čitelnější) konstrukce UPDATE tabulka SET sloupec1=hodnota1, sloupec2=hodnota2 je možné použít alternativní formu ve tvaru UPDATE tabulka SET (sloupec1,sloupec2) = (hodnota1,hodnota2). Namísto seznamu (hodnota1,hodnota2) je pochopitelně možné použít subquery, což je hlavní důvod použití.
PostgreSQL nyní varuje, pokud je ve standardním řetězci použita escape sekvence.Escape sekvence je sice ještě stále vyhodnocena stejně jak tomu bylo v předchozích verzích, nicméně v budoucnu již nebudou escape sekvence ve standarních řetězcích interpretovány.
Řetězce obsahující escape sekvence musí mít nyní prefix E např. select * from wwwlog where line=E'GET /\r\n'; Krom toho bych ještě připomenul že znak ' je nutné z bezpečnostních důvodů vkládat jako '' a nikoliv jako \' více informací v CVE-2006-2314.
Integrované autovacuum se dočkalo několika příjemných změn. Hlášky vypisované do logu serveru byly nahrazeny dvěma novými sloupci v systémovém katalogu pg_stat_all_tables obsahující čas posledního VACUUM a ANALYZE. Přibyl systémový katalog pg_autovacuum, určený k doladění autovacuum pro jednotlivé tabulky.
Archive log režim byl poprvé použit u PostgreSQL 8.0. Jedná se o možnost zálohování databáze pomocí běžných systémových nástrojů. Obnova se provádí z nekonzistentní zálohy databáze a následného přehrávání archivovaných logů. Tato obnova bývá v mnoha případech rychlejší než import dat.
Největší výhoda tohoto způsobu zálohování oproti klasickému pg_dumpu je možnost kontinuálního zálohování. Namísto abychom zazálohovali databázi jen jednou denně pg_dumpem, zazálohujeme jednorázově databázi a průběžně zálohujeme nové logy. V případě havárie obnovíme databázi ze zálohy a přehrajeme maximum logů, které se nám podařilo zazálohovat. Vzhledem k nutnosti zálohovat až celé protokolační soubory, které mají default velikost 16 MB, nastává zde jistá prodleva mezi časem vytvoření a zaplnění protokolačního souboru, která je nepřímo úměrná počtu provedených změn v databázi.
Pro lepší kontrolu této prodlevy byl přidán konfigurační parametr archive_timeout, který provede po uplynutí zadaného časového intervalu přepnutí do nového protokolačního souboru abychom mohli ten starý zazálohovat. Přepnutí si lze vynutit i pomocí nové funkce pg_switch_xlog().
Archive log režim se používá i pro vytváření hot standby serverů, namísto zálohování nových protokolačních souborů na pásku je ihned přehráváme na záložním serveru, kde tímto udržujeme offline repliku dostabáze. PostgreSQL neumí na rozdíl od Oracle dovolit v této replice současné provádění read-only dotazů. Ve verzi 8.2 je možné na standby serveru přehrát logy obsahující více než 2 miliardy transakcí a v případě havárie systému během přehrávání logu není již nutné začínat znovu od základní kopie db, ale postačí zopakovat přehrání patřičného logu.
Jako každoročně tak i letos byl vylepšen optimizer dotazů. V současné verzi došlo na optimalizaci outer joinů, konstrukcí výužívajících IN, UPDATE/DELETE pro partitioned tables, konstantních WHERE výrazů u subselectů, zlepšen odhad vybraných řádek u regulárních a LIKE/ILIKE výrazů. Jako každoročně se po vydání 8.2.0 přišlo na dodatečné chyby v optimizeru zapříčiňující v některých případech chybné výsledky.
Při importu dat si možná povšimnete rychlejšího vytváření indexů, což je následek optimalizace třídění. Krom toho přibyla možnost vytvářet indexy ONLINE t.j. bez zablokování zápisu do tabulky. Rychlostní nárůst zaznamenaly také subtransakce které, ačkoliv ve světě PosgreSQL poměrně nové, si již autoři aplikací stačili oblíbit. Další významnou změnou je možnost nastavit u tabulek a indexů FILLFACTOR, používá se to u často modifikovaných tabulek. Bylo zjemněno zamykání aby na sebe nemuseli uživatelé vzájemně tolik čekat a několika optimalizací se dočkalo již tradičně VACUUM. Zejména potěšující změnou je zrychlení connectu do databáze oproti 8.1.
Rychlost PostgreSQL je velmi dobrá a je přinejmenším srovnatelná s konkurečnímy produkty (MySQL, Oracle, SQL Server). Verze 8.2 by měla být podle vyjádření autorů zhruba o 20 procent rychlejší v OLTP. Poměrně oblíbenou činností je testovat Postgres vs MySQL. Výsledky testů najdete například zde.
Velmi příjemnou zprávou je začlenění PostgreSQL 8.1 do operačního systému Solaris počínaje verzí Solaris 10 Update 2. Integrace se Solarisem byla ve verzi 8.2 vylepšena, databázi je nyní možné sledovat pomocí Dtrace.
PostgreSQL na platformě Solaris je oficiálně celosvětově podporován firmou Sun, což uvítají uživatelé vyžadující alternativní unixovou databázi k Oracle. Firmu Oracle to pravděpodobně moc nepotěší, neboť SPARC Solaris je její nejprodávanější platformou.
Ačkoliv řada 8.2 neobsahuje žádné revoluční změny, upgrade na 8.2 lze jen doporučit pokud vámi používané aplikace umějí escapovat řetězce správně. Lze očekávat, že si tvůrci aplikací pro PostgreSQL oblíbí multiline INSERTy stejně rychle jako si oblíbili subtransakce.