ClickHouse-ը իրական հավելվածներում օգտագործելու տեսություն և պրակտիկա: Ալեքսանդր Զայցև (2018)

Չնայած այն հանգամանքին, որ այժմ շատ տվյալներ կան գրեթե ամենուր, վերլուծական տվյալների բազաները դեռ բավականին էկզոտիկ են: Նրանք վատ հայտնի են և նույնիսկ ավելի վատ կարող են դրանք արդյունավետ օգտագործել: Շատերը շարունակում են «կակտուս ուտել» MySQL-ով կամ PostgreSQL-ով, որոնք նախատեսված են այլ սցենարների համար, տառապում են NoSQL-ից կամ գերավճարում են կոմերցիոն լուծումների համար: ClickHouse-ը փոխում է խաղի կանոնները և զգալիորեն իջեցնում վերլուծական DBMS-ի աշխարհ մուտք գործելու շեմը։

Հաշվետվություն BackEnd Conf 2018-ից և այն հրապարակվում է խոսնակի թույլտվությամբ:

Ո՞վ եմ ես և ինչու եմ ես խոսում ClickHouse-ի մասին: Ես զարգացման տնօրեն եմ LifeStreet-ում, որն օգտագործում է ClickHouse-ը: Բացի այդ, ես Altinity-ի հիմնադիրն եմ: Այն Yandex-ի գործընկեր է, որը խթանում է ClickHouse-ը և օգնում Yandex-ին ավելի հաջողակ դարձնել ClickHouse-ը: Նաև պատրաստ է կիսվել ClickHouse-ի մասին գիտելիքներով:

Իսկ ես Պետյա Զայցեւի եղբայրը չեմ։ Ինձ հաճախ են հարցնում այս մասին. Չէ, մենք եղբայրներ չենք։

«Բոլորը գիտեն», որ ClickHouse-ը.

• Շատ արագ,
• Շատ հարմարավետ
• Օգտագործվում է Yandex-ում:

Մի քիչ քիչ հայտնի է, թե որ ընկերություններում և ինչպես է այն օգտագործվում։

Ես ձեզ կասեմ, թե ինչու, որտեղ և ինչպես է օգտագործվում ClickHouse-ը, բացառությամբ Yandex-ի:

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

Ես վերցրեցի երեք օրինակ, որոնք ցույց են տալիս ClickHouse-ը տարբեր տեսանկյուններից: Կարծում եմ՝ հետաքրքիր կլինի։

Առաջին հարցը հետևյալն է. «Ինչու՞ է մեզ անհրաժեշտ ClickHouse-ը»: Թվում է, թե դա բավականին ակնհայտ հարց է, բայց դրա պատասխանը մեկից ավելի է:

• Առաջին պատասխանը կատարման համար է: ClickHouse-ը շատ արագ է: Վերլուծությունը ClickHouse-ում նույնպես շատ արագ է: Այն հաճախ կարող է օգտագործվել այնտեղ, որտեղ այլ բան շատ դանդաղ է կամ շատ վատ:
• Երկրորդ պատասխանը ծախսն է: Եվ առաջին հերթին մասշտաբի արժեքը: Օրինակ, Vertica-ն բացարձակապես հիանալի տվյալների բազա է: Այն շատ լավ է աշխատում, եթե դուք չունեք շատ տերաբայթ տվյալներ: Բայց երբ խոսքը հարյուրավոր տերաբայթի կամ պետաբայթի մասին է, լիցենզիայի և աջակցության արժեքը բավականին զգալի է: Եվ դա թանկ է: Իսկ ClickHouse-ն անվճար է:
• Երրորդ պատասխանը գործառնական ծախսերն են: Սա մի փոքր այլ մոտեցում է։ RedShift-ը հիանալի անալոգային է: RedShift-ում դուք կարող եք շատ արագ որոշում կայացնել: Այն լավ կաշխատի, բայց միևնույն ժամանակ, ամեն ժամ, ամեն օր և ամեն ամիս, դուք բավականին թանկ կվճարեք Amazon-ին, քանի որ սա զգալիորեն թանկ ծառայություն է։ Google BigQuery նույնպես: Եթե ​​ինչ-որ մեկն օգտագործել է այն, ուրեմն նա գիտի, որ այնտեղ կարող ես մի քանի հարցում կատարել և հանկարծ հարյուրավոր դոլարների հաշիվ ստանալ:

ClickHouse-ը չունի այս խնդիրները:

Որտե՞ղ է այժմ օգտագործվում ClickHouse-ը: Բացի Yandex-ից, ClickHouse-ն օգտագործվում է մի շարք տարբեր բիզնեսներում և ընկերություններում:

• Առաջին հերթին, սա վեբ հավելվածների վերլուծություն է, այսինքն, սա օգտագործման դեպք է, որը եկել է Yandex-ից:
• Շատ AdTech ընկերություններ օգտագործում են ClickHouse-ը:
• Բազմաթիվ ընկերություններ, որոնք պետք է վերլուծեն գործարքների տեղեկամատյանները տարբեր աղբյուրներից:
• Մի քանի ընկերություններ օգտագործում են ClickHouse-ը՝ անվտանգության տեղեկամատյանները վերահսկելու համար: Նրանք բեռնում են դրանք ClickHouse-ում, կազմում հաշվետվություններ և ստանում իրենց անհրաժեշտ արդյունքները:
• Ընկերությունները սկսում են այն օգտագործել ֆինանսական վերլուծության մեջ, այսինքն՝ աստիճանաբար խոշոր բիզնեսները նույնպես մոտենում են ClickHouse-ին։
• ամպամածություն. Եթե ​​ինչ-որ մեկը հետևում է ClickHouse-ին, ապա հավանաբար լսել է այս ընկերության անունը։ Սա համայնքի հիմնական ներդրողներից մեկն է: Եվ նրանք ունեն շատ լուրջ ClickHouse տեղադրում: Օրինակ, նրանք պատրաստել են Kafka Engine-ը ClickHouse-ի համար:
• Հեռահաղորդակցության ընկերությունները սկսեցին օգտվել. Մի քանի ընկերություններ օգտագործում են ClickHouse-ը կամ որպես հայեցակարգի ապացույց կամ արդեն արտադրության մեջ:
• Մեկ ընկերություն օգտագործում է ClickHouse-ը՝ արտադրական գործընթացները վերահսկելու համար: Փորձարկում են միկրոսխեմաներ, մի խումբ պարամետրեր են դուրս գրում, մոտ 2 հատկանիշ կա։ Իսկ հետո վերլուծում են՝ խաղը լավ է, թե վատ։
• Blockchain վերլուծություն. Կա այնպիսի ռուսական ընկերություն, ինչպիսին Bloxy.info-ն է։ Սա ethereum ցանցի վերլուծություն է: Նրանք դա արեցին նաև ClickHouse-ում:

Եվ չափը նշանակություն չունի: Կան բազմաթիվ ընկերություններ, որոնք օգտագործում են մեկ փոքր սերվեր: Եվ նա թույլ է տալիս լուծել իրենց խնդիրները։ Եվ նույնիսկ ավելի շատ ընկերություններ օգտագործում են բազմաթիվ սերվերների կամ տասնյակ սերվերների մեծ կլաստերներ:

Իսկ եթե նայեք արձանագրություններին, ապա.

• Յանդեքս. 500+ սերվեր, նրանք այնտեղ պահում են օրական 25 միլիարդ գրառում:
• LifeStreet. 60 սերվեր, օրական մոտավորապես 75 միլիարդ գրառում: Ավելի քիչ սերվերներ կան, ավելի շատ գրառումներ, քան Yandex-ում:
• CloudFlare. 36 սերվեր, նրանք խնայում են օրական 200 միլիարդ գրառում: Նրանք ունեն նույնիսկ ավելի քիչ սերվերներ և ավելի շատ տվյալներ են պահում:
• Bloomberg. 102 սերվեր, օրական մոտ մեկ տրիլիոն մուտք: Ռեկորդակիր.

Աշխարհագրական առումով սա նույնպես շատ է։ Այս քարտեզն այստեղ ցույց է տալիս ջերմային քարտեզ, թե որտեղ է օգտագործվում ClickHouse-ն աշխարհում: Այստեղ ակնհայտորեն առանձնանում են Ռուսաստանը, Չինաստանը, Ամերիկան։ Եվրոպական երկրները քիչ են։ Եվ կան 4 կլաստերներ.

Սա համեմատական ​​վերլուծություն է, բացարձակ թվեր փնտրելու կարիք չկա։ Սա Altinity կայքում անգլալեզու նյութեր կարդացող այցելուների վերլուծությունն է, քանի որ այնտեղ ռուսախոսներ չկան։ Իսկ Ռուսաստանը, Ուկրաինան, Բելառուսը, այսինքն՝ համայնքի ռուսալեզու հատվածը, սրանք ամենաշատ օգտվողներն են։ Հետո գալիս են ԱՄՆ-ը և Կանադան: Չինաստանը շատ է բռնում. Վեց ամիս առաջ այնտեղ Չինաստան գրեթե չկար, հիմա Չինաստանն արդեն առաջ է անցել Եվրոպայից և շարունակում է աճել։ Հին Եվրոպան նույնպես հետ չի մնում, և ClickHouse-ի օգտագործման առաջատարը, տարօրինակ կերպով, Ֆրանսիան է:

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

Սրանք իրական ClickHouse-ի օգտագործման օրինակներ են մի քանի ընկերություններում:

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

• LifeStreet-ը գովազդային տեխնոլոգիական ընկերություն է, որն ունի բոլոր այն տեխնոլոգիաները, որոնք գալիս են գովազդային ցանցի հետ:
• Նա զբաղվում է գովազդի օպտիմիզացմամբ, ծրագրային սակարկություններով։
• Շատ տվյալներ՝ օրական մոտ 10 միլիարդ իրադարձություն: Միևնույն ժամանակ այնտեղ իրադարձությունները կարելի է բաժանել մի քանի ենթաիրադարձությունների։
• Այս տվյալների շատ հաճախորդներ կան, և դրանք ոչ միայն մարդիկ են, այլ շատ ավելին. սրանք տարբեր ալգորիթմներ են, որոնք զբաղվում են ծրագրային սակարկություններով:

Ընկերությունը երկար ու փշոտ ճանապարհ է անցել։ Եվ ես դրա մասին խոսեցի HighLoad-ում: Նախ, LifeStreet-ը MySQL-ից (կարճ կանգառով Oracle-ում) տեղափոխվեց Vertica: Եվ դուք կարող եք գտնել մի պատմություն դրա մասին:

Եվ ամեն ինչ շատ լավ էր, բայց արագ պարզվեց, որ տվյալները աճում են, իսկ Vertica-ն թանկ է։ Ուստի տարբեր այլընտրանքներ էին որոնվում։ Դրանցից մի քանիսը թվարկված են այստեղ: Եվ փաստորեն, մենք իրականացրել ենք հայեցակարգի ապացույց կամ երբեմն կատարողականի փորձարկում գրեթե բոլոր տվյալների բազաների համար, որոնք առկա էին շուկայում 13-ից 16-րդ տարում և մոտավորապես հարմար էին ֆունկցիոնալության առումով: Եվ ես խոսեցի նաև դրանցից մի քանիսի մասին HighLoad-ում:

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

Ուր գնալ. Եվ երկար ժամանակ բոլորովին պարզ չէր, թե ուր գնալ, քանի որ մի կողմից կան կոմերցիոն շտեմարաններ, կարծես թե լավ են աշխատում։ Ոմանք աշխատում են գրեթե նույնքան լավ, որքան Vertica-ն, ոմանք ավելի վատ: Բայց դրանք բոլորն էլ թանկ են, ավելի էժան ու ավելի լավ բան հնարավոր չէր գտնել:

Մյուս կողմից, կան բաց կոդով լուծումներ, որոնք այնքան էլ շատ չեն, այսինքն՝ վերլուծության համար դրանք կարելի է մատների վրա հաշվել։ Եվ դրանք անվճար են կամ էժան, բայց դանդաղ: Եվ դրանք հաճախ բացակայում են անհրաժեշտ և օգտակար ֆունկցիոնալությունից:

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

Ոչինչ չկար, մինչև Yandex-ը անսպասելիորեն դուրս հանեց ClickHouse-ը, ինչպես կախարդը գլխարկից, ինչպես նապաստակը: Եվ դա անսպասելի որոշում էր, դեռ հարց են տալիս՝ «Ինչո՞ւ», բայց այնուամենայնիվ։

Եվ անմիջապես 2016 թվականի ամռանը մենք սկսեցինք նայել, թե ինչ է ClickHouse-ը: Եվ պարզվեց, որ երբեմն այն կարող է ավելի արագ լինել, քան Vertica-ն։ Մենք փորձարկեցինք տարբեր սցենարներ տարբեր խնդրանքներով: Իսկ եթե հարցումն օգտագործել է միայն մեկ աղյուսակ, այսինքն՝ առանց որևէ միացման (join), ապա ClickHouse-ը երկու անգամ ավելի արագ էր, քան Vertica-ն։

Ես շատ ծույլ չէի և օրերս նայեցի Yandex-ի թեստերը: Այնտեղ էլ նույնն է՝ ClickHouse-ը երկու անգամ ավելի արագ է, քան Vertica-ն, ուստի հաճախ են խոսում այդ մասին:

Բայց եթե հարցումներում միացումներ կան, ապա ամեն ինչ պարզվում է ոչ այնքան միանշանակ։ Իսկ ClickHouse-ը կարող է երկու անգամ ավելի դանդաղ լինել, քան Vertica-ն: Իսկ եթե մի փոքր ուղղեք խնդրանքը և նորից գրեք այն, ապա դրանք մոտավորապես հավասար են։ Վատ չէ։ Եվ անվճար:

Եվ ստանալով թեստի արդյունքները և նայելով դրան տարբեր տեսանկյուններից, LifeStreet-ը գնաց ClickHouse:

Սա 16-րդ տարին է, հիշեցնում եմ. Դա նման էր կատակի մկների մասին, որոնք լաց էին լինում և ծակում իրենց, բայց շարունակում էին ուտել կակտուսը: Եվ սա մանրամասն նկարագրվեց, այս մասին կա տեսանյութ և այլն։

Ուստի դրա մասին մանրամասն չեմ խոսի, կխոսեմ միայն արդյունքների ու մի քանի հետաքրքիր բաների մասին, որոնց մասին այն ժամանակ չէի խոսում։

Արդյունքներն են.

• Հաջող միգրացիան և մեկ տարուց ավելի համակարգն արդեն աշխատում է արտադրության մեջ։
• Բարձրացել է արտադրողականությունը և ճկունությունը։ 10 միլիարդ գրառումներից, որոնք մենք կարող էինք մեզ թույլ տալ պահել օրական, այնուհետև կարճ ժամանակով, LifeStreet-ն այժմ պահում է օրական 75 միլիարդ ձայնագրություն և կարող է դա անել 3 ամիս կամ ավելի: Եթե ​​հաշվում եք գագաթնակետին, ապա սա մինչև մեկ միլիոն իրադարձություն է վայրկյանում: Օրական ավելի քան մեկ միլիոն SQL հարցումներ են ժամանում այս համակարգում՝ հիմնականում տարբեր ռոբոտներից:
• Չնայած այն հանգամանքին, որ ClickHouse-ի համար ավելի շատ սերվերներ են օգտագործվել, քան Vertica-ի համար, դրանք խնայել են նաև ապարատային, քանի որ Vertica-ում օգտագործվել են բավականին թանկ SAS սկավառակներ։ ClickHouse-ն օգտագործեց SATA-ն: Իսկ ինչո՞ւ։ Քանի որ Vertica-ում ներդիրը համաժամանակյա է: Իսկ համաժամացման համար անհրաժեշտ է, որ սկավառակները շատ չդանդաղեն, նաեւ ցանցը շատ չդանդաղի, այսինքն՝ բավականին թանկ գործողություն։ Իսկ ClickHouse-ում ներդիրը ասինխրոն է: Ավելին, դուք միշտ կարող եք ամեն ինչ գրել տեղում, դրա համար լրացուցիչ ծախսեր չկան, այնպես որ տվյալները կարող են տեղադրվել ClickHouse-ում շատ ավելի արագ, քան Vertika-ում, նույնիսկ ավելի դանդաղ կրիչներում: Իսկ կարդալը մոտավորապես նույնն է։ SATA-ի վրա կարդալը, եթե դրանք RAID-ում են, ապա այս ամենը բավական արագ է:
• Չի սահմանափակվում լիցենզիայով, այսինքն՝ 3 փետաբայթ տվյալներ 60 սերվերում (20 սերվերը մեկ կրկնօրինակն է) և 6 տրիլիոն գրառումներ փաստերով և ագրեգացիաներով: Vertica-ում նման բան հնարավոր չէր թույլ տալ:

Այժմ ես դիմում եմ այս օրինակի գործնական բաներին:

• Առաջինը արդյունավետ սխեմա է. Շատ բան կախված է սխեմայից:
• Երկրորդը արդյունավետ SQL արտադրությունն է:

Տիպիկ OLAP հարցումը ընտրություն է: Սյունակների մի մասը գնում է խմբավորման ըստ, սյունակների մի մասը գնում է ագրեգատ ֆունկցիաների: Կա որտեղ, որը կարելի է ներկայացնել որպես խորանարդի կտոր: Ամբողջ խումբը կարելի է դիտարկել որպես պրոյեկցիա: Եվ այդ պատճառով այն կոչվում է տվյալների բազմաչափ վերլուծություն:

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

Իսկ ֆիզիկական ձևավորման առումով, թե ինչպես է այն տեղավորվում սեղանի վրա, նրանք սովորաբար նորմալացված ներկայացում են անում: Դուք կարող եք ապանորմալացնել, բայց դա թանկ է սկավառակի վրա և այնքան էլ արդյունավետ չէ հարցումների դեպքում: Հետևաբար, նրանք սովորաբար կազմում են նորմալացված ներկայացում, այսինքն՝ փաստերի աղյուսակ և շատ ու շատ չափումների աղյուսակներ:

Բայց այն լավ չի աշխատում ClickHouse-ում: Երկու պատճառ կա.

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

Եվ սրանից ելք կա ClickHouse-ում: նույնիսկ երկու.

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

• Միանալու կարիք չկա:
• Բարելավվող։ 2018 թվականի մարտից ի վեր հայտնվեց չփաստաթղթավորված հնարավորություն (դա չեք գտնի փաստաթղթերում)՝ մասնակիորեն թարմացնելու բառարանները, այսինքն՝ այն գրառումները, որոնք փոխվել են։ Գործնականում այն ​​նման է սեղանի։
• Միշտ հիշողության մեջ, ուստի բառարանի հետ միանալն ավելի արագ է աշխատում, քան եթե սեղան լիներ սկավառակի վրա և դեռ փաստ չէ, որ այն գտնվում է քեշում, ամենայն հավանականությամբ՝ ոչ:

• Ձեզ նույնպես միացումներ պետք չեն:
• Սա կոմպակտ 1-ից շատ ներկայացուցչություն է:
• Իսկ իմ կարծիքով զանգվածները պատրաստված են գիքերի համար։ Սրանք լամբդա ֆունկցիաներ են և այլն։

Սա կարմիր բառերի համար չէ։ Սա շատ հզոր ֆունկցիոնալություն է, որը թույլ է տալիս շատ բաներ անել շատ պարզ և էլեգանտ ձևով:

Տիպիկ օրինակներ, որոնք օգնում են լուծել զանգվածները: Այս օրինակները բավականին պարզ և պարզ են.

• Որոնում ըստ պիտակների: Եթե ​​այնտեղ հեշթեգներ ունեք և ցանկանում եք որոշ գրառումներ գտնել հեշթեգով:
• Որոնում ըստ բանալի-արժեքների զույգերի: Կան նաև արժեք ունեցող որոշ ատրիբուտներ:
• Բանալիների ցուցակների պահպանում, որոնք դուք պետք է թարգմանեք այլ բանի:

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

Իսկ ClickHouse-ում ձեզ հարկավոր չէ որևէ բան անել, բավական է նկարագրել հեշթեգների լարային զանգվածը կամ ստեղծել բանալու արժեքային համակարգերի համար տեղադրված կառույց:

Ներդրված կառուցվածքը չի կարող լավագույն անունը լինել: Սրանք երկու զանգվածներ են, որոնք ունեն ընդհանուր մաս անվան մեջ և հարակից որոշ բնութագրեր:

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

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

Կանոնավոր արտահայտությունը, որը կուզենայիք գրել, եթե այդ ամենը պահեիք մեկ տողում, դա առաջին հերթին անշնորհք կլիներ։ Եվ, երկրորդ, այն աշխատեց շատ ավելի երկար, քան երկու զանգված:

Մեկ այլ օրինակ. Դուք ունեք զանգված, որտեղ պահում եք ID-ն: Եվ դուք կարող եք դրանք թարգմանել անուններով: Գործառույթ arrayMap. Սա տիպիկ լամբդա ֆունկցիա է: Այնտեղ լամբդա արտահայտություններ ես փոխանցում։ Եվ նա բառարանից հանում է անվանման արժեքը յուրաքանչյուր ID-ի համար:

Որոնումը կարող է կատարվել նույն կերպ: Փոխանցվում է պրեդիկատ ֆունկցիա, որը ստուգում է, թե ինչ տարրեր են համընկնում:

Այս բաները մեծապես պարզեցնում են միացումը և լուծում մի շարք խնդիրներ:

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

• ClickHouse-ը հարցումների պլանավորող չունի: Բացարձակապես ոչ:
• Այնուամենայնիվ, բարդ հարցումները դեռ պետք է պլանավորվեն: Ո՞ր դեպքերում։
• Եթե ​​հարցումում մի քանի միացումներ կան, դուք դրանք փաթաթում եք ենթընտրանքների մեջ: Եվ կարևոր է դրանց կատարման հերթականությունը։
• Եվ երկրորդը, եթե խնդրանքը տարածվի: Քանի որ բաշխված հարցումում միայն ամենաներքին ենթընտրանքն է կատարվում բաշխված, իսկ մնացած ամեն ինչ փոխանցվում է մեկ սերվերի, որին միացել եք և այնտեղ գործարկվել: Հետևաբար, եթե դուք հարցումներ եք բաժանել բազմաթիվ միացումներով (միանալ), ապա դուք պետք է ընտրեք պատվերը:

Եվ նույնիսկ ավելի պարզ դեպքերում, երբեմն անհրաժեշտ է նաև կատարել ժամանակացույցի աշխատանքը և մի փոքր վերաշարադրել հարցումները։

Ահա մի օրինակ. Ձախ կողմում կա հարցում, որը ցույց է տալիս լավագույն 5 երկրները: Եվ դա տեւում է 2,5 վայրկյան, իմ կարծիքով։ Իսկ աջ կողմում՝ նույն հարցումը, բայց մի փոքր վերաշարադրված։ Տողով խմբավորելու փոխարեն մենք սկսեցինք խմբավորել ըստ բանալիի (int): Եվ դա ավելի արագ է: Եվ հետո արդյունքին միացրինք բառարան։ 2,5 վայրկյանի փոխարեն հարցումը տևում է 1,5 վայրկյան։ Սա լավ է.

Նմանատիպ օրինակ՝ վերագրանցման ֆիլտրերով։ Ահա մի խնդրանք Ռուսաստանին. Այն աշխատում է 5 վայրկյան: Եթե ​​մենք այն վերագրենք այնպես, որ նորից համեմատենք ոչ թե լարը, այլ թվերը Ռուսաստանին վերաբերող այդ բանալիների ինչ-որ հավաքածուի հետ, ապա դա շատ ավելի արագ կլինի։

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

• Առավելագույն աշխատանք բաշխված ռեժիմում:
• Տեսակավորում ըստ նվազագույն տեսակների, ինչպես ես արեցի ըստ ints-ի:
• Եթե ​​կան միացումներ (միացումներ), բառարաններ, ապա ավելի լավ է դրանք անել որպես վերջին միջոց, երբ արդեն ունեք տվյալներ գոնե մասամբ խմբավորված, ապա միանալու գործողությունը կամ բառարանային զանգը կկանչվի ավելի քիչ անգամ և ավելի արագ կլինի: .
• Զտիչների փոխարինում.

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

Անցնենք հաջորդ օրինակին։ X ընկերություն ԱՄՆ-ից։ Ինչ է նա անում?

Առաջադրանք կար.

• Գովազդային գործարքների օֆլայն կապում:
• Տարբեր կապող մոդելների մոդելավորում:

Ո՞րն է սցենարը:

Սովորական այցելուն գալիս է կայք, օրինակ՝ ամիսը 20 անգամ տարբեր գովազդներից, կամ հենց այդպես երբեմն գալիս է առանց գովազդի, քանի որ հիշում է այս կայքը։ Նայում է որոշ ապրանքներ, դնում է զամբյուղի մեջ, հանում զամբյուղից։ Եվ, ի վերջո, ինչ-որ բան գնում է:

Խելամիտ հարցեր. «Ո՞վ պետք է վճարի գովազդի համար, եթե անհրաժեշտ է»: և «Ի՞նչ գովազդ է ազդել նրա վրա, եթե այդպիսիք եղել են»: Այսինքն՝ ինչո՞ւ է գնել և ինչպե՞ս անել, որ այս մարդու նման մարդիկ նույնպես գնեն։

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

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

Կան բազմաթիվ պարտադիր մոդելներ:

Ամենատարածվածներն են.

• Վերջին փոխազդեցություն, որտեղ փոխազդեցությունը կամ սեղմում է կամ տպավորություն:
• Առաջին փոխազդեցություն, այսինքն՝ առաջին բանը, որը մարդուն բերեց կայք:
• Գծային համադրություն - բոլորը հավասարապես:
• Թուլացում.
• Եվ այսպես շարունակ։

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

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

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

Եվ երբ նրանք ցանկանում էին գործարքը կապել էկրանին, անմիջապես պարզվեց, որ դա այնքան էլ զվարճալի չէ: Իսկ ինչո՞ւ։ Կարելի է տեսնել, որ 30 անգամ ավելի շատ իրադարձություններ պետք է պահվեն: Եվ, համապատասխանաբար, ձեզ անհրաժեշտ են 30 անգամ ավելի շատ սերվերներ։ Եվ պարզվում է, որ սա ինչ-որ աստղագիտական ​​գործիչ է։ Կապակցումն անելու համար պահել մինչև 500 սերվեր, չնայած այն հանգամանքին, որ Runtime-ում զգալիորեն ավելի քիչ սերվերներ կան, ապա սա ինչ-որ սխալ ցուցանիշ է: Եվ նրանք սկսեցին մտածել, թե ինչ անել։

Եվ մենք գնացինք ClickHouse: Իսկ ինչպե՞ս դա անել ClickHouse-ում: Առաջին հայացքից թվում է, թե սա հակաօրինաչափությունների հավաքածու է։

• Գործարքն աճում է, մենք ավելի ու ավելի շատ իրադարձություններ ենք կապում դրան, այսինքն՝ այն փոփոխական է, և ClickHouse-ը այնքան էլ լավ չի աշխատում փոփոխվող օբյեկտների հետ:
• Երբ այցելուը գալիս է մեզ մոտ, մենք պետք է դուրս հանենք նրա գործարքները բանալիով՝ իր այցելության ID-ով: Սա նույնպես կետային հարցում է, նրանք դա չեն անում ClickHouse-ում: Սովորաբար ClickHouse-ն ունի մեծ …սկաներ, բայց այստեղ մենք պետք է որոշ գրառումներ ստանանք: Նաև հակապատկեր:
• Բացի այդ, գործարքը եղել է json-ով, բայց նրանք չէին ցանկանում այն ​​վերաշարադրել, ուստի ցանկանում էին պահել json-ը չկառուցված ձևով, և անհրաժեշտության դեպքում ինչ-որ բան հանել դրանից: Եվ սա նույնպես հակապատկեր է։

Այսինքն՝ հակապատկերների հավաքածու։

Բայց, այնուամենայնիվ, ստացվեց մի համակարգ, որը շատ լավ աշխատեց։

Ի՞նչ է արվել։ Հայտնվեց ClickHouse-ը, որի մեջ գցվեցին տեղեկամատյանները՝ բաժանված գրառումների։ Հայտնվեց վերագրվող ծառայություն, որը տեղեկամատյաններ էր ստանում ClickHouse-ից: Դրանից հետո, յուրաքանչյուր մուտքի համար, ըստ այցելության ID-ի, ես ստանում էի գործարքներ, որոնք կարող էին դեռևս մշակված չլինել, և գումարած snapshots, այսինքն՝ արդեն միացված գործարքները, մասնավորապես՝ նախորդ աշխատանքի արդյունքը: Ես դրանցից արդեն տրամաբանություն եմ արել, ընտրել եմ ճիշտ գործարքը, միացրել եմ նոր իրադարձություններ։ Նորից գրանցվեց: Մատյանը վերադարձավ ClickHouse, այսինքն՝ այն անընդհատ ցիկլային համակարգ է: Եվ բացի այդ, ես գնացի DWH՝ այնտեղ վերլուծելու։

Հենց այս տեսքով այն այնքան էլ լավ չէր աշխատում։ Եվ ClickHouse-ի համար ավելի հեշտ դարձնելու համար, երբ հարցում կար ըստ այցելության id-ի, նրանք այդ հարցումները խմբավորեցին 1-000 այցելության ID-ների բլոկների մեջ և հանեցին 2-000 մարդու համար նախատեսված բոլոր գործարքները: Եվ հետո ամեն ինչ ստացվեց:

Եթե ​​նայեք ClickHouse-ի ներսում, ապա այս ամենին սպասարկող ընդամենը 3 հիմնական աղյուսակ կա։

Առաջին աղյուսակը, որում բեռնվում են տեղեկամատյանները, և տեղեկամատյանները վերբեռնվում են գրեթե առանց մշակման:

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

Ահա SQL-ով գրված տեքստը. Կցանկանայի դրանում մի քանի կարևոր բան մեկնաբանել։

Առաջին կարևոր բանը ClickHouse-ում json-ից սյունակներ և դաշտեր հանելու հնարավորությունն է: Այսինքն՝ ClickHouse-ն ունի json-ի հետ աշխատելու որոշ մեթոդներ։ Նրանք շատ, շատ պարզունակ են։

visitParamExtractInt-ը թույլ է տալիս json-ից ատրիբուտներ հանել, այսինքն՝ առաջին հարվածն աշխատում է: Եվ այս կերպ դուք կարող եք դուրս հանել գործարքի ID-ն կամ այցելել id-ն: Այս անգամ.

Երկրորդ, այստեղ օգտագործվում է բարդ նյութականացված դաշտ: Ինչ է դա նշանակում? Սա նշանակում է, որ դուք չեք կարող այն տեղադրել աղյուսակի մեջ, այսինքն՝ այն տեղադրված չէ, այն հաշվարկվում և պահվում է տեղադրման ժամանակ: Կպցնելիս ClickHouse-ն անում է աշխատանքը ձեզ փոխարեն: Եվ այն, ինչ ձեզ ավելի ուշ պետք է, արդեն հանված է json-ից:

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

Երկրորդ կարևորը index_granularity-ն է։ Եթե ​​դուք տեսել եք MergeTree-ն, ապա դա սովորաբար 8 է ըստ լռելյայն index_granularity-ի: Ինչ է դա? Սա ցուցանիշի նոսրության պարամետրն է: ClickHouse-ում ինդեքսը նոսր է, այն երբեք չի ինդեքսավորում յուրաքանչյուր մուտք: Դա անում է ամեն 192 8 անգամ: Եվ սա լավ է, երբ շատ տվյալներ են պահանջվում հաշվարկել, բայց վատ է, երբ մի փոքր, քանի որ կա մեծ ծախս: Իսկ եթե նվազեցնում ենք ինդեքսի հատիկությունը, ապա կրճատում ենք վերադիրը։ Այն չի կարող կրճատվել մեկով, քանի որ կարող է բավարար հիշողություն չլինի: Ցուցանիշը միշտ պահվում է հիշողության մեջ:

Snapshot-ը նաև օգտագործում է ClickHouse-ի մի քանի այլ հետաքրքիր հնարավորություններ:

Նախ, դա AggregatingMergeTree-ն է: Իսկ AggregatingMergeTree-ն պահում է argMax, այսինքն՝ սա գործարքի վիճակն է, որը համապատասխանում է վերջին ժամանակի դրոշմանը: Գործարքները ստեղծվում են անընդհատ տվյալ այցելուի համար: Եվ այս գործարքի ամենավերջին վիճակում մենք ավելացրեցինք իրադարձություն և ունենք նոր վիճակ: Այն կրկին հարվածեց ClickHouse-ին: Եվ այս նյութականացված տեսակետում argMax-ի միջոցով մենք միշտ կարող ենք ստանալ ներկայիս վիճակը:

• Պարտադիրը «անջատված է» Runtime-ից:
• Պահվում և մշակվում է ամսական մինչև 3 միլիարդ գործարք: Սա ավելի մեծության կարգ է, քան Կասանդրայում էր, այսինքն՝ տիպիկ գործարքային համակարգում:
• 2x5 ClickHouse սերվերների կլաստեր: 5 սերվեր և յուրաքանչյուր սերվեր ունի կրկնօրինակ: Սա նույնիսկ ավելի քիչ է, քան Cassandra-ում էր՝ սեղմումների վրա հիմնված վերագրում կատարելու համար, և այստեղ մենք ունենք տպավորությունների վրա հիմնված: Այսինքն՝ սերվերների թիվը 30 անգամ ավելացնելու փոխարեն հաջողվել է կրճատել դրանք։

Եվ վերջին օրինակը ֆինանսական Y ընկերությունն է, որը վերլուծել է բաժնետոմսերի գների փոփոխությունների հարաբերակցությունը։

Իսկ առաջադրանքը հետևյալն էր.

• Կան մոտավորապես 5 բաժնետոմսեր:
• Հայտնի են մեջբերումներ յուրաքանչյուր 100 միլիվայրկանում:
• Տվյալները կուտակվել են 10 տարվա ընթացքում։ Ըստ երևույթին, որոշ ընկերությունների համար ավելի շատ, որոշների համար ավելի քիչ:
• Ընդհանուր առմամբ կա մոտավորապես 100 միլիարդ տող:

Եվ անհրաժեշտ էր հաշվարկել փոփոխությունների հարաբերակցությունը։

Ահա երկու բաժնետոմսեր և դրանց գնանշումները: Եթե ​​մեկը բարձրանում է, իսկ մյուսը՝ բարձրանում, ապա սա դրական հարաբերակցություն է, այսինքն՝ մեկը բարձրանում է, իսկ մյուսը՝ բարձրանում։ Եթե ​​մեկը բարձրանում է, ինչպես գրաֆիկի վերջում, իսկ մյուսը իջնում ​​է, ապա սա բացասական հարաբերակցություն է, այսինքն՝ երբ մեկը բարձրանում է, մյուսն ընկնում է։

Վերլուծելով այս փոխադարձ փոփոխությունները՝ կարելի է կանխատեսումներ անել ֆինանսական շուկայում։

Բայց խնդիրը բարդ է. Ի՞նչ է արվում սրա համար։ Մենք ունենք 100 միլիարդ գրառում, որոնք ունեն՝ ժամանակ, պաշար և գին: Մենք պետք է նախ հաշվարկենք գնային ալգորիթմից 100 միլիարդ անգամ մեծ տարբերությունը: RunningDifference-ը ClickHouse-ում ֆունկցիա է, որը հաջորդաբար հաշվարկում է երկու տողերի տարբերությունը:

Եվ դրանից հետո անհրաժեշտ է հաշվարկել հարաբերակցությունը, և հարաբերակցությունը պետք է հաշվարկվի յուրաքանչյուր զույգի համար: 5 բաժնետոմսերի համար զույգերը կազմում են 000 մլն. Եվ սա շատ է, այսինքն՝ 12,5 անգամ անհրաժեշտ է հաշվարկել հենց այդպիսի հարաբերակցության ֆունկցիա։

Եվ եթե ինչ-որ մեկը մոռացել է, ապա ͞x-ը և ͞y-ը մատ է: նմուշառման ակնկալիք: Այսինքն՝ պետք է ոչ միայն հաշվարկել արմատներն ու գումարները, այլ ևս մեկ գումար այս գումարների ներսում։ Հաշվարկների մի խումբ պետք է կատարվի 12,5 միլիոն անգամ և նույնիսկ խմբավորվի ըստ ժամերի: Մենք էլ շատ ժամեր ունենք։ Եվ դուք պետք է դա անեք 60 վայրկյանում։ Դա կատակ է:

Հարկավոր էր գոնե ինչ-որ կերպ ժամանակ ունենալ, քանի որ այս ամենը շատ ու շատ դանդաղ էր աշխատում մինչև ClickHouse-ի գալը։

Նրանք փորձել են հաշվարկել Hadoop-ի, Spark-ի, Greenplum-ի վրա։ Եվ այս ամենը շատ դանդաղ էր կամ թանկ: Այսինքն՝ կարելի էր ինչ-որ կերպ հաշվարկել, բայց հետո թանկ արժեր։

Եվ հետո եկավ ClickHouse-ը, և ամեն ինչ շատ ավելի լավացավ:

Հիշեցնում եմ, որ մենք տվյալների տեղայնացման խնդիր ունենք, քանի որ հարաբերակցությունները հնարավոր չէ տեղայնացնել։ Մենք չենք կարող տվյալների մի մասը դնել մի սերվերի վրա, մի մասը՝ մյուսի վրա և հաշվարկել, մենք պետք է ունենանք բոլոր տվյալները ամենուր։

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

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

Դրանից հետո այն կարող է կրկնօրինակվել: «r» տառը նշանակում է, որ մենք կրկնօրինակել ենք այս տվյալները: Այսինքն՝ մենք բոլոր երեք սերվերների վրա ունենք նույն տվյալները՝ սրանք զանգվածներն են։

Եվ հետո հատուկ սցենարով այս 12,5 միլիոն հարաբերակցությունների հավաքածուից, որոնք պետք է հաշվարկվեն, կարող եք փաթեթներ պատրաստել: Այսինքն՝ 2 առաջադրանք՝ 500 զույգ հարաբերակցություններով։ Եվ այս առաջադրանքը պետք է հաշվարկվի կոնկրետ ClickHouse սերվերի վրա: Նա ունի բոլոր տվյալները, քանի որ տվյալները նույնն են, և նա կարող է հաջորդաբար հաշվարկել դրանք։

Եվս մեկ անգամ այսպիսի տեսք ունի. Նախ՝ այս կառուցվածքում ունենք բոլոր տվյալները՝ ժամանակ, բաժնետոմսեր, գին: Այնուհետև մենք հաշվարկեցինք logReturn-ը, այսինքն՝ նույն կառուցվածքի տվյալները, բայց գնի փոխարեն արդեն ունենք logReturn։ Այնուհետև դրանք վերամշակվեցին, այսինքն՝ մենք ստացանք բաժնետոմսերի և գների ժամանակն ու խումբը: Կրկնօրինակված: Եվ դրանից հետո մենք ստեղծեցինք մի շարք առաջադրանքներ և դրանք կերակրեցինք ClickHouse-ին, որպեսզի այն հաշվի դրանք: Եվ դա աշխատում է:

Հայեցակարգի ապացուցման դեպքում առաջադրանքը ենթաառաջադրանք էր, այսինքն՝ ավելի քիչ տվյալներ են վերցվել: Եվ միայն երեք սերվեր:

Առաջին երկու փուլերը՝ Log_return-ի հաշվարկը և զանգվածների մեջ փաթաթելը տևեցին մոտ մեկ ժամ:

Իսկ հարաբերակցության հաշվարկը մոտ 50 ժամ է։ Բայց 50 ժամը քիչ է, քանի որ նախկինում շաբաթներով էին աշխատում։ Դա մեծ հաջողություն էր։ Եվ եթե հաշվեք, ապա վայրկյանում 70 անգամ ամեն ինչ հաշվել է այս կլաստերի վրա։

Բայց ամենակարևորն այն է, որ այս համակարգը գործնականում առանց խցանումների է, այսինքն՝ մասշտաբավորվում է գրեթե գծային: Եվ նրանք ստուգեցին այն: Հաջողությամբ մեծացրեց այն:

• Ճիշտ սխեման գործի կեսն է: Իսկ ճիշտ սխեման դա ClickHouse-ի բոլոր անհրաժեշտ տեխնոլոգիաների օգտագործումն է։
• Summing/AggregatingMergeTrees-ը տեխնոլոգիաներ են, որոնք թույլ են տալիս համախմբել կամ դիտարկել վիճակի պատկերը որպես հատուկ դեպք: Եվ դա մեծապես պարզեցնում է շատ բաներ:
• Նյութականացված դիտումները թույլ են տալիս շրջանցել մեկ ինդեքսի սահմանը: Միգուցե ես դա շատ պարզ չասացի, բայց երբ մենք բեռնեցինք տեղեկամատյանները, չմշակված տեղեկամատյանները աղյուսակում էին մեկ ինդեքսով, իսկ հատկանիշի տեղեկամատյանները՝ աղյուսակում, այսինքն՝ նույն տվյալները, միայն զտված էին, բայց ինդեքսը ամբողջությամբ էր։ մյուսները. Թվում է, թե նույն տվյալներն են, բայց տարբեր տեսակավորում: Իսկ Materialized Views-ը թույլ է տալիս, եթե դրա կարիքը ունեք, շրջանցեք ClickHouse-ի նման սահմանափակումը։
• Նվազեցրեք ինդեքսի հստակությունը կետային հարցումների համար:
• Եվ խելացիորեն տարածեք տվյալները, փորձեք հնարավորինս տեղայնացնել տվյալները սերվերի ներսում: Եվ փորձեք ապահովել, որ հարցումները նաև հնարավորինս օգտագործում են տեղայնացում, որտեղ հնարավոր է:

Եվ ամփոփելով այս կարճ ելույթը, կարող ենք ասել, որ ClickHouse-ն այժմ ամուր զբաղեցրել է ինչպես առևտրային տվյալների բազաների, այնպես էլ բաց կոդով տվյալների բազաների տարածքը, այսինքն՝ հատուկ վերլուծությունների համար: Նա հիանալի տեղավորվում է այս լանդշաֆտի մեջ: Եվ ավելին, այն սկսում է կամաց-կամաց դուրս մղել ուրիշներին, քանի որ երբ դուք ունեք ClickHouse, ձեզ InfiniDB-ի կարիք չկա: Vertika-ն շուտով կարող է անհրաժեշտ չլինել, եթե նրանք նորմալ SQL աջակցություն ապահովեն: Վայելե՛ք։

-Շնորհակալություն զեկույցի համար: Շատ հետաքրքիր! Կա՞ն համեմատություններ Apache Phoenix-ի հետ:

Ոչ, ես չեմ լսել, որ որևէ մեկը համեմատի: Մենք և Yandex-ը փորձում ենք հետևել ClickHouse-ի բոլոր համեմատություններին տարբեր տվյալների բազաների հետ: Քանի որ եթե հանկարծ ինչ-որ բան պարզվի, որ ավելի արագ է, քան ClickHouse-ը, ապա Լեշա Միլովիդովը չի կարող գիշերը քնել և սկսում է արագ արագացնել այն: Ես նման համեմատության մասին չեմ լսել։

• (Ալեքսեյ Միլովիդով) Apache Phoenix-ը SQL շարժիչ է, որն աշխատում է Hbase-ով: Hbase-ը հիմնականում նախատեսված է առանցքային արժեքի աշխատանքի սցենարի համար: Այնտեղ, յուրաքանչյուր տողում, կարող է լինել կամայական թվով սյունակներ կամայական անուններով: Սա կարելի է ասել այնպիսի համակարգերի մասին, ինչպիսիք են Hbase-ը, Cassandra-ն։ Եվ հենց ծանր վերլուծական հարցումներն են, որ նորմալ չեն աշխատի նրանց մոտ: Կամ դուք կարող եք մտածել, որ նրանք լավ են աշխատում, եթե դուք փորձ չեք ունեցել ClickHouse-ի հետ:

• Շնորհակալություն

  • Բարի օր Ինձ արդեն բավականին հետաքրքրում է այս թեման, քանի որ ես ունեմ վերլուծական ենթահամակարգ։ Բայց երբ նայում եմ ClickHouse-ին, ես զգում եմ, որ ClickHouse-ը շատ հարմար է իրադարձությունների վերլուծության համար՝ փոփոխական: Իսկ եթե ես պետք է վերլուծեմ շատ բիզնես տվյալներ մի փունջ մեծ աղյուսակներով, ապա ClickHouse-ը, որքան հասկանում եմ, այնքան էլ հարմար չէ ինձ համար: Հատկապես, եթե դրանք փոխվեն: Սա ճի՞շտ է, թե՞ կան օրինակներ, որոնք կարող են դա հերքել։

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

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

Իհարկե, սա ClickHouse-ի օգտագործումն է շատ կոնկրետ առաջադրանքի համար: Այն կարող էր ավելի ավանդաբար լուծվել Hadoop-ի շրջանակներում: Hadoop-ի համար սա իդեալական խնդիր է։ Բայց Hadoop-ում այն ​​շատ դանդաղ է ընթանում: Եվ իմ նպատակն է ցույց տալ, որ ClickHouse-ը կարող է լուծել առաջադրանքներ, որոնք սովորաբար լուծվում են բոլորովին այլ միջոցներով, բայց միևնույն ժամանակ դա անում է շատ ավելի արդյունավետ: Սա հարմարեցված է կոնկրետ առաջադրանքի համար: Հասկանալի է, որ եթե նման բանի հետ կապված խնդիր կա, ապա այն կարելի է լուծել նույն կերպ։

Պարզ է. Դուք ասացիք, որ 50 ժամը մշակվել է։ Արդյո՞ք դա հենց սկզբից է, երբ եք բեռնել տվյալները կամ ստացել արդյունքները:

Այո, այո:

Լավ, շատ շնորհակալ եմ.

Սա 3 սերվերի կլաստերի վրա է:

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

Իհարկե, իդեալական համակարգեր չկան։ Իսկ ClickHouse-ը նույնպես ունի իր խնդիրները։ Բայց լսե՞լ եք Yandex.Metrica-ի մասին, որ երկար ժամանակ չի աշխատում: Հավանաբար ոչ. Այն հուսալիորեն աշխատում է 2012-2013 թվականներից ClickHouse-ում: Նույնը կարող եմ ասել իմ փորձառության մասին։ Մենք երբեք լիակատար ձախողումներ չենք ունեցել։ Որոշ մասնակի բաներ կարող էին տեղի ունենալ, բայց դրանք երբեք այնքան քննադատական ​​չէին, որ լրջորեն ազդեին բիզնեսի վրա: Դա երբեք չի եղել: ClickHouse-ը բավականին հուսալի է և պատահականորեն չի խափանում: Դուք չունեք անհանգստանալու դրա մասին: Դա հում բան չէ: Դա ապացուցվել է բազմաթիվ ընկերությունների կողմից:

Բարեւ Ձեզ! Դուք ասացիք, որ դուք պետք է անմիջապես մտածեք տվյալների սխեմայի մասին: Իսկ եթե դա տեղի ունենար: Տվյալներս հորդում են ու թափվում։ Անցնում է վեց ամիս, և ես հասկանում եմ, որ անհնար է այսպես ապրել, ես պետք է նորից վերբեռնեմ տվյալները և ինչ-որ բան անեմ դրանց հետ:

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

Շնորհակալություն:

Source: www.habr.com