Մենք կդիտարկենք, թե ինչպես է Zabbix-ը աշխատում TimescaleDB տվյալների բազայի հետ՝ որպես հետին պլան: Մենք ձեզ ցույց կտանք, թե ինչպես սկսել զրոյից և ինչպես տեղափոխել PostgreSQL-ից: Մենք նաև կտրամադրենք երկու կոնֆիգուրացիաների համեմատական կատարողականության թեստեր:
HighLoad++ Սիբիր 2019. Տոմսկի դահլիճ. հունիսի 24, ժամը 16:00։ Թեզեր և . Հաջորդ HighLoad++ համաժողովը կանցկացվի 6 թվականի ապրիլի 7-ին և 2020-ին Սանկտ Պետերբուրգում։ Մանրամասներ և տոմսեր .
Անդրեյ Գուշչին (այսուհետ՝ Ա.Գ.). – Ես ZABBIX տեխնիկական աջակցության ինժեներ եմ (այսուհետ՝ «Zabbix»), մարզիչ: Ես աշխատում եմ տեխնիկական սպասարկման ոլորտում ավելի քան 6 տարի և ունեի կատարողականի անմիջական փորձ: Այսօր ես կխոսեմ այն կատարման մասին, որը TimescaleDB-ն կարող է ապահովել սովորական PostgreSQL 10-ի հետ համեմատած: Նաև որոշ ներածական մաս այն մասին, թե ինչպես է այն աշխատում ընդհանուր առմամբ:
Արտադրողականության հիմնական մարտահրավերները. տվյալների հավաքագրումից մինչև տվյալների մաքրում
Սկզբից, կան որոշակի կատարողական մարտահրավերներ, որոնց բախվում է յուրաքանչյուր մոնիտորինգի համակարգ: Արտադրողականության առաջին մարտահրավերը տվյալների արագ հավաքումն ու մշակումն է:
Լավ մոնիտորինգի համակարգը պետք է արագ, ժամանակին ստանա բոլոր տվյալները, մշակի դրանք ըստ ձգանման արտահայտությունների, այսինքն՝ մշակի այն ըստ որոշ չափանիշների (տարբեր համակարգերում դա տարբեր է) և պահպանի այն տվյալների բազայում՝ այս տվյալները օգտագործելու համար: ապագան։
Երկրորդ կատարողական մարտահրավերը պատմության պահպանումն է: Հաճախ պահեք տվյալների բազայում և արագ և հարմար մուտք ունեցեք որոշակի ժամանակահատվածում հավաքագրված այս ցուցանիշներին: Ամենակարևորն այն է, որ այս տվյալները հարմար են ձեռք բերելու համար, օգտագործեք դրանք հաշվետվություններում, գրաֆիկներում, գործարկիչներում, որոշ շեմային արժեքներում, ազդանշանների համար և այլն:
Երրորդ կատարողական մարտահրավերը պատմության մաքրումն է, այսինքն, երբ դուք հասնում եք այն կետին, երբ ձեզ հարկավոր չէ պահպանել որևէ մանրամասն չափումներ, որոնք հավաքվել են 5 տարվա ընթացքում (նույնիսկ ամիս կամ երկու ամիս): Ցանցի որոշ հանգույցներ ջնջվել են, կամ որոշ հոսթորդներ, չափիչները այլևս անհրաժեշտ չեն, քանի որ դրանք արդեն հնացած են և այլևս չեն հավաքվում: Այս ամենը պետք է մաքրել, որպեսզի ձեր տվյալների բազան շատ չմեծանա: Ընդհանուր առմամբ, մաքրման պատմությունը ամենից հաճախ պահեստավորման համար լուրջ փորձություն է. այն հաճախ շատ ուժեղ ազդեցություն է ունենում աշխատանքի վրա:
Ինչպե՞ս լուծել քեշավորման խնդիրները:
Հիմա կոնկրետ Զաբբիքսի մասին կխոսեմ։ Zabbix-ում առաջին և երկրորդ զանգերը լուծվում են քեշավորման միջոցով:
Տվյալների հավաքագրում և մշակում - Այս բոլոր տվյալները պահելու համար մենք օգտագործում ենք RAM: Այս տվյալները այժմ կքննարկվեն ավելի մանրամասն:
Նաև տվյալների բազայի կողմում կա որոշ քեշավորում հիմնական ընտրանքների համար՝ գրաֆիկների և այլ բաների համար:
Քեշավորում հենց Zabbix սերվերի կողմից. մենք ունենք ConfigurationCache, ValueCache, HistoryCache, TrendsCache: Ինչ է դա?
ConfigurationCache-ը հիմնական քեշն է, որում մենք պահում ենք չափումներ, հոսթեր, տվյալների տարրեր, գործարկիչներ; այն ամենը, ինչ ձեզ անհրաժեշտ է նախնական մշակումը մշակելու, տվյալներ հավաքելու համար, թե որ հոսթներից հավաքել, ինչ հաճախականությամբ: Այս ամենը պահվում է ConfigurationCache-ում, որպեսզի չգնան տվյալների բազա և չստեղծեն ավելորդ հարցումներ։ Սերվերի գործարկումից հետո մենք թարմացնում ենք այս քեշը (ստեղծում ենք այն) և պարբերաբար թարմացնում այն (կախված կազմաձևման կարգավորումներից):
Քեշավորում Zabbix-ում: Տվյալների հավաքագրումը
Այստեղ դիագրամը բավականին մեծ է.
Սխեմայի հիմնականներն այս կոլեկտորներն են.
Սրանք հավաքման գործընթացներն են, զանազան «փոլերներ», որոնք պատասխանատու են տարբեր տեսակի հավաքների համար: Նրանք հավաքում են տվյալներ icmp-ի, ipmi-ի և տարբեր պրոտոկոլների միջոցով և այդ ամենը փոխանցում նախնական մշակման:
PreProcessing HistoryCache
Բացի այդ, եթե մենք ունենք հաշվարկված տվյալների տարրեր (նրանք, ովքեր ծանոթ են Zabbix-ին, գիտեն), այսինքն՝ հաշվարկված, ագրեգացիոն տվյալների տարրեր, մենք դրանք վերցնում ենք անմիջապես ValueCache-ից։ Թե ինչպես է այն լրացվում, հետո կասեմ: Այս բոլոր կոլեկցիոներներն օգտագործում են ConfigurationCache՝ իրենց աշխատանքները ստանալու և այնուհետև դրանք նախնական մշակման անցնելու համար:
Նախամշակումը նաև օգտագործում է ConfigurationCache-ը՝ նախնական մշակման քայլերը ձեռք բերելու և այս տվյալները տարբեր ձևերով մշակելու համար: Սկսած 4.2 տարբերակից՝ մենք այն տեղափոխել ենք վստահված անձ։ Սա շատ հարմար է, քանի որ նախնական մշակումն ինքնին բավականին բարդ գործողություն է։ Եվ եթե դուք ունեք շատ մեծ Zabbix, տվյալների մեծ քանակի տարրերով և հավաքագրման բարձր հաճախականությամբ, ապա դա մեծապես հեշտացնում է աշխատանքը:
Հետևաբար, այն բանից հետո, երբ մենք ինչ-որ կերպ մշակեցինք այս տվյալները՝ օգտագործելով նախնական մշակումը, մենք այն պահում ենք HistoryCache-ում՝ հետագա մշակման համար: Սա ավարտում է տվյալների հավաքագրումը: Մենք անցնում ենք հիմնական գործընթացին.
History syncer-ի աշխատանքը
Zabbix-ում հիմնական պրոցեսը (քանի որ այն մոնոլիտ ճարտարապետություն է) History syncer-ն է։ Սա հիմնական գործընթացն է, որը վերաբերում է հատուկ յուրաքանչյուր տվյալների տարրի ատոմային մշակմանը, այսինքն՝ յուրաքանչյուր արժեքին.
- արժեքը գալիս է (այն վերցնում է HistoryCache-ից);
- ստուգում է Configuration syncer-ում. կան արդյոք հաշվարկման գործարկիչներ - հաշվարկում է դրանք.
եթե կա - ստեղծում է իրադարձություններ, ստեղծում է էսկալացիա՝ ըստ կոնֆիգուրացիայի, անհրաժեշտության դեպքում ահազանգ ստեղծելու համար. - գրանցում է գործարկիչները հետագա մշակման, ագրեգացման համար. եթե դուք հավաքում եք վերջին մեկ ժամվա ընթացքում և այլն, ապա այս արժեքը հիշվում է ValueCache-ի կողմից, որպեսզի չգնա պատմության աղյուսակ. Այսպիսով, ValueCache-ը լցված է անհրաժեշտ տվյալներով, որոնք անհրաժեշտ են գործարկիչները, հաշվարկված տարրերը և այլն հաշվարկելու համար;
- ապա History syncer-ը գրում է բոլոր տվյալները տվյալների բազայում.
- տվյալների բազան դրանք գրում է սկավառակի վրա, այստեղ ավարտվում է մշակման գործընթացը:
Տվյալների բազա. Քեշավորում
Տվյալների բազայի կողմում, երբ ցանկանում եք դիտել գծապատկերներ կամ իրադարձությունների մասին որոշ հաշվետվություններ, կան տարբեր քեշեր: Բայց այս զեկույցում դրանց մասին չեմ խոսի։
MySQL-ի համար կա Innodb_buffer_pool և մի շարք տարբեր քեշեր, որոնք նույնպես կարող են կազմաձևվել:
Բայց սրանք են հիմնականները.
- shared_buffers;
- արդյունավետ_քեշ_չափ;
- shared_pool.
Բոլոր տվյալների բազաների համար ես ասացի, որ կան որոշակի քեշեր, որոնք թույլ են տալիս RAM-ում պահել այն տվյալները, որոնք հաճախ անհրաժեշտ են հարցումների համար: Նրանք ունեն իրենց սեփական տեխնոլոգիաները դրա համար:
Տվյալների բազայի կատարողականի մասին
Համապատասխանաբար, կա մրցակցային միջավայր, այսինքն՝ Zabbix սերվերը հավաքում է տվյալներ և գրանցում դրանք։ Երբ վերագործարկվում է, այն նաև կարդում է պատմությունից՝ լրացնելու ValueCache-ը և այլն: Այստեղ դուք կարող եք ունենալ սցենարներ և հաշվետվություններ, որոնք օգտագործում են Zabbix API-ն, որը կառուցված է վեբ ինտերֆեյսի վրա: Zabbix API-ն մուտք է գործում տվյալների բազա և ստանում է անհրաժեշտ տվյալներ գրաֆիկներ, հաշվետվություններ կամ իրադարձությունների, վերջին խնդիրների ինչ-որ ցուցակ ստանալու համար:
Նաև շատ հայտնի վիզուալիզացիայի լուծում է Grafana-ն, որն օգտագործում են մեր օգտատերերը: Կարող է ուղղակիորեն մուտք գործել ինչպես Zabbix API-ի, այնպես էլ տվյալների բազայի միջոցով: Այն նաև որոշակի մրցակցություն է ստեղծում տվյալների ձեռքբերման համար. տվյալների բազայի ավելի լավ, ավելի լավ կարգավորում է անհրաժեշտ՝ արդյունքների արագ առաքմանը և թեստավորմանը համապատասխանելու համար:
Պատմության մաքրում: Զաբբիսն ունի Տնտեսուհի
Երրորդ զանգը, որն օգտագործվում է Zabbix-ում, պատմությունը մաքրելն է՝ օգտագործելով Housekeeper-ը: Housekeeper-ը հետևում է բոլոր կարգավորումներին, այսինքն՝ մեր տվյալների տարրերը ցույց են տալիս, թե որքան ժամանակ է պահվում (օրերով), որքան ժամանակ է պահպանվում միտումները և փոփոխությունների դինամիկան:
Ես չխոսեցի TrendCache-ի մասին, որը մենք հաշվում ենք թռիչքի ժամանակ. տվյալները հասնում են, մենք դրանք հավաքում ենք մեկ ժամով (հիմնականում դրանք վերջին ժամի թվերն են), գումարը միջին/նվազագույն է, և մենք դա գրանցում ենք ժամը մեկ անգամ: Փոփոխությունների դինամիկայի աղյուսակ («Միտումներ»): «Housekeeper»-ը սկսում և ջնջում է տվյալները տվյալների բազայից՝ օգտագործելով կանոնավոր ընտրանքներ, ինչը միշտ չէ, որ արդյունավետ է:
Ինչպե՞ս հասկանալ, որ դա անարդյունավետ է: Ներքին գործընթացների կատարողական գրաֆիկների վրա կարող եք տեսնել հետևյալ նկարը.
Ձեր Պատմության համաժամեցումը մշտապես զբաղված է (կարմիր գրաֆիկ): Եվ վերևում գտնվող «կարմիր» գրաֆիկը: Սա «Տնային տնտեսուհի» է, որը սկսում է և սպասում, որ տվյալների բազան ջնջի իր կողմից նշված բոլոր տողերը:
Վերցնենք մի քանի ապրանքի ID. անհրաժեշտ է ջնջել վերջին 5 հազարը. իհարկե, ըստ ցուցանիշների։ Բայց սովորաբար տվյալների բազան բավականին մեծ է. տվյալների բազան դեռ կարդում է այն սկավառակից և տեղադրում քեշի մեջ, և սա շատ թանկ գործողություն է տվյալների բազայի համար: Կախված դրա չափից, դա կարող է հանգեցնել որոշակի կատարողական խնդիրների:
Դուք կարող եք անջատել Housekeeper-ը պարզ եղանակով՝ մենք ունենք ծանոթ վեբ ինտերֆեյս: Ընդհանուր ադմինիստրացիայի կարգավորումները («Տնային տնտեսվարի» կարգավորումները) մենք անջատում ենք ներքին տնային տնտեսությունը ներքին պատմության և միտումների համար: Համապատասխանաբար, Housekeeper-ն այլևս չի վերահսկում սա.
Ի՞նչ կարող ես անել հետո: Դուք անջատեցիք այն, ձեր գծապատկերները հավասարվեցին... Ի՞նչ հետագա խնդիրներ կարող են առաջանալ այս դեպքում: Ի՞նչը կարող է օգնել:
Բաժանում (բաժանում)
Սովորաբար սա տարբեր կերպ է կազմաձևվում իմ թվարկած յուրաքանչյուր հարաբերական տվյալների բազայում: MySQL-ն ունի իր տեխնոլոգիան։ Բայց ընդհանուր առմամբ դրանք շատ նման են, երբ խոսքը վերաբերում է PostgreSQL 10-ին և MySQL-ին: Իհարկե, կան բազմաթիվ ներքին տարբերություններ, թե ինչպես է այդ ամենը իրականացվում և ինչպես է այդ ամենը ազդում աշխատանքի վրա: Բայց ընդհանուր առմամբ, նոր բաժանման ստեղծումը հաճախ բերում է նաև որոշակի խնդիրների։
Կախված ձեր կարգավորումից (որքան տվյալներ եք ստեղծում մեկ օրում), նրանք սովորաբար սահմանում են նվազագույնը՝ սա 1 օր/խմբաքանակ է, իսկ «թրենդների» դեպքում՝ փոփոխությունների դինամիկան՝ 1 ամիս/նոր խմբաքանակ: Սա կարող է փոխվել, եթե դուք ունեք շատ մեծ կարգավորում:
Անմիջապես ասենք կարգաբերման չափի մասին՝ մինչև 5 հազար նոր արժեք վայրկյանում (այսպես կոչված nvps) - սա կհամարվի փոքր «կարգավորում»: Միջին - վայրկյանում 5-ից 25 հազար արժեք: Այն ամենը, ինչ վերը նշված է, արդեն մեծ և շատ մեծ տեղադրումներ են, որոնք պահանջում են տվյալների բազայի շատ զգույշ կազմաձևում:
Շատ մեծ տեղակայանքների դեպքում 1 օրը չի կարող օպտիմալ լինել: Ես անձամբ տեսել եմ MySQL-ում օրական 40 գիգաբայթանոց միջնորմներ (և կարող են լինել ավելին): Սա շատ մեծ քանակությամբ տվյալ է, որը կարող է հանգեցնել որոշ խնդիրների: Այն պետք է կրճատվի։
Ինչու՞ է ձեզ անհրաժեշտ բաժանումը:
Այն, ինչ ապահովում է Partitioning-ը, կարծում եմ բոլորը գիտեն, սեղանի բաժանումն է: Հաճախ դրանք առանձին ֆայլեր են սկավառակի վրա և ընդարձակման հարցումներ: Այն ընտրում է մեկ միջնորմ ավելի օպտիմալ, եթե այն սովորական բաժանման մաս է:
Zabbix-ի համար, մասնավորապես, այն օգտագործվում է ըստ տիրույթի, ըստ տիրույթի, այսինքն՝ մենք օգտագործում ենք ժամանակի դրոշմակնիք (կանոնավոր թիվ, ժամանակաշրջանի սկզբից սկսած ժամանակ)։ Դուք նշում եք օրվա սկիզբը/օրվա վերջը, և սա բաժանումն է: Համապատասխանաբար, եթե դուք երկու օրվա վաղեմության տվյալներ եք խնդրում, ամեն ինչ ավելի արագ է վերցվում տվյալների բազայից, քանի որ ձեզ հարկավոր է միայն մեկ ֆայլ բեռնել քեշ և վերադարձնել այն (այլ ոչ թե մեծ աղյուսակ):
Շատ տվյալների բազաներ նաև արագացնում են ներդիրը (տեղադրումը մեկ երեխայի աղյուսակում): Առայժմ վերացական եմ խոսում, բայց սա էլ հնարավոր է։ Հաճախ բաժանումը օգնում է:
Elastics որոնել NoSQL-ի համար
Վերջերս, 3.4-ում, մենք ներդրեցինք NoSQL լուծում: Ավելացվել է Elasticsearch-ում գրելու հնարավորություն: Դուք կարող եք գրել որոշակի տեսակներ. դուք ընտրում եք՝ կամ գրեք թվեր կամ որոշ նշաններ; մենք ունենք տողային տեքստ, դուք կարող եք գրել տեղեկամատյաններ Elasticsearch-ում... Համապատասխանաբար, վեբ ինտերֆեյսը մուտք կունենա նաև Elasticsearch: Սա որոշ դեպքերում հիանալի է աշխատում, բայց այս պահին այն կարող է օգտագործվել:
TimescaleDB. Hypertables
4.4.2-ի համար մենք ուշադրություն դարձրինք TimescaleDB-ի նման մի բանի: Ինչ է դա? Սա PostgreSQL-ի ընդլայնումն է, այսինքն՝ ունի բնիկ PostgreSQL ինտերֆեյս։ Բացի այդ, այս ընդլայնումը թույլ է տալիս շատ ավելի արդյունավետ աշխատել ժամանակագրական տվյալների հետ և ունենալ ավտոմատ բաժանում: Ինչ տեսք ունի.
Սա հիպերսեղան է՝ Timescale-ում նման հասկացություն կա։ Սա հիպերաղյուսակ է, որը դուք ստեղծում եք, և այն պարունակում է կտորներ: Կտորները միջնորմներ են, դրանք մանկական աղյուսակներ են, եթե չեմ սխալվում: Դա իսկապես արդյունավետ է:
TimescaleDB և PostgreSQL
Ինչպես հավաստիացնում են TimescaleDB արտադրողները, նրանք օգտագործում են ավելի ճիշտ ալգորիթմ հարցումների, մասնավորապես ներդիրների մշակման համար, ինչը թույլ է տալիս նրանց ունենալ մոտավորապես մշտական կատարում՝ տվյալների բազայի ներդիրի մեծացող չափերով: Այսինքն, Postgres-ի 200 միլիոն տողից հետո սովորականը սկսում է շատ թուլանալ և կորցնում է կատարումը բառացիորեն զրոյի, մինչդեռ Timescale-ը թույլ է տալիս հնարավորինս արդյունավետ կերպով ներդիրներ տեղադրել ցանկացած քանակությամբ տվյալների հետ:
Ինչպե՞ս տեղադրել TimescaleDB: Դա պարզ է!
Դա փաստաթղթերում է, նկարագրված է. այն կարող եք տեղադրել ցանկացած փաթեթից... Դա կախված է Postgres-ի պաշտոնական փաթեթներից: Կարող է կազմվել ձեռքով: Այնպես ստացվեց, որ ես ստիպված էի հավաքել տվյալների բազայի համար:
Zabbix-ում մենք պարզապես ակտիվացնում ենք Extention-ը: Կարծում եմ, որ նրանք, ովքեր օգտագործել են Extention-ը Postgres-ում... Դուք ուղղակի ակտիվացնում եք Extention-ը, ստեղծում այն Zabbix տվյալների բազայի համար, որն օգտագործում եք:
Եվ վերջին քայլը...
TimescaleDB. Պատմության աղյուսակների միգրացիան
Դուք պետք է ստեղծեք հիպերսեղան: Դրա համար կա հատուկ գործառույթ՝ Ստեղծել հիպերտեյբլ: Դրանում առաջին պարամետրը աղյուսակն է, որն անհրաժեշտ է այս տվյալների բազայում (որի համար անհրաժեշտ է ստեղծել հիպերաղյուսակ):
Դաշտը, որով պետք է ստեղծվի, և chunk_time_interval (սա կտորների միջակայքն է (բաժանումներ, որոնք պետք է օգտագործվեն): 86-ը մեկ օր է:
Migrate_data պարամետր. Եթե տեղադրեք true-ի, ապա սա կտեղափոխի բոլոր ընթացիկ տվյալները նախապես ստեղծված հատվածներին:
Ես ինքս օգտագործել եմ migrate_data – դա բավականին ժամանակ է պահանջում՝ կախված ձեր տվյալների բազայի մեծությունից: Ես ունեի ավելի քան մեկ տերաբայթ. ստեղծելու համար պահանջվեց ավելի քան մեկ ժամ: Որոշ դեպքերում, թեստավորման ժամանակ, ես ջնջել եմ տեքստի (history_text) և տողի (history_str) պատմական տվյալները, որպեսզի դրանք չփոխանցեմ. դրանք ինձ համար իսկապես հետաքրքիր չէին:
Եվ մենք կատարում ենք վերջին թարմացումը մեր db_extination-ում. տեղադրում ենք timescaledb, որպեսզի տվյալների բազան և, մասնավորապես, մեր Zabbix-ը հասկանա, որ կա db_extination: Նա ակտիվացնում է այն և օգտագործում է տվյալների բազայի ճիշտ շարահյուսությունը և հարցումները՝ օգտագործելով այն «հատկանիշները», որոնք անհրաժեշտ են TimescaleDB-ի համար։
Սերվերի կազմաձևում
Ես օգտագործել եմ երկու սերվեր: Առաջին սերվերը բավականին փոքր վիրտուալ մեքենա է, 20 պրոցեսոր, 16 գիգաբայթ օպերատիվ հիշողություն: Ես դրա վրա կարգավորեցի Postgres 10.8-ը.
Օպերացիոն համակարգը Debian-ն էր, ֆայլային համակարգը՝ xfs: Ես կատարել եմ նվազագույն պարամետրեր այս կոնկրետ տվյալների բազան օգտագործելու համար, մինուս այն, ինչ կօգտագործի ինքը Zabbix-ը: Նույն մեքենայի վրա կար Zabbix սերվեր, PostgreSQL և բեռնման գործակալներ:
Ես օգտագործել եմ 50 ակտիվ գործակալներ, որոնք օգտագործում են LoadableModule՝ արագ տարբեր արդյունքներ ստեղծելու համար: Նրանք են, ովքեր ստեղծել են տողերը, թվերը և այլն: Տվյալների բազան լցրեցի շատ տվյալներով։ Սկզբում կոնֆիգուրացիան պարունակում էր 5 հազար տվյալների տարր յուրաքանչյուր հյուրընկալողի համար, և մոտավորապես յուրաքանչյուր տվյալների տարր պարունակում էր ձգան, որպեսզի դա իրական կարգավորում լինի: Երբեմն ձեզ նույնիսկ անհրաժեշտ է մեկից ավելի ձգան օգտագործելու համար:
Ես կարգավորեցի թարմացման միջակայքը և բեռը` ոչ միայն օգտագործելով 50 գործակալներ (ավելացնելով ավելին), այլ նաև օգտագործելով դինամիկ տվյալների տարրեր և թարմացման միջակայքը նվազեցնելով մինչև 4 վայրկյան:
Կատարման թեստ. PostgreSQL՝ 36 հազար NVP
Առաջին գործարկումը, առաջին կարգավորումը, որը ես ունեի, մաքուր PostreSQL 10-ի վրա էր այս սարքավորման վրա (35 հազար արժեք վայրկյանում): Ընդհանուր առմամբ, ինչպես տեսնում եք էկրանին, տվյալների տեղադրումը վայրկյանի կոտորակներ է պահանջում՝ ամեն ինչ լավ է և արագ, SSD կրիչներ (200 գիգաբայթ): Միակ բանը, որ 20 ԳԲ-ը բավականին արագ է լցվում։
Նման գրաֆիկները ապագայում բավականին շատ կլինեն։ Սա Zabbix սերվերի աշխատանքի ստանդարտ վահանակ է:
Առաջին գրաֆիկը վայրկյանում արժեքների քանակն է (կապույտ, վերևի ձախ), այս դեպքում 35 հազար արժեք: Սա (վերևի կենտրոնը) կառուցման գործընթացների բեռնումն է, և սա (վերևի աջում) ներքին գործընթացների բեռնումն է՝ պատմության համաժամեցիչներ և տնային տնտեսուհի, որն այստեղ (ներքևի կենտրոնում) աշխատում է բավականին երկար ժամանակ:
Այս գծապատկերը (ներքևի կենտրոնում) ցույց է տալիս ValueCache-ի օգտագործումը. քանի ValueCache է հարվածում գործարկիչների համար (վայրկյանում մի քանի հազար արժեք): Մեկ այլ կարևոր գրաֆիկը չորրորդն է (ներքևում ձախից), որը ցույց է տալիս HistoryCache-ի օգտագործումը, որի մասին ես խոսեցի, որը բուֆեր է տվյալների բազայում տեղադրելուց առաջ:
Կատարման թեստ. PostgreSQL՝ 50 հազար NVP
Հաջորդը, ես նույն սարքավորման վրա ավելացրի բեռը մինչև 50 հազար արժեք վայրկյանում: Housekeeper-ի կողմից բեռնվելիս հաշվարկով 10-2 վայրկյանում գրանցվել է 3 հազար արժեք։ Այն, ինչ իրականում ցուցադրվում է հետևյալ սքրինշոթում.
«Տնային տնտեսուհին» արդեն սկսում է խանգարել աշխատանքին, բայց ընդհանուր առմամբ, պատմությունը խորտակող թակարդների ծանրաբեռնվածությունը դեռևս 60% մակարդակի վրա է (երրորդ գրաֆիկ, վերևի աջ կողմում): HistoryCache-ն արդեն սկսում է ակտիվորեն լցվել, մինչ Housekeeper-ն աշխատում է (ներքևում՝ ձախ): Մոտ կես գիգաբայթ էր, 20%-ով լցված։
Կատարման թեստ. PostgreSQL՝ 80 հազար NVP
Այնուհետև ես այն հասցրի վայրկյանում 80 հազար արժեքի.
Դա մոտավորապես 400 հազար տվյալների տարր էր, 280 հազար ձգան: Ներդիրը, ինչպես տեսնում եք, պատմության խորտակիչների ծանրաբեռնվածության առումով (դրանք 30-ն էին) արդեն բավականին բարձր էր։ Այնուհետև ես մեծացրի տարբեր պարամետրեր՝ պատմության խորտակիչներ, քեշ... Այս սարքաշարի վրա պատմության խորտակիչների ծանրաբեռնվածությունը սկսեց աճել մինչև առավելագույնը, գրեթե «դարակի վրա», համապատասխանաբար, HistoryCache-ը մտավ շատ բարձր բեռի մեջ.
Այս ամբողջ ընթացքում ես վերահսկում էի համակարգի բոլոր պարամետրերը (ինչպես է օգտագործվում պրոցեսորը, RAM-ը) և հայտնաբերեցի, որ սկավառակի օգտագործումը առավելագույնն է. «Պոստգրեսը» սկսեց բավականին ակտիվորեն թափել տվյալները նման ինտենսիվությամբ, և սկավառակն այլևս ժամանակ չուներ գրելու, կարդալու...
Ես վերցրեցի մեկ այլ սերվեր, որն արդեն ուներ 48 պրոցեսոր և 128 գիգաբայթ RAM.
Ես նաև «լարեցի» այն՝ տեղադրեցի History syncer (60 հատ) և հասա ընդունելի կատարման: Փաստորեն, մենք «դարակի վրա» չենք, բայց սա, հավանաբար, արտադրողականության սահմանն է, որտեղ արդեն անհրաժեշտ է ինչ-որ բան անել դրա դեմ:
Կատարման թեստ. TimescaleDB՝ 80 հազար NVP
Իմ հիմնական խնդիրն էր օգտագործել TimescaleDB: Յուրաքանչյուր գրաֆիկ ցույց է տալիս անկում.
Այս ձախողումները հենց տվյալների միգրացիան են: Դրանից հետո Zabbix սերվերում պատմության սինկերների բեռնման պրոֆիլը, ինչպես տեսնում եք, շատ է փոխվել։ Այն թույլ է տալիս մուտքագրել տվյալներ գրեթե 3 անգամ ավելի արագ և ավելի քիչ օգտագործել HistoryCache-ը, համապատասխանաբար, դուք կունենաք ժամանակին տրամադրված տվյալներ: Կրկին, 80 հազար արժեք վայրկյանում բավականին բարձր ցուցանիշ է (իհարկե, ոչ Yandex-ի համար): Ընդհանուր առմամբ, սա բավականին մեծ կարգավորում է՝ մեկ սերվերով:
PostgreSQL կատարողականի թեստ՝ 120 հազար NVP
Այնուհետև ես ավելացրեցի տվյալների տարրերի քանակի արժեքը մինչև կես միլիոն և ստացա վայրկյանում 125 հազար հաշվարկված արժեք.
Եվ ես ստացա այս գրաֆիկները.
Սկզբունքորեն, սա աշխատանքային կարգավորում է, այն կարող է աշխատել բավականին երկար ժամանակ: Բայց քանի որ ընդամենը 1,5 տերաբայթանոց սկավառակ ունեի, մի երկու օրում սպառեցի։ Ամենակարևորն այն է, որ միևնույն ժամանակ TimescaleDB-ում ստեղծվեցին նոր միջնորմներ, և դա կատարման համար բոլորովին աննկատ էր, ինչը չի կարելի ասել MySQL-ի մասին։
Սովորաբար, միջնորմները ստեղծվում են գիշերը, քանի որ դա սովորաբար արգելափակում է աղյուսակների տեղադրումն ու աշխատանքը և կարող է հանգեցնել ծառայության դեգրադացման: Այս դեպքում դա այդպես չէ: Հիմնական խնդիրը TimescaleDB-ի հնարավորությունների փորձարկումն էր։ Արդյունքը հետևյալ ցուցանիշն էր՝ 120 հազար արժեք վայրկյանում։
Համայնքում կան նաև օրինակներ.
Անձը նաև միացրել է TimescaleDB-ն, և io.weight-ի օգտագործման ծանրաբեռնվածությունն ընկել է պրոցեսորի վրա; և ներքին գործընթացի տարրերի օգտագործումը նույնպես նվազել է TimescaleDB-ի ընդգրկման պատճառով։ Ավելին, դրանք սովորական նրբաբլիթի սկավառակներ են, այսինքն սովորական վիրտուալ մեքենա սովորական սկավառակների վրա (ոչ թե SSD):
Որոշ փոքր կարգավորումների համար, որոնք սահմանափակված են սկավառակի կատարմամբ, TimescaleDB-ն, իմ կարծիքով, շատ լավ լուծում է: Այն թույլ կտա շարունակել աշխատել՝ նախքան տվյալների բազայի ավելի արագ սարքավորում տեղափոխելը:
Բոլորիդ հրավիրում եմ մեր միջոցառումներին. կոնֆերանս Մոսկվայում, գագաթնաժողով Ռիգայում: Օգտվե՛ք մեր ալիքներից՝ Telegram, ֆորում, IRC: Եթե հարցեր ունեք, եկեք մեր գրասեղանի մոտ, մենք կարող ենք ամեն ինչի մասին խոսել։
Հանդիսատեսի հարցեր
Հարց հանդիսատեսից (այսուհետ՝ A). - Եթե TimescaleDB-ն այդքան հեշտ է կարգավորվում, և այն տալիս է նման կատարողականի խթան, ապա միգուցե սա պետք է օգտագործվի որպես լավագույն պրակտիկա՝ Zabbix-ը Postgres-ի հետ կարգավորելու համար: Եվ կա՞ն այս լուծման որևէ որոգայթ և թերություններ, կամ, ի վերջո, եթե ես որոշեի ստեղծել Zabbix ինձ համար, կարող եմ հեշտությամբ վերցնել Postgres-ը, անմիջապես տեղադրել Timescale-ը, օգտագործել այն և չմտածել որևէ խնդրի մասին:
AG: – Այո, ես կասեի, որ սա լավ խորհուրդ է. անմիջապես օգտագործեք Postgres-ը TimescaleDB ընդլայնմամբ: Ինչպես արդեն ասացի, շատ լավ ակնարկներ, չնայած այն հանգամանքին, որ այս «առանձնահատկությունը» փորձնական է: Բայց իրականում թեստերը ցույց են տալիս, որ սա հիանալի լուծում է (TimescaleDB-ի հետ) և կարծում եմ, որ այն կզարգանա: Մենք հետևում ենք, թե ինչպես է զարգանում այս ընդլայնումը և անհրաժեշտության դեպքում փոփոխություններ կանենք:
Նույնիսկ մշակման ընթացքում մենք ապավինում էինք նրանց հայտնի «առանձնահատկություններից» մեկի վրա՝ հնարավոր էր փոքր-ինչ այլ կերպ աշխատել կտորների հետ: Բայց հետո նրանք կտրեցին այն հաջորդ թողարկումում, և մենք ստիպված եղանք դադարեցնել այս կոդի վրա հիմնվելը: Ես խորհուրդ կտայի օգտագործել այս լուծումը բազմաթիվ կարգավորումներում: Եթե օգտագործում եք MySQL... Միջին կարգավորումների դեպքում ցանկացած լուծում լավ է աշխատում:
A: – Համայնքի վերջին գրաֆիկների վրա կար «Տնային տնտեսուհի» գրաֆ.
Նա շարունակեց աշխատել։ Ի՞նչ է անում Housekeeper-ը TimescaleDB-ի հետ:
AG: – Հիմա հստակ չեմ կարող ասել – կնայեմ ծածկագիրը և ավելի մանրամասն կպատմեմ: Այն օգտագործում է TimescaleDB հարցումները ոչ թե կտորները ջնջելու, այլ դրանք ինչ-որ կերպ համախմբելու համար: Ես դեռ պատրաստ չեմ պատասխանել այս տեխնիկական հարցին։ Մենք ավելին կիմանանք այսօր կամ վաղը ստենդում:
A: – Ես նմանատիպ հարց ունեմ՝ Timescale-ում ջնջման գործողության կատարման մասին:
A (լսարանի պատասխանը). – Երբ դուք ջնջում եք տվյալները աղյուսակից, եթե դա անում եք ջնջման միջոցով, ապա պետք է անցնեք աղյուսակը՝ ջնջեք, մաքրեք, նշեք ամեն ինչ ապագա վակուումի համար: Timescale-ում, քանի որ դուք ունեք կտորներ, կարող եք թողնել: Կոպիտ ասած՝ մեծ տվյալների մեջ գտնվող ֆայլին պարզապես ասում եք՝ «Ջնջել»։
Timescale-ը պարզապես հասկանում է, որ նման հատված այլևս գոյություն չունի: Եվ քանի որ այն ինտեգրված է հարցումների պլանավորողին, այն օգտագործում է կեռիկներ՝ ընտրված կամ այլ գործողություններում ձեր պայմանները բռնելու համար և անմիջապես հասկանում է, որ այս հատվածն այլևս գոյություն չունի. «Ես այլևս այնտեղ չեմ գնա»: (տվյալները մատչելի չեն): Այսքանը: Այսինքն, սեղանի սկանավորումը փոխարինվում է երկուական ֆայլի ջնջմամբ, ուստի այն արագ է:
A: – Մենք արդեն անդրադարձել ենք ոչ SQL-ի թեմային: Որքան ես հասկանում եմ, Zabbix-ը իրականում կարիք չունի փոփոխելու տվյալները, և այս ամենը մատյանի պես մի բան է: Հնարավո՞ր է արդյոք օգտագործել մասնագիտացված տվյալների շտեմարաններ, որոնք չեն կարող փոխել իրենց տվյալները, բայց միևնույն ժամանակ շատ ավելի արագ են պահպանում, կուտակում և բաշխում - Clickhouse, օրինակ, Կաֆկայի նման մի բան: Կաֆկան նույնպես տեղեկամատյան է: Հնարավո՞ր է ինչ-որ կերպ դրանք ինտեգրել:
AG: -Բեռնաթափում կարելի է անել։ Մենք ունենք որոշակի «առանձնահատկություն» սկսած 3.4 տարբերակից. դուք կարող եք գրել բոլոր պատմական ֆայլերը, իրադարձությունները, մնացած ամեն ինչ ֆայլերում. և այնուհետև ուղարկեք այն որևէ այլ տվյալների բազա՝ օգտագործելով ինչ-որ կարգավորիչ: Փաստորեն, շատ մարդիկ վերամշակում և գրում են անմիջապես տվյալների բազայում: Ինքնաթիռի ժամանակ պատմության սինկերները գրում են այս ամենը ֆայլերի մեջ, պտտում են այս ֆայլերը և այլն, և դուք կարող եք դա փոխանցել Clickhouse: Ես չեմ կարող ասել պլանների մասին, բայց միգուցե NoSQL լուծումների հետագա աջակցությունը (օրինակ՝ Clickhouse) կշարունակվի։
A: – Ընդհանրապես, պարզվում է, որ դուք կարող եք լիովին ազատվել պոստգրեսից:
AG: – Իհարկե, Zabbix-ում ամենադժվարը պատմական աղյուսակներն են, որոնք ստեղծում են ամենաշատ խնդիրներն ու իրադարձությունները: Այս դեպքում, եթե դուք երկար ժամանակ չեք պահում իրադարձությունները և պահպանում եք պատմությունը միտումներով որևէ այլ արագ պահեստավորման մեջ, ապա ընդհանուր առմամբ, կարծում եմ, խնդիրներ չեն լինի։
A: – Կարո՞ղ եք գնահատել, թե որքան ավելի արագ կաշխատի ամեն ինչ, եթե, օրինակ, անցնեք Քլիքհաուսին:
AG: - Ես դա չեմ փորձարկել: Կարծում եմ, որ գոնե նույն թվերին կարելի է հասնել բավականին պարզ՝ հաշվի առնելով, որ Clickhouse-ն ունի իր ինտերֆեյսը, բայց ես չեմ կարող հստակ ասել: Ավելի լավ է փորձարկել: Ամեն ինչ կախված է կոնֆիգուրացիայից՝ քանի հոսթ ունեք և այլն: Տեղադրումը մի բան է, բայց դուք նույնպես պետք է առբերեք այս տվյալները՝ Grafana կամ այլ բան:
A: – Այսինքն՝ մենք խոսում ենք հավասար պայքարի մասին, այլ ոչ թե այս արագ տվյալների բազաների մեծ առավելությունների մասին։
AG: - Կարծում եմ, երբ ինտեգրվենք, ավելի ճշգրիտ թեստեր կլինեն։
A: – Ո՞ւր գնաց հին բարի RRD-ն: Ի՞նչը ստիպեց ձեզ անցնել SQL տվյալների բազաներին: Սկզբում բոլոր ցուցանիշները հավաքագրվել են RRD-ում:
AG: – Zabbix-ն ուներ RRD, հավանաբար շատ հին տարբերակով: SQL տվյալների բազաները միշտ եղել են՝ դասական մոտեցում: Դասական մոտեցումը MySQL-ն է, PostgreSQL-ը (դրանք գոյություն ունեն շատ վաղուց)։ Մենք գրեթե երբեք չենք օգտագործել ընդհանուր ինտերֆեյս SQL և RRD տվյալների բազաների համար:
Մի քանի գովազդ 🙂
Շնորհակալություն մեզ հետ մնալու համար: Ձեզ դուր են գալիս մեր հոդվածները: Ցանկանու՞մ եք տեսնել ավելի հետաքրքիր բովանդակություն: Աջակցեք մեզ՝ պատվիրելով կամ խորհուրդ տալով ընկերներին, , մուտքի մակարդակի սերվերների եզակի անալոգ, որը հորինվել է մեր կողմից ձեզ համար. (հասանելի է 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