ClickHouse-ի արդյունավետ օգտագործումը: Ալեքսեյ Միլովիդով (Յանդեքս)

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

Բարեւ բոլորին! Իմ անունը Ալեքսեյ է, ես պատրաստում եմ ClickHouse-ը:

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

Փոխարենը կասեմ, թե ինչ հնարավոր սխալներ կան, այսինքն՝ ինչպես կարելի է սխալ օգտագործել ClickHouse-ը։ Իրականում, վախենալու կարիք չկա, քանի որ մենք զարգացնում ենք ClickHouse-ը որպես պարզ, հարմար և աննպատակահարմար համակարգ։ Տեղադրեցի, խնդիր չկա:

Բայց դուք դեռ պետք է հաշվի առնեք, որ այս համակարգը մասնագիտացված է, և դուք հեշտությամբ կարող եք հանդիպել անսովոր օգտագործման դեպքի, որը այս համակարգը դուրս կբերի իր հարմարավետության գոտուց:

Ուրեմն, ի՞նչ փոցխ կա։ Հիմնականում կխոսեմ ակնհայտ բաների մասին։ Ամեն ինչ ակնհայտ է բոլորի համար, բոլորն ամեն ինչ հասկանում են և կարող են ուրախանալ, որ այդքան խելացի են, իսկ նրանք, ովքեր չեն հասկանում, նոր բան կսովորեն։

Առաջին և ամենապարզ օրինակը, որը, ցավոք, հաճախ է պատահում, փոքր խմբաքանակներով մեծ քանակությամբ ներդիրներ են, այսինքն՝ մեծ քանակությամբ փոքր ներդիրներ:

Եթե ​​հաշվի առնենք, թե ինչպես է ClickHouse-ը կատարում ներդիրը, ապա կարող եք ուղարկել առնվազն մեկ տերաբայթ տվյալ մեկ հարցումով: Դա խնդիր չէ։

Եվ տեսնենք, թե ինչպիսին կլինի բնորոշ կատարումը: Օրինակ, մենք ունենք աղյուսակ Yandex.Metrica տվյալներից: Հիթեր. 105 որոշ սյունակներ. 700 բայթ չսեղմված: Եվ մենք լավ ձևով կտեղադրենք մեկ միլիոն տողերի խմբաքանակներում:

Մենք MergeTree-ն տեղադրում ենք աղյուսակի մեջ, ստացվում է վայրկյանում կես միլիոն տող: Հիանալի: Կրկնվող աղյուսակում այն ​​մի փոքր ավելի փոքր կլինի՝ մոտավորապես 400 տող վայրկյանում:

Եվ եթե միացնեք քվորումի ներդրումը, դուք կստանաք մի փոքր ավելի քիչ, բայց դեռ արժանապատիվ կատարում՝ 250 ժամկետ վայրկյանում: Քվորումի տեղադրումը չփաստաթղթավորված հատկություն է ClickHouse*-ում:

* 2020 թվականի դրությամբ, արդեն փաստաթղթավորված.

Ի՞նչ կլինի, եթե վատ բան անես: Մենք մեկ տող ենք տեղադրում MergeTree աղյուսակում և ստանում ենք 59 տող վայրկյանում: Դա 10 անգամ ավելի դանդաղ է: ReplicatedMergeTree-ում – 000 տող վայրկյանում: Իսկ եթե քվորումը միացված է, ուրեմն ստացվում է վայրկյանում 6 տող։ Իմ կարծիքով, սա մի տեսակ բացարձակ հիմարություն է: Ինչպե՞ս կարող ես այդպես դանդաղեցնել: Ես նույնիսկ իմ շապիկի վրա գրված եմ, որ ClickHouse-ը չպետք է դանդաղի: Բայց, այնուամենայնիվ, երբեմն պատահում է.

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

Տեխնիկական տեսանկյունից բանն այն է, որ երբ դուք ներդիր եք անում ClickHouse-ում, տվյալները չեն հայտնվում որևէ memtable-ում։ Մենք նույնիսկ չունենք իրական log կառուցվածք MergeTree, այլ պարզապես MergeTree, քանի որ չկա ոչ տեղեկամատյան, ոչ էլ memTable: Մենք ուղղակի անմիջապես գրում ենք տվյալները ֆայլային համակարգում՝ արդեն դասավորված սյունակներով: Իսկ եթե ունեք 100 սյունակ, ապա 200-ից ավելի ֆայլեր պետք է գրվեն առանձին գրացուցակում: Այս ամենը շատ ծանր է։

Եվ հարց է առաջանում. «Ինչպե՞ս դա անել ճիշտ»: Եթե իրավիճակն այնպիսին է, որ դեռ պետք է ինչ-որ կերպ գրանցել տվյալները ClickHouse-ում:

Մեթոդ 1. Սա ամենահեշտ ճանապարհն է: Օգտագործեք ինչ-որ բաշխված հերթ: Օրինակ՝ Կաֆկան։ Դուք պարզապես տվյալներ եք հանում Կաֆկայից և հավաքում դրանք վայրկյանը մեկ: Եվ ամեն ինչ լավ կլինի, դուք ձայնագրեք, ամեն ինչ լավ է աշխատում։

Թերությունները կայանում են նրանում, որ Kafka-ն մեկ այլ մեծածավալ բաշխված համակարգ է: Ես նաև հասկանում եմ, որ ձեր ընկերությունում արդեն ունեք Կաֆկա: Լավ է, հարմար է։ Բայց եթե այն գոյություն չունի, ապա դուք պետք է մտածեք երեք անգամ, նախքան ձեր նախագծի մեջ մեկ այլ բաշխված համակարգ քաշեք: Եվ այսպես, արժե դիտարկել այլընտրանքային տարբերակներ:

Մեթոդ 2. Սա հին դպրոցական այլընտրանք է և միևնույն ժամանակ շատ պարզ: Ունե՞ք ինչ-որ սերվեր, որը ստեղծում է ձեր տեղեկամատյանները: Եվ դա պարզապես գրում է ձեր տեղեկամատյանները ֆայլում: Եվ վայրկյանը մեկ, օրինակ, մենք վերանվանում ենք այս ֆայլը և պոկում ենք նորը: Եվ առանձին սկրիպտը, կամ cron-ի կամ ինչ-որ դեյմոնի միջոցով, վերցնում է ամենահին ֆայլը և գրում այն ​​ClickHouse-ում: Եթե ​​դուք գրանցում եք տեղեկամատյանները վայրկյանը մեկ, ապա ամեն ինչ լավ կլինի:

Բայց այս մեթոդի թերությունն այն է, որ եթե ձեր սերվերը, որի վրա ստեղծվում են տեղեկամատյանները, ինչ-որ տեղ անհետանում է, ապա տվյալները նույնպես կանհետանան:

Մեթոդ 3. Կա ևս մեկ հետաքրքիր մեթոդ, որն ընդհանրապես ժամանակավոր ֆայլեր չի պահանջում։ Օրինակ, դուք ունեք ինչ-որ գովազդային մանող կամ այլ հետաքրքիր դեմոն, որը տվյալներ է ստեղծում: Եվ դուք կարող եք կուտակել տվյալների մի փունջ անմիջապես RAM-ում, բուֆերում: Եվ երբ բավական ժամանակ է անցել, դուք այս բուֆերը մի կողմ եք դնում, ստեղծում եք նորը և առանձին թեմայում տեղադրում եք արդեն կուտակվածը ClickHouse-ում։

Մյուս կողմից, տվյալները նույնպես անհետանում են kill -9-ով։ Եթե ​​ձեր սերվերը խափանվի, դուք կկորցնեք այս տվյալները: Եվ մեկ այլ խնդիր այն է, որ եթե դուք չեք կարողացել գրել տվյալների բազա, ապա ձեր տվյալները կկուտակվեն RAM-ում: Եվ կամ RAM-ը կսպառվի, կամ դուք պարզապես կկորցնեք տվյալները:

Մեթոդ 4. Մեկ այլ հետաքրքիր մեթոդ. Ունե՞ք ինչ-որ սերվերային գործընթաց: Եվ այն կարող է անմիջապես ուղարկել տվյալներ ClickHouse-ին, բայց դա անել մեկ կապով: Օրինակ, ես ուղարկել եմ http հարցում փոխանցման կոդավորումով՝ chunked with insert: Եվ դա ոչ շատ հազվադեպ է ստեղծում կտորներ, դուք կարող եք ուղարկել յուրաքանչյուր տող, չնայած այս տվյալները շրջանակելու համար ծախսեր կլինեն:

Այնուամենայնիվ, այս դեպքում տվյալները անմիջապես կուղարկվեն ClickHouse-ին: Եվ ClickHouse-ը դրանք ինքնին կփուֆերացնի:

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

Մեթոդ 5. Ահա ևս մեկ հետաքրքիր մեթոդ. Սա մի տեսակ համայնքի կողմից մշակված սերվեր է տվյալների փաթեթավորման համար: Ես ինքս չեմ նայել, ուստի ոչինչ երաշխավորել չեմ կարող։ Այնուամենայնիվ, ClickHouse-ի համար երաշխիքներ չեն տրամադրվում: Սա նույնպես բաց կոդով է, բայց մյուս կողմից, դուք կարող եք սովոր լինել որոշ որակի ստանդարտի, որը մենք փորձում ենք ապահովել: Բայց այս բանի համար - չգիտեմ, գնացեք GitHub, նայեք կոդը: Երևի նորմալ բան են գրել։

* 2020 թվականից, նույնպես պետք է հաշվի առնել KittenHouse.

Մեթոդ 6. Մեկ այլ մեթոդ բուֆերային աղյուսակների օգտագործումն է: Այս մեթոդի առավելությունն այն է, որ այն շատ հեշտ է սկսել օգտագործել: Ստեղծեք բուֆերային աղյուսակ և տեղադրեք այն դրա մեջ:

Թերությունն այն է, որ խնդիրն ամբողջությամբ լուծված չէ։ Եթե ​​MergeTree-ի նման դրույքաչափով դուք պետք է խմբավորեք տվյալները վայրկյանում մեկ խմբաքանակով, ապա բուֆերային աղյուսակում դրույքաչափով դուք պետք է խմբավորեք առնվազն մինչև մի քանի հազար վայրկյանում: Եթե ​​վայրկյանում 10-ից ավելի լինի, միեւնույն է վատ կլինի։ Իսկ եթե խմբաքանակ մտցնես, ուրեմն տեսար, որ վայրկյանում հարյուր հազար տող է ստացվում։ Եվ սա արդեն բավականին ծանր տվյալների վրա է:

Եվ նաև բուֆերային աղյուսակները գրանցամատյան չունեն: Եվ եթե ձեր սերվերի հետ ինչ-որ բան այն չէ, ապա տվյալները կկորչեն:

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

Եվ այս հնարավորության մեջ հատկապես հաճելին այն է, որ մենք չէինք, որ դա արեցինք: Սա համայնքի առանձնահատկությունն է: Եվ երբ ասում եմ «համայնքային հատկանիշ», ես դա նկատի ունեմ առանց որևէ արհամարհանքի: Կարդացինք կոդը, վերանայեցինք, պետք է լավ աշխատի։

* 2020 թվականի դրությամբ նմանատիպ աջակցություն է հայտնվել Rabbit MQ.

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

* այս պահին խնդիրն ամբողջությամբ լուծված է, VALUES-ում արտահայտություններ օգտագործելիս այլևս չկա կատարողականի հետընթաց:

Մեկ այլ օրինակ, երբ կարող են լինել որոշ խնդիրներ, երբ դուք ունեք տվյալներ մեկ խմբաքանակի վերաբերյալ, որը պատկանում է մի շարք միջնորմների: Լռելյայնորեն, ClickHouse միջնորմները ըստ ամիսների են: Եվ եթե դուք տեղադրեք միլիոն տողերի խմբաքանակ, և կան մի քանի տարվա տվյալներ, ապա այնտեղ կունենաք մի քանի տասնյակ միջնորմ։ Եվ սա համարժեք է նրան, որ կլինեն մի քանի տասնյակ անգամ ավելի փոքր խմբաքանակներ, քանի որ ներսում դրանք միշտ առաջին հերթին բաժանվում են միջնորմների։

* Վերջերս, փորձարարական ռեժիմում, ClickHouse-ը աջակցություն է ավելացրել RAM-ի կտորների և կտորների կոմպակտ ձևաչափին, նախօրոք գրելու մատյանով, որը գրեթե ամբողջությամբ լուծում է խնդիրը:

Հիմա եկեք նայենք երկրորդ տեսակի խնդրին` տվյալների մուտքագրմանը:

Տվյալների մուտքագրումը կարող է լինել խիստ կամ լարային: String-ն այն է, երբ դուք պարզապես վերցրել եք այն և հայտարարել, որ ձեր բոլոր դաշտերը տիպի string են: Սա վատ է: Սա անելու կարիք չկա։

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

Օրինակ, մենք ունենք IP հասցե: Մի դեպքում մենք այն պահպանել ենք որպես տող։ Օրինակ, 192.168.1.1. Իսկ մեկ այլ դեպքում դա կլինի UInt32* տիպի մի շարք։ 32 բիթը բավարար է IPv4 հասցեի համար:

Նախ, տարօրինակ կերպով, տվյալները կսեղմվեն մոտավորապես հավասարապես: Տարբերություն, իհարկե, կլինի, բայց ոչ այդքան մեծ։ Այսպիսով, սկավառակի մուտքի / ելքի հետ կապված հատուկ խնդիրներ չկան:

Բայց պրոցեսորի ժամանակի և հարցումների կատարման ժամանակի լուրջ տարբերություն կա:

Եկեք հաշվենք եզակի IP հասցեների քանակը, եթե դրանք պահվում են որպես թվեր: Դա հասնում է 137 միլիոն տող վայրկյանում: Եթե ​​նույնը լարերի տեսքով է, ապա վայրկյանում 37 միլիոն տող։ Ես չգիտեմ, թե ինչու է այս զուգադիպությունը տեղի ունեցել։ Ես ինքս կատարեցի այս խնդրանքները։ Բայց դեռ մոտ 4 անգամ ավելի դանդաղ:

Իսկ եթե հաշվարկում եք սկավառակի տարածության տարբերությունը, ապա կա նաև տարբերություն։ Իսկ տարբերությունը մոտ մեկ քառորդ է, քանի որ կան բավականին շատ յուրահատուկ IP հասցեներ։ Իսկ եթե լինեին փոքրաթիվ տարբեր իմաստներով տողեր, ապա դրանք ըստ բառարանի հեշտությամբ կսեղմվեին մոտավորապես նույն ծավալի մեջ։

Իսկ քառապատիկ ժամանակային տարբերությունը ճանապարհի վրա չէ: Միգուցե դու չես տալիս, իհարկե, բայց երբ տեսնում եմ նման տարբերություն, տխրում եմ։

Դիտարկենք տարբեր դեպքեր։

1. Մի դեպք, երբ ունես քիչ տարբեր յուրահատուկ արժեքներ։ Այս դեպքում մենք օգտագործում ենք մի պարզ պրակտիկա, որը դուք հավանաբար գիտեք և կարող եք օգտագործել ցանկացած DBMS-ի համար: Այս ամենը իմաստ ունի ոչ միայն ClickHouse-ի համար: Պարզապես գրեք թվային նույնացուցիչներ տվյալների բազայում: Եվ դուք կարող եք փոխարկել տողերի և ետ ձեր հավելվածի կողմում:

Օրինակ՝ դուք տարածաշրջան ունեք։ Եվ դուք փորձում եք պահպանել այն որպես լար։ Իսկ այնտեղ գրվելու է՝ Մոսկվա և Մոսկվայի մարզ։ Եվ երբ տեսնում եմ, որ այնտեղ գրված է «Մոսկվա», դա ոչինչ է, բայց երբ Մոսկվան է, մի տեսակ լրիվ տխուր է դառնում։ Սա քանի բայթ է:

Փոխարենը, մենք պարզապես գրում ենք Ulnt32 և 250 համարները: Yandex-ում մենք ունենք 250, բայց ձերը կարող է տարբեր լինել: Ամեն դեպքում, ես կասեմ, որ ClickHouse-ն ունի ներկառուցված հնարավորություն աշխատելու գեոբազայի հետ: Դուք պարզապես գրեք գրացուցակ տարածաշրջաններով, ներառյալ հիերարխիկ, այսինքն՝ կլինեն Մոսկվա, Մոսկվայի մարզ և այն ամենը, ինչ ձեզ հարկավոր է: Եվ դուք կարող եք փոխարկել խնդրանքի մակարդակով:

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

Թերությունն այն է, որ դուք պետք է պարբերաբար փոխեք այն: Ավելացվեց ընդամենը մեկ տարբերակ. Եկեք փոխենք աղյուսակը: Փաստորեն, ClickHouse-ում փոփոխվող աղյուսակն անվճար է: Հատկապես անվճար Enum-ի համար, քանի որ սկավառակի տվյալները չեն փոխվում: Սակայն, այնուամենայնիվ, alter-ը ձեռք է բերում կողպեք* սեղանի վրա և պետք է սպասի մինչև բոլոր ընտրվածները կատարվեն: Եվ միայն դրանից հետո կփոխվի, այսինքն՝ դեռ որոշ անհարմարություններ կան:

* ClickHouse-ի վերջին տարբերակներում ALTER-ը ամբողջովին անարգելափակված է:

Մեկ այլ տարբերակ, որը բավականին յուրահատուկ է ClickHouse-ի համար, արտաքին բառարանների միացումն է։ Դուք կարող եք թվեր գրել ClickHouse-ում և պահել ձեր գրացուցակները ձեզ հարմար ցանկացած համակարգում: Օրինակ՝ կարող եք օգտագործել՝ MySQL, Mongo, Postgres: Դուք նույնիսկ կարող եք ստեղծել ձեր սեփական միկրոսերվիսը, որը կուղարկի այս տվյալները http-ի միջոցով: Իսկ ClickHouse մակարդակում դուք գրում եք մի ֆունկցիա, որը այս տվյալները թվերից կվերածի տողերի:

Սա մասնագիտացված, բայց շատ արդյունավետ միջոց է արտաքին սեղանի վրա միացում կատարելու համար: Եվ կա երկու տարբերակ. Մեկ մարմնավորման դեպքում այս տվյալներն ամբողջությամբ կպահվեն, ամբողջությամբ կներկայացվեն RAM-ում և թարմացվեն որոշակի հաճախականությամբ: Եվ մեկ այլ տարբերակում, եթե այս տվյալները չեն տեղավորվում RAM-ի մեջ, ապա կարող եք մասամբ քեշավորել դրանք:

Ահա մի օրինակ. Կա Yandex.Direct: Եվ կա գովազդային ընկերություն և բաններներ։ Հավանաբար կան մոտ տասնյակ միլիոն գովազդային ընկերություններ։ Եվ դրանք մոտավորապես տեղավորվում են RAM-ի մեջ: Եվ կան միլիարդավոր պաստառներ, դրանք չեն տեղավորվում: Եվ մենք օգտագործում ենք քեշավորված բառարան MySQL-ից:

Միակ խնդիրն այն է, որ քեշավորված բառարանը լավ կաշխատի, եթե հարվածի տոկոսադրույքը մոտ է 100%-ին: Եթե ​​այն ավելի փոքր է, ապա տվյալների յուրաքանչյուր խմբաքանակի համար հարցումները մշակելիս դուք իրականում պետք է վերցնեք բացակայող բանալիները և գնաք ստանալ տվյալները MySQL-ից: ClickHouse-ի մասին, ես դեռ կարող եմ երաշխավորել, որ այո, այն չի դանդաղում, ես չեմ խոսի այլ համակարգերի մասին:

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

Մեկ այլ միջոց, երբ չգիտեք, թե որտեղից կարող եք ստանալ ձեր տողերի նույնացուցիչները: դուք կարող եք պարզապես հաշել այն: Ավելին, ամենապարզ տարբերակը 64-բիթանոց հեշ վերցնելն է:

Միակ խնդիրն այն է, որ եթե հեշը 64-բիթ է, ապա գրեթե անկասկած կունենաք բախումներ: Որովհետև եթե այնտեղ միլիարդ տող կա, ապա հավանականությունն արդեն նկատելի է դառնում։

Իսկ գովազդային ընկերությունների անուններն այս կերպ հաշշելն այնքան էլ լավ չի լինի։ Եթե ​​խառնվեն տարբեր ընկերությունների գովազդային արշավները, ուրեմն անհասկանալի բան կլինի։

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

Որպես բոնուս, շատ գործողությունների համար միայն հեշերը բավարար են, և տողերն իրենք որևէ տեղ պահելու կարիք չունեն:

Մեկ այլ օրինակ, եթե տողերը կարճ են, օրինակ՝ կայքի տիրույթները։ Նրանք կարող են պահվել այնպես, ինչպես կա: Կամ, օրինակ, բրաուզերի լեզուն ru 2 բայթ է: Իհարկե, ես իսկապես ցավում եմ բայթերի համար, բայց մի անհանգստացեք, 2 բայթն ափսոս չէ: Խնդրում եմ պահել այնպես, ինչպես կա, մի անհանգստացեք:

Մեկ այլ դեպք, երբ, ընդհակառակը, կան շատ տողեր և դրանցում կան շատ եզակիներ, և նույնիսկ հավաքածուն պոտենցիալ անսահմանափակ է: Տիպիկ օրինակ են որոնման արտահայտությունները կամ URL-ները: Որոնեք արտահայտություններ, ներառյալ տառասխալները: Տեսնենք, թե օրական քանի եզակի որոնման արտահայտություն կա: Եվ պարզվում է, որ դրանք բոլոր իրադարձությունների գրեթե կեսն են։ Եվ այս դեպքում կարող եք մտածել, որ պետք է նորմալացնել տվյալները, հաշվել նույնացուցիչները և դնել առանձին աղյուսակում։ Բայց դուք պետք չէ դա անել: Պարզապես պահեք այս տողերը այնպես, ինչպես կան:

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

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

Եթե ​​ունեք URL-ներ կամ որևէ այլ բարդ երկար տող, ապա արժե հաշվի առնել, որ կարող եք նախապես հաշվարկել ինչ-որ քաղվածք և գրել այն առանձին սյունակում:

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

Տեսնենք, թե որն է տարբերությունը: ClickHouse-ն ունի մասնագիտացված ֆունկցիա, որը հաշվարկում է տիրույթը։ Այն շատ արագ է, մենք այն օպտիմալացրել ենք։ Եվ, ճիշտն ասած, այն նույնիսկ չի համապատասխանում RFC-ին, բայց, այնուամենայնիվ, հաշվի է առնում այն ​​ամենը, ինչ մեզ անհրաժեշտ է:

Եվ մի դեպքում մենք պարզապես կստանանք URL-ները և կհաշվարկենք տիրույթը։ Դա աշխատում է մինչև 166 միլիվայրկյան: Եվ եթե դուք վերցնում եք պատրաստի տիրույթ, ապա այն ստացվում է ընդամենը 67 միլիվայրկյան, այսինքն՝ գրեթե երեք անգամ ավելի արագ։ Եվ դա ավելի արագ է ոչ թե այն պատճառով, որ մենք պետք է որոշ հաշվարկներ անենք, այլ այն պատճառով, որ մենք ավելի քիչ տվյալներ ենք կարդում:

Դրա համար մեկ հարցումը, որն ավելի դանդաղ է, ունի գիգաբայթ վայրկյանում ավելի մեծ արագություն։ Քանի որ այն ավելի շատ գիգաբայթ է կարդում: Սա բոլորովին ավելորդ տվյալներ են։ Թվում է, թե հարցումն ավելի արագ է աշխատում, բայց այն ավարտելու համար ավելի երկար է տևում:

Իսկ եթե նայեք սկավառակի տվյալների քանակին, կստացվի, որ URL-ը 126 մեգաբայթ է, իսկ տիրույթը՝ ընդամենը 5 մեգաբայթ։ Ստացվում է 25 անգամ ավելի քիչ։ Բայց, այնուամենայնիվ, հարցումը կատարվում է ընդամենը 4 անգամ ավելի արագ։ Բայց դա պայմանավորված է նրանով, որ տվյալները տաք են: Իսկ եթե ցուրտ լիներ, ապա սկավառակի I/O-ի շնորհիվ հավանաբար 25 անգամ ավելի արագ կլիներ:

Ի դեպ, եթե դուք գնահատում եք, թե որքան փոքր է տիրույթը URL-ից, ապա պարզվում է, որ այն մոտ 4 անգամ փոքր է, բայց չգիտես ինչու, տվյալները սկավառակի վրա 25 անգամ ավելի քիչ են զբաղեցնում: Ինչո՞ւ։ Սեղմման պատճառով. Եվ URL-ը սեղմված է, և տիրույթը սեղմված է: Բայց հաճախ URL-ը պարունակում է մի փունջ աղբ:

Եվ, իհարկե, արժե օգտագործել տվյալների ճիշտ տեսակները, որոնք նախատեսված են հատուկ ցանկալի արժեքների համար կամ հարմար են: Եթե ​​դուք IPv4-ում եք, ապա պահեք UInt32*: Եթե ​​IPv6, ապա FixedString(16), քանի որ IPv6 հասցեն 128 բիթ է, այսինքն՝ պահվում է անմիջապես երկուական ձևաչափով:

Բայց ի՞նչ անել, եթե երբեմն ունեք IPv4 հասցեներ, իսկ երբեմն՝ IPv6: Այո, կարող եք երկուսն էլ պահել: Մեկ սյունակ IPv4-ի համար, մյուսը՝ IPv6-ի համար: Իհարկե, IPv4-ում IPv6 ցուցադրելու տարբերակ կա: Սա նույնպես կաշխատի, բայց եթե հարցումներում ձեզ հաճախ է անհրաժեշտ IPv4 հասցե, ապա լավ կլինի այն տեղադրել առանձին սյունակում:

* ClickHouse-ն այժմ ունի IPv4, IPv6 տվյալների առանձին տեսակներ, որոնք տվյալները պահպանում են նույնքան արդյունավետ, որքան թվերը, բայց դրանք ներկայացնում են նույնքան հարմար, որքան տողերը:

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

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

Այսպիսով, այս դեպքում ավելի ճիշտ կլինի բաժանել 4 սյունակի։ Մի վախեցեք այստեղ, քանի որ սա ClickHouse-ն է: ClickHouse-ը սյունակային տվյալների բազա է: Եվ որքան շատ կոկիկ փոքրիկ սյուներ, այնքան լավ: Կլինեն 5 BrowserVersions, կազմեք 5 սյունակ: Սա լավ է:

Հիմա եկեք տեսնենք, թե ինչ անել, եթե դուք ունեք շատ երկար տողեր, շատ երկար զանգվածներ: Նրանք բոլորովին կարիք չունեն պահելու ClickHouse-ում: Փոխարենը, դուք կարող եք պահել միայն նույնացուցիչը ClickHouse-ում: Եվ այս երկար տողերը դրեք ինչ-որ այլ համակարգի մեջ:

Օրինակ, մեր վերլուծական ծառայություններից մեկն ունի իրադարձության որոշ պարամետրեր: Եվ եթե իրադարձությունների համար շատ պարամետրեր կան, մենք պարզապես պահպանում ենք առաջին հանդիպած 512-ը, քանի որ 512-ը ափսոս չէ:

Եվ եթե դուք չեք կարող որոշել ձեր տվյալների տեսակները, ապա կարող եք նաև տվյալներ գրանցել ClickHouse-ում, բայց Log տիպի ժամանակավոր աղյուսակում, որը հատուկ է ժամանակավոր տվյալների համար: Դրանից հետո դուք կարող եք վերլուծել, թե ինչ արժեքների բաշխում ունեք այնտեղ, ինչ կա ընդհանրապես և ստեղծել ճիշտ տեսակներ:

*ClickHouse-ն այժմ ունի տվյալների տեսակ Ցածր կարդինալություն ինչը թույլ է տալիս արդյունավետ կերպով պահել լարերը՝ քիչ ջանք գործադրելով:

Հիմա անդրադառնանք մեկ այլ հետաքրքիր դեպքի. Երբեմն մարդկանց մոտ ամեն ինչ տարօրինակ է ստացվում: Ես մտնում եմ և տեսնում եմ սա։ Եվ անմիջապես թվում է, որ դա արվել է մի շատ փորձառու, խելացի ադմինի կողմից, ով մեծ փորձ ունի կարգավորելու MySQL տարբերակը 3.23:

Այստեղ մենք տեսնում ենք հազար աղյուսակներ, որոնցից յուրաքանչյուրը գրանցում է ով գիտի, հազարի բաժանման մնացորդը:

Սկզբունքորեն, ես հարգում եմ այլ մարդկանց փորձը, ներառյալ այն տառապանքի ըմբռնումը, որը կարելի է ձեռք բերել այս փորձառության միջոցով:

Իսկ պատճառները քիչ թե շատ պարզ են. Սրանք հին կարծրատիպեր են, որոնք կարող են կուտակվել այլ համակարգերի հետ աշխատելիս։ Օրինակ, MyISAM աղյուսակները չունեն կլաստերային առաջնային բանալի: Եվ տվյալների բաժանման այս ձևը կարող է լինել նույն ֆունկցիոնալությունը ստանալու հուսահատ փորձ:

Մեկ այլ պատճառ էլ այն է, որ մեծ սեղանների վրա դժվար է որևէ փոփոխական գործողություն կատարել: Ամեն ինչ կարգելափակվի։ Չնայած MySQL-ի ժամանակակից տարբերակներում այս խնդիրն արդեն այնքան էլ լուրջ չէ։

Կամ, օրինակ, microsharding, բայց դրա մասին ավելի ուշ:

ClickHouse-ում դա անելու կարիք չկա, քանի որ, նախ, առաջնային բանալին խմբավորված է, տվյալները դասակարգվում են առաջնային բանալիով։

Եվ երբեմն մարդիկ ինձ հարցնում են. «Ինչպե՞ս է տատանվում տիրույթի հարցումների կատարումը ClickHouse-ում՝ կախված աղյուսակի չափից»: Ասում եմ՝ ընդհանրապես չի փոխվում։ Օրինակ, դուք ունեք միլիարդ տող ունեցող աղյուսակ և կարդում եք մեկ միլիոն տողերի միջակայք: Ամեն ինչ լավ է. Եթե ​​աղյուսակում կա տրիլիոն տող, և դուք կարդաք մեկ միլիոն տող, ապա դա կլինի գրեթե նույնը:

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

ClickHouse-ում փոխելն անվճար է, եթե փոխեք ավելացնել/թողնել սյունակը:

Եվ դուք չպետք է փոքր սեղաններ պատրաստեք, քանի որ եթե աղյուսակում ունեք 10 տող կամ 10 տող, ապա դա ընդհանրապես նշանակություն չունի: ClickHouse-ը համակարգ է, որն օպտիմիզացնում է թողունակությունը, այլ ոչ թե հետաձգումը, ուստի անիմաստ է մշակել 000 տող:

Ճիշտ է օգտագործել մեկ մեծ սեղան: Ազատվեք հին կարծրատիպերից, ամեն ինչ լավ կլինի։

Եվ որպես բոնուս, վերջին տարբերակում մենք այժմ ունենք կամայական բաժանման բանալի ստեղծելու հնարավորություն՝ առանձին միջնորմների վրա սպասարկման բոլոր տեսակի գործողություններ կատարելու համար:

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

* այժմ ClickHouse-ը նույնպես ունի սեղանի ֆունկցիայի մուտքագրում.

Մեկ այլ հակաօրինաչափություն է microsharding-ը: Օրինակ, դուք պետք է բեկեք տվյալները և ունեք 5 սերվեր, իսկ վաղը կլինի 6 սերվեր: Եվ դուք մտածում եք, թե ինչպես կարելի է վերաբալանսի այս տվյալները: Եվ դրա փոխարեն դուք բաժանվում եք ոչ թե 5, այլ 1 բեկորի: Եվ հետո դուք քարտեզագրում եք այս միկրոշարդերից յուրաքանչյուրը առանձին սերվերի վրա: Եվ դուք, օրինակ, մեկ սերվերի վրա կստանաք, օրինակ, 000 ClickHouses: Առանձին օրինակներ առանձին նավահանգիստների կամ առանձին տվյալների բազաների վրա:

Բայց սա շատ լավ չէ ClickHouse-ում: Քանի որ նույնիսկ մեկ ClickHouse օրինակը փորձում է օգտագործել բոլոր հասանելի սերվերի ռեսուրսները մեկ հարցումը մշակելու համար: Այսինքն, դուք ունեք ինչ-որ սերվեր, և այն ունի, օրինակ, 56 պրոցեսորային միջուկ: Դուք կատարում եք հարցում, որը տևում է մեկ վայրկյան, և այն կօգտագործի 56 միջուկ: Իսկ եթե այնտեղ 200 ClickHouses տեղադրեք մեկ սերվերի վրա, ապա կստացվի, որ կսկսվի 10 թել։ Ընդհանուր առմամբ, ամեն ինչ շատ վատ է լինելու։

Մյուս պատճառն այն է, որ այս ատյաններում աշխատանքի բաշխումն անհավասար է լինելու։ Ոմանք ավելի շուտ կավարտեն, ոմանք՝ ավելի ուշ։ Եթե ​​այս ամենը տեղի ունենար մեկ օրինակով, ապա ClickHouse-ն ինքը կպարզեր, թե ինչպես ճիշտ բաշխել տվյալները թելերի միջև:

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

Մեկ այլ հակապատկեր, թեև այն դժվար թե կարելի է անվանել հակապատկեր։ Սա մեծ քանակությամբ նախնական համախմբում է:

Ընդհանուր առմամբ, նախնական համախմբումը լավ է: Դուք ունեիք միլիարդ տող, այն համախմբեցիք, և այն դարձավ 1 տող, և այժմ հարցումը կատարվում է ակնթարթորեն: Ամեն ինչ հիանալի է։ Դուք կարող եք դա անել: Եվ դրա համար նույնիսկ ClickHouse-ն ունի աղյուսակի հատուկ տեսակ՝ AggregatingMergeTree, որն իրականացնում է աճող ագրեգացիա, երբ տվյալները տեղադրվում են:

Բայց լինում են դեպքեր, երբ մտածում ես, որ մենք կհավաքենք այսպիսի տվյալներ և կհավաքենք այսպես: Եվ որոշ հարևան բաժանմունքում ես նույնպես չեմ ուզում ասել, թե որն է, նրանք օգտագործում են SummingMergeTree աղյուսակները՝ ամփոփելու հիմնական բանալիով, և մոտ 20 սյունակ օգտագործվում է որպես հիմնական բանալի: Ամեն դեպքում, ես փոխեցի որոշ սյունակների անունները գաղտնիության համար, բայց դա մոտավորապես այդպես է:

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

Իսկ ինչո՞վ է դա առանձնահատուկ: Փաստն այն է, որ հարեւան գերատեսչության այս մարդիկ երբեմն գնում են և խնդրում առաջնային բանալին ավելացնել ևս մեկ սյունակ։ Այսինքն՝ մենք հավաքել ենք տվյալները այսպես, բայց հիմա մի քիչ ավելին ենք ուզում։ Սակայն ClickHouse-ը չունի փոփոխվող հիմնական բանալի: Հետեւաբար, մենք պետք է գրենք որոշ սցենարներ C++-ով: Եվ ես չեմ սիրում սցենարներ, նույնիսկ եթե դրանք C++-ով են:

Եվ եթե նայեք, թե ինչի համար է ստեղծվել ClickHouse-ը, ապա ոչ ագրեգացված տվյալները հենց այն սցենարն են, որոնց համար այն ծնվել է: Եթե ​​դուք օգտագործում եք ClickHouse-ը ոչ համախմբված տվյալների համար, ապա դա ճիշտ եք անում: Եթե ​​դուք համախմբում եք, դա երբեմն ներելի է:

Մեկ այլ հետաքրքիր դեպք է հարցումները անսահման օղակում: Երբեմն ես գնում եմ ինչ-որ արտադրական սերվեր և նայում այնտեղ ցուցադրվող գործընթացների ցանկին: Եվ ամեն անգամ ես հայտնաբերում եմ, որ ինչ-որ սարսափելի բան է տեղի ունենում:

Օրինակ՝ այսպես. Անմիջապես պարզ է, որ ամեն ինչ կարելի է անել մեկ խնդրանքով: Պարզապես գրեք url-ը և ցուցակը այնտեղ:

Ինչու՞ են անվերջ օղակում շատ նման հարցումներ վատ: Եթե ​​ինդեքսը չի օգտագործվում, ապա դուք կունենաք բազմաթիվ անցումներ նույն տվյալների վրա: Բայց եթե ինդեքսն օգտագործվում է, օրինակ, դուք ունեք հիմնական բանալին ru-ի համար և այնտեղ գրում եք url = ինչ-որ բան: Եվ դուք կարծում եք, որ եթե աղյուսակից կարդացվի միայն մեկ URL, ամեն ինչ լավ կլինի։ Բայց իրականում ոչ: Քանի որ ClickHouse-ն ամեն ինչ անում է խմբաքանակով:

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

Եվ որպես բոնուս, կարող եք նշել, որ ClickHouse-ում չպետք է վախենաք նույնիսկ մեգաբայթեր և նույնիսկ հարյուրավոր մեգաբայթեր փոխանցել IN բաժին: Մեր պրակտիկայից ես հիշում եմ, որ եթե MySQL-ում մենք մի փունջ արժեքներ ենք փոխանցում IN բաժին, օրինակ, այնտեղ փոխանցում ենք 100 մեգաբայթ որոշ թվեր, ապա MySQL-ն ուտում է 10 գիգաբայթ հիշողություն և ուրիշ ոչինչ չի պատահում, ամեն ինչ: վատ է աշխատում.

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

Բայց, այնուամենայնիվ, կան որոշ դժվարություններ։ Օրինակ, այն փաստը, որ IN-ը ենթահղումով չի օգտագործում ինդեքսը: Բայց սա մեր խնդիրն է, և մենք պետք է շտկենք այն: Այստեղ հիմնարար ոչինչ չկա։ Մենք կուղղենք այն*.

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

* արդեն օգտագործում; Ամեն ինչ շտկվեց, ինչպես խոստացել էին։

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

Եվ կա միայն մեկ լուծում. Եթե ​​բացել եք API-ն, ապա ստիպված կլինեք կտրել այն։ Օրինակ՝ մի տեսակ քվոտաներ մտցրեք։ Ուրիշ նորմալ տարբերակներ չկան։ Հակառակ դեպքում անմիջապես սցենար կգրեն ու խնդիրներ կլինեն։

Իսկ ClickHouse-ն ունի հատուկ հատկություն՝ քվոտայի հաշվարկ։ Ավելին, դուք կարող եք փոխանցել ձեր քվոտայի բանալին: Սա, օրինակ, ներքին օգտագործողի ID-ն է: Իսկ դրանցից յուրաքանչյուրի համար քվոտաները կհաշվարկվեն ինքնուրույն։

Հիմա մեկ այլ հետաքրքիր բան. Սա ձեռքով կրկնօրինակում է:

Ես գիտեմ շատ դեպքեր, երբ, չնայած ClickHouse-ն ունի ներկառուցված կրկնօրինակման աջակցություն, մարդիկ ձեռքով կրկնում են ClickHouse-ը:

Ո՞րն է սկզբունքը։ Դուք ունեք տվյալների մշակման խողովակաշար: Եվ այն աշխատում է ինքնուրույն, օրինակ, տարբեր տվյալների կենտրոններում։ Նույն տվյալները նույն կերպ եք գրում ClickHouse-ում։ Ճիշտ է, պրակտիկան ցույց է տալիս, որ ձեր կոդի որոշ առանձնահատկությունների պատճառով տվյալները դեռևս կտարբերվեն: Հուսով եմ, որ դա ձեր մեջ է:

Եվ ժամանակ առ ժամանակ դուք դեռ ստիպված կլինեք ձեռքով համաժամեցնել: Օրինակ, ամիսը մեկ ադմինները rsync են անում:

Փաստորեն, շատ ավելի հեշտ է օգտագործել ClickHouse-ում ներկառուցված կրկնօրինակումը: Բայց կարող են լինել որոշ հակացուցումներ, քանի որ դրա համար անհրաժեշտ է օգտագործել ZooKeeper-ը: ZooKeeper-ի մասին վատ բան չեմ ասի, սկզբունքորեն համակարգը աշխատում է, բայց պատահում է, որ մարդիկ չեն օգտագործում java-phobia-ի պատճառով, քանի որ ClickHouse-ը այնքան լավ համակարգ է, գրված է C++-ով, որը կարող եք օգտագործել և ամեն ինչ լավ կլինի. Իսկ ZooKeeper-ը java-ում է: Եվ ինչ-որ կերպ դուք նույնիսկ չեք ուզում նայել, բայց հետո կարող եք օգտագործել ձեռքով կրկնօրինակում:

ClickHouse-ը գործնական համակարգ է: Նա հաշվի է առնում ձեր կարիքները: Եթե ​​դուք ունեք ձեռքով կրկնօրինակում, ապա կարող եք ստեղծել Բաշխված աղյուսակ, որը նայում է ձեր ձեռքով կրկնօրինակներին և կատարում ձախողում դրանց միջև: Եվ նույնիսկ կա հատուկ տարբերակ, որը թույլ է տալիս խուսափել ֆլոպներից, նույնիսկ եթե ձեր տողերը համակարգվածորեն տարբերվում են:

Հետագա խնդիրներ կարող են առաջանալ, եթե օգտագործեք պարզունակ սեղանի շարժիչներ: ClickHouse-ը կոնստրուկտոր է, որն ունի սեղանի տարբեր շարժիչների փունջ: Բոլոր լուրջ դեպքերի համար, ինչպես գրված է փաստաթղթերում, օգտագործեք MergeTree ընտանիքի աղյուսակները: Եվ մնացած բոլորը, դա այդպես է, առանձին դեպքերի կամ թեստերի համար:

MergeTree աղյուսակում ձեզ հարկավոր չէ որևէ ամսաթիվ և ժամ ունենալ: Դուք դեռ կարող եք օգտագործել այն: Եթե ​​չկա ամսաթիվ և ժամ, ապա գրեք, որ լռելյայն 2000 է: Սա կաշխատի և ռեսուրսներ չի պահանջի:

Իսկ սերվերի նոր տարբերակում դուք նույնիսկ կարող եք նշել, որ ունեք մաքսային բաժանում առանց բաժանման բանալի: Այդպես էլ կլինի։

Մյուս կողմից, դուք կարող եք օգտագործել պարզունակ սեղանի շարժիչներ: Օրինակ, մեկ անգամ լրացրեք տվյալները և նայեք, շրջեք և ջնջեք: Դուք կարող եք օգտագործել Log-ը:

Կամ միջանկյալ մշակման համար փոքր ծավալներ պահելը StripeLog կամ TinyLog է:

Հիշողությունը կարող է օգտագործվել, եթե տվյալների քանակը փոքր է, և դուք պարզապես կարող եք ինչ-որ բան խառնել RAM-ում:

ClickHouse-ին իրականում դուր չի գալիս վերանորմալացված տվյալները:

Ահա մի տիպիկ օրինակ. Սա URL-ների հսկայական քանակ է: Դուք դրանք դնում եք հաջորդ աղյուսակում: Եվ հետո նրանք որոշեցին իրենց հետ JOIN անել, բայց դա, որպես կանոն, չի աշխատի, քանի որ ClickHouse-ը միայն աջակցում է Hash JOIN-ին։ Եթե ​​չկա բավարար RAM շատ տվյալների համար, որոնք պետք է միացվեն, ապա JOIN-ը չի աշխատի*:

Եթե ​​տվյալները բարձր կարդինալություն են, ապա մի անհանգստացեք, պահեք դրանք ապանորմալացված ձևով, URL-ները ուղղակիորեն գտնվում են հիմնական աղյուսակում:

* և այժմ ClickHouse-ն ունի նաև միաձուլման միացում, և այն աշխատում է այնպիսի պայմաններում, երբ միջանկյալ տվյալները չեն տեղավորվում RAM-ում: Բայց սա անարդյունավետ է, և հանձնարարականը մնում է ուժի մեջ։

Մի երկու օրինակ էլ, բայց արդեն կասկածում եմ՝ հակապատկեր են, թե ոչ։

ClickHouse-ն ունի մեկ հայտնի թերություն. Այն չգիտի, թե ինչպես թարմացնել*: Որոշ առումներով սա նույնիսկ լավ է: Եթե ​​դուք ունեք որոշ կարևոր տվյալներ, օրինակ՝ հաշվապահություն, ապա ոչ ոք չի կարողանա այն ուղարկել, քանի որ թարմացումներ չկան։

* խմբաքանակի ռեժիմում թարմացման և ջնջման աջակցությունը վաղուց ավելացվել է:

Բայց կան մի քանի հատուկ եղանակներ, որոնք թույլ են տալիս թարմացումներ անել, կարծես հետին պլանում: Օրինակ՝ ReplaceMergeTree-ի նման աղյուսակներ: Նրանք թարմացումներ են կատարում ֆոնային միաձուլումների ժամանակ: Դուք կարող եք դա պարտադրել՝ օգտագործելով օպտիմալացնել աղյուսակը: Բայց դա շատ հաճախ մի արեք, քանի որ այն ամբողջությամբ կվերագրի միջնորմը:

ClickHouse-ում բաշխված JOIN-ները նույնպես վատ են մշակվում հարցումների պլանավորողի կողմից:

Վատ, բայց երբեմն լավ:

Օգտագործելով ClickHouse-ը միայն տվյալների հետ կարդալու համար՝ օգտագործելով select*:

Ես խորհուրդ չեմ տա օգտագործել ClickHouse-ը ծանր հաշվարկների համար: Բայց սա ամբողջովին ճիշտ չէ, քանի որ մենք արդեն հեռանում ենք այս առաջարկությունից: Եվ մենք վերջերս ավելացրել ենք մեքենայական ուսուցման մոդելներ կիրառելու հնարավորությունը ClickHouse - Catboost-ում: Եվ դա ինձ անհանգստացնում է, քանի որ մտածում եմ. «Ինչ սարսափ է: Ահա թե քանի ցիկլ է ստացվում մեկ բայթում: Ես իսկապես ատում եմ ժամացույցները բայթերով վատնելը:

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

Հարցեր

Շնորհակալություն զեկույցի համար: Որտե՞ղ կարող եմ բողոքել ClickHouse-ի խափանման մասին:

Դուք կարող եք բողոքել անձամբ ինձ հենց հիմա:

Վերջերս ես սկսեցի օգտագործել ClickHouse-ը: Ես անմիջապես գցեցի cli ինտերֆեյսը:

Ի՜նչ հաշիվ։

Քիչ անց ես խափանեցի սերվերը փոքր ընտրությամբ:

Դուք տաղանդ ունեք։

Ես բացեցի GitHub-ի սխալ, բայց այն անտեսվեց:

Մենք կտեսնենք:

Ալեքսեյը խաբեց ինձ մասնակցելու զեկույցին, խոստանալով ասել, թե ինչպես եք մուտք գործում ներսի տվյալները:

Շատ պարզ.

Ես սա հասկացա երեկ։ Ավելի մանրամասն.

Այնտեղ սարսափելի հնարքներ չկան։ Պարզապես կա բլոկ առ բլոկ սեղմում: Կանխադրվածը LZ4 է, կարող եք միացնել ZSTD*: Արգելափակում է 64 կիլոբայթից մինչև 1 մեգաբայթ:

* կա նաև աջակցություն մասնագիտացված սեղմման կոդեկների համար, որոնք կարող են օգտագործվել այլ ալգորիթմների հետ շղթայում:

Արդյո՞ք բլոկները պարզապես հումքային տվյալներ են:

Ոչ ամբողջովին հում: Կան զանգվածներ. Եթե ​​դուք ունեք թվային սյունակ, ապա անընդմեջ թվերը տեղադրվում են զանգվածում:

Պարզ է.

Ալեքսեյ, օրինակ, որը եղել է uniqExact-ի IP-ների միջոցով, այսինքն այն փաստը, որ uniqExact-ը տողերով հաշվարկելու համար ավելի երկար է տևում, քան թվերով և այլն: Իսկ եթե մենք ականջներով ֆինտ օգտագործենք և սրբագրման ժամանակ ձուլենք: Այսինքն, դուք կարծես ասել եք, որ մեր սկավառակի վրա դա շատ տարբեր չէ: Եթե ​​դիսկից տողեր կարդանք ու ձուլենք, մեր ագրեգատներն ավելի արագ կլինեն, թե ոչ։ Թե՞ այստեղ դեռ մի փոքր շահելու ենք։ Ինձ թվում է, որ դու սա փորձարկեցիր, բայց ինչ-ինչ պատճառներով չնշեցիր այն չափանիշում:

Կարծում եմ՝ ավելի դանդաղ կլինի, քան առանց քասթինգի։ Այս դեպքում IP հասցեն պետք է վերլուծվի տողից: Իհարկե, ClickHouse-ում մեր IP հասցեի վերլուծությունը նույնպես օպտիմիզացված է: Մենք շատ փորձեցինք, բայց այնտեղ դուք ունեք տասը հազարերորդ ձևով գրված թվերը։ Շատ անհարմար. Մյուս կողմից, uniqExact ֆունկցիան ավելի դանդաղ կաշխատի տողերի վրա, ոչ միայն այն պատճառով, որ դրանք տողեր են, այլ նաև այն պատճառով, որ ընտրված է ալգորիթմի այլ մասնագիտացում: Պարզապես տողերը տարբեր կերպ են մշակվում։

Իսկ եթե վերցնենք ավելի պարզունակ տվյալների տեսակ: Օրինակ, մենք գրել ենք օգտվողի ID-ն, որը մենք ունենք, գրել ենք որպես տող, իսկ հետո խառնել ենք, ավելի զվարճալի կլինի, թե ոչ:

Ես կասկածում եմ. Կարծում եմ՝ ավելի տխուր կլինի, քանի որ ի վերջո թվերի վերլուծությունը լուրջ խնդիր է։ Ինձ թվում է, որ այս գործընկերը նույնիսկ հաշվետվություն է տվել այն մասին, թե որքան դժվար է թվերը վերլուծել տասը հազարերորդական ձևով, բայց գուցե ոչ:

Ալեքսեյ, շատ շնորհակալ եմ զեկույցի համար: Եվ շատ շնորհակալ եմ ClickHouse-ի համար: Ես պլանների հետ կապված հարց ունեմ. Կա՞ն պլաններ, որ գործառույթը թերի թարմացնի բառարանները:

Այսինքն՝ մասնակի վերաբեռնում։

Այո այո. Հավանում է այնտեղ MySQL դաշտ սահմանելու հնարավորությունը, այսինքն՝ թարմացնել հետո, որպեսզի միայն այս տվյալները բեռնվեն, եթե բառարանը շատ մեծ է:

Շատ հետաքրքիր առանձնահատկություն. Եվ ես կարծում եմ, որ ինչ-որ մեկը դա առաջարկել է մեր զրուցարանում: Գուցե դա նույնիսկ դու էիր:

Չեմ կարծում։

Հիանալի է, հիմա պարզվում է, որ երկու խնդրանք կա. Եվ դուք կարող եք կամաց-կամաց սկսել դա անել: Բայց ես ուզում եմ անմիջապես զգուշացնել, որ այս հատկությունը բավականին պարզ է իրագործվում: Այսինքն՝ տեսականորեն ուղղակի պետք է աղյուսակում գրել տարբերակի համարը, հետո գրել՝ տարբերակ ավելի քիչ, քան այսինչը։ Սա նշանակում է, որ, ամենայն հավանականությամբ, մենք սա կառաջարկենք էնտուզիաստներին։ Դուք էնտուզիաստ եք:

Այո, բայց, ցավոք, ոչ C++-ով։

Ձեր գործընկերները գիտե՞ն ինչպես գրել C++-ով:

Ես կգտնեմ մեկին:

Հոյակապ*.

* Հատկանիշն ավելացվել է զեկույցից երկու ամիս անց. հարցի հեղինակը մշակել է այն և ուղարկել իրը քաշեք խնդրանքը.

Thank you!

Բարեւ Ձեզ! Շնորհակալություն զեկույցի համար: Դուք նշեցիք, որ ClickHouse-ը շատ լավ է սպառում իրեն հասանելի բոլոր ռեսուրսները: Իսկ Luxoft-ի կողքի խոսնակը խոսեց Ռուսական փոստի համար իր լուծման մասին։ Նա ասաց, որ իրենց շատ է դուր եկել ClickHouse-ը, բայց նրանք չեն օգտագործել այն իրենց հիմնական մրցակցի փոխարեն հենց այն պատճառով, որ այն խժռում է ամբողջ պրոցեսորը։ Եվ նրանք չկարողացան այն միացնել իրենց ճարտարապետությանը, իրենց ZooKeeper-ին` դոկերներով: Հնարավո՞ր է ինչ-որ կերպ սահմանափակել ClickHouse-ը, որպեսզի այն չսպառի այն ամենը, ինչ հասանելի է դառնում իրեն:

Այո, դա հնարավոր է և շատ հեշտ։ Եթե ​​ցանկանում եք ավելի քիչ միջուկներ սպառել, ապա պարզապես գրեք set max_threads = 1. Եվ վերջ, այն կկատարի հարցումը մեկ միջուկում: Ավելին, դուք կարող եք նշել տարբեր պարամետրեր տարբեր օգտվողների համար: Այնպես որ, խնդիր չկա: Եվ ասեք ձեր գործընկերներին Luxoft-ից, որ լավ չէ, որ նրանք չեն գտել այս կարգավորումը փաստաթղթերում:

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

Նախ, գերանները, որպես կանոն, երկար տողեր չեն: Բացառություններ, իհարկե, կան։ Օրինակ, java-ով գրված ինչ-որ ծառայություն բացառություն է գցում, այն գրանցվում է: Եվ այսպես շարունակ անվերջ օղակում, և կոշտ սկավառակի տարածքը սպառվում է: Լուծումը շատ պարզ է. Եթե ​​տողերը շատ երկար են, ապա կտրեք դրանք։ Ի՞նչ է նշանակում երկար: Տասնյակ կիլոբայթները վատ են*։

* ClickHouse-ի վերջին տարբերակներում միացված է «հարմարվողական ինդեքսի հատիկությունը», որը մեծ մասամբ վերացնում է երկար տողերի պահպանման խնդիրը:

Նորմա՞լ է կիլոբայթը:

Լավ:

Բարեւ Ձեզ! Շնորհակալություն զեկույցի համար: Ես արդեն հարցրել եմ այս մասին զրուցարանում, բայց չեմ հիշում, թե արդյոք պատասխան եմ ստացել։ Կա՞ն պլաններ ինչ-որ կերպ ընդլայնել ՀԵՏ բաժինը CTE-ի ձևով:

Դեռ ոչ. Մեր ՀԵՏ բաժինը որոշ չափով անլուրջ է: Դա մեզ համար նման է մի փոքրիկ հատկանիշի:

Ես հասկանում եմ. Շնորհակալություն!

Շնորհակալություն զեկույցի համար: Շատ հետաքրքիր! Գլոբալ հարց. Կա՞ն արդյոք ծրագրեր փոփոխելու տվյալների ջնջումը, միգուցե ինչ-որ տեսակի կոճղերի տեսքով:

Պարտադիր։ Սա մեր առաջին խնդիրն է մեր հերթում: Այժմ մենք ակտիվորեն մտածում ենք, թե ինչպես անել ամեն ինչ ճիշտ։ Եվ դուք պետք է սկսեք սեղմել ստեղնաշարը*:

* սեղմեց ստեղնաշարի կոճակները և արեց ամեն ինչ:

Սա ինչ-որ կերպ կազդի՞ համակարգի աշխատանքի վրա, թե՞ ոչ: Արդյո՞ք տեղադրումը կլինի այնքան արագ, որքան հիմա է:

Հավանաբար, ջնջումները և թարմացումներն իրենք շատ ծանր կլինեն, բայց դա չի ազդի ընտրվածների կամ ներդիրների կատարման վրա:

Եվ ևս մեկ փոքրիկ հարց. Ներկայացման ժամանակ դուք խոսեցիք առաջնային բանալին: Համապատասխանաբար ունենք բաժանում, որը լռելյայն ամսական է, ճի՞շտ է։ Եվ երբ մենք սահմանում ենք ամսաթվերի միջակայք, որը համապատասխանում է մեկ ամսվա, ապա միայն այս բաժանումը կարդում է, չէ՞:

Այո:

Մի հարց. Եթե ​​մենք չենք կարող ընտրել որևէ առաջնային բանալի, ապա ճի՞շտ է դա անել հատուկ «Ամսաթիվ» դաշտի համաձայն, որպեսզի հետին պլանում այս տվյալների ավելի քիչ վերադասավորում լինի, որպեսզի դրանք ավելի կանոնավոր կերպով տեղավորվեն: Եթե ​​դուք չունեք տիրույթի հարցումներ և չեք կարող նույնիսկ ընտրել որևէ հիմնական բանալի, արժե՞ ամսաթիվ նշել հիմնական բանալիում:

Այո:

Միգուցե իմաստ ունի առաջնային բանալիում տեղադրել մի դաշտ, որն ավելի լավ կսեղմի տվյալները, եթե դրանք դասավորված են ըստ այս դաշտի: Օրինակ, օգտվողի ID. Օգտատերը, օրինակ, գնում է նույն կայք։ Այս դեպքում դրեք օգտվողի ID-ն և ժամանակը: Եվ այդ ժամանակ ձեր տվյալները ավելի լավ կսեղմվեն: Ինչ վերաբերում է ամսաթվին, եթե դուք իսկապես չունեք և երբեք չունեք տիրույթի հարցումներ ամսաթվերի վերաբերյալ, ապա պետք չէ ամսաթիվը դնել հիմնական բանալիում:

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

Source: www.habr.com