Հեռավոր ապագայում անհարկի տվյալների ավտոմատ ջնջումը կլինի DBMS-ի կարևոր խնդիրներից մեկը [1]: Միևնույն ժամանակ, մենք ինքներս պետք է հոգ տանենք անհարկի տվյալների ջնջման կամ տեղափոխման մասին ավելի քիչ թանկ պահեստավորման համակարգեր: Ենթադրենք, դուք որոշել եք ջնջել մի քանի միլիոն տող: Բավականին պարզ խնդիր է, հատկապես, եթե պայմանը հայտնի է, և կա համապատասխան ցուցանիշ։ «DELETE FROM table1 WHERE col1 = :value» - ինչ կարող է լինել ավելի պարզ, չէ՞:
Video:
«Հայլոդ» ծրագրի հանձնաժողովում եմ առաջին տարվանից, այսինքն՝ 2007 թվականից։
Եվ ես Postgres-ում եմ 2005 թվականից: Օգտագործել եմ այն բազմաթիվ նախագծերում:
RuPostges-ի հետ խումբը նույնպես գործում է 2007 թվականից:
Meetup-ում մենք աճել ենք մինչև 2100+ մասնակից: Այն աշխարհում երկրորդն է Նյու Յորքից հետո՝ վաղուց շրջանցելով Սան Ֆրանցիսկոյից։
Ես մի քանի տարի է, ինչ ապրում եմ Կալիֆորնիայում։ Ավելի շատ աշխատում եմ ամերիկյան, այդ թվում՝ խոշոր ընկերությունների հետ։ Նրանք Postgres-ի ակտիվ օգտատերեր են: Եվ այնտեղ տեղի են ունենում ամենատարբեր հետաքրքիր բաներ:
-Սա իմ ընկերությունն է։ Մենք զբաղվում ենք այն առաջադրանքների ավտոմատացման բիզնեսով, որոնք վերացնում են զարգացման դանդաղումները:
Եթե ինչ-որ բան եք անում, երբեմն Փոստգրեսի շուրջը բախվում եք որոշ խոչընդոտների: Ենթադրենք, դուք պետք է սպասեք, մինչև ադմինիստրատորը կստեղծի ձեզ համար թեստային ստենդ, կամ դուք պետք է սպասեք մինչև DBA-ն պատասխանի ձեզ: Եվ նման խոչընդոտներ մենք գտնում ենք մշակման, փորձարկման և կառավարման գործընթացում և փորձում վերացնել դրանք ավտոմատացման և նոր մոտեցումների միջոցով։
Վերջերս Լոս Անջելեսի VLDB-ում էի: Սա տվյալների բազայի ամենամեծ կոնֆերանսն է: Եվ եղավ հաղորդում, որ ապագայում DBMS-ները ոչ միայն կպահպանեն, այլեւ ավտոմատ կերպով կջնջեն տվյալները։ Սա նոր թեմա է։
Աշխարհում ավելի ու ավելի շատ տվյալներ կան՝ զետաբայթերը 1 000 000 փետաբայթ են։ Եվ հիմա հաշվարկվում է, որ մենք ունենք ավելի քան 100 զետաբայթ տվյալների պահպանում աշխարհում։ Եվ դրանք ավելի ու ավելի շատ են:
Իսկ ի՞նչ անել դրա դեմ։ Պարզ է, որ այն պետք է ջնջվի։ Ահա այս հետաքրքիր զեկույցի հղումը: Բայց դա դեռ չի իրականացվում DBMS-ում:
Նրանք, ովքեր գիտեն փող հաշվել, երկու բան են ուզում. Նրանք ուզում են, որ մենք ջնջենք, ուստի տեխնիկապես մենք պետք է կարողանանք դա անել:
Այն, ինչ ես ձեզ հաջորդիվ կասեմ, ինչ-որ վերացական իրավիճակ է, որն իր մեջ ներառում է մի շարք իրական իրավիճակներ, այսինքն՝ ինձ և շրջակա տվյալների բազաների հետ իրականում տեղի ունեցածի մի քանի անգամ, շատ տարիներ: Rake-ն ամենուր է, և բոլորը անընդհատ քայլում են դրա վրա:
Ասենք՝ ունենք բազա կամ մի քանի բազա, որոնք աճում են։ Իսկ որոշ գրառումներ ուղղակի աղբ են։ Օրինակ, օգտատերը սկսեց այնտեղ ինչ-որ բան անել և չավարտեց այն: Եվ որոշ ժամանակ անց մենք գիտենք, որ այս անավարտ գործն այլևս չի կարող պահվել։ Այսինքն՝ մենք ցանկանում ենք մաքրել որոշ անպետք իրեր՝ տարածք խնայելու, կատարողականությունը բարելավելու և այլն:
Ընդհանուր առմամբ, խնդիրն այն է, որ ավտոմատացնել որոշակի աղյուսակի կոնկրետ բաների, կոնկրետ տողերի ջնջումը:
Եվ մենք ունենք նման խնդրանք, որի մասին կխոսենք այսօր, այսինքն՝ աղբահանության մասին։
Մենք խնդրեցինք փորձառու ծրագրավորողին դա անել: Նա վերցրեց այս խնդրանքը, ստուգեց այն իր համար. ամեն ինչ աշխատում է: Փորձարկվել է բեմադրության վրա՝ ամեն ինչ լավ է: Մենք գլորեցինք այն, և ամեն ինչ աշխատում է: Մենք այն գործարկում ենք օրը մեկ անգամ՝ ամեն ինչ լավ է:
Տվյալների բազան աճում և աճում է: Daily DELETE-ը սկսում է աշխատել մի փոքր ավելի դանդաղ:
Այնուհետև մենք հասկանում ենք, որ մենք այժմ իրականացնում ենք մարքեթինգային արշավ, և թրաֆիկը մի քանի անգամ ավելի մեծ կլինի, ուստի մենք որոշում ենք ժամանակավորապես դադարեցնել լրացուցիչ բաները: Եվ մենք մոռանում ենք վերադարձնել այն:
Մի քանի ամիս անց նրանք հիշեցին. Եվ այդ ծրագրավորողը թողեց կամ այլ բանով էր զբաղված, և նրանք հանձնարարեցին մեկ ուրիշին վերադարձնել այն:
Նա ստուգել է մշակումը, բեմադրությունը. ամեն ինչ կարգին է: Բնականաբար, դեռ պետք է մաքրել կուտակվածը։ Նա ստուգեց, ամեն ինչ աշխատում է։
Ի՞նչ կլինի հետո։ Հետո մեզ մոտ ամեն ինչ քանդվում է։ Այն ընկնում է, որ ինչ-որ պահի մեզ մոտ ամեն ինչ փլվի։ Բոլորը շոկի մեջ են, ոչ ոք չի հասկանում, թե ինչ է կատարվում։ Եվ հետո պարզվում է, որ խնդիրը այս ՋՆՋԵԼՆ էր։
Ի՞նչը սխալվեց: Ահա այն բաների ցանկը, որոնք կարող են սխալ լինել: Ո՞րն է սրա ամենակարևորը:
Օրինակ՝ վերանայում չի եղել, այսինքն՝ DBA փորձագետը չի նայել։ Անմիջապես խնդիրը կգտներ իր փորձառու աչքով, բացի այդ, նրան հասանելի է արդյունահանումը, որտեղ մի քանի միլիոն տող է կուտակվել։
Միգուցե ինչ-որ կերպ սխալ են ստուգել։
Հնարավոր է, որ սարքաշարը հնացած է, և այս տվյալների բազայի համար անհրաժեշտ է թարմացում:
Կամ ինչ-որ բան այն չէ հենց տվյալների բազայում, և մենք պետք է Postgres-ից տեղափոխվենք MySQL:
Կամ գուցե ինչ-որ բան այն չէ վիրահատության հետ:
Գուցե աշխատանքի կազմակերպման հարցում ինչ-որ սխալներ կան, և ինչ-որ մեկին պետք է ազատել աշխատանքից և ավելի լավ մարդկանց աշխատանքի ընդունել:
DBA ստուգում չի եղել: Եթե լիներ DBA, նա կտեսներ այս մի քանի միլիոն տողերը և, նույնիսկ առանց որևէ փորձի, կասեր. «Այդպես չի արվում»: Ենթադրենք, եթե այս կոդը լիներ GitLab-ում, GitHub-ում, և կոդի վերանայման գործընթաց լիներ, և այնպես չէր, որ այս գործողությունը կարտադրվեր առանց DBA-ի հաստատման, ապա ակնհայտորեն DBA-ն կասեր. «Դուք չեք կարող դա անել»:
Եվ նա կասեր, որ դուք խնդիրներ կունենաք սկավառակի IO-ի հետ, և բոլոր պրոցեսները կխենթանան, կարող են կողպեքներ լինել, ինչպես նաև դուք շատ րոպեներով արգելափակեք ավտովակուումը, այնպես որ սա լավ չէ:
Երկրորդ սխալն այն է, որ սխալ տեղում են ստուգել։ Մենք տեսանք այն բանից հետո, որ շատ աղբի տվյալներ էին կուտակվել արդյունահանման վրա, բայց մշակողը չուներ որևէ կուտակված տվյալ այս տվյալների բազայում, և ոչ ոք իրականում այս աղբը չստեղծեց բեմադրության վրա: Ըստ այդմ՝ եղել է 1 տող, որոնք արագ մշակվել են։
Մենք հասկանում ենք, որ մեր թեստերը թույլ են, այսինքն՝ կառուցված գործընթացը խնդիրներ չի առաջացնում։ Նրանք համարժեք BD փորձ չեն անցկացրել:
Իդեալական փորձը նախընտրելի է իրականացնել նույն սարքավորման վրա։ Միշտ չէ, որ դա հնարավոր է անել նույն սարքավորման վրա, բայց շատ կարևոր է, որ այն լինի տվյալների բազայի ամբողջական չափի պատճենը: Սա այն է, ինչ ես քարոզում եմ արդեն մի քանի տարի։ Եվ մեկ տարի առաջ ես խոսեցի այս մասին, դուք կարող եք դիտել այդ ամենը 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-ը:
Եվ դրանից հետո մենք նորից սկսում ենք այն և տեսնում ենք, թե որքան ժամանակ կպահանջվի այս սարքավորման վրա բարձրանալու համար, այսինքն՝ որքան REDO այն կանի այս վատ իրավիճակում:
Կրկնակի կստուգեմ, որ վիճակը վատ է. Նախ, մենք ընկանք անցակետի ավարտից անմիջապես առաջ, ուստի կորցնելու շատ բան ունենք։ Եվ երկրորդը՝ մենք զանգվածային վիրահատություն ենք տարել։ Եվ եթե անցակետերի ժամանակն ավարտվեր, ապա, ամենայն հավանականությամբ, ավելի քիչ WAL կստեղծվեր վերջին անցակետից հետո: Այսինքն՝ կրկնակի պարտվող է։
Մենք չափում ենք այս իրավիճակը տարբեր չափերի max_wal_size-ի համար և հասկանում ենք, որ եթե max_wal_size-ը 64 գիգաբայթ է, ապա կրկնակի վատթարագույն իրավիճակում մենք կբարձրանանք 10 րոպեում: Եվ մենք մտածում ենք՝ գոհ ենք սրանից, թե ոչ։ Սա բիզնեսի հարց է: Այս պատկերը պետք է ցույց տանք նրանց, ովքեր պատասխանատու են բիզնեսի որոշումների համար և հարցնենք. «Ինչքա՞ն կարող ենք սպասել առավելագույնը, եթե խնդիր կա, կարո՞ղ ենք ամենավատ իրավիճակում 3-5 րոպե պառկել, իսկ դուք որոշում կայացնեք։
Եվ ահա մի հետաքրքիր կետ. Մեր կոնֆերանսում Պատրոնի մասին մի քանի զեկուցումներ ունենք: Եվ գուցե դուք օգտագործում եք այն: Սա Autofailover է 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 րոպե, և ամեն ինչ կհաստատվի: Բայց, ցավոք, նույնիսկ փորձառու մշակողները սխալներ են թույլ տալիս, նույնիսկ շատ խոշոր ընկերություններում:
Ինչու՞ է կարևոր քանդվելը:
Եթե տեսնենք, որ սկավառակը դժվարանում է, ապա դանդաղեցնենք այն։ Եվ եթե մենք ունենք խափանում, ապա մենք կարող ենք ավելացնել դադարներ, կարող ենք դանդաղեցնել շնչափողը:
Իսկ ուրիշներին երկար չենք արգելափակի։ Որոշ դեպքերում դա նշանակություն չունի, եթե դուք ջնջում եք իրական աղբը, որի վրա ոչ ոք չի աշխատում, ապա դուք հավանաբար չեք արգելափակի որևէ մեկին, բացի autovacuum-ից, քանի որ այն կսպասի գործարքի ավարտին: Բայց եթե ջնջեք ինչ-որ բան, որը դեռևս կարող է պահանջել մեկ ուրիշը, նա կարգելափակվի, և ինչ-որ շղթայական ռեակցիա կսկսվի: Կայքերում և բջջային հավելվածներում պետք է խուսափել երկարատև գործարքներից:
Սա հետաքրքիր է։ Ես հաճախ տեսնում եմ, որ մշակողները հարցնում են. «Ի՞նչ փաթեթի չափս պետք է ընտրեմ»:
Հասկանալի է, որ որքան մեծ է խմբաքանակի չափը, այնքան ավելի ցածր է գործարքի գլխավճարը, այսինքն՝ գործարքներից լրացուցիչ ծախսերը: Բայց միևնույն ժամանակ մեծանում է այս գործարքի ժամանակը։
Ես ունեմ մի շատ պարզ կանոն. վերցրեք այնքան, որքան կարող եք, բայց մի գերազանցեք կատարումը մեկ վայրկյանում:
Ինչու՞ մի վայրկյան: Բացատրությունը շատ պարզ է ու հասկանալի բոլորին, նույնիսկ ոչ տեխնիկական մարդկանց։ Մենք տեսնում ենք արձագանքը. Վերցնենք 50 միլիվայրկյան: Եթե ինչ-որ բան փոխվել է, մեր աչքերը կարձագանքեն։ Եթե դա ավելի քիչ է, ապա ավելի դժվար է: Եթե ինչ-որ բան արձագանքում է 100 միլիվայրկյան հետո, օրինակ, դուք սեղմել եք մկնիկի վրա, և այն պատասխանել է ձեզ 100 միլիվայրկյան անց, դուք արդեն զգում եք այս փոքր ուշացումը: Երկրորդն արդեն ընկալվում է որպես արգելակ։
Համապատասխանաբար, եթե մենք բաժանենք մեր զանգվածային գործողությունները 10 վայրկյանանոց պոռթկումների, ապա մենք կանգնած ենք ինչ-որ մեկին արգելափակելու ռիսկի տակ: Եվ դա կաշխատի մի քանի վայրկյան, և մարդիկ կնկատեն: Դրա համար ես նախընտրում եմ մեկ վայրկյանից ավելի չանել։ Բայց միևնույն ժամանակ, մի՛ քանդեք այն շատ մանրակրկիտ, քանի որ գործարքի գումարը նկատելի կլինի։ Հենակետն ավելի դժվար ժամանակ կունենա, և այլ տարբեր խնդիրներ կարող են առաջանալ:
Մենք ընտրում ենք փաթեթի չափը: Յուրաքանչյուր դեպքում մենք կարող ենք դա անել տարբեր կերպ: Այն կարող է ավտոմատացված լինել: Եվ մենք համոզված ենք մեկ փաթեթի մշակման արդյունավետության մեջ։ Այսինքն՝ մենք ջնջում ենք մեկ խմբաքանակը կամ ԹԱՐՄԱՑՆՈՒՄ:
Ի դեպ, այն ամենը, ինչի մասին ես խոսում եմ, միայն ՋՆՋԵԼՈՒ մասին չէ։ Ինչպես կարող էիք կռահել, սրանք տվյալների վրա կատարված ցանկացած զանգվածային գործողություններ են:
Եվ մենք տեսնում ենք, որ ծրագիրը գերազանց է։ Դուք կարող եք տեսնել ինդեքսի սկանավորում, նույնիսկ ավելի լավ՝ միայն սկանավորում: Եվ մենք ունենք փոքր քանակությամբ տվյալներ: Եվ ամեն ինչ աշխատում է մեկ վայրկյանից էլ քիչ ժամանակում: Սուպեր.
Եվ մենք դեռ պետք է այնպես անենք, որ դեգրադացիա չլինի։ Դա տեղի է ունենում, որ առաջին փաթեթները արագորեն աշխատում են, իսկ հետո այն դառնում է ավելի ու ավելի ու ավելի վատ: Գործընթացն այնպիսին է, որ շատ թեստավորում է պահանջվում: Սա հենց այն է, ինչի համար են տվյալների բազայի լաբորատորիաները:
Եվ մենք դեռ պետք է ինչ-որ բան պատրաստենք, որպեսզի դա մեզ թույլ տա պատշաճ կերպով վերահսկել դա արտադրության մեջ։ Օրինակ՝ մենք կարող ենք մատյանում գրել ժամը, կարող ենք գրել, թե որտեղ ենք հիմա և ում ենք հենց նոր ջնջել։ Եվ դա թույլ կտա մեզ հետագայում հասկանալ, թե ինչ է կատարվում։ Եվ եթե ինչ-որ բան սխալ է, արագ գտեք խնդիրը:
Եթե մենք պետք է ստուգենք հարցումների արդյունավետությունը, և մենք պետք է բազմիցս կրկնենք, ապա կա ընկեր բոտ: Այն արդեն պատրաստ է։ Այն ամեն օր օգտագործվում է տասնյակ մշակողների կողմից: Եվ այն կարող է տրամադրել հսկայական տերաբայթ տվյալների բազա՝ ըստ պահանջի 30 վայրկյանում՝ ձեր սեփական պատճենը: Եվ դուք կարող եք այնտեղ ինչ-որ բան ջնջել և ասել RESET, և նորից ջնջել այն: Դուք կարող եք փորձարկել դրա հետ այս կերպ. Ես այս բանի մեջ ապագա եմ տեսնում։ Եվ մենք արդեն սա անում ենք։
Որո՞նք են բաժանման ռազմավարությունները: Ես տեսնում եմ 3 տարբեր բաժանման ռազմավարություններ, որոնք օգտագործվում են մշակողների կողմից փաթեթում:
Առաջինը շատ պարզ է. Մենք ունենք թվային ID: Եվ եկեք այն բաժանենք տարբեր ինտերվալների և աշխատենք դրա հետ: Բացասական կողմը պարզ է. Առաջին հատվածում կարող ենք ունենալ 100 տող իրական աղբ, երկրորդում՝ 5 տող կամ ընդհանրապես ոչ մի տող, կամ բոլոր 1 տողերը աղբ դուրս գան։ Շատ անհավասար աշխատանք, բայց հեշտ է բաժանվել: Մենք վերցրեցինք առավելագույն ID-ն և բաժանեցինք այն: Սա միամիտ մոտեցում է։
Երկրորդ ռազմավարությունը հավասարակշռված մոտեցում է: Այն օգտագործվում է Gitlab-ում։ Մենք վերցրեցինք և սկանավորեցինք սեղանը: Մենք գտանք ID-ների փաթեթների սահմաններն այնպես, որ յուրաքանչյուր տուփ պարունակում էր ուղիղ 10 գրառում: Եվ նրանք ինձ հրեցին ինչ-որ հերթի մեջ։ Եվ մենք շարունակում ենք մշակումը։ Դա կարելի է անել մի քանի թելերով:
Առաջին ռազմավարության մեջ, ի դեպ, դուք կարող եք դա անել նաև մի քանի թելերով։ Դժվար չէ։
Բայց կա ավելի սառը և օպտիմալ մոտեցում: Սա երրորդ ռազմավարությունն է։ Եվ երբ հնարավոր է, ավելի լավ է ընտրել այն: Մենք դա անում ենք հատուկ ինդեքսի հիման վրա: Այս դեպքում, ամենայն հավանականությամբ, դա կլինի ինդեքս՝ ըստ մեր աղբի վիճակի և ID-ի։ Մենք կներառենք ID-ն, որպեսզի դա լինի միայն ինդեքսի սկանավորում, որպեսզի չգնանք կույտին:
Ընդհանրապես, միայն ինդեքսների սկանավորումն ավելի արագ է, քան ինդեքսի սկանավորումը:
Եվ մենք արագ գտնում ենք մեր ID-ները, որոնք ցանկանում ենք ջնջել: Մենք նախապես ընտրում ենք BATCH_SIZE: Եվ մենք դրանք ոչ միայն ստանում ենք, այլ հատուկ ձևով ենք ընդունում և անմիջապես կողպում։ Բայց այնպես ենք կողպում, որ եթե արդեն կողպված են, ոչ թե կողպենք, այլ անցնենք ու վերցնենք հաջորդները։ Սա թարմացման համար է, որ բաց թողնելն արգելափակված է: Postgres-ի այս սուպեր հատկությունը մեզ թույլ է տալիս աշխատել մի քանի թելերով, եթե ցանկանում ենք: Հնարավոր է մեկ հոսքով։ Եվ այստեղ կա CTE – սա մեկ հարցում է: Եվ մենք իրական հեռացում ունենք այս CTE-ի երկրորդ հարկում. returning *. ID-ն վերադարձնելը հնարավոր է, բայց ավելի լավ է *, եթե յուրաքանչյուր տողում քիչ տվյալներ ունեք:
Ինչո՞ւ է մեզ սա պետք: Մեզ սա պետք է զեկուցելու համար։ Մենք հիմա իրականում այդքան տողեր ենք ջնջել։ Եվ մենք սահմաններ ունենք ID-ով կամ ստեղծված_at-ով այսպես: Դուք կարող եք կատարել min, max. Ուրիշ բան էլ կա, որ կարելի է անել։ Այստեղ դուք կարող եք շատ իրեր տեղավորել: Եվ սա շատ հարմար է մոնիտորինգի համար։
Ցուցանիշի հետ կապված ևս մեկ դիտողություն կա. Եթե մենք որոշենք, որ մեզ անհրաժեշտ է հատուկ ինդեքս այս կոնկրետ առաջադրանքի համար, մենք պետք է համոզվենք, որ այն չի փչացնի միայն բազմակի թարմացումները: Այսինքն՝ Պոստգրեսը նման վիճակագրություն ունի։ Սա կարող եք տեսնել pg_stat_user_tables-ում ձեր աղյուսակում: Դուք կարող եք տեսնել, թե արդյոք տաք թարմացումները օգտագործվում են, թե ոչ:
Կան իրավիճակներ, երբ ձեր նոր ցուցանիշը կարող է պարզապես կտրել դրանք: Եվ ձեր մյուս բոլոր թարմացումները, որոնք արդեն աշխատում են, կդանդաղեն: Ոչ միայն այն պատճառով, որ ինդեքսը հայտնվել է (յուրաքանչյուր ինդեքս մի փոքր դանդաղեցնում է թարմացումները, բայց մի փոքր), բայց այստեղ այն նաև կփչացնի: Իսկ այս աղյուսակի համար հատուկ օպտիմալացում անել հնարավոր չէ։ Սա երբեմն պատահում է: Սա այնպիսի նրբություն է, որ քչերն են հիշում։ Եվ այս փոցխի վրա ոտք դնելը հեշտ է: Երբեմն պատահում է, որ պետք է մոտեցում գտնել այլ տեսանկյունից և դեռ անել առանց այս նոր ինդեքսի, կամ կազմել այլ ինդեքս, կամ ինչ-որ կերպ, օրինակ, կարող ես օգտագործել երկրորդ մեթոդը:
Բայց սա ամենաօպտիմալ ռազմավարությունն է՝ ինչպես բաժանվել խմբաքանակների ու մեկ խնդրանքով կրակել տուփերի վրա, քիչ-քիչ ջնջել և այլն։
Երկար գործարքներ -
Արգելափակված ավտովակուում —
Արգելափակման խնդիր —
Թիվ 5 սխալը մեծ է: Օկմետրից Նիկոլայը խոսեց Postgres մոնիտորինգի մասին. Ցավոք, չկա իդեալական Postgres մոնիտորինգ: Ոմանք ավելի մոտ են, ոմանք ավելի հեռու: Okmeter-ը բավականին մոտ է կատարյալ լինելուն, բայց շատ բաներ բացակայում են, որոնք պետք է ավելացնել: Դուք պետք է պատրաստ լինեք դրան:
Օրինակ, ավելի լավ է վերահսկել մեռած tuples. Եթե ձեր սեղանում շատ մեռած իրեր ունեք, ապա ինչ-որ բան այն չէ: Ավելի լավ է հիմա արձագանքենք, այլապես կարող է դեգրադացիա լինել և իջնել: Սա տեղի է ունենում.
Եթե կա մեծ IO, ապա պարզ է, որ սա լավ չէ:
Երկար գործարքներ նույնպես: Երկարատև գործարքները չպետք է թույլատրվեն OLTP-ով: Եվ ահա մի հատվածի հղում, որը թույլ է տալիս վերցնել այս հատվածը և կատարել երկարատև գործարքների հետագծում:
Ինչու են երկար գործարքները վատ: Քանի որ բոլոր կողպեքները կազատվեն միայն վերջում: Եվ մենք բոլորին փակում ենք: Բացի այդ, մենք արգելափակում ենք ավտովակուումը բոլոր սեղանների համար: Սա ամենևին էլ լավ չէ։ Նույնիսկ եթե կրկնօրինակի վրա միացված է տաք սպասման ռեժիմը, դա դեռ վատ է: Ընդհանրապես, ավելի լավ է ոչ մի տեղ թույլ չտալ երկարատև գործարքներ։
Եթե մենք ունենք բազմաթիվ աղյուսակներ, որոնք վակուումացված չեն, ապա մենք պետք է ահազանգ ունենանք: Սա հենց այն իրավիճակն է, որը հնարավոր է այստեղ։ Մենք կարող ենք անուղղակիորեն ազդել ավտովակուումի աշխատանքի վրա։ Սա մի հատված է Avito-ից, որը ես մի փոքր բարելավեցի: Եվ պարզվեց, որ դա հետաքրքիր գործիք է, որպեսզի տեսնենք, թե ինչ ունենք ավտովակուումով: Օրինակ, նրանք սպասում են որոշ սեղանների և չեն կարող սպասել իրենց հերթին: Այն նաև պետք է մոնիտորինգի ենթարկվի և ունենա ահազանգ:
Եվ թողարկում է բլոկներ: Արգելափակման ծառերի անտառ. Ես սիրում եմ ինչ-որ մեկից ինչ-որ բան վերցնել և բարելավել այն: Այստեղ Data Egret-ից ես վերցրեցի մի հիանալի ռեկուրսիվ CTE, որը ցույց է տալիս կողպեքի ծառերի անտառը: Սա լավ բան է ախտորոշման համար: Եվ դրա հիման վրա կարելի է կառուցել նաև մոնիտորինգ։ Բայց դա պետք է արվի ուշադիր: Դուք պետք է ձեր statement_timeout-ը փոքր դարձնեք: Իսկ lock_timeout-ը ցանկալի է։
Երբեմն այս բոլոր սխալները տեղի են ունենում միասին:
Իմ կարծիքով այստեղ ամենամեծ սխալը կազմակերպչական է։ Դա կազմակերպչական է, քանի որ տեխնոլոգիան չի համապատասխանում առաջադրանքին: Սա թիվ 2-ն է՝ սխալ տեղում են ստուգել։
Մենք այնտեղ չստուգեցինք, քանի որ չունեինք արտադրական կլոն, որպեսզի հեշտությամբ ստուգենք: Մշակողը կարող է ընդհանրապես մուտք չունենալ արտադրությանը:
Եվ մենք սխալ տեղում ստուգեցինք: Եթե այնտեղ ստուգեին, մենք ինքներս դա կտեսնեինք։ Մշակողը կարող էր տեսնել այս ամենը նույնիսկ առանց DBA-ի, եթե նա ստուգեր այն լավ միջավայրում, որտեղ կան նույն քանակությամբ տվյալներ և նույն դիրքը: Նա կտեսներ այս ամբողջ դեգրադացիան ու ամաչում էր։
Ավելին ավտովակուումի մասին: Մի քանի միլիոն տողերի զանգվածային մաքրում կատարելուց հետո մենք դեռ պետք է REPACK անենք: Սա հատկապես կարևոր է ինդեքսների համար։ Նրանք դժվարության մեջ կլինեն այն բանից հետո, երբ մենք այնտեղ ամեն ինչ մաքրենք:
Իսկ եթե ցանկանում եք հետ բերել ամենօրյա մաքրման աշխատանքները, ապա կառաջարկեի դա անել ավելի հաճախ, բայց ավելի փոքր կտորներով։ Դուք կարող եք դա անել րոպեն մեկ անգամ կամ նույնիսկ ավելի հաճախ, ընդամենը մի քիչ: Եվ մենք պետք է երկու բանի մոնիտորինգ սահմանենք՝ որ այս բանը սխալներ չունենա և հետ չմնա։ Այն հնարքը, որը ես ցույց տվեցի ձեզ, կլուծի սա:
Այն, ինչ մենք անում ենք, բաց կոդով է: Սա տեղադրված է GitLab-ում: Եվ մենք այնպես ենք անում, որ մարդիկ կարողանան ստուգել նույնիսկ առանց DBA-ի: Մենք պատրաստում ենք տվյալների բազայի լաբորատորիա, այսինքն՝ այն, ինչ մենք անվանում ենք հիմնական բաղադրիչ, որի վրա Ջոն այժմ աշխատում է: Եվ դուք կարող եք վերցնել արտադրության պատճենը: Այժմ կա Joe-ի ներդրում Slack-ի համար, որտեղ կարող եք ասել՝ «բացատրեք այսինչ հարցումը» և անմիջապես ստացեք արդյունքը տվյալների բազայի ձեր պատճենի համար: Այնտեղ կարող եք նույնիսկ DELETE անել, և ոչ ոք չի նկատի:
Ենթադրենք, դուք ունեք 10 տերաբայթ, մենք ստեղծում ենք տվյալների բազայի լաբորատորիա նաև 10 տերաբայթ: Իսկ 10 ծրագրավորողներ կարող են միաժամանակ աշխատել 10 տերաբայթանոց տվյալների բազաների հետ։ Յուրաքանչյուրը կարող է անել այն, ինչ ուզում է։ Այն կարող է ջնջել, թողնել և այլն: Ահա թե որքան ֆանտաստիկ է: Այս մասին կխոսենք վաղը։
Սա կոչվում է բարակ մատակարարում: Սա նուրբ ապահովում է: Սա ինչ-որ ֆանտազիա է, որը մեծապես նվազեցնում է զարգացման, թեստավորման ձգձգումները և աշխարհն ավելի լավ տեղ է դարձնում այս առումով: Այսինքն, դա թույլ է տալիս խուսափել զանգվածային գործողությունների հետ կապված խնդիրներից:
Օրինակ՝ 5 տերաբայթ տվյալների բազա, պատճենեք 30 վայրկյանից պակաս ժամանակում: Եվ դա նույնիսկ կախված չէ չափից, այսինքն, կարևոր չէ, թե քանի տերաբայթ:
Այսօր արդեն կարող եք այցելել և փորեք մեր գործիքները: Կարող եք գրանցվել և տեսնել, թե ինչ կա այնտեղ: Դուք կարող եք տեղադրել այս բոտը ձեզ համար: Դա անվճար է: Գրել.
Հարցեր
Շատ հաճախ իրական իրավիճակներում պարզվում է, որ այն տվյալները, որոնք պետք է մնան աղյուսակում, շատ ավելի քիչ են, քան այն, ինչ պետք է ջնջվի։ Այսինքն, նման իրավիճակում հաճախ ավելի հեշտ է իրականացնել նման մոտեցում, երբ ավելի պարզ է ստեղծել նոր օբյեկտ, այնտեղ պատճենել միայն անհրաժեշտ տվյալները և բեռնել հին աղյուսակը: Հասկանալի է, որ այս պահի համար անհրաժեշտ է ծրագրային մոտեցում, երբ դուք անցում եք կատարում: Ի՞նչ կասեք այս մոտեցման մասին:
Սա շատ լավ մոտեցում է և շատ լավ առաջադրանք։ Այն շատ նման է նրան, ինչ անում է pg_repack, շատ նման է նրան, ինչ դուք պետք է անեք, երբ ID-ները դարձնում եք 4 բայթ: Շատ շրջանակներ դա արեցին մի քանի տարի առաջ, և հենց որ աղյուսակները մեծացան, դրանք պետք է փոխարկվեին 8 բայթի:
Այս խնդիրը բավականին բարդ է։ Մենք դա արեցինք։ Եվ դուք պետք է շատ զգույշ լինեք: Կան կողպեքներ և այլն: Բայց դա արվում է։ Այսինքն՝ ստանդարտ մոտեցումը նման է pg_repack-ին։ Դուք նման նշան եք հայտարարում. Եվ մինչ դուք կսկսեք ներբեռնել տվյալները դրա վրա՝ օգտագործելով snapshot, դուք նաև հայտարարում եք մեկ աղյուսակ, որը հետևում է բոլոր փոփոխություններին: Այնտեղ կա մի հնարք, որ դուք կարող եք նույնիսկ չհետևել որոշ փոփոխություններին: Կան նրբություններ. Եվ այնուհետև դուք միանում եք՝ փոփոխելով փոփոխությունները: Կլինի կարճ դադար, մինչ մենք փակում ենք բոլորին, բայց ընդհանուր առմամբ դա արվում է:
Եթե նայեք pg_repack-ին GitHub-ում, ապա երբ առաջադրանք կար ID-ն int 4-ից int 8-ի փոխակերպելու, գաղափար կար՝ օգտագործել հենց pg_repack: Սա նույնպես հնարավոր է, բայց դա մի քիչ հաքերային մեթոդ է, բայց դա նույնպես կաշխատի սրա համար: Դուք կարող եք միջամտել այն ձգանին, որն օգտագործում է pg_repack և այնտեղ ասել. «Մեզ այս տվյալները պետք չեն», այսինքն՝ մենք փոխանցում ենք միայն այն, ինչ մեզ անհրաժեշտ է։ Եվ հետո նա պարզապես կանցնի, և վերջ:
Այս մոտեցմամբ մենք նաև ստանում ենք աղյուսակի երկրորդ օրինակը, որում տվյալները արդեն ինդեքսավորված են և շատ հավասարաչափ դրված են գեղեցիկ ինդեքսներով։
Ոչ, դա լավ մոտեցում է: Բայց ես գիտեմ, որ դրա համար ավտոմատացում մշակելու փորձեր կան, այսինքն՝ համընդհանուր լուծում տալու համար։ Ես կարող եմ ձեզ կապ հաստատել այս ավտոմատացման հետ: Գրված է Python-ով, լավ բան է:
Ես պարզապես մի փոքր հեռու եմ MySQL աշխարհից, ուստի եկա լսելու: Եվ մենք օգտագործում ենք այս մոտեցումը.
Բայց դա աշխատում է միայն այն դեպքում, եթե մենք ունենք 90%: Եթե ունենք 5 տոկոս, ապա դրանից օգտվելն այնքան էլ լավ չէ։
Շնորհակալություն զեկույցի համար: Եթե չկան ռեսուրսներ՝ ամբողջական պատճենահանման համար, կա՞ արդյոք որևէ ալգորիթմ կամ բանաձև՝ բեռը կամ չափը հաշվարկելու համար:
Լավ հարց. Մինչ այժմ մեզ հաջողվել է գտնել բազմաբայթանոց տվյալների բազաներ։ Նույնիսկ եթե այնտեղ սարքաշարը նույնը չէ, օրինակ՝ ավելի քիչ հիշողություն, ավելի քիչ պրոցեսոր և սկավառակները նույնը չեն, բայց մենք դեռ անում ենք դա։ Եթե բացարձակապես ոչ մի տեղ չկա, ապա դուք պետք է մտածեք դրա մասին: Մինչեւ վաղը մտածեմ, եկել ես, կխոսենք, լավ հարց է։
Շնորհակալություն զեկույցի համար: Սկզբում սկսեցիր խոսել այն մասին, թե ինչպես կա մի թույն Postgres, որն ունի այսինչ սահմանափակումներ, բայց այն զարգանում է։ Բայց այս ամենը մեծ հաշվով հենակ է։ Արդյո՞ք այս ամենը չի հակասում հենց «Պոստգրես»-ի զարգացմանը, որում կհայտնվի ինչ-որ ջնջել դիֆերենտ կամ այլ բան, որը ցածր մակարդակով պետք է աջակցի այն, ինչ մենք այստեղ փորձում ենք կոծկել մեր որոշ տարօրինակ միջոցներով:
Եթե մենք ասել ենք SQL-ին ջնջել կամ թարմացնել բազմաթիվ գրառումներ մեկ գործարքում, ինչպե՞ս կարող է Postgres-ը տարածել այն: Մենք ֆիզիկապես սահմանափակ ենք գործառնություններում։ Մենք դեռ երկար ժամանակ դա կանենք: Եվ մենք այս պահին կկողպենք և այլն:
Դա արել են ցուցանիշներով։
Ես կարող եմ ենթադրել, որ նույն անցակետի թյունինգը կարող է ավտոմատացված լինել: Մի օր, հավանաբար, դա տեղի կունենա։ Բայց հետո ես իսկապես չեմ հասկանում հարցը.
Հարցն այն է, որ այնտեղ զարգացման վեկտոր չկա՞, և այստեղ ձերը զուգահեռ է ընթանում։ Նրանք. Դեռ չե՞ն մտածել այդ մասին։
Ես խոսեցի այն սկզբունքների մասին, որոնք կարելի է կիրառել հիմա։ Կա ևս մեկ բոտ , դրանով դուք կարող եք կատարել ավտոմատացված անցակետի թյունինգ։ Սա երբևէ կլինի՞ Պոստգրեսում: Չգիտեմ, դա դեռ չի էլ քննարկվում։ Մենք դեռ հեռու ենք սրանից։ Բայց կան գիտնականներ, որոնք նոր համակարգեր են ստեղծում։ Եվ մեզ մղում են դեպի ավտոմատ ինդեքսներ։ Զարգացումներ կան. Օրինակ, դուք կարող եք դիտել ավտոմատ թյունինգը: Այն ավտոմատ կերպով ընտրում է պարամետրերը: Բայց նա դեռ չի անի ձեզ համար անցակետային թյունինգ: Այսինքն, այն կընտրի կատարման համար, shell buffer և այլն:
Իսկ անցակետի թյունինգի համար կարող եք դա անել. եթե ունեք հազար կլաստերներ և տարբեր սարքավորումներ, տարբեր վիրտուալ մեքենաներ ամպի մեջ, կարող եք օգտագործել մեր բոտը: կատարել ավտոմատացում. Եվ max_wal_size-ը կընտրվի ավտոմատ կերպով՝ ըստ ձեր թիրախային կարգավորումների: Բայց, ցավոք սրտի, սա դեռ մոտ չէ միջուկում լինելուն:
Բարի օր Դուք խոսեցիք երկար գործարքների վնասի մասին: Ասացիք, որ ջնջումների դեպքում ավտովակուումն արգելափակվում է։ Ուրիշ ինչպե՞ս է սա մեզ վնասում: Քանի որ մենք ավելի շատ խոսում ենք տարածք ազատելու և այն օգտագործելու մասին: Էլ ի՞նչ ենք կորցնում։
Autovacuum – սա կարող է լինել ամենամեծ խնդիրը այստեղ: Իսկ այն, որ երկար գործարքը կարող է արգելափակել այլ գործարքներ, ավելի վտանգավոր հնարավորություն է։ Նա կարող է հանդիպել կամ չհանդիպել: Եթե նա հանդիպեր, ապա ամեն ինչ կարող էր շատ վատ լինել: Իսկ ավտովակուումի դեպքում սա նույնպես խնդիր է: OLTP-ում երկար գործարքների հետ կապված երկու խնդիր կա՝ կողպեքներ և ավտովակուում: Եվ եթե դուք ունեք տաք սպասման հետադարձ կապ միացված կրկնօրինակի վրա, ապա դուք նաև կստանաք ավտովակուումային կողպեք վարպետի վրա, այն կգա կրկնօրինակից: Բայց գոնե այնտեղ կողպեքներ չեն լինի։ Եվ այստեղ կլինեն կողպեքներ: Մենք խոսում ենք տվյալների փոփոխությունների մասին, ուստի կողպեքներն այստեղ կարևոր կետ են: Եվ եթե դա երկար շարունակվի, ապա ավելի ու ավելի շատ գործարքներ են արգելափակվում: Նրանք կարող են արգելափակել ուրիշներին: Եվ հայտնվում են կողպեքի ծառերը: Ես տրամադրեցի հատվածի հղումը: Եվ այս խնդիրն ավելի արագ է դառնում նկատելի, քան ավտովակուումի խնդիրը, որը կարող է միայն կուտակվել։
Շնորհակալություն զեկույցի համար: Դուք սկսեցիք ձեր զեկույցը ասելով, որ սխալ եք փորձարկել: Մենք շարունակեցինք մեր միտքը, որ պետք է վերցնել նույն տեխնիկան, նույն բազայով։ Ենթադրենք, մենք ծրագրավորողին հիմք ենք տվել։ Եվ նա կատարեց խնդրանքը. Եվ թվում է, թե նրա հետ ամեն ինչ լավ է։ Բայց նա ուղիղ եթերում չի ստուգում, իսկ ուղիղ եթերում, օրինակ, մենք ունենք 60-70% բեռ: Եվ նույնիսկ եթե մենք օգտագործում ենք այս թյունինգը, այն այնքան էլ լավ չի ստացվում
Ձեր թիմում փորձագետ ունենալը և DBA փորձագետների օգտագործումը, ովքեր կարող են կանխատեսումներ անել, թե ինչ կլինի իրական ֆոնային ծանրաբեռնվածության ներքո, կարևոր է: Երբ մենք պարզապես կատարում ենք մեր մաքուր փոփոխությունները, մենք տեսնում ենք նկար: Բայց ավելի առաջադեմ մոտեցում, երբ մենք նորից նույն բանն արեցինք, բայց արտադրությունից մոդելավորված բեռով: Սա բացարձակապես հիասքանչ է: Դուք դեռ պետք է մեծանաք դրան: Սա չափահաս է: Մենք զուտ նայեցինք այն, ինչ հասանելի էր, և նաև նայեցինք՝ արդյոք ունենք բավարար ռեսուրսներ: Սա լավ հարց է:
Երբ մենք արդեն անում ենք աղբի ընտրություն և ունենք, օրինակ, ջնջված դրոշակ
Ահա թե ինչ է անում autovacuum-ը ավտոմատ կերպով Postgres-ում:
Օ, նա անում է?
Autovacuum-ը աղբահան է:
Thank you!
Շնորհակալություն զեկույցի համար: Կա՞ տարբերակ անմիջապես նախագծել տվյալների բազա՝ բաժանման միջոցով, որպեսզի ամբողջ աղբը հիմնական սեղանից բաժանվի ինչ-որ մի կողմ:
Իհարկե ունեն:
Հնարավո՞ր է արդյոք պաշտպանվել մեզ, եթե մենք փակել ենք սեղան, որը չպետք է օգտագործվի:
Իհարկե կա։ Բայց սա հավի ու ձվի հարց է: Եթե բոլորս իմանանք, թե ինչ է լինելու ապագայում, ապա, իհարկե, ամեն ինչ հիանալի կանենք։ Բայց բիզնեսը փոխվում է, նոր սյունակներ և նոր հարցումներ են հայտնվում: Եվ հետո - օպ, մենք ուզում ենք ջնջել այն: Բայց սա իդեալական իրավիճակ է, կյանքում դա լինում է, բայց ոչ միշտ։ Բայց ընդհանուր առմամբ դա լավ գաղափար է: Պարզապես կտրեք և վերջ:
Source: www.habr.com
