, najnovšia verzia "najlepšej na svete relačnej databázy s otvoreným zdrojovým kódom" vyjde o pár týždňov (ak všetko pôjde podľa plánu). To zodpovedá bežnému harmonogramu - nová verzia s množstvom nových funkcií vychádza raz ročne a, úprimne povedané, to je pôsobivé. Preto som sa stal aktívnym členom komunity PostgreSQL.
Podľa mňa, na rozdiel od predchádzajúcich vydaní, PostgreSQL 12 neobsahuje jednu alebo dve revolučné funkcie (ako napríklad časti alebo paralelizmus dotazov). Trochu som si robil srandu, že hlavná vec PostgreSQL 12 spočíva vo väčšej stabilite. A nie je to také dôležité, keď spravujete kritické dáta svojho podnikania?
Ale PostgreSQL 12 sa týmto neobmedzuje: s novými funkciami a vylepšeniami sa aplikácie budú správať lepšie, a od vás sa len požaduje robiť upgrade!
(Nuž, možno ešte prestavať indexy, ale v tomto vydaní to nie je také hrozné, ako sme zvyknutí.)
Bude to skvelé - upgradnúť PostgreSQL a okamžite si užiť významné zlepšenia bez zbytočných ťažkostí. Pred niekoľkými rokmi som analyzoval aktualizáciu z PostgreSQL 9.4 na PostgreSQL 10 a videl som, ako sa aplikácia zrýchlila vďaka vylepšenému paralelizmu dotazov v PostgreSQL 10. A, samozrejme, takmer nič som nemusel robiť (iba nastaviť konfiguračný parameter max_parallel_workers).
Súhlasíte, je pohodlné, keď po upgrade aplikácie fungujú lepšie. A my sa veľmi snažíme uspokojiť používateľov, pretože ich s PostgreSQL pribúda.
A ako vás jednoduchý upgrade na PostgreSQL 12 urobí šťastným? Teraz vám o tom poviem.
Závažné zlepšenia indexovania
Bez indexovania databáza ďaleko nezájde. Ako by sme inak rýchlo nachádzali informácie? Základný systém indexovania PostgreSQL sa nazýva . Tento typ indexu je optimalizovaný pre systémy ukladania.
Jednoducho používame príkaz CREATE INDEX ON some_table (some_column), a PostgreSQL vykonáva veľkú prácu na udržaní aktuálnosti indexu, zatiaľ čo neustále vkladáme, aktualizujeme a odstraňujeme hodnoty. Všetko funguje samo, ako kúzlo.
Ale indexy PostgreSQL majú jeden problém - oni a zaberajú zbytočné miesto na disku, a výkonnosť extrakcie a aktualizácie dát klesá. Pod "nafukovaním" rozumiem neefektívnemu udržovaniu indexovej štruktúry. To môže byť — alebo aj nemusí byť — spojené s odpadovými tuple, ktoré odstraňuje (ďakujem za informáciu Petrovi Geogheganovi ()). Nafukovanie indexu je obzvlášť zjavné v pracovných záťažiach, kde sa index aktívne mení.
PostgreSQL 12 vážne zlepšuje výkon B-stromových indexov, a experimenty s testami typu TPC-C ukázali, že miesto sa teraz využíva v priemere o 40 % menej. Teraz strácame menej času nielen na údržbu B-stromových indexov (to znamená na zapisovacie operácie), ale aj na extrakciu dát, keďže indexy sa stali oveľa menšími.
Aplikácie, ktoré aktívne aktualizujú svoje tabuľky — zvyčajne OLTP aplikácie () — budú oveľa efektívnejšie využívať disk a spracovávať požiadavky. Čím viac miesta je na disku, tým viac má databáza priestoru na rast bez upgrade infraštruktúry.
Niektoré stratégie upgradu vyžadujú prestavbu B-stromových indexov, aby sa využili tieto výhody (napríklad, nezrekonštruuje indexy automaticky). V predchádzajúcich verziách PostgreSQL prestavba veľkých indexov v tabuľkách viedla k významným prestojom, pretože v tomto čase nebolo možné vykonávať žiadne zmeny. Ale v PostgreSQL 12 je tu ešte jedna skvelá funkcia: teraz môžeme prestavovať indexy paralelne príkazom , aby sme sa úplne vyhli prestojom.
V PostgreSQL 12 sú aj ďalšie vylepšenia infraštruktúry indexovania. Ďalšia vec, kde sa neobišlo bez čarovania, je , známy aj ako WAL (write-ahead log). Žurnál predbežného zápisu zaznamenáva každú transakciu v PostgreSQL na prípad zlyhania a replikáciu. Aplikácie ho používajú na archiváciu a . Samozrejme, žurnál predbežného zápisu sa zapisuje na disk, čo môže ovplyvniť výkon.
Vo verzii PostgreSQL 12 sa znížili náklady na záznamy WAL, ktoré vytvárajú indexy GiST, GIN a SP-GiST pri vytváraní indexu. To poskytuje niekoľko významných výhod: záznamy WAL zaberajú menej miesta na disku a dáta sa rýchlejšie obnovujú, napríklad počas obnovenia po havárii alebo obnovy na časový okamih. Ak vo svojich aplikáciách používate takéto indexy (napríklad geografické aplikácie založené na PostGIS veľa používajú index GiST), je to ďalšia funkcia, ktorá výrazne zlepší výkon bez akýchkoľvek vašich zásahov.
Particionovanie — viac, lepšie, rýchlejšie
Vo verzii PostgreSQL 10 sa objavilo . Vo verzii PostgreSQL 11 sa to stalo oveľa jednoduchšie. Vo verzii PostgreSQL 12 je možné meniť škálovanie sekcií.
Vo verzii PostgreSQL 12 sa výkon systému particionovania výrazne zlepšil, najmä ak má tabuľka tisíce sekcií. Napríklad, ak sa dopyt týka iba niekoľkých sekcií v tabuľke, kde ich je tisíc, bude sa vykonávať oveľa rýchlejšie. Výkon sa zlepšil nielen pre takéto typy dopytov. Ešte si všimnete, ako sa urýchlili operácie INSERT v tabuľkách s množstvom sekcií.
Zaznamenávanie údajov pomocou — mimochodom, to je skvelý spôsob a tu je príklad — do particionovaných tabuliek vo verzii PostgreSQL 12 sa tiež stalo efektívnejším. S COPY to už bolo rýchle, a vo verzii PostgreSQL 12 to úplne letí.
Vďaka týmto výhodám je možné v PostgreSQL ukladať súbory údajov ešte väčšej veľkosti a extrakcia sa stala jednoduchšou. A to bez akýchkoľvek vašich zásahov. Ak má aplikácia veľa sekcií, napríklad zapisuje údaje časových radov, jednoduché vylepšenie výrazne zlepší jej výkon.
A hoci toto vylepšenie nie je úplne z kategórie 'vylepšili sme to a tešíme sa', vo verzii PostgreSQL 12 je možné vytvárať vonkajšie kľúče, ktoré odkazujú na particionované tabuľky, takže práca s particionovaním je čisto potešením.
Dopyty WITH sa stali oveľa lepšími
Keď (tiež známe ako CTE, tiež dopyty WITH), nemohol som sa dočkať, kedy napíšem článok o tom, . Je to jedna z tých funkcií, ktoré urýchlia aplikáciu. Ak, samozrejme, používate CTE.
Často si všímam, že nováčikovia v SQL radi používajú CTE: ak ich napíšete určitým spôsobom, máte pocit, že píšete imperatívny program. Osobne som mal rád, keď som prepisoval tieto dotazy, aby som sa obmedzil bez CTE a zvýšil výkon. Teraz je všetko inak.
PostgreSQL 12 umožňuje vloženie určitého typu CTE bez vedľajších efektov (SELECT), ktorý sa používa iba raz bližšie k koncu dotazu. Keby som sledoval štatistiku dotazov s CTE, ktoré som prepisoval, väčšina z nich by spadala do tejto kategórie. Pomáha to vývojárom písať zrozumiteľný kód, ktorý teraz aj rýchlo funguje.
Naviac PostgreSQL 12 optimalizuje vykonávanie SQL samostatne, nemusíte robiť nič. A hoci teraz pravdepodobne už nebudem musieť optimalizovať také dotazy, je skvelé, že PostgreSQL naďalej pracuje na optimalizácii dotazov.
Just-in-Time (JIT) — teraz predvolene
V systémoch PostgreSQL 12 s podporou JIT kompilácia je predvolená. Najprv získate podporu pre niektoré interné operácie, a po druhé, dotazy s výrazmi (najjednoduchší príklad — x + y) v zoznamoch výberov (ktoré máte po SELECT), agregátoch, výrazmi v podmienkach WHERE a ďalšími môžu využiť JIT na zvýšenie výkonu.
Keďže je JIT povolený v PostgreSQL 12 predvolene, výkon sa zlepší sám, ale odporúčam vyskúšať aplikáciu v PostgreSQL 11, kde sa JIT iba objavil, aby ste zmerali výkon dotazov a zistili, či treba niečo nastaviť.
A čo ostatné nové funkcie PostgreSQL 12?
V PostgreSQL 12 je množstvo nových skvelých funkcií — od možnosti skúmať dáta JSON pomocou štandardných SQL/JSON dotazovacích výrazov až po viacfaktorovú autentifikáciu s parametrom clientcert=verify-full, vytvorenými stĺpcami a mnohými ďalšími. Stačí na samostatný príspevok.
Ako aj PostgreSQL 10, PostgreSQL 12 zvýši celkový výkon hneď po aktualizácii. Samozrejme, môžete mať svoj vlastný spôsob — otestujte aplikáciu za podobných podmienok v pracovnom systéme skôr, ako aktivujete vylepšenia, ako som to urobil ja s PostgreSQL 10. Aj keď je PostgreSQL 12 už teraz stabilnejší, ako som očakával, nešportujte kvalitu testovania aplikácií, skôr než ich pustíte do produkcie.
Zdroj: habr.com
