Վերջին մի քանի տարիների ընթացքում ժամանակային շարքերի տվյալների բազաները տարօրինակ բանից (խիստ մասնագիտացված, որն օգտագործվում է կամ բաց մոնիտորինգի համակարգերում (և կապված կոնկրետ լուծումների հետ) կամ Big Data նախագծերում) վերածվել են «սպառողական արտադրանքի»: Ռուսաստանի Դաշնության տարածքում դրա համար պետք է հատուկ շնորհակալություն հայտնել Yandex-ին և ClickHouse-ին: Մինչ այս պահը, եթե ձեզ հարկավոր էր մեծ քանակությամբ ժամանակային շարքի տվյալներ պահել, դուք կամ պետք է հաշտվեիք հրեշավոր Hadoop ստեկը ստեղծելու և այն պահպանելու անհրաժեշտության հետ, կամ շփվեք յուրաքանչյուր համակարգի համար առանձին արձանագրությունների հետ:
Կարող է թվալ, որ 2019 թվականին հոդվածը, որի մասին արժե օգտագործել TSDB-ն, բաղկացած կլինի միայն մեկ նախադասությունից՝ «պարզապես օգտագործիր ClickHouse»-ը։ Բայց... կան նրբերանգներ.
Իսկապես, ClickHouse-ն ակտիվորեն զարգանում է, օգտատերերի բազան աճում է, և աջակցությունը շատ ակտիվ է, բայց արդյոք մենք դարձել ենք ClickHouse-ի հանրային հաջողության պատանդը, որը ստվերել է այլ, գուցե ավելի արդյունավետ/հուսալի լուծումներ:
Անցյալ տարվա սկզբին մենք սկսեցինք վերամշակել սեփական մոնիտորինգի համակարգը, որի ընթացքում ծագեց տվյալների պահպանման համար համապատասխան բազա ընտրելու հարցը։ Այստեղ ես ուզում եմ խոսել այս ընտրության պատմության մասին։
Խնդրի ձևակերպում
Նախ անհրաժեշտ նախաբան. Ինչո՞ւ է մեզ ընդհանրապես անհրաժեշտ մեր մոնիտորինգի համակարգը և ինչպե՞ս է այն նախագծվել:
Մենք սկսեցինք աջակցության ծառայություններ մատուցել 2008 թվականին, և մինչև 2010 թվականը պարզ դարձավ, որ դժվարացավ հավաքել տվյալներ հաճախորդի ենթակառուցվածքում տեղի ունեցող գործընթացների վերաբերյալ այն լուծումներով, որոնք առկա էին այն ժամանակ (խոսքը, Աստված ների ինձ, Cacti, Zabbix): և առաջացող գրաֆիտը):
Մեր հիմնական պահանջներն էին.
- աջակցություն (այդ ժամանակ՝ տասնյակ, իսկ ապագայում՝ հարյուրավոր) հաճախորդների մեկ համակարգի ներսում և միևնույն ժամանակ ահազանգերի կառավարման կենտրոնացված համակարգի առկայություն.
- ահազանգման համակարգի կառավարման ճկունություն (հերթապահների միջև ահազանգերի ընդլայնում, ժամանակացույց, գիտելիքների բազա);
- գրաֆիկները խորապես մանրամասնելու ունակություն (այդ ժամանակ Zabbix-ը գրաֆիկները ներկայացնում էր նկարների տեսքով);
- մեծ քանակությամբ տվյալների երկարաժամկետ պահպանում (մեկ տարի կամ ավելի) և դրանք արագ առբերելու հնարավորություն:
Այս հոդվածում մեզ հետաքրքրում է վերջին կետը.
Խոսելով պահեստավորման մասին՝ պահանջները հետևյալն էին.
- համակարգը պետք է արագ աշխատի;
- Ցանկալի է, որ համակարգը ունենա SQL ինտերֆեյս;
- համակարգը պետք է կայուն լինի և ունենա օգտատերերի ակտիվ բազա և աջակցություն (մի անգամ մենք բախվեցինք այնպիսի համակարգերին աջակցելու անհրաժեշտությանը, ինչպիսիք են MemcacheDB-ն, որն այլևս մշակված չէր, կամ MooseFS-ի բաշխված պահեստը, որի սխալների որոնիչը պահվում էր չինարենով. մենք կրկնում ենք այս պատմությունը մեր նախագծի համար, որը չէր ուզում);
- Համապատասխանություն CAP թեորեմին. Համապատասխանություն (պահանջվում է) - տվյալները պետք է լինեն արդիական, մենք չենք ցանկանում, որ ահազանգերի կառավարման համակարգը չստանա նոր տվյալներ և չթքի բոլոր նախագծերի համար տվյալների չժամանի մասին ահազանգերը. Partition Tolerance (պարտադիր) - մենք չենք ցանկանում ստանալ Split Brain համակարգ; Հասանելիություն (կրիտիկական չէ, եթե կա ակտիվ կրկնօրինակ) - մենք կարող ենք ինքներս անցնել պահեստային համակարգին վթարի դեպքում՝ օգտագործելով ծածկագիրը:
Տարօրինակ կերպով, այն ժամանակ MySQL-ը մեզ համար իդեալական լուծում էր: Մեր տվյալների կառուցվածքը չափազանց պարզ էր. սերվերի id, հաշվիչի id, ժամանակի դրոշմակնիք և արժեք; Թեժ տվյալների արագ նմուշառումն ապահովվել է մեծ բուֆերային լողավազանի միջոցով, իսկ պատմական տվյալների նմուշառումն ապահովվել է SSD-ով:
Այսպիսով, մենք ստացանք թարմ երկշաբաթյա տվյալների նմուշ՝ մանրամասնությամբ մինչև 200 ms մինչև տվյալների ամբողջական մատուցումը, և բավականին երկար ժամանակ ապրեցինք այս համակարգում:
Մինչդեռ ժամանակն անցնում էր, և տվյալների քանակը մեծանում էր։ Մինչև 2016 թվականը տվյալների ծավալը հասել է տասնյակ տերաբայթերի, ինչը զգալի ծախս էր վարձակալված SSD պահեստավորման համատեքստում:
Այս պահին սյունակային տվյալների բազաները ակտիվորեն լայն տարածում էին գտել, ինչի մասին մենք սկսեցինք ակտիվորեն մտածել. կրկնօրինակների քանակը, որոնք կարող են, եթե դուք օգտագործում եք սյունակային տվյալների բազա, սեղմեք այն սեղմման միջոցով:
Այնուամենայնիվ, ընկերության հիմնական համակարգը շարունակեց կայուն աշխատել, և ես չէի ուզում փորձարկել այլ բանի անցնելու համար:
2017 թվականին Սան Խոսեում Percona Live կոնֆերանսում Clickhouse-ի մշակողները հավանաբար առաջին անգամ հայտարարեցին իրենց մասին։ Առաջին հայացքից համակարգը պատրաստ էր արտադրության համար (դե, Yandex.Metrica-ն կոշտ արտադրական համակարգ է), աջակցությունը արագ և պարզ էր, և, որ ամենակարևորը, գործարկումը պարզ էր: 2018 թվականից մենք սկսել ենք անցումային գործընթացը։ Բայց այդ ժամանակ կային շատ «մեծահասակների» և ժամանակի փորձարկված TSDB համակարգեր, և մենք որոշեցինք զգալի ժամանակ հատկացնել և համեմատել այլընտրանքները՝ համոզվելու համար, որ մեր պահանջներին համապատասխան Քլիքհաուսի այլընտրանքային լուծումներ չկան:
Ի լրումն արդեն իսկ սահմանված պահեստավորման պահանջների, հայտնվել են նորերը.
- նոր համակարգը պետք է ապահովի առնվազն նույն արդյունավետությունը, ինչ MySQL-ը նույն քանակությամբ սարքաշարի վրա.
- նոր համակարգի պահեստավորումը պետք է զգալիորեն ավելի քիչ տարածք զբաղեցնի.
- DBMS-ը դեռ պետք է հեշտ կառավարվի.
- Ես ուզում էի մինիմալ կերպով փոխել հավելվածը DBMS-ը փոխելիս:
Ի՞նչ համակարգեր ենք սկսել դիտարկել:
Apache Փեթակ / Apache Impala
Հին, մարտում փորձարկված Hadoop ստեկ: Ըստ էության, դա SQL ինտերֆեյս է, որը կառուցված է HDFS-ում տվյալների բնիկ ձևաչափերով պահելու վրա:
Ընդունեք:
- Կայուն շահագործման դեպքում շատ հեշտ է չափել տվյալները:
- Կան սյունակային լուծումներ տվյալների պահպանման համար (ավելի քիչ տարածք):
- Զուգահեռ առաջադրանքների շատ արագ կատարում, երբ առկա են ռեսուրսներ:
Դեմ
- Դա Hadoop-ն է, և դժվար է օգտագործել: Եթե մենք պատրաստ չենք ամպի մեջ պատրաստի լուծում ընդունելու (և պատրաստ չենք ծախսերի առումով), ապա ամբողջ փաթեթը պետք է հավաքվի և աջակցվի ադմինների ձեռքերով, և մենք իսկապես չենք ուզում. սա.
- Տվյալները համախմբված են .
Այնուամենայնիվ.
Արագությունը ձեռք է բերվում հաշվողական սերվերների քանակի մասշտաբով: Պարզ ասած, եթե մենք խոշոր ընկերություն ենք, զբաղված ենք վերլուծություններով, և բիզնեսի համար կարևոր է հնարավորինս արագ տեղեկատվություն հավաքել (նույնիսկ մեծ քանակությամբ հաշվողական ռեսուրսների օգտագործման գնով), դա կարող է լինել մեր ընտրությունը: Բայց մենք պատրաստ չէինք բազմապատկել ապարատային նավատորմը՝ առաջադրանքները արագացնելու համար:
Դրյուիդ/Պինոտ
Հատկապես TSDB-ի մասին շատ ավելին կա, բայց նորից՝ Hadoop ստեկը:
Կա .
Մի քանի խոսքով. Druid/Pinot-ն ավելի լավ տեսք ունի, քան Clickhouse-ը այն դեպքերում, երբ.
- Դուք ունեք տվյալների տարասեռ բնույթ (մեր դեպքում մենք գրանցում ենք սերվերի չափումների միայն ժամանակային շարքեր, և, ըստ էության, սա մեկ աղյուսակ է: Բայց կարող են լինել նաև այլ դեպքեր՝ սարքավորումների ժամանակային շարքեր, տնտեսական ժամանակային շարքեր և այլն. իր սեփական կառուցվածքը, որը պետք է համախմբվի և վերամշակվի):
- Ավելին, այս տվյալները շատ են։
- Ժամանակային շարքերով աղյուսակները և տվյալները հայտնվում և անհետանում են (այսինքն, տվյալների մի շարք ժամանել, վերլուծվել և ջնջվել է):
- Չկա հստակ չափանիշ, որով կարելի է բաժանել տվյալները:
Հակառակ դեպքերում, ClickHouse-ն ավելի լավ է գործում, և սա մեր դեպքն է:
clickhouse
- SQL-ի նման
- Հեշտ է կառավարել:
- Մարդիկ ասում են, որ դա աշխատում է:
Ստացվում է թեստավորման կարճ ցուցակում:
Ներխուժում
ClickHouse-ի օտարերկրյա այլընտրանք: Մինուսներից. Բարձր հասանելիությունը առկա է միայն կոմերցիոն տարբերակում, բայց այն պետք է համեմատել:
Ստացվում է թեստավորման կարճ ցուցակում:
Cassandra
Մի կողմից, մենք գիտենք, որ այն օգտագործվում է մոնիտորինգի այնպիսի համակարգերով, ինչպիսիք են, օրինակ. կամ OkMeter. Այնուամենայնիվ, կան առանձնահատկություններ.
Cassandra-ն ավանդական իմաստով սյունակային տվյալների բազա չէ: Այն ավելի շատ նման է տողերի տեսքին, բայց յուրաքանչյուր տող կարող է ունենալ տարբեր թվով սյունակներ, ինչը հեշտացնում է սյունակային տեսքը կազմակերպելը: Այս առումով պարզ է, որ 2 միլիարդ սյունակների սահմանաչափի դեպքում հնարավոր է որոշ տվյալներ պահպանել սյունակներում (և նույն ժամանակային շարքերը): Օրինակ, MySQL-ում կա 4096 սյունակի սահմանափակում, և հեշտ է պատահել 1117 կոդով սխալի վրա, եթե փորձես անել նույնը:
Cassandra շարժիչը կենտրոնացած է մեծ քանակությամբ տվյալների պահպանման վրա բաշխված համակարգում առանց վարպետի, իսկ վերոհիշյալ Cassandra CAP թեորեմն ավելի շատ վերաբերում է AP-ին, այսինքն՝ տվյալների առկայությանը և բաժանման դիմադրությանը: Այսպիսով, այս գործիքը կարող է հիանալի լինել, եթե ձեզ միայն անհրաժեշտ է գրել այս տվյալների բազայում և հազվադեպ կարդալ դրանից: Եվ այստեղ տրամաբանական է օգտագործել Cassandra-ն որպես «սառը» պահեստ։ Այսինքն՝ որպես երկարաժամկետ, հուսալի վայր՝ մեծ քանակությամբ պատմական տվյալների պահպանման համար, որոնք հազվադեպ են անհրաժեշտ, բայց անհրաժեշտության դեպքում կարող են առբերվել: Այնուամենայնիվ, ամբողջականության համար մենք դա նույնպես կփորձարկենք։ Բայց, ինչպես ես ավելի վաղ ասացի, ցանկություն չկա ակտիվորեն վերաշարադրել կոդը ընտրված տվյալների բազայի լուծման համար, այնպես որ մենք այն կփորձարկենք մի փոքր սահմանափակ՝ առանց տվյալների բազայի կառուցվածքը հարմարեցնելու Կասանդրայի առանձնահատկություններին:
Պրոմեթեւս
Դե, հետաքրքրությունից դրդված, մենք որոշեցինք ստուգել Պրոմեթևսի պահեստավորման աշխատանքը՝ պարզապես հասկանալու համար՝ մենք ավելի արագ ենք, թե դանդաղ, քան ներկայիս լուծումները և որքանով:
Փորձարկման մեթոդաբանություն և արդյունքներ
Այսպիսով, մենք փորձարկեցինք 5 տվյալների բազա հետևյալ 6 կոնֆիգուրացիաներում՝ ClickHouse (1 հանգույց), ClickHouse (բաշխված աղյուսակ 3 հանգույցների համար), InfluxDB, Mysql 8, Cassandra (3 հանգույց) և Prometheus: Փորձարկման պլանը հետևյալն է.
- վերբեռնեք պատմական տվյալներ մեկ շաբաթվա համար (օրական 840 միլիոն արժեք; 208 հազար չափումներ);
- մենք ստեղծում ենք ձայնագրման բեռ (դիտարկվել է բեռնման 6 ռեժիմ, տես ստորև);
- Ձայնագրմանը զուգահեռ մենք պարբերաբար ընտրություն ենք կատարում՝ ընդօրինակելով գծապատկերներով աշխատող օգտատիրոջ խնդրանքը։ Որպեսզի ամեն ինչ շատ չբարդացնենք, մենք ընտրեցինք տվյալներ 10 չափումների համար (այդքանն է պրոցեսորի գրաֆիկի վրա) մեկ շաբաթվա համար։
Մենք բեռնում ենք՝ ընդօրինակելով մեր մոնիտորինգի գործակալի վարքագիծը, որը յուրաքանչյուր 15 վայրկյանը մեկ արժեքներ է ուղարկում յուրաքանչյուր չափման: Միևնույն ժամանակ, մեզ հետաքրքրում է տարբեր լինել.
- չափումների ընդհանուր թիվը, որոնց մեջ գրված են տվյալները.
- մեկ մետրային արժեքներ ուղարկելու ընդմիջում;
- խմբաքանակի չափը.
Խմբաքանակի չափի մասին. Քանի որ խորհուրդ չի տրվում մեր գրեթե բոլոր փորձարարական տվյալների բազաները բեռնել առանձին ներդիրներով, մեզ անհրաժեշտ կլինի ռելե, որը հավաքում է մուտքային չափումները և դրանք խմբերի կխմբավորում և տվյալների բազայում գրում որպես խմբաքանակի ներդիր:
Նաև, ավելի լավ հասկանալու համար, թե ինչպես կարելի է այնուհետև մեկնաբանել ստացված տվյալները, եկեք պատկերացնենք, որ մենք ոչ միայն ուղարկում ենք մի շարք չափումներ, այլ չափումները կազմակերպվում են սերվերների մեջ՝ 125 չափումներ մեկ սերվերի համար: Այստեղ սերվերը պարզապես վիրտուալ սուբյեկտ է, պարզապես հասկանալու համար, որ, օրինակ, 10000 չափումներ համապատասխանում են մոտ 80 սերվերի:
Եվ ահա, այս ամենը հաշվի առնելով, մեր տվյալների բազայի 6 գրելու բեռնման ռեժիմներն են.
Այստեղ երկու կետ կա. Նախ, Կասանդրայի համար այս խմբաքանակի չափերը չափազանց մեծ էին, այնտեղ մենք օգտագործեցինք 50 կամ 100 արժեքներ: Եվ երկրորդ, քանի որ Պրոմեթևսը աշխատում է խստորեն ձգման ռեժիմում, այսինքն. այն ինքնին գնում և հավաքում է տվյալներ չափման աղբյուրներից (և նույնիսկ pushgateway-ը, չնայած անվանը, հիմնովին չի փոխում իրավիճակը), համապատասխան բեռներն իրականացվել են ստատիկ կազմաձևերի համակցության միջոցով:
Թեստի արդյունքները հետևյալն են.
Ինչն արժե ուշադրություն դարձնելՖանտաստիկ արագ նմուշներ Պրոմեթևսից, ահավոր դանդաղ նմուշներ Կասանդրայից, անընդունելի դանդաղ նմուշներ InfluxDB-ից; Ձայնագրման արագության առումով ClickHouse-ը հաղթեց բոլորին, իսկ Պրոմեթևսը չի մասնակցում մրցույթին, քանի որ ինքն է ներդիրներ պատրաստում, և մենք ոչինչ չենք չափում։
Որպես հետեւանք,ClickHouse-ը և InfluxDB-ն իրենց լավագույնն են դրսևորել, բայց Influx-ի կլաստերը կարող է ստեղծվել միայն Enterprise տարբերակի հիման վրա, որն արժե գումար, մինչդեռ ClickHouse-ը ոչինչ արժե և արտադրված է Ռուսաստանում: Տրամաբանական է, որ ԱՄՆ-ում ընտրությունը հավանաբար հօգուտ inInfluxDB-ի է, իսկ մեզ մոտ՝ ClickHouse-ի։
Source: www.habr.com