, nejnovější vydání „nejlepší relační databáze s otevřeným zdrojovým kódem na světě“, vyjde za pár týdnů (pokud vše půjde podle plánu). To se řídí obvyklým harmonogramem - nová verze se spoustou nových funkcí vychází jednou ročně a upřímně řečeno, je to působivé. Proto jsem se stal aktivním členem PostgreSQL komunity.
Podle mého názoru, na rozdíl od minulých vydání, PostgreSQL 12 neobsahuje jednu nebo dvě revoluční funkce (jako je dělení nebo paralelismus dotazů). Jednou jsem žertoval, že hlavní vlastností PostgreSQL 12 je větší stabilita. Není to to, co potřebujete, když spravujete kritická data vaší firmy?
PostgreSQL 12 se však neomezuje pouze na toto: s novými funkcemi a vylepšeními budou aplikace fungovat lépe, Vše, co musíte udělat, je upgradovat!
(No, možná i přebudovat indexy, ale v tomto vydání to není tak děsivé, jak jsme zvyklí.)
Bylo by skvělé upgradovat PostgreSQL a hned si užívat výrazných vylepšení bez zbytečných gest. Před několika lety jsem analyzoval upgrade z PostgreSQL 9.4 na PostgreSQL 10 a viděl jsem, jak je aplikace rychlejší díky vylepšenému paralelismu dotazů v PostgreSQL 10. A co je nejdůležitější, nebylo ode mě vyžadováno téměř nic (stačí nastavit konfigurační parametr max_parallel_workers).
Souhlasíte, je vhodné, když aplikace fungují lépe ihned po upgradu. A my se velmi snažíme uživatelům vyhovět, protože PostgreSQL jich má čím dál tím víc.
A jak vám udělá radost jednoduchý upgrade na PostgreSQL 12? Teď vám to povím.
Hlavní vylepšení indexování
Bez indexace se databáze daleko nedostane. Jak jinak můžete rychle najít informace? Základní indexovací systém PostgreSQL se nazývá . Tento typ indexu je optimalizován pro úložné systémy.
Používáme pouze operátora CREATE INDEX ON some_table (some_column)a PostgreSQL odvádí skvělou práci při udržování indexu v aktuálním stavu, zatímco neustále vkládáme, aktualizujeme a mažeme hodnoty. Všechno funguje samo, jako kouzlo.
Ale PostgreSQL indexy mají jeden problém – oni a zabírají místo na disku navíc a výkon extrahování a aktualizace dat je snížen. Tím „nadýmáním“ mám na mysli neefektivní údržbu struktury indexu. To může, ale nemusí souviset s odpadkovými n-ticemi, které (za info děkuji Peteru Gaganovi))). Nafouknutí indexu je zvláště patrné při zátěži, kde se index aktivně mění.
PostgreSQL 12 výrazně zlepšuje výkon indexů B-stromu a experimenty s testy jako TPC-C ukázaly, že prostor je nyní využíván v průměru o 40 % méně. Nyní trávíme méně času nejen údržbou indexů B-stromu (to znamená operacemi zápisu), ale také získáváním dat, protože indexy se mnohem zmenšily.
Aplikace, které aktivně aktualizují své tabulky, jsou obvykle aplikace OLTP () bude mnohem efektivnější z hlediska využití disku a zpracování dotazů. Čím více místa na disku, tím více místa má databáze k růstu bez upgradů infrastruktury.
Některé strategie upgradu vyžadují, abyste znovu sestavili indexy B-stromu, abyste mohli využít těchto výhod (např. nebude automaticky znovu sestavovat indexy). V předchozích verzích PostgreSQL vedlo přestavba velkých indexů na tabulkách k významným prostojům, protože během této doby nebylo možné provést žádné změny. PostgreSQL 12 má ale další skvělou funkci: nyní můžete paralelně s příkazem znovu sestavit indexy abyste se zcela vyhnuli prostojům.
PostgreSQL 12 má další vylepšení infrastruktury indexování. Další věc, kde bylo nějaké kouzlo - , neboli WAL (zápis dopředu). Záznam napřed zapisuje každou transakci do PostgreSQL v případě selhání a replikace. Aplikace jej využívají k archivaci a . Log předem se samozřejmě zapisuje na disk, což může ovlivnit výkon.
PostgreSQL 12 snížil režii záznamů WAL, které jsou vytvářeny indexy GiST, GIN a SP-GiST při vytváření indexu. To má několik hmatatelných výhod: záznamy WAL zabírají méně místa na disku a data se přehrávají rychleji, například během převzetí služeb při selhání nebo obnovy v určitém okamžiku. Pokud takové indexy používáte ve svých aplikacích (například geoprostorové aplikace založené na PostGIS hodně používají index GiST), je to další funkce, která výrazně zlepší výkon bez jakéhokoli úsilí z vaší strany.
Dělení oddílů – větší, lepší, rychlejší
Představení PostgreSQL 10 . V PostgreSQL 11 je jeho použití mnohem jednodušší. V PostgreSQL 12 můžete škálovat oddíly.
V PostgreSQL 12 se výkon systému dělení výrazně zlepšil, zvláště pokud jsou v tabulce tisíce oddílů. Pokud například dotaz ovlivňuje pouze několik oddílů v tabulce s tisíci z nich, poběží mnohem rychleji. Zlepšení výkonu se neomezují pouze na tyto typy dotazů. Také si všimnete, o kolik rychlejší jsou operace INSERT u tabulek s mnoha oddíly.
Zápis dat pomocí - mimochodem, to je skvělý způsob a zde je příklad - Dělené tabulky v PostgreSQL 12 se také staly efektivnějšími. S COPY bylo vše rychlé, ale v PostgreSQL 12 to letí úplně.
Tyto výhody umožňují PostgreSQL ukládat ještě větší datové sady a usnadňují jejich načítání. A žádné úsilí z vaší strany. Pokud má aplikace mnoho sekcí, například zapisuje data časových řad, jednoduchý upgrade výrazně zlepší její výkon.
A i když to není zrovna vylepšení typu upgrade-and-rejoice, v PostgreSQL 12 můžete vytvářet cizí klíče, které odkazují na rozdělené tabulky, aby byla práce s rozdělením potěšením.
WITH dotazy se právě zlepšily
Kdy (aka CTE, aka WITH queries), měl jsem chuť napsat článek o tom, jak . Jedná se o jednu z funkcí, která urychlí aplikaci. Pokud ovšem nepoužíváte CTE.
Často si všímám, že začátečníci SQL rádi používají CTE: pokud je píšete určitým způsobem, máte pocit, že píšete imperativní program. Osobně jsem tyto dotazy rád přepisoval, abych se obešel без CTE a zvýšit produktivitu. Nyní je vše jinak.
PostgreSQL 12 vám umožňuje vložit konkrétní typ CTE bez vedlejších účinků (SELECT), který se použije pouze jednou na konci požadavku. Pokud bych sledoval CTE dotazy, které jsem přepsal, většina z nich by spadala do této kategorie. To pomáhá vývojářům psát jasný kód, který je nyní také rychlý.
Navíc PostgreSQL 12 optimalizuje samotné provádění SQL, nemusíte nic dělat. I když teď asi nebudu potřebovat optimalizovat takové dotazy, je skvělé, že PostgreSQL nadále pracuje na optimalizaci dotazů.
Just-in-Time (JIT) – nyní výchozí
Na systémech PostgreSQL 12 s podporou Kompilace JIT je ve výchozím nastavení povolena. Nejprve získáte podporu pro některé interní operace a za druhé, dotazy s výrazy (nejjednodušší příklad je x + y) ve výběrových seznamech (které máte po SELECT), agregace, výrazy s klauzulemi WHERE a další mohou používat JIT ke zlepšení výkonu.
Vzhledem k tomu, že JIT je ve výchozím nastavení v PostgreSQL 12 povoleno, výkon se sám o sobě zlepší, ale doporučuji otestovat aplikaci v PostgreSQL 11, kde byl JIT poprvé představen, abyste změřili výkon dotazů a zjistili, zda je potřeba něco doladit.
Ale co zbytek nových funkcí PostgreSQL 12?
PostgreSQL 12 má spoustu skvělých nových funkcí, od schopnosti kontrolovat data JSON pomocí standardních výrazů směrování SQL/JSON až po vícefaktorové ověřování pomocí clientcert=verify-full, generované sloupce a další. Dost na samostatný příspěvek.
Stejně jako PostgreSQL 10 i PostgreSQL 12 zlepší celkový výkon ihned po upgradu. Samozřejmě můžete mít svůj vlastní způsob - otestujte aplikaci za podobných podmínek na produkčním systému před povolením vylepšení, jako jsem to udělal s PostgreSQL 10. I když je PostgreSQL 12 již stabilnější, než jsem očekával, nebuďte líní testovat aplikace no, před jejich uvolněním do výroby.
Zdroj: www.habr.com