DBA բոտ Ջո. Անատոլի Ստանսլեր (Postgres.ai)

Ինչպե՞ս է հետին պլանի մշակողը հասկանում, որ SQL հարցումը լավ կաշխատի «prod»-ի վրա: Խոշոր կամ արագ աճող ընկերություններում ոչ բոլորին է հասանելի «ապրանքը»: Եվ մուտքի դեպքում ոչ բոլոր հարցումները կարող են առանց ցավի ստուգվել, և տվյալների բազայի պատճեն ստեղծելը հաճախ ժամեր է պահանջում: Այս խնդիրները լուծելու համար մենք ստեղծեցինք արհեստական ​​DBA՝ Ջո: Այն արդեն հաջողությամբ ներդրվել է մի քանի ընկերություններում և օգնում է ավելի քան մեկ տասնյակ մշակողների:

Video:

Բարեւ բոլորին! Ես Անատոլի Ստանսլերն եմ։ Ես աշխատում եմ ընկերությունում postgres.ai. Մենք պարտավորվում ենք արագացնել զարգացման գործընթացը՝ հեռացնելով Postgres-ի աշխատանքի հետ կապված ձգձգումները ծրագրավորողներից, DBA-ներից և QA-ներից:

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

Երբ մենք զարգացնում և կատարում ենք բարդ ծանրաբեռնված միգրացիաներ, մենք ինքներս մեզ հարց ենք տալիս. Մենք օգտագործում ենք վերանայում, օգտագործում ենք ավելի փորձառու գործընկերների, DBA փորձագետների գիտելիքները: Եվ նրանք կարող են ասել՝ կթռչի, թե ոչ։

Բայց, երևի թե, ավելի լավ կլիներ, եթե մենք ինքներս փորձարկեինք այն լրիվ չափի պատճենների վրա: Իսկ այսօր մենք պարզապես կխոսենք այն մասին, թե հիմա ինչ մոտեցումներ կան թեստավորման նկատմամբ և ինչպես կարելի է դա ավելի լավ անել և ինչ գործիքներով։ Մենք կխոսենք նաև նման մոտեցումների դրական և բացասական կողմերի մասին, ինչպես նաև այն մասին, թե ինչ կարող ենք ուղղել այստեղ։

Ո՞վ է երբևէ կազմել ինդեքսներ անմիջապես արդյունահանման վրա կամ որևէ փոփոխություն կատարել: Բավականին մի քիչ: Իսկ ո՞ւմ համար դա բերեց նրան, որ տվյալները կորել են կամ եղել են պարապուրդներ: Այդ դեպքում դուք գիտեք այս ցավը: Փառք Աստծո, որ պահեստայիններ կան:

Առաջին մոտեցումը փորձարկումն է արդ. Կամ, երբ ծրագրավորողը նստում է տեղական մեքենայի վրա, նա ունի թեստային տվյալներ, ինչ-որ սահմանափակ ընտրություն կա: Եվ մենք դուրս ենք գալիս արդյունահանման, և մենք ստանում ենք այս իրավիճակը:

Դա ցավում է, դա թանկ է: Հավանաբար, ավելի լավ է չանել:

Իսկ ո՞րն է դա անելու լավագույն միջոցը:

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

Սա մեզ թույլ կտա հեռացնել որոշ սխալներ, այսինքն՝ կանխել դրանք արդ.

Ի՞նչ խնդիրներ կան։

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

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

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

Ի՞նչն է մեզ խանգարում յուրաքանչյուր ծրագրավորողին տալ փորձնական նստարան, լրիվ չափի պատճեն: Կարծում եմ՝ պարզ է, թե ինչն է խանգարում:

Ո՞վ ունի տերաբայթից ավելի տվյալների բազա: Սենյակի կեսից ավելին.

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

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

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

Բայց նրանք օգտագործում են այս մոտեցումը, քանի որ դա նրանց թույլ է տալիս հուսալի պահել արտադրանքը:

Ի՞նչ կարող ենք անել այստեղ: Եկեք փորձարկման նստարանները դարձնենք էժան և յուրաքանչյուր մշակողի տանք իր փորձարկման նստարանը:

Եվ սա հնարավոր է։

Եվ այս մոտեցմամբ, երբ մենք բարակ կլոններ ենք պատրաստում յուրաքանչյուր մշակողի համար, մենք կարող ենք այն կիսել մեկ մեքենայի վրա: Օրինակ, եթե դուք ունեք 10TB տվյալների բազա և ցանկանում եք այն տալ 10 մշակողների, ապա ձեզ հարկավոր չէ ունենալ XNUMX x XNUMXTB տվյալների բազա: Ձեզ անհրաժեշտ է միայն մեկ մեքենա՝ մեկ մեքենայի միջոցով յուրաքանչյուր մշակողի համար բարակ մեկուսացված պատճեններ պատրաստելու համար: Ես ձեզ կասեմ, թե ինչպես է այն աշխատում մի փոքր ուշ:

Իրական օրինակ.

• DB - 4,5 տերաբայթ:

• Մենք կարող ենք անկախ պատճեններ ստանալ 30 վայրկյանում:

Պետք չէ սպասել փորձարկման կրպակի և կախված լինել նրանից, թե որքան է այն: Դուք կարող եք այն ստանալ վայրկյանների ընթացքում: Դա կլինի ամբողջովին մեկուսացված միջավայրեր, որոնք, սակայն, կիսում են տվյալները միմյանց միջև:

Սա շատ լավ է. Այստեղ խոսքը մոգության և զուգահեռ տիեզերքի մասին է։

Մեր դեպքում սա աշխատում է OpenZFS համակարգի միջոցով:

OpenZFS-ը պատճենահանման վրա գրելու ֆայլային համակարգ է, որն աջակցում է ակնոցներ և կլոնավորումներ տուփից դուրս: Այն հուսալի է և մասշտաբային: Նրան շատ հեշտ է կառավարել: Այն կարող է բառացիորեն տեղակայվել երկու թիմերում:

Կան այլ տարբերակներ.

• lvm,

• Պահպանում (օրինակ, մաքուր պահեստավորում):

Տվյալների բազայի լաբորատորիան, որի մասին ես խոսում եմ, մոդուլային է: Կարող է իրականացվել այս ընտրանքների միջոցով: Բայց առայժմ մենք կենտրոնացել ենք OpenZFS-ի վրա, քանի որ կոնկրետ LVM-ի հետ կապված խնդիրներ կային։

Ինչպես է դա աշխատում? Տվյալները ամեն անգամ փոխելիս վերագրանցելու փոխարեն, մենք դրանք պահպանում ենք՝ պարզապես նշելով, որ այս նոր տվյալները ժամանակի նոր կետից են, նոր լուսանկար:

Եվ ապագայում, երբ մենք ուզում ենք հետադարձ կատարել կամ ցանկանում ենք նոր կլոն ստեղծել ավելի հին տարբերակից, մենք պարզապես ասում ենք.

Եվ այս օգտվողը կաշխատի նման տվյալների հավաքածուով: Նա կամաց-կամաց կփոխի դրանք, կկազմի իր ակնթարթները։

Եվ մենք ճյուղավորվելու ենք: Մեր դեպքում յուրաքանչյուր ծրագրավորող հնարավորություն կունենա ունենալ իր խմբագրած կլոնը, և այն տվյալները, որոնք կիսվում են, կտարածվեն բոլորի միջև:

Նման համակարգը տանը տեղակայելու համար հարկավոր է լուծել երկու խնդիր.

• Առաջինը տվյալների աղբյուրն է, որտեղից կվերցնեք դրանք։ Դուք կարող եք կրկնօրինակել արտադրության հետ: Դուք արդեն կարող եք օգտագործել ձեր կազմաձևած կրկնօրինակները, հուսով եմ: WAL-E, WAL-G կամ Barman: Եվ նույնիսկ եթե դուք օգտագործում եք ինչ-որ Cloud լուծում, ինչպիսիք են RDS կամ Cloud SQL, ապա կարող եք օգտագործել տրամաբանական աղբարկղեր: Բայց մենք դեռ խորհուրդ ենք տալիս օգտագործել կրկնօրինակներ, քանի որ այս մոտեցմամբ դուք նաև կպահպանեք ֆայլերի ֆիզիկական կառուցվածքը, ինչը թույլ կտա ձեզ ավելի մոտ լինել այն չափորոշիչներին, որոնք դուք կտեսնեիք արտադրության մեջ, որպեսզի բռնեք առկա խնդիրները:

• Երկրորդն այն է, որտեղ դուք ցանկանում եք հյուրընկալել տվյալների բազայի լաբորատորիան: Դա կարող է լինել Cloud, դա կարող է լինել On-premise: Այստեղ կարևոր է ասել, որ ZFS-ն աջակցում է տվյալների սեղմմանը: Եվ դա բավականին լավ է անում:

Պատկերացրեք, որ յուրաքանչյուր նման կլոնի համար, կախված այն գործողություններից, որոնք մենք կատարում ենք բազայի հետ, կաճի ինչ-որ մշակույթ: Դրա համար dev-ին նույնպես տարածք է պետք: Բայց քանի որ մենք վերցրել ենք 4,5 տերաբայթ բազա, ZFS-ն այն կսեղմի մինչև 3,5 տերաբայթ: Սա կարող է տարբեր լինել՝ կախված կարգավորումներից: Եվ մենք դեռ տեղ ունենք մշակի համար:

Նման համակարգը կարող է օգտագործվել տարբեր դեպքերի համար:

• Սրանք մշակողներ են, DBA-ներ հարցումների վավերացման, օպտիմալացման համար:

• Սա կարող է օգտագործվել ՈԱ թեստավորման ժամանակ՝ փորձարկելու որոշակի միգրացիա՝ նախքան այն արտադրելու համար: Եվ մենք կարող ենք նաև ստեղծել հատուկ միջավայրեր QA-ի համար իրական տվյալներով, որտեղ նրանք կարող են փորձարկել նոր գործառույթներ: Եվ սպասելու ժամերի փոխարեն վայրկյաններ կպահանջվեն, իսկ որոշ այլ դեպքերում, երբ բարակ օրինակները չեն օգտագործվում, գուցե օրեր:

• Եվ ևս մեկ դեպք. Եթե ​​ընկերությունը չունի հիմնված վերլուծական համակարգ, ապա մենք կարող ենք մեկուսացնել արտադրանքի բազայի բարակ կլոնը և տալ այն երկար հարցումների կամ հատուկ ինդեքսների, որոնք կարող են օգտագործվել վերլուծության մեջ:

Այս մոտեցմամբ.

1. Ցածր հավանականությունը սխալների վրա «prod», քանի որ մենք փորձարկել ենք բոլոր փոփոխությունները լրիվ չափի տվյալների վրա:

2. Մենք ունենք թեստավորման մշակույթ, քանի որ այժմ պետք չէ ժամերով սպասել սեփական ստենդին:

3. Եվ չկա խոչընդոտ, չկա սպասել թեստերի միջև: Դուք կարող եք իրականում գնալ և ստուգել: Եվ այսպես ավելի լավ կլինի, քանի որ մենք արագացնենք զարգացումը:

• Ավելի քիչ կվերագործարկվեն. Ավելի քիչ սխալներ կհայտնվեն արդ. Ավելի ուշ դրանք ավելի քիչ կվերափոխենք:

• Մենք կարող ենք հակադարձել անշրջելի փոփոխությունները։ Սա ստանդարտ մոտեցում չէ:

1. Սա ձեռնտու է, քանի որ մենք կիսում ենք փորձարկման նստարանների ռեսուրսները:

Արդեն լավ է, բայց էլ ի՞նչ կարելի է արագացնել:

Նման համակարգի շնորհիվ մենք կարող ենք մեծապես նվազեցնել նման թեստավորման անցնելու շեմը։

Հիմա կա մի արատավոր շրջան, երբ ծրագրավորողը իրական լիարժեք տվյալների հասանելիություն ստանալու համար պետք է դառնա փորձագետ։ Նրան պետք է վստահել այդպիսի մուտքը։

Բայց ինչպես աճել, եթե այն չկա: Բայց ինչ անել, եթե դուք ունեք թեստային տվյալների միայն շատ փոքր հավաքածու: Այդ դեպքում դուք իրական փորձ չեք ստանա:

Ինչպե՞ս դուրս գալ այս շրջանակից: Որպես առաջին ինտերֆեյս, հարմար ցանկացած մակարդակի մշակողների համար, մենք ընտրեցինք Slack բոտը։ Բայց դա կարող է լինել ցանկացած այլ ինտերֆեյս:

Ի՞նչ է դա ձեզ թույլ տալիս: Դուք կարող եք վերցնել կոնկրետ հարցում և ուղարկել այն տվյալների բազայի հատուկ ալիք: Մենք ավտոմատ կերպով կտեղակայենք բարակ կլոն վայրկյանների ընթացքում: Եկեք գործարկենք այս հարցումը: Մենք հավաքում ենք չափումներ և առաջարկություններ: Եկեք ցույց տանք պատկերացում: Եվ հետո այս կլոնը կմնա այնպես, որ այս հարցումը հնարավոր լինի ինչ-որ կերպ օպտիմալացնել, ավելացնել ինդեքսներ և այլն:

Եվ նաև Slack-ը մեզ հնարավորություն է ընձեռում համագործակցության համար: Քանի որ սա պարզապես ալիք է, դուք կարող եք սկսել քննարկել այս հարցումը հենց այնտեղ՝ նման խնդրանքի համար, ձեր գործընկերներին, DBA-ներին, որոնք գտնվում են ընկերության ներսում:

Բայց խնդիրներ, իհարկե, կան։ Քանի որ սա իրական աշխարհն է, և մենք միաժամանակ օգտագործում ենք բազմաթիվ կլոններ հյուրընկալող սերվեր, մենք պետք է սեղմենք կլոններին հասանելի հիշողության և պրոցեսորի հզորությունը:

Բայց որպեսզի այս թեստերը հավաստի լինեն, դուք պետք է ինչ-որ կերպ լուծեք այս խնդիրը:

Հասկանալի է, որ կարևոր կետը նույն տվյալն է։ Բայց մենք արդեն ունենք: Եվ մենք ցանկանում ենք հասնել նույն կոնֆիգուրացիան: Եվ մենք կարող ենք նման գրեթե նույնական կոնֆիգուրացիա տալ։

Հաճելի կլիներ ունենալ նույն սարքաշարը, ինչ արտադրության մեջ, բայց այն կարող է տարբերվել:

Հիշենք, թե ինչպես է Postgres-ը աշխատում հիշողության հետ: Մենք ունենք երկու պահոց: Մեկը ֆայլային համակարգից և մեկ բնիկ Postgres, այսինքն՝ Համօգտագործվող բուֆերային քեշ:

Կարևոր է նշել, որ Համօգտագործվող բուֆերային քեշը հատկացվում է, երբ Postgres-ը սկսվում է, կախված այն բանից, թե ինչ չափս եք նշում կազմաձևում:

Իսկ երկրորդ քեշը օգտագործում է ողջ հասանելի տարածքը:

Իսկ երբ մի մեքենայի վրա մի քանի կլոն ենք պատրաստում, ստացվում է, որ կամաց-կամաց լրացնում ենք հիշողությունը։ Եվ լավ իմաստով, Համօգտագործվող բուֆերային քեշը կազմում է մեքենայի վրա հասանելի հիշողության ընդհանուր քանակի 25%-ը:

Եվ ստացվում է, որ եթե չփոխենք այս պարամետրը, ապա մեկ մեքենայի վրա կկարողանանք գործարկել ընդամենը 4 օրինակ, այսինքն՝ ընդհանուր առմամբ այս բարակ կլոններից 4-ը։ Եվ սա, իհարկե, վատ է, քանի որ մենք ցանկանում ենք նրանցից շատ ավելին ունենալ։

Բայց մյուս կողմից, Buffer Cache-ն օգտագործվում է ինդեքսների հարցումներ կատարելու համար, այսինքն՝ պլանը կախված է նրանից, թե որքան մեծ են մեր քեշերը։ Եվ եթե մենք պարզապես վերցնենք այս պարամետրը և նվազեցնենք այն, ապա մեր ծրագրերը կարող են շատ բան փոխվել:

Օրինակ, եթե մենք ունենք մեծ քեշ prod-ում, ապա Postgres-ը կնախընտրի օգտագործել ինդեքս: Իսկ եթե ոչ, ապա կլինի SeqScan: Իսկ ի՞նչ իմաստ կունենար, եթե մեր ծրագրերը չհամընկնեին։

Բայց այստեղ մենք գալիս ենք այն եզրակացության, որ իրականում Postgres-ի պլանը կախված չէ պլանի Shared Buffer-ում նշված կոնկրետ չափից, այն կախված է effect_cache_size-ից:

Effective_cache_size-ը մեզ հասանելի քեշի գնահատված քանակն է, այսինքն՝ բուֆերային քեշի և ֆայլային համակարգի քեշի գումարը: Սա սահմանված է կազմաձևով: Եվ այս հիշողությունը չի հատկացվում։

Եվ այս պարամետրի շնորհիվ մենք կարող ենք մի տեսակ խաբել Postgres-ին՝ ասելով, որ մենք իրականում ունենք շատ հասանելի տվյալներ, նույնիսկ եթե չունենք այս տվյալները: Եվ այսպիսով, պլանները լիովին կհամընկնեն արտադրության հետ։

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

• Դա կախված է այն բեռից, որը ներկայումս գտնվում է արդ.

• Դա կախված է ինքնին մեքենայի բնութագրերից:

Եվ սա անուղղակի պարամետր է, բայց իրականում մենք կարող ենք օպտիմիզացնել հենց տվյալների քանակով, որը կկարդա այս հարցումը՝ արդյունք ստանալու համար:

Եվ եթե ցանկանում եք, որ ժամանակը մոտ լինի նրան, ինչ մենք կտեսնենք արդյունահանման մեջ, ապա մենք պետք է վերցնենք ամենանման սարքավորումները և, հնարավոր է, նույնիսկ ավելին, որպեսզի բոլոր կլոնները տեղավորվեն: Բայց սա փոխզիջում է, այսինքն՝ դուք կստանաք նույն պլանները, կտեսնեք, թե կոնկրետ հարցումը որքան տվյալներ կկարդա և կկարողանաք եզրակացնել՝ այս հարցումը լավն է (կամ միգրացիան), թե վատ, այն դեռ պետք է օպտիմալացվի։ .

Եկեք նայենք, թե ինչպես է Joe-ն հատուկ օպտիմիզացված:

Վերցնենք հարցում իրական համակարգից։ Այս դեպքում տվյալների բազան 1 տերաբայթ է: Եվ մենք ուզում ենք հաշվել թարմ գրառումների քանակը, որոնք 10-ից ավելի հավանումներ են ունեցել։

Մենք հաղորդագրություն ենք գրում ալիքին, մեզ համար կլոն է տեղադրվել։ Եվ մենք կտեսնենք, որ նման հարցումը կավարտվի 2,5 րոպեում։ Սա առաջին բանն է, որ մենք նկատում ենք։

B Joe-ն ձեզ ցույց կտա ավտոմատ առաջարկներ՝ հիմնված պլանի և չափումների վրա:

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

Եկեք մանրամասն նայենք տեղի ունեցածին: Իսկապես, մենք տեսնում ենք, որ մենք կարդացել ենք գրեթե մեկուկես գիգաբայթ տվյալներ ֆայլի քեշից կամ նույնիսկ սկավառակից: Եվ սա լավ չէ, քանի որ մենք ստացել ենք ընդամենը 142 տող:

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

Եվ դա տեղի ունեցավ պլանում, քանի որ հարցման պայմանները և ինդեքսի պայմանները մասամբ չեն համընկնում:

Փորձենք ավելի ճշգրիտ դարձնել ինդեքսը և տեսնել, թե դրանից հետո ինչպես է փոխվում հարցման կատարումը։

Ինդեքսի ստեղծումը բավականին երկար տևեց, բայց հիմա մենք ստուգում ենք հարցումը և տեսնում ենք, որ ժամանակը 2,5 րոպեի փոխարեն ընդամենը 156 միլիվայրկյան է, ինչը բավական լավ է։ Իսկ մենք կարդում ենք ընդամենը 6 մեգաբայթ տվյալ։

Եվ հիմա մենք օգտագործում ենք միայն ինդեքսային սկանավորում:

Մեկ այլ կարևոր պատմություն այն է, որ մենք ցանկանում ենք ավելի հասկանալի կերպով ներկայացնել ծրագիրը: Մենք իրականացրել ենք վիզուալիզացիա՝ օգտագործելով Flame Graphs:

Սա այլ խնդրանք է, ավելի ինտենսիվ։ Եվ մենք կառուցում ենք Flame Graphs ըստ երկու պարամետրի. սա այն տվյալների քանակն է, որը որոշակի հանգույցը հաշվում է պլանում և ժամանակում, այսինքն՝ հանգույցի կատարման ժամանակը:

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

Իհարկե, բոլորը գիտեն բացատրել.depesz.com: Այս վիզուալիզացիայի լավ առանձնահատկությունն այն է, որ մենք պահպանում ենք տեքստի պլանը և նաև որոշ հիմնական պարամետրեր ենք դնում աղյուսակի մեջ, որպեսզի կարողանանք տեսակավորել:

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

Վիզուալիզացիայի նոր մոտեցում կա. սա բացատրում է.dalibo.com-ը: Նրանք ծառի վիզուալիզացիա են անում, բայց հանգույցները միմյանց հետ համեմատելը շատ դժվար է: Այստեղ դուք կարող եք լավ հասկանալ կառուցվածքը, սակայն, եթե կա մեծ խնդրանք, ապա ձեզ հարկավոր է ոլորել ետ ու առաջ, բայց նաև տարբերակ:

համագործակցություն

Եվ, ինչպես ասացի, Slack-ը մեզ համագործակցելու հնարավորություն է տալիս։ Օրինակ, եթե մենք հանդիպենք բարդ հարցման, որը պարզ չէ, թե ինչպես կարելի է օպտիմալացնել, մենք կարող ենք պարզաբանել այս հարցը մեր գործընկերների հետ Slack-ի թեմայում:

Մեզ թվում է, որ կարևոր է փորձարկել լրիվ չափի տվյալների վրա: Դա անելու համար մենք պատրաստեցինք Update Database Lab գործիքը, որը հասանելի է բաց կոդով: Կարող եք նաև օգտագործել Joe bot-ը: Դուք կարող եք վերցնել այն հենց հիմա և իրականացնել այն ձեր տեղում: Բոլոր ուղեցույցները հասանելի են այնտեղ:

Կարևոր է նաև նշել, որ լուծումն ինքնին հեղափոխական չէ, քանի որ կա Delphix, բայց այն ձեռնարկատիրական լուծում է: Ամբողջովին փակ է, շատ թանկ արժե։ Մենք հատուկ մասնագիտացած ենք Postgres-ում: Սրանք բոլորը բաց կոդով արտադրանք են: Միացեք մեզ!

Այստեղ ես ավարտում եմ: Շնորհակալություն!

Հարցեր

Բարեւ Ձեզ! Շնորհակալություն զեկույցի համար: Շատ հետաքրքիր է, հատկապես ինձ համար, որովհետև որոշ ժամանակ առաջ նույն խնդիրը լուծել եմ։ Եվ այսպես, ես ունեմ մի շարք հարցեր. Հուսով եմ, որ ես կստանամ դրա գոնե մի մասը:

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

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

Այո, ես մի հարցադրում ունեմ. Այսինքն՝ ինչպե՞ս եք ապահովում այս մոդուլների կյանքի ցիկլը։ Մենք ունենք այս խնդիրը և մի ամբողջ առանձին պատմություն։ Ինչպե՞ս է դա տեղի ունենում:

Յուրաքանչյուր կլոնի համար կա որոշակի ttl: Հիմնականում մենք ունենք ֆիքսված ttl:

Ի՞նչ, եթե ոչ գաղտնիք:

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

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

Ո՞րն է ZFS-ի հիմնական խնդիրը: Այն փաստը, որ դուք պետք է աշխատեք նույն հոսթի վրա, այսինքն՝ բոլոր ատյանները կգործեն նույն ՕՀ-ում: Իսկ պահեստավորման դեպքում կարելի է միացնել տարբեր սարքավորումներ։ Իսկ խցանումը միայն այն բլոկներն են, որոնք գտնվում են պահեստավորման համակարգում։ Իսկ տեխնոլոգիաների ընտրության հարցը հետաքրքիր է։ Ինչու ոչ LVM:

Մասնավորապես, մենք կարող ենք քննարկել LVM-ն հանդիպման ժամանակ: Պահպանման մասին - դա պարզապես թանկ է: Մենք կարող ենք իրականացնել ZFS համակարգը ցանկացած վայրում: Դուք կարող եք այն տեղադրել ձեր մեքենայի վրա: Դուք կարող եք պարզապես ներբեռնել պահեստը և տեղադրել այն: ZFS-ը տեղադրվում է գրեթե ամենուր, եթե խոսքը Linux-ի մասին է։ Այսինքն՝ մենք ստանում ենք շատ ճկուն լուծում։ Իսկ ZFS-ն ինքը շատ բան է տալիս տուփից: Կարող եք բեռնել այնքան տվյալներ, որքան ցանկանում եք, միացնել մեծ քանակությամբ սկավառակներ, կան snapshots: Եվ, ինչպես ասացի, հեշտ է կառավարել: Այսինքն՝ շատ հաճելի է թվում օգտագործել։ Նա փորձարկված է, նա շատ տարեկան է։ Նա ունի շատ մեծ համայնք, որն աճում է: ZFS-ը շատ հուսալի լուծում է:

Նիկոլայ Սամոխվալով. Կարո՞ղ եմ լրացուցիչ մեկնաբանություններ տալ: Ես Նիկոլայ եմ, աշխատում ենք Անատոլիի հետ միասին։ Համաձայն եմ, որ պահեստը հիանալի է: Եվ մեր որոշ հաճախորդներ ունեն Pure Storage և այլն:

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

Բայց ZFS-ը հասանելի է բոլորին: DelPhix-ն արդեն բավական է, նրանք ունեն 300 հաճախորդ։ Դրանցից Fortune 100-ն ունի 50 հաճախորդ, այսինքն՝ դրանք ուղղված են ՆԱՍԱ-ին և այլն։ Ժամանակն է, որ բոլորը ստանան այս տեխնոլոգիան։ Եվ դա է պատճառը, որ մենք ունենք բաց կոդով Core: Մենք ունենք ինտերֆեյսի մաս, որը բաց կոդով չէ: Սա այն հարթակն է, որը մենք ցույց կտանք։ Բայց մենք ցանկանում ենք, որ այն հասանելի լինի բոլորին: Մենք ցանկանում ենք հեղափոխություն անել, որպեսզի բոլոր փորձարկողները դադարեն գուշակել դյուրակիր համակարգիչների վրա: Պետք է գրենք SELECT և անմիջապես տեսնենք, որ դանդաղ է։ Դադարեք սպասել, որ DBA-ն ձեզ կասի այդ մասին: Ահա հիմնական նպատակը. Եվ ես կարծում եմ, որ մենք բոլորս կհասնենք սրան։ Եվ մենք այս բանը պատրաստում ենք բոլորի համար: Հետևաբար ZFS, քանի որ այն հասանելի կլինի ամենուր: Շնորհակալություն համայնքին խնդիրների լուծման և բաց կոդով լիցենզիա ունենալու համար և այլն։*

Ողջույններ: Շնորհակալություն զեկույցի համար: Իմ անունը Մաքսիմ է: Մենք նույն հարցերով ենք զբաղվել։ Նրանք ինքնուրույն են որոշել. Ինչպե՞ս եք կիսում ռեսուրսները այս կլոնների միջև: Յուրաքանչյուր կլոն ցանկացած պահի կարող է իր գործն անել՝ մեկը մի բան է փորձարկում, մյուսը՝ մյուսը, ինչ-որ մեկը ինդեքս է կառուցում, ինչ-որ մեկը ծանր աշխատանք ունի: Եվ եթե դուք դեռ կարող եք բաժանել CPU-ով, ապա IO-ով, ինչպես եք բաժանում: Սա առաջին հարցն է։

Իսկ երկրորդ հարցը տրիբունաների նմանության մասին է։ Ասենք, ես այստեղ ZFS ունեմ ու ամեն ինչ թույն է, բայց պրոդում գտնվող հաճախորդը չունի ZFS, այլ օրինակ ext4: Ինչպե՞ս այս դեպքում:

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

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

Երկու հարց ունեմ. Սա շատ թույն բան է: Եղե՞լ են դեպքեր, երբ արտադրության տվյալները կարևոր են, օրինակ՝ վարկային քարտերի համարները: Արդեն պատրաստ կա՞, թե՞ դա առանձին խնդիր է։ Եվ երկրորդ հարցը՝ MySQL-ի համար կա՞ նման բան։

Տվյալների մասին. Մինչեւ չանենք, մշուշապատում ենք անելու։ Բայց եթե դուք տեղակայում եք հենց Joe-ին, եթե մուտք չեք տալիս մշակողներին, ապա տվյալներին հասանելիություն չկա: Ինչո՞ւ։ Որովհետև Ջոն տվյալներ չի ցուցադրում: Այն ցույց է տալիս միայն չափումներ, պլաններ և վերջ: Դա արվել է միտումնավոր, քանի որ դա մեր հաճախորդի պահանջներից է։ Նրանք ցանկանում էին, որպեսզի կարողանան օպտիմալացնել՝ առանց բոլորին հասանելիություն տալու:

MySQL-ի մասին. Այս համակարգը կարող է օգտագործվել ցանկացած բանի համար, որը պահում է վիճակը սկավառակի վրա: Եվ քանի որ մենք անում ենք Postgres-ը, մենք հիմա առաջին հերթին անում ենք բոլոր ավտոմատացումը Postgres-ի համար: Մենք ցանկանում ենք ավտոմատացնել տվյալների ստացումը կրկնօրինակից: Մենք ճիշտ ենք կարգավորում Postgres-ը: Մենք գիտենք, թե ինչպես անել, որ պլանները համապատասխանեն և այլն:

Բայց քանի որ համակարգը ընդարձակելի է, այն կարող է օգտագործվել նաև MySQL-ի համար: Եվ նման օրինակներ կան. Yandex-ը նման բան ունի, բայց ոչ մի տեղ չեն հրապարակում։ Նրանք օգտագործում են Yandex.Metrica-ի ներսում։ Եվ կա պարզապես պատմություն MySQL-ի մասին: Բայց տեխնոլոգիաները նույնն են, ZFS:

Շնորհակալություն զեկույցի համար: Ես էլ մի երկու հարց ունեմ. Դուք նշեցիք, որ կլոնավորումը կարող է օգտագործվել վերլուծության համար, օրինակ՝ այնտեղ լրացուցիչ ինդեքսներ կառուցելու համար։ Կարո՞ղ եք մի փոքր ավելին պատմել, թե ինչպես է այն աշխատում:

Եվ ես անմիջապես կտամ երկրորդ հարցը տրիբունաների նմանության, պլանների նմանության մասին։ Պլանը կախված է նաև Postgres-ի հավաքած վիճակագրությունից: Ինչպե՞ս եք լուծում այս խնդիրը:

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

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

Ցուցանիշը ամեն անգամ կստեղծվի՞:

Դուք կարող եք այնպես անել, որ մենք դիպչենք տվյալներին, նկարներ պատրաստենք, այնուհետև մենք կվերականգնվենք այս լուսանկարից և կառաջարկենք նոր հարցումներ: Այսինքն՝ դուք կարող եք այնպես անել, որ կարողանաք նոր կլոններ բարձրացնել արդեն ամրացված ինդեքսներով։

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

Ահա ևս մեկ խնդիր. Եթե ​​դուք օգտագործում եք ամպային լուծում, ապա այնտեղ հասանելի են միայն տրամաբանական աղբանոցներ, քանի որ Google-ը, Amazon-ը ձեզ թույլ չեն տալիս ֆիզիկական պատճենահանել։ Խնդիր կլինի.

Շնորհակալություն զեկույցի համար: Այստեղ երկու լավ հարց կար MySQL-ի և ռեսուրսների փոխանակման վերաբերյալ: Բայց, փաստորեն, ամեն ինչ հանգում է նրան, որ սա ոչ թե կոնկրետ DBMS-ի, այլ ամբողջ ֆայլային համակարգի թեմա է: Եվ, համապատասխանաբար, ռեսուրսների փոխանակման հարցերը նույնպես պետք է լուծվեն այնտեղից, ոչ թե վերջում, որ դա Postgres է, այլ ֆայլային համակարգում, սերվերում, օրինակ։

Հարցս մի քիչ այլ է. Այն ավելի մոտ է բազմաշերտ տվյալների բազային, որտեղ կան մի քանի շերտեր։ Օրինակ, մենք ստեղծեցինք տասը տերաբայթանոց պատկերի թարմացում, մենք կրկնօրինակում ենք: Եվ մենք հատուկ օգտագործում ենք այս լուծումը տվյալների բազաների համար: Կրկնօրինակումն ընթացքի մեջ է, տվյալները թարմացվում են: Այստեղ զուգահեռ աշխատում են 100 աշխատակիցներ, ովքեր անընդհատ այս տարբեր կադրերն են արձակում։ Ինչ անել? Ինչպե՞ս համոզվել, որ կոնֆլիկտ չկա, որ նրանք մեկնարկեցին, և հետո ֆայլային համակարգը փոխվեց, և այս նկարները բոլորը գնացին:

Նրանք չեն գնա, քանի որ ZFS-ն այդպես է աշխատում: Մենք կարող ենք առանձին պահել մեկ թեմայում ֆայլային համակարգի փոփոխությունները, որոնք տեղի են ունենում կրկնօրինակման պատճառով: Եվ պահեք այն կլոնները, որոնք մշակողները օգտագործում են տվյալների հին տարբերակների վրա: Եվ դա մեզ մոտ աշխատում է, սրանով ամեն ինչ կարգին է։

Ստացվում է, որ թարմացումը տեղի կունենա որպես լրացուցիչ շերտ, և բոլոր նոր նկարները կգնան արդեն, այս շերտի հիման վրա, չէ՞:

Նախորդ շերտերից, որոնք նախորդ կրկնություններից էին:

Նախորդ շերտերը կընկնեն, բայց դրանք վերաբերելու են հին շերտին, և արդյոք նոր նկարներ կվերցնեն թարմացման մեջ ստացված վերջին շերտից:

Ընդհանուր առմամբ՝ այո։

Այնուհետև արդյունքում կունենանք մինչև թուզ շերտ։ Եվ ժամանակի ընթացքում դրանք պետք է սեղմել?

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

Բարև, շնորհակալություն զեկույցի համար: Հարց Ջոյի մասին. Դուք ասացիք, որ հաճախորդը չի ցանկանում բոլորին հասանելիություն տալ տվյալներին: Խստորեն ասած, եթե մարդն ունի Explain Analyze-ի արդյունքը, ապա նա կարող է դիտել տվյալները:

Դա այդպես է: Օրինակ, կարող ենք գրել. «SELECT FROM WHERE email = to that»: Այսինքն՝ մենք չենք տեսնի բուն տվյալները, բայց կարող ենք տեսնել որոշ անուղղակի նշաններ։ Սա պետք է հասկանալ. Բայց մյուս կողմից, ամեն ինչ կա: Մենք ունենք գրանցամատյանների աուդիտ, մենք վերահսկում ենք այլ գործընկերներ, ովքեր նույնպես տեսնում են, թե ինչ են անում մշակողները: Եվ եթե ինչ-որ մեկը փորձի դա անել, ապա անվտանգության ծառայությունը կգա նրանց մոտ և կաշխատի այս հարցով։

Բարի օր Շնորհակալություն զեկույցի համար: Մի կարճ հարց ունեմ. Եթե ​​ընկերությունը չի օգտագործում Slack-ը, այժմ կա՞ դրա հետ կապված որևէ կապ, կամ հնարավո՞ր է, որ մշակողները գործարկեն օրինակներ՝ փորձնական հավելվածը տվյալների բազաներին միացնելու համար:

Այժմ կա Slack-ի հղում, այսինքն՝ այլ մեսենջեր չկա, բայց ես իսկապես ցանկանում եմ աջակցություն ցուցաբերել նաև այլ մեսենջերների համար: Ինչ կարող ես դու անել? Դուք կարող եք տեղադրել DB Lab առանց Ջոյի, գնալ REST API-ի կամ մեր հարթակի օգնությամբ և ստեղծել կլոններ և միանալ PSQL-ի հետ: Բայց դա կարելի է անել, եթե պատրաստ եք ձեր ծրագրավորողներին հասանելիություն տալ տվյալներին, քանի որ այլևս էկրան չի լինի:

Ինձ այս շերտը պետք չէ, բայց ինձ պետք է նման հնարավորություն։

Հետո այո, դա կարելի է անել:

Source: www.habr.com