გაბრაზება, ვაჭრობა და დეპრესია InfluxDB-თან მუშაობისას

თუ იყენებთ დროის სერიების მონაცემთა ბაზას (timeseries db, ვიკი) როგორც სტატისტიკის მქონე საიტის მთავარი საცავი, მაშინ პრობლემის გადაჭრის ნაცვლად შეიძლება ბევრი თავის ტკივილი მოგიტანოთ. მე ვმუშაობ პროექტზე, რომელიც იყენებს ასეთ მონაცემთა ბაზას და ზოგჯერ InfluxDB, რომელზეც განხილული იქნება, სრულიად მოულოდნელი სიურპრიზები წარმოადგინა.

პასუხისმგებლობის შეზღუდვის განაცხადი: ჩამოთვლილი საკითხები ეხება InfluxDB 1.7.4 ვერსიას.

რატომ დროის სერია?

პროექტი მიზნად ისახავს ტრანზაქციების თვალყურის დევნებას სხვადასხვა ბლოკჩეინზე და სტატისტიკის ჩვენებას. კონკრეტულად, ჩვენ ვუყურებთ სტაბილური მონეტების ემისიას და წვას (ვიკი). ამ ტრანზაქციებზე დაყრდნობით, თქვენ უნდა ააწყოთ გრაფიკები და აჩვენოთ შემაჯამებელი ცხრილები.

ტრანზაქციების ანალიზის დროს გაჩნდა იდეა: გამოვიყენოთ InfluxDB დროის სერიების მონაცემთა ბაზა, როგორც ძირითადი საცავი. ტრანზაქციები არის დროის წერტილები და ისინი კარგად ჯდება დროის სერიების მოდელში.

აგრეგაციის ფუნქციები ასევე ძალიან მოსახერხებელი ჩანდა - იდეალურია ხანგრძლივი პერიოდის დიაგრამების დასამუშავებლად. მომხმარებელს სჭირდება დიაგრამა ერთი წლის განმავლობაში, ხოლო მონაცემთა ბაზა შეიცავს მონაცემთა ნაკრების დროის ჩარჩოს ხუთი წუთის განმავლობაში. უაზროა მისთვის ასი ათასი წერტილის გაგზავნა - ხანგრძლივი დამუშავების გარდა, ისინი ეკრანზეც კი არ ჯდება. თქვენ შეგიძლიათ დაწეროთ დროის გაზრდის საკუთარი განხორციელება, ან გამოიყენოთ Influx-ში ჩაშენებული აგრეგაციის ფუნქციები. მათი დახმარებით შეგიძლიათ მონაცემების დაჯგუფება დღის მიხედვით და გაგზავნოთ საჭირო 365 ქულა.

ცოტა დამაბნეველი იყო, რომ ასეთი მონაცემთა ბაზები ჩვეულებრივ გამოიყენება მეტრიკის შეგროვების მიზნით. სერვერების, iot მოწყობილობების, ყველაფრის მონიტორინგი, საიდანაც „მიედინება“ ფორმის მილიონობით წერტილი: [ - ]. მაგრამ თუ მონაცემთა ბაზა კარგად მუშაობს მონაცემთა დიდი ნაკადით, მაშინ რატომ უნდა გამოიწვიოს მცირე მოცულობამ პრობლემები? ამის გათვალისწინებით, ჩვენ ავიღეთ InfluxDB სამუშაოდ.

კიდევ რა არის მოსახერხებელი InfluxDB-ში

გარდა აღნიშნული აგრეგაციის ფუნქციებისა, არის კიდევ ერთი დიდი რამ - უწყვეტი შეკითხვები (doc). ეს არის მონაცემთა ბაზაში ჩაშენებული გრაფიკი, რომელსაც შეუძლია მონაცემების დამუშავება გრაფიკის მიხედვით. მაგალითად, ყოველ 24 საათში შეგიძლიათ დააჯგუფოთ დღის ყველა ჩანაწერი, გამოთვალოთ საშუალო და ჩაწეროთ ერთი ახალი ქულა სხვა ცხრილში საკუთარი ველოსიპედების დაწერის გარეშე.

არსებობს ასევე შენარჩუნების პოლიტიკა (doc) - მონაცემთა წაშლის დაყენება გარკვეული პერიოდის შემდეგ. ეს სასარგებლოა, როდესაც, მაგალითად, გჭირდებათ CPU დატვირთვის შენახვა ერთი კვირის განმავლობაში წამში ერთხელ გაზომვით, მაგრამ რამდენიმე თვის მანძილზე ასეთი სიზუსტე არ არის საჭირო. ასეთ სიტუაციაში შეგიძლიათ გააკეთოთ ეს:

1. შექმენით უწყვეტი მოთხოვნა მონაცემების სხვა ცხრილში გაერთიანებისთვის;
2. პირველი ცხრილისთვის განსაზღვრეთ პოლიტიკა იმავე კვირაზე ძველი მეტრიკის წაშლისთვის.

და Influx დამოუკიდებლად შეამცირებს მონაცემთა ზომას და წაშლის არასაჭირო ნივთებს.

შენახული მონაცემების შესახებ

ბევრი მონაცემი არ ინახება: დაახლოებით 70 ათასი ტრანზაქცია და კიდევ მილიონი ქულა ბაზრის ინფორმაციით. ახალი ჩანაწერების დამატება - არაუმეტეს 3000 ქულა დღეში. ასევე არის საიტის მეტრიკა, მაგრამ იქ მონაცემები ცოტაა და, შენახვის პოლიტიკის მიხედვით, ისინი ინახება არა უმეტეს ერთი თვის განმავლობაში.

პრობლემები

სერვისის შემუშავებისა და შემდგომი ტესტირების დროს უფრო და უფრო კრიტიკული პრობლემები წარმოიქმნა 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-ისთვის სერვერმა აჩვენა ექვსი CPU-ს სრული დატვირთვა:

ამავდროულად, NodeJs პროცესმა საერთოდ არ უზრუნველყო რაიმე დატვირთვა.

შესრულების სიჩქარე უკვე დაქვეითებულია 7-10 RPS-ით: თუ ერთ კლიენტს შეეძლო პასუხის მიღება 200 ms-ში, მაშინ 10 კლიენტს მოუწევდა ლოდინი წამში. 25 RPS არის ზღვარი, რომლის დროსაც სტაბილურობა განიცადა; 500 შეცდომა დაუბრუნდა კლიენტებს.

ასეთი შესრულებით შეუძლებელია Influx-ის გამოყენება ჩვენს პროექტში. უფრო მეტიც: პროექტში, სადაც მონიტორინგის დემონსტრირება სჭირდება ბევრ კლიენტს, შეიძლება აღმოჩნდეს მსგავსი პრობლემები და გადაიტვირთოს მეტრიკის სერვერი.

გამოყვანის

მიღებული გამოცდილებიდან ყველაზე მნიშვნელოვანი დასკვნა არის ის, რომ თქვენ ვერ შეძლებთ პროექტში უცნობი ტექნოლოგიების მიღებას საკმარისი ანალიზის გარეშე. github-ზე ღია საკითხების მარტივი სკრინინგმა შეიძლება მოგაწოდოთ ინფორმაცია, რათა თავიდან აიცილოთ InfluxDB, როგორც მონაცემთა ძირითადი მაღაზიის არჩევა.

InfluxDB კარგად უნდა მოერგო ჩემი პროექტის ამოცანებს, მაგრამ როგორც პრაქტიკამ აჩვენა, ეს მონაცემთა ბაზა არ აკმაყოფილებს საჭიროებებს და აქვს ბევრი ხარვეზი.

თქვენ უკვე შეგიძლიათ იპოვოთ ვერსია 2.0.0-beta პროექტის საცავში; ჩვენ მხოლოდ იმედი გვაქვს, რომ მეორე ვერსიას მნიშვნელოვანი გაუმჯობესება ექნება. ამასობაში მე წავალ TimescaleDB დოკუმენტაციის შესწავლას.

წყარო: www.habr.com