, poslední verze „nejlepší na světě relační databáze s otevřeným zdrojovým kódem“ vyjde za pár týdnů (pokud vše půjde podle plánu). To odpovídá běžnému harmonogramu — nová verze s řadou nových funkcí vychází každoročně a, upřímně řečeno, to je působivé. Proto jsem se stal aktivním členem komunity PostgreSQL.
Podle mě se PostgreSQL 12 od předchozích vydání liší tím, že neobsahuje jednu nebo dvě revoluční funkce (jako například partitioning nebo paralelismus dotazů). Jednou jsem si srandu, že hlavní vtip PostgreSQL 12 spočívá ve větší stabilitě. A není to právě to, co potřebujete při správě kritických dat vašeho podnikání?
Ale PostgreSQL 12 se tímto zdaleka neomezuje: s novými možnostmi a vylepšeními budou aplikace fungovat lépe, a od vás se vyžaduje jen provést upgrade!
(No, možná ještě přestavět indexy, ale v této verzi to není tak hrozné, jak jsme zvyklí.)
To bude skvělé — upgradovat PostgreSQL a rovnou si užívat výrazná zlepšení bez zbytečných pohybů. Před několika lety jsem analyzoval aktualizaci z PostgreSQL 9.4 na PostgreSQL 10 a viděl, jak se aplikace zrychlila díky vylepšenému paralelismu dotazů v PostgreSQL 10. A co je nejdůležitější, od mě se téměř nic nevyžadovalo (jen jsem nastavil parametr konfigurace. max_parallel_workers).
Souhlasíte, že je pohodlné, když aplikace fungují lépe hned po upgradu. A my se opravdu snažíme potěšit uživatele, protože jich s PostgreSQL přibývá.
A jak jednoduchý upgrade na PostgreSQL 12 vás učiní šťastnými? Teď vám to povím.
Závažná vylepšení indexování
Bez indexování se databáze daleko nedostane. Jak jinak rychle najít informace? Základní systém indexování PostgreSQL se nazývá . Tento typ indexu je optimalizován pro systémy ukládání.
Prostě použijeme příkaz CREATE INDEX ON some_table (some_column), a PostgreSQL odvádí většinu práce, aby udržovalo index aktuální, zatímco my neustále vkládáme, aktualizujeme a odstraňujeme hodnoty. Vše funguje samo od sebe, jako kouzlem.
Ale indexy PostgreSQL mají jeden problém — ony a zabírají zbytečné místo na disku, zatímco výkonnost extrakce a aktualizace dat klesá. Pod pojmem „zvětšování“ mám na mysli neefektivní udržování indexové struktury. To může — ale také nemusí — souviset s nepoužitelnými řádky, které se odstraňují. (děkujeme za informace Peteru Geogheganovi ()). Zvětšování indexu je zvláště patrné u pracovních zátěží, kde se index aktivně mění.
PostgreSQL 12 výrazně zlepšuje výkon B-stromových indexů a experimenty s testy typu TPC-C ukázaly, že místo je nyní využíváno v průměru o 40 % méně. Nyní trávíme méně času nejen údržbou B-stromových indexů (tj. při zápisových operacích), ale také při extrakci dat, protože indexy jsou nyní mnohem menší.
Aplikace, které aktivně aktualizují své tabulky — obvykle OLTP aplikace () — budou mnohem efektivněji využívat disk a zpracovávat dotazy. Čím více místa na disku, tím více má databáze prostoru pro růst bez upgradu infrastruktury.
Některé strategie upgradu vyžadují přestavbu B-stromových indexů, aby bylo možné využít těchto výhod (například, nepřestaví indexy automaticky). V předchozích verzích PostgreSQL vedla přestavba velkých indexů v tabulkách k významnému prostoji, protože v té době nebylo možné provádět změny. Ale v PostgreSQL 12 je zde další skvělá funkce: nyní je možné přestavovat indexy paralelně pomocí příkazu , aby se zcela vyhnulo prostoji.
V PostgreSQL 12 jsou také další vylepšení infrastruktury indexování. Další věc, kde se to neobešlo bez magie, je , také známý jako WAL (write-ahead log). Žurnal předběžného zápisu zaznamenává každou transakci v PostgreSQL pro případ selhání a replikace. Aplikace ho využívají pro archivaci a . Samozřejmě, že žurnal předběžného zápisu se zapisuje na disk, což může ovlivnit výkon.
Ve PostgreSQL 12 se snížily náklady na záznamy WAL, které vytvářejí indexy GiST, GIN a SP-GiST při vytváření indexu. To přináší několik významných výhod: záznamy WAL zabírají méně místa na disku a data se rychleji obnovují, například při obnovení po selhání nebo při návratu k určitému bodu v čase. Pokud tyto indexy používáte ve svých aplikacích (například geoprostorové aplikace založené na PostGIS často využívají index GiST), je to další funkce, která výrazně zlepší výkon s minimálním úsilím z vaší strany.
Rozdělení — více, lépe, rychleji
Ve PostgreSQL 10 se objevilo . Ve PostgreSQL 11 se výrazně zjednodušilo jeho použití. V PostgreSQL 12 lze měnit měřítko sekcí.
Ve PostgreSQL 12 se výkon systému sekcí výrazně zlepšil, zejména pokud má tabulka tisíce sekcí. Například, pokud dotaz zasáhne pouze několik sekcí v tabulce s tisíci sekcemi, bude se provádět mnohem rychleji. Zlepšení výkonu se netýká pouze těchto typů dotazů. Také si všimnete, že operace INSERT v tabulkách s mnoha sekcemi se zrychlily.
Zapisování dat pomocí — mimochodem, je to skvělý způsob a zde je příklad — do rozdělených tabulek ve PostgreSQL 12 se také stalo efektivnější. S COPY to bylo rychlé, ale ve PostgreSQL 12 se to doslova letí.
Díky těmto výhodám lze v PostgreSQL uchovávat soubory dat ještě větší velikosti a jejich extrakce se stala snadnější. A bez jakýchkoli snah z vaší strany. Pokud má aplikace mnoho sekcí, například když zapisuje data časových řad, jednoduchá aktualizace výrazně zlepší její výkon.
A i když toto zlepšení nepřipadá přímo do kategorie „uplaťte a radujte se“, v PostgreSQL 12 lze vytvářet cizí klíče, které odkazují na rozdělené tabulky, takže práce s dělením je radostí.
Dotazy WITH se výrazně zlepšily
Když (také známé jako CTE, také známé jako dotazy WITH), nedokázal jsem se dočkat, až napíšu článek o tom, . To je jedna z těch funkcí, které urychlí aplikaci. Pokud tedy používáte CTE.
Často si všímám, že nováčci v SQL rádi používají CTE: pokud je napíšete určitým způsobem, cítíte, že píšete imperativní program. Osobně jsem měl rád přepisování těchto dotazů, abych se obešel bez CTE a zvýšil tak výkon. Teď je všechno jinak.
PostgreSQL 12 umožňuje vkládat určitý typ CTE bez vedlejších efektů (nebude prováděn při nepravdivosti první podmínky. Opravy pomocí), který se používá pouze jednou, blíže ke konci dotazu. Kdybych vedl statistiku dotazů s CTE, které jsem přepisoval, většina z nich by spadala do této kategorie. Pomáhá to vývojářům psát srozumitelný kód, který nyní také rychle běží.
Navíc PostgreSQL 12 optimalizuje provádění SQL automaticky, nemusíte s tím vůbec nic dělat. Ačkoliv teď pravděpodobně už nebudu muset tyto dotazy optimalizovat, je skvělé, že PostgreSQL pokračuje v optimalizaci dotazů.
Just-in-Time (JIT) — nyní jako výchozí nastavení
V systémech PostgreSQL 12 s podporou JIT-kompilace je aktivována jako výchozí nastavení. Za prvé, dostanete podporu pro některé interní operace, a za druhé, dotazy s výrazy (nejjednodušší příklad — x + y) v seznamech výběru (které máte po SELECT), agregátech, výrazy v podmínkách WHERE a další mohou využít JIT pro zvýšení výkonu.
Jakmile je JIT v PostgreSQL 12 jako výchozí nastavení, výkon se zlepší sám o sobě, ale doporučuji otestovat aplikaci v PostgreSQL 11, kde JIT právě vznikl, abyste změřili výkon dotazů a zjistili, zda je potřeba něco nastavit.
A co ostatní nové funkce PostgreSQL 12?
V PostgreSQL 12 je spousta nových skvělých funkcí — od možnosti zkoumat data JSON pomocí standardních SQL/JSON dotazů, až po vícefaktorovou autentizaci s parametrem clientcert=verify-full, generovaných sloupců a mnoho dalšího. To by zasloužilo samostatný příspěvek.
Stejně jako PostgreSQL 10, PostgreSQL 12 zvýší celkový výkon ihned po upgradu. Samozřejmě máte svůj způsob — otestujte aplikaci za podobných podmínek v provozním systému, než zapnete vylepšení, jak jsem to udělal já s PostgreSQL 10. I když je PostgreSQL 12 už nyní stabilnější, než jsem předpokládal, nebojte se kvalitně testovat aplikace před jejich uvedením do produkce.
Zdroj: habr.com
