🥇Տեղափոխում ClickHouse՝ 3 տարի անց

Երեք տարի առաջ Յանդեքսից Վիկտոր Տարնավսկին և Ալեքսեյ Միլովիդովը բեմում Բարձր բեռնում ++ պատմեց, որքան լավ է ClickHouse-ը և ինչպես այն չի դանդաղում: Իսկ հաջորդ փուլում կար Ալեքսանդր Զայցև с հաշվետվություն տեղափոխվելու մասին clickhouse մեկ այլ վերլուծական DBMS-ից և այն եզրակացությամբ, որ clickhouse, իհարկե, լավ է, բայց ոչ շատ հարմար։ Երբ ընկերությունը 2016թ LifeStreet- ը, որտեղ Ալեքսանդրն այն ժամանակ աշխատում էր, փոխակերպում էր բազմաբայթանոց վերլուծական համակարգը clickhouse, դա մի հետաքրքրաշարժ «դեղին աղյուսով ճանապարհ» էր՝ լի անհայտ վտանգներով. clickhouse այն ժամանակ այն ականապատ դաշտի տեսք ուներ:

Երեք տարի անց clickhouse դարձավ շատ ավելի լավը. այս ընթացքում Ալեքսանդրը հիմնեց Altinity ընկերությունը, որը ոչ միայն օգնում է մարդկանց տեղափոխվել այնտեղ clickhouse տասնյակ նախագծեր, բայց նաև բարելավում է արտադրանքը ինքնին Yandex-ի գործընկերների հետ միասին: Հիմա clickhouse դեռ ոչ անհոգ զբոսանք, այլ ոչ էլ ականապատ դաշտ:

Ալեքսանդրը 2003 թվականից աշխատում է բաշխված համակարգերի հետ՝ մշակելով խոշոր նախագծեր MySQL, Oracle и Vertica. Վերջինի վրա HighLoad++ 2019 թ Օգտագործման առաջամարտիկներից Ալեքսանդր clickhouse, պատմեց, թե ինչ է հիմա այս DBMS-ը: Մենք կիմանանք հիմնական հատկանիշների մասին clickhouseԻնչպես է այն տարբերվում այլ համակարգերից և որ դեպքերում է ավելի արդյունավետ օգտագործել այն: Օգտվելով օրինակներից՝ մենք կդիտարկենք վերջին և նախագծով փորձարկված պրակտիկաները՝ հիմնված համակարգերի կառուցման համար clickhouse.

Հետահայաց՝ այն, ինչ տեղի ունեցավ 3 տարի առաջ

Երեք տարի առաջ մենք տեղափոխեցինք ընկերությունը LifeStreet- ը մասին clickhouse մեկ այլ վերլուծական տվյալների բազայից, և գովազդային ցանցի վերլուծական միգրացիան այսպիսի տեսք ուներ.

Հունիս 2016. Մեջ Բաց կոդով հայտնվել clickhouse և մեր նախագիծը սկսվեց;
օգոստոս. Հայեցակարգի ապացույցխոշոր գովազդային ցանց, ենթակառուցվածք և 200-300 տերաբայթ տվյալներ;
հոկտեմբեր. Առաջին արտադրության տվյալները;
դեկտեմբեր. Ապրանքի ամբողջական բեռը օրական 10-50 միլիարդ իրադարձություն է:
Հունիս 2017. Օգտատերերի հաջող միգրացիա դեպի clickhouse, 2,5 փետաբայթ տվյալներ 60 սերվերների կլաստերի վրա։

Միգրացիոն գործընթացի ընթացքում աճում էր այն ըմբռնումը, որ clickhouse լավ համակարգ է, որի հետ հաճելի է աշխատել, բայց սա Yandex-ի ներքին նախագիծն է։ Հետևաբար, կան նրբերանգներ. Yandex-ը նախ գործ կունենա իր ներքին հաճախորդների հետ, և միայն այնուհետև համայնքի և արտաքին օգտատերերի կարիքների հետ, իսկ ClickHouse-ն այնուհետև չհասավ ձեռնարկության մակարդակին շատ ֆունկցիոնալ ոլորտներում: Ահա թե ինչու մենք հիմնեցինք Altinity-ն 2017 թվականի մարտին, որպեսզի պատրաստենք clickhouse նույնիսկ ավելի արագ և հարմար ոչ միայն Yandex-ի, այլև այլ օգտատերերի համար: Իսկ հիմա մենք.

Մենք մարզվում և օգնում ենք լուծումներ ստեղծել՝ հիմնվելով clickhouse որպեսզի հաճախորդները փորձանքի մեջ չընկնեն, և որ լուծումն ի վերջո գործի.
Մենք տրամադրում ենք 24/7 աջակցություն clickhouse- տեղադրումներ;
Մենք մշակում ենք մեր սեփական էկոհամակարգային նախագծերը.
Մենք ակտիվորեն պարտավորվում ենք ինքներս մեզ clickhouse, պատասխանելով օգտատերերի հարցումներին, ովքեր ցանկանում են տեսնել որոշակի առանձնահատկություններ:

Եվ իհարկե, մենք օգնում ենք տեղափոխվելու հարցում clickhouse с MySQL, Vertica, Oracle, Greenplum, Redshift- ը և այլ համակարգեր։ Մենք ներգրավված ենք եղել տարբեր քայլերի մեջ, և դրանք բոլորն էլ հաջող են եղել:

Ինչու տեղափոխվել clickhouse

Չի դանդաղեցնում! Սա է հիմնական պատճառը։ clickhouse - շատ արագ տվյալների բազա տարբեր սցենարների համար.

Պատահական մեջբերումներ մարդկանցից, ովքեր երկար ժամանակ աշխատել են մարդկանց հետ clickhouse.

Մասշտաբայնություն. Ինչ-որ այլ տվյալների բազայում դուք կարող եք լավ կատարման հասնել մեկ սարքաշարի վրա, բայց clickhouse դուք կարող եք մասշտաբել ոչ միայն ուղղահայաց, այլև հորիզոնական՝ պարզապես սերվերներ ավելացնելով: Ամեն ինչ այնքան հարթ չի աշխատում, որքան մենք կցանկանայինք, բայց այն աշխատում է: Դուք կարող եք ընդլայնել համակարգը, քանի որ ձեր բիզնեսը մեծանում է: Կարևոր է, որ մենք այժմ սահմանափակված չլինենք լուծմամբ և միշտ կա զարգացման ներուժ։

Դյուրատարություն. Մի բանի հետ կապված չկա. Օրինակ, հետ Amazon RedShift Դժվար է ինչ-որ տեղ տեղափոխվել: Ա clickhouse դուք կարող եք տեղադրել այն ձեր նոութբուքի, սերվերի վրա, տեղակայել այն ամպի մեջ, գնալ Կուբերնետես — ենթակառուցվածքի շահագործման սահմանափակումներ չկան։ Սա հարմար է բոլորի համար, և սա մեծ առավելություն է, որով չեն կարող պարծենալ նմանատիպ բազմաթիվ այլ տվյալների բազաներ։

Ճկունություն. clickhouse կանգ չի առնում մի բանի վրա, օրինակ՝ Yandex.Metrica-ի վրա, այլ զարգանում և օգտագործվում է ավելի ու ավելի շատ տարբեր նախագծերում և ոլորտներում: Այն կարող է ընդլայնվել՝ ավելացնելով նոր հնարավորություններ՝ նոր խնդիրներ լուծելու համար: Օրինակ, ենթադրվում է, որ տեղեկամատյանները տվյալների բազայում պահելը վատ վարք է, ուստի նրանք եկան. Elasticsearch- ը. Բայց ճկունության շնորհիվ clickhouse, դրա մեջ կարող եք նաև տեղեկամատյաններ պահել, և հաճախ դա նույնիսկ ավելի լավ է, քան ներսում Elasticsearch- ը - ին clickhouse դրա համար անհրաժեշտ է 10 անգամ պակաս երկաթ:

Ազատ Open Source. Ոչ մի բանի համար պետք չէ վճարել: Համակարգը ձեր նոութբուքի կամ սերվերի վրա տեղադրելու թույլտվության շուրջ բանակցություններ վարելու կարիք չկա: Ոչ թաքնված վճարներ: Միևնույն ժամանակ, բաց կոդով տվյալների բազայի ոչ մի այլ տեխնոլոգիա չի կարող մրցակցել արագությամբ clickhouse. MySQL, MariaDB, Greenplum - նրանք բոլորն էլ շատ ավելի դանդաղ են:

Համայնք, քշել և զվարճանք. At clickhouse հիանալի համայնք. հանդիպումներ, զրույցներ և Ալեքսեյ Միլովիդով, ով բոլորիս գանձում է իր էներգիայով և լավատեսությամբ:

Տեղափոխվելով ClickHouse

Գնալ clickhouse ինչ-ինչ պատճառներով ձեզ հարկավոր է ընդամենը երեք բան.

Հասկացեք սահմանափակումները clickhouse և ինչի համար դա հարմար չէ:
Օգտվել տեխնոլոգիան և դրա ամենամեծ առավելությունները:
Փորձարկում. Նույնիսկ հասկանալով, թե ինչպես է այն աշխատում clickhouse, միշտ չէ, որ հնարավոր է կանխատեսել, թե երբ կլինի ավելի արագ, երբ ավելի դանդաղ, երբ ավելի լավ և երբ ավելի վատ։ Այսպիսով, փորձեք այն:

Շարժվող խնդիր

Միայն մեկ «բայց» կա՝ եթե տեղափոխվես clickhouse մեկ այլ բանից, ապա սովորաբար ինչ-որ բան սխալ է լինում: Մենք սովոր ենք որոշ պրակտիկաների և բաների, որոնք աշխատում են մեր սիրելի տվյալների բազայում: Օրինակ, ցանկացած մեկի հետ աշխատող SQL-շտեմարանները պարտադիր են համարում գործառույթների հետևյալ շարքը.

գործարքներ;
սահմանափակումներ;
հետեւողականություն;
ինդեքսներ;
ԹԱՐՄԱՑՆԵԼ/ՋՆԵԼ;
NULL-ներ;
միլիվայրկյաններ;
ավտոմատ տիպի ձուլվածքներ;
բազմակի միացումներ;
կամայական միջնապատեր;
կլաստերի կառավարման գործիքներ.

Հավաքագրումը պարտադիր է, բայց երեք տարի առաջ clickhouse Այս գործառույթներից ոչ մեկը հասանելի չէր: Այժմ մնացել է չիրագործվածի կեսից պակասը՝ գործարքներ, սահմանափակումներ, հետևողականություն, միլիվայրկյաններ և տիպի ձուլում:

Եվ գլխավորն այն է, որ ներս clickhouse որոշ ստանդարտ պրակտիկաներ և մոտեցումներ չեն գործում կամ աշխատում են այլ կերպ, քան մենք սովոր ենք: Այն ամենը, ինչ հայտնվում է clickhouse, համապատասխանում է "ClickHouse ճանապարհը«, այսինքն. գործառույթները տարբերվում են այլ տվյալների բազաներից: Օրինակ:

Ինդեքսները ընտրված չեն, բայց բաց են թողնվել:
ԹԱՐՄԱՑՆԵԼ/ՋՆԵԼ ոչ թե սինխրոն, այլ ասինխրոն։
Կան բազմաթիվ միացումներ, բայց չկա հարցումների պլանավորող: Ինչպես են դրանք այնուհետև կատարվում, ընդհանուր առմամբ այնքան էլ պարզ չէ տվյալների բազայի աշխարհի մարդկանց համար:

ClickHouse-ի սցենարներ

1960 թվականին հունգարական ծագումով ամերիկացի մաթեմատիկոս Wigner EP հոդված է գրել»Մաթեմատիկայի անհիմն արդյունավետությունը բնական գիտություններում» («Մաթեմատիկայի անհասկանալի արդյունավետությունը բնական գիտություններում»), որ մեզ շրջապատող աշխարհը չգիտես ինչու լավ նկարագրված է մաթեմատիկական օրենքներով: Մաթեմատիկան վերացական գիտություն է, և մաթեմատիկական ձևով արտահայտված ֆիզիկական օրենքները չնչին չեն, և Wigner EP ընդգծեց, որ սա շատ տարօրինակ է.

Իմ տեսանկյունից, clickhouse - նույն տարօրինակությունը. Վիգներին վերաձեւակերպելու համար կարող ենք այսպես ասել. աներեւակայելի արդյունավետությունը ապշեցուցիչ է. clickhouse վերլուծական հավելվածների լայն տեսականիով:

Օրինակ՝ վերցնենք Իրական ժամանակի տվյալների պահեստ, որի մեջ տվյալները բեռնվում են գրեթե անընդհատ: Մենք ուզում ենք նրանից հարցումներ ստանալ երկրորդ ուշացումով։ Խնդրում եմ - օգտագործեք այն clickhouse, քանի որ սա այն սցենարն է, որի համար նախատեսված էր: clickhouse հենց այսպես է այն օգտագործվում ոչ միայն համացանցում, այլ նաև մարքեթինգի և ֆինանսական վերլուծության մեջ, AdTecժ, ինչպես նաև ներս Խարդախության հայտնաբերումn. IN Իրական ժամանակի տվյալների պահեստ օգտագործվում է բարդ կառուցվածքային սխեման, ինչպիսին է «աստղը» կամ «ձյան փաթիլը», բազմաթիվ աղյուսակներ ՄԻԱՑԵՔ (երբեմն բազմակի), և տվյալները սովորաբար պահվում և փոխվում են որոշ համակարգերում:

Վերցնենք մեկ այլ սցենար. Ժամանակային շարքՍարքերի, ցանցերի մոնիտորինգ, օգտագործման վիճակագրություն, իրերի ինտերնետ: Այստեղ մենք հանդիպում ենք ժամանակին պատվիրված բավականին պարզ իրադարձությունների։ clickhouse ի սկզբանե չի մշակվել դրա համար, բայց ցույց է տվել, որ լավ է աշխատում, այդ իսկ պատճառով խոշոր ընկերությունները օգտագործում են clickhouse որպես տեղեկատվության մոնիտորինգի պահոց: Պարզելու համար, թե արդյոք դա հարմար է clickhouse ժամանակային շարքերի համար մենք հենանիշ ենք կազմել՝ հիմնվելով մոտեցման և արդյունքների վրա Ներխուժում и TimescaleDB - մասնագիտացված ժամանակային շարքեր տվյալների բազաներ։ ՊարզվեցՈր clickhouse, նույնիսկ առանց նման առաջադրանքների օպտիմալացման, հաղթում է օտար դաշտում.

В ժամանակային շարքեր Սովորաբար օգտագործվում է նեղ աղյուսակ՝ մի քանի փոքր սյունակներ: Շատ տվյալներ կարող են ստացվել մոնիտորինգից՝ միլիոնավոր գրառումներ վայրկյանում, և դրանք սովորաբար լինում են փոքր պոռթկումներով (իրական ժամանակում հոսքային): Հետևաբար, անհրաժեշտ է ներդիրի այլ սցենար, և հարցումներն իրենք ունեն իրենց առանձնահատկությունները:

տեղեկամատյան կառավարում. Տվյալների բազայում տեղեկամատյանների հավաքումը սովորաբար վատ է, բայց clickhouse դա կարելի է անել վերը նկարագրված որոշ մեկնաբանություններով: Շատ ընկերություններ օգտագործում են clickhouse հենց այս նպատակով: Այս դեպքում մենք օգտագործում ենք հարթ լայն սեղան, որտեղ մենք պահում ենք ամբողջ տեղեկամատյանները (օրինակ, ձևով JSON), կամ կտրել կտորներով: Տվյալները սովորաբար բեռնվում են մեծ խմբաքանակներով (ֆայլեր), և մենք որոնում ենք ըստ որոշակի դաշտի:

Այս գործառույթներից յուրաքանչյուրի համար սովորաբար օգտագործվում են մասնագիտացված տվյալների բազաներ: clickhouse կարելի է անել ամեն ինչ և այնքան լավ, որ գերազանցում է նրանց: Հիմա եկեք ավելի սերտ նայենք ժամանակային շարքեր սցենար, և ինչպես ճիշտ «եփել»: clickhouse այս սցենարի համար:

Ժամանակային շարք

Ներկայումս սա է հիմնական սցենարը, որի համար clickhouse համարվում է ստանդարտ լուծում: Ժամանակային շարքեր ժամանակի ընթացքում դասավորված իրադարձությունների մի շարք է, որը ներկայացնում է ժամանակի ընթացքում ինչ-որ գործընթացի փոփոխությունները: Օրինակ, սա կարող է լինել օրվա սրտի հաճախականությունը կամ համակարգում կատարվող գործընթացների քանակը: Այն ամենը, ինչ ժամանակին տալիս է որոշակի չափսեր, դա է ժամանակային շարքեր:

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

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

Ներկայումս նկատվում է մասնագիտացված տվյալների բազաների աճ, որոնք չափում են ժամանակային շարքեր. Առցանց DB- շարժիչներ Տարբեր տվյալների բազաները ինչ-որ կերպ դասավորված են, և դուք կարող եք դրանք դիտել ըստ տեսակի.

Ամենաարագ աճող տեսակն է ժամանակային շարքերս. Գրաֆիկական տվյալների բազաները նույնպես աճում են, բայց ժամանակային շարքերվերջին մի քանի տարիների ընթացքում դրանք ավելի արագ են աճում: Տվյալների բազաների այս ընտանիքի տիպիկ ներկայացուցիչներն են Ներխուժում, Պրոմեթեւս, KDB, TimescaleDB (կառուցված PostgreSQL), լուծումներ Amazon. clickhouse կարող է օգտագործվել նաև այստեղ և օգտագործվում է։ Թույլ տվեք ձեզ մի քանի հրապարակային օրինակներ բերել:

Առաջատարներից մեկն ընկերությունն է CloudFlare (CDN- մատակարար): Նրանք վերահսկում են իրենց CDN միջոցով clickhouse (DNS- հարցումներ, HTTP-հարցումներ) հսկայական ծանրաբեռնվածությամբ՝ վայրկյանում 6 միլիոն իրադարձություն: Ամեն ինչ անցնում է Kafka, գնում է clickhouse, որը հնարավորություն է տալիս իրական ժամանակում տեսնել համակարգում տեղի ունեցող իրադարձությունների վահանակները։

Comcast - ԱՄՆ-ում հեռահաղորդակցության առաջատարներից մեկը՝ ինտերնետ, թվային հեռուստատեսություն, հեռախոսակապ: Նրանք ստեղծել են նմանատիպ կառավարման համակարգ CDN ներսում Open Source ծրագրի նախագիծը Apache Traffic Control աշխատել ձեր հսկայական տվյալների հետ: clickhouse օգտագործվում է որպես հետին պլան վերլուծության համար:

Պերկոնա ներկառուցված clickhouse ձեր ներսում PMMտարբեր մոնիտորինգի պահպանման համար MySQL.

Հատուկ պահանջներ

Ժամանակային շարքերի տվյալների բազաները ունեն իրենց հատուկ պահանջները:

Արագ ներդրում բազմաթիվ գործակալներից. Մենք պետք է շատ արագ մուտքագրենք տվյալներ շատ հոսքերից։ clickhouse Դա լավ է անում, քանի որ նրա բոլոր ներդիրները չեն արգելափակում: Ցանկացած տեղադրել նոր ֆայլ է սկավառակի վրա, և փոքր ներդիրները կարող են այս կամ այն կերպ բուֆերացվել: IN clickhouse Ավելի լավ է տվյալները զետեղել մեծ խմբաքանակներով, քան մեկ տողով:
Ճկուն սխեմա: Մեջ ժամանակային շարքեր մենք սովորաբար ամբողջությամբ չգիտենք տվյալների կառուցվածքը: Հնարավոր է կառուցել մոնիտորինգի համակարգ կոնկրետ հավելվածի համար, բայց հետո դժվար է այն օգտագործել մեկ այլ հավելվածի համար: Սա պահանջում է ավելի ճկուն սխեմա: clickhouse, թույլ է տալիս դա անել, չնայած այն խիստ տպագրված հիմք է:
Արդյունավետ պահեստավորում և տվյալների մոռացում. Սովորաբար ներս ժամանակային շարքեր հսկայական քանակությամբ տվյալներ, ուստի դրանք պետք է հնարավորինս արդյունավետ կերպով պահպանվեն: Օրինակ, ժամը Ներխուժում լավ սեղմումը նրա հիմնական առանձնահատկությունն է: Բայց բացի պահեստավորումից, դուք նաև պետք է կարողանաք «մոռանալ» հին տվյալները և ինչ-որ բան անել նվազեցման նմուշառում - ագրեգատների ավտոմատ հաշվարկ:
Արագ հարցումներ ագրեգացված տվյալների վրա. Երբեմն հետաքրքիր է վերջին 5 րոպեներին նայել միլիվայրկյանների ճշտությամբ, սակայն ամսական տվյալների րոպեների կամ վայրկյանների հստակեցման կարիքը կարող է լինել. ընդհանուր վիճակագրությունը բավական է: Նման աջակցությունն անհրաժեշտ է, հակառակ դեպքում 3 ամսվա խնդրանքը շատ երկար ժամանակ կպահանջի նույնիսկ մինչև վերջ clickhouse.
Նման խնդրանքներվերջին կետը, առ». Սրանք բնորոշ են ժամանակային շարքեր հարցումներ. դիտեք համակարգի վերջին չափումը կամ վիճակը որոշակի պահին t. Սրանք տվյալների բազայի համար այնքան էլ հաճելի հարցումներ չեն, բայց դուք նույնպես պետք է կարողանաք դրանք կատարել:
«Սոսնձում» ժամանակային շարք. Ժամանակային շարքեր ժամանակային շարք է: Եթե կան երկու ժամանակային շարքեր, դրանք հաճախ պետք է միացվեն և փոխկապակցվեն: Հարմար չէ դա անել բոլոր տվյալների շտեմարաններում, հատկապես չհավասարեցված ժամանակային շարքերի դեպքում. ահա որոշ ժամանակային կետեր, կան ուրիշներ: Դուք կարող եք միջին համարել, բայց հանկարծ այնտեղ դեռ անցք կլինի, ուստի պարզ չէ:

Տեսնենք, թե ինչպես են այդ պահանջները բավարարվում clickhouse.

Ծրագիրը

В clickhouse սխեման համար ժամանակային շարքեր կարող է կատարվել տարբեր ձևերով՝ կախված տվյալների օրինաչափության աստիճանից։ Կարելի է համակարգ կառուցել սովորական տվյալների վրա, երբ մենք նախապես գիտենք բոլոր ցուցանիշները: Օրինակ՝ ես սա արեցի CloudFlare մոնիտորինգով CDN լավ օպտիմիզացված համակարգ է: Դուք կարող եք կառուցել ավելի ընդհանուր համակարգ, որը վերահսկում է ամբողջ ենթակառուցվածքը և տարբեր ծառայություններ: Անկանոն տվյալների դեպքում մենք նախապես չգիտենք, թե ինչ ենք վերահսկում, և սա, հավանաբար, ամենատարածված դեպքն է։

Կանոնավոր տվյալներ. Սյունակներ. Սխեման պարզ է՝ սյունակներ՝ պահանջվող տեսակներով.

CREATE TABLE cpu (
  created_date Date DEFAULT today(),  
  created_at DateTime DEFAULT now(),  
  time String,  
  tags_id UInt32,  /* join to dim_tag */
  usage_user Float64,  
  usage_system Float64,  
  usage_idle Float64,  
  usage_nice Float64,  
  usage_iowait Float64,  
  usage_irq Float64,  
  usage_softirq Float64,  
  usage_steal Float64,  
  usage_guest Float64,  
  usage_guest_nice Float64
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Սա սովորական աղյուսակ է, որը վերահսկում է համակարգի բեռնման որոշակի գործունեությունը (Տեղ, համակարգ, պարապ, գեղեցիկ) Պարզ և հարմար, բայց ոչ ճկուն: Եթե մենք ուզում ենք ավելի ճկուն սխեմա, ապա կարող ենք օգտագործել զանգվածներ։

Անկանոն տվյալներ. Զանգվածներ:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  )
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

Կառուցվածք Բույն երկու զանգված են. metrics.name и չափումներ.արժեք. Այստեղ դուք կարող եք պահել այնպիսի կամայական մոնիտորինգի տվյալներ, ինչպիսիք են անունների զանգվածը և չափումների զանգվածը յուրաքանչյուր իրադարձության համար: Հետագա օպտիմալացման համար նման մեկ կառուցվածքի փոխարեն կարող եք մի քանիսը պատրաստել։ Օրինակ, մեկը համար բոց-արժեք, մեկ այլ՝ համար int- նշանակում է, որովհետև int Ես ուզում եմ ավելի արդյունավետ պահել:

Բայց նման կառույցն ավելի դժվար է մուտք գործել։ Դուք պետք է օգտագործեք հատուկ կոնստրուկցիա՝ օգտագործելով հատուկ գործառույթներ՝ սկզբում ինդեքսի և այնուհետև զանգվածի արժեքները հանելու համար.

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

Բայց դա դեռ բավականին արագ է աշխատում: Անկանոն տվյալների պահպանման մեկ այլ եղանակ է տողով:

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

CREATE TABLE cpu_rlc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metric_name LowCardinality(String),  
  metric_value Float64
) ENGINE = MergeTree(created_date, (metric_name, tags_id, created_at), 8192);


SELECT 
    maxIf(metric_value, metric_name = 'usage_user'),
    ... 
FROM cpu_r
WHERE metric_name IN ('usage_user', ...)

clickhouse հաղթահարում է դա, այն ունի հատուկ ընդարձակումներ clickhouse SQL. Օրինակ, առավելագույնը Եթե — հատուկ ֆունկցիա, որը հաշվարկում է առավելագույնը մետրիկով, երբ ինչ-որ պայման բավարարված է: Դուք կարող եք գրել մի քանի նման արտահայտություններ մեկ հարցում և անմիջապես հաշվարկել արժեքը մի քանի չափումների համար:

Եկեք համեմատենք երեք մոտեցում.

Մանրամասն

Այստեղ ես ավելացրել եմ «Սկավառակի տվյալների չափը» որոշ թեստային տվյալների հավաքածուի համար: Սյունակների դեպքում մենք ունենք տվյալների ամենափոքր չափը՝ առավելագույն սեղմում, հարցման առավելագույն արագություն, բայց մենք վճարում ենք՝ ստիպված լինելով ամեն ինչ միանգամից գրանցել։

Զանգվածների դեպքում ամեն ինչ մի փոքր ավելի վատ է։ Տվյալները դեռ լավ սեղմված են, և անկանոն օրինակ կարող է պահպանվել: Բայց clickhouse - սյունակային տվյալների բազա, և երբ մենք սկսում ենք ամեն ինչ պահել զանգվածում, այն վերածվում է մեկ շարքի, և մենք վճարում ենք ճկունության համար արդյունավետությամբ: Ցանկացած գործողության համար դուք ստիպված կլինեք կարդալ ամբողջ զանգվածը հիշողության մեջ, այնուհետև գտնել դրա մեջ ցանկալի տարրը, և եթե զանգվածը մեծանում է, ապա արագությունը նվազում է:

Այս մոտեցումն օգտագործող ընկերություններից մեկում (օրինակ. Uber), զանգվածները կտրված են 128 տարրի կտորների։ 200 ՏԲ տվյալների/օրական ծավալով մի քանի հազար չափումների տվյալները պահվում են ոչ թե մեկ զանգվածում, այլ 10 կամ 30 զանգվածում՝ հատուկ պահպանման տրամաբանությամբ։

Ամենապարզ մոտեցումը լարերի հետ է: Սակայն տվյալները վատ են սեղմված, աղյուսակի չափը մեծ է, և նույնիսկ երբ հարցումները հիմնված են մի քանի չափումների վրա, ClickHouse-ը օպտիմալ կերպով չի աշխատում:

Հիբրիդային սխեմա

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

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  ),
  usage_user Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_user')],
  usage_system Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_system')]
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Տեղադրելիս clickhouse ինքնաբերաբար կհաշվի դրանք: Այս կերպ Դուք կարող եք համատեղել բիզնեսը հաճույքի հետ. սխեման ճկուն է և ընդհանուր, բայց մենք հանեցինք ամենահաճախ օգտագործվող սյունակները: Նկատի ունեցեք, որ դա չէր պահանջում փոխել ներդիրը և ETLորը շարունակում է զանգվածներ տեղադրել աղյուսակում: Մենք պարզապես արեցինք ALTER TABLE, ավելացրեց մի քանի բարձրախոս, և մենք ստացանք հիբրիդային և ավելի արագ սխեման, որը կարող եք անմիջապես սկսել օգտագործել:

Կոդեկներ և սեղմում

Համար ժամանակային շարքեր Կարևոր է, թե որքան լավ եք փաթեթավորում տվյալները, քանի որ տեղեկատվության քանակը կարող է շատ մեծ լինել: IN clickhouse Գոյություն ունի գործիքների մի շարք՝ սեղմման էֆեկտի հասնելու համար 1:10, 1:20 և երբեմն ավելի շատ: Սա նշանակում է, որ 1 ՏԲ չփաթեթավորված տվյալները սկավառակի վրա զբաղեցնում է 50-100 ԳԲ: Ավելի փոքր չափը լավ է, տվյալները կարող են ավելի արագ կարդալ և մշակվել:

Սեղմման բարձր մակարդակի հասնելու համար, clickhouse աջակցում է հետևյալ կոդեկներին.

Օրինակ աղյուսակ.

CREATE TABLE benchmark.cpu_codecs_lz4 (
    created_date Date DEFAULT today(), 
    created_at DateTime DEFAULT now() Codec(DoubleDelta, LZ4), 
    tags_id UInt32, 
    usage_user Float64 Codec(Gorilla, LZ4), 
    usage_system Float64 Codec(Gorilla, LZ4), 
    usage_idle Float64 Codec(Gorilla, LZ4), 
    usage_nice Float64 Codec(Gorilla, LZ4), 
    usage_iowait Float64 Codec(Gorilla, LZ4), 
    usage_irq Float64 Codec(Gorilla, LZ4), 
    usage_softirq Float64 Codec(Gorilla, LZ4), 
    usage_steal Float64 Codec(Gorilla, LZ4), 
    usage_guest Float64 Codec(Gorilla, LZ4), 
    usage_guest_nice Float64 Codec(Gorilla, LZ4), 
    additional_tags String DEFAULT ''
)
ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Այստեղ մենք սահմանում ենք կոդեկը DoubleDelta մի դեպքում, երկրորդում՝ Գորիլա, և մենք անպայման կավելացնենք ավելին LZ4 սեղմում. Արդյունքում սկավառակի տվյալների չափը զգալիորեն կրճատվում է.

Սա ցույց է տալիս, թե որքան տարածք են զբաղեցնում նույն տվյալները, բայց օգտագործելով տարբեր կոդեկներ և սեղմումներ.

սկավառակի վրա GZIP ֆայլում;
ClickHouse-ում առանց կոդեկների, բայց ZSTD սեղմումով;
ClickHouse-ում՝ կոդեկներով և սեղմելով LZ4 և ZSTD:

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

Չափը կարեւոր է

Ոչ պակաս կարևոր выбрать ճիշտ տվյալների տեսակը.

Վերը նշված բոլոր օրինակներում ես օգտագործել եմ Բոց64. Բայց եթե ընտրեինք Բոց32, ապա դա ավելի լավ կլիներ: Դա լավ ցույց տվեցին Պերկոնայի տղաները վերը նշված հոդվածում։ Կարևոր է օգտագործել առավել կոմպակտ տեսակը, որը հարմար է առաջադրանքի համար. նույնիսկ ավելի քիչ սկավառակի չափի համար, քան հարցման արագության համար: clickhouse սա շատ զգայուն է:

Եթե կարող եք օգտագործել int32 փոխարենը int64, ապա սպասեք կատարողականի գրեթե կրկնակի աճ: Տվյալները ավելի քիչ հիշողություն են խլում, և բոլոր «թվաբանությունը» շատ ավելի արագ է աշխատում: clickhouse Ներքին առումով այն շատ խիստ տպագրված համակարգ է, այն առավելագույնս օգտագործում է ժամանակակից համակարգերի ընձեռած բոլոր հնարավորությունները:

Ագրեգացիա և Նյութականացված տեսակետներ

Համախմբումը և նյութականացված տեսակետները թույլ են տալիս ստեղծել ագրեգատներ տարբեր առիթների համար.

Օրինակ, դուք կարող եք ունենալ ոչ համախմբված աղբյուրի տվյալներ, և կարող եք դրանց կցել տարբեր նյութականացված դիտումներ՝ ավտոմատ գումարման միջոցով հատուկ շարժիչի միջոցով: SummingMergeTree (SMT). SMT հատուկ ագրեգացիոն տվյալների կառուցվածք է, որն ավտոմատ կերպով հաշվարկում է ագրեգատները: Հում տվյալները տեղադրվում են տվյալների բազայում, դրանք ավտոմատ կերպով համախմբվում են, և վահանակները կարող են անմիջապես օգտագործվել դրա վրա:

TTL - «մոռանալ» հին տվյալները

Ինչպե՞ս «մոռանալ» այն տվյալները, որոնք այլևս անհրաժեշտ չեն: clickhouse գիտի, թե ինչպես դա անել: Աղյուսակներ ստեղծելիս կարող եք նշել TTL արտահայտություններ. օրինակ, որ մենք պահում ենք րոպեական տվյալներ մեկ օրվա համար, օրական տվյալները 30 օրվա ընթացքում և երբեք չենք շոշափում շաբաթական կամ ամսական տվյալները.

CREATE TABLE aggr_by_minute
…
TTL time + interval 1 day

CREATE TABLE aggr_by_day
…
TTL time + interval 30 day

CREATE TABLE aggr_by_week
…
/* no TTL */

Բազմաշերտ - տվյալների բաժանել սկավառակների վրա

Հետևելով այս գաղափարին, տվյալները կարող են պահպանվել clickhouse տարբեր վայրերում. Ենթադրենք, որ մենք ցանկանում ենք պահպանել թեժ տվյալները վերջին շաբաթվա համար շատ արագ տեղանքի վրա SSD, իսկ ավելի շատ պատմական տվյալներ ենք դնում մեկ այլ տեղ։ IN clickhouse սա այժմ հնարավոր է.

Դուք կարող եք կարգավորել պահպանման քաղաքականությունը (պահպանման քաղաքականություն) Այսպիսով clickhouse որոշակի պայմանների հասնելուց հետո ավտոմատ կերպով տվյալներ կփոխանցի մեկ այլ պահեստ:

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

CREATE TABLE 
... 
TTL date + INTERVAL 7 DAY TO VOLUME 'cold_volume', 
    date + INTERVAL 180 DAY DELETE

Եզակի հնարավորություններ clickhouse

Գրեթե ամեն ինչում clickhouse Կան այդպիսի «կարևորություններ», բայց դրանք փոխհատուցվում են բացառիկությամբ, մի բան, որը չկա այլ տվյալների բազաներում: Օրինակ, այստեղ կան եզակի առանձնահատկություններ clickhouse:

Զանգվածներ: Մեջ clickhouse զանգվածների շատ լավ աջակցություն, ինչպես նաև դրանց վրա բարդ հաշվարկներ կատարելու ունակություն:
Տվյալների կառուցվածքների համախմբում. Սա «մարդասպանի հատկանիշներից» է. clickhouse. Չնայած այն հանգամանքին, որ Yandex-ի տղաները ասում են, որ մենք չենք ուզում տվյալների համախմբում, ամեն ինչ ագրեգացված է. clickhouse, քանի որ դա արագ է և հարմար։
Նյութականացված հայացքներ. Տվյալների ագրեգացման կառուցվածքների հետ միասին նյութականացված դիտումները թույլ են տալիս հարմարեցնել իրական ժամանակում ագրեգացիա.
ClickHouse SQL. Սա լեզվի ընդլայնում է SQL որոշ լրացուցիչ և բացառիկ հնարավորություններով, որոնք հասանելի են միայն clickhouse. Նախկինում դա նման էր մի կողմից ընդլայնման, իսկ մյուս կողմից՝ թերության։ Այժմ գրեթե բոլոր թերությունները համեմատ SQL 92 մենք այն հանեցինք, հիմա դա ընդամենը ընդլայնում է:
lambda-արտահայտությունները. Արդյո՞ք դրանք դեռևս որևէ տվյալների բազայում են:
ML- աջակցություն. Սա հասանելի է տարբեր տվյալների բազաներում, ոմանք ավելի լավն են, ոմանք ավելի վատ:
Բաց կոդով. Մենք կարող ենք ընդլայնել clickhouse միասին. Այժմ ներս clickhouse մոտ 500 ներդրող, և այս թիվը անընդհատ աճում է։

Բարդ հարցումներ

В clickhouse նույն բանն անելու շատ տարբեր եղանակներ կան: Օրինակ, դուք կարող եք վերադարձնել վերջին արժեքը աղյուսակից երեք տարբեր եղանակներով CPU (կա նաև չորրորդը, բայց այն էլ ավելի էկզոտիկ է):

Առաջինը ցույց է տալիս, թե որքան հարմար է դա անել clickhouse հարցումներ, երբ ցանկանում եք դա ստուգել շղարշ ենթահարցում պարունակվող. Սա մի բան է, որն անձամբ ես իսկապես բաց թողեցի այլ տվյալների բազաներում: Եթե ես ուզում եմ ինչ-որ բան համեմատել ենթհարցման հետ, ապա այլ տվյալների բազաներում դրա հետ կարելի է համեմատել միայն սկալարը, բայց մի քանի սյունակների համար պետք է գրել. ՄԻԱՑԵՔ: Մեջ clickhouse Դուք կարող եք օգտագործել tuple:

SELECT *
  FROM cpu 
 WHERE (tags_id, created_at) IN 
    (SELECT tags_id, max(created_at)
        FROM cpu 
        GROUP BY tags_id)

Երկրորդ մեթոդն անում է նույն բանը, բայց օգտագործում է ագրեգատ ֆունկցիա argMax:

SELECT 
    argMax(usage_user), created_at),
    argMax(usage_system), created_at),
...
 FROM cpu

В clickhouse կան մի քանի տասնյակ ագրեգատ ֆունկցիաներ, և եթե օգտագործեք կոմբինատորներ, ապա ըստ կոմբինատորիկայի օրենքների դուք կստանաք դրանցից մոտ հազարը: ԱրգՄաքս - գործառույթներից մեկը, որը հաշվարկում է առավելագույն արժեքը. հարցումը վերադարձնում է արժեքը usage_user, որի դեպքում հասնում է առավելագույն արժեքը ստեղծված_at:

SELECT now() as created_at,
       cpu.*
  FROM (SELECT DISTINCT tags_id from cpu) base 
  ASOF LEFT JOIN cpu USING (tags_id, created_at)

ASOF ՄԻԱՑԵՔ — տողերի «սոսնձում» տարբեր ժամանակներով։ Սա եզակի հատկություն է տվյալների բազաների համար, որը հասանելի է միայն kdb+. Եթե կան երկու ժամանակային շարքեր տարբեր ժամանակներով, ASOF ՄԻԱՑԵՔ թույլ է տալիս տեղափոխել և միավորել դրանք մեկ հարցումով: Մեկ ժամանակային շարքի յուրաքանչյուր արժեքի համար հայտնաբերվում է մյուսի ամենամոտ արժեքը, և դրանք վերադարձվում են նույն տողում.

Վերլուծական գործառույթներ

Ստանդարտում SQL-2003 կարող եք գրել այսպես.

SELECT origin,
       timestamp,
       timestamp -LAG(timestamp, 1) OVER (PARTITION BY origin ORDER BY timestamp) AS duration,
       timestamp -MIN(timestamp) OVER (PARTITION BY origin ORDER BY timestamp) AS startseq_duration,
       ROW_NUMBER() OVER (PARTITION BY origin ORDER BY timestamp) AS sequence,
       COUNT() OVER (PARTITION BY origin ORDER BY timestamp) AS nb
  FROM mytable
ORDER BY origin, timestamp;

В clickhouse Դուք չեք կարող դա անել, այն չի աջակցում ստանդարտին SQL-2003 և, հավանաբար, երբեք դա չի անի: Փոխարենը, ներս clickhouse Ընդունված է գրել այսպես.

Ես խոստացել եմ լամբդա - ահա նրանք:

Սա ստանդարտի վերլուծական հարցման անալոգն է SQL-2003նա հաշվում է երկուսի տարբերությունը ժամանակի դրոշմ, տևողություն, հերթական համարը՝ այն ամենը, ինչ մենք սովորաբար համարում ենք վերլուծական ֆունկցիաներ։ IN clickhouse Մենք դրանք հաշվում ենք զանգվածների միջոցով. սկզբում տվյալները փլուզում ենք զանգվածի մեջ, որից հետո զանգվածի վրա անում ենք այն ամենը, ինչ ուզում ենք, այնուհետև այն հետ ենք ընդլայնում։ Դա այնքան էլ հարմար չէ, նվազագույնը ֆունկցիոնալ ծրագրավորման սեր է պահանջում, բայց շատ ճկուն է։

Հատուկ առանձնահատկություններ

Բացի այդ, ին clickhouse բազմաթիվ մասնագիտացված գործառույթներ: Օրինակ, ինչպե՞ս որոշել, թե քանի նիստ է տեղի ունենում միաժամանակ: Տիպիկ մոնիտորինգի խնդիրն է առավելագույն բեռը որոշել մեկ խնդրանքով: IN clickhouse Այս նպատակով կա հատուկ գործառույթ.

Ընդհանուր առմամբ, ClickHouse-ն ունի հատուկ գործառույթներ բազմաթիվ նպատակների համար.

runDifference, runAccumulate, հարեւան;
sumMap (բանալին, արժեք);
timeSeriesGroupSum (uid, timestamp, value);
timeSeriesGroupRateSum (uid, timestamp, value);
skewPop, skewSamp, kurtPop, kurtSamp;
ԼՑՈՎ / ՓՈՂԿՈՎՆԵՐՈՎ;
պարզԳծային ռեգրեսիա, ստոխաստիկԳծային ռեգրեսիա։

Սա գործառույթների ամբողջական ցանկ չէ, ընդհանուր առմամբ 500-600-ն է։ Հուշում. բոլոր գործառույթները մուտքագրված են clickhouse գտնվում է համակարգի աղյուսակում (ոչ բոլորն են փաստաթղթավորված, բայց բոլորն էլ հետաքրքիր են).

select * from system.functions order by name

clickhouse այն պահպանում է իր մասին շատ տեղեկություններ, այդ թվում տեղեկամատյանների աղյուսակներ, query_log, հետագծման մատյան, տվյալների բլոկներով գործողությունների մատյան (part_log), չափումների մատյան և համակարգի մատյան, որը սովորաբար գրում է սկավառակի վրա։ Տեղեկամատյանների չափումները ժամանակային շարքեր в clickhouse իրականում clickhouseՏվյալների բազան ինքնին կարող է դեր խաղալ ժամանակային շարքեր տվյալների բազաները՝ դրանով իսկ «խժռելով» իրեն։

Սա նույնպես եզակի բան է, քանի որ մենք լավ գործ ենք անում ժամանակային շարքերԻնչո՞ւ մենք չենք կարող մեր մեջ պահել այն ամենը, ինչ մեզ անհրաժեշտ է: Մեզ պետք չէ Պրոմեթեւս, ամեն ինչ մեզ համար ենք պահում։ Միացված է Գրաֆանա և մենք վերահսկում ենք ինքներս մեզ: Այնուամենայնիվ, եթե clickhouse ընկնում է, մենք չենք տեսնի, թե ինչու, այնպես որ նրանք սովորաբար դա չեն անում:

Մեծ կլաստեր կամ շատ փոքր clickhouse

Ո՞րն է ավելի լավ՝ մեկ մեծ կլաստեր կամ շատ փոքր ClickHouses: Ավանդական մոտեցում DWH մեծ կլաստեր է, որում սխեմաները հատկացվում են յուրաքանչյուր հավելվածի համար: Մենք եկանք տվյալների բազայի ադմինիստրատորի մոտ - տվեք մեզ դիագրամ, և նրանք մեզ տվեցին մեկը.

В clickhouse դուք կարող եք դա անել այլ կերպ: Դուք կարող եք յուրաքանչյուր հավելված դարձնել ձեր սեփականը clickhouse:

Մեծ հրեշավորը մեզ այլևս պետք չէ DWH և անհարմար ադմիններ: Մենք կարող ենք յուրաքանչյուր հավելված տալ իր սեփականը clickhouse, և մշակողը կարող է դա անել ինքը, քանի որ clickhouse շատ հեշտ է տեղադրել և չի պահանջում բարդ կառավարում.

Բայց եթե մենք շատ բան ունենանք clickhouse, և դուք պետք է հաճախակի տեղադրեք այն, ապա ցանկանում եք ավտոմատացնել այս գործընթացը: Դրա համար մենք կարող ենք, օրինակ, օգտագործել Կուբերնետես и clickhouse- օպերատոր: IN Kubernetes ClickHouse Դուք կարող եք տեղադրել այն «սեղմման վրա»: Ես կարող եմ սեղմել կոճակը, գործարկել մանիֆեստը և տվյալների բազան պատրաստ է: Ես կարող եմ անմիջապես ստեղծել դիագրամ, սկսել բեռնել չափումները այնտեղ, և 5 րոպեից ես պատրաստ եմ վահանակը Գրաֆանա. Դա այնքան պարզ է:

Արդյունքը:

Այնպես որ, clickhouse - Սա.

Արագ. Սա բոլորը գիտեն։
Պարզապես. Մի քիչ հակասական, բայց ես կարծում եմ, որ դա դժվար է մարզման մեջ, հեշտ է մարտում: Եթե հասկանում եք, թե ինչպես clickhouse այն աշխատում է, ապա ամեն ինչ շատ պարզ է:
Ունիվերսալ. Հարմար է տարբեր սցենարների համար. DWH, ժամանակային շարք, մատյանների պահեստավորում. Բայց դա այդպես չէ OLTP տվյալների բազա, այնպես որ մի փորձեք այնտեղ կարճ ներդիրներ և ընթերցումներ անել:
Հետաքրքիր է. Հավանաբար նա, ով աշխատում է clickhouse, շատ հետաքրքիր պահեր ապրեց լավ ու վատ իմաստով։ Օրինակ, նոր թողարկում դուրս եկավ, ամեն ինչ դադարեց աշխատել: Կամ երբ երկու օր պայքարում էիր առաջադրանքի հետ, բայց Telegram chat-ում հարց տալուց հետո խնդիրը լուծվեց երկու րոպեում։ Կամ, ինչպես Լեշա Միլովիդովի զեկույցի համաժողովում, սքրինշոթ clickhouse խզել է հեռարձակումը Բարձր բեռնում ++. Այսպիսի բան անընդհատ լինում է և դժվարացնում է մեր կյանքը։ clickhouse պայծառ ու հետաքրքիր!

Դուք կարող եք դիտել շնորհանդեսը այստեղ.

Բարձր բեռնվածության համակարգերի մշակողների երկար սպասված հանդիպումը ժամը Բարձր բեռնում ++ նոյեմբերի 9-ին և 10-ին Սկոլկովոյում։ Ի վերջո, սա կլինի անցանց կոնֆերանս (թեև բոլոր նախազգուշական միջոցներով), քանի որ HighLoad++-ի էներգիան հնարավոր չէ փաթեթավորել առցանց:

Համաժողովի համար մենք գտնում և ցույց ենք տալիս տեխնոլոգիայի առավելագույն հնարավորությունների մասին դեպքեր. HighLoad++-ը եղել է, կա և կլինի միակ վայրը, որտեղ երկու օրից կարող եք իմանալ, թե ինչպես են աշխատում Facebook-ը, Yandex-ը, VKontakte-ն, Google-ը և Amazon-ը:

2007 թվականից ի վեր մեր հանդիպումներն առանց ընդհատումների անցկացնելով՝ այս տարի կհանդիպենք 14-րդ անգամ։ Այս ընթացքում համաժողովն աճել է 10 անգամ, անցյալ տարի կարևորագույն արդյունաբերության իրադարձությունը համախմբել է 3339 մասնակիցների, 165 խոսնակների, զեկույցների և հանդիպումների, իսկ 16 հետքերով աշխատում էին միաժամանակ:
Անցյալ տարի եղել է 20 ավտոբուս, 5280 լիտր թեյ և սուրճ, 1650 լիտր մրգային ըմպելիք և 10200 շիշ ջուր։ Եվ ևս 2640 կիլոգրամ սնունդ, 16 ափսե և 000 բաժակ։ Ի դեպ, վերամշակված թղթից հանգանակված գումարով 25 կաղնու տնկի ենք տնկել :)

Դուք կարող եք գնել տոմսեր այստեղ, ստանալ նորություններ համաժողովի մասին - այստեղև խոսեք բոլոր սոցիալական ցանցերում. Telegram, facebook, Vkontakte и Twitter.

Source: www.habr.com

Տեղափոխվելով ClickHouse՝ 3 տարի անց