Թարմացում ծույլերի համար. ինչպես է PostgreSQL 12-ը բարելավում կատարումը

PostgreSQL 12- ը, «աշխարհի լավագույն բաց կոդով հարաբերական տվյալների բազայի» վերջին տարբերակը կթողարկվի մի քանի շաբաթից (եթե ամեն ինչ ընթանա ըստ պլանի): Սա հետևում է տարին մեկ անգամ մի տոննա նոր տարբերակով նոր տարբերակ թողարկելու սովորական ժամանակացույցին, և անկեղծ ասած, դա տպավորիչ է: Այդ իսկ պատճառով ես դարձա PostgreSQL համայնքի ակտիվ անդամ:

Իմ կարծիքով, ի տարբերություն նախորդ թողարկումների, PostgreSQL 12-ը չի պարունակում մեկ կամ երկու հեղափոխական առանձնահատկություններ (օրինակ՝ բաժանումը կամ հարցումների զուգահեռությունը): Մի անգամ ես կատակեցի, որ PostgreSQL 12-ի հիմնական առանձնահատկությունն ավելի մեծ կայունությունն է: Արդյո՞ք դա այն չէ, ինչ ձեզ հարկավոր է, երբ կառավարում եք ձեր բիզնեսի կարևոր տվյալները:

Բայց PostgreSQL 12-ը դրանով չի սահմանափակվում. նոր հնարավորություններով և բարելավումներով հավելվածներն ավելի լավ կաշխատեն, և այն ամենը, ինչ դուք պետք է անեք, թարմացնելն է:

(Դե, գուցե վերակառուցեք ինդեքսները, բայց այս թողարկումում դա այնքան էլ սարսափելի չէ, որքան մենք սովոր ենք):

Հիանալի կլինի արդիականացնել PostgreSQL-ը և անմիջապես վայելել զգալի բարելավումներ՝ առանց ավելորդ աղմուկի: Մի քանի տարի առաջ ես վերանայեցի PostgreSQL 9.4-ից PostgreSQL 10-ի արդիականացումը և տեսա, թե ինչպես է հավելվածն արագանում PostgreSQL 10-ում հարցումների բարելավված զուգահեռականության շնորհիվ: Եվ, ամենակարևորը, ինձանից գրեթե ոչինչ չի պահանջվում (պարզապես սահմանեք կազմաձևման պարամետրը: max_parallel_workers).

Համաձայն եմ, հարմար է, երբ հավելվածներն ավելի լավ են աշխատում թարմացումից անմիջապես հետո: Եվ մենք շատ ենք փորձում գոհացնել օգտատերերին, քանի որ PostgreSQL-ն ավելի ու ավելի շատ է նրանցից:

Այսպիսով, ինչպե՞ս կարող է ձեզ երջանիկ դարձնել PostgreSQL 12-ի պարզ թարմացումը: Հիմա կասեմ.

Ինդեքսավորման հիմնական բարելավումներ

Առանց ինդեքսավորման տվյալների բազան հեռու չի գնա: Այլապես ինչպե՞ս կարող եք արագ տեղեկատվություն գտնել: PostgreSQL-ի հիմնարար ինդեքսավորման համակարգը կոչվում է Բ-ծառ. Այս տեսակի ինդեքսը օպտիմիզացված է պահեստավորման համակարգերի համար:

Մենք պարզապես օգտագործում ենք օպերատորը CREATE INDEX ON some_table (some_column), և PostgreSQL-ը մեծ աշխատանք է կատարում ինդեքսը թարմացնելու համար, մինչ մենք անընդհատ տեղադրում, թարմացնում և ջնջում ենք արժեքները: Ամեն ինչ աշխատում է ինքնուրույն, ասես կախարդանքով։

Բայց PostgreSQL ինդեքսները մեկ խնդիր ունեն՝ դրանք ուռճացված են և գրավում է սկավառակի լրացուցիչ տարածք և նվազեցնում տվյալների որոնման և թարմացման արդյունավետությունը: «Փքվածություն» ասելով նկատի ունեմ ինդեքսի կառուցվածքի անարդյունավետ պահպանումը։ Սա կարող է, կամ չի կարող կապված լինել այն աղբատարների հետ, որոնք այն հեռացնում է VACUUM (շնորհակալություն Փիթեր Գագանին տեղեկատվության համար)Փիթեր Գեոգեգան)): Ինդեքսի փքվածությունը հատկապես նկատելի է ծանրաբեռնվածության դեպքում, որտեղ ցուցանիշը ակտիվորեն փոխվում է:

PostgreSQL 12-ը զգալիորեն բարելավում է B-tree ինդեքսների կատարումը, և TPC-C-ի նման հենանիշերի հետ փորձերը ցույց են տվել, որ այժմ միջինում 40%-ով ավելի քիչ տարածք է օգտագործվում: Այժմ մենք ավելի քիչ ժամանակ ենք ծախսում ոչ միայն B-tree ինդեքսների պահպանման վրա (այսինքն՝ գրելու գործառնությունների վրա), այլև տվյալների առբերման վրա, քանի որ ինդեքսները շատ ավելի փոքր են։

Ծրագրեր, որոնք ակտիվորեն թարմացնում են իրենց աղյուսակները, սովորաբար OLTP հավելվածներ (գործարքների իրական ժամանակի մշակում) - շատ ավելի արդյունավետ կօգտագործի սկավառակը և կմշակի հարցումները: Որքան շատ սկավառակի տարածություն, այնքան ավելի շատ տարածք պետք է աճի տվյալների բազան՝ առանց ենթակառուցվածքի արդիականացման:

Որոշ արդիականացման ռազմավարություններ պահանջում են վերակառուցել B-tree ինդեքսները՝ այս առավելություններից օգտվելու համար (օրինակ. pg_upgrade ինքնաբերաբար չի վերակառուցի ինդեքսները): PostgreSQL-ի նախորդ տարբերակներում աղյուսակների վրա մեծ ինդեքսների վերակառուցումը հանգեցրեց զգալի խափանումների, քանի որ այդ ընթացքում հնարավոր չէր փոփոխություններ կատարել: Բայց PostgreSQL 12-ն ունի ևս մեկ հիանալի առանձնահատկություն. այժմ դուք կարող եք վերակառուցել ինդեքսները հրամանին զուգահեռ: REINDEX ՄԻԱԺԱՄԱՆԱԿամբողջովին խուսափելու պարապուրդից:

PostgreSQL 12-ում ինդեքսավորման ենթակառուցվածքի այլ բարելավումներ կան: Մեկ այլ բան, որտեղ ինչ-որ կախարդություն կար. առաջ գրել մատյան, որը կոչվում է WAL (նախապես գրելու մատյան): Գրանցման նախնական գրանցամատյանը գրանցում է PostgreSQL-ում յուրաքանչյուր գործարք՝ ձախողման և կրկնօրինակման դեպքում: Հավելվածներն այն օգտագործում են արխիվացնելու և ժամանակի վերականգնում. Իհարկե, առաջ գրելու մատյանը գրված է սկավառակի վրա, ինչը կարող է ազդել աշխատանքի վրա:

PostgreSQL 12-ը նվազեցրել է WAL գրառումների գերավճարը, որոնք ստեղծվում են GiST, GIN և SP-GiST ինդեքսներով ինդեքսի կառուցման ընթացքում: Սա ապահովում է մի քանի շոշափելի առավելություններ. WAL գրառումները ավելի քիչ տարածություն են զբաղեցնում սկավառակի վրա, և տվյալները վերարտադրվում են ավելի արագ, օրինակ՝ աղետից վերականգնման կամ ժամանակի վերականգնման ժամանակ: Եթե ​​դուք օգտագործում եք նման ինդեքսներ ձեր հավելվածներում (օրինակ, PostGIS-ի վրա հիմնված աշխարհատարածական հավելվածները շատ են օգտագործում GiST ինդեքսը), սա ևս մեկ առանձնահատկություն է, որը զգալիորեն կբարելավի փորձը՝ առանց ձեր կողմից որևէ ջանքի:

Բաժանում - ավելի մեծ, ավելի լավ, ավելի արագ

Ներկայացվեց PostgreSQL 10-ը դեկլարատիվ բաժանում. PostgreSQL 11-ում այն ​​շատ ավելի հեշտ է դարձել օգտագործել: PostgreSQL 12-ում կարող եք փոխել բաժինների մասշտաբը:

PostgreSQL 12-ում բաժանման համակարգի կատարումը զգալիորեն ավելի լավ է դարձել, հատկապես, եթե աղյուսակում կան հազարավոր բաժանումներ: Օրինակ, եթե հարցումն ազդի հազարավոր աղյուսակի միայն մի քանի բաժանմունքների վրա, այն կկատարվի շատ ավելի արագ: Կատարումը բարելավվել է ոչ միայն այս տեսակի հարցումների համար: Դուք նաև կիմանաք, թե որքան արագ են INSERT գործողությունները բազմաթիվ միջնորմներով աղյուսակների վրա:

Տվյալների գրանցում օգտագործելով COPY - Ի դեպ, սա հիանալի միջոց է զանգվածային տվյալների ներբեռնում և ահա մի օրինակ ստանալով JSON — PostgreSQL 12-ի բաժանված աղյուսակները նույնպես ավելի արդյունավետ են դարձել: COPY-ով ամեն ինչ արդեն արագ էր, բայց PostgreSQL 12-ում այն ​​բացարձակապես թռչում է:

Այս առավելությունների շնորհիվ PostgreSQL-ը թույլ է տալիս պահպանել նույնիսկ ավելի մեծ տվյալների հավաքածուներ և հեշտացնել դրանք առբերելը: Եվ ոչ մի ջանք ձեր կողմից: Եթե ​​հավելվածն ունի բազմաթիվ միջնորմներ, ինչպիսիք են ժամանակային շարքերի տվյալների գրանցումը, պարզ թարմացումը զգալիորեն կբարելավի դրա կատարումը:

Թեև սա հենց «բարելավում և վայելեք» բարելավում չէ, PostgreSQL 12-ը թույլ է տալիս ստեղծել օտարերկրյա բանալիներ, որոնք հղում են կատարում բաժանված աղյուսակներին՝ դարձնելով բաժանումը հաճելի աշխատելու համար:

ՀԵՏ հարցումները պարզապես շատ ավելի լավացան

Երբ կիրառվել է կարկատել ներկառուցված ընդհանուր աղյուսակի արտահայտությունների համար (aka CTE, aka WITH queries), ես չէի համբերում հոդված գրելու մասին որքան երջանիկ էին PostgreSQL հավելվածների մշակողները. Սա այն հատկանիշներից է, որոնք կարագացնեն հավելվածը։ Եթե, իհարկե, չեք օգտագործում CTE:

Ես հաճախ եմ նկատում, որ SQL-ի նորեկները սիրում են օգտագործել CTE-ներ, եթե դրանք գրում եք որոշակի ձևով, իսկապես թվում է, որ դուք հրամայական ծրագիր եք գրում: Անձամբ ես սիրում էի վերաշարադրել այս հարցումները՝ շրջանցելու համար առանց CTE և բարձրացնել արտադրողականությունը: Հիմա ամեն ինչ այլ է։

PostgreSQL 12-ը թույլ է տալիս ներդնել CTE-ի որոշակի տեսակ առանց կողմնակի ազդեցությունների (SELECT), որն օգտագործվում է միայն մեկ անգամ՝ հարցման ավարտին մոտ: Եթե ​​ես հետևեի CTE հարցումներին, որոնք ես նորից գրեցի, դրանցից շատերը կհայտնվեին այս կատեգորիայի մեջ: Սա օգնում է մշակողներին գրել հստակ կոդ, որն այժմ նույնպես արագ է աշխատում:

Ավելին, PostgreSQL 12-ն ինքնին օպտիմիզացնում է SQL-ի կատարումը՝ առանց որևէ բան անելու: Եվ չնայած ես, հավանաբար, կարիք չեմ ունենա օպտիմիզացնել նման հարցումները, բայց հիանալի է, որ PostgreSQL-ը շարունակում է աշխատել հարցումների օպտիմալացման վրա:

Just-in-Time (JIT) - այժմ լռելյայն

PostgreSQL 12 համակարգերում աջակցությամբ LLVM JIT կոմպիլյացիան լռելյայն միացված է: Առաջին հերթին, դուք ստանում եք աջակցություն JIT որոշ ներքին գործառնությունների համար, և երկրորդը, արտահայտություններով հարցումները (ամենապարզ օրինակը x + y) ընտրված ցուցակներում (որոնք ունեք SELECT-ից հետո), ագրեգատներ, WHERE կետերով արտահայտություններ և այլք կարող են օգտագործել JIT-ը կատարելագործելու համար:

Քանի որ JIT-ը լռելյայն միացված է PostgreSQL 12-ում, կատարումն ինքնին կբարելավվի, բայց ես խորհուրդ եմ տալիս փորձարկել հավելվածը PostgreSQL 11-ում, որը ներկայացրեց JIT-ը, որպեսզի չափեք հարցումների կատարողականը և տեսնեք, թե արդյոք ձեզ հարկավոր է որևէ բան կարգավորել:

Ի՞նչ կասեք PostgreSQL 12-ի մնացած նոր հնարավորությունների մասին:

PostgreSQL 12-ն ունի բազմաթիվ հիանալի նոր հնարավորություններ՝ JSON տվյալները ուսումնասիրելու հնարավորությունից՝ օգտագործելով ստանդարտ SQL/JSON երթուղու արտահայտությունները մինչև պարամետրով բազմագործոն նույնականացում: clientcert=verify-full, ստեղծել սյունակներ և շատ ավելին: Բավական է առանձին գրառման համար:

PostgreSQL 10-ի նման, PostgreSQL 12-ը կբարելավի ընդհանուր կատարումը թարմացումից անմիջապես հետո: Դուք, իհարկե, կարող եք ունենալ ձեր սեփական ուղին. փորձարկեք հավելվածը նմանատիպ պայմաններում արտադրական համակարգում, նախքան բարելավումները միացնելը, ինչպես ես արեցի PostgreSQL 10-ի հետ: Նույնիսկ եթե PostgreSQL 12-ն արդեն ավելի կայուն է, քան ես սպասում էի, մի ծույլ մի եղեք փորձարկման մեջ: դիմումները մանրակրկիտ կերպով, նախքան դրանք արտադրության մեջ թողնելը:

Source: www.habr.com