Հարգելի DELETE: Նիկոլայ Սամոխվալով (Postgres.ai)

Հեռավոր ապագայում անհարկի տվյալների ավտոմատ հեռացումը կլինի DBMS-ի կարևոր խնդիրներից մեկը [1]: Միևնույն ժամանակ, մենք ինքներս պետք է հոգ տանենք անհարկի տվյալների ջնջման կամ տեղափոխման մասին ավելի քիչ թանկ պահեստավորման համակարգեր: Ենթադրենք՝ որոշել եք ջնջել մի քանի միլիոն տող: Բավականին պարզ առաջադրանք, հատկապես, եթե պայմանը հայտնի է, և կա համապատասխան ցուցանիշ։ «DELETE FROM table1 WHERE col1 = :value» - ինչ կարող է լինել ավելի պարզ, չէ՞:

Video:

• «Հայլոդ» ծրագրի հանձնաժողովում եմ առաջին տարվանից, այսինքն՝ 2007 թվականից։

• Իսկ ես Postgres-ում եմ 2005 թվականից: Օգտագործել է այն բազմաթիվ նախագծերում:

• Խումբ RuPostges-ի հետ նույնպես 2007 թվականից։

• Meetup-ում մենք աճել ենք մինչև 2100+ մասնակից: Այն աշխարհում երկրորդն է Նյու Յորքից հետո՝ երկար ժամանակ շրջանցելով Սան Ֆրանցիսկոյից։

• Ես մի քանի տարի ապրել եմ Կալիֆորնիայում։ Ես ավելի շատ գործ ունեմ ամերիկյան, այդ թվում՝ խոշոր ընկերությունների հետ։ Նրանք Postgres-ի ակտիվ օգտատերեր են։ Եվ կան բոլոր տեսակի հետաքրքիր բաներ:

https://postgres.ai/ իմ ընկերությունն է: Մենք զբաղվում ենք այն առաջադրանքների ավտոմատացման բիզնեսով, որոնք վերացնում են զարգացման դանդաղումները:

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

https://www.seagate.com/files/www-content/our-story/trends/files/idc-seagate-dataage-whitepaper.pdf

Վերջերս Լոս Անջելեսի VLDB-ում էի: Սա տվյալների բազաների վերաբերյալ ամենամեծ համաժողովն է: Եվ եղավ հաղորդում, որ ապագայում DBMS-ը ոչ միայն կպահի, այլև ավտոմատ կերպով կջնջի տվյալները։ Սա նոր թեմա է։

Զետաբայթների աշխարհում ավելի ու ավելի շատ տվյալներ կան՝ դա 1 փետաբայթ է: Եվ հիմա արդեն հաշվարկվում է, որ մենք ունենք ավելի քան 000 զետաբայթ տվյալների պահպանում աշխարհում։ Եվ դրանք ավելի ու ավելի շատ են:

https://vldb2019.github.io/files/VLDB19-keynote-2-slides.pdf

Եվ ինչ անել դրա հետ: Ակնհայտ է, որ այն պետք է հեռացվի: Ահա այս հետաքրքիր զեկույցի հղումը: Բայց մինչ այժմ դա չի իրականացվել DBMS-ում:

Նրանք, ովքեր կարողանում են գումար հաշվել, երկու բան են ուզում. Նրանք ուզում են, որ մենք ջնջենք, ուստի տեխնիկապես մենք պետք է կարողանանք դա անել:

Այն, ինչ ես կպատմեմ հետո, ինչ-որ վերացական իրավիճակ է, որը ներառում է իրական իրավիճակների մի փունջ, այսինքն՝ մի տեսակ հավաքագրում, թե ինչ է իրականում կատարվել ինձ և շրջակա տվյալների բազաների հետ շատ անգամներ, շատ տարիներ: Ռեկերը ամենուր են, և բոլորը անընդհատ ոտքեր են դնում դրանց վրա:

Ասենք՝ ունենք բազա կամ մի քանի բազա, որոնք աճում են։ Իսկ որոշ գրառումներ ակնհայտորեն աղբ են: Օրինակ, օգտատերը սկսել է այնտեղ ինչ-որ բան անել, բայց չի ավարտել: Եվ որոշ ժամանակ անց մենք գիտենք, որ այս անավարտությունն այլևս չի կարող պահվել։ Այսինքն՝ մենք կցանկանայինք մաքրել որոշ աղբատարներ՝ տարածք խնայելու, կատարողականությունը բարելավելու համար և այլն։

Ընդհանրապես, խնդիր է դրված ավտոմատացնել կոնկրետ բաների, կոնկրետ գծերի հեռացումը ինչ-որ աղյուսակում։

Եվ մենք ունենք նման խնդրանք, որի մասին կխոսենք այսօր, այն է՝ աղբահանության մասին։

Մենք խնդրեցինք դա անել փորձառու ծրագրավորողից: Նա վերցրեց այս խնդրանքը, ստուգեց այն իր համար. ամեն ինչ աշխատում է: Փորձարկվել է բեմադրության վրա՝ ամեն ինչ լավ է: Գլորվել է - ամեն ինչ աշխատում է: Օրը մեկ անգամ մենք գործարկում ենք այն - ամեն ինչ լավ է:

Տվյալների բազան աճում և աճում է: Daily DELETE-ը սկսում է մի փոքր ավելի դանդաղ աշխատել:

Հետո մենք հասկանում ենք, որ այժմ ունենք մարքեթինգային ընկերություն, և տրաֆիկը մի քանի անգամ ավելի մեծ կլինի, ուստի որոշում ենք ժամանակավորապես դադարեցնել ավելորդ բաները։ Եվ մոռացեք վերադառնալ:

Մի քանի ամիս անց նրանք հիշեցին. Եվ այդ ծրագրավորողը թողեց կամ այլ բանով է զբաղված, մեկ ուրիշին հանձնարարեց վերադարձնել այն:

Նա ստուգել է dev-ը, բեմադրությունը՝ ամեն ինչ կարգին է: Բնականաբար, դեռ պետք է մաքրել կուտակվածը։ Նա ստուգեց, որ ամեն ինչ աշխատում է:

Ի՞նչ կլինի հետո։ Հետո մեզ մոտ ամեն ինչ քանդվում է։ Այն ընկնում է այնպես, որ ինչ-որ պահի ամեն ինչ ընկնում է: Բոլորը շոկի մեջ են, ոչ ոք չի հասկանում, թե ինչ է կատարվում։ Եվ հետո պարզվում է, որ բանը եղել է այս DELETE-ում։

Ինչ որ բան այնպես չգնաց? Ահա ցուցակը, թե ինչ կարող էր սխալ լինել: Սրանցից ո՞րն է ամենակարևորը:

• Օրինակ՝ վերանայում չի եղել, այսինքն՝ DBA փորձագետը չի նայել։ Փորձառու աչքով անմիջապես կգտներ խնդիրը, բացի այդ, նրան հասանելի է արդյունահանումը, որտեղ մի քանի միլիոն տող է կուտակվել։

• Երևի սխալ են ստուգել։

• Միգուցե ապարատը հնացած է, և դուք պետք է թարմացնեք այս բազան:

• Կամ ինչ-որ բան այն չէ հենց տվյալների բազայում, և մենք պետք է Postgres-ից տեղափոխվենք MySQL:

• Կամ գուցե ինչ-որ բան այն չէ վիրահատության մեջ:

• Միգուցե աշխատանքի կազմակերպման հարցում որոշ սխալներ կան, և պետք է ինչ-որ մեկին աշխատանքից ազատել և աշխատանքի ընդունել լավագույն մարդկանց:

DBA ստուգում չի եղել: Եթե ​​լիներ DBA, նա կտեսներ այս մի քանի միլիոն տողերը և նույնիսկ առանց որևէ փորձի կասեր. «Նրանք այդպես չեն անում»: Ենթադրենք, եթե այս կոդը լիներ GitLab-ում, GitHub-ում և լիներ կոդի վերանայման գործընթաց, և չլիներ նման բան, որ առանց DBA-ի հաստատման այս գործողությունը տեղի ունենար արդյունահանման վրա, ապա ակնհայտորեն DBA-ն կասեր. «Սա չի կարելի անել: »:

Եվ նա կասեր, որ դուք խնդիրներ կունենաք սկավառակի IO-ի հետ, և բոլոր պրոցեսները կխենթանան, կարող են կողպեքներ լինել, ինչպես նաև դուք մի քանի րոպեով կփակեք ավտովակուումը, այնպես որ սա լավ չէ:

http://bit.ly/nancy-hl2018-2

Երկրորդ սխալը՝ սխալ տեղում են ստուգել։ Մենք տեսանք այն բանից հետո, որ շատ անպետք տվյալներ կուտակվեցին prod-ի վրա, բայց մշակողը չուներ կուտակված տվյալներ այս տվյալների բազայում, և ոչ ոք չստեղծեց այս աղբը բեմադրման ընթացքում: Համապատասխանաբար, կար 1 տող, որոնք արագ մշակվեցին:

Մենք հասկանում ենք, որ մեր թեստերը թույլ են, այսինքն՝ կառուցված գործընթացը խնդիրներ չի առաջացնում։ Համարժեք DB փորձ չի իրականացվել:

Իդեալական փորձը նախընտրելի է իրականացնել նույն սարքավորման վրա։ Միշտ չէ, որ դա հնարավոր է անել նույն սարքավորման վրա, բայց շատ կարևոր է, որ այն լինի տվյալների բազայի ամբողջական չափի պատճեն: Սա այն է, ինչ ես քարոզում եմ արդեն մի քանի տարի։ Եվ մեկ տարի առաջ ես խոսեցի այս մասին, դուք կարող եք դիտել այդ ամենը YouTube-ում:

Միգուցե մեր սարքավորումները վատն են։ Եթե ​​նայեք, ապա ուշացումը թռավ: Մենք տեսել ենք, որ օգտագործումը 100 տոկոս է։ Իհարկե, եթե դրանք լինեին ժամանակակից NVMe կրիչներ, ապա հավանաբար մեզ համար շատ ավելի հեշտ կլիներ: Եվ միգուցե մենք դրանից չպառկվեինք։

Եթե ​​դուք ունեք ամպեր, ապա արդիականացումը հեշտությամբ կատարվում է այնտեղ: Բարձրացրել են նոր կրկնօրինակներ նոր սարքավորումների վրա: անցում. Եվ ամեն ինչ լավ է: Բավականին հեշտ:

Հնարավո՞ր է ինչ-որ կերպ դիպչել փոքր սկավառակներին: Եվ այստեղ, պարզապես DBA-ի օգնությամբ, մենք սուզվում ենք որոշակի թեմայի մեջ, որը կոչվում է անցակետի թյունինգ: Ստացվում է, որ մենք անցակետի թյունինգ չենք ունեցել։

Ի՞նչ է անցակետը: Այն գտնվում է ցանկացած DBMS-ում: Երբ դուք ունեք տվյալներ հիշողության մեջ, որոնք փոխվում են, դրանք անմիջապես չեն գրվում սկավառակի վրա: Տեղեկատվությունը, որ տվյալները փոխվել են, նախ գրվում է նախօրոք գրանցման մատյանում: Եվ ինչ-որ պահի, DBMS-ը որոշում է, որ ժամանակն է իրական էջերը սկավառակի վրա թափել, որպեսզի եթե մենք ձախողենք, կարողանանք ավելի քիչ REDO անել: Դա նման է խաղալիքի: Եթե ​​մեզ սպանեն, մենք խաղը կսկսենք վերջին անցակետից։ Եվ բոլոր DBMS-ները դա իրականացնում են:

Postgres-ի կարգավորումները հետ են մնում: Դրանք նախատեսված են 10-15 տարեկան տվյալների և գործարքների ծավալների համար։ Եվ անցակետը բացառություն չէ։

Ահա տեղեկատվությունը մեր Postgres ստուգման զեկույցից, այսինքն՝ առողջության ավտոմատ ստուգումից: Եվ ահա մի քանի տերաբայթանոց տվյալների բազա: Եվ լավ երեւում է, որ գրեթե 90 տոկոս դեպքերում հարկադիր անցակետերը։

Ինչ է դա նշանակում? Այնտեղ երկու կարգավորում կա. Անցակետը կարող է գալ ժամանակի դադարով, օրինակ՝ 10 րոպեի ընթացքում: Կամ դա կարող է առաջանալ, երբ բավականին շատ տվյալներ են լրացվել:

Իսկ լռելյայնորեն max_wal_saze-ը սահմանված է 1 գիգաբայթ: Փաստորեն, դա իսկապես տեղի է ունենում Postgres-ում 300-400 մեգաբայթից հետո: Դուք այնքան շատ տվյալներ եք փոխել, և ձեր անցակետը տեղի է ունենում:

Եվ եթե ոչ ոք չի կարգավորել, և սպասարկումն աճել է, և ընկերությունը մեծ գումարներ է վաստակում, շատ գործարքներ ունի, ապա անցակետը գալիս է րոպեն մեկ, երբեմն 30 վայրկյանը մեկ և երբեմն նույնիսկ համընկնում: Սա բավականին վատ է:

Եվ մենք պետք է համոզվենք, որ դա ավելի քիչ է լինում: Այսինքն, մենք կարող ենք բարձրացնել max_wal_size: Եվ դա ավելի քիչ կլինի:

Բայց մենք մշակել ենք մի ամբողջ մեթոդաբանություն, թե ինչպես դա անել ավելի ճիշտ, այսինքն՝ ինչպես որոշում կայացնել կարգավորումների ընտրության վերաբերյալ՝ հստակորեն հիմնված կոնկրետ տվյալների վրա։

Ըստ այդմ, մենք երկու շարք փորձեր ենք կատարում տվյալների բազաների վրա։

Առաջին շարքը` մենք փոխում ենք max_wal_size: Եվ մենք հսկայական գործողություն ենք իրականացնում: Նախ, մենք դա անում ենք 1 գիգաբայթի լռելյայն պարամետրով: Եվ մենք կատարում ենք միլիոնավոր տողերի զանգվածային Ջնջում:

Դուք տեսնում եք, թե որքան դժվար է մեզ համար: Մենք տեսնում ենք, որ սկավառակի IO-ն շատ վատն է: Մենք նայում ենք, թե քանի WAL ենք ստեղծել, քանի որ սա շատ կարևոր է: Տեսնենք, թե քանի անգամ է եղել անցակետը։ Եվ մենք տեսնում ենք, որ դա լավ չէ։

Հաջորդը մենք մեծացնում ենք max_wal_size-ը: Կրկնում ենք. Մենք ավելացնում ենք, կրկնում ենք. Եվ այսքան անգամ: Սկզբունքորեն 10 միավորը լավ է, որտեղ 1, 2, 4, 8 գիգաբայթ: Եվ մենք նայում ենք որոշակի համակարգի վարքագծին: Հասկանալի է, որ այստեղ սարքավորումները պետք է լինեն արդ. Դուք պետք է ունենաք նույն սկավառակները, նույն քանակությամբ հիշողություն և նույն Postgres-ի կարգավորումները:

Եվ այսպես մենք կփոխանակենք մեր համակարգը, և մենք գիտենք, թե ինչպես է վարվելու DBMS-ը վատ զանգվածային DELETE-ի դեպքում, ինչպես է այն անցակետը:

Անցակետը ռուսերենով անցակետեր են։

Օրինակ՝ Ջնջել մի քանի միլիոն տող ըստ ինդեքսի, տողերը «ցրված» են էջերի վրա:

Ահա մի օրինակ. Սա ինչ-որ հիմք է: Իսկ max_wal_size-ի համար 1 գիգաբայթ լռելյայն կարգավորումով, շատ պարզ է, որ մեր սկավառակները գնում են դարակ՝ ձայնագրման համար։ Այս նկարը շատ հիվանդ հիվանդի բնորոշ ախտանիշ է, այսինքն՝ նա իսկապես իրեն վատ է զգացել։ Եվ կար մեկ եզակի գործողություն, ընդամենը մի քանի միլիոն տողերի Ջնջում էր:

Եթե ​​պրոդում թույլատրվի նման վիրահատություն, ապա մենք ուղղակի կպառկենք, քանի որ պարզ է, որ մեկ ՋՆՋՈՒՄԸ մեզ սպանում է դարակում։

Ավելին, որտեղ 16 գիգաբայթ, պարզ է, որ ատամներն արդեն գնացել են։ Ատամներն արդեն ավելի լավն են, այսինքն՝ առաստաղ ենք թակում, բայց ոչ այնքան վատ։ Այնտեղ որոշակի ազատություն կար։ Աջ կողմում արձանագրությունն է։ Իսկ գործողությունների քանակը՝ երկրորդ գրաֆիկը։ Եվ պարզ է, որ մենք արդեն մի փոքր ավելի հեշտ ենք շնչում, երբ 16 գիգաբայթ:

Իսկ որտեղ 64 գիգաբայթ է երեւում, որ լրիվ լավացել է։ Արդեն ատամներն արտահայտված են, ավելի շատ հնարավորություններ կան՝ գոյատևելու այլ վիրահատություններ և ինչ-որ բան անելու սկավառակի հետ։

Ինչու:

Ես մի փոքր խորանալու եմ մանրամասների մեջ, բայց այս թեման, թե ինչպես անցկացնել անցակետի թյունինգը, կարող է հանգեցնել մի ամբողջ զեկույցի, այնպես որ ես շատ չեմ բեռնի, բայց մի փոքր կնշեմ, թե ինչ դժվարություններ կան:

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

Եվ մենք կստիպենք, որ անցակետը բազմիցս փրկի այն։ Ինչպե՞ս նրա համար ավելորդ վիրահատություններ կլինեն։

Բայց սա դեռ ամենը չէ։ Postgres-ում էջերը 8 կիլոբայթ են, իսկ Linux-ում՝ 4 կիլոբայթ: Եվ կա full_page_writes պարամետր: Այն լռելյայն միացված է: Եվ սա ճիշտ է, քանի որ եթե այն անջատենք, ապա վտանգ կա, որ այն խափանելու դեպքում կպահպանվի միայն էջի կեսը։

Փոխանցման մատյան WAL-ին գրելու վարքագիծն այնպիսին է, որ երբ մենք ունենք անցակետ և առաջին անգամ փոխում ենք էջը, ամբողջ էջը, այսինքն՝ բոլոր 8 կիլոբայթը, մտնում է առաջի մատյան, թեև մենք միայն փոխել ենք տող, որը կշռում է 100 բայթ: Եվ մենք պետք է գրենք ամբողջ էջը:

Հետագա փոփոխություններում կլինի միայն կոնկրետ կրկնակի, բայց առաջին անգամ մենք գրում ենք ամեն ինչ:

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

Եվ, համապատասխանաբար, ունենք երկու կրճատում.

Եթե ​​մեծացնենք max_wal_size-ը, կստացվի, որ հեշտացնում ենք թե՛ անցակետը, թե՛ wal writer-ը։ Եվ դա հիանալի է:

Եկեք մի տերաբայթ դնենք ու դրանով ապրենք։ Ի՞նչ վատ բան կա դրա մեջ: Սա վատ է, քանի որ ձախողման դեպքում մենք ժամերով բարձրանալու ենք, քանի որ անցակետը վաղուց էր և արդեն շատ բան է փոխվել։ Եվ մենք պետք է այս ամենը REDO-ն անենք: Եվ այսպես, մենք կատարում ենք փորձերի երկրորդ շարքը։

Մենք գործողություններ ենք կատարում և տեսնում ենք, երբ անցակետն ավարտվում է, մենք դիտմամբ սպանում ենք -9 Postgres-ին:

Եվ դրանից հետո մենք նորից սկսում ենք այն, և տեսնում ենք, թե որքան ժամանակ այն կբարձրանա այս սարքավորման վրա, այսինքն՝ որքանով այն կվերամշակվի այս վատ իրավիճակում:

Երկու անգամ նշեմ, որ վիճակը վատ է. Նախ, մենք վթարի ենթարկվեցինք անցակետի ավարտից անմիջապես առաջ, ուստի կորցնելու շատ բան ունենք: Եվ երկրորդը՝ մենք զանգվածային վիրահատություն ենք տարել։ Եվ եթե անցակետերը հայտնվեին ժամանակին, ապա, ամենայն հավանականությամբ, ավելի քիչ WAL կստեղծվեր վերջին անցակետից հետո: Այսինքն՝ կրկնակի պարտվող է։

Մենք չափում ենք նման իրավիճակը տարբեր max_wal_size չափերի համար և հասկանում ենք, որ եթե max_wal_size-ը 64 գիգաբայթ է, ապա կրկնակի վատագույն դեպքում մենք կբարձրանանք 10 րոպեով։ Եվ մենք մտածում ենք՝ դա մեզ սազո՞ւմ է, թե՞ ոչ։ Սա բիզնեսի հարց է: Մենք պետք է ցույց տանք այս նկարը բիզնես որոշումների համար պատասխանատուներին և հարցնենք. «Առավելագույնը որքա՞ն ժամանակ կարող ենք պառկել խնդրի դեպքում: Կարո՞ղ ենք ամենավատ իրավիճակում 3-5 րոպե պառկել։ Եվ դուք որոշում եք կայացնում:

Եվ ահա մի հետաքրքիր կետ. Համաժողովում Պատրոնիի մասին մի երկու զեկույց ունենք։ Եվ գուցե դուք օգտագործում եք այն: Սա Postgres-ի ավտոմատ ֆայլեր է: GitLab-ը և Data Egret-ը խոսել են այս մասին:

Եվ եթե դուք ունեք ավտոմատ ֆայլովոր, որը գալիս է 30 վայրկյանում, ապա միգուցե մենք կարող ենք պառկել 10 րոպե: Որովհետև այս պահին մենք կանցնենք կրկնօրինակին, և ամեն ինչ լավ կլինի: Սա վիճելի հարց է: Ես հստակ պատասխան չգիտեմ։ Ես պարզապես զգում եմ, որ այս թեման միայն վթարի վերականգնման շուրջ չէ։

Եթե ​​ձախողումից հետո երկար վերականգնում ունենք, ապա շատ այլ իրավիճակներում մեզ անհարմար կզգանք: Օրինակ՝ նույն փորձերի ժամանակ, երբ մենք ինչ-որ բան ենք անում և երբեմն ստիպված ենք լինում սպասել 10 րոպե։

Ես դեռ շատ հեռու չէի գնա, նույնիսկ եթե մենք ունենանք autofailover: Որպես կանոն, այնպիսի արժեքներ, ինչպիսիք են 64, 100 գիգաբայթը, լավ արժեքներ են: Երբեմն նույնիսկ արժե ավելի քիչ ընտրել: Ընդհանրապես, սա նուրբ գիտություն է։

Կրկնումներ կատարելու համար, օրինակ, max_wal_size =1, 8, պետք է բազմիցս կրկնել զանգվածային գործողությունը: Դու կատարեցիր դա. Եվ նույն հիմքի վրա ուզում ես նորից անել, բայց արդեն ջնջել ես ամեն ինչ։ Ինչ անել?

Ես ավելի ուշ կխոսեմ մեր լուծման մասին, թե ինչ ենք մենք անում նման իրավիճակներում կրկնելու համար: Եվ սա ամենաճիշտ մոտեցումն է։

Բայց այս դեպքում մեր բախտը բերեց։ Եթե, ինչպես ասվում է այստեղ «ՍԿՍԵԼ, ՋՆՋԵԼ, ՇՏԱՊԵԼ», ապա կարող ենք կրկնել ՋՆՋԵԼ։ Այսինքն, եթե մենք ինքներս չեղարկել ենք, ապա կարող ենք կրկնել։ Եվ ֆիզիկապես ձեր մոտ տվյալները կլինեն նույն տեղում: Դուք նույնիսկ ոչ մի փքվածություն չեք ստանում: Դուք կարող եք կրկնել նման DELETE-ների վրա:

Այս DELETE-ը ROLLBACK-ով իդեալական է անցակետի թյունինգի համար, նույնիսկ եթե դուք չունեք պատշաճ կերպով տեղակայված տվյալների բազայի լաբորատորիաներ:

Մեկ «i» սյունակով ափսե ենք պատրաստել։ Postgres-ն ունի օգտակար սյունակներ: Նրանք անտեսանելի են, եթե հատուկ չխնդրեն: Դրանք են՝ ctid, xmid, xmax:

Ctid-ը ֆիզիկական հասցե է: Զրոյական էջ՝ էջի առաջին բազմապատիկը։

Երևում է, որ ROOLBACK-ից հետո դուբլը մնացել է նույն տեղում։ Այսինքն՝ կարող ենք նորից փորձել, նույն կերպ կվարվի։ Սա է գլխավորը։

Xmax-ը բազմակի մահվան ժամանակն է: Այն դրոշմված էր, բայց Postgres-ը գիտի, որ գործարքը հետ է գլորվել, ուստի կապ չունի՝ 0 է, թե հետադարձ գործարք: Սա հուշում է, որ հնարավոր է կրկնել DELETE-ի վրա և ստուգել համակարգի վարքագծի հիմնական գործառնությունները: Դուք կարող եք ստեղծել տվյալների բազայի լաբորատորիաներ աղքատների համար:

Խոսքը ծրագրավորողների մասին է։ DBA-ի մասին նույնպես սրա համար միշտ նախատում են ծրագրավորողներին. «Ինչո՞ւ եք այդքան երկար ու բարդ գործողություններ անում»: Սա բոլորովին այլ ուղղահայաց թեմա է։ Ժամանակին վարչարարություն կար, հիմա էլ զարգացում կլինի։

Ակնհայտ է, որ մենք կտոր-կտոր չենք արել։ Պարզ է. Անհնար է միլիոնավոր տողերի կույտի համար նման Ջնջել մասերի չկոտրել։ Դա կարվի 20 րոպե, և ամեն ինչ կպառկի։ Բայց, ցավոք, նույնիսկ փորձառու մշակողները սխալներ են թույլ տալիս, նույնիսկ շատ խոշոր ընկերություններում:

Ինչու՞ է կարևոր կոտրելը:

• Եթե ​​տեսնենք, որ սկավառակը կոշտ է, ապա եկեք դանդաղեցնենք այն։ Եվ եթե մենք կոտրված ենք, ապա մենք կարող ենք ավելացնել դադարներ, կարող ենք դանդաղեցնել շնչափողը:

• Իսկ ուրիշներին երկար ժամանակ չենք արգելափակելու։ Որոշ դեպքերում դա նշանակություն չունի, եթե դուք ջնջում եք իրական աղբը, որի վրա ոչ ոք չի աշխատում, ապա, ամենայն հավանականությամբ, դուք չեք արգելափակի որևէ մեկին, բացի ավտովակուումային աշխատանքից, քանի որ այն կսպասի գործարքի ավարտին: Բայց եթե դուք հեռացնեք մի բան, որը մեկ ուրիշը կարող է պահանջել, ապա նրանք կարգելափակվեն, ինչ-որ շղթայական ռեակցիա կլինի: Կայքերում և բջջային հավելվածներում պետք է խուսափել երկարատև գործարքներից:

https://postgres.ai/products/joe/

Սա հետաքրքիր է։ Ես հաճախ տեսնում եմ, որ մշակողները հարցնում են. «Ի՞նչ փաթեթի չափս պետք է ընտրեմ»:

Հասկանալի է, որ որքան մեծ է փաթեթի չափը, այնքան փոքր է գործարքի վերին ծախսը, այսինքն՝ գործարքների լրացուցիչ ծախսերը: Բայց միևնույն ժամանակ ավելանում է այս գործարքի ժամանակը։

Ես շատ պարզ կանոն ունեմ՝ վերցրեք որքան կարող եք, բայց մի անցեք գործարկվողների վրա վայրկյանում:

Ինչու՞ մի վայրկյան: Բացատրությունը շատ պարզ է ու հասկանալի բոլորին, նույնիսկ ոչ տեխնիկական մարդկանց։ Մենք տեսնում ենք արձագանք. Վերցնենք 50 միլիվայրկյան: Եթե ​​ինչ-որ բան փոխվել է, ուրեմն մեր աչքը կարձագանքի։ Եթե ​​ավելի քիչ, ապա ավելի դժվար: Եթե ​​ինչ-որ բան արձագանքում է 100 միլիվայրկյան անց, օրինակ, դուք սեղմել եք մկնիկը, և նա ձեզ պատասխանել է 100 միլիվայրկյան անց, դուք արդեն զգում եք այս փոքր ուշացումը: Երկրորդն արդեն ընկալվում է որպես արգելակներ։

Համապատասխանաբար, եթե մենք բաժանենք մեր զանգվածային գործողությունները 10 վայրկյանանոց պոռթկումների, ապա մենք ռիսկ ունենք, որ ինչ-որ մեկին արգելափակելու ենք։ Եվ դա կաշխատի մի քանի վայրկյան, և մարդիկ դա արդեն կնկատեն։ Ուստի ես նախընտրում եմ մեկ վայրկյանից ավելի չանել։ Բայց միևնույն ժամանակ, մի կոտրեք այն շատ մանրակրկիտ, քանի որ գործարքի գումարը նկատելի կլինի: Հիմքը ավելի կոշտ կլինի, և այլ տարբեր խնդիրներ կարող են առաջանալ:

Մենք ընտրում ենք փաթեթի չափը։ Յուրաքանչյուր դեպքում մենք կարող ենք դա անել տարբեր կերպ: Կարող է ավտոմատացված լինել: Եվ մենք համոզված ենք մեկ տուփի մշակման արդյունավետության մեջ։ Այսինքն՝ մենք ջնջում ենք մեկ փաթեթը կամ ԹԱՐՄԱՑՆՈՒՄ:

Ի դեպ, այն ամենը, ինչի մասին ես խոսում եմ, միայն ՋՆՋԵԼՈՒ մասին չէ։ Ինչպես կռահեցիք, սրանք տվյալների վրա կատարված ցանկացած զանգվածային գործողություններ են:

Եվ մենք տեսնում ենք, որ ծրագիրը գերազանց է։ Դուք կարող եք տեսնել ինդեքսի սկանավորումը, միայն ինդեքսների սկանավորումն ավելի լավն է: Եվ մենք ունենք փոքր քանակությամբ տվյալներ: Եվ մեկ վայրկյանից էլ քիչ է կատարում: Սուպեր.

Եվ մենք դեռ պետք է համոզվենք, որ դեգրադացիա չլինի։ Պատահում է, որ առաջին փաթեթները արագ են ստացվում, իսկ հետո վատանում, վատանում ու վատանում։ Գործընթացն այնպիսին է, որ պետք է շատ փորձարկել։ Սա հենց այն է, ինչի համար են տվյալների բազայի լաբորատորիաները:

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

Եթե ​​մենք պետք է ստուգենք հարցումների արդյունավետությունը, և մենք պետք է բազմիցս կրկնենք, ապա գոյություն ունի նման բան, որը կոչվում է գործընկեր բոտ: Նա արդեն պատրաստ է։ Այն օգտագործվում է օրական տասնյակ ծրագրավորողների կողմից: Եվ նա գիտի, թե ինչպես 30 վայրկյանում խնդրանքով տալ հսկայական տերաբայթ տվյալների բազա՝ ձեր սեփական պատճենը: Եվ դուք կարող եք այնտեղ ինչ-որ բան ջնջել և ասել RESET, և նորից ջնջել այն: Դուք կարող եք փորձարկել դրա հետ այս կերպ. Ես այս բանի համար ապագա եմ տեսնում: Եվ մենք դա արդեն անում ենք։

https://docs.gitlab.com/ee/development/background_migrations.html

Որո՞նք են բաժանման ռազմավարությունները: Ես տեսնում եմ բաժանման 3 տարբեր ռազմավարություններ, որոնք օգտագործում են փաթեթի մշակողները:

Առաջինը շատ պարզ է. Մենք ունենք թվային ID: Եվ եկեք այն բաժանենք տարբեր ինտերվալների և աշխատենք դրա հետ: Բացասական կողմը պարզ է. Առաջին սեգմենտում կարող է ունենալ 100 տող իրական աղբ, երկրորդում 5 տողով կամ ընդհանրապես չլինենք, կամ էլ 1 տողն էլ աղբ դուրս գա։ Շատ անհավասար աշխատանք է, բայց հեշտ է կոտրել։ Նրանք վերցրել են առավելագույն ID-ն ու ջարդել են այն։ Սա միամիտ մոտեցում է։

Երկրորդ ռազմավարությունը հավասարակշռված մոտեցում է: Այն օգտագործվում է Gitlab-ում։ Նրանք վերցրեցին և սկանավորեցին սեղանը։ Մենք գտանք նույնականացման տուփերի սահմանները, որպեսզի յուրաքանչյուր փաթեթ ուներ ուղիղ 10 գրառում: Եվ դրանք հերթագրեք: Եվ հետո մենք մշակում ենք: Դուք կարող եք դա անել մի քանի թեմաներով:

Առաջին ռազմավարության մեջ նույնպես, ի դեպ, դուք կարող եք դա անել մի քանի թելերով։ Դժվար չէ։

https://medium.com/@samokhvalov/how-partial-indexes-affect-update-performance-in-postgres-d05e0052abc

Բայց կա ավելի սառը և ավելի լավ մոտեցում: Սա երրորդ ռազմավարությունն է։ Եվ երբ հնարավոր է, ավելի լավ է ընտրել այն: Մենք դա անում ենք հատուկ ինդեքսի հիման վրա։ Այս դեպքում, ամենայն հավանականությամբ, դա կլինի ինդեքս՝ ըստ մեր աղբի վիճակի և ID-ի։ Մենք կներառենք ID-ն, որպեսզի այն լինի միայն ինդեքսային սկանավորում, որպեսզի մենք չգնանք կույտին:

Ընդհանրապես, միայն ինդեքսների սկանավորումն ավելի արագ է, քան ինդեքսի սկանավորումը:

Եվ մենք արագ գտնում ենք մեր ID-ները, որոնք ցանկանում ենք ջնջել: BATCH_SIZE մենք ընտրում ենք նախապես: Եվ մենք ոչ միայն ստանում ենք դրանք, այլ ստանում ենք դրանք հատուկ ձևով և անմիջապես կոտրում: Բայց մենք կողպում ենք, որ եթե արդեն կողպված են, ոչ թե կողպենք, այլ անցնենք ու վերցնենք հաջորդները։ Սա թարմացման համար է, որ բաց թողնելն արգելափակված է: Postgres-ի այս սուպեր հատկությունը մեզ թույլ է տալիս աշխատել մի քանի թելերով, եթե ցանկանում ենք: Հնարավոր է մեկ հոսքով։ Եվ այստեղ կա CTE - սա մեկ խնդրանք է: Եվ մենք իրական ջնջում ունենք այս CTE-ի երկրորդ հարկում. returning *. Դուք կարող եք վերադարձնել ID-ն, բայց դա ավելի լավ է *եթե յուրաքանչյուր տողում շատ տվյալներ չունեք:

Ինչո՞ւ է դա մեզ պետք: Սա այն է, ինչ մենք պետք է զեկուցենք: Մենք հիմա իրականում այդքան շատ տողեր ենք ջնջել: Եվ մենք ունենք սահմաններ ID-ով կամ ստեղծված_at-ով, այսպես. Դուք կարող եք կատարել min, max. Կարելի է ուրիշ բան անել։ Այստեղ դուք կարող եք շատ բան անել: Եվ դա շատ հարմար է մոնիտորինգի համար։

Ցուցանիշի վերաբերյալ կա ևս մեկ նշում. Եթե ​​մենք որոշենք, որ մեզ անհրաժեշտ է հատուկ ինդեքս այս առաջադրանքի համար, ապա մենք պետք է համոզվենք, որ այն չի փչացնի միայն բազմակի թարմացումները: Այսինքն՝ Պոստգրեսը նման վիճակագրություն ունի։ Սա կարելի է տեսնել pg_stat_user_tables-ում ձեր աղյուսակում: Դուք կարող եք տեսնել՝ թեժ թարմացումներն օգտագործվում են, թե ոչ:

Կան իրավիճակներ, երբ ձեր նոր ցուցանիշը կարող է պարզապես կտրել դրանք: Եվ դուք ունեք մնացած բոլոր թարմացումները, որոնք արդեն աշխատում են, դանդաղեցրեք: Ոչ միայն այն պատճառով, որ ինդեքսը հայտնվել է (յուրաքանչյուր ինդեքս մի փոքր դանդաղեցնում է թարմացումները, բայց մի փոքր), բայց այստեղ այն դեռ փչացնում է այն: Իսկ այս աղյուսակի համար հատուկ օպտիմալացում անել հնարավոր չէ։ Սա երբեմն պատահում է: Սա այնպիսի նրբություն է, որ քչերն են հիշում։ Եվ այս փոցխը հեշտ է քայլել: Երբեմն պատահում է, որ պետք է մյուս կողմից մոտեցում գտնել և դեռ անել առանց այս նոր ինդեքսի, կամ կազմել այլ ինդեքս, կամ ինչ-որ այլ ձևով, օրինակ, կարող ես օգտագործել երկրորդ մեթոդը։

Բայց սա ամենաօպտիմալ ռազմավարությունն է՝ ինչպես բաժանվել խմբաքանակների և մեկ խնդրանքով կրակել խմբաքանակների վրա, մի փոքր ջնջել և այլն։

Երկար գործարքներ https://gitlab.com/snippets/1890447

Արգելափակված ավտովակուում - https://gitlab.com/snippets/1889668

արգելափակման խնդիր - https://gitlab.com/snippets/1890428

Թիվ 5 սխալը մեծ է: Նիկոլայը Okmeter-ից խոսեց Postgres մոնիտորինգի մասին: Իդեալական Postgres մոնիտորինգը, ցավոք, գոյություն չունի: Ոմանք ավելի մոտ են, ոմանք ավելի հեռու: Okmeter-ը բավական մոտ է կատարյալ լինելուն, բայց շատ բան բացակայում է և պետք է ավելացնել: Դուք պետք է պատրաստ լինեք դրան:

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

Եթե ​​կա մեծ IO, ապա պարզ է, որ սա լավ չէ:

Երկար գործարքներ նույնպես: Երկարատև գործարքները չպետք է թույլատրվեն OLTP-ով: Եվ ահա հատվածի հղումը, որը թույլ է տալիս վերցնել այս հատվածը և արդեն կատարել երկարատև գործարքների որոշակի հետևում:

Ինչու են երկար գործարքները վատ: Քանի որ բոլոր կողպեքները կազատվեն միայն վերջում: Եվ մենք բոլորին խփում ենք: Բացի այդ, մենք արգելափակում ենք ավտովակուումը բոլոր սեղանների համար: Դա բոլորովին լավ չէ։ Նույնիսկ եթե կրկնօրինակի վրա միացված է տաք սպասման ռեժիմը, դա դեռ վատ է: Ընդհանրապես, ոչ մի տեղ ավելի լավ չէ խուսափել երկարատև գործարքներից։

Եթե ​​մենք ունենք բազմաթիվ աղյուսակներ, որոնք վակուումացված չեն, ապա մենք պետք է ահազանգ ունենանք: Այստեղ հնարավոր է նման իրավիճակ. Մենք կարող ենք անուղղակիորեն ազդել ավտովակուումի շահագործման վրա: Սա մի հատված է Avito-ից, որը ես մի փոքր բարելավեցի: Եվ պարզվեց, որ դա հետաքրքիր գործիք է, որպեսզի տեսնենք, թե ինչ ունենք ավտովակուումով: Օրինակ, որոշ սեղաններ սպասում են այնտեղ և չեն սպասի իրենց հերթին։ Դուք նաև պետք է այն դնեք մոնիտորինգի մեջ և ունենաք ահազանգ:

Եվ թողարկում է բլոկներ: Բլոկ ծառերի անտառ. Ես սիրում եմ ինչ-որ մեկից ինչ-որ բան վերցնել և բարելավել այն: Այստեղ ես վերցրեցի մի զով ռեկուրսիվ CTE Data Egret-ից, որը ցույց է տալիս կողպեքի ծառերի անտառը: Սա լավ ախտորոշիչ գործիք է: Եվ դրա հիման վրա դուք կարող եք նաև կառուցել մոնիտորինգ: Բայց դա պետք է արվի ուշադիր: Ձեզ համար պետք է մի փոքր statement_timeout անել: Իսկ lock_timeout-ը ցանկալի է։

Երբեմն այս բոլոր սխալները տեղի են ունենում ընդհանուր առմամբ:

Իմ կարծիքով այստեղ հիմնական սխալը կազմակերպչական է։ Դա կազմակերպչական է, քանի որ տեխնիկան չի ձգում։ Սա թիվ 2-ն է՝ սխալ տեղում են ստուգել։

Մենք սխալ տեղում ենք ստուգել, ​​քանի որ չենք ունեցել արտադրական կլոն, որը հեշտ է ստուգել։ Մշակողը կարող է ընդհանրապես մուտք չունենալ արտադրությանը:

Եվ մենք ստուգեցինք ոչ այնտեղ: Եթե ​​այնտեղ ստուգեինք, ինքներս կտեսնեինք։ Մշակողը տեսավ այդ ամենը նույնիսկ առանց DBA-ի, եթե նա ստուգեր այն լավ միջավայրում, որտեղ կան նույն քանակությամբ տվյալներ և նույնական դիրք: Նա կտեսներ այս ամբողջ դեգրադացիան ու կամաչեր։

Ավելին ավտովակուումի մասին: Այն բանից հետո, երբ մենք կատարել ենք մի քանի միլիոն տողերի զանգվածային մաքրում, մենք դեռ պետք է անենք REPACK: Սա հատկապես կարևոր է ինդեքսների համար։ Այն բանից հետո, երբ այնտեղ ամեն ինչ մաքրենք, նրանք իրենց վատ կզգան։

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

Այն, ինչ մենք անում ենք, բաց կոդով է: Այն տեղադրված է GitLab-ում: Եվ մենք այնպես ենք անում, որ մարդիկ կարողանան ստուգել նույնիսկ առանց DBA-ի: Մենք տվյալների բազայի լաբորատորիա ենք անում, այսինքն՝ կանչում ենք այն բազային բաղադրիչը, որի վրա Ջոն ներկայումս աշխատում է։ Եվ դուք կարող եք վերցնել արտադրության պատճենը: Այժմ կա Joe-ի ներդրում անգործության համար, կարող եք այնտեղ ասել. «բացատրեք այսինչ խնդրանքը» և անմիջապես ստացեք արդյունքը տվյալների բազայի ձեր պատճենի համար: Այնտեղ կարող ես նույնիսկ ՋՆՋԵԼ, և ոչ ոք դա չի նկատի։

Ենթադրենք, դուք ունեք 10 տերաբայթ, մենք տվյալների բազայի լաբորատորիա ենք պատրաստում նաև 10 տերաբայթ: Իսկ միաժամանակ 10 տերաբայթանոց տվյալների բազաների դեպքում 10 ծրագրավորողներ կարող են միաժամանակ աշխատել: Յուրաքանչյուրը կարող է անել այն, ինչ ուզում է։ Կարող է ջնջել, թողնել և այլն: Դա նման ֆանտազիա է: Այս մասին կխոսենք վաղը։

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

Օրինակ՝ 5 տերաբայթ տվյալների բազա, պատճենի ստացում 30 վայրկյանից պակաս ժամանակում: Եվ դա նույնիսկ կախված չէ չափից, այսինքն, կարեւոր չէ, թե քանի տերաբայթ:

Այսօր դուք կարող եք գնալ postgres.ai և փորեք մեր գործիքները: Կարող եք գրանցվել՝ տեսնելու, թե ինչ կա այնտեղ։ Դուք կարող եք տեղադրել այս բոտը: Դա անվճար է. Գրել.

Հարցեր

Շատ հաճախ իրական իրավիճակներում պարզվում է, որ այն տվյալները, որոնք պետք է մնան աղյուսակում, շատ ավելի քիչ են, քան այն, ինչ պետք է ջնջվի։ Այսինքն, նման իրավիճակում հաճախ ավելի հեշտ է իրականացնել նման մոտեցում, երբ ավելի հեշտ է ստեղծել նոր օբյեկտ, այնտեղ պատճենել միայն անհրաժեշտ տվյալները և բեռնել հին աղյուսակը: Հասկանալի է, որ այս պահի համար ծրագրային մոտեցում է պետք, մինչդեռ դուք փոխարկվելու եք։ Ինչպե՞ս է այս մոտեցումը:

Սա շատ լավ մոտեցում է և շատ լավ առաջադրանք։ Այն շատ նման է նրան, ինչ անում է pg_repack, շատ նման է նրան, ինչ դուք պետք է անեք, երբ ID-ները դարձնում եք 4 բայթ: Շատ շրջանակներ դա արել են մի քանի տարի առաջ, և պարզապես թիթեղները մեծացել են, և դրանք պետք է վերածվեն 8 բայթի:

Այս խնդիրը բավականին բարդ է։ Մենք արեցինք դա. Եվ դուք պետք է շատ զգույշ լինեք: Կան կողպեքներ և այլն։ Բայց դա արվում է։ Այսինքն, ստանդարտ մոտեցումը pg_repack-ի հետ գնալն է: Դուք նման պիտակ եք հայտարարում։ Եվ մինչ կսկսեք դրա մեջ ներբեռնել նկարի տվյալները, դուք նաև հայտարարում եք մեկ ափսե, որը հետևում է բոլոր փոփոխություններին: Կա մի հնարք, որ դուք կարող եք նույնիսկ չհետևել որոշ փոփոխություններին։ Կան նրբություններ. Եվ հետո դուք փոխում եք փոփոխվող փոփոխությունները: Մի փոքր դադար կլինի, երբ բոլորին փակենք, բայց ընդհանուր առմամբ դա արվում է։

Եթե ​​նայեք pg_repack-ին GitHub-ում, ապա այնտեղ, երբ առաջադրանք կար ID-ն int 4-ից int 8-ի փոխակերպելու, ապա գաղափար կար՝ օգտագործել հենց pg_repack: Սա նույնպես հնարավոր է, բայց դա մի քիչ հափշտակություն է, բայց սա նույնպես կաշխատի: Դուք կարող եք միջամտել այն ձգանին, որն օգտագործում է pg_repack և այնտեղ ասել. «Մեզ այս տվյալները պետք չեն», այսինքն՝ մենք փոխանցում ենք միայն այն, ինչ մեզ անհրաժեշտ է։ Եվ հետո նա պարզապես փոխվում է, և վերջ:

Այս մոտեցմամբ մենք դեռ ստանում ենք աղյուսակի երկրորդ օրինակը, որում տվյալները արդեն ինդեքսավորվում են և շատ հավասարապես դրված են գեղեցիկ ինդեքսներով:

Բլոտը չկա, լավ մոտեցում է։ Բայց ես գիտեմ, որ փորձեր կան դրա համար ավտոմատացում մշակելու, այսինքն՝ համընդհանուր լուծում տալու համար։ Ես կարող եմ ձեզ կապ հաստատել այս ավտոմատացման հետ: Այն գրված է Python-ով, ինչը լավ բան է:

Ես պարզապես մի փոքր հեռու եմ MySQL աշխարհից, ուստի եկել եմ լսելու: Եվ մենք օգտագործում ենք այս մոտեցումը.

Բայց դա միայն այն դեպքում, եթե մենք ունենանք 90%: Եթե ​​ունենք 5 տոկոս, ապա դրանից օգտվելն այնքան էլ լավ չէ։

Շնորհակալություն զեկույցի համար: Եթե ​​չկան ռեսուրսներ արդյունահանման ամբողջական պատճենը պատրաստելու համար, կա՞ արդյոք որևէ ալգորիթմ կամ բանաձև՝ բեռը կամ չափը հաշվարկելու համար:

Լավ հարց է. Առայժմ մենք կարողանում ենք գտնել բազմաբայթանոց տվյալների բազաներ։ Նույնիսկ եթե այնտեղ սարքավորումը նույնը չէ, օրինակ՝ ավելի քիչ հիշողություն, ավելի քիչ պրոցեսոր և սկավառակներ, բայց մենք դա անում ենք։ Եթե ​​բացարձակապես ոչ մի տեղ չկա, ապա պետք է մտածել։ Մինչեւ վաղը մտածեմ, եկել ես, կխոսենք, լավ հարց է։

Շնորհակալություն զեկույցի համար: Դուք սկզբում սկսեցիք այն մասին, որ կա մի թույն Postgres, որն ունի այսինչ սահմանափակումներ, բայց այն զարգանում է։ Եվ այս ամենը մեծ հաշվով հենակ է։ Արդյո՞ք այս ամենը չի հակասում հենց «Պոստգրես»-ի զարգացմանը, որում կհայտնվի ինչ-որ DELETE deferent, կամ ինչ-որ այլ բան, որը պետք է ցածր մակարդակի վրա պահի այն, ինչ մենք փորձում ենք արատավորել այստեղ մեր որոշ տարօրինակ միջոցներով:

Եթե ​​մենք SQL-ում ասել ենք՝ ջնջել կամ թարմացնել բազմաթիվ գրառումներ մեկ գործարքում, ապա ինչպե՞ս կարող է Postgres-ը դա տարածել այնտեղ։ Մենք ֆիզիկապես սահմանափակ ենք գործառնություններում։ Մենք դեռ երկար ենք անելու։ Եվ մենք այս պահին կկողպենք և այլն:

Կատարված է ինդեքսներով:

Ես կարող եմ ենթադրել, որ նույն անցակետի թյունինգը կարող է ավտոմատացված լինել: Մի օր դա կարող է լինել: Բայց հետո ես իսկապես չեմ հասկանում հարցը.

Հարց է՝ կա՞ զարգացման այնպիսի վեկտոր, որ այս ու այն կողմ գնում է, իսկ այստեղ՝ ձերը զուգահեռ։ Նրանք. Դեռ չե՞ն մտածել այդ մասին։

Ես խոսեցի այն սկզբունքների մասին, որոնք կարելի է կիրառել հիմա։ Կա ևս մեկ բոտ Nancy, սրանով դուք կարող եք ավտոմատացված անցակետի թյունինգ անել։ Արդյո՞ք այն մի օր կլինի Պոստգրեսում: Չգիտեմ, դա դեռ չի էլ քննարկվել։ Մենք դեռ հեռու ենք դրանից։ Բայց կան գիտնականներ, որոնք նոր համակարգեր են ստեղծում։ Եվ նրանք մեզ խցկեցին ավտոմատ ինդեքսների մեջ: Զարգացումներ կան. Օրինակ, դուք կարող եք դիտել ավտոմատ թյունինգը: Այն ավտոմատ կերպով ընտրում է պարամետրերը: Բայց նա դեռ չի անի ձեզ համար անցակետային թյունինգ։ Այսինքն, այն կվերցնի կատարման համար, shell buffer և այլն:

Իսկ անցակետի թյունինգի համար կարող եք դա անել. եթե ունեք հազար կլաստերներ և տարբեր սարքավորումներ, տարբեր վիրտուալ մեքենաներ ամպի մեջ, կարող եք օգտագործել մեր բոտը: Nancy կատարել ավտոմատացում. Եվ max_wal_size-ը կընտրվի ըստ ձեր թիրախային պարամետրերի ավտոմատ կերպով: Բայց մինչ այժմ դա նույնիսկ մոտ չէ առանցքում, ցավոք սրտի:

Բարի օր Դուք խոսեցիք երկարատև գործարքների վտանգների մասին։ Ասացիք, որ ջնջումների դեպքում ավտովակուումն արգելափակվում է։ Էլ ինչպե՞ս է դա մեզ վնասում։ Քանի որ մենք ավելի շատ խոսում ենք տարածք ազատելու և այն օգտագործելու մասին: Էլ ի՞նչ ենք մեզ պակասում։

Autovacuum-ը գուցե ամենամեծ խնդիրը չէ այստեղ: Իսկ այն, որ երկար գործարքը կարող է արգելափակել այլ գործարքներ, այս հնարավորությունն ավելի վտանգավոր է։ Նա կարող է հանդիպել կամ չհանդիպել: Եթե ​​նա հանդիպեց, ապա դա կարող է շատ վատ լինել: Իսկ ավտովակուումի դեպքում սա նույնպես խնդիր է: OLTP-ում երկար գործարքների հետ կապված երկու խնդիր կա՝ կողպեքներ և ավտովակուում: Եվ եթե կրկնօրինակի վրա միացված եք տաք սպասման հետադարձ կապը, ապա դուք դեռ կստանաք ավտովակուումային կողպեք վարպետի վրա, այն կժամանի կրկնօրինակից: Բայց գոնե կողպեքներ չեն լինի։ Եվ լոկերներ կլինեն: Մենք խոսում ենք տվյալների փոփոխությունների մասին, ուստի կողպեքներն այստեղ կարևոր կետ են: Եվ եթե այս ամենը երկար, երկար ժամանակ է, ապա ավելի ու ավելի շատ գործարքներ են արգելափակվում: Նրանք կարող են գողանալ ուրիշներին: Եվ հայտնվում են լոկ ծառեր: Ես տրամադրեցի հատվածի հղումը: Եվ այս խնդիրն ավելի արագ է դառնում նկատելի, քան ավտովակուումի խնդիրը, որը կարող է միայն կուտակվել։

Շնորհակալություն զեկույցի համար: Դուք սկսեցիք ձեր զեկույցը ասելով, որ սխալ եք փորձարկել: Մենք շարունակեցինք մեր միտքը, որ պետք է վերցնել նույն տեխնիկան, բազայի հետ նույն ձևով։ Ենթադրենք, մենք ծրագրավորողին հիմք ենք տվել։ Եվ նա կատարեց խնդրանքը։ Եվ նա կարծես լավ է: Բայց նա ուղիղ եթերում չի ստուգում, այլ ուղիղ եթերի համար, օրինակ, 60-70% բեռ ունենք։ Եվ նույնիսկ եթե մենք օգտագործում ենք այս թյունինգը, այն այնքան էլ լավ չի աշխատում:

Թիմում փորձագետ ունենալը և DBA փորձագետների օգտագործումը, ովքեր կարող են կանխատեսել, թե ինչ կլինի իրական ֆոնային բեռի դեպքում, կարևոր է: Երբ մենք պարզապես քշեցինք մեր մաքուր փոփոխությունները, մենք տեսնում ենք նկարը: Բայց ավելի առաջադեմ մոտեցում, երբ մենք նորից նույն բանն արեցինք, բայց արտադրության հետ նմանակված բեռով: Դա բավականին թույն է: Մինչ այդ դուք պետք է մեծանաք։ Դա նման է մեծահասակի: Մենք պարզապես նայեցինք, թե ինչ ունենք և նաև նայեցինք, թե արդյոք ունենք բավարար ռեսուրսներ: Դա լավ հարց է:

Երբ մենք արդեն անում ենք աղբի ընտրություն և ունենք, օրինակ, ջնջված դրոշակ

Ահա թե ինչ է անում autovacuum-ը ավտոմատ կերպով Postgres-ում:

Օ, նա դա անում է:

Autovacuum-ը աղբահան է:

Thank you!

Շնորհակալություն զեկույցի համար: Կա՞ տարբերակ անմիջապես ձևավորել տվյալների բազա՝ բաժանումով այնպես, որ ամբողջ աղբը կեղտոտվի հիմնական սեղանից ինչ-որ մի կողմ:

Իհարկե ունեն:

Այդ դեպքում հնարավո՞ր է պաշտպանվել մեզ, եթե մենք կողպել ենք սեղան, որը չպետք է օգտագործվի:

Իհարկե ունեն: Բայց դա նման է հավի ու ձվի հարցի: Եթե ​​բոլորս իմանանք, թե ինչ է լինելու ապագայում, ապա, իհարկե, ամեն ինչ թույն կանենք։ Բայց բիզնեսը փոխվում է, կան նոր սյունակներ, նոր խնդրանքներ։ Եվ հետո – օպ, մենք ուզում ենք հեռացնել այն: Բայց այս իդեալական իրավիճակը կյանքում լինում է, բայց ոչ միշտ։ Բայց ընդհանուր առմամբ դա լավ գաղափար է: Պարզապես կտրեք և վերջ:

Source: www.habr.com