Hlavní navigace

Postgresql verze 6.5 - co tu máme nového?

14. 7. 1999
Doba čtení: 4 minuty

Sdílet

Nedávno vyšla nová verze populárního OpenSource SQL serveru, jehož historie sahá až někam do univerzitního unixového pravěku. Podívejme se, co nového nám autoři nachystali tentokrát...

Samotní vývojáři tohoto systému považují verzi 6.5 za důležitý předěl v historii – pokud tomu dobře rozumím, prý se jim konečně podařilo kód zděděný původně z univerzity v Berkeley ovládnout natolik, že jsou schopni přidávat nové základní vlastnosti a díky neustále rostoucímu počtu přispívajících programátorů z celého světa nás budou „bombardovat“ stále lepšími postgresy častěji než v minulosti. Uvidíme, jak se jim to podaří :) Každopádně tato verze opravdu přináší několik podstatných změn a doporučuji ji k vyzkoušení všem stávajícím uživatelům…

Nejdůležitější změny najdete v oblasti transakčního zpracování. Zde si neodpustím malou odbočku a srovnání s konkurencí: Zatímco MySQL je vyvíjen s důrazem na rychlost, jednoduchost a optimalizaci prostoru obsazeného daty, PostgreSQL se ubírá směrem k robusnímu (a bohužel pomalejšímu) systému s rozsáhlými možnostmi rozšiřování uživatelskými typy a funkcemi, programování logiky databáze a transakčního zpracování. Tam, kde jsme u MySQL omezeni na prosté zamykání tabulek, PostgreSQL přináší zdokonalený model současně probíhajících transakcí, navzájem od sebe izolovaných pomocí tzv. Multi-Version Concurrency Control, jehož základním principem je existence různých verzí záznamu tak, aby jedna transakce nebyla ovlivněna současně probíhající transakcí jinou. Pokusím se zde stručně popsat tuto koncepci – SQL guru nechť mi odpustí, pokud se dopustím nějakých nepřesností a zjednodušování, téma je to poměrně náročné…

Transakce je vlastně nějaká série SQL dotazů, jež mohou číst, zapisovat a měnit data v různých tabulkách a mohou skončit buď potvrzením nebo zrušením všech změn, které provedly. Takže změny, které transakce provedla, se buď projeví všechny najednou, nebo vůbec. Vyplývá z toho několik problémů, které bývají v různých SQL systémech různě řešeny. Především jak zařídit, aby právě probíhající změny, které transakce dělá, nebyly až do jejího potvrzení vidět v jiných transakcích ani v současně probíhajících SELECTech (neboť v průběhu transakce může být databáze v nekonzistentním stavu). Nejjednodušší (a samozřejmě nejméně efektivní) je systém zamykání tabulek nebo záznamů, který zajistí, že právě měněná data se stanou nepřístupnými pro další transakce nebo dotazy a ty musí počkat na ukončení právě probíhající transakce. Ta však může být libovolně rozsáhlá a to způsobí znatelné zpomalení celého systému, pokud více uživatelů provádí nějaké změny (a navíc brání i prostému čtení dat).

Proto PostgreSQL zavádí tento nový model verzí, který umožní současný běh více transakcí tak, aby se navzájem neblokovaly (a neblokovaly ani pokusy o čtení databáze) – současně běžící transakce jsou od sebe izolovány tak, aby neviděly právě probíhající nepotvrzené změny ostatních transakcí. Existují zde 2 úrovně izolace transakce – základní READ COMMITED a více restriktivní SERIALIZABLE. Transakce typu READ COMMITED obsahuje obecně několik dotazů – každý dotaz vidí jen ta data, která byla potvrzena (COMMIT – úspěšné dokončení běhu transakce a zviditelnění provedených změn) před zasláním dotazu. Transakce SERIALIZABLE omezuje viditelnost změn ještě více – pouze na ta data, která byla potvrzena před započetím celé transakce. Tento „drobný“ rozdíl je podstatný, pokud transakce obsahuje více UPDATE příkazů – u základního typu READ COMMITED se může stát, že se během provádění transakce mezi 2 UPDATE příkazy změní obsah některých zpracovávaných dat a transakce na tuto změnu není schopna reagovat. Pokud použijete transakci SERIALIZABLE, máte jistotu, že více současně probíhajících transakcí skončí nakonec tak, jako by byly prováděny za sebou. Popřípadě mohou skončit chybovým hlášením, pokud se data v průběhu zpracování změní úspěšným dokončením dříve započaté transakce. Uff… Celá tato oblast je poměrně dobře zdokumentována v kapitole 9. manuálu, včetně podrobně popsaného systému zamykání na různých úrovních.

S tímto tématem souvisí i další vlastnost tohoto systému: data vrácená SELECtem už ve chvíli, kdy je obdrží aplikace, mohou být změněna (nebo už vůbec nemusí existovat). Pro případ, že chcete určitá data přečíst, nějak analyzovat a poté změnit, je zde nová konstrukce SELECT … FOR UPDATE, která zajistí ochranu výsledných záznamů před změnou nebo zrušením. Jsou zde i další nové SQL konstrukce: SELECT … INTERSECT/EXCEPT SELECT …, realizující průnik nebo rozdíl dvou výsledných množin, SELECT … LIMIT , umožňující vrácení jen určité části výsledku dotazu (ideální třeba pro implementaci stránkování prohlíženého výsledku u webových aplikací) nebo CASE, COALESCE a IFNULL – tyto funkce umožňují tvorbu podmíněných výrazů v SQL dotazech.

root_podpora

Co se týče dalších změn, autoři slibují zrychlení snad všech částí backendu – včetně SELECT JOIN dotazů, které prozatím neprobíhaly vždy optimálně. Mnoho drobných chybiček je opravených (například operátor || pro spojování řetězců už je možno použít i mezi 3 a více operandy), konečně byl přidán numerický typ umožňující přesnou specifikaci počtu platných míst (jako u staré dobré dBase). Pouze upgrade databází z předchozích verzí je nutno dělat prostřednictvím pg_dump, to ale vyplývá ze změněných datových struktur samotných databázových souborů.

Drobných změn je zde opravdu mnoho, doporučuji prostudovat přímo na mateřském webu. Osobně už se těším na příští verzi, která by měla mimo jiné implementovat i „opravdovou“ referenční integritu tak, jak ji známe z jiných komerčních SQL serverů.

Byl pro vás článek přínosný?

Autor článku