Յանդեքսի ներդրումը հետևյալ տվյալների բազաներում կվերանայվի.
- clickhouse
- Odyssey
- Վերականգնում մինչև ժամանակի մի կետ (WAL-G)
- PostgreSQL (ներառյալ logerrors, Amcheck, heapcheck)
- Greenplum
Video:
Բարեւ աշխարհ! Ես Անդրեյ Բորոդինն եմ։ Եվ այն, ինչ ես անում եմ Yandex.Cloud-ում, բաց հարաբերական տվյալների շտեմարանների մշակումն է՝ ելնելով Yandex.Cloud-ի և Yandex.Cloud-ի հաճախորդների շահերից:
Այս ելույթում մենք կխոսենք այն մարտահրավերների մասին, որոնք ծառացած են բաց տվյալների բազաների մասշտաբով: Ինչու է դա կարևոր: Քանի որ փոքր, փոքր խնդիրներ, որոնք, ինչպես մոծակները, հետո դառնում են փիղ: Նրանք մեծանում են, երբ շատ կլաստերներ ունես:
Բայց դա չէ գլխավորը: Անհավատալի բաներ են տեղի ունենում. Բաներ, որոնք տեղի են ունենում միլիոնից մեկ դեպքում. Եվ ամպային միջավայրում դուք պետք է պատրաստ լինեք դրան, քանի որ անհավանական բաները շատ հավանական են դառնում, երբ ինչ-որ բան գոյություն ունի մասշտաբով:
Բայց! Ո՞րն է բաց տվյալների բազայի առավելությունը: Փաստն այն է, որ դուք տեսական հնարավորություն ունեք զբաղվելու ցանկացած խնդրի հետ։ Դուք ունեք աղբյուրի կոդը, ունեք ծրագրավորման գիտելիքներ։ Մենք համատեղում ենք այն, և այն աշխատում է:
Ի՞նչ մոտեցումներ կան բաց կոդով ծրագրային ապահովման վրա աշխատելիս:
- Ամենաուղղակի մոտեցումը ծրագրային ապահովման օգտագործումն է: Եթե դուք օգտագործում եք արձանագրություններ, եթե օգտագործում եք ստանդարտներ, եթե օգտագործում եք ձևաչափեր, եթե հարցումներ եք գրում բաց կոդով ծրագրային ապահովման մեջ, ապա դուք արդեն աջակցում եք դրան:
- Դուք ավելի մեծացնում եք նրա էկոհամակարգը: Դուք մեծացնում եք վրիպակի վաղ հայտնաբերման հավանականությունը: Դուք բարձրացնում եք այս համակարգի հուսալիությունը: Դուք մեծացնում եք ծրագրավորողների հասանելիությունը շուկայում: Դուք բարելավում եք այս ծրագրաշարը: Դուք արդեն մասնակից եք, եթե պարզապես վերջացրիք ոճը ձեռք բերելու և այնտեղ ինչ-որ բանի հետ կապված:
- Մեկ այլ հասկանալի մոտեցում է բաց կոդով ծրագրային ապահովման հովանավորումը: Օրինակ, հայտնի Google Summer of Code ծրագիրը, երբ Google-ը վճարում է մեծ թվով ուսանողների ամբողջ աշխարհից հասկանալի գումար, որպեսզի նրանք մշակեն բաց ծրագրային նախագծեր, որոնք բավարարում են որոշակի արտոնագրման պահանջները:
- Սա շատ հետաքրքիր մոտեցում է, քանի որ այն թույլ է տալիս ծրագրակազմին զարգանալ՝ առանց ուշադրությունը համայնքից շեղելու: Google-ը, որպես տեխնոլոգիական հսկա, չի ասում, որ մենք ուզում ենք այս հնարավորությունը, մենք ուզում ենք շտկել այս սխալը, և այստեղ պետք է փորել: Google-ն ասում է. «Արա այն, ինչ անում ես: Պարզապես շարունակեք աշխատել այնպես, ինչպես աշխատել եք, և ամեն ինչ լավ կլինի»:
- Բաց կոդով մասնակցելու հաջորդ մոտեցումը մասնակցությունն է: Երբ դուք խնդիր ունեք բաց կոդով ծրագրային ապահովման մեջ, և կան մշակողներ, ձեր մշակողները սկսում են լուծել խնդիրները: Նրանք սկսում են ձեր ենթակառուցվածքն ավելի արդյունավետ դարձնել, ձեր ծրագրերն ավելի արագ և հուսալի դարձնել:
Բաց կոդով ծրագրային ապահովման ոլորտում Yandex-ի ամենահայտնի նախագծերից մեկը ClickHouse-ն է։ Սա տվյալների բազա է, որը ծնվել է որպես պատասխան Yandex.Metrica-ի առջեւ ծառացած մարտահրավերներին:
Եվ որպես տվյալների բազա, այն ստեղծվել է բաց կոդով, որպեսզի ստեղծվի էկոհամակարգ և զարգացնի այն այլ մշակողների հետ միասին (ոչ միայն Yandex-ի շրջանակներում): Իսկ այժմ սա մեծ նախագիծ է, որում ներգրավված են բազմաթիվ տարբեր ընկերություններ։
Yandex.Cloud-ում մենք ստեղծեցինք ClickHouse-ը Yandex Object Storage-ի վերևում, այսինքն՝ ամպային պահեստի վերևում:
Ինչու՞ է սա կարևոր ամպի մեջ: Որովհետև ցանկացած տվյալների բազա աշխատում է այս եռանկյունում, այս բուրգում, հիշողության տեսակների այս հիերարխիայում: Դուք ունեք արագ, բայց փոքր ռեգիստրներ և էժան մեծ, բայց դանդաղ SSD, կոշտ սկավառակներ և որոշ այլ բլոկ սարքեր: Եվ եթե դուք արդյունավետ եք բուրգի վերևում, ապա դուք ունեք արագ տվյալների բազա: եթե դուք արդյունավետ եք այս բուրգի ներքևում, ապա ունեք մասշտաբային տվյալների բազա: Եվ այս առումով ներքևից ևս մեկ շերտ ավելացնելը տրամաբանական մոտեցում է տվյալների բազայի մասշտաբայնությունը մեծացնելու համար։
Ինչպե՞ս կարելի էր դա անել։ Սա կարևոր կետ է այս զեկույցում:
- Մենք կարող ենք իրականացնել ClickHouse-ը MDS-ի միջոցով: MDS-ը Yandex-ի ամպային պահեստավորման ներքին ինտերֆեյս է: Այն ավելի բարդ է, քան սովորական S3 արձանագրությունը, բայց ավելի հարմար է բլոկային սարքի համար: Ավելի լավ է տվյալների գրանցման համար: Դա ավելի շատ ծրագրավորում է պահանջում։ Ծրագրավորողները կծրագրավորեն, դա նույնիսկ լավ է, հետաքրքիր է:
- S3-ն ավելի տարածված մոտեցում է, որը ինտերֆեյսը դարձնում է ավելի պարզ՝ որոշակի տեսակի ծանրաբեռնվածություններին ավելի քիչ հարմարվելու գնով:
Բնականաբար, ցանկանալով ապահովել ամբողջ ClickHouse էկոհամակարգի ֆունկցիոնալությունը և կատարել այն առաջադրանքը, որն անհրաժեշտ է Yandex.Cloud-ի ներսում, մենք որոշեցինք համոզվել, որ ամբողջ ClickHouse համայնքը կշահի դրանից: Մենք իրականացրեցինք ClickHouse-ը S3-ի վրա, այլ ոչ թե ClickHouse-ը MDS-ի միջոցով: Եվ սա մեծ աշխատանք է:
Հղումներ.
«Ֆայլային համակարգի աբստրակցիոն շերտ»
«AWS SDK S3 ինտեգրում»
«IDisk ինտերֆեյսի բազային ներդրում S3-ի համար»
«Մատյանների պահպանման շարժիչների ինտեգրում IDisk ինտերֆեյսով»
«Log շարժիչի աջակցություն S3-ի և SeekableReadBuffer-ի համար»
«Storage Stripe Log S3 աջակցություն»
«Storage MergeTree նախնական աջակցություն S3-ի համար»
«MergeTree-ի ամբողջական աջակցություն S3-ի համար»
«Աջակցեք ReplicatedMergeTree-ին S3-ի վրա»
«Ավելացրեք լռելյայն հավատարմագրեր և հատուկ վերնագրեր s3 պահեստավորման համար»
«S3 դինամիկ պրոքսի կոնֆիգուրացիայով»
«S3 պրոքսի լուծիչով»
Սա pull հայտերի ցանկ է ClickHouse-ում վիրտուալ ֆայլային համակարգի ներդրման համար: Սա ձգման հարցումների մեծ քանակ է:
Հղումներ.
«DiskS3 կոշտ կապերի օպտիմալ իրականացում»
«S3 HTTP հաճախորդ — Խուսափեք պատասխանների հոսքը հիշողության մեջ պատճենելուց»
«Խուսափեք S3 HTTP-ում պատասխանների ամբողջ հոսքը հիշողության մեջ պատճենելուց
հաճախորդ»
«S3 սկավառակի համար քեշի նշանի և ֆայլերի ինդեքսավորման հնարավորություն»
«Տեղափոխեք մասերը DiskLocal-ից DiskS3 զուգահեռաբար»
Բայց աշխատանքն այսքանով չավարտվեց. Հատկանիշի ստեղծումից հետո ևս որոշ աշխատանք է պահանջվել՝ այս գործառույթն օպտիմալացնելու համար:
Հղումներ.
«Ավելացնել SelectedRows և SelectedBytes իրադարձություններ»
«S3 հարցումից պրոֆիլավորման իրադարձություններ ավելացնել system.events»
«Ավելացնել QueryTimeMicroseconds, SelectQueryTimeMicroseconds և InsertQueryTimeMicroseconds»
Եվ հետո անհրաժեշտ էր դա ախտորոշելի դարձնել, մոնիթորինգ ստեղծել և կառավարելի դարձնել:
Եվ այս ամենն արվեց, որպեսզի ամբողջ համայնքը, ամբողջ ClickHouse էկոհամակարգը ստանա այս աշխատանքի արդյունքը։
Անցնենք գործարքային տվյալների բազաներին, OLTP տվյալների բազաներին, որոնք ավելի մոտ են անձամբ ինձ։
Սա բաց կոդով DBMS-ի մշակման բաժինն է: Այս տղաները փողոցային մոգություն են անում՝ գործարքների բաց տվյալների բազաները բարելավելու համար:
Նախագծերից մեկը, որի օրինակով կարելի է խոսել այն մասին, թե ինչպես և ինչ ենք անում, Connection Pooler-ն է Postgres-ում:
Postgres-ը գործընթացների տվյալների բազա է: Սա նշանակում է, որ տվյալների բազան պետք է ունենա հնարավորինս քիչ ցանցային կապեր, որոնք կառավարում են գործարքները:
Մյուս կողմից, ամպային միջավայրում բնորոշ իրավիճակ է, երբ հազար կապ միանգամից գալիս է մեկ կլաստերի: Եվ կապի pooler-ի խնդիրն է փաթեթավորել հազար կապեր սերվերի միացումների փոքր քանակի մեջ:
Կարելի է ասել, որ կապի միավորիչը հեռախոսային օպերատորն է, ով վերադասավորում է բայթերն այնպես, որ դրանք արդյունավետորեն հասնեն տվյալների բազա:
Ցավոք, ռուսերեն լավ բառ չկա կապի ավազան: Երբեմն դա կոչվում է մուլտիպլեքսերի միացումներ: Եթե գիտեք, թե ինչպես անվանել կապի լողավազան, ապա անպայման ասեք, ես շատ ուրախ կլինեմ խոսել ճիշտ ռուսերեն տեխնիկական լեզվով:
Մենք ուսումնասիրեցինք կապի միավորները, որոնք հարմար էին կառավարվող postgres կլաստերի համար: Իսկ PgBouncer-ը մեզ համար լավագույն ընտրությունն էր: Բայց մենք հանդիպեցինք մի շարք խնդիրների PgBouncer-ի հետ: Շատ տարիներ առաջ Վոլոդյա Բորոդինը հաղորդումներ էր տալիս, որ մենք օգտագործում ենք PgBouncer, մեզ ամեն ինչ դուր է գալիս, բայց կան նրբերանգներ, աշխատելու բան կա։
Եվ մենք աշխատեցինք։ Մենք շտկեցինք մեր հանդիպած խնդիրները, կարկատեցինք Bouncer-ը և փորձեցինք մղել pull-ի հարցումները հոսանքին հակառակ: Սակայն հիմնարար մեկ թելերի հետ աշխատելը դժվար էր:
Մենք պետք է կասկադներ հավաքեինք կարկատված Բաունսերներից: Երբ մենք ունենք բազմաթիվ միաթելային Bouncers, վերին շերտի միացումները փոխանցվում են Bouncers-ի ներքին շերտին: Սա վատ կառավարվող համակարգ է, որը դժվար է կառուցել և մեծացնել առաջ ու առաջ:
Մենք եկանք այն եզրակացության, որ մենք ստեղծել ենք մեր սեփական կապի լողավազան, որը կոչվում է Odyssey: Մենք դա գրել ենք զրոյից։
2019-ին, PgCon կոնֆերանսում, ես ներկայացրեցի այս պուլերը մշակողների համայնքին: Այժմ մենք GitHub-ում ունենք 2-ից մի փոքր պակաս աստղ, այսինքն՝ նախագիծը կենդանի է, նախագիծը հայտնի է:
Եվ եթե Yandex.Cloud-ում ստեղծեք Postgres կլաստեր, ապա դա կլինի ներկառուցված Odyssey-ով կլաստեր, որը վերակազմավորվում է կլաստերը հետ կամ առաջ չափելիս:
Ի՞նչ սովորեցինք այս նախագծից: Մրցակցող նախագծի մեկնարկը միշտ ագրեսիվ քայլ է, ծայրահեղ միջոց է, երբ ասում ենք, որ կան խնդիրներ, որոնք բավական արագ չեն լուծվում, չեն լուծվում մեզ հարմար ժամանակային ընդմիջումներով։ Բայց սա արդյունավետ միջոց է։
PgBouncer-ը սկսեց ավելի արագ զարգանալ:
Իսկ հիմա այլ նախագծեր են հայտնվել։ Օրինակ՝ pgagroal-ը, որը մշակվել է Red Hat-ի մշակողների կողմից։ Նրանք հետապնդում են նմանատիպ նպատակներ և իրականացնում են նմանատիպ գաղափարներ, բայց, իհարկե, իրենց առանձնահատկություններով, որոնք ավելի մոտ են pgagroal մշակողներին։
Պոստգրես համայնքի հետ աշխատելու ևս մեկ դեպք է վերականգնվում ժամանակի մի կետում: Սա վերականգնում է ձախողումից հետո, սա վերականգնում է կրկնօրինակից:
Կան բազմաթիվ կրկնօրինակներ, և դրանք բոլորը տարբեր են: Գրեթե յուրաքանչյուր Postgres վաճառող ունի իր պահուստային լուծումը:
Եթե վերցնեք բոլոր պահուստային համակարգերը, ստեղծեք առանձնահատկությունների մատրիցա և կատակով հաշվարկեք որոշիչն այս մատրիցում, այն կլինի զրո: Ինչ է սա նշանակում? Իսկ եթե վերցնում եք հատուկ պահուստային ֆայլ, ապա այն չի կարող հավաքվել մնացած բոլոր մասերից: Այն եզակի է իր իրականացման մեջ, եզակի է իր նպատակներով, եզակի է իր մեջ ներդրված գաղափարներով։ Եվ դրանք բոլորը կոնկրետ են:
Մինչ մենք աշխատում էինք այս հարցի վրա, CitusData-ն գործարկեց WAL-G նախագիծը: Սա պահեստային համակարգ է, որը ստեղծվել է ամպային միջավայրին ուշադրություն դարձնելով: Այժմ CitusData-ն արդեն Microsoft-ի մի մասն է: Եվ այդ պահին մեզ շատ դուր եկան այն գաղափարները, որոնք դրված էին WAL-G-ի սկզբնական թողարկումներում։ Եվ մենք սկսեցինք նպաստել այս նախագծին:
Այժմ այս նախագծում կան տասնյակ մշակողներ, սակայն WAL-G-ի լավագույն 10 ներդրողները ներառում են 6 Yandexoid: Մենք այնտեղ բերեցինք մեր շատ գաղափարներ։ Եվ, իհարկե, մենք ինքներս իրականացրեցինք դրանք, ինքներս փորձարկեցինք, ինքներս թողարկեցինք արտադրության մեջ, մենք ինքներս օգտագործում ենք դրանք, մենք ինքներս պարզում ենք, թե ուր շարժվել հաջորդը՝ WAL-G մեծ համայնքի հետ շփվելիս:
Եվ մեր տեսանկյունից, այժմ այս պահեստային համակարգը, այդ թվում՝ հաշվի առնելով մեր ջանքերը, դարձել է օպտիմալ ամպային միջավայրի համար։ Սա ամպում Postgres-ի կրկնօրինակման լավագույն արժեքն է:
Ինչ է դա նշանակում? Մենք բավականին մեծ գաղափար էինք առաջ քաշում. պահուստավորումը պետք է ապահով լինի, էժան աշխատի և հնարավորինս արագ վերականգնվի:
Ինչու՞ պետք է էժան լինի շահագործումը: Երբ ոչինչ չի կոտրվել, դուք չպետք է իմանաք, որ կրկնօրինակներ ունեք: Ամեն ինչ լավ է աշխատում, որքան հնարավոր է քիչ պրոցեսոր եք վատնում, որքան հնարավոր է քիչ եք օգտագործում ձեր սկավառակի ռեսուրսները և որքան հնարավոր է քիչ բայթ եք ուղարկում ցանց, որպեսզի չխանգարեք ձեր արժեքավոր ծառայությունների ծանրաբեռնվածությանը:
Իսկ երբ ամեն ինչ փչանում է, օրինակ, ադմինը գցել է տվյալները, ինչ-որ բան սխալ է տեղի ունեցել, և շտապ պետք է վերադառնալ անցյալ, ողջ գումարով վերականգնում ես, քանի որ ուզում ես արագ և անձեռնմխելի ետ վերադարձնել քո տվյալները։
Եվ մենք առաջ քաշեցինք այս պարզ գաղափարը։ Եվ, մեզ թվում է, մեզ հաջողվեց դա իրականացնել։
Բայց սա դեռ ամենը չէ: Մի փոքր բան էլ էինք ուզում. Մենք ցանկանում էինք շատ տարբեր տվյալների բազաներ: Մեր ոչ բոլոր հաճախորդներն են օգտագործում Postgres-ը: Որոշ մարդիկ օգտագործում են MySQL, MongoDB: Համայնքում այլ մշակողներ աջակցել են FoundationDB-ին: Եվ այս ցանկն անընդհատ ընդլայնվում է։
Համայնքին դուր է գալիս տվյալների բազան ամպի կառավարվող միջավայրում գործարկելու գաղափարը: Եվ ծրագրավորողները պահպանում են իրենց տվյալների բազաները, որոնք կարող են միատեսակ կրկնօրինակվել Postgres-ի հետ միասին մեր պահուստային համակարգով:
Ի՞նչ սովորեցինք այս պատմությունից: Մեր արտադրանքը, որպես զարգացման բաժին, կոդի տողեր չէ, հայտարարություններ չեն, ֆայլեր չեն: Մեր արտադրանքը ձգողական պահանջներ չէ: Սրանք այն գաղափարներն են, որոնք մենք փոխանցում ենք համայնքին։ Սա տեխնոլոգիական փորձաքննություն է և տեխնոլոգիաների շարժում դեպի ամպային միջավայր:
Կա Postgres-ի նման տվյալների բազա։ Ինձ ամենից շատ դուր է գալիս Postgres միջուկը: Ես շատ ժամանակ եմ ծախսում համայնքի հետ Postgres-ի միջուկը զարգացնելու վրա:
Բայց այստեղ պետք է ասել, որ Yandex.Cloud-ն ունի կառավարվող տվյալների բազաների ներքին տեղադրում։ Եվ դա սկսվել է շատ վաղուց Yandex.Mail-ում։ Փորձաքննությունը, որն այժմ հանգեցրել է կառավարվող Postgres-ին, կուտակվել է, երբ փոստը ցանկացել է տեղափոխվել Postgres:
Փոստը շատ նման պահանջներ ունի ամպին: Այն պետք է, որ դուք կարողանաք հասնել անսպասելի էքսպոնենցիալ աճի ձեր տվյալների ցանկացած կետում: Եվ փոստն արդեն ուներ մի քանի հարյուր միլիոն փոստարկղերով հսկայական թվով օգտատերերի, ովքեր անընդհատ բազմաթիվ հարցումներ են անում:
Եվ սա բավականին լուրջ մարտահրավեր էր այն թիմի համար, որը զարգացնում էր Պոստգրեսը։ Դեռ այն ժամանակ մեր հանդիպած ցանկացած խնդրի մասին տեղեկացվում էր համայնքին: Եվ այս խնդիրները շտկվեցին և համայնքի կողմից որոշ տեղերում շտկվեցին նույնիսկ որոշ այլ տվյալների բազաների վճարովի աջակցության մակարդակով և նույնիսկ ավելի լավ: Այսինքն՝ դուք կարող եք նամակ ուղարկել PgSQL հաքերին և ստանալ պատասխան 40 րոպեի ընթացքում։ Որոշ տվյալների բազաներում վճարովի աջակցությունը կարող է մտածել, որ կան ավելի առաջնահերթ բաներ, քան ձեր սխալը:
Այժմ Postgres-ի ներքին տեղադրումը մի քանի փետաբայթ տվյալ է: Սրանք վայրկյանում մի քանի միլիոն հարցումներ են: Սրանք հազարավոր կլաստերներ են: Այն շատ մասշտաբային է։
Բայց կա մի նրբերանգ. Այն ապրում է ոչ թե շքեղ ցանցային կրիչներով, այլ բավականին պարզ սարքավորումներով: Եվ կա թեստային միջավայր հատուկ հետաքրքիր նոր բաների համար:
Եվ որոշակի պահի թեստային միջավայրում մենք ստացանք հաղորդագրություն, որը ցույց էր տալիս, որ տվյալների բազայի ինդեքսների ներքին ինվարիանտները խախտվել են։
Ինվարիանտը հարաբերությունների մի տեսակ է, որը մենք ակնկալում ենք, որ միշտ պահպանվեն:
Շատ կրիտիկական իրավիճակ է մեզ համար. Դա ցույց է տալիս, որ որոշ տվյալներ կարող են կորել: Եվ տվյալների կորուստը ուղղակի աղետալի բան է:
Ընդհանուր գաղափարը, որին մենք հետևում ենք կառավարվող տվյալների բազաներում, այն է, որ նույնիսկ ջանքերի դեպքում դժվար կլինի տվյալներ կորցնել: Նույնիսկ եթե դուք դիտավորյալ հեռացնեք դրանք, դուք դեռ պետք է անտեսեք դրանց բացակայությունը երկար ժամանակով: Տվյալների անվտանգությունը կրոն է, որին մենք բավականին ջանասիրաբար հետևում ենք:
Եվ այստեղ ստեղծվում է մի իրավիճակ, որը հուշում է, որ կարող է լինել մի իրավիճակ, որին մենք պատրաստ չլինենք։ Եվ մենք սկսեցինք պատրաստվել այս իրավիճակին:
Առաջին բանը, որ մենք արեցինք, թաղեցինք այս հազարավոր կլաստերների գերանները: Մենք գտանք, թե կլաստերներից որոնք էին գտնվում խնդրահարույց որոնվածով սկավառակների վրա, որոնք կորցնում էին տվյալների էջի թարմացումները: Նշված բոլոր Postgres տվյալների ծածկագիրը: Եվ այդ հաղորդագրությունները, որոնք ցույց են տալիս ներքին ինվարիանտների խախտումները, մենք նշել ենք կոդով, որը նախատեսված է տվյալների կոռուպցիան հայտնաբերելու համար:
Այս կարկատումը գործնականում ընդունվեց համայնքի կողմից՝ առանց մեծ քննարկման, քանի որ յուրաքանչյուր կոնկրետ դեպքում ակնհայտ էր, որ ինչ-որ վատ բան է տեղի ունեցել և պետք է տեղեկանալ գրանցամատյանում:
Դրանից հետո մենք հասանք նրան, որ ունենք մոնիտորինգ, որը սկանավորում է տեղեկամատյանները: Իսկ կասկածելի հաղորդագրությունների դեպքում նա արթնացնում է հերթապահին, իսկ հերթապահն այն վերանորոգում է։
Բայց! Տեղեկամատյանների սկանավորումը էժան գործողություն է մեկ կլաստերի վրա և աղետալիորեն թանկ՝ հազար կլաստերների համար:
Մենք գրել ենք ընդլայնում, որը կոչվում է . Այն ստեղծում է տվյալների բազայի տեսք, որտեղ դուք կարող եք էժան և արագ ընտրել անցյալի սխալների վիճակագրությունը: Իսկ եթե մեզ պետք է արթնացնել հերթապահին, ապա այս մասին կիմանանք առանց գիգաբայթ ֆայլերը սկանավորելու, այլ հեշ աղյուսակից մի քանի բայթ հանելով։
Այս ընդլայնումն ընդունվել է, օրինակ, պահոցում . Եթե ցանկանում եք օգտագործել այն, կարող եք տեղադրել այն ինքներդ: Իհարկե բաց կոդով է:
Բայց սա դեռ ամենը չէ: Մենք սկսեցինք օգտագործել Amcheck-ը՝ համայնքի կողմից ստեղծված ընդլայնում, ինդեքսներում անփոփոխ խախտումներ գտնելու համար:
Եվ մենք պարզեցինք, որ եթե այն գործարկեք մասշտաբով, ապա կան սխալներ: Մենք սկսեցինք շտկել դրանք: Մեր ուղղումներն ընդունվել են։
Մենք պարզեցինք, որ այս ընդլայնումը չի կարող վերլուծել GiST & GIT ինդեքսները: Մենք ստիպեցինք նրանց աջակցել։ Բայց այս աջակցությունը դեռ քննարկվում է համայնքի կողմից, քանի որ սա համեմատաբար նոր գործառույթ է, և այնտեղ շատ մանրամասներ կան:
Եվ մենք նաև հայտնաբերեցինք, որ կրկնօրինակման առաջնորդի, վարպետի վրա խախտումների ինդեքսները ստուգելիս ամեն ինչ լավ է աշխատում, բայց կրկնօրինակների, հետևորդի վրա կոռուպցիայի որոնումն այնքան էլ արդյունավետ չէ: Ոչ բոլոր ինվարիանտներն են ստուգվում: Եվ մի ինվարիանտ մեզ շատ անհանգստացրեց. Եվ մենք մեկուկես տարի անցկացրեցինք համայնքի հետ հաղորդակցվելու համար, որպեսզի հնարավոր դառնար կրկնօրինակների այս ստուգումը:
Մենք գրել ենք կոդ, որը պետք է հետևի բոլոր կարող... արձանագրություններին: Մենք բավականին երկար քննարկեցինք այս կարկատելը Crunchy Data-ից Փիթեր Գագանի հետ: Նա ստիպված էր մի փոքր փոփոխել Պոստգրեսում գոյություն ունեցող B-ծառը, որպեսզի ընդուներ այս կարկատումը: Նա ընդունվեց։ Եվ այժմ կրկնօրինակների ինդեքսների ստուգումը նույնպես բավական արդյունավետ է դարձել՝ հայտնաբերելու այն խախտումները, որոնց մենք հանդիպել ենք: Այսինքն, սրանք այն խախտումներն են, որոնք կարող են առաջանալ սկավառակի որոնվածի սխալների, Postgres-ի սխալների, Linux միջուկի սխալների և ապարատային խնդիրների պատճառով: Խնդիրների աղբյուրների բավականին ընդարձակ ցանկ, որոնց մենք պատրաստվում էինք։
Բայց բացի ինդեքսներից, կա այնպիսի մաս, ինչպիսին է կույտը, այսինքն՝ այն վայրը, որտեղ տվյալները պահվում են: Եվ շատ ինվարիանտներ չկան, որոնք կարելի է ստուգել:
Մենք ունենք ընդլայնում, որը կոչվում է Heapcheck: Մենք սկսեցինք զարգացնել այն: Ու դրան զուգահեռ մեզ հետ միասին EnterpriseDB ընկերությունը նույնպես սկսեց մոդուլ գրել, որը նույն կերպ անվանեցին Heapcheck։ Միայն մենք այն անվանեցինք PgHeapcheck, իսկ նրանք պարզապես անվանեցին Heapcheck: Նրանք ունեն նմանատիպ գործառույթներով, մի փոքր այլ ստորագրությամբ, բայց նույն գաղափարներով։ Դրանք տեղ-տեղ մի քիչ ավելի լավ են իրականացրել։ Եվ նրանք նախկինում տեղադրեցին բաց կոդով:
Եվ հիմա մենք զարգացնում ենք նրանց ընդլայնումը, քանի որ դա արդեն ոչ թե իրենց, այլ համայնքի ընդլայնումն է։ Իսկ ապագայում սա այն միջուկի մի մասն է, որը կտրամադրվի բոլորին, որպեսզի նրանք կարողանան նախապես իմանալ ապագա խնդիրների մասին։
Որոշ տեղերում նույնիսկ եկանք այն եզրակացության, որ մեր մոնիտորինգի համակարգերում ունենք կեղծ պոզիտիվներ։ Օրինակ, 1C համակարգը: Տվյալների բազա օգտագործելիս Postgres-ը երբեմն գրում է տվյալներ, որոնք կարող է կարդալ, բայց pg_dump-ը չի կարող կարդալ:
Այս իրավիճակը մեր խնդիրների հայտնաբերման համակարգին կոռուպցիոն տեսք ուներ: Հերթապահին արթնացրել են. Հերթապահը նայեց, թե ինչ է կատարվում. Որոշ ժամանակ անց մի հաճախորդ եկավ ու ասաց, որ խնդիրներ ունեմ։ Սպասավորը բացատրեց, թե որն է խնդիրը. Բայց խնդիրը Postgres-ի հիմքում է:
Ես գտա քննարկում այս հատկության մասին: Եվ նա գրել է, որ մենք հանդիպել ենք այս հատկանիշին, և դա տհաճ է, մարդը գիշերը արթնացել է, որպեսզի հասկանա, թե դա ինչ է։
Համայնքը պատասխանեց. «Օ, մենք իսկապես պետք է շտկենք դա»:
Ես ունեմ մի պարզ անալոգիա. Եթե դուք քայլում եք կոշիկով, որի մեջ ավազի հատիկ կա, ապա, սկզբունքորեն, կարող եք առաջ շարժվել՝ խնդիր չկա: Եթե հազարավոր մարդկանց կոշիկ եք վաճառում, ուրեմն եկեք ընդհանրապես առանց ավազի երկարաճիտ կոշիկներ պատրաստենք։ Եվ եթե ձեր կոշիկներից օգտվողներից մեկը պատրաստվում է մարաթոն վազել, ապա դուք ցանկանում եք շատ լավ կոշիկներ պատրաստել, իսկ հետո դրանք չափել ձեր բոլոր օգտագործողների համար: Եվ նման անսպասելի օգտվողները միշտ գտնվում են ամպային միջավայրում: Միշտ կան օգտատերեր, ովքեր օգտագործում են կլաստերը ինչ-որ օրիգինալ ձևով: Դուք միշտ պետք է պատրաստվեք դրան:
Ի՞նչ ենք մենք սովորել այստեղ: Մի պարզ բան սովորեցինք՝ կարևորը համայնքին բացատրելն է, որ խնդիր կա։ Եթե համայնքը ճանաչել է խնդիրը, ապա բնական մրցակցություն է առաջանում խնդիրը լուծելու համար։ Որովհետև բոլորն ուզում են լուծել մի կարևոր խնդիր. Բոլոր վաճառողները, բոլոր հաքերները հասկանում են, որ իրենք կարող են ոտք դնել այս փոցխին, ուստի ցանկանում են վերացնել նրանց։
Եթե դուք աշխատում եք խնդրի վրա, բայց դա ձեզանից բացի ոչ մեկին չի անհանգստացնում, բայց դուք համակարգված աշխատում եք դրա վրա և այն ի վերջո համարվում է խնդիր, ապա ձեր ձգման խնդրանքն անպայման կընդունվի: Ձեր կարկատելը կընդունվի, ձեր բարելավումները կամ նույնիսկ բարելավման հարցումները կվերանայվեն համայնքի կողմից: Օրվա վերջում մենք տվյալների բազան ավելի լավն ենք դարձնում միմյանց համար:
Հետաքրքիր տվյալների բազա է Greenplum-ը: Դա խիստ զուգահեռ տվյալների բազա է, որը հիմնված է Postgres կոդերի բազայի վրա, որը ես շատ ծանոթ եմ:
Իսկ Greenplum-ն ունի հետաքրքիր ֆունկցիոնալություն՝ կցել օպտիմիզացված աղյուսակներ: Սրանք աղյուսակներ են, որոնք կարող եք արագ ավելացնել: Նրանք կարող են լինել կամ սյունակ, կամ տող:
Բայց չկար կլաստերավորում, այսինքն՝ չկար ֆունկցիոնալություն, որտեղ դուք կարող եք դասավորել աղյուսակում գտնվող տվյալները՝ ըստ ինդեքսներից մեկի հերթականության:
Տաքսու տղաները եկան ինձ մոտ և ասացին. «Անդրեյ, դու ճանաչում ես Պոստգրեսին։ Եվ այստեղ գրեթե նույնն է. Անցեք 20 րոպեի: Դու վերցրու ու արա»։ Ես մտածեցի, որ այո, ես գիտեմ Postgres-ը, անցնելով 20 րոպե, ես պետք է դա անեմ:
Բայց ոչ, դա 20 րոպե չէր, ես դա գրել եմ ամիսների ընթացքում: PgConf.Russia կոնֆերանսի ժամանակ ես մոտեցա Հեյկի Լինականգասին Pivotal-ից և հարցրեցի. «Սրա հետ կապված խնդիրներ կա՞ն: Ինչու՞ չկա հավելվածի օպտիմիզացված աղյուսակների կլաստերավորում»: Նա ասում է. «Դուք վերցրեք տվյալները։ Դուք դասավորում եք, վերադասավորում եք։ Դա ուղղակի աշխատանք է»: Ես. «Օ, այո, դուք պարզապես պետք է վերցնեք և անեք դա»: Նա ասում է. «Այո, մեզ ազատ ձեռքեր են պետք դա անելու համար»։ Ես մտածեցի, որ ես անպայման պետք է դա անեմ:
Եվ մի քանի ամիս անց ես ներկայացրեցի ձգման հարցում, որն իրականացրեց այս գործառույթը: Այս խնդրանքը վերանայվել է Pivotal-ի կողմից համայնքի հետ միասին: Իհարկե, վրիպակներ կային։
Բայց ամենահետաքրքիրն այն է, որ երբ այս ձգման հարցումը միաձուլվեց, սխալներ հայտնաբերվեցին հենց Greenplum-ում: Մենք պարզել ենք, որ կույտային աղյուսակները երբեմն խախտում են գործառնականությունը, երբ դրանք հավաքվում են: Եվ սա մի բան է, որը պետք է շտկել։ Եվ նա այն տեղում է, որին ես հենց նոր շոշափեցի։ Եվ իմ բնական արձագանքը հետևյալն էր. լավ, թույլ տվեք դա անել:
Ես ուղղեցի այս սխալը: Ուղարկեց ձգման հարցում ամրագրողներին: Նրան սպանել են։
Որից հետո պարզվեց, որ այս ֆունկցիոնալությունը պետք է ձեռք բերել PostgreSQL 12-ի Greenplum տարբերակում։ Այսինքն՝ 20 րոպեանոց արկածը շարունակվում է նոր հետաքրքիր արկածներով։ Հետաքրքիր էր շոշափել ներկայիս զարգացումը, որտեղ համայնքը կտրում է նոր և ամենակարևոր հատկանիշները: Սառած է։
Բայց ամեն ինչ այսքանով չավարտվեց: Ամեն ինչից հետո պարզվեց, որ այս ամենի համար պետք է փաստաթղթեր գրել։
Ես սկսեցի փաստաթղթեր գրել: Բարեբախտաբար, Pivotal-ի վավերագրողները եկան: Անգլերենը նրանց մայրենի լեզուն է: Նրանք ինձ օգնեցին փաստաթղթերի հարցում: Իրականում նրանք իրենք են վերաշարադրել իմ առաջարկածը իրական անգլերենի։
Եվ ահա, կարծես թե, արկածն ավարտվեց։ Իսկ դուք գիտե՞ք, թե ինչ եղավ հետո։ Տաքսու տղաները եկան ինձ մոտ և ասացին. «Դեռ երկու արկած կա՝ յուրաքանչյուրը 10 րոպեով»։ Իսկ ի՞նչ ասեմ նրանց։ Ես ասացի, որ հիմա մասշտաբով հաշվետվություն կտամ, հետո կտեսնենք ձեր արկածները, քանի որ սա հետաքրքիր աշխատանք է։
Ի՞նչ սովորեցինք այս դեպքից։ Քանի որ բաց կոդով աշխատելը միշտ աշխատում է կոնկրետ անձի հետ, այն միշտ աշխատում է համայնքի հետ: Որովհետև յուրաքանչյուր փուլում ես աշխատել եմ ինչ-որ մշակողի, ինչ-որ փորձարկողի, ինչ-որ հաքերի, ինչ-որ վավերագրողի, ինչ-որ ճարտարապետի հետ: Ես չեմ աշխատել Greenplum-ի հետ, ես աշխատել եմ Greenplum-ի շրջապատի մարդկանց հետ:
Բայց! Կա ևս մեկ կարևոր կետ՝ դա պարզապես աշխատանք է: Այսինքն՝ գալիս ես, սուրճ խմում, ծածկագիր գրում։ Բոլոր տեսակի պարզ ինվարիանտներն աշխատում են: Արեք դա նորմալ, լավ կլինի: Եվ դա բավականին հետաքրքիր աշխատանք է: Այս աշխատանքի համար հարցում կա Yandex.Cloud-ի հաճախորդներից՝ մեր կլաստերների օգտագործողներից և՛ Yandex-ի ներսում, և՛ դրսում: Եվ կարծում եմ, որ նախագծերի թիվը, որոնց մենք մասնակցում ենք, կավելանա, կավելանա նաև մեր ներգրավվածության խորությունը։
Այսքանը: Անցնենք հարցերին։
Հարցերի նիստ
Բարեւ Ձեզ! Եվս մեկ հարց ու պատասխան ունենք. Իսկ ստուդիայում Անդրեյ Բորոդինը։ Սա այն մարդն է, ով հենց նոր պատմեց ձեզ Yandex.Cloud-ի և Yandex-ի ներդրման մասին բաց կոդով: Մեր զեկույցն այժմ ամբողջությամբ չի վերաբերում Cloud-ին, բայց միևնույն ժամանակ մենք հիմնված ենք նման տեխնոլոգիաների վրա: Առանց այն ամենի, ինչ անում էիք Yandex-ի ներսում, Yandex.Cloud-ում ծառայություն չէր լինի, այնպես որ շնորհակալություն եմ հայտնում անձամբ ինձանից: Եվ առաջին հարցը հեռարձակումից. «Ի՞նչ է գրված ձեր նշած նախագծերից յուրաքանչյուրը»:
WAL-G-ի պահեստային համակարգը գրված է Go-ում: Սա այն նոր նախագծերից է, որոնց վրա մենք աշխատել ենք։ Նա բառացիորեն ընդամենը 3 տարեկան է։ Եվ տվյալների բազան հաճախ վերաբերում է հուսալիությանը: Իսկ դա նշանակում է, որ տվյալների շտեմարանները բավականին հին են և դրանք սովորաբար գրված են C-ով: Postgres նախագիծը սկսվել է մոտ 30 տարի առաջ: Այնուհետև C89-ը ճիշտ ընտրություն էր: Իսկ վրան գրված է Պոստգրես. Ավելի ժամանակակից տվյալների բազաները, ինչպիսին է ClickHouse-ը, սովորաբար գրված են C++-ով: Համակարգի ամբողջ զարգացումը հիմնված է C-ի և C++-ի վրա:
Հարց մեր ֆինանսական մենեջերի կողմից, ով պատասխանատու է Cloud-ի ծախսերի համար. «Ինչո՞ւ է Cloud-ը գումար ծախսում բաց կոդով աջակցության վրա»:
Այստեղ ֆինանսական մենեջերի համար պարզ պատասխան կա. Մենք դա անում ենք մեր ծառայություններն ավելի լավը դարձնելու համար: Ի՞նչ ձևերով կարող ենք ավելի լավ գործել: Մենք կարող ենք անել ամեն ինչ ավելի արդյունավետ, ավելի արագ և ավելի լայնածավալ դարձնել: Բայց մեզ համար այս պատմությունն առաջին հերթին հուսալիության մասին է: Օրինակ, պահեստային համակարգում մենք վերանայում ենք դրա վրա կիրառվող պատչերի 100%-ը: Մենք գիտենք, թե որն է ծածկագիրը: Եվ մենք ավելի հարմար ենք նոր տարբերակների արտադրության համար: Այսինքն՝ խոսքը առաջին հերթին վստահության, զարգացման պատրաստակամության և հուսալիության մասին է
Մեկ այլ հարց. «Yandex.Cloud-ում ապրող արտաքին օգտատերերի պահանջները տարբերվու՞մ են ներքին Cloud-ում ապրող ներքին օգտատերերի պահանջներից»:
Բեռնման պրոֆիլը, իհարկե, տարբեր է: Բայց իմ բաժնի տեսանկյունից բոլոր հատուկ ու հետաքրքիր դեպքերը ստեղծվում են ոչ ստանդարտ ծանրաբեռնվածության վրա։ Երևակայություն ունեցող ծրագրավորողներին, անսպասելին անող ծրագրավորողներին նույնքան հավանական է, որ գտնվեն ինչպես ներքին, այնպես էլ արտաքին: Այս առումով մենք բոլորս մոտավորապես նույնն ենք։ Եվ, հավանաբար, Yandex-ի տվյալների շտեմարանների շահագործման մեջ միակ կարևոր հատկանիշը կլինի այն, որ Yandex-ի ներսում մենք ունենք ուսուցում։ Ինչ-որ պահի, որոշ հասանելիության գոտի ամբողջությամբ անցնում է ստվերում, և Yandex-ի բոլոր ծառայությունները պետք է ինչ-որ կերպ շարունակեն գործել, չնայած դրան: Սա փոքր տարբերություն է։ Բայց դա ստեղծում է բազմաթիվ հետազոտությունների զարգացում տվյալների բազայի և ցանցի կույտի միջերեսում: Հակառակ դեպքում, արտաքին և ներքին տեղակայանքները առաջացնում են նույն պահանջները հատկանիշների և նմանատիպ հարցումներ՝ հուսալիությունը և արդյունավետությունը բարելավելու համար:
Հաջորդ հարցը. «Ինչպե՞ս եք դուք անձամբ վերաբերվում այն փաստին, որ ձեր արածի մեծ մասն օգտագործվում է այլ Ամպերի կողմից»: Մենք կոնկրետ չենք անվանի, բայց շատ նախագծեր, որոնք կատարվել են Yandex.Cloud-ում, օգտագործվում են այլ մարդկանց ամպերում:
Սա թույն է: Նախ, դա նշան է, որ մենք ինչ-որ բան ճիշտ ենք արել։ Եվ դա քորում է էգոն: Եվ մենք ավելի վստահ ենք, որ ճիշտ որոշում ենք կայացրել։ Մյուս կողմից, սա հույս է, որ ապագայում դա մեզ կբերի նոր գաղափարներ, նոր խնդրանքներ երրորդ կողմի օգտատերերի կողմից: GitHub-ի խնդիրների մեծ մասը ստեղծվում է առանձին համակարգի ադմինիստրատորների, անհատ DBA-ների, առանձին ճարտարապետների, անհատ ինժեներների կողմից, բայց երբեմն գալիս են համակարգված փորձ ունեցող մարդիկ և ասում, որ որոշ դեպքերի 30%-ում մենք ունենք այս խնդիրը և եկեք մտածենք, թե ինչպես լուծել այն: Սա այն է, ինչին մենք ամենաշատն ենք սպասում: Մենք անհամբեր սպասում ենք փորձի փոխանակմանը այլ ամպային հարթակների հետ:
Դուք շատ եք խոսել մարաթոնի մասին: Ես գիտեմ, որ դուք մարաթոն եք վազել Մոսկվայում։ Որպես արդյունք? Առաջ անցե՞լ եք PostgreSQL-ի տղաներին:
Ոչ, Օլեգ Բարթունովը շատ արագ է վազում։ Նա ավարտեց ինձնից մեկ ժամ առաջ։ Ընդհանուր առմամբ, ես գոհ եմ, թե որքան հեռու եմ հասել: Ինձ համար միայն ավարտելը ձեռքբերում էր։ Ընդհանուր առմամբ, զարմանալի է, որ postgres համայնքում այդքան շատ վազորդներ կան: Ինձ թվում է, որ ինչ-որ կապ կա աերոբիկ սպորտի և համակարգերի ծրագրավորման ցանկության միջև:
Ուզում եք ասել, որ ClickHouse-ում վազորդներ չկա՞ն:
Ես հաստատ գիտեմ, որ նրանք այնտեղ են։ ClickHouse-ը նաև տվյալների բազա է: Ի դեպ, Օլեգը հիմա ինձ գրում է. Սա հիանալի գաղափար է:
Մեկ այլ հարց Նիկիտայից հեռարձակումից. «Ինչու՞ ինքներդ շտկեցիք Greenplum-ի սխալը և չտաք այն կրտսերներին»: Ճիշտ է, այնքան էլ պարզ չէ, թե որն է սխալը և որ ծառայությունում, բայց հավանաբար դա նշանակում է այն, ինչի մասին դուք խոսեցիք:
Այո, սկզբունքորեն դա կարող էր տրվել ինչ-որ մեկին։ Դա պարզապես կոդը էր, որը ես պարզապես փոխել եմ: Եվ բնական էր դա անել անմիջապես։ Սկզբունքորեն, թիմի հետ փորձը կիսելու գաղափարը լավ գաղափար է: Մենք անպայման կկիսենք Greenplum-ի առաջադրանքները մեր բաժնի բոլոր անդամների միջև:
Քանի որ խոսքը կրտսերների մասին է, այստեղ հարց է ծագում. Անձը որոշել է ստեղծել առաջին կոմիտեն Պոստգրեսում։ Ի՞նչ պետք է նա անի առաջին պարտավորությունը կատարելու համար:
Սա հետաքրքիր հարց է. «Ինչի՞ց սկսել»: Սովորաբար բավական դժվար է սկսել ինչ-որ բան միջուկում: Postgres-ում, օրինակ, կա անելիքների ցուցակ: Բայց իրականում սա թերթիկ է, թե ինչ են փորձել անել, բայց չի հաջողվել։ Սրանք բարդ բաներ են։ Եվ սովորաբար դուք կարող եք գտնել որոշ օգտակար ծառայություններ էկոհամակարգում, որոշ ընդարձակումներ, որոնք կարող են բարելավվել, որոնք ավելի քիչ ուշադրություն են գրավում միջուկի մշակողների կողմից: Եվ, համապատասխանաբար, այնտեղ աճի համար ավելի շատ կետեր կան։ Google Summer of code ծրագրում ամեն տարի postgres համայնքը առաջ է քաշում բազմաթիվ տարբեր թեմաներ, որոնց կարելի է անդրադառնալ: Այս տարի ունեինք, կարծեմ, երեք աշակերտ։ Մեկը նույնիսկ WAL-G-ում գրել է Yandex-ի համար կարևոր թեմաներ: Greenplum-ում ամեն ինչ ավելի պարզ է, քան Postgres համայնքում, քանի որ Greenplum-ի հաքերները շատ լավ են վերաբերվում ձգման հարցումներին և սկսում են անմիջապես վերանայել: Postgres-ին կարկատել ուղարկելը ամիսների խնդիր է, բայց Greenplum-ը կգա մեկ օրից և կտեսնի, թե ինչ եք արել: Ուրիշ բան, որ Greenplum-ին անհրաժեշտ է լուծել ընթացիկ խնդիրները։ Greenplum-ը լայնորեն չի օգտագործվում, ուստի ձեր խնդիրը գտնելը բավականին դժվար է: Եվ առաջին հերթին պետք է խնդիրներ լուծել, իհարկե։
Source: www.habr.com