Ապրիլին Avito-ի ինժեներները հավաքվեցին առցանց հանդիպումների ClickHouse-ի գլխավոր ծրագրավորող Ալեքսեյ Միլովիդովի և Կիրիլ Շվակովի՝ Golang-ի ծրագրավորող Integros-ի հետ: Մենք քննարկեցինք, թե ինչպես ենք օգտագործում տվյալների բազայի կառավարման համակարգը և ինչ դժվարությունների ենք հանդիպում:
Հանդիպման հիման վրա մենք հավաքել ենք հոդված՝ փորձագետների պատասխաններով մեր և հանդիսատեսի հարցերին կրկնօրինակումների, տվյալների փոփոխման, արտաքին բառարանների, Golang դրայվերի և ClickHouse տարբերակների թարմացման վերաբերյալ: Այն կարող է օգտակար լինել ծրագրավորողների համար, ովքեր արդեն ակտիվորեն աշխատում են Yandex DBMS-ի հետ և հետաքրքրված են դրա ներկայով և ապագայով: Լռելյայն պատասխանները Ալեքսեյ Միլովիդովն է, եթե այլ բան գրված չէ։
Զգույշ եղեք, կտրվածքի տակ շատ տեքստ կա։ Հուսով ենք, որ հարցերով բովանդակությունը կօգնի ձեզ կողմնորոշվել:
Պարունակություն
Եթե չեք ցանկանում կարդալ տեքստը, կարող եք դիտել հավաքների ձայնագրությունը . Ժամային կոդերը՝ տեսանյութի առաջին մեկնաբանության մեջ։
ClickHouse-ը անընդհատ թարմացվում է, բայց մեր տվյալները՝ ոչ: Ի՞նչ անել դրա հետ կապված:
ClickHouse-ը մշտապես թարմացվում է, և մեր տվյալները, որոնք օպտիմիզացվել են վերջնական մշակված, չեն թարմացվում և պահուստային պատճենում են:
Ենթադրենք, ինչ-որ խնդիր ունեինք, և տվյալները կորել էին։ Մենք որոշեցինք վերականգնել, և պարզվեց, որ հին բաժանմունքները, որոնք պահվում են պահեստային սերվերների վրա, շատ են տարբերվում ClickHouse-ի ներկայումս օգտագործվող տարբերակից։ Ի՞նչ անել նման իրավիճակում, և արդյոք դա հնարավոր է:
Իրավիճակը, երբ դուք վերականգնել եք տվյալները հին ձևաչափով կրկնօրինակից, բայց այն չի միանում նոր տարբերակին, անհնար է: Մենք համոզվում ենք, որ ClickHouse-ում տվյալների ձևաչափը միշտ մնում է հետհամատեղելի: Սա շատ ավելի կարևոր է, քան ֆունկցիոնալության հետամնաց համատեղելիությունը, եթե փոխվել է հազվադեպ օգտագործվող որոշ ֆունկցիաների վարքագիծը: ClickHouse-ի նոր տարբերակը միշտ պետք է կարողանա կարդալ սկավառակի վրա պահվող տվյալները: Սա է օրենքը։
Որո՞նք են ClickHouse-ից տվյալների կրկնօրինակման ներկայիս լավագույն փորձը:
Ինչպե՞ս կրկնօրինակումներ անել՝ հաշվի առնելով, որ մենք ունենք օպտիմիզացված վերջնական գործառնություններ, հսկայական տերաբայթ տվյալների բազա և տվյալներ, որոնք թարմացվում են, ասենք, վերջին երեք օրվա ընթացքում, և հետո դրա հետ որևէ ընթացակարգ չի կատարվում։
Մենք կարող ենք մեր լուծումը պատրաստել և բաշի վրա գրել. հավաքեք այս պահուստային պատճենները այսինչ ձևով: Միգուցե ինչ-որ բան հենելու կարիք չկա, իսկ հեծանիվը վաղուց է հորինվել։
Սկսենք լավագույն փորձից: Իմ գործընկերները միշտ խորհուրդ են տալիս, ի պատասխան կրկնօրինակումների մասին հարցերի, հիշեցնել Yandex.Cloud ծառայության մասին, որտեղ այս խնդիրն արդեն լուծված է։ Այսպիսով, հնարավորության դեպքում օգտագործեք այն:
Չկա ամբողջական լուծում կրկնօրինակումների համար, հարյուր տոկոսով ներկառուցված ClickHouse-ում: Կան որոշ բլանկներ, որոնք կարող են օգտագործվել: Ամբողջական լուծում ստանալու համար դուք կամ պետք է ձեռքով մի փոքր շտկեք, կամ ստեղծեք փաթաթաներ սցենարների տեսքով:
Ես կսկսեմ ամենապարզ լուծումներից և կավարտեմ ամենաբարդ լուծումներով՝ կախված տվյալների ծավալից և կլաստերի չափից: Որքան մեծ է կլաստերը, այնքան ավելի բարդ է լուծումը:
Եթե տվյալների հետ աղյուսակը զբաղեցնում է ընդամենը մի քանի գիգաբայթ, կրկնօրինակում կարելի է անել այսպես.
- Պահպանել աղյուսակի սահմանումը, այսինքն՝ մետատվյալները - ցույց տալ, ստեղծել աղյուսակ.
- Կատարեք աղբավայր՝ օգտագործելով ClickHouse հաճախորդը. ընտրել * սեղանից ներկայացնել. Լռելյայն դուք կստանաք TabSeparated ձևաչափով ֆայլ: Եթե ցանկանում եք ավելի արդյունավետ լինել, կարող եք դա անել Native ձևաչափով:
Եթե տվյալների քանակն ավելի մեծ է, ապա կրկնօրինակումն ավելի շատ ժամանակ և շատ տարածություն կխլի: Սա կոչվում է տրամաբանական կրկնօրինակում, այն կապված չէ ClickHouse տվյալների ձևաչափի հետ: Եթե դա այդպես է, ապա որպես վերջին միջոց կարող եք վերցնել կրկնօրինակում և վերբեռնել այն MySQL՝ վերականգնման համար։
Ավելի առաջադեմ դեպքերի համար ClickHouse-ն ունի ներկառուցված հնարավորություն՝ ստեղծելու միջնորմների պատկերը տեղական ֆայլային համակարգում: Այս հատկությունը հասանելի է որպես հարցում փոխել սեղանի սառեցման միջնորմը. Կամ պարզապես փոխել սեղանի սառեցումը - սա ամբողջ աղյուսակի պատկերն է:
Պատկերը կստեղծվի հետևողականորեն մեկ աղյուսակի համար մեկ բեկորի վրա, այսինքն՝ անհնար է այս կերպ ստեղծել ամբողջ կլաստերի հետևողական պատկերը: Բայց առաջադրանքների մեծ մասի համար նման կարիք չկա, և բավական է կատարել հարցումը յուրաքանչյուր բեկորի վրա և ստանալ հետևողական պատկեր: Այն ստեղծվում է կոշտ հղումների տեսքով և, հետևաբար, լրացուցիչ տեղ չի զբաղեցնում: Այնուհետև դուք պատճենում եք այս նկարը պահուստային սերվերին կամ պահեստին, որն օգտագործում եք կրկնօրինակումների համար:
Նման կրկնօրինակի վերականգնումը բավականին հեշտ է: Նախ, ստեղծեք աղյուսակներ՝ օգտագործելով առկա աղյուսակների սահմանումները: Հաջորդը, պատճենեք միջնորմների պահպանված նկարները Directory-Detached-ում այս աղյուսակների համար և գործարկեք հարցումը կցել միջնորմ. Այս լուծումը բավականին հարմար է տվյալների ամենալուրջ ծավալների համար:
Երբեմն ձեզ ավելի սառը բան է պետք. այն դեպքերում, երբ դուք ունեք տասնյակ կամ նույնիսկ հարյուրավոր տերաբայթ յուրաքանչյուր սերվերի վրա և հարյուրավոր սերվերներ: Այստեղ կա լուծում, որը ես վերցրել եմ Yandex.Metrica-ի իմ գործընկերներից: Բոլորին խորհուրդ չէի տա՝ կարդացեք և ինքներդ որոշեք՝ հարմար է, թե ոչ։
Նախ անհրաժեշտ է ստեղծել մի քանի սերվերներ մեծ սկավառակի դարակներով: Հաջորդը, այս սերվերների վրա, բարձրացրեք մի քանի ClickHouse սերվերներ և կարգավորեք դրանք այնպես, որ նրանք աշխատեն որպես նույն բեկորների մեկ այլ կրկնօրինակ: Եվ այնուհետև օգտագործեք ֆայլային համակարգ կամ ինչ-որ գործիք այս սերվերների վրա, որը թույլ է տալիս ստեղծել նկարներ: Այստեղ երկու տարբերակ կա. Առաջին տարբերակը LVM snapshots-ն է, երկրորդը՝ ZFS-ը Linux-ում։
Դրանից հետո ամեն օր պետք է նկար ստեղծեք, այն կստիպի և որոշ տեղ կզբաղեցնի: Բնականաբար, եթե տվյալները փոխվեն, ժամանակի ընթացքում տարածության քանակը կավելանա: Այս լուսանկարը կարող է ցանկացած պահի հանվել և վերականգնվել տվյալները, նման տարօրինակ լուծում: Բացի այդ, մենք նաև պետք է սահմանափակենք այս կրկնօրինակները կազմաձևում, որպեսզի նրանք չփորձեն առաջնորդ դառնալ:
Հնարավո՞ր կլինի արդյոք լիսեռներում կրկնօրինակների վերահսկվող ուշացում կազմակերպել։
Այս տարի դուք նախատեսում եք լիսեռներ պատրաստել ClickHouse-ում: Հնարավո՞ր է արդյոք դրանցում կազմակերպել կրկնօրինակների վերահսկվող ուշացում։ Մենք կցանկանայինք օգտագործել այն՝ փոփոխություններով և այլ փոփոխություններով բացասական սցենարներից պաշտպանվելու համար:
Հնարավո՞ր է արդյոք ինչ-որ պտույտ կատարել փոփոխությունների համար: Օրինակ, գոյություն ունեցող լիսեռում վերցրեք և ասեք, որ մինչև այս պահը դուք կիրառում եք փոփոխությունները, և այս պահից դադարում եք փոփոխությունները կիրառել:
Եթե հրամանը եկավ մեր կլաստերին և կոտրեց այն, ապա մենք ունենք մեկ ժամ ուշացումով պայմանական կրկնօրինակ, որտեղ կարող ենք ասել, որ եկեք օգտագործենք այն տվյալ պահին, բայց վերջին տասը րոպեների ընթացքում փոփոխություններ չենք կիրառի դրա վրա:
Նախ՝ կրկնօրինակների վերահսկվող ուշացման մասին։ Նման խնդրանք եղավ օգտատերերի կողմից, և մենք խնդիր ստեղծեցինք Github-ում հետևյալ խնդրանքով. Ոչ ոք չի առաքել, և հարցը փակվել է։ Այնուամենայնիվ, դուք արդեն կարող եք ստանալ այս հնարավորությունը՝ կարգավորելով ClickHouse-ը: Ճիշտ է, միայն 20.3 տարբերակից սկսած։
ClickHouse-ը մշտապես իրականացնում է տվյալների միաձուլում ֆոնին: Երբ միաձուլումն ավարտվում է, տվյալների որոշակի փաթեթը փոխարինվում է ավելի մեծ կտորով: Միևնույն ժամանակ, նախկինում եղած տվյալների կտորները որոշ ժամանակ շարունակում են մնալ սկավառակի վրա:
Նախ, դրանք շարունակում են պահպանվել այնքան ժամանակ, քանի դեռ կան ընտրված հարցումներ, որոնք օգտագործում են դրանք՝ չարգելափակող գործողություն ապահովելու համար: Ընտրված հարցումները հեշտությամբ ընթերցվում են հին կտորներից:
Երկրորդ, կա նաև ժամանակային շեմ՝ հին տվյալների կտորները ութ րոպե ընկած են սկավառակի վրա: Այս ութ րոպեները կարող են հարմարեցվել և նույնիսկ վերածվել մեկ օրվա: Սա կարժենա սկավառակի տարածություն. կախված տվյալների հոսքից, պարզվում է, որ վերջին օրը տվյալները ոչ միայն կկրկնապատկվեն, այլև կարող են դառնալ հինգ անգամ ավելի: Բայց եթե լուրջ խնդիր կա, կարող եք դադարեցնել ClickHouse սերվերը և դասավորել ամեն ինչ:
Այժմ հարց է առաջանում, թե ինչպես է սա պաշտպանում փոփոխություններից: Այստեղ արժե ավելի խորը նայել, քանի որ ClickHouse-ի հին տարբերակներում փոփոխականն այնպես էր աշխատում, որ ուղղակիորեն փոխում էր կտորները: Որոշ ֆայլերով կա տվյալների մի կտոր, և մենք անում ենք, օրինակ. փոխել անկման սյունակը. Այնուհետև այս սյունակը ֆիզիկապես հեռացվում է բոլոր կտորներից:
Բայց սկսած 20.3 տարբերակից, փոփոխության մեխանիզմն ամբողջությամբ փոխվել է, և այժմ տվյալների կտորները միշտ անփոփոխ են: Նրանք բոլորովին չեն փոխվում. փոփոխություններն այժմ աշխատում են մոտավորապես նույն կերպ, ինչ միաձուլումները: Տեղում կտորը փոխարինելու փոխարեն մենք ստեղծում ենք նորը։ Նոր հատվածում չփոխված ֆայլերը դառնում են կոշտ հղումներ, և եթե մենք ջնջենք սյունակը, այն պարզապես կբացակայի նոր հատվածում: Հին կտորը լռելյայն կջնջվի ութ րոպե հետո, և այստեղ դուք կարող եք շտկել վերը նշված կարգավորումները:
Նույնը վերաբերում է այնպիսի փոփոխություններին, ինչպիսիք են մուտացիաները: Երբ դուք անում եք փոխել ջնջել կամ փոխել թարմացումը, այն չի փոխում կտորը, այլ ստեղծում է նորը։ Եվ հետո ջնջում է հինը:
Իսկ եթե սեղանի կառուցվածքը փոխվել է:
Ինչպե՞ս վերականգնել հին սխեմայով ստեղծված կրկնօրինակը: Եվ երկրորդ հարցը վերաբերում է snapshots-ի և ֆայլային համակարգի գործիքների գործին: Արդյո՞ք Btrfs-ը լավն է այստեղ ZFS-ի փոխարեն Linux LVM-ում:
Եթե դու անես կցել միջնորմ բաժանումներ այլ կառուցվածքով, ապա ClickHouse-ը ձեզ կասի, որ դա հնարավոր չէ: Սա է լուծումը։ Առաջինը MergeTree տիպի ժամանակավոր աղյուսակ ստեղծելն է հին կառուցվածքով, այնտեղ կցել տվյալները՝ օգտագործելով կցումը և կատարել փոփոխական հարցում: Այնուհետև կարող եք կամ պատճենել կամ փոխանցել այս տվյալները և նորից կցել, կամ օգտագործել հարցումը փոխել սեղանի տեղափոխման միջնորմը.
Այժմ երկրորդ հարցն այն է, թե արդյոք Btrfs-ը կարելի է օգտագործել: Սկսելու համար, եթե դուք ունեք LVM, ապա LVM snapshot-ները բավական են, և ֆայլային համակարգը կարող է լինել ext4, դա նշանակություն չունի: Btrts-ի հետ ամեն ինչ կախված է այն օգտագործելու ձեր փորձից: Սա հասուն ֆայլային համակարգ է, բայց դեռ որոշ կասկածներ կան այն մասին, թե ինչպես ամեն ինչ գործնականում կաշխատի որոշակի սցենարում: Ես խորհուրդ չէի տա օգտագործել սա, քանի դեռ արտադրության մեջ չունեք Btrfs:
Որո՞նք են տվյալների վերափոխման ներկայիս լավագույն փորձը:
Վերափոխման խնդիրը բարդ է և բազմակողմանի: Այստեղ մի քանի հնարավոր պատասխաններ կան: Դուք կարող եք գնալ մի կողմից և ասել սա. ClickHouse-ը ներկառուցված ռեշարդինգի հատկություն չունի: Բայց ես վախենում եմ, որ այս պատասխանը ոչ մեկին չի սազում: Հետևաբար, դուք կարող եք գնալ մյուս կողմից և ասել, որ ClickHouse-ը տվյալների վերամշակման բազմաթիվ եղանակներ ունի:
Եթե կլաստերի տարածքը սպառվում է կամ այն չի կարողանում հաղթահարել բեռը, դուք ավելացնում եք նոր սերվերներ: Բայց այս սերվերները լռելյայն դատարկ են, դրանց վրա տվյալներ չկան, բեռ չկա։ Դուք պետք է վերադասավորեք տվյալները այնպես, որ դրանք հավասարապես տարածվեն նոր, ավելի մեծ կլաստերի վրա:
Առաջին ճանապարհը դա կարելի է անել, դա բաժանումների մի մասը պատճենելն է նոր սերվերների վրա՝ օգտագործելով հարցումը փոփոխել սեղանի բեռնման միջնորմը. Օրինակ, դուք բաժանումներ ունեիք ըստ ամիսների, և վերցնում եք 2017 թվականի առաջին ամիսը և պատճենում այն նոր սերվերի վրա, այնուհետև երրորդ ամիսը պատճենում եք որևէ այլ նոր սերվերի վրա: Եվ դուք դա անում եք այնքան ժամանակ, մինչև այն դառնա քիչ թե շատ հավասար:
Փոխանցումը կարող է իրականացվել միայն այն միջնորմների համար, որոնք ձայնագրման ընթացքում չեն փոխվում: Թարմ միջնորմների համար ձայնագրությունը պետք է անջատվի, քանի որ դրանց փոխանցումը ատոմային չէ: Հակառակ դեպքում, դուք կունենաք կրկնօրինակներ կամ տվյալների բացեր: Այնուամենայնիվ, այս մեթոդը գործնական է և գործում է բավականին արդյունավետ: Պատրաստի սեղմված միջնորմները փոխանցվում են ցանցով, այսինքն՝ տվյալները չեն սեղմվում կամ վերակոդավորվում։
Այս մեթոդը ունի մեկ թերություն, և դա կախված է բեկորային սխեմայից, արդյոք դուք գրավադրվել եք այս սխեմայով, ինչ բաշխման բանալի եք ունեցել: Ձեր օրինակում չափումների դեպքի համար, փոխանակման բանալին ուղու հեշն է: Երբ ընտրում եք Բաշխված աղյուսակը, այն միանգամից անցնում է կլաստերի բոլոր բեկորներին և այնտեղից վերցնում տվյալներ:
Սա նշանակում է, որ իրականում ձեզ համար նշանակություն չունի, թե որ բեկորի վրա ինչ տվյալներ են հայտնվել: Հիմնական բանն այն է, որ մեկ ճանապարհի տվյալները ավարտվում են մեկ բեկորի վրա, բայց որն է կարևոր: Այս դեպքում պատրաստի միջնորմների փոխանցումը կատարյալ է, քանի որ ընտրված հարցումներով դուք նույնպես կստանաք ամբողջական տվյալներ՝ անկախ նրանից, թե նախքան թարմացումը, թե դրանից հետո, սխեման իրականում նշանակություն չունի:
Բայց կան դեպքեր, որոնք ավելի բարդ են։ Եթե կիրառման տրամաբանության մակարդակում դուք ապավինում եք հատուկ բեկորային սխեմայի, որ այս հաճախորդը գտնվում է այս կամ այն բեկորի վրա, և հարցումը կարող է ուղարկվել անմիջապես այնտեղ, և ոչ թե Բաշխված աղյուսակին: Կամ դուք օգտագործում եք ClickHouse-ի բավականին վերջին տարբերակը և միացրել եք կարգավորումը օպտիմիզացնել բաց թողնել չօգտագործված բեկորները. Այս դեպքում, ընտրելով հարցման ժամանակ, կվերլուծվի որտեղ հատվածի արտահայտությունը և կհաշվարկվի, թե որ բեկորները պետք է օգտագործվեն ըստ հղկման սխեմայի։ Սա աշխատում է պայմանով, որ տվյալները բաժանված են հենց այս բաժանման սխեմայի համաձայն: Եթե դրանք ձեռքով վերադասավորել եք, համապատասխանությունը կարող է փոխվել:
Այսպիսով, սա թիվ մեկ մեթոդն է: Եվ ես սպասում եմ ձեր պատասխանին, արդյոք մեթոդը հարմար է, թե եկեք առաջ շարժվենք:
Վլադիմիր Կոլոբաև, առաջատար համակարգի ադմինիստրատոր Avito-ումԱլեքսեյ, ձեր նշած մեթոդը այնքան էլ լավ չի աշխատում, երբ պետք է բեռը տարածել, ներառյալ կարդալը: Մենք կարող ենք վերցնել մի բաժանում, որը ամսական է և կարող է նախորդ ամիսը տանել մեկ այլ հանգույց, բայց երբ հարցումը գալիս է այս տվյալների համար, մենք միայն այն կբեռնենք: Բայց մենք կցանկանայինք բեռնել ամբողջ կլաստերը, քանի որ հակառակ դեպքում որոշ ժամանակ ընթերցման ամբողջ բեռը կմշակվի երկու բեկորներով:
Ալեքսեյ Միլովիդով. Պատասխանն այստեղ տարօրինակ է. այո, դա վատ է, բայց դա կարող է աշխատել: Ես հստակ կբացատրեմ, թե ինչպես: Արժե դիտարկել բեռնվածության սցենարը, որը գալիս է ձեր տվյալների հետևում: Եթե սա մոնիտորինգի տվյալ է, ապա գրեթե վստահաբար կարող ենք ասել, որ հարցումների ճնշող մեծամասնությունը թարմ տվյալների համար է:
Դուք տեղադրել եք նոր սերվերներ, տեղափոխել եք հին միջնորմներ, բայց նաև փոխել եք թարմ տվյալների գրանցման եղանակը: Եվ թարմ տվյալները կտարածվեն ողջ կլաստերի վրա: Այսպիսով, ընդամենը հինգ րոպեից հետո վերջին հինգ րոպեների հարցումները հավասարապես կբեռնեն կլաստերը, իսկ մեկ օր հետո XNUMX ժամվա հարցումները հավասարապես կբեռնեն կլաստերը: Իսկ նախորդ ամսվա հարցումները, ցավոք, կուղղվեն միայն կլաստերային սերվերների մի մասին։
Բայց հաճախ 2019 թվականի փետրվարի համար հատուկ հարցումներ չեք ունենա։ Ամենայն հավանականությամբ, եթե հարցումները մտնեն 2019 թվական, ապա դրանք կլինեն ամբողջ 2019 թվականի համար՝ մեծ ժամանակահատվածի համար, և ոչ թե ինչ-որ փոքր միջակայքի համար: Եվ նման հարցումները նաև կկարողանան հավասարաչափ բեռնել կլաստերը: Բայց ընդհանուր առմամբ, ձեր դիտողությունը միանգամայն ճիշտ է, որ սա ժամանակավոր լուծում է, որը ամբողջությամբ չի տարածում տվյալները։
Հարցին պատասխանելու համար ևս մի քանի կետ ունեմ. Դրանցից մեկն այն մասին է, թե ինչպես սկզբնական շրջանում նախագծել բեկորային սխեման, որպեսզի կրկնակի փոխանակումը ավելի քիչ ցավ պատճառի: Սա միշտ չէ, որ հնարավոր է:
Օրինակ, դուք ունեք մոնիտորինգի տվյալներ: Մոնիտորինգի տվյալները աճում են երեք պատճառով. Առաջինը պատմական տվյալների կուտակումն է։ Երկրորդը երթեւեկության աճն է։ Եվ երրորդը մոնիտորինգի ենթակա իրերի քանակի ավելացումն է։ Կան նոր միկրոծառայություններ և չափումներ, որոնք պետք է պահպանվեն:
Հնարավոր է, որ դրանցից ամենամեծ աճը կապված է երրորդ պատճառի՝ մոնիտորինգի կիրառման ավելացման հետ։ Եվ այս դեպքում արժե դիտարկել բեռի բնույթը, որոնք են ընտրված հիմնական հարցումները: Հիմնական ընտրված հարցումները, ամենայն հավանականությամբ, հիմնված կլինեն չափումների որոշ ենթաբազմության վրա:
Օրինակ, պրոցեսորի օգտագործումը որոշ սերվերների վրա ինչ-որ ծառայության կողմից: Ստացվում է, որ կա ստեղների որոշակի ենթախումբ, որոնցով դուք ստանում եք այս տվյալները։ Եվ այս տվյալների հարցում ինքնին, ամենայն հավանականությամբ, բավականին պարզ է և ավարտվում է տասնյակ միլիվայրկյանների ընթացքում: Օգտագործվում է մոնիտորինգի ծառայությունների և վահանակների համար: Հուսով եմ, որ սա ճիշտ եմ հասկանում:
Վլադիմիր Կոլոբաև. Փաստն այն է, որ մենք շատ հաճախ ենք դիմում պատմական տվյալներին, քանի որ իրական ժամանակում համեմատում ենք ներկա իրավիճակը պատմականի հետ։ Եվ մեզ համար կարևոր է արագ մուտք ունենալ մեծ քանակությամբ տվյալների, և ClickHouse-ը հիանալի աշխատանք է կատարում այս հարցում:
Դուք միանգամայն իրավացի եք, մենք ընթերցված հարցումների մեծ մասը զգում ենք վերջին օրվա ընթացքում, ինչպես ցանկացած մոնիտորինգի համակարգ: Բայց միևնույն ժամանակ պատմական տվյալների ծանրաբեռնվածությունը նույնպես բավականին մեծ է։ Դա հիմնականում ահազանգման համակարգից է, որը շրջում է ամեն երեսուն վայրկյանը մեկ և ClickHouse-ին ասում. «Տվեք ինձ վերջին վեց շաբաթվա տվյալները: Հիմա ստեղծեք ինձ ինչ-որ շարժվող միջին, և եկեք համեմատենք ներկայիս արժեքը պատմականի հետ»:
Ես կցանկանայի ասել, որ նման շատ վերջին հարցումների համար մենք ունենք ևս մեկ փոքր աղյուսակ, որտեղ մենք պահում ենք ընդամենը երկու օրվա տվյալներ, և հիմնական հարցումները թռչում են դրան: Մենք միայն մեծ պատմական հարցումներ ենք ուղարկում մեծ բեկորային սեղանին:
Ալեքսեյ Միլովիդով. Ցավոք, պարզվում է, որ այն վատ կիրառելի է ձեր սցենարի համար, բայց ես ձեզ կասեմ երկու վատ և բարդ բեկորային սխեմաների նկարագրությունը, որոնք կարիք չունեն օգտագործելու, բայց որոնք օգտագործվում են իմ ընկերների ծառայության մեջ:
Yandex.Metrica իրադարձությունների հետ կա հիմնական կլաստեր: Իրադարձությունները էջերի դիտումներն են, սեղմումները և փոխարկումները: Հարցումների մեծ մասը գնում է կոնկրետ կայք: Դու բացում ես Yandex.Metrica ծառայությունը, ունես կայք՝ avito.ru, գնում ես ռեպորտաժին, և քո կայքի համար հարցում է արվում։
Բայց կան այլ խնդրանքներ՝ վերլուծական և գլոբալ, որոնք արվում են ներքին վերլուծաբանների կողմից։ Ամեն դեպքում, ես նշում եմ, որ ներքին վերլուծաբանները հարցումներ են անում միայն Yandex-ի ծառայությունների համար։ Բայց, այնուամենայնիվ, նույնիսկ Yandex ծառայությունները զբաղեցնում են բոլոր տվյալների զգալի մասը: Սրանք պահանջներ են ոչ թե կոնկրետ հաշվիչների, այլ ավելի լայն զտման համար:
Ինչպե՞ս կազմակերպել տվյալները այնպես, որ ամեն ինչ արդյունավետ աշխատի մեկ հաշվիչի, ինչպես նաև գլոբալ հարցումների համար: Մեկ այլ դժվարություն այն է, որ ClickHouse-ում Metrics կլաստերի հարցումների թիվը վայրկյանում մի քանի հազար է: Միևնույն ժամանակ, մեկ ClickHouse սերվերը չի կարող կարգավորել ոչ տրիվիալ հարցումները, օրինակ՝ վայրկյանում մի քանի հազար։
Կլաստերի չափը վեց հարյուր բան սերվեր է: Եթե դուք պարզապես քաշեք Բաշխված աղյուսակը այս կլաստերի վրա և ուղարկեք մի քանի հազար հարցումներ այնտեղ, դա ավելի վատ կլինի, քան դրանք մեկ սերվեր ուղարկելը: Մյուս կողմից, այն տարբերակը, որ տվյալները հավասարաչափ տարածվեն, և մենք գնանք և պահանջենք բոլոր սերվերներից, անմիջապես մերժվում է:
Կա մի տարբերակ, որը տրամագծորեն հակառակ է. Պատկերացրեք, եթե մենք տվյալները բաժանենք կայքերում, և մեկ կայքի հարցումը գնվի մեկ բեկորի: Այժմ կլաստերը կկարողանա կարգավորել տասը հազար հարցումներ վայրկյանում, բայց մեկ բեկորի վրա ցանկացած հարցում կաշխատի չափազանց դանդաղ: Այն այլևս չի ծավալվի թողունակության առումով: Հատկապես եթե սա avito.ru կայքն է: Գաղտնիքը չեմ բացահայտի, եթե ասեմ, որ Avito-ն RuNet-ի ամենաշատ այցելվող կայքերից է։ Եվ այն մեկ բեկորի վրա մշակելը խելագարություն կլինի։
Հետեւաբար, բեկորային սխեման նախագծված է ավելի խորամանկ ձեւով: Ամբողջ կլաստերը բաժանված է մի շարք կլաստերների, որոնք մենք անվանում ենք շերտեր։ Յուրաքանչյուր կլաստեր պարունակում է մեկ տասնյակից մինչև մի քանի տասնյակ բեկորներ: Ընդհանուր առմամբ կան երեսունինը այդպիսի կլաստերներ։
Ինչպե՞ս է այս ամենը ծավալվում: Կլաստերների թիվը չի փոխվում. ինչպես մի քանի տարի առաջ էր երեսունինը, այդպես էլ մնում է: Բայց դրանցից յուրաքանչյուրի ներսում մենք աստիճանաբար ավելացնում ենք բեկորների քանակը, երբ կուտակում ենք տվյալներ: Իսկ sharding-ի սխեման ամբողջությամբ այսպիսին է՝ այս կլաստերները բաժանված են կայքերի, և որպեսզի հասկանանք, թե որ վեբկայքը որ կլաստերում է, օգտագործվում է MySQL-ում առանձին մետաբազա։ Մեկ կայք՝ մեկ կլաստերի վրա: Եվ դրա ներսում փոխանակումը տեղի է ունենում ըստ այցելուների ID-ների:
Ձայնագրելիս դրանք բաժանում ենք այցելուի ID-ի բաժանման մնացորդի վրա։ Բայց երբ ավելացնում ենք նոր բեկոր, բեկորների սխեման փոխվում է, մենք շարունակում ենք բաժանել, բայց բաժանման մնացորդը մեկ այլ թվի վրա: Սա նշանակում է, որ մեկ այցելու արդեն գտնվում է մի քանի սերվերների վրա, և դուք չեք կարող հույս դնել դրա վրա: Սա արվում է բացառապես ապահովելու համար, որ տվյալները ավելի լավ սեղմված են: Իսկ հարցումներ կատարելիս մենք անցնում ենք Distributed աղյուսակը, որը նայում է կլաստերին և մուտք է գործում տասնյակ սերվերներ։ Սա այնքան հիմար սխեմա է:
Բայց իմ պատմությունը կիսատ կմնա, եթե չասեմ, որ մենք հրաժարվել ենք այս սխեմայից։ Նոր սխեմայում մենք փոխեցինք ամեն ինչ և պատճենեցինք բոլոր տվյալները՝ օգտագործելով clickhouse-copier-ը:
Նոր սխեմայում բոլոր կայքերը բաժանված են երկու կատեգորիայի՝ մեծ և փոքր: Ես չգիտեմ, թե ինչպես է ընտրվել շեմը, բայց արդյունքն այն էր, որ մեծ կայքերը գրանցվում են մեկ կլաստերի վրա, որտեղ կան 120 բեկորներ՝ յուրաքանչյուրը երեք կրկնօրինակով, այսինքն՝ 360 սերվեր: Իսկ շարդինգի սխեման այնպիսին է, որ ցանկացած հարցում միանգամից գնում է բոլոր բեկորներին: Եթե այժմ Yandex.Metrica-ում բացեք հաշվետվության որևէ էջ avito.ru-ի համար, ապա հարցումը կուղարկվի 120 սերվեր: RuNet-ում քիչ մեծ կայքեր կան: Իսկ խնդրանքները վայրկյանում հազար չեն, բայց հարյուրից էլ պակաս։ Այս ամենը հանգիստ ծամում է Distributed աղյուսակը, որը նրանցից յուրաքանչյուրը մշակում է 120 սերվերով։
Իսկ երկրորդ կլաստերը փոքր կայքերի համար է: Ահա բեկման սխեման՝ հիմնված կայքի ID-ի վրա, և յուրաքանչյուր հարցում գնում է ուղիղ մեկ բեկորի:
ClickHouse-ն ունի clickhouse-պատճենահանող սարք: Կպատմե՞ք նրա մասին:
Անմիջապես կասեմ, որ այս լուծումն ավելի ծանրաբեռնված է և որոշ չափով պակաս արդյունավետ: Առավելությունն այն է, որ այն ամբողջությամբ քսում է տվյալները ձեր նշած օրինաչափության համաձայն: Բայց կոմունալ ծրագրի թերությունն այն է, որ այն ընդհանրապես չի վերականգնվում: Այն պատճենում է տվյալները մեկ կլաստերային սխեմայից մյուս կլաստերային սխեմայի վրա:
Սա նշանակում է, որ այն գործելու համար դուք պետք է ունենաք երկու կլաստեր: Նրանք կարող են տեղակայվել նույն սերվերների վրա, բայց, այնուամենայնիվ, տվյալները չեն տեղափոխվի աստիճանաբար, այլ կպատճենվեն։
Օրինակ՝ չորս սերվեր կար, հիմա ութն է։ Դուք ստեղծում եք նոր Distributed աղյուսակ բոլոր սերվերների վրա, նոր տեղական աղյուսակներ և գործարկում եք clickhouse-copier-ը՝ դրանում նշելով աշխատանքային սխեման, որը այն պետք է կարդա այնտեղից, ընդունի նոր փոխանակման սխեման և փոխանցի տվյալները այնտեղ: Իսկ հին սերվերների վրա ձեզ հարկավոր կլինի մեկուկես անգամ ավելի շատ տարածք, քան կա հիմա, քանի որ հին տվյալները պետք է մնան դրանց վրա, և նույն հին տվյալների կեսը կհասնի դրանց վրա: Եթե նախապես մտածել եք, որ տվյալները պետք է վերանայվեն, և տեղ կա, ապա այս մեթոդը հարմար է:
Ինչպե՞ս է աշխատում clickhouse-copier-ը ներսում: Այն ամբողջ աշխատանքը բաժանում է առաջադրանքների մի շարքի՝ մեկ աղյուսակի մեկ բաժանումը մեկ բեկորի վրա մշակելու համար: Այս բոլոր առաջադրանքները կարող են կատարվել զուգահեռաբար, և clickhouse-copier-ը կարող է գործարկվել տարբեր մեքենաների վրա մի քանի օրինակով, բայց այն, ինչ անում է մեկ բաժանման համար, ոչ այլ ինչ է, քան ներդիրի ընտրություն: Տվյալները կարդացվում են, ապասեղմվում, վերաբաշխվում, հետո նորից սեղմվում, ինչ-որ տեղ գրվում և նորից տեսակավորվում: Սա ավելի կոշտ որոշում է։
Դուք ունեիք մի փորձնական բան, որը կոչվում էր ռեշարդինգ: Ի՞նչ նրա հետ:
Դեռևս 2017-ին դուք ունեիք մի փորձնական բան, որը կոչվում էր resharding: ClickHouse-ում նույնիսկ տարբերակ կա: Ոնց հասկացա, չթափվեց։ Կարո՞ղ եք ասել, թե ինչու դա տեղի ունեցավ: Կարծես թե շատ տեղին է։
Ամբողջ խնդիրն այն է, որ եթե անհրաժեշտ է տեղում թարմացնել տվյալները, ապա դա ատոմային կերպով անելու համար պահանջվում է շատ բարդ համաժամացում: Երբ մենք սկսեցինք նայել, թե ինչպես է աշխատում այս համաժամացումը, պարզ դարձավ, որ կան հիմնարար խնդիրներ: Եվ այս հիմնարար խնդիրները ոչ միայն տեսական են, այլ անմիջապես սկսեցին իրենց գործնականում դրսևորել մի բանի տեսքով, որը կարելի է շատ պարզ բացատրել՝ ոչինչ չի ստացվում:
Հնարավո՞ր է միավորել տվյալների բոլոր մասերը, նախքան դրանք դանդաղ սկավառակներ տեղափոխելը:
Հարց TTL-ի մասին՝ միաձուլումների համատեքստում դանդաղ սկավառակի տեղափոխման տարբերակով: Կա՞ որևէ միջոց, բացի cron-ի միջոցով, բոլոր մասերը միավորելու մեկի մեջ, նախքան դրանք դանդաղ սկավառակներ տեղափոխելը:
Հարցի պատասխանը հնարավո՞ր է ինչ-որ կերպ ավտոմատ կերպով սոսնձել բոլոր կտորները մեկում, նախքան դրանք տեղափոխելը. ոչ: Չեմ կարծում, որ սա անհրաժեշտ է: Պետք չէ բոլոր մասերը միավորել մեկի մեջ, այլ պարզապես հույս դնել այն փաստի վրա, որ դրանք ավտոմատ կերպով կտեղափոխվեն դանդաղ սկավառակներ:
Տրանսֆերային կանոնների երկու չափանիշ ունենք. Առաջինն այնպես է, ինչպես լցված է։ Եթե ընթացիկ պահեստային մակարդակն ունի ազատ տարածության որոշակի տոկոսից պակաս, մենք ընտրում ենք մեկ կտոր և տեղափոխում այն ավելի դանդաղ պահեստ: Ավելի ճիշտ, ոչ թե ավելի դանդաղ, այլ հաջորդը, ինչպես դուք կարգավորում եք:
Երկրորդ չափանիշը չափն է: Խոսքը մեծ կտորների տեղափոխման մասին է: Դուք կարող եք կարգավորել շեմը՝ ըստ արագ սկավառակի ազատ տարածության, և տվյալները կփոխանցվեն ավտոմատ կերպով։
Ինչպե՞ս տեղափոխել ClickHouse-ի նոր տարբերակները, եթե նախապես համատեղելիությունը ստուգելու միջոց չկա:
Այս թեման պարբերաբար քննարկվում է հաշվի առնելով տարբեր վարկածներ, և դեռ. Որքանո՞վ է անվտանգ 19.11-ից 19.16-ի և, օրինակ, 19.16-ից 20.3-ի թարմացումը: Ո՞րն է նոր տարբերակներ տեղափոխելու լավագույն միջոցը՝ առանց նախապես ավազարկղում համատեղելիությունը ստուգելու հնարավորության:
Այստեղ կան մի քանի «ոսկե» կանոններ. Առաջին - . Այն մեծ է, բայց կան առանձին պարբերություններ հետընթաց անհամատեղելի փոփոխությունների մասին։ Մի վերաբերվեք այս կետերին որպես կարմիր դրոշի: Սրանք սովորաբար աննշան անհամատեղելիություններ են, որոնք ներառում են որոշ եզրային գործառույթներ, որոնք դուք, ամենայն հավանականությամբ, չեք օգտագործում:
Երկրորդ, եթե ավազարկղում համատեղելիությունը ստուգելու միջոց չկա, և դուք ցանկանում եք անմիջապես թարմացնել արտադրության մեջ, խորհուրդն այն է, որ ձեզ հարկավոր չէ դա անել: Նախ ստեղծեք ավազատուփ և փորձարկեք: Եթե չկա փորձարկման միջավայր, ապա դուք, ամենայն հավանականությամբ, չունեք շատ մեծ ընկերություն, ինչը նշանակում է, որ կարող եք պատճենել տվյալների մի մասը ձեր նոութբուքին և համոզվել, որ դրա վրա ամեն ինչ ճիշտ է աշխատում: Դուք նույնիսկ կարող եք տեղական մի քանի կրկնօրինակներ բարձրացնել ձեր մեքենայի վրա: Կամ կարող եք վերցնել նոր տարբերակ մոտակայքում և վերբեռնել որոշ տվյալներ, այսինքն՝ ստեղծել իմպրովիզացված թեստային միջավայր:
Մեկ այլ կանոն՝ տարբերակի թողարկումից հետո մեկ շաբաթ չթարմացնելը՝ արտադրության մեջ սխալներ հայտնաբերելու և հետագա արագ շտկումների պատճառով: Եկեք պարզենք ClickHouse տարբերակների համարակալումը, որպեսզի չշփոթվենք։
Կա 20.3.4 տարբերակը։ 20 թիվը ցույց է տալիս արտադրության տարեթիվը՝ 2020 թվական։ Ներսում եղածի տեսանկյունից սա նշանակություն չունի, ուստի մենք դրան ուշադրություն չենք դարձնի։ Հաջորդը - 20.3. Մենք ավելացնում ենք երկրորդ թիվը՝ այս դեպքում՝ 3-ը, ամեն անգամ, երբ թողարկում ենք նոր գործառույթներով թողարկում: Եթե ցանկանում ենք ինչ-որ հատկանիշ ավելացնել ClickHouse-ին, պետք է ավելացնենք այս թիվը։ Այսինքն՝ 20.4 տարբերակում ClickHouse-ն էլ ավելի լավ կաշխատի։ Երրորդ նիշը 20.3.4 է: Այստեղ 4-ը կարկատելների թողարկումների թիվն է, որոնցում մենք չենք ավելացրել նոր հնարավորություններ, այլ ուղղել ենք որոշ սխալներ: Իսկ 4-ը նշանակում է, որ մենք դա արել ենք չորս անգամ:
Մի կարծեք, որ սա սարսափելի բան է։ Սովորաբար օգտատերը կարող է տեղադրել վերջին տարբերակը, և այն կաշխատի առանց որևէ խնդիրների՝ տարեկան աշխատանքի ժամանակի հետ կապված: Բայց պատկերացրեք, որ bitmaps-ների մշակման ինչ-որ ֆունկցիայում, որն ավելացրել են մեր չինացի ընկերները, սերվերը խափանում է սխալ արգումենտներ փոխանցելիս։ Մենք պարտավոր ենք դա շտկել։ Մենք կթողարկենք նոր patch տարբերակը, և ClickHouse-ը կդառնա ավելի կայուն:
Եթե դուք ունեք ClickHouse-ը, որն աշխատում է արտադրության մեջ, և ClickHouse-ի նոր տարբերակը դուրս է գալիս լրացուցիչ հնարավորություններով, օրինակ՝ 20.4.1-ն առաջինն է, մի շտապեք այն արտադրել հենց առաջին օրը: Ինչու է դա ընդհանրապես անհրաժեշտ: Եթե դեռ չեք օգտագործում ClickHouse-ը, ապա կարող եք տեղադրել այն, և, ամենայն հավանականությամբ, ամեն ինչ լավ կլինի: Բայց եթե ClickHouse-ն արդեն կայուն է աշխատում, ապա հետևեք կարկատներին և թարմացումներին՝ տեսնելու, թե ինչ խնդիրներ ենք մենք ուղղում:
Կիրիլ Շվակով. Ես կցանկանայի մի փոքր ավելացնել թեստային միջավայրերի մասին: Բոլորը շատ են վախենում թեստային միջավայրերից և չգիտես ինչու կարծում են, որ եթե դուք ունեք շատ մեծ ClickHouse կլաստեր, ապա թեստային միջավայրը պետք է լինի ոչ պակաս կամ առնվազն տասն անգամ փոքր: Դա ամենևին էլ այդպես չէ։
Ես կարող եմ ձեզ իմ օրինակից ասել. Ես ունեմ նախագիծ, և կա ClickHouse-ը: Մեր թեստային միջավայրը հենց նրա համար է. սա Հեթցների փոքր վիրտուալ մեքենա է քսան եվրոյով, որտեղ բացարձակապես ամեն ինչ տեղադրված է: Դա անելու համար մենք ունենք ամբողջական ավտոմատացում Ansible-ում, և, հետևաբար, սկզբունքորեն տարբերություն չկա, թե ուր գնալ՝ ապարատային սերվերներ, թե՞ պարզապես տեղակայվել վիրտուալ մեքենաներում:
Ի՞նչ կարելի է անել: Լավ կլինի, որ ClickHouse-ի փաստաթղթերում օրինակ բերեք այն մասին, թե ինչպես կարելի է փոքրիկ կլաստեր տեղակայել ձեր սեփական տանը՝ Docker-ում, LXC-ում, գուցե ստեղծել Ansible գրքույկ, քանի որ տարբեր մարդիկ ունեն տարբեր տեղակայումներ: Սա շատ բան կպարզեցնի։ Երբ դուք վերցնում և տեղակայում եք կլաստերը հինգ րոպեում, շատ ավելի հեշտ է փորձել ինչ-որ բան պարզել: Սա շատ ավելի հարմար է, քանի որ արտադրական տարբերակի մեջ գլորվելը, որը դուք չեք փորձարկել, ճանապարհ է դեպի ոչ մի տեղ: Երբեմն այն աշխատում է, երբեմն էլ՝ ոչ: Եվ հետևաբար, հաջողության հույսը վատ է:
Մաքսիմ Կոտյակով, ավագ ինժեներ Ավիտո. Ես մի փոքր կավելացնեմ թեստային միջավայրերի մասին մի շարք խնդիրներից, որոնց բախվում են խոշոր ընկերությունները: Մենք ունենք ClickHouse-ի լիարժեք ընդունման կլաստեր, տվյալների սխեմաների և պարամետրերի առումով դա արտադրության մեջ եղածի ճշգրիտ պատճենն է: Այս կլաստերը տեղակայված է բավականին հնամաշ բեռնարկղերում՝ նվազագույն ռեսուրսներով: Մենք այնտեղ գրում ենք արտադրության տվյալների որոշակի տոկոս, բարեբախտաբար հնարավոր է կրկնօրինակել հոսքը Կաֆկայում։ Այնտեղ ամեն ինչ սինխրոնիզացված է և մասշտաբային՝ և՛ հզորության, և՛ հոսքի առումով, և, տեսականորեն, բոլոր մյուս բաները հավասար լինելով, այն պետք է իրեն պահի արտադրության պես՝ չափումների առումով: Այն ամենը, ինչ կարող է պայթուցիկ լինել, սկզբում գլորվում է այս տակդիրի վրա և թողնում այնտեղ մի քանի օր մինչև պատրաստ լինելը: Բայց բնականաբար, այս լուծումը թանկ է, դժվար և ունի ոչ զրոյական աջակցության ծախսեր:
Ալեքսեյ Միլովիդով. Ես ձեզ կասեմ, թե ինչպիսին է Yandex.Metrica-ի մեր ընկերների թեստային միջավայրը: Մի կլաստերն ուներ 600 կենտ սերվեր, մյուսը՝ 360, և կա երրորդ և մի քանի կլաստերներ։ Դրանցից մեկի փորձարկման միջավայրը պարզապես երկու բեկոր է՝ յուրաքանչյուրում երկու կրկնօրինակով: Ինչու՞ երկու բեկոր: Որպեսզի դու մենակ չես։ Եվ պետք է լինեն նաև կրկնօրինակներ: Պարզապես որոշակի նվազագույն գումար, որը դուք կարող եք թույլ տալ:
Այս թեստային միջավայրը թույլ է տալիս ստուգել՝ արդյոք ձեր հարցումներն աշխատում են, և արդյոք որևէ կարևոր բան կոտրված է: Բայց հաճախ բոլորովին այլ բնույթի խնդիրներ են առաջանում, երբ ամեն ինչ աշխատում է, բայց ծանրաբեռնվածության մեջ կան փոքր փոփոխություններ։
Մի օրինակ բերեմ. Մենք որոշեցինք տեղադրել ClickHouse-ի նոր տարբերակը: Այն տեղադրվել է թեստային միջավայրում, ավտոմատացված թեստերն ավարտվել են հենց Yandex.Metrica-ում, որոնք համեմատում են հին և նոր տարբերակի տվյալները՝ գործարկելով ամբողջ խողովակաշարը: Եվ, իհարկե, մեր CI-ի կանաչ թեստերը: Հակառակ դեպքում մենք նույնիսկ չէինք առաջարկի այս տարբերակը։
Ամեն ինչ լավ է. Մենք սկսում ենք անցնել արտադրության։ Ես հաղորդագրություն եմ ստանում, որ գրաֆիկների ծանրաբեռնվածությունը մի քանի անգամ ավելացել է: Մենք հետ ենք գլորում տարբերակը։ Ես նայում եմ գծապատկերին և տեսնում. բեռնվածությունը իրականում մի քանի անգամ ավելացել է թողարկման ընթացքում և հետ է նվազել, երբ դրանք դուրս են եկել: Հետո սկսեցինք հետ գլորել տարբերակը։ Իսկ բեռը նույն կերպ ավելացավ ու նույն կերպ հետ ընկավ։ Այսպիսով, եզրակացությունը հետևյալն է. բեռը մեծացել է դասավորության պատճառով, զարմանալի ոչինչ չկա:
Հետո դժվար էր համոզել գործընկերներին տեղադրել նոր տարբերակը։ Ես ասում եմ. «Լավ է, դուրս գցիր: Ձեր մատները խաչած պահեք, ամեն ինչ կաշխատի: Այժմ գրաֆիկների բեռը մեծացել է, բայց ամեն ինչ կարգին է։ Մնա այդտեղ." Ընդհանուր առմամբ, մենք դա արեցինք, և վերջ. տարբերակը թողարկվեց արտադրության համար: Բայց գրեթե յուրաքանչյուր դասավորության դեպքում նմանատիպ խնդիրներ են առաջանում:
Kill query-ը պետք է սպանի հարցումները, բայց դա չի անում: Ինչո՞ւ։
Մի օգտատեր, ինչ-որ վերլուծաբան, եկավ ինձ մոտ և ստեղծեց հարցում, որը դրեց իմ ClickHouse կլաստերը: Որոշ հանգույց կամ ամբողջ կլաստեր, կախված նրանից, թե որ կրկնօրինակը կամ բեկորն է գնացել հարցումը: Ես տեսնում եմ, որ այս սերվերի CPU-ի բոլոր ռեսուրսները դարակում են, ամեն ինչ կարմիր է: Միևնույն ժամանակ, ClickHouse-ն ինքն է պատասխանում հարցումներին։ Եվ ես գրում եմ. «Խնդրում եմ, ցույց տվեք ինձ, գործընթացի ցուցակը, թե ինչ խնդրանք է առաջացրել այս խելագարությունը»:
Ես գտնում եմ այս խնդրանքը և գրում եմ սպանել դրան: Եվ ես տեսնում եմ, որ ոչինչ չի կատարվում։ Իմ սերվերը դարակում է, ClickHouse-ը ինձ մի քանի հրաման է տալիս, ցույց է տալիս, որ սերվերը կենդանի է, և ամեն ինչ հիանալի է: Բայց ես դեգրադացիա ունեմ օգտատերերի բոլոր հարցումներում, դեգրադացիան սկսվում է ClickHouse-ի գրառումներից, և իմ սպանության հարցումը չի աշխատում: Ինչո՞ւ։ Ես կարծում էի, որ kill query-ը պետք է սպաներ հարցումները, բայց դա չի անում:
Հիմա բավականին տարօրինակ պատասխան կլինի. Բանն այն է, որ kill հարցումը չի սպանում հարցումները:
Kill query-ը ստուգում է մի փոքրիկ տուփ, որը կոչվում է «Ես ուզում եմ, որ այս հարցումը սպանվի»: Եվ հարցումն ինքնին նայում է այս դրոշին յուրաքանչյուր բլոկի մշակման ժամանակ: Եթե այն սահմանված է, հարցումը կդադարի գործել: Ստացվում է, որ ոչ ոք չի սպանում խնդրանքը, նա ինքը պետք է ամեն ինչ ստուգի և կանգ առնի։ Եվ սա պետք է աշխատի բոլոր այն դեպքերում, երբ հարցումը գտնվում է տվյալների բլոկների մշակման վիճակում: Այն կմշակի տվյալների հաջորդ բլոկը, կստուգի դրոշակը և կդադարեցնի:
Սա չի աշխատում այն դեպքերում, երբ հարցումն արգելափակված է ինչ-որ գործողության ժամանակ: Ճիշտ է, ամենայն հավանականությամբ, դա ձեր դեպքը չէ, քանի որ, ըստ ձեզ, այն օգտագործում է մեծ քանակությամբ սերվերային ռեսուրսներ։ Հնարավոր է, որ դա չաշխատի արտաքին տեսակավորման և որոշ այլ մանրամասների դեպքում։ Բայց ընդհանուր առմամբ դա չպետք է տեղի ունենա, դա սխալ է: Եվ միակ բանը, որ կարող եմ խորհուրդ տալ, ClickHouse-ի թարմացումն է:
Ինչպե՞ս հաշվարկել արձագանքման ժամանակը ընթերցման բեռի տակ:
Կա աղյուսակ, որը պահում է իրերի ագրեգատները՝ տարբեր հաշվիչներ: Տողերի թիվը մոտավորապես հարյուր միլիոն է։ Հնարավո՞ր է արդյոք հաշվել կանխատեսելի պատասխան ժամանակի վրա, եթե 1K RPS լցնեք 1K ապրանքների համար:
Դատելով համատեքստից՝ խոսքը ընթերցանության ծանրաբեռնվածության մասին է, քանի որ գրելու հետ կապված խնդիրներ չկան՝ կարելի է անգամ հազար, նույնիսկ հարյուր հազար, երբեմն էլ մի քանի միլիոն տող տեղադրել։
Ընթերցանության հարցումները շատ տարբեր են: Ընտրված 1-ում ClickHouse-ը կարող է վայրկյանում կատարել մոտ տասնյակ հազարավոր հարցումներ, այնպես որ նույնիսկ մեկ բանալու հարցումներն արդեն կպահանջեն որոշակի ռեսուրսներ: Եվ նման կետերի հարցումներն ավելի դժվար կլինեն, քան որոշ առանցքային արժեքների տվյալների բազաներում, քանի որ յուրաքանչյուր ընթերցման համար անհրաժեշտ է կարդալ տվյալների բլոկն ըստ ինդեքսների: Մեր ինդեքսը վերաբերում է ոչ թե յուրաքանչյուր գրառումին, այլ յուրաքանչյուր տիրույթին: Այսինքն, դուք ստիպված կլինեք կարդալ ամբողջ տիրույթը. սա լռելյայն 8192 տող է: Եվ դուք ստիպված կլինեք ապասեղմել սեղմված տվյալների բլոկը 64 ԿԲ-ից մինչև 1 ՄԲ: Սովորաբար, նման նպատակային հարցումները մի քանի միլիվայրկյան են պահանջում: Բայց սա ամենապարզ տարբերակն է։
Փորձենք պարզ թվաբանություն: Եթե մի քանի միլիվայրկյանները բազմապատկեք հազարով, կստանաք մի քանի վայրկյան: Կարծես անհնար է վայրկյանում հազար խնդրանքով հետևել, բայց իրականում դա հնարավոր է, քանի որ մենք ունենք մի քանի պրոցեսորային միջուկներ: Այսպիսով, սկզբունքորեն, ClickHouse-ը երբեմն կարող է պահել 1000 RPS, բայց կարճ խնդրանքների համար, հատուկ նպատակային:
Եթե Ձեզ անհրաժեշտ է չափել ClickHouse կլաստերը ըստ պարզ հարցումների քանակի, ապա ես խորհուրդ եմ տալիս ամենապարզ բանը՝ ավելացնել կրկնօրինակների քանակը և հարցումներ ուղարկել պատահական կրկնօրինակի: Եթե մեկ կրկնօրինակը վայրկյանում հինգ հարյուր հարցում է պահում, ինչը լիովին իրատեսական է, ապա երեք կրկնօրինակները կբավարարեն մեկուկես հազար:
Երբեմն, իհարկե, դուք կարող եք կարգավորել ClickHouse-ը առավելագույն քանակի կետերի ընթերցումների համար: Ի՞նչ է պետք սրա համար։ Առաջինը ինդեքսի հատիկությունը նվազեցնելն է: Այս դեպքում այն չպետք է կրճատվի մինչև մեկ, այլ այն հիմքով, որ ինդեքսում գրառումների թիվը կկազմի մի քանի միլիոն կամ տասնյակ միլիոններ մեկ սերվերի համար։ Եթե աղյուսակը ունի հարյուր միլիոն տող, ապա հատիկությունը կարող է սահմանվել 64-ի:
Դուք կարող եք նվազեցնել սեղմված բլոկի չափը: Դրա համար կան կարգավորումներ րոպե սեղմել բլոկի չափը, կոմպրեսի բլոկի առավելագույն չափը. Դրանք կարող են կրճատվել, վերալիցքավորվել տվյալների հետ, իսկ հետո նպատակային հարցումներն ավելի արագ կլինեն: Բայց այնուամենայնիվ, ClickHouse-ը բանալի-արժեքի տվյալների բազա չէ: Փոքր հարցումների մեծ քանակությունը բեռի հակապատկեր է:
Կիրիլ Շվակով. Խորհուրդ կտամ, եթե այնտեղ սովորական հաշիվներ լինեն։ Սա բավականին ստանդարտ իրավիճակ է, երբ ClickHouse-ը պահում է ինչ-որ հաշվիչ: Ես օգտատեր ունեմ, նա այսինչ երկրից է, և ինչ-որ երրորդ ոլորտից, և ես պետք է աստիճանաբար ինչ-որ բան ավելացնեմ։ Վերցրեք MySQL-ը, պատրաստեք յուրահատուկ բանալի՝ MySQL-ում դա կրկնօրինակ է, իսկ PostgreSQL-ում՝ կոնֆլիկտ, և ավելացրեք գումարած նշան: Սա շատ ավելի լավ կաշխատի:
Երբ դուք շատ տվյալներ չունեք, ClickHouse-ն օգտագործելն այնքան էլ իմաստ չունի: Կան կանոնավոր տվյալների բազաներ, և նրանք դա լավ են անում:
Ի՞նչ կարող եմ կսմթել ClickHouse-ում, որպեսզի ավելի շատ տվյալներ լինեն քեշում:
Եկեք պատկերացնենք մի իրավիճակ՝ սերվերներն ունեն 256 ԳԲ օպերատիվ հիշողություն, ամենօրյա ռեժիմում ClickHouse-ը տևում է մոտ 60-80 ԳԲ, պիկին՝ մինչև 130: կա՞ն ավելի քիչ ուղևորություններ դեպի սկավառակ:
Սովորաբար, օպերացիոն համակարգի էջերի քեշը դա լավ է անում: Եթե դուք պարզապես բացում եք վերևը, նայեք այնտեղ՝ քեշավորված կամ անվճար - այնտեղ նաև գրված է, թե որքան է պահված, ապա կնկատեք, որ ամբողջ ազատ հիշողությունն օգտագործվում է քեշի համար: Իսկ այս տվյալները կարդալիս դրանք կկարդան ոչ թե սկավառակից, այլ RAM-ից։ Միևնույն ժամանակ, կարող եմ ասել, որ քեշը արդյունավետ է օգտագործվում, քանի որ հենց սեղմված տվյալներն են պահվում:
Այնուամենայնիվ, եթե ցանկանում եք ավելի արագացնել որոշ պարզ հարցումներ, հնարավոր է միացնել քեշը ապասեղմված տվյալների մեջ ClickHouse-ի ներսում: Այն կոչվում է չսեղմված քեշ. Config.xml կազմաձևման ֆայլում սահմանեք չսեղմված քեշի չափը ձեր անհրաժեշտ արժեքին. խորհուրդ եմ տալիս ոչ ավելի, քան անվճար RAM-ի կեսը, քանի որ մնացածը կգտնվի էջի քեշի տակ:
Բացի այդ, կան երկու հարցումների մակարդակի կարգավորումներ: Առաջին կարգավորում - օգտագործել չսեղմված քեշը - ներառում է դրա օգտագործումը. Խորհուրդ է տրվում միացնել այն բոլոր հարցումների համար, բացառությամբ ծանր պահանջների, որոնք կարող են կարդալ բոլոր տվյալները և մաքրել քեշը: Իսկ երկրորդ պարամետրը նման է քեշը օգտագործելու տողերի առավելագույն քանակին: Այն ավտոմատ կերպով սահմանափակում է մեծ հարցումները, որպեսզի նրանք շրջանցեն քեշը:
Ինչպե՞ս կարող եմ կարգավորել storage_configuration-ը RAM-ում պահեստավորման համար:
Նոր ClickHouse փաստաթղթում ես կարդացի բաժինը, որը վերաբերում էր . Նկարագրությունը պարունակում է օրինակ արագ SSD-ով:
Հետաքրքիր է, թե ինչպես կարելի է նույն բանը կարգավորել ծավալային տաք հիշողության հետ: Եվ ևս մեկ հարց. Ինչպե՞ս է ընտրվածը աշխատում տվյալների այս կազմակերպության հետ, այն կարդա՞ ամբողջ հավաքածուն, թե՞ միայն այն, որը գտնվում է սկավառակի վրա, և արդյոք այս տվյալները սեղմված են հիշողության մեջ: Իսկ ինչպե՞ս է աշխատում prewhere բաժինը տվյալների նման կազմակերպության հետ:
Այս պարամետրը ազդում է տվյալների կտորների պահպանման վրա, և դրանց ձևաչափը որևէ կերպ չի փոխվում:
Եկեք ավելի սերտ նայենք:
Դուք կարող եք կարգավորել տվյալների պահպանումը RAM-ում: Այն ամենը, ինչ կազմաձևված է սկավառակի համար, նրա ճանապարհն է: Դուք ստեղծում եք tmpfs միջնորմ, որը տեղադրված է ֆայլային համակարգի ինչ-որ ուղու վրա: Դուք նշում եք այս ճանապարհը որպես ամենաթեժ բաժանման համար տվյալների պահպանման ուղի, տվյալների կտորները սկսում են հասնել և գրվել այնտեղ, ամեն ինչ լավ է:
Բայց ես խորհուրդ չեմ տալիս դա անել ցածր հուսալիության պատճառով, չնայած եթե դուք ունեք առնվազն երեք կրկնօրինակներ տարբեր տվյալների կենտրոններում, ապա դա հնարավոր է: Եթե ինչ-որ բան պատահի, տվյալները կվերականգնվեն: Եկեք պատկերացնենք, որ սերվերը հանկարծակի անջատվել է և նորից միացվել։ Միջնորմը նորից տեղադրվեց, բայց այնտեղ ոչինչ չկար։ Երբ ClickHouse սերվերը սկսվում է, տեսնում է, որ այն չունի այդ կտորները, չնայած, ըստ ZooKeeper մետատվյալների, դրանք պետք է լինեն այնտեղ: Նա նայում է, թե որ կրկնօրինակներն ունեն դրանք, հարցում է անում և ներբեռնում: Այս կերպ տվյալները կվերականգնվեն:
Այս առումով, RAM-ում տվյալների պահպանումն էապես չի տարբերվում սկավառակի վրա պահելուց, քանի որ երբ տվյալները գրվում են սկավառակի վրա, այն նաև սկզբում հայտնվում է էջի քեշում և ֆիզիկապես գրվում է ավելի ուշ: Սա կախված է ֆայլային համակարգի մոնտաժման տարբերակից: Բայց ամեն դեպքում, ես կասեմ, որ ClickHouse-ը չի համաժամանակացնում տեղադրման ժամանակ:
Այս դեպքում RAM-ի տվյալները պահվում են ճիշտ նույն ձևաչափով, ինչ սկավառակի վրա: Ընտրելու հարցումը նույն կերպ ընտրում է այն հատվածները, որոնք պետք է կարդալ, ընտրում է անհրաժեշտ տվյալների միջակայքերը կտորներում և կարդում դրանք: Իսկ prewhere-ն աշխատում է ճիշտ նույն կերպ՝ անկախ նրանից՝ տվյալները RAM-ում էին, թե սկավառակի վրա։
Մինչև քանի՞ թվով եզակի արժեքներ է արդյունավետ Low Cardinality-ը:
Low Cardinality-ը խելամտորեն նախագծված է: Այն կազմում է տվյալների բառարաններ, բայց դրանք տեղական են։ Նախ, յուրաքանչյուր կտորի համար կան տարբեր բառարաններ, և երկրորդ, նույնիսկ մեկ կտորի ներսում դրանք կարող են տարբեր լինել յուրաքանչյուր տիրույթի համար: Երբ եզակի արժեքների թիվը հասնում է մի շեմի` մեկ միլիոն, կարծում եմ, բառարանը պարզապես պահվում է և ստեղծվում է նորը:
Պատասխանն ընդհանուր է. յուրաքանչյուր տեղական տիրույթի համար, ասենք, յուրաքանչյուր օրվա համար, ինչ-որ տեղ մինչև մեկ միլիոն եզակի արժեքներ ցածր կարդինալությունը արդյունավետ է: Այնուհետև կլինի պարզապես հետադարձ, որտեղ կօգտագործվեն բազմաթիվ տարբեր բառարաններ, և ոչ միայն մեկը: Այն կաշխատի մոտավորապես նույնը, ինչ սովորական լարային սյունակը, գուցե մի փոքր ավելի քիչ արդյունավետ, բայց կատարողականի լուրջ դեգրադացիա չի լինի:
Որո՞նք են հինգ միլիարդ տողերով աղյուսակի ամբողջական տեքստի որոնման լավագույն փորձը:
Կան տարբեր պատասխաններ. Առաջինն այն է, որ ClickHouse-ը ամբողջական տեքստային որոնման համակարգ չէ: Դրա համար կան հատուկ համակարգեր, օրինակ. и . Այնուամենայնիվ, ես ավելի ու ավելի եմ տեսնում մարդկանց, ովքեր ասում են, որ Elasticsearch-ից անցնում են ClickHouse-ին:
Ինչու է դա տեղի ունենում: Նրանք դա բացատրում են նրանով, որ Elasticsearch-ը դադարում է հաղթահարել բեռը որոշ ծավալներում՝ սկսած ինդեքսների կառուցումից։ Ինդեքսները դառնում են չափազանց ծանր, և եթե ուղղակի տվյալները փոխանցեք ClickHouse-ին, ապա ստացվում է, որ դրանք մի քանի անգամ ավելի արդյունավետ են պահվում ծավալի առումով։ Ընդ որում, որոնման հարցումները հաճախ այնպիսին չէին, որ անհրաժեշտ էր տվյալների ողջ ծավալում գտնել ինչ-որ արտահայտություն՝ հաշվի առնելով մորֆոլոգիան, այլ բոլորովին այլ։ Օրինակ՝ վերջին մի քանի ժամվա ընթացքում տեղեկամատյաններում գտեք բայթերի որոշակի հաջորդականություն:
Այս դեպքում ClickHouse-ում ստեղծում եք ինդեքս, որի առաջին դաշտը կլինի ամսաթիվը և ժամը։ Եվ տվյալների ամենամեծ կրճատումը հիմնված կլինի ամսաթվերի վրա: Ընտրված ամսաթվերի միջակայքում, որպես կանոն, արդեն հնարավոր է իրականացնել ամբողջական տեքստի որոնում, նույնիսկ օգտագործելով բիրտ ուժի մեթոդը, օգտագործելով like: ClickHouse-ի նման օպերատորը ամենաարդյունավետ նման օպերատորն է, որը կարող եք գտնել: Եթե ավելի լավ բան գտնես, ասա ինձ։
Բայց, այնուամենայնիվ, նման է ամբողջական սկանավորումը: Իսկ ամբողջական սկանավորումը կարող է դանդաղ լինել ոչ միայն պրոցեսորի, այլև սկավառակի վրա։ Եթե հանկարծ դուք ունեք օրական մեկ տերաբայթ տվյալ, և օրվա ընթացքում որոնում եք որևէ բառ, ապա ստիպված կլինեք սկանավորել տերաբայթը: Եվ դա հավանաբար սովորական կոշտ սկավառակների վրա է, և վերջում դրանք կբեռնվեն այնպես, որ դուք չեք կարողանա մուտք գործել այս սերվերը SSH-ի միջոցով:
Այս դեպքում ես պատրաստ եմ առաջարկել ևս մեկ փոքրիկ հնարք. Դա փորձարարական է. կարող է աշխատել, կարող է ոչ: ClickHouse-ն ունի ամբողջական տեքստային ինդեքսներ՝ եռագիր Bloom զտիչների տեսքով: Arenadata-ի մեր գործընկերներն արդեն փորձել են այս ցուցանիշները, և դրանք հաճախ աշխատում են ճիշտ այնպես, ինչպես նախատեսված է:
Դրանք ճիշտ օգտագործելու համար դուք պետք է լավ իմանաք, թե ինչպես են դրանք աշխատում. ինչ է եռագիր Bloom ֆիլտրը և ինչպես ընտրել դրա չափը: Կարող եմ ասել, որ դրանք կօգնեն որոշ հազվագյուտ արտահայտությունների, ենթատողերի հարցումների համար, որոնք հազվադեպ են հանդիպում տվյալների մեջ: Այս դեպքում ենթատիրույթները կընտրվեն ըստ ինդեքսների և ավելի քիչ տվյալներ կկարդան:
Վերջերս ClickHouse-ն ավելացրել է նույնիսկ ավելի առաջադեմ գործառույթներ ամբողջական տեքստի որոնման համար: Սա, առաջին հերթին, մի փունջ ենթատողերի որոնում է մեկ անցումով, ներառյալ տարբերակները, որոնք զգայուն են մեծատառերի, մեծատառերի նկատմամբ զգայուն, UTF-8-ի աջակցությամբ կամ միայն ASCII-ի համար: Ընտրեք Ձեզ անհրաժեշտ ամենաարդյունավետը:
Հայտնվել է նաև մեկ անցումով մի քանի կանոնավոր արտահայտությունների որոնում: Պետք չէ X-ը գրել մեկ ենթատողի պես կամ X-ը՝ մեկ այլ ենթատողի: Դուք անմիջապես գրում եք, և ամեն ինչ արվում է հնարավորինս արդյունավետ:
Երրորդ, այժմ կա regexps-ի մոտավոր որոնում և ենթատողերի մոտավոր որոնում: Եթե որևէ մեկը սխալ է գրել բառը, այն կփնտրվի առավելագույն համապատասխանության համար:
Ո՞րն է մեծ թվով օգտվողների համար ClickHouse մուտքը կազմակերպելու լավագույն միջոցը:
Ասեք մեզ, թե ինչպես լավագույնս կազմակերպել մուտքը մեծ թվով սպառողների և վերլուծաբանների համար: Ինչպե՞ս ստեղծել հերթ, առաջնահերթություն տալ առավելագույն միաժամանակյա հարցումներին և ի՞նչ գործիքներով:
Եթե կլաստերը բավականաչափ մեծ է, ապա լավ լուծում կլինի ևս երկու սերվեր բարձրացնելը, որը կդառնա մուտքի կետ վերլուծաբանների համար։ Այսինքն՝ թույլ մի տվեք վերլուծաբաններին մուտք գործել կլաստերի կոնկրետ բեկորներ, այլ պարզապես ստեղծեք երկու դատարկ սերվեր՝ առանց տվյալների, և կարգավորեք դրանց մուտքի իրավունքները։ Այս դեպքում օգտվողի կարգավորումները բաշխված հարցումների համար փոխանցվում են հեռավոր սերվերներին: Այսինքն՝ դուք կարգավորում եք ամեն ինչ այս երկու սերվերների վրա, և կարգավորումներն ազդում են ամբողջ կլաստերի վրա։
Սկզբունքորեն, այս սերվերները չունեն տվյալներ, բայց նրանց վրա RAM-ի քանակը շատ կարևոր է հարցումների կատարման համար: Սկավառակը կարող է օգտագործվել նաև ժամանակավոր տվյալների համար, եթե միացված է արտաքին համախմբումը կամ արտաքին տեսակավորումը:
Կարևոր է դիտարկել այն կարգավորումները, որոնք կապված են բոլոր հնարավոր սահմանափակումների հետ: Եթե ես հիմա գնամ Yandex.Metrica կլաստեր՝ որպես վերլուծաբան և խնդրեմ ընտրեք քանակությունը հիթերից, ապա անմիջապես ինձ կտրվի բացառություն, որ ես չեմ կարող կատարել հարցումը։ Տողերի առավելագույն քանակը, որոնք ինձ թույլատրվում է սկանավորել, հարյուր միլիարդ է, և ընդհանուր առմամբ, կլաստերի մեկ աղյուսակում դրանք հիսուն տրիլիոն են: Սա առաջին սահմանափակումն է։
Ենթադրենք, ես հանել եմ տողերի սահմանաչափը և նորից գործարկել հարցումը: Այնուհետև կտեսնեմ հետևյալ բացառությունը՝ կարգավորումը միացված է ուժի ինդեքսն ըստ ամսաթվի. Ես չեմ կարող լրացնել հարցումը, եթե ժամկետների միջակայք չեմ նշել: Այն ձեռքով նշելու համար պետք չէ հույս դնել վերլուծաբանների վրա: Տիպիկ դեպքն այն է, երբ գրվում է ամսաթվերի միջակայք, որտեղ իրադարձությունների ամսաթիվը շաբաթվա միջև է: Եվ հետո նրանք պարզապես սխալ տեղում նշել են փակագիծ, և դրա փոխարեն պարզվել է, որ կամ - կամ URL համընկնում է: Եթե սահմանափակում չկա, այն կսողա URL-ի սյունակը և պարզապես կվատնի մի տոննա ռեսուրսներ:
Բացի այդ, ClickHouse-ն ունի երկու առաջնահերթ կարգավորում: Ցավոք, նրանք շատ պարզունակ են: Մեկը պարզապես կոչվում է առաջնություն. Եթե առաջնահերթություն ≠ 0, և որոշակի առաջնահերթություն ունեցող հարցումներ են կատարվում, բայց կատարվում է ավելի փոքր առաջնահերթություն ունեցող հարցում, ինչը նշանակում է ավելի բարձր առաջնահերթություն, ապա ավելի մեծ առաջնահերթության արժեքով հարցում, ինչը նշանակում է ավելի ցածր առաջնահերթություն: , ուղղակի կասեցված է և այս ընթացքում ընդհանրապես չի աշխատի։
Սա շատ կոպիտ պարամետր է և հարմար չէ այն դեպքերի համար, երբ կլաստերը մշտական ծանրաբեռնվածություն ունի: Բայց եթե դուք ունեք կարճ, բուռն հարցումներ, որոնք կարևոր են, և կլաստերը հիմնականում անգործուն է, այս կարգավորումը հարմար է:
Հաջորդ առաջնահերթ կարգավորումը կոչվում է OS թեմայի առաջնահերթություն. Այն պարզապես սահմանում է գեղեցիկ արժեքը Linux-ի ժամանակացույցի բոլոր հարցումների կատարման թելերի համար: Այն աշխատում է այսպես, բայց այն դեռ աշխատում է: Եթե դուք սահմանեք նվազագույն գեղեցիկ արժեքը՝ այն արժեքով ամենամեծն է, հետևաբար՝ նվազագույն առաջնահերթությունը, և սահմանեք -19 բարձր առաջնահերթություն ունեցող հարցումների համար, ապա պրոցեսորը կսպառի ցածր առաջնահերթության հարցումները մոտ չորս անգամ ավելի քիչ, քան բարձր առաջնահերթությունները:
Դուք նաև պետք է կազմաձևեք հարցումների կատարման առավելագույն ժամանակը, ասենք, հինգ րոպե: Հարցման կատարման նվազագույն արագությունը ամենաթեժ բանն է: Այս պարամետրը գոյություն ունի երկար ժամանակ, և պահանջվում է ոչ միայն պնդել, որ ClickHouse-ը չի դանդաղում, այլ պարտադրել այն:
Պատկերացրեք, դուք կարգավորել եք. եթե որոշ հարցումներ մշակում են մեկ միլիոնից պակաս տող վայրկյանում, դուք չեք կարող դա անել: Սա խայտառակում է մեր բարի անունը, մեր լավ տվյալների բազան: Ուղղակի սա արգելենք։ Իրականում երկու կարգավորում կա. Մեկը կոչվում է րոպե կատարման արագություն - վայրկյանում տողերով, իսկ երկրորդը կոչվում է ժամանակի ավարտ մինչև կատարման րոպեի արագությունը ստուգելը` լռելյայն տասնհինգ վայրկյան: Այսինքն, հնարավոր է տասնհինգ վայրկյան, և հետո, եթե դա դանդաղ է, ապա պարզապես բացառություն գցեք և ընդհատեք հարցումը:
Դուք նաև պետք է սահմանեք քվոտաներ: ClickHouse-ն ունի ներկառուցված քվոտայի հատկություն, որը հաշվում է ռեսուրսների սպառումը: Բայց, ցավոք, ոչ թե ապարատային ռեսուրսներ, ինչպիսիք են պրոցեսորը, սկավառակները, այլ տրամաբանականները՝ մշակված հարցումների, տողերի և կարդացվող բայթերի քանակը: Եվ դուք կարող եք կարգավորել, օրինակ, առավելագույնը հարյուր հարցում հինգ րոպեի ընթացքում և հազար հարցում մեկ ժամում:
Ինչու է դա կարևոր: Քանի որ որոշ վերլուծական հարցումներ կկատարվեն ձեռքով անմիջապես ClickHouse հաճախորդից: Եվ ամեն ինչ լավ կլինի: Բայց եթե դուք ունեք առաջադեմ վերլուծաբաններ ձեր ընկերությունում, նրանք կգրեն սցենար, և կարող է սխալ լինել սցենարում: Եվ այս սխալը կհանգեցնի նրան, որ հարցումը կկատարվի անսահման օղակով: Սա այն է, ինչից մենք պետք է պաշտպանվենք:
Հնարավո՞ր է մեկ հարցման արդյունքներ տալ տասը հաճախորդի:
Մենք ունենք մի քանի օգտատերեր, ովքեր սիրում են շատ մեծ խնդրանքներով գալ ժամանակի նույն պահին: Խնդրանքը մեծ է և, սկզբունքորեն, արագ կատարվում, բայց քանի որ նման խնդրանքները միաժամանակ շատ են, դառնում է շատ ցավալի։ Հնարավո՞ր է տասը անգամ անընդմեջ ժամանած նույն հարցումը մեկ անգամ կատարել և արդյունքը տալ տասը հաճախորդի։
Խնդիրն այն է, որ մենք չունենք միջանկյալ տվյալների քեշի կամ քեշի արդյունքները: Կա օպերացիոն համակարգի էջի քեշ, որը թույլ չի տա ձեզ նորից կարդալ սկավառակի տվյալները, բայց, ցավոք, տվյալները դեռ կկտրվեն, ապասերիալացվեն և վերամշակվեն:
Ես կցանկանայի ինչ-որ կերպ խուսափել դրանից՝ կա՛մ միջանկյալ տվյալները քեշավորելով, կա՛մ նմանատիպ հարցումները ինչ-որ հերթում շարելով և արդյունքների քեշ ավելացնելով: Ներկայումս մենք ունենք մեկ ձգման հարցում մշակման փուլում, որն ավելացնում է հարցումների քեշ, բայց միայն ենթհարցումների համար in and join բաժիններում, այսինքն՝ լուծումը թերի է:
Սակայն մենք նույնպես բախվում ենք նման իրավիճակի։ Հատկապես կանոնական օրինակ են էջադրված հարցումները: Զեկույց կա, մի քանի էջ ունի, 10-ի սահմանի հարցում էլ կա, հետո նույնը, բայց լիմիտը 10,10։ Հետո ևս մեկ հաջորդ էջ: Եվ հարց է՝ ինչո՞ւ ենք մենք ամեն անգամ հաշվում այս ամենը։ Բայց հիմա լուծում չկա, և դրանից խուսափելու միջոց չկա։
Գոյություն ունի այլընտրանքային լուծում, որը տեղադրված է որպես կողք՝ ClickHouse-ի կողքին. .
Կիրիլ Շվակով. ClickHouse Proxy-ն ունի ներկառուցված տոկոսադրույքի սահմանափակիչ և ներկառուցված արդյունքների քեշ: Այնտեղ շատ կարգավորումներ արվեցին, քանի որ նմանատիպ խնդիր էր լուծվում։ Proxy-ը թույլ է տալիս սահմանափակել հարցումները՝ հերթագրելով դրանք և կարգավորել, թե որքան է գործում հարցումների քեշը: Եթե հարցումներն իսկապես նույնն էին, ապա Proxy-ն դրանք կուղարկի բազմիցս, բայց կգնա ClickHouse միայն մեկ անգամ:
Nginx-ն ունի նաև քեշ անվճար տարբերակում, և սա նույնպես կաշխատի: Nginx-ը նույնիսկ ունի կարգավորումներ, որոնք, եթե հարցումները ժամանեն միևնույն ժամանակ, այն կդանդաղեցնի մյուսների աշխատանքը, մինչև մեկը ավարտվի: Բայց հենց ClickHouse Proxy-ում է, որ կարգավորումը շատ ավելի լավ է արվում: Այն ստեղծվել է հատուկ ClickHouse-ի համար, հատուկ այս հարցումների համար, ուստի ավելի հարմար է։ Դե, դա հեշտ է տեղադրել:
Ի՞նչ կասեք ասինխրոն գործողությունների և նյութականացված տեսակետների մասին:
Խնդիր կա, որ կրկնվող շարժիչի հետ գործառնությունները ասինխրոն են՝ սկզբում տվյալները գրվում են, հետո այն փլուզվում է։ Եթե նյութականացված պլանշետը որոշ ագրեգատներով ապրում է նշանի տակ, ապա դրա վրա կգրվեն կրկնօրինակներ: Իսկ եթե չկա բարդ տրամաբանություն, ապա տվյալները կկրկնօրինակվեն։ Ի՞նչ կարող ես անել դրա դեմ:
Կա ակնհայտ լուծում՝ ասինխրոն փլուզման գործողության ժամանակ matview-ների որոշակի դասի վրա գործարկել: Կա՞ն արդյոք արծաթե փամփուշտներ կամ նմանատիպ գործառույթներ իրականացնելու ծրագրեր:
Արժե հասկանալ, թե ինչպես է աշխատում deduplication-ը: Այն, ինչ ես հիմա ձեզ կասեմ, կապված չէ հարցի հետ, բայց միայն այն դեպքում, երբ արժե հիշել:
Կրկնվող աղյուսակում ներդնելիս տեղի է ունենում ամբողջ տեղադրված բլոկների կրկնօրինակում: Եթե դուք նորից տեղադրեք նույն բլոկը, որը պարունակում է նույն թվով նույն տողերը նույն հերթականությամբ, ապա տվյալները կհեռացվեն: Տեղադրելուն ի պատասխան դուք կստանաք «Ok», բայց իրականում տվյալների մեկ փաթեթ կգրվի, և այն չի կրկնօրինակվի:
Սա անհրաժեշտ է որոշակիության համար: Եթե տեղադրման ժամանակ ստացել եք «Ok», ապա ձեր տվյալները տեղադրվել են: Եթե դուք սխալ եք ստանում ClickHouse-ից, նշանակում է, որ դրանք չեն տեղադրվել, և դուք պետք է կրկնեք տեղադրումը: Բայց եթե տեղադրման ժամանակ կապը խզվում է, ուրեմն չգիտես՝ տվյալները տեղադրվել են, թե ոչ։ Միակ տարբերակը նորից կրկնել ներդիրը։ Եթե տվյալներն իրականում տեղադրվել են, և դուք նորից տեղադրել եք դրանք, ապա կա արգելափակման կրկնօրինակում: Սա անհրաժեշտ է կրկնօրինակներից խուսափելու համար:
Եվ նաև կարևոր է, թե ինչպես է այն աշխատում նյութականացված տեսակետների համար: Եթե հիմնական աղյուսակում տեղադրվելիս տվյալները կրկնօրինակվել են, ապա դրանք նույնպես չեն մտնի նյութականացված տեսք:
Հիմա հարցի մասին. Ձեր իրավիճակն ավելի բարդ է, քանի որ դուք ձայնագրում եք առանձին տողերի կրկնօրինակներ: Այսինքն, ոչ թե ամբողջ փաթեթն է կրկնօրինակվում, այլ կոնկրետ գծեր, և դրանք փլուզվում են հետին պլանում։ Իրոք, տվյալները կփլուզվեն հիմնական աղյուսակում, բայց չփլուզված տվյալները կգնան նյութականացված տեսք, և միաձուլումների ժամանակ ոչինչ չի պատահի նյութականացված դիտումների հետ: Քանի որ նյութականացված տեսակետը ոչ այլ ինչ է, քան ներդիրի ձգան: Մյուս գործողությունների ժամանակ դրան հավելյալ ոչինչ չի պատահում։
Եվ ես չեմ կարող ձեզ ուրախացնել այստեղ: Պարզապես պետք է կոնկրետ լուծում փնտրել այս գործի համար։ Օրինակ, հնարավո՞ր է այն վերարտադրել նյութականացված տեսքով, և կրկնօրինակման մեթոդը կարող է աշխատել նույն կերպ: Բայց, ցավոք, ոչ միշտ: Եթե ագրեգացվի, չի ստացվի։
Կիրիլ Շվակով. Ժամանակին նաև հենակների շինարարություն ունեինք։ Խնդիր կար, որ կան գովազդային տպավորություններ, և կան որոշակի տվյալներ, որոնք մենք կարող ենք իրական ժամանակում ցույց տալ՝ դրանք պարզապես տպավորություններ են։ Դրանք հազվադեպ են կրկնօրինակվում, բայց եթե դա տեղի ունենա, մենք ամեն դեպքում կփլուզենք դրանք: Եվ կային բաներ, որոնք հնարավոր չէր կրկնել՝ կտտոցներ և այս ամբողջ պատմությունը: Բայց ես նույնպես ուզում էի ցույց տալ նրանց գրեթե անմիջապես:
Ինչպե՞ս են կազմվել նյութականացված տեսակետները: Կային դիտումներ, որտեղ ուղղակիորեն գրված էր՝ գրված էր չմշակված տվյալների վրա, և գրված էր դիտումների վրա։ Այնտեղ ինչ-որ պահի տվյալներն այնքան էլ ճիշտ չեն, կրկնօրինակվում են և այլն։ Եվ կա աղյուսակի երկրորդ մասը, որտեղ դրանք լրիվ նույնն են, ինչ նյութականացված տեսակետները, այսինքն՝ կառուցվածքով բացարձակապես նույնական են։ Մեկ-մեկ մենք վերահաշվարկում ենք տվյալները, հաշվում ենք տվյալները առանց կրկնօրինակների, գրում ենք այդ աղյուսակներին։
Մենք անցել ենք API-ի միջոցով, դա չի աշխատի ClickHouse-ում ձեռքով: Եվ API-ն նայում է. երբ ես ունեմ աղյուսակի վերջին ավելացման ամսաթիվը, որտեղ երաշխավորված է, որ ճիշտ տվյալներն արդեն հաշվարկված են, և նա հարցում է կատարում մեկ աղյուսակին և մեկ այլ աղյուսակին: Մեկից հարցումն ընտրում է մինչև որոշակի ժամանակ, իսկ մյուսից ստանում է այն, ինչ դեռ չի հաշվարկվել։ Եվ դա աշխատում է, բայց ոչ միայն ClickHouse-ի միջոցով:
Եթե ունեք ինչ-որ API՝ վերլուծաբանների, օգտագործողների համար, ապա, սկզբունքորեն, սա տարբերակ է: Դուք միշտ հաշվում եք, միշտ հաշվում եք: Դա կարելի է անել օրական մեկ անգամ կամ մեկ այլ ժամանակ: Դուք ինքներդ ընտրում եք մի շարք, որը ձեզ պետք չէ և կրիտիկական չէ:
ClickHouse-ն ունի բազմաթիվ տեղեկամատյաններ: Ինչպե՞ս կարող եմ մի հայացքով տեսնել այն ամենը, ինչ տեղի է ունենում սերվերի հետ:
ClickHouse-ն ունի շատ մեծ թվով տարբեր տեղեկամատյաններ, և այս թիվը գնալով ավելանում է: Նոր տարբերակներում դրանցից մի քանիսը նույնիսկ լռելյայն միացված են, իսկ հին տարբերակներում դրանք պետք է միացված լինեն թարմացման ժամանակ: Այնուամենայնիվ, դրանք ավելի ու ավելի շատ են: Ի վերջո, ես կցանկանայի տեսնել, թե ինչ է կատարվում իմ սերվերի հետ այժմ, միգուցե ինչ-որ ամփոփիչ վահանակի վրա:
Ունե՞ք ClickHouse թիմ կամ ձեր ընկերների թիմեր, որոնք աջակցում են պատրաստի վահանակների որոշ գործառույթներին, որոնք կցուցադրեն այս տեղեկամատյանները որպես պատրաստի արտադրանք: Ի վերջո, ClickHouse-ում միայն տեղեկամատյաններին նայելը հիանալի է: Բայց շատ թույն կլիներ, եթե այն արդեն պատրաստ լիներ վահանակի տեսքով։ Սրանից հարված կհասցնեի:
Կան վահանակներ, չնայած դրանք ստանդարտացված չեն: Մեր ընկերությունում մոտ 60 թիմ օգտվում է ClickHouse-ից, և ամենատարօրինակն այն է, որ նրանցից շատերն ունեն վահանակներ, որոնք իրենք պատրաստել են իրենց համար և մի փոքր տարբեր: Որոշ թիմեր օգտագործում են Yandex.Cloud-ի ներքին տեղադրումը: Կան պատրաստի հաշվետվություններ, թեև ոչ բոլոր անհրաժեշտները։ Մյուսներն ունեն իրենց սեփականը:
Metrica-ի իմ գործընկերներն ունեն իրենց սեփական վահանակը Grafana-ում, իսկ ես ունեմ իմը նրանց կլաստերի համար: Ես նայում եմ այնպիսի բաների, ինչպիսիք են քեշի հարվածը սերիֆի քեշի համար: Եվ ավելի դժվարն այն է, որ մենք օգտագործում ենք տարբեր գործիքներ: Ես ստեղծել եմ իմ վահանակը՝ օգտագործելով շատ հին գործիք, որը կոչվում է Graphite-web: Նա ամբողջովին տգեղ է: Եվ ես դեռ օգտագործում եմ այն այսպես, չնայած Grafana-ն, հավանաբար, ավելի հարմար և գեղեցիկ կլիներ:
Վահանակների հիմնական բանը նույնն է: Սրանք կլաստերի համար համակարգային չափումներ են՝ պրոցեսոր, հիշողություն, սկավառակ, ցանց: Մյուսները՝ միաժամանակյա հարցումների քանակը, միաժամանակյա միաձուլումների քանակը, հարցումների քանակը վայրկյանում, MergeTree աղյուսակի միջնորմների առավելագույն քանակությունը, կրկնօրինակման հետաձգումը, կրկնօրինակման հերթի չափը, տեղադրվող տողերի քանակը վայրկյանում, տեղադրվող բլոկների քանակը վայրկյանում: Սա այն ամենն է, ինչ ստացվում է ոչ թե տեղեկամատյաններից, այլ չափիչներից։
Վլադիմիր Կոլոբաև. Ալեքսեյ, ուզում եմ մի փոքր ուղղել. Կա Գրաֆանան։ Grafana-ն ունի տվյալների աղբյուր, որը ClickHouse-ն է: Այսինքն, ես կարող եմ հարցումներ կատարել Grafana-ից անմիջապես ClickHouse-ին: ClickHouse-ն ունի տեղեկամատյաններով աղյուսակ, այն նույնն է բոլորի համար։ Արդյունքում, ես ուզում եմ մուտք գործել այս տեղեկամատյան աղյուսակը Grafana-ում և տեսնել իմ սերվերի կատարած հարցումները: Հիանալի կլիներ ունենալ այսպիսի վահանակ:
Ես ինքս հեծանիվ վարեցի: Բայց ես հարց ունեմ. եթե այդ ամենը ստանդարտացված է, և Grafana-ն օգտագործվում է բոլորի կողմից, ինչու՞ Yandex-ը չունի նման պաշտոնական վահանակ:
Կիրիլ Շվակով. Փաստորեն, տվյալների աղբյուրը, որը գնում է ClickHouse, այժմ աջակցում է Altinity-ին: Եվ ես պարզապես ուզում եմ վեկտոր տալ, թե որտեղ պետք է փորել և ում մղել: Դուք կարող եք հարցնել նրանց, քանի որ Yandex-ը դեռ պատրաստում է ClickHouse-ը, և ոչ թե դրա շուրջ պատմությունը: Altinity-ն այն հիմնական ընկերությունն է, որը ներկայումս գովազդում է ClickHouse-ը: Նրան չեն լքի, այլ կաջակցեն։ Որովհետև, սկզբունքորեն, Գրաֆանա կայքէջում վահանակ վերբեռնելու համար պարզապես անհրաժեշտ է գրանցվել և վերբեռնել այն՝ հատուկ խնդիրներ չկան:
Ալեքսեյ Միլովիդով. Անցած տարվա ընթացքում ClickHouse-ն ավելացրել է հարցումների պրոֆիլավորման բազմաթիվ հնարավորություններ: Կան չափումներ ռեսուրսների օգտագործման յուրաքանչյուր հարցման համար: Եվ հենց վերջերս մենք ավելացրեցինք նույնիսկ ավելի ցածր մակարդակի հարցումների պրոֆիլավորիչ՝ տեսնելու, թե որտեղ է ծախսվում հարցումը ամեն միլիվայրկյան: Բայց այս ֆունկցիոնալությունն օգտագործելու համար ես պետք է բացեմ կոնսոլի հաճախորդը և մուտքագրեմ հարցում, որը ես միշտ մոռանում եմ: Ես այն պահել եմ ինչ-որ տեղ և շարունակում եմ մոռանալ, թե կոնկրետ որտեղ:
Կցանկանայի, որ մի գործիք լիներ, որը պարզապես ասեր, ահա ձեր ծանր հարցումները՝ խմբավորված ըստ հարցումների դասի: Ես սեղմեցի մեկի վրա, և նրանք ինձ կասեին, որ դրա համար ծանր է: Հիմա նման լուծում չկա։ Եվ իսկապես շատ տարօրինակ է, որ երբ մարդիկ ինձ հարցնում են. «Ասա ինձ, կա՞ն պատրաստի վահանակներ Grafana-ի համար», ես ասում եմ. «Գնացեք Grafana կայք, կա «Dashboards» համայնք և կա վահանակ: Դիմկայից, Կոստյանից կա վահանակ։ Ես չգիտեմ, թե դա ինչ է, ես ինքս չեմ օգտագործել այն »:
Ինչպե՞ս ազդել միաձուլումների վրա, որպեսզի սերվերը չխանգարի OOM-ին:
Ես ունեմ աղյուսակ, աղյուսակում կա միայն մեկ միջնորմ, դա ReplacingMergeTree-ն է։ Չորս տարի է, ինչ տվյալներ եմ գրում դրա մեջ։ Ինձ անհրաժեշտ էր փոխել դրա մեջ և ջնջել որոշ տվյալներ:
Ես դա արեցի, և այս հարցումը մշակելիս կլաստերի բոլոր սերվերների ամբողջ հիշողությունը սպառվեց, և կլաստերի բոլոր սերվերները մտան OOM: Հետո նրանք բոլորը միասին վեր կացան, սկսեցին միաձուլել այս նույն գործողությունը, այս տվյալների բլոկը և նորից ընկան OOM: Հետո նորից վեր կացան ու նորից ընկան։ Եվ այս բանը չդադարեց:
Հետո պարզվեց, որ սա իրականում սխալ էր, որը տղաները շտկեցին: Սա շատ լավ է, շատ շնորհակալ եմ: Բայց նստվածք մնաց։ Եվ հիմա, երբ մտածում եմ աղյուսակում ինչ-որ միաձուլման մասին, ինձ մոտ հարց է առաջանում՝ ինչո՞ւ չեմ կարող ինչ-որ կերպ ազդել այս միաձուլումների վրա: Օրինակ, սահմանափակեք դրանք պահանջվող RAM-ի քանակով կամ, սկզբունքորեն, այն քանակով, որը կմշակի այս կոնկրետ աղյուսակը:
Ես ունեմ աղյուսակ, որը կոչվում է «Մետրիկա», խնդրում եմ մշակել այն ինձ համար երկու թեմայում: Զուգահեռաբար տասը կամ հինգ միաձուլում ստեղծելու կարիք չկա, դա արեք երկուսով: Կարծում եմ, որ երկուսի համար բավարար հիշողություն ունեմ, բայց տասը մշակելու համար կարող է բավարար չլինել։ Ինչու՞ է վախը մնում: Քանի որ աղյուսակը մեծանում է, և մի օր ես կկանգնեմ մի իրավիճակի հետ, որը, սկզբունքորեն, այլևս վրիպակի պատճառով չէ, այլ այն պատճառով, որ տվյալները կփոխվեն այնքան մեծ քանակությամբ, որ ես պարզապես բավարար հիշողություն չեմ ունենա: սերվեր. Եվ հետո սերվերը միաձուլվելու ժամանակ կխափանի OOM-ի մեջ: Ավելին, ես կարող եմ չեղարկել մուտացիան, բայց Մերջին այլեւս չկա։
Գիտեք, միաձուլման ժամանակ սերվերը չի ընկնի OOM-ի մեջ, քանի որ միաձուլման ժամանակ RAM-ի քանակն օգտագործվում է միայն մեկ փոքր տիրույթի տվյալների համար։ Այսպիսով, ամեն ինչ լավ կլինի՝ անկախ տվյալների քանակից։
Վլադիմիր Կոլոբաև. Լավ: Այստեղ պահն այնպիսին է, որ սխալը շտկելուց հետո ես ինձ համար ներբեռնեցի նոր տարբերակ, իսկ մեկ այլ սեղանի վրա՝ ավելի փոքր, որտեղ կան բազմաթիվ միջնորմներ, կատարեցի նմանատիպ գործողություն։ Իսկ միաձուլման ժամանակ սերվերի վրա այրվել է մոտ 100 ԳԲ օպերատիվ հիշողություն։ Ես ունեի 150 զբաղված, 100 կերած, և 50 ԳԲ պատուհան էր մնացել, այնպես որ ես չընկա OOM-ի մեջ:
Ի՞նչն է ներկայումս պաշտպանում ինձ OOM-ի մեջ ընկնելուց, եթե այն իրականում սպառում է 100 ԳԲ RAM: Ի՞նչ անել, եթե հանկարծ միաձուլման վրա RAM-ը սպառվի:
Ալեքսեյ Միլովիդով. Նման խնդիր կա, որ RAM-ի սպառումը հատուկ միաձուլման համար սահմանափակված չէ։ Եվ երկրորդ խնդիրն այն է, որ եթե ինչ-որ միաձուլում է նշանակվել, ապա այն պետք է կատարվի, քանի որ այն գրանցված է կրկնօրինակման մատյանում: Կրկնօրինակման մատյանը այն գործողություններն են, որոնք անհրաժեշտ են կրկնօրինակը հետևողական վիճակի բերելու համար: Եթե դուք ձեռքով մանիպուլյացիաներ չեք անում, որոնք կվերադարձնեն այս կրկնօրինակման մատյանը, միաձուլումը պետք է կատարվի այսպես թե այնպես:
Իհարկե, ավելորդ չի լինի ունենալ RAM-ի սահմանափակում, որը «միայն դեպքում» պաշտպանում է OOM-ից: Դա չի օգնի միաձուլման ավարտին, այն նորից կսկսվի, կհասնի ինչ-որ շեմի, բացառություն կդնի և հետո նորից կսկսվի. դրանից լավ բան չի ստացվի: Բայց սկզբունքորեն օգտակար կլիներ այս սահմանափակումը մտցնել։
Ինչպե՞ս է մշակվելու ClickHouse-ի Golang դրայվերը:
Golang վարորդին, որը գրել է Կիրիլ Շվակովը, այժմ պաշտոնապես աջակցվում է ClickHouse թիմի կողմից: Նա , նա այժմ մեծ է և իրական։
Մի փոքրիկ նշում. Գոյություն ունի անսահման կարգի նորմալ ձևերի հիանալի և սիրելի շտեմարան՝ սա Vertica-ն է: Նրանք նաև ունեն իրենց պաշտոնական python դրայվերը, որն աջակցվում է Vertica-ի մշակողների կողմից: Եվ մի քանի անգամ պատահել է, որ պահեստավորման տարբերակները և վարորդի տարբերակները բավականին կտրուկ տարբերվել են, և վարորդը ինչ-որ պահի դադարեց աշխատել: Եվ երկրորդ կետը. Այս պաշտոնական վարորդի աջակցությունը, ինձ թվում է, իրականացվում է «խուլ» համակարգով. դուք նրանց խնդիր եք գրում, և այն ընդմիշտ կախված է:
Երկու հարց ունեմ. Այժմ Kirill's Golang վարորդը գրեթե լռելյայն միջոց է Golang-ից ClickHouse-ի հետ հաղորդակցվելու համար: Եթե ինչ-որ մեկը դեռ չի շփվում http ինտերֆեյսի միջոցով, քանի որ դա նրան այդպես է դուր գալիս: Ինչպե՞ս կշարունակվի այս վարորդի զարգացումը: Արդյո՞ք այն կհամաժամանակացվի հենց պահոցում կատարված որևէ ընդհատվող փոփոխությունների հետ: Իսկ ինչպիսի՞ն է հարցի քննարկման կարգը։
Կիրիլ Շվակով. Առաջինն այն է, թե ինչպես է ամեն ինչ կազմակերպվում բյուրոկրատական եղանակով։ Այս կետը չի քննարկվել, ուստի պատասխանելու ոչինչ չունեմ։
Խնդրի վերաբերյալ հարցին պատասխանելու համար մեզ անհրաժեշտ է վարորդի մի փոքր պատմություն։ Ես աշխատել եմ մի ընկերությունում, որն ուներ շատ տվյալներ: Դա գովազդային մանող էր՝ հսկայական թվով իրադարձություններով, որոնք ինչ-որ տեղ պետք է պահվեին: Եվ ինչ-որ պահի հայտնվեց ClickHouse-ը: Մենք այն լրացրեցինք տվյալների հետ, և սկզբում ամեն ինչ լավ էր, բայց հետո ClickHouse-ը խափանվեց: Այդ պահին մենք որոշեցինք, որ դա մեզ պետք չէ։
Մեկ տարի անց մենք վերադարձանք ClickHouse-ն օգտագործելու գաղափարին, և մեզ անհրաժեշտ էր ինչ-որ կերպ տվյալներ գրել այնտեղ: Ներածական ուղերձը սա էր. ապարատը շատ թույլ է, ռեսուրսները քիչ են։ Բայց մենք միշտ էլ այսպես ենք աշխատել, և հետևաբար նայել ենք հայրենի արձանագրությանը։
Քանի որ մենք աշխատում էինք Գոյում, պարզ էր, որ մեզ Գոյ վարորդ է պետք։ Ես դա արեցի գրեթե լրիվ դրույքով, դա իմ աշխատանքային խնդիրն էր: Մենք դա հասցրինք որոշակի կետի, և սկզբունքորեն ոչ ոք չէր ենթադրում, որ մեզնից բացի որևէ մեկը կօգտագործի այն։ Հետո CloudFlare-ը եկավ ճիշտ նույն խնդրով, և որոշ ժամանակ մենք նրանց հետ աշխատեցինք շատ սահուն, քանի որ նրանք ունեին նույն առաջադրանքները: Ավելին, մենք դա արել ենք ինչպես ClickHouse-ում, այնպես էլ դրայվերում:
Ինչ-որ պահի ես ուղղակի դադարեցի դա անել, քանի որ իմ գործունեությունը ClickHouse-ի և աշխատանքի առումով մի փոքր փոխվեց։ Ուստի հարցերը փակված չեն։ Պարբերաբար մարդիկ, ովքեր ինչ-որ բանի կարիք ունեն, իրենք պարտավորվում են շտեմարան: Հետո ես նայում եմ ձգման խնդրանքին և երբեմն նույնիսկ ինքս ինչ-որ բան եմ խմբագրում, բայց դա հազվադեպ է պատահում:
Ես ուզում եմ վերադառնալ վարորդի մոտ։ Մի քանի տարի առաջ, երբ այս ամբողջը սկսվեց, ClickHouse-ը նույնպես տարբերվում էր և տարբեր հնարավորություններով: Այժմ մենք հասկանում ենք, թե ինչպես կարելի է վերափոխել վարորդը, որպեսզի այն լավ աշխատի: Եթե դա տեղի ունենա, ապա 2-րդ տարբերակը ցանկացած դեպքում անհամատեղելի կլինի կուտակված հենակների պատճառով։
Ես չգիտեմ, թե ինչպես կազմակերպել այս հարցը: Ես ինքս շատ ժամանակ չունեմ: Եթե որոշ մարդիկ վերջացնեն վարորդին, ես կարող եմ օգնել նրանց և ասել, թե ինչ անեն: Սակայն նախագծի մշակմանը Yandex-ի ակտիվ մասնակցությունը դեռ չի քննարկվել։
Ալեքսեյ Միլովիդով. Փաստորեն, այս վարորդների մասով դեռ բյուրոկրատիա չկա։ Միակ բանն այն է, որ դրանք ներկայացվում են պաշտոնական կազմակերպության, այսինքն՝ այս դրայվերը ճանաչվում է որպես Go-ի պաշտոնական լռելյայն լուծում։ Ուրիշ վարորդներ էլ կան, բայց առանձին են գալիս։
Այս վարորդների համար մենք ներքին զարգացում չունենք։ Հարցն այն է, թե մենք կարո՞ղ ենք անհատին աշխատանքի ընդունել ոչ թե կոնկրետ այս վարորդի, այլ համայնքի բոլոր վարորդների զարգացման համար, թե՞ կարող ենք գտնել մեկին դրսից:
Արտաքին բառարանը չի բեռնվում վերաբեռնումից հետո, երբ lazy_load կարգավորումը միացված է: Ինչ անել?
Մենք ունենք lazy_load պարամետրը միացված, և սերվերի վերագործարկումից հետո բառարանն ինքնուրույն չի բեռնվում: Այն բարձրացվում է միայն այն բանից հետո, երբ օգտվողը մուտք գործի այս բառարանը: Իսկ երբ առաջին անգամ մուտք եմ գործում, սխալ է տալիս։ Հնարավո՞ր է ինչ-որ կերպ ավտոմատ կերպով բեռնել բառարանները՝ օգտագործելով ClickHouse-ը, թե՞ պետք է ինքներդ միշտ վերահսկել դրանց պատրաստակամությունը, որպեսզի օգտվողները սխալներ չստանան:
Հավանաբար մենք ունենք ClickHouse-ի հին տարբերակը, ուստի բառարանն ինքնաբերաբար չի բեռնվել: Կարո՞ղ է այդպես լինել:
Նախ, բառարանները կարող են հարկադիր բեռնվել՝ օգտագործելով հարցումը համակարգի վերաբեռնման բառարանները. Երկրորդ, սխալի հետ կապված. եթե բառարանն արդեն բեռնված է, ապա հարցումները կաշխատեն բեռնված տվյալների հիման վրա: Եթե բառարանը դեռ չի բեռնվել, ապա այն կբեռնվի անմիջապես հարցման ժամանակ:
Սա այնքան էլ հարմար չէ ծանր բառարանների համար։ Օրինակ, դուք պետք է քաշեք միլիոն տող MySQL-ից: Ինչ-որ մեկը կատարում է պարզ ընտրություն, բայց այս ընտրությունը կսպասի նույն միլիոն տողերին: Այստեղ երկու լուծում կա. Առաջինը lazy_load-ն անջատելն է: Երկրորդ, երբ սերվերը աշխատում է, նախքան դրա վրա բեռը դնելը, արեք համակարգի վերաբեռնման բառարան կամ պարզապես կատարել հարցում, որն օգտագործում է բառարան: Այնուհետև բառարանը կբեռնվի: Դուք պետք է վերահսկեք բառարանների հասանելիությունը lazy_load պարամետրով միացված, քանի որ ClickHouse-ը դրանք ավտոմատ կերպով չի բեռնում:
Վերջին հարցի պատասխանը կա՛մ տարբերակը հին է, կա՛մ պետք է վրիպազերծել:
Ի՞նչ անել այն փաստի հետ, որ համակարգի վերաբեռնման բառարանները չեն բեռնում բազմաթիվ բառարաններից որևէ մեկը, եթե դրանցից գոնե մեկը սխալմամբ խափանվի:
Մեկ այլ հարց կա համակարգի վերաբեռնման բառարանների վերաբերյալ: Մենք ունենք երկու բառարան՝ մեկը բեռնված չէ, երկրորդը՝ բեռնված։ Այս դեպքում System Reload Dictionaries-ը չի բեռնում որևէ բառարան, և դուք պետք է կետ առ կետ բեռնեք կոնկրետ մեկը իր անունով՝ օգտագործելով համակարգի վերաբեռնման բառարանը: Սա նաև կապված է ClickHouse տարբերակի հետ:
Ես ուզում եմ ձեզ ուրախացնել: Այս պահվածքը փոխվում էր։ Սա նշանակում է, որ եթե թարմացնեք ClickHouse-ը, այն նույնպես կփոխվի։ Եթե դուք գոհ չեք ձեր ներկայիս պահվածքից համակարգի վերաբեռնման բառարանները, թարմացրեք, և հուսանք, որ այն կփոխվի դեպի լավը:
Կա՞ որևէ միջոց՝ մանրամասները կարգավորելու ClickHouse կոնֆիգուրայում, բայց դրանք չցուցադրելու սխալների դեպքում:
Հաջորդ հարցը բառարանի հետ կապված սխալների, այն է՝ մանրամասների մասին է։ Մենք նշել ենք կապի մանրամասները ClickHouse կոնֆիգուրայում բառարանի համար, և եթե կա սխալ, մենք ի պատասխան ստանում ենք այս մանրամասները և գաղտնաբառը:
Մենք լուծեցինք այս սխալը՝ մանրամասներ ավելացնելով ODBC վարորդի կազմաձևում: Կա՞ որևէ միջոց՝ մանրամասները կարգավորելու ClickHouse կոնֆիգուրացիայի մեջ, բայց սխալների դեպքում չցուցադրել այդ մանրամասները:
Իրական լուծումն այստեղ odbc.ini-ում այս հավատարմագրերը նշելն է, իսկ ինքը՝ ClickHouse-ում նշել միայն ODBC տվյալների աղբյուրի անունը: Դա տեղի չի ունենա բառարանի այլ աղբյուրների համար՝ ոչ MySQL-ով բառարանի, ոչ էլ մյուսների համար, դուք չպետք է տեսնեք գաղտնաբառը, երբ սխալ հաղորդագրություն եք ստանում: ODBC-ի համար ես նույնպես կնայեմ, եթե այն գոյություն ունի, պարզապես անհրաժեշտ է հեռացնել այն:
Բոնուս՝ մեծացնելու ֆոն հավաքույթներից
Նկարի վրա սեղմելով՝ հավաքների բոնուսային ֆոները կբացվեն ամենահամառ ընթերցողների համար։ Մենք կրակը մարում ենք Avito տեխնոլոգիայի թալիսմանների հետ, խորհրդակցում ենք համակարգի ադմինիստրատորի սենյակի կամ հին դպրոցի համակարգչային ակումբի գործընկերների հետ և կամրջի տակ ամեն օր հանդիպումներ ենք անցկացնում գրաֆիտիների ֆոնին:
Source: www.habr.com