Մենք կքննարկենք Zabbix-ի աշխատանքի առանձնահատկությունները TimescaleDB տվյալների բազայի հետ որպես backend։ Ապացուցելու ենք, թե ինչպես սկսել զրոյից եւ ինչպես տեղափոխվել PostgreSQL-ից։ Также приведем сравнительные тесты производительности двух конфигураций.
HighLoad++ Սիբիր 2019։ «Տոմսկ» դահլիճը։ Իյունիսի 24, 16:00։ Թեզիսներ եւ ։ Ներառել պիտակ «HighLoad++» հաջորդ կոնֆերանսը կանցկացվի 2020 թվականի ապրիլի 6-ին և 7-ին Սանկտ Պետերբուրգում։ մանրամասները եւ տոմսերը .
Անդրեյ Գուշչինը (անվանումը – ԱԳ): – Ես ZABBIX տեխնիկական աջակցման ինժեներ եմ (անվանումը – «Զաբբիկս»), մարզիչ։ Ես ավելի քան 6 տարի աշխատում եմ տեխնիկական աջակցությունում եւ ուղիղ կապված եմ արտադրողականության հետ։ Այսօր ես պատմելու եմ TimescaleDB-ի մատուցած արտադրողականության մասին, համեմատելով սովորական PostgreSQL 10-ի հետ։ Եվ որոշակի մուտքային մաս կպատմեմ, թե ինչպես է դա աշխատում։
Արտադրողականության հիմնական մարտահրավերներ. տվյալների հավաքումից մինչև մաքրման գործընթացը
Սկսում ենք նրանից, որ կա որոշակի արտադրողականության մարտահրավերներ, որոնց բախվում է յուրաքանչյուր մոնիթորումային համակարգ։ Նախնական արտադրողականության մարտահրավերը` տվյալների արագ հավաքումն ու մշակումը։
Լավ մոնիթորինգի համակարգը պետք է արագ եւ ժամանակին ստանա բոլոր տվյալները, մշակել դրանք ըստ պահերային արտահայտությունների, այսինքն՝ մշակել ըստ որոշակի չափանիշների (յուրաքանչյուր համակարգում դա տարբեր է) և պահել տվյալների բազայում, որպեսզի հետագայում այդ տվյալները օգտագործվեն։
Երկրորդ արտադրողականության մարտահրավերը այն է, որ պատմությունը պահելուց հետո։ Պահել տվյալների բազայում եւ ունենալ արագ եւ հարմար հասանելիություն այդ մեթրիկներին, որոնք հավաքվել են որոշակի ժամանակահատվածում։ Ամենակարևորը, որ այդ տվյալները հեշտությամբ հասանելի լինեն, օգտագործվեն հաշվետվություններում, գծապատկերներում, դերերներում, որոշակի շեմային արժեքների, ծանուցումների համար եւ այլն։
Երրորդ արտադրողականության մարտահրավերը պատմության մաքրման գործընթացն է, այսինքն` երբ ձեզ մեկ օր գալիս է այն օրը, երբ ձեզ պետք չէ պահել որոշ մանրամասն մեթրիկներ, որոնք հավաքվել են 5 տարվա ընթացքում (ընդ որում, կարող են լինել ամիսներ կամ երկու ամիս)। Որոշ ցանցային узлы արվել են, կամ որոշ հոսթեր, метрики արդեն չեն անհրաժեշտ, որովհետեւ ի վերջո դրանք դարձել են հնացած եւ դադարել են հավաքվել։ Սա ամեն ինչը պետք է մաքրվել, որպեսզի ձեր տվյալների բազան չընդլայնվի մեծ չափերի։ Եվ ընդհանրապես, պատմության մաքրման գործընթացը հաճախ առկա է մի լուրջ փորձ մարտահրավերների համար` հաճախ ազդելով արտադրողականության վրա։
Ինչպես լուծել կաշիռի խնդիրները։
Ես հիմա խոսելու եմ որոշակիորեն «Զաբբիկս»-ի մասին։ «Զաբբիկս»-ում առաջին և երկրորդ մարտահրավերները լուծված են կաշիռով։
Տվյալների հավաքում և մշակումը` մենք օգտագործում ենք օպերատիվ հիշողությունը բոլոր այս տվյալները պահելու համար։ Հիմա այդ մասին կլինի ավելի մանրամասն խոսք։
Այնպես էլ տվյալների բազայի կողմում կան որոշակի կաշիռային հնարքներ հիմնական ընտրություների համար` գծապատկերների, այլ բաների համար։
Zabbix-ի ինքնուրույն կեշավորում. Մեր մոտ ընդգրկված են ConfigurationCache, ValueCache, HistoryCache, TrendsCache։ Ի՞նչ են դրանք:
ConfigurationCache-ը հիմնական կեշն է, որտեղ պահում ենք մետրիկաները, հոստերը, տվյալների բաղադրիչները, եռանկյունները։ Եվ դա անհրաժեշտ է պրեպրոցեսինգի, տվյալների հավաքման համար, թե որ հոստերից հավաքել, որ հաճախականությամբ։ Իր ամփոփվածությունը թույլ է տալիս չգնալ տվյալների բազա, չստեղծել ավելորդ հարցումներ։ Սերվերի մեկնարկից հետո կեշը թարմացնում ենք (ստեղծում) և հետևաբար ժամանակ առ ժամանակ (կոնֆիգուրացիայի կարգավորումներից կախված) թարմացնում։
Zabbix-ում կեշավորում. Տվյալների հավաքում
Այս պահին սխեման բավական մեծ է։
Սխեմայի հիմնական բաղադրիչներն են՝ այս հավաքիչները։
Դրանք հավաքման գործընթացներն են, տարբեր «փոլլերներ», որոնք պատասխանատվություն են կրում տարբեր տեսակների հավաքման համար։ Նրանք հավաքում են տվյալներ icmp, ipmi, տարբեր ծրագրային պրոտոկոլներով և փոխանցում դրանք պրեպրոցեսինգի։
PreProcessing HistoryCache
Որպեսզի ունենանք հաշվարկվող տվյալների բաղադրիչներ (ո՛վ է ծանոթ «Zabbix»-ին՝ գիտի), այսինքն՝ հաշվարկվող, ագրեգատիվ տվյալների մասեր, դրանք վերցնում ենք անմիջապես ValueCache-ից։ Ինչպես է այն լցվում, խոսելու եմ ավելի ուշ։ Սատիպանոցները օգտագործում են ConfigurationCache-ը իրենց տրված խնդիրները ստանալու համար և շարունակաբար փոխանցում դեպի պրեպրոցեսինգ։
Պրեպրոցեսինգն օգտագործում է նույնպես ConfigurationCache-ը՝ պրեպրոցեսինգի քայլերը ստանալու համար, մշակելով տվյալները տարբեր ձևերով։ 4.2 տարբերակից սկսած, այն տեղափոխվել է պրոքսի։ Դա շատ Հարմար է, քանի որ յուրաքնչյուր պրեպրոցեսինգը՝ բավականին ծանր ընթացակարգ է։ Եվ եթե ունեք շատ մեծ «Zabbix», մեծ թվով տվյալների բաղադրիչներով և բարձր հավաքման հաճախականությամբ, այն շատ հեշտացնում է աշխատանքը։
Ու entsprechend, երբ մշակել ենք տվյալները ինչ-որ կերպ պրեպրոցեսինգի միջոցով, պահում ենք դրանք HistoryCache-ում, որպեսզի հետագայում մշակենք։ Այստեղ ավարտվում է տվյալների հավաքումը։ Մենք անցնում ենք գլխավոր գործընթացին։
History syncer-ի աշխատանքը
Գլխավորը՝ «Zabbix»-ում (քանզի դա մոնոլիտային ճարտարապետություն է)՝ History syncer-ն է։ Սա գլխավոր գործընթացն է, որն զբաղվում է յուրաքանչյուր տվյալների բաղադրիչի ատոմար մշակմամբ, այսինքն՝ յուրաքանչյուր արժեքագործութամբ՝
- արժեքը գալիս է (այն վերցնում է HistoryCache-ից);
- ստուգում է Configuration syncer-ում՝ արդյոք կան եռանկյուններ հաշվարկման համար։ Եթե կան, դրանք հաշվարկում է;
եթե կան, ապա ստեղծում է իրադրություններ, ստեղծում է էսկալացիա գնալու համար, որպեսզի ստեղծի ազդարարություն, եթե դա անհրաժեշտ է конфигурации-ից; - գրում է եռանկյունները հետագա մշակման, ագրեգացման համար։ Եթե դուք ագրեգացնում եք վերջին ժամվա ընթացքում և այլն, այս արժեքը հիշում է ValueCache-ում, որպեսզի չդիմի պատմության աղյուսակին; այսպիսով, ValueCache-ը լցվում է անհրաժեշտ տվյալներով, որոնք անհրաժեշտ են եռանկյունների, հաշվարկվող բաղադրիչների և այլն հաշվարկելու համար;
- պատմության սինխեր հ записывает все данные в базу данных;
- Հիմնական տվյալները գրանցվում են սկավառակում՝ գործընթացը դրա հետ ավարտվում է:
Տվյալների բազաներ։ Քեշավորում
Տվյալների բազայի կողմից, երբ ցանկանում եք տեսնել գծապատկերներ կամ որոշ հաշվետվություններ իրադարձությունների մասին, կան տարբեր քեշեր։ Սակայն այս զեկույցում չեմ քննարկի դրանք։
MySQL-ի համար կա Innodb_buffer_pool, եւ դեռ շատ տարբեր քեշեր, որոնք նույնպես կարելի է կարգավորել։
Սրանք հիմնականներն են՝
- shared_buffers;
- effective_cache_size;
- shared_pool.
Ես բոլոր տվյալների բազաների համար ներկայացրել եմ, որ կան որոշակի քեշեր, որոնք թույլ են տալիս պահպանել оперативной памяти чаще պահանջվող տվյալները։ Այնտեղ իրենց տեխնոլոգիաներն են նման գործողությունների համար։
Տվյալների բազայի կատարողականության մասին
Հետևաբար, կա մրցակցային միջավայր, այսինքն՝ «Զաբբիքս» սերվերն հավաքում է տվյալներ եւ գրանցում դրանք։ Պետականության վերագործարկման ժամանակ նա նույնպես կարդում է պատմությունից, որպեսզի լցնի ValueCache-ն եւ այլն։ Այստեղ կարող եք ունենալ սցենարներ եւ հաշվետվություններ, որոնք օգտագործում են «Զաբբիքս»-API, որը կառուցված է վեբ-հրահանգման վրա։ «Զաբբիքս»-API-ն մտնում է ԲԴ եւ ստանում անհրաժեշտ տվյալները՝ գծապատկերներ, հաշվետվություններ կամ որոշակի իրադարձությունների, վերջին խնդիրների ցուցակ ստանալու համար։
Նաեւ չափազանց արդիական լուծում է մոդելավորելու համար՝ Grafana, որը օգտագործում են մեր օգտվողները։ Այն կարողանում է մուտք գործել թե՛ «Զաբբիքս»-API-ի միջոցով, թե՛ ԲԴ-ի միջոցով։ Այդ ժամին նույնպես ստեղծում է որոշակի մրցակցություն տվյալների ներգրավման համար։ Պետք է ավելի նուրբ, լավ կարգավորում ԲԴ, որպեսզի համապատասխանի արագ արդյունքների տրամադրմանը եւ փորձարկմանը։
Պատմության մաքրում։ «Զաբբիքս»-ում կա Housekeeper
Երրորդ կանչը, որն օգտագործվում է «Զաբբիքս»-ում՝ պատմության մաքրումն է Housekeeper-ի միջոցով։ «Հաուսքիփերը» պահպանում է բոլոր կարգավորումները, այսինքն՝ մեր տվյալների տարրերում նշված է, թե որքան պահել (օրերով), որքան պահել միտումները, փոփոխությունների դինամիկան։
Ես չեմ պատմել ՏրենդՔեշի մասին, որը հաշվարկում ենք即时։ Կատարվում են տվյալներ, մենք դրանք агрегացնում ենք մեկ ժամում (առավելապես՝ վերջին ժամի համար թիվ), միջին / նվազագույն քանակությամբ եւ գրում ենք դա մեկ ժամում փոփոխությունների դինամիկայի աղյուսակում (Տրենդս)։ «Հաուսքիփերը» մեկնարկվում է եւ ջնջում է սովորական ընտրությամբ տվյալներ ԲԴ-ից, ինչը միշտ էլ արդյունավետ չէ։
Ինչպե՞ս հասկանալ, որ դա արդյունավետ չէ։ Դուք կարող եք ներքին գործընթացների կատարողականության գծապատկերներում տեսնել այս պատկերը՝
Դուք ունեք History syncer-ը մշտապես զբաղված (կարմիր գծագրություն)։ Իսկ «որոշած» գծագրությունը, որը վերևում է՝ դա «Հաուսքիփերն» է, որը մեկնարկվում է եւ սպասում է ԲԴ-ից, մինչև կջնջի բոլոր տողերը, որոնք նա սահմանել է։
Վերցնենք որեւէ Item ID։ Պետք է ջնջել վերջին 5000-ն; իհարկե, կողմնորոշված տվյալներիացին։ Բայց սովորաբար տվյալների հավաքածուն բավականին մեծ է՝ տվյալների բազան այնպես թե այնպես կկարդացնի սկավառակից եւ տեղադրի քեշում, ինչը շատ թանկ գործողություն է ԲԴ-ի համար։ Նրա չափերից կախված, դա կարող է բերել որոշակի կատարողական խնդիրների։
«Housekeeper»-ը կարող եք անջատել պարզ ճանապարհով՝ մեր հայտնի վեբ-հաճախորդի միջոցով: Ծրագրավորման բաժնում Administration general (հաճախորդի համար «Housekeeper»-ի կարգավորումներ) մենք անջատում ենք ներսում գտնվող housekeeping-ը ներքին պատմության և միտումների համար: Համապատասխանաբար, «Housekeeper»-ը այլևս չի կառավարում սա:
Ի՞նչ կարող եք անել հաջորդը: Դուք անջատվել եք, գրաֆիկները հավասարեցվել են… Այս դեպքում ի՞նչ կարող են լինել հետագա խնդիրները: Ի՞նչ կարող է օգնել:
Партиционирование (секционирование)
Նորմալ կերպով, դա կարգավորվում է յուրաքանչյուր հարաբերական տվյալների բազայում, որ ես թվարկել եմ, տարբեր եղանակներով: MySQL- ում իր տեխնոլոգիան է: Բայց ընդհանուր առմամբ, դրանք բավականին նման են, եթե խոսում ենք PostgreSQL 10 և MySQL մասին: Համոզված եմ, այնտեղ շատ ներքին տարբերություններ կան, թե ինչպես է դա իրականանում և ինչպես է դա ազդում կատարողականության վրա: Բայց ընդհանուր առմամբ, նոր բաժանման ստեղծումը հաճախ նաև հանգեցնում է որոշակի խնդիրների:
Ձեր setup-ից կախված (ինչքան շատ տվյալներ եք ստեղծում օրը), սովորաբար սահմանվում է ամենափոքրը՝ 1 օր/բաժանման համար, իսկ «միտումների», փոփոխությունների դինամիկայի համար՝ 1 ամիս/նոր բաժանման համար: Սա կարող է փոխվել, եթե ունեք շատ մեծ setup:
Ամեն ինչ արագ ասեմ setup-ի չափերի մասին. մինչ 5000 նոր արժեքի մեկ վարկյանում (nvps կոչվողը) – դա կպահպանվի փոքր «setup»: Դիմացի – 5-ից 25 հազար արժեքի մեկ վարկյանում: Ամեն ինչ, ինչից վերև, արդեն մեծ և շատ մեծ տեղադրվածք է, որոնք պահանջում են շատ մանրակրկիտ տվյալների բազայի կարգավորում:
Ամեն մեծ տեղադրումներում 1 օրը՝ դա կարող էր չլինել օպտիմալ: Ես անձամբ տեսել եմ MySQL-ում 40 գիգաբայթ բաժանումներ 1 օրը (և ավել ևս կարող են լինել): Սա շատ մեծ տվյալների ծավալ է, որը կարող է հանգեցնել որոշակի խնդիրների: Սա պետք է փոքրացնել:
Ինչու է անհրաժեշտ партиционирование?
Partitioning-ը ի՞նչ օգուտ է ունենում, կարծում եմ, բոլորը գիտեն՝ դա աղյուսակների секционирование-ն է: Հաճախ դա առանձին ֆայլեր են սկավառակում և պսև-հարցումներ: Այն ավելի լավ ընտրություն է անում մեկ բաժանման, եթե դա մտնում է սովորական партиционирование:
«Zabbix»-ի համար, մասնավորապես, օգտագործվում է ռեյնջով, հետևաբար մենք օգտագործում ենք timestamp (սովորական թիվ, ժամանակի սկիզբը): Դուք սահմանում եք օրվա սկիզբ/վերջ, և սա է հանդիսանում բաժանում: Համապատասխանաբար, եթե դուք հարցնում եք երկու օրվա վաղության տվյալների համար, դա բոլորը կարողանում են ավելի արագ վերցնել տվյալների բազայից, քանի որ հարկավոր է միայն մեկ ֆայլ լիցքավորել կոշտ վիճակահանման մեջ և ներկայացնել (և ոչ մեծ աղյուսակ):
Շատ ԲԴ-ներ նաև արագացնում են insert (ներմուծումը մեկ child-աղյուսակ): Hasta ես խոսում եմ абстрактно, բայց սա նույնպես հնարավոր է: Parтиционирование-ը հաճախ օգնում է:
Elasticsearch для NoSQL
हाल ही में, 3.4 में, हमने NoSQL समाधान लागू किया। Elasticsearch में लिखने की संभावना जोड़ी। आप कुछ विशेष प्रकार के डेटा लिख सकते हैं: या तो संख्या या कुछ प्रतीक चुनते हैं; हमारे पास स्ट्रिंग-टेक्स्ट है, आप Elasticsearch में लॉग्स लिख सकते हैं… इसके अनुसार, वेब इंटरफेस भी अब Elasticsearch को संबोधित करेगा। यह कुछ मामलों में उत्कृष्टता के साथ काम करता है, लेकिन वर्तमान में इसका उपयोग किया जा सकता है।
TimescaleDB। हाइपरटेबल्स
4.4.2 के लिए, हमने TimescaleDB पर एक चीज़ पर ध्यान दिया। यह क्या है? यह PostgreSQL के लिए एक एक्सटेंशन है, जिसका मतलब है कि इसमें PostgreSQL का नेटिव इंटरफेस है। इसके अलावा, यह एक्सटेंशन टाइमसीरीज डेटा के साथ अधिक प्रभावी ढंग से काम करने और स्वचालित विभाजन की सुविधा देता है। यह कैसे दिखता है:
यह हाइपरटेबल है – यह टाइमस्केल में एक अवधारणा है। यह एक हाइपरटेबल है, जिसे आप बनाते हैं, और इसमें चंक्स (chunk) होते हैं। चंक्स – ये विभाजन हैं, ये चाइल्ड-टेबल्स हैं, अगर मैं गलत नहीं हूँ। यह वास्तव में प्रभावशाली है।
TimescaleDB और PostgreSQL
TimescaleDB के निर्माता सुनिश्चित करते हैं कि वे प्रश्नों के प्रबंधन के लिए एक अधिक प्रभावी एल्गोरिदम का उपयोग करते हैं, विशेष रूप से insert के लिए, जो डेटा सेट-इन्सर्शन के आकार के बढ़ने पर लगभग स्थिर प्रदर्शन बनाए रखता है। यानी 200 मिलियन पंक्तियों के बाद ‘PostgreSQL’ सामान्य तौर पर बहुत कमज़ोर हो जाता है और सचमुच शून्य के करीब प्रदर्शन खो देता है, जबकि ‘Timescale’ किसी भी डेटा की मात्रा के साथ inserts को अधिकतम दक्षता से सम्मिलित करने की अनुमति देता है।
TimescaleDB कैसे स्थापित करें? यह बहुत आसान है!
इसकी दस्तावेज़ीकरण में लिखा है – इसे विभिन्न पैकेजों से स्थापित किया जा सकता है… यह आधिकारिक ‘PostgreSQL’ पैकेजों पर निर्भर करता है। इसे मैन्युअल रूप से भी संकलित किया जा सकता है। ऐसा हुआ कि मुझे डेटाबेस के लिए संकलित करना पड़ा।
‘Zabbix’ पर हम बस एक्सटेंशन सक्रिय करते हैं। मुझे लगता है कि जो लोग ‘PostgreSQL’ में एक्सटेंशन का उपयोग कर चुके हैं… आप बस एक्सटेंशन को सक्रिय करते हैं, इसे उस ‘Zabbix’ डेटाबेस के लिए बनाते हैं, जिसका आप उपयोग करते हैं।
और आखिरी कदम…
TimescaleDB। ऐतिहासिक टेबलों को परिभाषित करना
आपको हाइपरटेबल बनाना है। इसके लिए एक विशेष फ़ंक्शन है – Create hypertable। इसमें पहले पैरामीटर के रूप में उस तालिका का नाम बताएं, जो इस डेटाबेस में चाहिए (जिसके लिए हाइपरटेबल बनाना है)।
क्षेत्र, जिसके आधार पर बनाना है, और chunk_time_interval (यह चंक्स का अंतराल है (विभाजन, जिन्हें उपयोग करना है)। 86 400 – यह एक दिन है।
पैरामीटर migrate_data: यदि आप इसे true में डालते हैं, तो यह सभी मौजूदा डेटा को पूर्व-निर्मित चंक्स में स्थानांतरित करता है।
मैंने खुद migrate_data का उपयोग किया – इसमें काफी समय लगता है, आपके डेटाबेस का आकार क्या है, इस पर निर्भर करता है। मेरे पास एक टेराबाइट से अधिक था – निर्माण में एक घंटे से अधिक समय लगा। कुछ मामलों में परीक्षण करते समय मैंने असल में इतिहासात्मक डेटा (history_text) और स्ट्रिंग (history_str) को हटा दिया ताकि मैं इसे न स्थानांतरित करूँ – ये वास्तव में मेरे लिए दिलचस्प नहीं थे।
Վերջին թարմացումը կատարում ենք մեր db_extention-ում: Մենք տեղադրում ենք timescaledb-ը, որպեսզի տվյալների հիմքն ու մեր «Զաբբիքս»-ը հասկանան, թե ինչ է db_extention-ը։ Այն ակտիվացնում է և ճիշտ օգտագործում տնտեսչական և запросները տվյալների հիմքին, օգտագործելով արդեն այն «ֆունկցիաները», որոնք անհրաժեշտ են TimescaleDB-ի համար։
Սերվերի մոդիֆիկացում
Ես օգտագործել եմ երկու սերվեր: Առաջին սերվերը՝ դա բավական փոքր վիրտուալ մեքենա է, 20 պրոցեսոր, 16 գիգաբայթ օպերատեսիոն հիշողություն: Կարգավորեցի դրա վրա PostgreSQL 10.8:
Օպերացիոն համակարգը եղել է Debian, ֆայլային համակարգը՝ xfs: Կատարեցի նվազագույն կարգավորումներ, որպեսզի օգտագործեմ հենց այս տվյալների հիմքը, բացառությամբ այն, որ այն օգտագործելու է ինքն «Զաբբիքս»-ը: Այդ նույն մեքենայում կար «Զաբբիքս»-սերվեր, PostgreSQL և բեռնային գործակալներ:
Ես օգտագործել եմ 50 ակտիվ գործակալներ, որոնք օգտագործում են LoadableModule, որպեսզի արագ գեներացնեն տարբեր արդյունքներ: Նրանք գեներացնում էին տողեր, թվեր, և այլն: Ես լցնում էի տվյալների հիմքը մեծ քանակությամբ տվյալներով: Սկզբնական կարգավորումը պարունակում էր 5000 տվյալների տարր յուրաքանչյուր հոստի համար, և մոտավորապես յուրաքանչյուր տվյալների տարրը ուներ թրիգեր՝ որպեսզի ստեղծվի իրական setup: Иногда для использования даже требуется больше одного триггера.
Թարմացման ինտերվալը, ինքնին բեռնվածությունը կարգավորել եմ այն բանով, որ ոչ միայն 50 գործակալների եմ օգտագործել (ավելացրեցի ևս), այլ նաև դինամիկ տվյալների տարրերի միջոցով և իջեցվեց թարմացման ինտերվալը մինչև 4 վայրկյան:
Ձեռնարկային թեստ: PostgreSQL: 36 հազար NVP-ներ
Առաջին գործարկումը, առաջին setup ինձ մոտ եղել է մաքուր PostgreSQL 10-ի վրա այս սարքավորումներում (35 հազար արժեքներ վայրկյանի): Ընդհանուր առմամբ, ինչպես տեսանյութում երևում է, տվյալների տեղադրումը անցկացվում է հատվածների վայրկյանում՝ բոլորն էլ լավ և արագ, SSD-դիսկեր (200 ԳԲ): Միայն 20 ԳԲ-ը շատ արագ լցվում է:
Գոյություն կունենա շատ նման գրաֆիկներ: Դա «Զաբբիքս»-սերվերի ստանդարտ աշխատանքային վահանակն է:
Առաջին գրաֆիկը՝ հարաբերական արժեքների քանակը վայրկյանին (կապույտ, վերևում ձախ), 35 հազար արժեքներ այս դեպքում: Սա (վերևում կենտրոնում) պրոցեսների բեռնվածությունն է, և սա (վերևի աջը)՝ ներքին պրոցեսների բեռնվածությունը՝ history syncers և housekeeper, որը այստեղ (վերևում կենտրոնում) իրականացվեց բավական երկար ժամանակ:
Այս գրաֆիկը (վերևի կենտրոնում) ցույց է տալիս ValueCache-ի օգտագործումը՝ որքան հիթեր են ValueCache-ի համար թրիգերների ( մի քանի հազար արժեքներ վայրկյանին): Չափազանց կարևոր է՝ չորրորդ գրաֆիկը (վերևի ձախ), որը ցույց է տալիս HistoryCache-ի օգտագործումը, որը ես պատմեցի, որը բուֆեր է տեղադրման առաջ:
Ձեռնարկային թեստ: PostgreSQL: 50 հազար NVP-ներ
Այժմ ես ավելացրել եմ բեռնվածությունը մինչև 50 հազար արժեքի վայրկյանի վրա նույն սարքավորումներում։ Housekeeper-ի բեռնվածությունը՝ 10 հազար արժեքներ գրանցվել են արդեն 2-3 վայրկյանում հաշվարկմամբ: Ինչը, ըստ էության, ցույց է տրված հաջորդ սկրինշոթում։
«Хаוסкипер» արդեն սկսում է խանգարել աշխատանքին, սակայն ընդհանուր առմամբ հիստորի-սինքերի բեռնվածությունը դեռ գտնվում է 60% մակարդակում (երրորդ աղյուսակ, վերևի աջում): HistoryCache-ը արդեն «Хаускипера» աշխատելու ընթացքում սկսել է ակտիվորեն լցվել (ներքևում ձախում): Այն մոտավորապես կես գիգաբայթ էր, լցվել էր 20%-ով:
Կիրառողական թեստ: PostgreSQL: 80 հազար NVPs
Հաջորդը բարձրացրի մինչև 80 հազար արժեքներ մեկ վայրկյանում:
Այսպիսով, դա մոտ 400 հազար տվյալների էլեմենտ էր, 280 հազար խթանիչ: Գրառումը, ինչպես տեսնում եք, հիստորի-սինքերի բեռնվածությամբ (նրանց թիվը 30 էր) արդեն բավականին բարձր էր: Հաջորդաբար ես բարձրացրի տարբեր պարամետրեր՝ հիստորի-սինքեր, caches … Այս սարքում հիստորի-սինքերի բեռնվածությունը սկսեց բարձրանալ առավելագույնի, գրեթե «պոլկում»՝ համապատասխանորեն, HistoryCache-ը անցավ շատ բարձր բեռնվածություն:
Այս ողջ ընթացքում ես հետևում էի համակարգի բոլոր պարամետրերին (ինչպես է օգտագործվում պրոցեսորը, օպերատիվ հիշողությունը) և պարզեցի, որ զինակիցների օգտագործումը առավելագույնն էր՝ ես հասա այս սկանդալային համակարգի այս արագությանը: «Postgres» այս ինտենսիվության վրա սկսեց տվյալները բավականին ակտիվ նետել, և սկանդալը այլևս չկարողանում էր գրել, կարդալ …
Ես վերցրեցի մեկ այլ սերվեր, որն արդեն ուներ 48 պրոցեսոր 128 գիգաբայթ օպերատիվ հիշողությամբ:
Այնուհետև ես այն «զտեցի»՝ տեղադրեցի History syncer (60 հատ) և հասա ընդունելի արդյունավետության: Ի՞նչ պիտի ասեմ, մենք դեռ չենք «պոլկում», բայց սա արդեն, հավանաբար, աշխատանքի սահմանը է, որտեղ արդեն անհրաժեշտ է ինչ-որ բան հրապարակել:
Կիրառողական թեստ: TimescaleDB: 80 հազար NVPs
Որպեսզի TimescaleDB օգտագործելու գլխավոր խնդիր ունեի: Յուրաքանչյուր գրքում է տեսանելի կորստը:
Այս կորստները հենց տվյալների միգրացիայի հետևանք են: Այդուհետև «Zabbix» սերվերում հիստորի-սինքերի բեռնվածության պրոֆիլը, ինչպես տեսնում եք, շատ զգալի կերպով փոխվեց: Այն գրեթե 3 անգամ ավելի արագ թույլ է տալիս տվյալներ գրանցել և ավելի քիչ HistoryCache օգտագործել՝ հետևաբար, տվյալները ժամանակին կմատակարարվեն ձեզ: Հատուկ, 80 հազար արժեք մեկ վայրկյանում՝ դա բավականին բարձր տեմպ է (խիստ չէ «Յանդեքս»-ի համար): Ընդհանուր առմամբ, սա բավականին մեծ սարքավորում է, մեկ սերվերով:
Կիրառողական թեստ PostgreSQL: 120 հազար NVPs
Հաջորդում ես բարձրացրի տվյալների էլեմենտների քանակը չափազանց կես միլիոնի և ստացա հաշվարկված արժեք 125 հազար մեկ վայրկյանում:
Եվ ստացա այսպիսի աղյուսակներ:
Փաստորեն, սա աշխատող սարքավորում է, այն կարող է բավական երկար ժամանակ աշխատել: Բայց քանի որ ես ունեի սկանդալ միայն 1.5 տերաբայթ, ապա դրա օգտագործումը մի քանի օրում սպառվեց: Իրականում ամեն դեպքում նոր բաժիններ ստեղծվեցին TimescaleDB-ում, և դա կատարողականության համար անցավ աննկատ, ինչը չի կարող ասել MySQL-ի մասին:
Обычно партиции создаются ночью, так как это блокирует вставку и работу с таблицами, что может приводить к деградации сервиса. В данном случае этого нет! Главная задача заключалась в проверке возможностей TimescaleDB. Получилось 120 тысяч значений в секунду.
Также есть примеры в «комньюнити»:
Человек также включил TimescaleDB, и использование io.weight на процессоре снизилось; снижение загрузки внутренних процессов также наблюдается благодаря активации TimescaleDB. При этом используются обычные дисковые накопители, то есть стандартная виртуальная машина на обычных дисках (не SSD)!
Для небольших установок, ограниченных производительностью диска, TimescaleDB, на мой взгляд, является отличным решением. Оно позволит продолжать работу до тех пор, пока не будет произведена миграция на более мощное оборудование для базы данных.
Приглашаю вас на наши мероприятия: Conference – в Москве, Summit – в Риге. Используйте наши каналы – «Телеграм», форум, IRC. Если у вас есть вопросы – приходите к нам на стойку, будем рады обсудить все.
Вопросы аудитории
Вопрос из аудитории (далее – А): – Если настройка TimescaleDB так проста и она предлагает такой прирост производительности, возможно, следует использовать её как лучшую практику для настройки «Заббикса» с «Постгресом»? Есть ли какие-то подводные камни или недостатки в этом решении, или, если я решил установить «Заббикс», я могу просто взять «Постгрес», установить туда «Таймскейл», пользоваться и не беспокоиться о других проблемах?
АГ: – Да, я бы сказал, что это хорошая рекомендация: использовать «Постгрес» сразу с расширением TimescaleDB. Как я уже говорил, много положительных отзывов, несмотря на то что эта «фича» экспериментальная. Но тесты показывают, что это отличное решение (с TimescaleDB), и я думаю, что оно будет развиваться! Мы следим за развитием этого расширения и будем исправлять все недостатки.
Мы даже во время разработки опирались на одну их известную «фичу»: можно было немного по-другому работать с чанками. Но в следующем релизе они убрали это, и нам пришлось отказаться от данного кода. Я бы рекомендовал использовать это решение на многих установках. Если вы используете MySQL… Для средних установок любое решение неплохо работает.
А: – На последних графиках от сообщества был график с «Хаускипером»:
Что «Хаускипер» делает с TimescaleDB?
АГ: – Сейчас не могу точно сказать – посмотрю код и дам более подробный ответ. Он использует запросы именно TimescaleDB не для удаления чанков, а для какой-то агрегации. Пока не готов ответить на этот технический вопрос. Сегодня или завтра уточним на стенде.
А: – Ես տվեցի համանման հարց – «Թայմսկեյլ» մաքրման գործողության արդյունավետության մասին:
Ա (պատասխան լսարանում): – Երբ դու ջնջում ես տվյալները աղյուսակից, եթե դու դա անում ես delete-ով, ապա դու պետք է անցնես աղյուսակով՝ ջնջելու, մաքրելու, բոլոր բաները նշել ապագա վակուումի համար: «Թայմսկեյլ»-ում, քանի որ դու ունես չանքեր, կարող ես արագ անցկացնել: грубо говоря, դու պարզապես ասում ես ֆայլին, որը գտնվում է մեծ տվյալներում՝ «Ջնջել»:
«Թայմսկեյլ»-ը պարզապես հասկանում է, որ նման չանք այլևս չկա: Եվ քանի որ այն ինտեգրվում է հարցման պլանավորիչի մեջ, այն բռնում է քո պայմանները select-ում կամ այլ գործողություններում և անմիջապես հասկանում, որ այդ չանքը այլևս չկա – «Ես այնտեղ այլևս չեմ գնա!» (տվյալները բացակայում են): Вот и всё! То есть скан таблицы заменяется на удаление бинарного файла, поэтому это быстро.
А: – Վերջապես խոսվեց ոչ SQL թեմայի մասին: Ինչպես գիտեմ, «Զաբբիքս»-ին հատկապես պետք չէ տվյալները փոփոխել, իսկ ամեն ինչը միSort log-ի մոտ է: Կարելի՞ է օգտագործել հատուկ տվյալների բազաներ, որոնք չեն կարող փոխել իրենց տվյալները, բայց ավելի արագ են պահում, կուտակում, տալիս – օրինակ Clickhouse, կամ որ-нибудь кафка-образное?.. Kafka – это же тоже лог! Можно ли их как-то интегрировать?
АГ: – Нужно выгрузку сделать: у нас есть определённая «фича» с версии 3.4: вы можете писать в файлы все исторические файлы, события, все прочее; и дальше каким-то обработчиком отсылать в любую другую БД. На самом деле много кто переделывает и пишет напрямую в БД. На лету хистори-синкеры всё это пишут в файлы, ротируют эти файлы и так далее, и это вы можете перекидывать в «Кликхаус». Не могу сказать о планах, но, возможно, дальнейшая поддержка NoSQL-решений (таких, как «Кликхаус») будет продолжаться.
А: – Вообще, получается, можно полностью избавиться от постгреса?
АГ: – Конечно, самая сложная часть в «Заббиксе» – это исторические таблицы, которые создают больше всего проблем, и события. В этом случае, если вы не будете долго хранить события и будете хранить историю с трендами в каком-то другом быстром хранилище, то в целом никаких проблем, думаю, не будет.
А: – Можете оценить, насколько быстрее всё будет работать, если перейти на «Кликхаус», допустим?
АГ: – Я не тестировал. Думаю, что как минимум тех же цифр можно будет достичь достаточно просто, учитывая, что «Кликхаус» имеет свой интерфейс, но не могу сказать однозначно. Лучше протестировать. Всё зависит от конфигурации: сколько у вас хостов и так далее. Вставка – это одно, но нужно ещё забирать эти данные – Grafana или ещё чем-то.
А: – То есть речь идёт о равной борьбе, а не о большом преимуществе этих быстрых БД?
АГ: – Думаю, когда интегрируем, будут более точные тесты.
А: – Որտե՞ղ է գոնե լավ ու թանկ RRD-ը։ Ինչու՞ են տեղափոխվել SQL տվյալների բազաներ։ Առաջին հերթին RRD-ում էին հավաքվում բոլոր մետրիկաները։
АГ: – «Zabbix»-ում RRD, հնարավոր է, շատ հին տարբերակում եղել է։ Always SQL databases եղել են ՝ դասական մոտեցում։ Դասական մոտեցումը MySQL-ն է, PostgreSQL-ն (շատ վաղուց արդեն գոյություն ունեն)։ Մենք ընդհանուր ինտերֆեյս ունենք SQL տվյալների բազաների համար, իսկ RRD-ը մենք գրեթե երբեք չենք օգտագործել։
Մի փոքր գովազդ 🙂
Շնորհակալություն, որ մնում եք մեզ հետ։ Ձեզ դուր են գալիս մեր հոդվածները։ Ուզում եք տեսնել ավելի հետաքրքիր նյութեր։ Օգնեք մեզ` պատվեր ձևակերպելով կամ ծանոթներին խորհուրդ տալով։ , յուրաքանչյուր այլընտրանք, որը մենք առաջարկել ենք ձեզ՝ (և RAID1, RAID10 տարբերակներ հասանելի են, մինչև 24 միջուկներ և մինչև 40GB DDR4):
Dell R730xd-ը կրկնակի անգամ էժան է Equinix Tier IV տվյալային կենտրոնում Ամստերդամում։ Մ seuls է մեզ մոտ նավահանգստի Նիդերլանդներում! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — սկսվում է $99-ից! Կարդացեք այն մասին
Ընտանիք: habr.com
