Զայրույթ, սակարկություն և դեպրեսիա InfluxDB-ի հետ աշխատելիս

Եթե ​​դուք օգտագործում եք ժամանակային շարքերի տվյալների բազա (ժամանակային շարք db, Վիքիփեդիա, ազատ հանրագիտարան) որպես վիճակագրություն ունեցող կայքի հիմնական պահեստ, ապա խնդիրը լուծելու փոխարեն կարող եք շատ գլխացավեր ունենալ։ Ես աշխատում եմ մի նախագծի վրա, որն օգտագործում է նման տվյալների բազա, և երբեմն InfluxDB-ն, որը կքննարկվի, ներկայացնում էր բոլորովին անսպասելի անակնկալներ։

Հրաժարում պատասխանատվությունիցԹվարկված խնդիրները վերաբերում են InfluxDB 1.7.4 տարբերակին:

Ինչու՞ ժամանակային շարքեր:

Նախագիծն ուղղված է տարբեր բլոկչեյններով գործարքներին հետևելուն և վիճակագրության ցուցադրմանը: Մասնավորապես, մենք նայում ենք կայուն մետաղադրամների արտանետմանը և այրմանը (Վիքիփեդիա, ազատ հանրագիտարան) Այս գործարքների հիման վրա դուք պետք է կառուցեք գրաֆիկներ և ցուցադրեք ամփոփ աղյուսակներ:

Գործարքները վերլուծելիս միտք ծագեց՝ օգտագործել InfluxDB ժամանակային շարքերի տվյալների բազան որպես հիմնական պահեստ: Գործարքները ժամանակի կետեր են և դրանք լավ տեղավորվում են ժամանակային շարքերի մոդելի մեջ:

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

Մի փոքր շփոթեցնող էր, որ նման տվյալների բազաները սովորաբար օգտագործվում են չափումների հավաքագրման նպատակով: Սերվերների, iot սարքերի մոնիտորինգ, այն ամենը, ինչից «հոսում են» ձևի միլիոնավոր կետեր՝ [<ժամանակ> - <մետրային արժեք>]: Բայց եթե տվյալների բազան լավ է աշխատում տվյալների մեծ հոսքի դեպքում, ապա ինչո՞ւ պետք է փոքր ծավալը խնդիրներ առաջացնի: Սա նկատի ունենալով, մենք գործի դրեցինք InfluxDB-ն:

Էլ ինչ է հարմար InfluxDB-ում

Բացի նշված ագրեգացիոն գործառույթներից, կա ևս մեկ հիանալի բան. շարունակական հարցումներ (բժիշկ) Սա տվյալների բազայում ներկառուցված ժամանակացույց է, որը կարող է մշակել տվյալները ժամանակացույցով: Օրինակ, յուրաքանչյուր 24 ժամը մեկ դուք կարող եք խմբավորել օրվա բոլոր գրառումները, հաշվարկել միջինը և մեկ նոր միավոր գրանցել մեկ այլ աղյուսակում՝ առանց ձեր սեփական հեծանիվները գրելու:

կա նաեւ պահպանման քաղաքականություն (բժիշկ) - որոշակի ժամանակահատվածից հետո տվյալների ջնջման կարգավորում: Օգտակար է, երբ, օրինակ, պետք է մեկ շաբաթ պահել պրոցեսորի ծանրաբեռնվածությունը վայրկյանում մեկ անգամ չափումներով, բայց մի քանի ամսվա ընթացքում նման ճշգրտություն պետք չէ։ Նման իրավիճակում դուք կարող եք անել հետևյալը.

1. ստեղծել շարունակական հարցում՝ տվյալները մեկ այլ աղյուսակում համախմբելու համար.
2. առաջին աղյուսակի համար սահմանեք նույն շաբաթից ավելի հին չափորոշիչների ջնջման քաղաքականություն:

Իսկ Influx-ը ինքնուրույն կնվազեցնի տվյալների չափը և կջնջի ավելորդ բաները։

Պահված տվյալների մասին

Շատ տվյալներ չեն պահվում՝ մոտ 70 հազար գործարք և ևս միլիոն միավոր շուկայական տեղեկություններով։ Նոր գրառումների ավելացում` օրական 3000 միավորից ոչ ավելի: Կայքի համար կան նաև չափումներ, սակայն այնտեղ քիչ տվյալներ կան և, ըստ պահպանման քաղաքականության, դրանք պահվում են ոչ ավելի, քան մեկ ամիս։

Problems

Ծառայության մշակման և հետագա փորձարկման ընթացքում ավելի ու ավելի շատ կարևոր խնդիրներ առաջացան InfluxDB-ի շահագործման մեջ:

1. Տվյալների ջնջում

Գործարքների հետ կապված տվյալների մի շարք կա.

SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'

Արդյունքը:

Տվյալները ջնջելու հրաման եմ ուղարկում.

DELETE FROM transactions WHERE symbol=’USDT’

Հաջորդը ես խնդրում եմ ստանալ արդեն ջնջված տվյալները։ Եվ դատարկ պատասխանի փոխարեն Influx-ը վերադարձնում է տվյալների մի մասը, որը պետք է ջնջվի:

Ես փորձում եմ ջնջել ամբողջ աղյուսակը.

DROP MEASUREMENT transactions

Ես ստուգում եմ աղյուսակի ջնջումը.

SHOW MEASUREMENTS

Ցանկում աղյուսակը չեմ տեսնում, բայց տվյալների նոր հարցումը դեռ վերադարձնում է գործարքների նույն փաթեթը:

Խնդիրն ինձ մոտ միայն մեկ անգամ է առաջացել, քանի որ ջնջման դեպքը մեկուսացված դեպք էր։ Բայց տվյալների բազայի այս պահվածքն ակնհայտորեն չի տեղավորվում «ճիշտ» գործողության շրջանակում։ Ավելի ուշ ես գտա այն բաց github-ում տոմս գրեթե մեկ տարի առաջ այս թեմայով:

Արդյունքում օգնեց ամբողջ տվյալների բազայի ջնջումը, ապա վերականգնելը:

2. Լողացող կետով թվեր

InfluxDB-ում ներկառուցված գործառույթներն օգտագործելիս մաթեմատիկական հաշվարկները ճշգրտության սխալներ ունեն: Ոչ թե սա ինչ-որ արտասովոր բան է, բայց տհաճ է:

Իմ դեպքում տվյալներն ունեն ֆինանսական բաղադրիչ, և ես կցանկանայի դրանք մշակել բարձր ճշգրտությամբ։ Այս պատճառով մենք նախատեսում ենք հրաժարվել շարունակական հարցումներից:

3. Շարունակական հարցումները չեն կարող հարմարվել տարբեր ժամային գոտիների

Ծառայությունն ունի աղյուսակ՝ ամենօրյա գործարքների վիճակագրությամբ: Յուրաքանչյուր օրվա համար դուք պետք է խմբավորեք այդ օրվա բոլոր գործարքները: Բայց յուրաքանչյուր օգտատիրոջ օրը կսկսվի տարբեր ժամանակ, և, հետևաբար, գործարքների շարքը տարբեր կլինի: UTC-ով այո 37 տարբերակ տեղաշարժեր, որոնց համար անհրաժեշտ է տվյալների համախմբում:

InfluxDB-ում, ըստ ժամանակի խմբավորման, կարող եք լրացուցիչ նշել տեղաշարժ, օրինակ՝ Մոսկվայի ժամանակով (UTC+3).

SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)

Բայց հարցման արդյունքը սխալ կլինի: Ինչ-ինչ պատճառներով, ըստ օրվա խմբավորված տվյալները կսկսվեն մինչև 1677 թվականը (InfluxDB-ն պաշտոնապես աջակցում է այս տարվանից սկսած ժամանակային միջակայքը).

Այս խնդիրը լուծելու համար մենք ծառայությունը ժամանակավորապես փոխեցինք UTC+0-ի:

4. Կատարում

Ինտերնետում կան բազմաթիվ հենանիշեր, որոնք համեմատում են InfluxDB-ն և այլ տվյալների բազաները: Առաջին հայացքից դրանք նման էին մարքեթինգային նյութերի, բայց հիմա կարծում եմ, որ դրանցում որոշակի ճշմարտություն կա:

Ես կպատմեմ իմ գործը:

Ծառայությունը տրամադրում է API մեթոդ, որը վերադարձնում է վիճակագրությունը վերջին օրվա համար: Հաշվարկներ կատարելիս մեթոդը երեք անգամ հարցնում է տվյալների բազան հետևյալ հարցումներով.

SELECT * FROM coins_info WHERE time <= NOW() GROUP BY symbol ORDER BY time DESC LIMIT 1

SELECT * FROM dominance_info ORDER BY time DESC LIMIT 1

SELECT * FROM transactions WHERE time >= NOW() - 24h ORDER BY time DESC

Բացատրություն

1. Առաջին հարցումով մենք ստանում ենք շուկայական տվյալներով յուրաքանչյուր մետաղադրամի վերջին միավորները: Ութ միավոր ութ մետաղադրամի համար իմ դեպքում:
2. Երկրորդ հարցումը ստանում է նորագույն միավորներից մեկը:
3. Երրորդը պահանջում է վերջին XNUMX ժամվա գործարքների ցուցակը, դրանք կարող են լինել մի քանի հարյուր:

Թույլ տվեք պարզաբանել, որ InfluxDB-ն ավտոմատ կերպով կառուցում է ինդեքս՝ հիմնվելով թեգերի և ժամանակի վրա, ինչը արագացնում է հարցումները։ Առաջին խնդրանքով սիմվոլ պիտակ է:

Ես սթրես-թեստ եմ անցկացրել այս API մեթոդի վրա: 25 RPS-ի համար սերվերը ցուցադրեց վեց պրոցեսորների ամբողջական բեռնվածություն.

Միևնույն ժամանակ, NodeJs գործընթացն ընդհանրապես որևէ բեռ չի ապահովել։

Կատարման արագությունն արդեն նվազել է 7-10 RPS-ով. եթե մեկ հաճախորդը կարող էր պատասխան ստանալ 200 ms-ում, ապա 10 հաճախորդ պետք է սպասեր մեկ վայրկյան: 25 RPS-ն այն սահմանն է, որով տուժել է կայունությունը, հաճախորդներին է վերադարձվել 500 սխալ:

Նման կատարմամբ անհնար է Influx-ը օգտագործել մեր նախագծում։ Ավելին. մի նախագծում, որտեղ մոնիտորինգը պետք է ցուցադրվի շատ հաճախորդների, կարող են հայտնվել նմանատիպ խնդիրներ և չափումների սերվերը ծանրաբեռնված կլինի:

Արտադրողականություն

Ձեռք բերված փորձից ամենակարևոր եզրակացությունն այն է, որ առանց բավարար վերլուծության չես կարող անհայտ տեխնոլոգիա ընդգրկել նախագծի մեջ: Github-ում բաց խնդիրների պարզ ստուգումը կարող է տեղեկատվություն տրամադրել՝ խուսափելու համար InfluxDB-ն որպես տվյալների հիմնական պահեստ ընտրելուց:

InfluxDB-ն պետք է լավ հարմարվեր իմ նախագծի առաջադրանքների համար, բայց ինչպես ցույց է տվել պրակտիկան, այս տվյալների բազան չի բավարարում կարիքները և ունի բազմաթիվ սխալներ:

Ծրագրի շտեմարանում արդեն կարող եք գտնել 2.0.0-բետա տարբերակը, մնում է միայն հուսալ, որ երկրորդ տարբերակը զգալի բարելավումներ կունենա: Միևնույն ժամանակ, ես կգնամ ուսումնասիրելու TimescaleDB փաստաթղթերը:

Source: www.habr.com