HighLoad++ Մոսկվա 2018, Կոնգրեսի դահլիճ. նոյեմբերի 9-ին, ժամը 15:00-ին
Համառոտագրեր և ներկայացում.
Յուրի Նասրետդինով (VKontakte). Զեկույցում կխոսվի մեր ընկերությունում ClickHouse-ի ներդրման փորձի մասին՝ ինչու է դա մեզ անհրաժեշտ, որքան տվյալներ ենք պահում, ինչպես ենք գրում և այլն:
Լրացուցիչ նյութեր.
Յուրի Նասրետդինով. - Բարեւ բոլորին! Ես Յուրի Նասրետդինովն եմ, քանի որ ինձ արդեն ներկայացրել են։ Ես աշխատում եմ VKontakte-ում։ Ես կխոսեմ այն մասին, թե ինչպես ենք մենք տվյալները մտցնում ClickHouse-ում մեր սերվերի նավատորմից (տասնյակ հազարավոր):
Ի՞նչ են գերանները և ինչու՞ հավաքել դրանք:
Ինչ մենք ձեզ կասենք. ինչ արեցինք, ինչու էր մեզ անհրաժեշտ «ClickHouse»-ը, համապատասխանաբար, ինչու ընտրեցինք այն, մոտավորապես ինչպիսի կատարում կարող եք ստանալ առանց հատուկ որևէ բան կարգավորելու: Ես ձեզ ավելին կպատմեմ բուֆերային աղյուսակների, դրանց հետ կապված խնդիրների և մեր լուծումների մասին, որոնք մշակել ենք բաց կոդով` KittenHouse և Lighthouse:
Ինչու՞ մեզ պետք էր ընդհանրապես որևէ բան անել (ՎԿոնտակտեում ամեն ինչ միշտ լավ է, այնպես չէ՞): Մենք ուզում էինք հավաքել վրիպազերծման տեղեկամատյաններ (և այնտեղ հարյուրավոր տերաբայթ տվյալներ կային), միգուցե ինչ-որ կերպ ավելի հարմար կլիներ վիճակագրությունը հաշվարկելը. և մենք ունենք տասնյակ հազարավոր սերվերների նավատորմ, որոնցից այս ամենը պետք է արվի:
Ինչո՞ւ որոշեցինք. Մենք հավանաբար ունեինք գերանների պահպանման լուծումներ: Այստեղ կա այդպիսի հանրային «Backend VK»: Ես բարձր խորհուրդ եմ տալիս բաժանորդագրվել դրան:
Ի՞նչ են տեղեկամատյանները: Սա շարժիչ է, որը վերադարձնում է դատարկ զանգվածներ: VK-ում շարժիչներն այն են, ինչ մյուսները անվանում են միկրոսերվիսներ: Եվ ահա ժպտացող կպչուկ (բավականին շատ հավանումներ): Ինչու այդպես? Դե, լսեք հետագա!
Ի՞նչ կարելի է օգտագործել տեղեկամատյանները պահելու համար: Հադուփի մասին հնարավոր չէ չհիշատակել։ Այնուհետև, օրինակ, Rsyslog (այս տեղեկամատյանները պահելով ֆայլերում): LSD. Ո՞վ գիտի, թե ինչ է LSD-ն: Ոչ, ոչ այս LSD-ն: Պահպանեք ֆայլերը, համապատասխանաբար, նույնպես: Դե, ClickHouse-ը տարօրինակ տարբերակ է:
Clickhouse և մրցակիցներ. պահանջներ և հնարավորություններ
Ի՞նչ ենք մենք ուզում։ Մենք ցանկանում ենք ապահովել, որ մենք չպետք է շատ անհանգստանանք գործողության համար, որպեսզի այն աշխատի առանց տուփի, գերադասելի է նվազագույն կոնֆիգուրացիան: Մենք ուզում ենք շատ գրել, և արագ գրել: Եվ մենք ուզում ենք այն պահել ամեն տեսակ ամիսներով, տարիներով, այսինքն՝ երկար ժամանակ։ Մենք կարող ենք ցանկանալ հասկանալ ինչ-որ խնդիր, որով նրանք եկան մեզ մոտ և ասացին. «Ինչ-որ բան այստեղ չի աշխատում», և դա 3 ամիս առաջ էր), և մենք ուզում ենք տեսնել, թե ինչ է տեղի ունեցել 3 ամիս առաջ»: Տվյալների սեղմում – պարզ է, թե ինչու է դա գումարած, քանի որ այն նվազեցնում է զբաղեցրած տարածքի քանակը:
Եվ մենք ունենք այսպիսի հետաքրքիր պահանջ՝ մենք երբեմն գրում ենք որոշ հրամանների ելքը (օրինակ՝ տեղեկամատյանները), այն բավականին հեշտությամբ կարող է լինել ավելի քան 4 կիլոբայթ։ Եվ եթե այս բանն աշխատում է UDP-ով, ապա այն ծախսելու կարիք չունի... կապի համար որևէ «գլխավճար» չի ունենա, իսկ մեծ թվով սերվերների համար սա պլյուս կլինի:
Տեսնենք, թե ինչ է մեզ առաջարկում բաց կոդով։ Նախ, մենք ունենք Logs Engine. սա մեր շարժիչն է. Սկզբունքորեն ամեն ինչ կարող է անել, նույնիսկ երկար տողեր գրել։ Դե, այն թափանցիկորեն չի սեղմում տվյալները. մենք ինքներս կարող ենք սեղմել մեծ սյունակներ, եթե ցանկանում ենք... մենք, իհարկե, չենք ուզում (եթե հնարավոր է): Միակ խնդիրն այն է, որ նա կարող է տալ միայն այն, ինչ տեղավորվում է իր հիշողության մեջ. Մնացածը կարդալու համար հարկավոր է ձեռք բերել այս շարժիչի բինլոգը և, համապատասխանաբար, բավական երկար ժամանակ է պահանջվում։
Ի՞նչ այլ տարբերակներ կան: Օրինակ՝ «Հադուպ»։ Գործողության հեշտությունը... Ո՞վ է կարծում, որ Hadup-ը հեշտ է կարգավորվում: Իհարկե, ձայնագրության հետ կապված խնդիրներ չկան։ Կարդալիս երբեմն հարցեր են ծագում. Սկզբունքորեն, ես կասեի, հավանաբար, ոչ, հատկապես գերանների համար: Երկարատև պահեստավորում, իհարկե, այո, տվյալների սեղմում, այո, երկար տողեր, պարզ է, որ կարող եք ձայնագրել: Բայց ձայնագրությունը մեծ թվով սերվերներից... Դուք դեռ պետք է ինքներդ ինչ-որ բան անեք:
Rsyslog. Փաստորեն, մենք այն օգտագործել ենք որպես պահեստային տարբերակ, որպեսզի կարողանանք կարդալ առանց բինլոգը թափելու, բայց այն չի կարող երկար տողեր գրել, սկզբունքորեն չի կարող գրել 4 կիլոբայթից ավելի: Դուք ինքներդ պետք է նույն կերպ կատարեք տվյալների սեղմում: Ընթերցանությունը կգա ֆայլերից:
Այնուհետև կա LSD-ի «բադուշկա» զարգացումը: Ըստ էության, նույնն է, ինչ «Rsyslog»-ը. այն աջակցում է երկար տողերի, բայց այն չի կարող աշխատել UDP-ի միջոցով և, փաստորեն, դրա պատճառով, ցավոք, այնտեղ բավականին շատ բաներ պետք է վերագրվեն: LSD-ն պետք է վերանախագծվի, որպեսզի կարողանա ձայնագրել տասնյակ հազարավոր սերվերներից:
Եվ ահա՛։ Զվարճալի տարբերակ է ElasticSearch-ը: Թե ինչպես կարելի է ասել? Ընթերցանությունից լավ է ստացվում, այսինքն՝ արագ է կարդում, բայց գրելուց ոչ այնքան լավ։ Նախ, եթե այն սեղմում է տվյալները, այն շատ թույլ է: Ամենայն հավանականությամբ, ամբողջական որոնումը պահանջում է ավելի մեծ տվյալների կառուցվածքներ, քան սկզբնական ծավալը: Դժվար է գործել, և դրա հետ կապված հաճախ խնդիրներ են առաջանում։ Եվ, կրկին, Elastic-ով ձայնագրություն - մենք պետք է ամեն ինչ ինքներս անենք:
Այստեղ ClickHouse-ը, իհարկե, իդեալական տարբերակ է: Միակ բանն այն է, որ տասնյակ հազարավոր սերվերներից ձայնագրելը խնդիր է։ Բայց գոնե մեկ խնդիր կա, կարելի է փորձել ինչ-որ կերպ լուծել։ Իսկ զեկույցի մնացած մասը այս խնդրի մասին է։ Ինչպիսի՞ կատարում կարող եք ակնկալել ClickHouse-ից:
Ինչպե՞ս ենք այն տեղադրելու: MergeTree
Ձեզնից ո՞վ չի լսել կամ չգիտի «ClickHouse»-ի մասին: Ես պետք է ձեզ ասեմ, չէ՞: Շատ արագ. Ներդրումն այնտեղ՝ 1-2 գիգաբիթ վայրկյանում, մինչև 10 գիգաբիթ/վայրկյան պոռթկումները իրականում կարող են դիմակայել այս կոնֆիգուրացիան. կան երկու 6 միջուկանի Xeon (այսինքն, նույնիսկ ամենահզորը), 256 գիգաբայթ RAM, 20 տերաբայթ: RAID-ում (ոչ ոք կազմաձևված չէ, լռելյայն կարգավորումներ): Ալեքսեյ Միլովիդովը, ClickHouse-ի ծրագրավորողը, հավանաբար նստած է այնտեղ և լաց է լինում, քանի որ մենք ոչինչ չենք կարգավորել (մեզ մոտ ամեն ինչ այդպես է աշխատել): Համապատասխանաբար, սկանավորման արագություն, ասենք, մոտ 6 միլիարդ տող վայրկյանում կարելի է ստանալ, եթե տվյալները լավ սեղմված են: Եթե ձեզ դուր է գալիս % տեքստային տողի վրա՝ 100 միլիոն տող վայրկյանում, այսինքն՝ այն բավականին արագ է թվում:
Ինչպե՞ս ենք այն տեղադրելու: Դե, դուք գիտեք, որ VK-ն օգտագործում է PHP: Մենք PHP-ի յուրաքանչյուր աշխատողից HTTP-ի միջոցով կտեղադրենք «ClickHouse»՝ MergeTree աղյուսակում յուրաքանչյուր գրառումի համար: Ո՞վ է խնդիր տեսնում այս սխեմայի հետ կապված: Չգիտես ինչու, ոչ բոլորն են ձեռքերը բարձրացրել։ Թույլ տվեք պատմել ձեզ.
Նախ, կան շատ սերվերներ, համապատասխանաբար, կլինեն շատ կապեր (վատ): Այնուհետև ավելի լավ է տվյալներ տեղադրել MergeTree-ում ոչ ավելի հաճախ, քան վայրկյանում մեկ անգամ: Իսկ ո՞վ գիտի, թե ինչու։ Լավ լավ. Ես ձեզ մի փոքր ավելին կպատմեմ այս մասին: Մեկ այլ հետաքրքիր հարց այն է, որ մենք չենք անում վերլուծություն, մեզ պետք չէ հարստացնել տվյալները, մեզ պետք չեն միջանկյալ սերվերներ, մենք ուզում ենք ուղղակիորեն տեղադրել «ClickHouse» (ցանկալի է՝ որքան ավելի անմիջական, այնքան լավ):
Ըստ այդմ, ինչպե՞ս է կատարվում ներդիրը MergeTree-ում: Ինչու՞ ավելի լավ է դրա մեջ ներդնել ոչ ավելի հաճախ, քան վայրկյանը մեկ անգամ կամ ավելի քիչ: Փաստն այն է, որ «ClickHouse»-ը սյունակային տվյալների բազա է և դասավորում է տվյալները առաջնային բանալու աճման կարգով, և երբ դուք ներդիր եք անում, ստեղծվում են մի շարք ֆայլեր, որոնք առնվազն հավասար են այն սյունակների քանակին, որոնցում տեսակավորված են տվյալները: առաջնային բանալու աճման կարգով (ստեղծվում է առանձին գրացուցակ, սկավառակի վրա ֆայլերի մի շարք յուրաքանչյուր ներդիրի համար): Այնուհետև գալիս է հաջորդ ներդիրը, և հետին պլանում դրանք միավորվում են ավելի մեծ «միջնորմների»: Քանի որ տվյալները տեսակավորված են, հնարավոր է «միաձուլել» երկու տեսակավորված ֆայլ՝ առանց մեծ հիշողություն սպառելու:
Բայց, ինչպես կարող եք կռահել, եթե յուրաքանչյուր ներդիրի համար գրեք 10 ֆայլ, ապա ClickHouse-ը (կամ ձեր սերվերը) արագ կավարտվի, ուստի խորհուրդ է տրվում տեղադրել մեծ խմբաքանակներով: Համապատասխանաբար, մենք երբեք առաջին սխեման արտադրություն չենք մտցրել։ Մենք անմիջապես գործարկեցինք մեկը, որն այստեղ թիվ 2 ունի.
Այստեղ պատկերացրեք, որ կան մոտ հազար սերվերներ, որոնց վրա մենք գործարկել ենք, կա ընդամենը PHP: Եվ յուրաքանչյուր սերվերի վրա կա մեր տեղական գործակալը, որը մենք անվանեցինք «Kittenhouse», որը պահպանում է մեկ կապ «ClickHouse»-ի հետ և տեղադրում տվյալներ ամեն մի քանի վայրկյանը մեկ: Տվյալները զետեղում է ոչ թե MergeTree-ում, այլ բուֆերային աղյուսակում, որը ծառայում է հենց այնպես, որպեսզի անմիջապես խուսափի MergeTree-ի մեջ անմիջապես զետեղելուց:
Աշխատեք բուֆերային աղյուսակների հետ
Ինչ է դա? Բուֆերային աղյուսակները հիշողության մի կտոր են, որը բեկված է (այսինքն, այն կարող է հաճախակի տեղադրվել դրա մեջ): Դրանք բաղկացած են մի քանի կտորից, և կտորներից յուրաքանչյուրն աշխատում է որպես անկախ բուֆեր, և դրանք լվացվում են ինքնուրույն (եթե բուֆերի մեջ շատ կտորներ ունեք, ապա վայրկյանում շատ ներդիրներ կլինեն)։ Կարելի է կարդալ այս աղյուսակներից - այնուհետև կարդում եք բուֆերի և մայր աղյուսակի բովանդակության միավորումը, բայց այս պահին գրելը արգելափակված է, ուստի ավելի լավ է չկարդալ այնտեղից: Իսկ բուֆերային աղյուսակները ցույց են տալիս շատ լավ QPS, այսինքն՝ մինչև 3 հազար QPS դուք ընդհանրապես ոչ մի խնդիր չեք ունենա տեղադրելիս։ Հասկանալի է, որ եթե սերվերը հոսանքազրկվի, ապա տվյալները կարող են կորչել, քանի որ դրանք պահվել են միայն հիշողության մեջ։
Միևնույն ժամանակ, բուֆերով սխեման բարդացնում է ALTER-ը, քանի որ նախ պետք է թողնել հին բուֆերային աղյուսակը հին սխեմայով (տվյալները ոչ մի տեղ չեն անհետանա, քանի որ այն կջնջվի մինչև աղյուսակը ջնջվի): Այնուհետև դուք «փոխում եք» ձեզ անհրաժեշտ աղյուսակը և նորից ստեղծում բուֆերային աղյուսակը: Համապատասխանաբար, թեև չկա բուֆերային աղյուսակ, ձեր տվյալները ոչ մի տեղ չեն հոսի, բայց դուք կարող եք դրանք ունենալ սկավառակի վրա առնվազն տեղական մակարդակում:
Ինչ է Kittenhouse-ը և ինչպես է այն աշխատում:
Ինչ է KittenHouse-ը: Սա վստահված անձ է: Գուշակեք, թե ինչ լեզվով: Ես հավաքեցի իմ զեկույցում ամենաշատ հիպ թեմաները՝ «Clickhouse», Գնացեք, միգուցե ես ուրիշ բան հիշեմ: Այո, սա գրված է Go-ում, քանի որ ես իրականում չգիտեմ ինչպես գրել C-ով, չեմ ուզում:
Համապատասխանաբար, այն կապ է պահպանում յուրաքանչյուր սերվերի հետ և կարող է գրել հիշողության մեջ: Օրինակ, եթե մենք գրում ենք սխալների տեղեկամատյանները Clickhouse-ում, ապա եթե Clickhouse-ը ժամանակ չունի տվյալներ տեղադրելու համար (ի վերջո, եթե շատ է գրված), ապա մենք չենք ուռչում հիշողությունը, մենք պարզապես դուրս ենք նետում մնացածը: Որովհետև եթե մենք սխալներ գրենք վայրկյանում մի քանի գիգաբիթ, ապա հավանաբար կարող ենք մի քանիսը դուրս նետել: Kittenhouse-ը կարող է դա անել: Բացի այդ, այն կարող է կատարել հուսալի առաքում, այսինքն՝ գրել սկավառակի վրա տեղական մեքենայի վրա և ամեն անգամ (այնտեղ, ամեն երկու վայրկյանը մեկ) փորձում է տվյալներ փոխանցել այս ֆայլից: Եվ սկզբում մենք օգտագործեցինք սովորական Values ֆորմատը՝ ոչ թե երկուական ձևաչափ, այլ տեքստային ձևաչափ (ինչպես սովորական SQL-ում):
Բայց հետո սա եղավ. Մենք օգտագործեցինք հուսալի առաքում, գրեցինք տեղեկամատյաններ, հետո որոշեցինք (դա պայմանական թեստային կլաստեր էր)... Այն մի քանի ժամով դուրս բերվեց և հետ բերվեց, և հազար սերվերից սկսվեց ներդրումը - պարզվեց, որ Քլիքհաուսը դեռևս ուներ «Թելեր միացման վրա» - համապատասխանաբար, հազար միացումներում ակտիվ ներդրումը հանգեցնում է սերվերի միջին ծանրաբեռնվածության մոտ մեկուկես հազարի: Զարմանալիորեն, սերվերն ընդունեց հարցումները, բայց տվյալները որոշ ժամանակ անց դեռ տեղադրվեցին; բայց սերվերի համար շատ դժվար էր դա սպասարկել...
Ավելացնել nginx
Նման լուծումը Thread մեկ կապի մոդելի համար nginx է: Մենք տեղադրեցինք nginx-ը Քլիքհաուսի դիմաց, միևնույն ժամանակ ստեղծեցինք հավասարակշռում երկու կրկնօրինակների համար (մեր ներդիրի արագությունը ավելացել է 2 անգամ, թեև դա փաստ չէ, որ այդպես պետք է լինի) և սահմանափակեցինք Clickhouse-ի հետ կապերի քանակը մինչև հոսանքին հակառակ և, համապատասխանաբար, ավելի շատ, քան 50 միացումներում, կարծես թե իմաստ չունի ներդնել:
Հետո մենք հասկացանք, որ այս սխեման ընդհանուր առմամբ ունի թերություններ, քանի որ մենք այստեղ ունենք միայն մեկ nginx: Համապատասխանաբար, եթե այս nginx-ը խափանվի, չնայած կրկնօրինակների առկայությանը, մենք կորցնում ենք տվյալները կամ, համենայն դեպս, ոչ մի տեղ չենք գրում: Այդ իսկ պատճառով մենք կատարեցինք մեր սեփական բեռի հավասարակշռումը: Մենք նաև հասկացանք, որ «Clickhouse»-ը դեռ հարմար է գերանների համար, և «դևը» նույնպես սկսեց իր տեղեկամատյանները գրել «Clickhouse»-ում, ճիշտն ասած, շատ հարմար: Մենք դեռ օգտագործում ենք այն այլ «դևերի» համար:
Այնուհետև մենք հայտնաբերեցինք այս հետաքրքիր խնդիրը. եթե դուք օգտագործում եք SQL ռեժիմում ներդնելու ոչ ստանդարտ մեթոդ, դա ստիպում է լիարժեք AST-ի վրա հիմնված SQL վերլուծիչ, որը բավականին դանդաղ է աշխատում: Համապատասխանաբար, մենք ավելացրել ենք կարգավորումներ՝ ապահովելու համար, որ դա երբեք տեղի չունենա: Մենք կատարեցինք բեռի հավասարակշռում, առողջության ստուգումներ, որպեսզի եթե մեկը մահանա, մենք դեռ թողնենք տվյալները: Այժմ մենք ունենք բավականին շատ աղյուսակներ, որոնք պետք է ունենանք տարբեր Clickhouse կլաստերներ: Եվ մենք նաև սկսեցինք մտածել այլ օգտագործման մասին, օրինակ, մենք ուզում էինք տեղեկամատյաններ գրել nginx մոդուլներից, բայց նրանք չգիտեն, թե ինչպես հաղորդակցվել մեր RPC-ի միջոցով: Դե, ես կցանկանայի նրանց սովորեցնել, թե ինչպես գոնե ինչ-որ կերպ ուղարկել, օրինակ՝ ստանալ իրադարձություններ localhost-ում UDP-ի միջոցով և այնուհետև դրանք փոխանցել Clickhouse:
Լուծումից մեկ քայլ հեռու
Վերջնական սխեման սկսեց այսպիսի տեսք ունենալ (այս սխեմայի չորրորդ տարբերակը). Clickhouse-ի դիմացի յուրաքանչյուր սերվերի վրա կա nginx (նույն սերվերի վրա) և այն պարզապես միջնորդում է հարցումները localhost-ին՝ 50 կապերի քանակի սահմանափակումով: կտորներ. Եվ այս սխեման արդեն բավականին աշխատում էր, դրա հետ ամեն ինչ բավականին լավ էր:
Մոտ մեկ ամիս այսպես ապրեցինք։ Բոլորը ուրախացան, աղյուսակներ ավելացրին, ավելացրին, ավելացրին... Ընդհանրապես, պարզվեց, որ բուֆերային աղյուսակների ավելացման ձևն այնքան էլ օպտիմալ չէր (այդպես ասենք)։ Յուրաքանչյուր աղյուսակում մենք արեցինք 16 կտոր և մի քանի վայրկյան ֆլեշ ինտերվալ; մենք ունեինք 20 աղյուսակ և յուրաքանչյուր աղյուսակ ստանում էր 8 ներդիր վայրկյանում, և այս պահին սկսվեց «Clickhouse»-ը... ձայնագրությունները սկսեցին դանդաղել: Նրանք նույնիսկ չեն անցել… Nginx-ը լռելյայն ուներ այնպիսի հետաքրքիր բան, որ եթե կապերն ավարտվում էին հոսանքին հակառակ, ապա այն պարզապես վերադարձրեց «502»-ը բոլոր նոր հարցումներին:
Եվ ահա մենք ունենք (ես հենց նոր նայեցի հենց Clickhouse-ի տեղեկամատյանները) հարցումների մոտ կես տոկոսը ձախողվեց: Համապատասխանաբար, սկավառակի օգտագործումը բարձր էր, միաձուլումները շատ էին։ Դե ինչ արեցի։ Բնականաբար, ես չփորձեցի պարզել, թե ինչու հենց կապն ու հոսանքն ի վեր ավարտվեցին:
Nginx-ի փոխարինում հակադարձ վստահված անձի հետ
Ես որոշեցի, որ մենք ինքներս պետք է կառավարենք դա, մենք պետք չէ դա թողնել nginx-ին. nginx-ը չգիտի, թե ինչ աղյուսակներ կան Clickhouse-ում, և ես փոխարինեցի nginx-ը հակադարձ պրոքսիով, որը ես նաև ինքս եմ գրել:
Ինչ է նա անում? Այն աշխատում է «goshnoy» fasthttp գրադարանի հիման վրա, այսինքն՝ արագ, գրեթե նույնքան արագ, որքան nginx-ը։ Ներեցեք, Իգոր, եթե դուք ներկա եք այստեղ (նշում. Իգոր Սիսոևը ռուս ծրագրավորող է, ով ստեղծել է nginx վեբ սերվերը): Այն կարող է հասկանալ, թե ինչպիսի հարցումներ են դրանք՝ INSERT կամ SELECT, համապատասխանաբար, այն տարբեր տեսակի հարցումների համար ունի տարբեր կապի լողավազաններ:
Ըստ այդմ, նույնիսկ եթե մենք ժամանակ չունենանք լրացնել ներդիրների հարցումները, «ընտրվածները» կանցնեն, և հակառակը։ Եվ այն խմբավորում է տվյալները բուֆերային աղյուսակների մեջ՝ փոքր բուֆերով. եթե եղել են սխալներ, շարահյուսական սխալներ և այլն, որպեսզի դրանք մեծապես չազդեն մնացած տվյալների վրա, քանի որ երբ մենք պարզապես տեղադրում ենք բուֆերային աղյուսակներ, մենք ուներ փոքր «bachi», և բոլոր շարահյուսական սխալներն ազդեցին միայն այս փոքրիկ հատվածի վրա. իսկ այստեղ դրանք արդեն կազդեն մեծ բուֆերի վրա։ Փոքրը 1 մեգաբայթ է, այսինքն՝ այնքան էլ փոքր չէ։
Համաժամացման տեղադրումը և, ըստ էության, nginx-ի փոխարինումը, ըստ էության, անում է նույնը, ինչ նախկինում անում էր nginx-ը. դրա համար հարկավոր չէ փոխել տեղական «Kittenhouse»-ը: Եվ քանի որ այն օգտագործում է fasthttp, այն շատ արագ է. դուք կարող եք մեկ վայրկյանում ավելի քան 100 հազար հարցում կատարել մեկ ներդիրների համար հակադարձ պրոքսիի միջոցով: Տեսականորեն, դուք կարող եք միաժամանակ մեկ տող տեղադրել kittenhouse-ի հակառակ վստահված անձի մեջ, բայց, իհարկե, մենք դա չենք անում:
Սխեման սկսեց այսպիսի տեսք ունենալ. «Kittenhouse», հակառակ վստահված անձը խմբավորում է բազմաթիվ հարցումներ աղյուսակների մեջ և, իր հերթին, բուֆերային աղյուսակները դրանք տեղադրում են հիմնականների մեջ:
Killer-ը ժամանակավոր լուծում է, Kitten-ը՝ մշտական
Հետաքրքիր խնդիր է... Ձեզանից որևէ մեկը օգտվե՞լ է fasthttp-ից: Ո՞վ օգտագործեց fasthttp-ը POST հարցումներով: Հավանաբար, դա իսկապես չպետք է արվեր, քանի որ այն լռելյայնորեն բուֆերացնում է հարցման մարմինը, և մեր բուֆերի չափը սահմանվել է 16 մեգաբայթ: Ինչ-որ պահի ներդիրը դադարեց շարունակել, և 16 մեգաբայթանոց կտորներ սկսեցին հայտնվել բոլոր տասնյակ հազարավոր սերվերներից, և դրանք բոլորը բուֆերվեցին հիշողության մեջ՝ նախքան Քլիքհաուս ուղարկելը: Համապատասխանաբար, հիշողությունը սպառվեց, «Of-Of-Memory Killer»-ը եկավ և սպանեց հակադարձ վստահված անձին (կամ «Clickhouse»-ը, որը տեսականորեն կարող էր ավելի շատ «ուտել», քան հակառակ վստահված անձին): Ցիկլը կրկնվեց. Շատ հաճելի խնդիր չէ։ Թեև մենք սրա վրա պատահաբար հանդիպեցինք միայն մի քանի ամիս աշխատելուց հետո։
Ի՞նչ եմ ես արել: Կրկին, ես իսկապես չեմ սիրում հասկանալ, թե կոնկրետ ինչ է տեղի ունեցել: Կարծում եմ, որ բավականին ակնհայտ է, որ դուք չպետք է բուֆեր անցնեք հիշողության մեջ: Չկարողացա արագ http կարկատել, չնայած փորձեցի։ Բայց ես գտա այնպես, որ այնպես անեմ, որ ոչ մի բան կարկատելու կարիք չլինի, ու HTTP-ում իմ սեփական մեթոդն էի հորինել՝ կոչեցի ԿԱՏՈՒԿ։ Դե, տրամաբանական է. «VK», «Kitten»... Էլ ի՞նչ:
Եթե հարցումը սերվեր է գալիս Kitten մեթոդով, ապա սերվերը պետք է պատասխանի «meow» - տրամաբանորեն: Եթե նա արձագանքում է սրան, ապա համարվում է, որ նա հասկանում է այս պրոտոկոլը, և հետո ես ընդհատում եմ կապը (fasthttp-ն ունի այդպիսի մեթոդ), և կապը անցնում է «raw» ռեժիմի։ Ինչո՞ւ է դա ինձ պետք: Ես ուզում եմ վերահսկել, թե ինչպես է կատարվում TCP կապերից կարդալը: TCP-ն հիանալի հատկություն ունի. եթե ոչ ոք մյուս կողմից չի կարդում, ապա գրությունը սկսում է սպասել, և հիշողությունը առանձնապես չի ծախսվում դրա վրա:
Եվ այսպես, ես միանգամից կարդում եմ մոտ 50 հաճախորդից (հիսունից, որովհետև հիսունը պետք է անպայման բավարար լինի, նույնիսկ եթե փոխարժեքը գալիս է մեկ այլ DC-ից)... Սպառումը այս մոտեցմամբ նվազել է առնվազն 20 անգամ, բայց ես, ճիշտն ասած. , ես չկարողացա ճշգրիտ չափել ժամը, քանի որ դա արդեն անիմաստ է (արդեն սխալի աստիճանի է հասել): Արձանագրությունը երկուական է, այսինքն՝ պարունակում է աղյուսակի անվանումը և տվյալները. http-ի վերնագրեր չկան, ուստի ես չեմ օգտագործել վեբ վարդակից (ես պետք չէ շփվել բրաուզերների հետ. ես պատրաստել եմ արձանագրություն, որը համապատասխանում է մեր կարիքներին): Եվ նրա հետ ամեն ինչ լավ դարձավ։
Բուֆերային աղյուսակը տխուր է
Վերջերս մենք հանդիպեցինք բուֆերային աղյուսակների մեկ այլ հետաքրքիր առանձնահատկություն. Եվ այս խնդիրն արդեն շատ ավելի ցավոտ է, քան մյուսները։ Եկեք պատկերացնենք այս իրավիճակը. դուք արդեն ակտիվորեն օգտագործում եք Clickhouse-ը, ունեք տասնյակ Clickhouse սերվերներ և ունեք որոշ հարցումներ, որոնք կարդալու համար շատ երկար ժամանակ է պահանջվում (ասենք, ավելի քան 60 վայրկյան); և դուք գալիս եք և անում եք Alter այս պահին... Միևնույն ժամանակ, «ընտրությունները», որոնք սկսվել են «Alter»-ից առաջ, չեն ներառվի այս աղյուսակում, «Alter»-ը չի սկսվի. այս վայրը. Միգուցե սա կարելի՞ է ուղղել։ Թե՞ դա անհնար է։
Ընդհանուր առմամբ, պարզ է, որ իրականում դա այնքան էլ մեծ խնդիր չէ, բայց բուֆերային աղյուսակների դեպքում այն ավելի ցավոտ է դառնում։ Որովհետև, եթե, ասենք, ձեր «Alter»-ի ժամանակն ավարտվի (և այն կարող է ավարտվել մեկ այլ հոսթի վրա, ոչ թե ձեր, այլ օրինակ, օրինակ), ապա... Դուք ջնջել եք բուֆերային աղյուսակը, ձեր «Alter»-ը ( կամ ինչ-որ այլ հոսթ) սպառվել է: Այնուհետև տեղի է ունեցել «Փոփոխել» սխալ) - դուք դեռ պետք է համոզվեք, որ տվյալները շարունակվում են գրվել. դուք ետ եք ստեղծում բուֆերային աղյուսակները (ըստ նույն սխեմայի, ինչ մայր աղյուսակը), ապա «Alter»-ը անցնում է, վերջիվերջո ավարտվում, և աղյուսակի բուֆերը սկսում է տարբերվել ծնողից: Կախված նրանից, թե ինչ էր «Alter»-ը, ներդիրը կարող է այլևս չգնալ այս բուֆերային աղյուսակին. սա շատ տխուր է:
Կա նաև նման նշան (գուցե ինչ-որ մեկը դա նկատել է) - այն կոչվում է query_thread_log Clickhouse-ի նոր տարբերակներում: Լռելյայն, որոշ տարբերակներում կար մեկը: Այստեղ մենք մի քանի ամսում 840 միլիոն ձայնագրություն ենք կուտակել (100 գիգաբայթ)։ Դա պայմանավորված է նրանով, որ այնտեղ գրվել են «ներդիրներ» (գուցե հիմա, ի դեպ, դրանք չեն գրվում): Ինչպես ասացի ձեզ, մեր «ներդիրները» փոքր են. մենք շատ «ներդիրներ» ունեինք բուֆերային աղյուսակներում: Հասկանալի է, որ սա անջատված է, ես պարզապես ասում եմ ձեզ այն, ինչ տեսա մեր սերվերում: Ինչո՞ւ։ Սա ևս մեկ փաստարկ է բուֆերային աղյուսակների օգտագործման դեմ: Սփոթին շատ տխուր է։
Ո՞վ գիտեր, որ այս տղայի անունը Սփոթի է: VK-ի աշխատակիցները բարձրացրել են ձեռքերը. ԼԱՎ.
«KitttenHouse»-ի ծրագրերի մասին
Պլանները սովորաբար չեն կիսվում, չէ՞: Հանկարծ դուք չեք կատարի դրանք և շատ լավ չեք երևա ուրիշների աչքերում: Բայց ես ռիսկի կդիմեմ։ Մենք ուզում ենք անել հետևյալը. բուֆերային սեղանները, ինձ թվում է, դեռ հենակներ են, և մենք պետք է ինքներս բուֆերացնենք ներդիրը: Բայց մենք դեռ չենք ուզում այն բուֆերացնել սկավառակի վրա, այնպես որ մենք բուֆերային կցենք տեղադրումը հիշողության մեջ:
Համապատասխանաբար, երբ «ներդիր» կազմվի, այն այլևս համաժամանակյա չի լինի. այն արդեն կաշխատի որպես բուֆերային աղյուսակ, կտեղադրվի մայր աղյուսակի մեջ (լավ, մի օր անց) և առանձին ալիքով կհաղորդի, թե որ ներդիրներն են անցել և որոնք։ չունեն.
Ինչու չեմ կարող լքել համաժամանակյա ներդիրը: Դա շատ ավելի հարմար է: Փաստն այն է, որ եթե տեղադրես 10 հազար հոսթից, ապա ամեն ինչ լավ է, ամեն ինչից մի քիչ կստանաս, վայրկյանը մեկ տեղադրում ես այնտեղ, ամեն ինչ լավ է։ Բայց ես կցանկանայի, որ այս սխեման աշխատեր, օրինակ, երկու մեքենաներից, որպեսզի կարողանաք ներբեռնել բարձր արագությամբ, միգուցե չստանաք առավելագույնը Clickhouse-ից, բայց մեկ մեքենայից գրեք առնվազն 100 մեգաբայթ վայրկյանում հակադարձ պրոքսիի միջոցով. սա սխեման պետք է մասշտաբի լինի և՛ մեծ, և՛ փոքր քանակությամբ, այնպես որ մենք չենք կարող սպասել մեկ վայրկյան յուրաքանչյուր տեղադրման համար, ուստի այն պետք է լինի ասինխրոն: Եվ նույն կերպ, ասինխրոն հաստատումները պետք է գան տեղադրման ավարտից հետո: Անցել է, թե ոչ՝ կիմանանք։
Ամենակարևորն այն է, որ այս սխեմայում մենք հաստատ գիտենք՝ ներդիրը եղե՞լ է, թե՞ ոչ։ Պատկերացրեք այս իրավիճակը. դուք ունեք բուֆերային աղյուսակ, ինչ-որ բան եք գրել դրա մեջ, իսկ հետո, ենթադրենք, աղյուսակը մտավ միայն կարդալու ռեժիմ և փորձեց մաքրել բուֆերը: Ու՞ր են գնալու տվյալները: Նրանք կմնան բուֆերում։ Բայց մենք չենք կարող վստահ լինել դրանում. իսկ եթե լինի ինչ-որ այլ սխալ, որի պատճառով տվյալները չեն մնա բուֆերում... (Հասցե Ալեքսեյ Միլովիդով, Yandex, ClickHouse ծրագրավորող) Թե՞ այն կմնա: Միշտ? Ալեքսեյը մեզ համոզում է, որ ամեն ինչ լավ է լինելու։ Մենք նրան չհավատալու պատճառ չունենք։ Բայց միևնույն է. եթե մենք չօգտագործենք բուֆերային աղյուսակներ, ապա դրանց հետ խնդիրներ չեն լինի: Երկու անգամ ավելի շատ աղյուսակներ ստեղծելը նույնպես անհարմար է, թեև սկզբունքորեն մեծ խնդիրներ չկան։ Սա է պլանը։
Եկեք խոսենք ընթերցանության մասին
Հիմա խոսենք կարդալու մասին։ Մենք այստեղ գրել ենք նաև մեր գործիքը: Թվում է, լավ, ինչու՞ այստեղ գրել ձեր սեփական գործիքը: Իսկ ո՞վ է օգտագործել Tabix-ը: Մի կերպ քչերն են ձեռք բարձրացրել... Իսկ ո՞վ է գոհ Tabix-ի կատարումից։ Դե, մենք դրանից գոհ չենք, և դա այնքան էլ հարմար չէ տվյալների դիտման համար։ Դա լավ է վերլուծության համար, բայց պարզապես դիտելու համար այն ակնհայտորեն օպտիմիզացված չէ: Այսպիսով, ես գրեցի իմ սեփական ինտերֆեյսը:
Դա շատ պարզ է. այն կարող է կարդալ միայն տվյալները: Գրաֆիկա ցույց տալ չգիտի, ոչինչ անել չգիտի։ Բայց այն կարող է ցույց տալ, թե ինչ է մեզ անհրաժեշտ. օրինակ, քանի տող կա աղյուսակում, որքան տեղ է զբաղեցնում այն (առանց սյունակների բաժանելու), այսինքն՝ շատ տարրական ինտերֆեյս է այն, ինչ մեզ անհրաժեշտ է:
Եվ այն շատ նման է Sequel Pro-ին, բայց արված է միայն Twitter-ի Bootstrap-ում և երկրորդ տարբերակում: Դուք հարցնում եք. «Յուրի, ինչու՞ երկրորդ տարբերակով»: Ո՞ր տարին։ 2018թ. Ընդհանրապես, ես դա արել եմ շատ վաղուց «Muscle»-ի (MySQL) համար և պարզապես մի քանի տող փոխել եմ այնտեղի հարցումներում, և այն սկսել է աշխատել «Clickhouse»-ի համար, ինչի համար հատուկ շնորհակալություն: Քանի որ վերլուծիչը շատ նման է «մկանայինին», իսկ հարցումները շատ նման են՝ շատ հարմար, հատկապես սկզբում:
Դե, այն կարող է զտել աղյուսակները, կարող է ցույց տալ աղյուսակի կառուցվածքը և բովանդակությունը, թույլ է տալիս տեսակավորել, զտել ըստ սյունակների, ցույց է տալիս հարցումը, որը հանգեցրել է արդյունքի, տուժած տողերը (արդյունքում քանիսը), այսինքն՝ հիմնական բաները տվյալների դիտման համար: Բավականին արագ:
Կա նաև խմբագիր։ Ես ազնվորեն փորձեցի ամբողջ խմբագրին գողանալ Tabix-ից, բայց չկարողացա: Բայց ինչ-որ կերպ դա աշխատում է: Սկզբունքորեն, այսքանը:
«Clickhouse»-ը հարմար է որջերի համար
Ես ուզում եմ ձեզ ասել, որ Clickhouse-ը, չնայած նկարագրված բոլոր խնդիրներին, շատ հարմար է տեղեկամատյանների համար: Ամենակարևորը, այն լուծում է մեր խնդիրը. այն շատ արագ է և թույլ է տալիս զտել տեղեկամատյանները ըստ սյունակների: Սկզբունքորեն, բուֆերային աղյուսակները լավ չեն աշխատել, բայց սովորաբար ոչ ոք չգիտի, թե ինչու... Միգուցե հիմա դուք ավելի լավ գիտեք, թե որտեղ խնդիրներ կունենաք:
TCP? Ընդհանուր առմամբ, VK-ում ընդունված է օգտագործել UDP: Եվ երբ ես օգտագործեցի TCP... Իհարկե, ոչ ոք ինձ չասաց. «Յուրի, ինչ ես խոսում: Դուք չեք կարող, ձեզ UDP է պետք»: Պարզվեց, որ TCP-ն այնքան էլ սարսափելի չէ։ Միակ բանն այն է, որ եթե դուք ունեք տասնյակ հազարավոր ակտիվ միացություններ, որոնք գրում եք, ապա պետք է այն մի փոքր ավելի ուշադիր պատրաստեք; բայց դա հնարավոր է, և բավականին հեշտ:
Խոստացել էի HighLoad Siberia-ում տեղադրել «Kittenhouse» և «Lighthouse», եթե բոլորը բաժանորդագրվեն մեր հանրային «VK backend»-ին... Եվ գիտեք, ոչ բոլորն են բաժանորդագրվել... Իհարկե, ես չեմ պահանջի, որ դուք բաժանորդագրվեք մեր հանրային. Դուք դեռ շատ եք, ինչ-որ մեկը կարող է նույնիսկ վիրավորվել, բայց այնուամենայնիվ, խնդրում եմ բաժանորդագրվեք (իսկ այստեղ ես պետք է կատվի աչքերը դարձնեմ): դա է . Շատ շնորհակալություն! Github-ը մերն է . Clickhouse-ի հետ ձեր մազերը փափուկ և մետաքսյա կլինեն:
Կապար: - Ընկերներ, հիմա հարցերի համար: Անմիջապես այն բանից հետո, երբ մենք ներկայացնում ենք շնորհակալագիրը և ձեր զեկույցը VHS-ի վերաբերյալ:
Յուրի Նասրետդինովը (այսուհետ՝ Ե. Ն.). – Ինչպե՞ս կարողացաք գրանցել իմ զեկույցը VHS-ի վերաբերյալ, եթե այն նոր է ավարտվել:
Կապար: - Դուք նույնպես չեք կարող լիովին որոշել, թե ինչպես է «Clickhouse»-ը աշխատելու, թե ոչ: Ընկերներ, 5 րոպե հարցերի համար:
Հարցեր
Հարց հանդիսատեսից (այսուհետ՝ Q). - Բարի օր. Շատ շնորհակալ եմ զեկույցի համար։ Երկու հարց ունեմ. Սկսեմ մի անլուրջ բանից՝ գծագրերում (3, 4, 7...) անվան «Kittenhouse» տառերի թիվը ազդո՞ւմ է կատուների բավարարվածության վրա։
YN: -Քանակը ինչի՞:
Զ. - Նամակ t. Կան երեք տ, ինչ-որ տեղ մոտ երեք տ:
YN: -Ես չե՞մ ուղղել: Դե, իհարկե, դա անում է: Սրանք տարբեր ապրանքներ են, ես ուղղակի խաբում էի ձեզ այս ամբողջ ընթացքում: Լավ, կատակում եմ, դա նշանակություն չունի: Ահ, հենց այստեղ: Չէ, նույն բանն է, ես տառասխալ եմ արել։
Զ. - Շնորհակալություն. Երկրորդ հարցը լուրջ է. Ինչքան հասկացա, Clickhouse-ում բուֆերային աղյուսակները ապրում են բացառապես հիշողության մեջ, բուֆերացված չեն սկավառակի վրա և, համապատասխանաբար, համառ չեն։
YN: - Այո:
Զ. – Եվ միևնույն ժամանակ, ձեր հաճախորդը բուֆեր է անցնում սկավառակի վրա, ինչը ենթադրում է նույն տեղեկամատյանների առաքման որոշակի երաշխիք: Բայց սա ոչ մի կերպ երաշխավորված չէ Clickhouse-ում: Բացատրեք, թե ինչպես է իրականացվում երաշխիքը, ինչի՞ շնորհիվ է... Ահա այս մեխանիզմն ավելի մանրամասն
YN: – Այո, տեսականորեն այստեղ հակասություններ չկան, քանի որ երբ Քլիքհաուսը ընկնում է, դուք իրականում կարող եք դա հայտնաբերել միլիոնավոր տարբեր ձևերով: Եթե Clickhouse-ը խափանում է (եթե այն սխալ է ավարտվում), դուք կարող եք, կոպիտ ասած, մի փոքր ետ շրջել ձեր գրած գրանցամատյանը և սկսել այն պահից, երբ ամեն ինչ ճիշտ էր։ Ենթադրենք, մի րոպե հետ եք շրջում, այսինքն համարվում է, որ մեկ րոպեում ամեն ինչ լվացել եք։
Զ. – Այսինքն՝ «Kittenhouse»-ն ավելի երկար է պահում պատուհանը և ընկնելու դեպքում կարո՞ղ է ճանաչել և ետ պտտել։
YN: - Բայց սա տեսականորեն է: Գործնականում մենք դա չենք անում, և հուսալի առաքումը զրոյից մինչև անսահման անգամ է: Բայց միջին հաշվով մեկ. Մենք գոհ ենք, որ եթե Clickhouse-ը ինչ-ինչ պատճառներով խափանվի կամ սերվերները «վերագործարկվեն», ապա մենք մի փոքր կորցնում ենք: Մնացած բոլոր դեպքերում ոչինչ չի ստացվի։
Զ. - Բարեւ Ձեզ. Ինձ հենց սկզբից թվում էր, որ դուք իսկապես կօգտագործեք UDP զեկույցի հենց սկզբից: Դու ունես http, էդ ամեն ինչը... Իսկ քո նկարագրած խնդիրների մեծ մասը, ոնց հասկանում եմ, առաջացել է հենց այս լուծումից...
YN: – Ի՞նչ ենք մենք օգտագործում TCP-ն:
Զ. -Ըստ էության՝ այո։
YN: - Ոչ:
Զ. – Արագhttp-ով էր, որ խնդիրներ ունեիք, կապի հետ խնդիրներ ունեիք: Եթե դուք նոր օգտագործեիք UDP-ն, դուք ինքներդ ձեզ որոշ ժամանակ կխնայեիք: Դե, երկար հաղորդագրությունների կամ այլ բանի հետ կապված խնդիրներ կառաջանային...
YN: -Ինչո՞վ:
Զ. – Երկար հաղորդագրություններով, քանի որ դա կարող է չտեղավորվել MTU-ի մեջ, այլ բան... Դե, կարող են լինել սեփական խնդիրներ: Հարցն այն է, թե ինչու ոչ UDP:
YN: – Ես կարծում եմ, որ հեղինակները, ովքեր մշակել են TCP/IP-ը, ինձանից շատ ավելի խելացի են և ինձնից լավ գիտեն, թե ինչպես սերիականացնել փաթեթները (այնպես, որ դրանք գնան), միևնույն ժամանակ կարգավորել ուղարկման պատուհանը, չծանրաբեռնել ցանցը, տալ կարծիք, թե ինչի մասին: չի կարդացվում, չհաշված մյուս կողմից... Այս բոլոր խնդիրները, իմ կարծիքով, կլինեին UDP-ում, միայն թե ես պետք է գրեի նույնիսկ ավելի շատ կոդ, քան արդեն գրել էի, որպեսզի ինքս իրականացնեմ նույն բանը և, ամենայն հավանականությամբ, վատ. Ես նույնիսկ իսկապես չեմ սիրում C-ով գրել, էլ չեմ խոսում այնտեղ...
Զ. - Պարզապես հարմար! Ուղարկվել է լավ և ոչ մի բանի մի սպասեք, այն ամբողջովին ասինխրոն է: Ետ եկավ ծանուցում, որ ամեն ինչ լավ է, դա նշանակում է, որ այն հասել է. Եթե դա չի գալիս, նշանակում է, որ դա վատ է:
YN: – Ինձ երկուսն էլ պետք են – Ես պետք է կարողանամ ուղարկել և՛ առաքման երաշխիքով, և՛ առանց առաքման երաշխիքի: Սրանք երկու տարբեր սցենարներ են։ Ես պետք է չկորցնեմ որոշ գերաններ կամ չկորցնեմ դրանք ողջամտության սահմաններում:
Զ. -Ես ժամանակ չեմ կորցնի։ Սա պետք է ավելի շատ քննարկվի: Շնորհակալություն.
Կապար: - Ով հարցեր ունի, ձեռքերը դեպի երկինք:
Զ. -Բարև, ես Սաշան եմ: Զեկույցի մեջտեղում ինչ-որ տեղ այնպիսի զգացողություն հայտնվեց, որ TCP-ից բացի հնարավոր է օգտագործել պատրաստի լուծում՝ ինչ-որ Կաֆկա։
YN: – Դե... ես ձեզ ասացի, որ չեմ ուզում օգտագործել միջանկյալ սերվերներ, քանի որ… Կաֆկայում պարզվում է, որ մենք ունենք տասը հազար հոսթ; իրականում մենք ավելի շատ ունենք՝ տասնյակ հազարավոր հյուրընկալողներ: Կարող է նաև ցավալի լինել Կաֆկայի հետ առանց որևէ վստահված անձի: Բացի այդ, ամենակարևորը, այն դեռ տալիս է «լատենտություն», տալիս է լրացուցիչ հոսթեր, որոնք դուք պետք է ունենաք: Բայց ես չեմ ուզում դրանք ունենալ, ես ուզում եմ…
Զ. «Բայց ի վերջո այդպես էլ ստացվեց»:
YN: - Ոչ, տանտերեր չկան: Այս ամենը աշխատում է Clickhouse հոսթինգների վրա:
Զ. - Դե, իսկ «Kittenhouse», որը հակառակն է, որտեղ է նա ապրում:
YN: – Clickhouse հոսթի վրա այն ոչինչ չի գրում սկավառակի վրա:
Զ. -Ենթադրենք.
Կապար: -Գո՞հ եք: Կարո՞ղ ենք ձեզ աշխատավարձ տալ:
Զ. - Այո, դու կարող ես. Փաստորեն, նույն բանը ստանալու համար շատ հենակներ կան, իսկ հիմա - TCP թեմայի նախորդ պատասխանը հակասում է, իմ կարծիքով, այս իրավիճակին։ Պարզապես թվում է, որ ամեն ինչ կարող էր արվել իմ ծնկների վրա շատ ավելի քիչ ժամանակում:
YN: – Եվ նաև ինչու չէի ուզում օգտագործել Կաֆկան, քանի որ Clickhouse Telegram չաթում բավականին շատ բողոքներ կային, որ, օրինակ, Կաֆկայի հաղորդագրությունները կորել են: Ոչ թե հենց Կաֆկայից, այլ Կաֆկայի և Քլիքհաուսի ինտեգրման մեջ; կամ ինչ-որ բան այնտեղ չի միացել: Կոպիտ ասած, այդ ժամանակ Կաֆկայի համար պատվիրատու գրելու կարիք կլիներ։ Չեմ կարծում, որ ավելի պարզ կամ վստահելի լուծում կարող է լինել:
Զ. - Ասա ինձ, ինչո՞ւ չփորձեցիր հերթեր կամ ինչ-որ սովորական ավտոբուս: Քանի որ դուք ասում եք, որ ասինխրոնությամբ դուք կարող եք տեղեկամատյաններն իրենք ուղարկել հերթի միջով և պատասխանը ստանալ ասինխրոն՝ հերթի միջով:
YN: - Խնդրում եմ առաջարկեք, թե ինչ հերթեր կարելի է օգտագործել:
Զ. – Ցանկացած, նույնիսկ առանց երաշխիքի, որ դրանք կարգին են: Մի տեսակ Redis, RMQ...
YN: – Ես այնպիսի զգացողություն ունեմ, որ Redis-ը, ամենայն հավանականությամբ, չի կարողանա մուտքագրման այնպիսի ծավալ ունենալ նույնիսկ մեկ հոսթի վրա (մի քանի սերվերների իմաստով), որը դուրս է հանում Clickhouse-ը: Ես չեմ կարող դա հիմնավորել որևէ ապացույցով (ես չեմ սահմանել այն), բայց ինձ թվում է, որ Redis-ը այստեղ լավագույն լուծումը չէ: Սկզբունքորեն, այս համակարգը կարելի է համարել որպես իմպրովիզացված հաղորդագրությունների հերթ, բայց որը հարմարեցված է միայն «Clickhouse»-ի համար։
Կապար: - Յուրի, շատ շնորհակալ եմ: Առաջարկում եմ հարց ու պատասխանն այստեղ ավարտել ու ասել, թե հարց տվողներից ում կտանք գիրքը։
YN: – Առաջին հարց տվողին ուզում եմ գիրք նվիրել:
Կապար: -Հրաշալի՜ Հիանալի Հիասքանչ! Շատ շնորհակալություն!
Մի քանի գովազդ 🙂
Շնորհակալություն մեզ հետ մնալու համար: Ձեզ դուր են գալիս մեր հոդվածները: Ցանկանու՞մ եք տեսնել ավելի հետաքրքիր բովանդակություն: Աջակցեք մեզ՝ պատվիրելով կամ խորհուրդ տալով ընկերներին, , մուտքի մակարդակի սերվերների եզակի անալոգ, որը հորինվել է մեր կողմից ձեզ համար. (հասանելի է RAID1 և RAID10-ով, մինչև 24 միջուկով և մինչև 40 ԳԲ DDR4):
Dell R730xd 2 անգամ ավելի էժան Ամստերդամի Equinix Tier IV տվյալների կենտրոնում: Միայն այստեղ Նիդեռլանդներում! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99-ից: Կարդացեք մասին
Source: www.habr.com