InfluxDB ilə işləyərkən qəzəb, sövdələşmə və depressiya

Əgər zaman seriyası verilənlər bazasından istifadə edirsinizsə (timeseries db, wiki) statistikası olan bir sayt üçün əsas saxlama yeri olaraq, problemi həll etmək əvəzinə çox baş ağrıları ala bilərsiniz. Belə bir verilənlər bazasından istifadə edən bir layihə üzərində işləyirəm və bəzən müzakirə olunacaq InfluxDB ümumiyyətlə gözlənilməz sürprizlər təqdim etdi.

Məsuliyyətdən imtinaQeyd: Göstərilən məsələlər InfluxDB 1.7.4 üçündir.

Niyə zaman seriyası?

Layihə müxtəlif blokçeynlərdə əməliyyatları izləmək və statistikanı göstərməkdir. Konkret olaraq, biz sabit sikkələrin emissiyasına və yandırılmasına baxırıq (wiki). Bu əməliyyatlara əsaslanaraq, qrafiklər qurmalı və pivot cədvəlləri göstərməlisiniz.

Əməliyyatları təhlil edərkən bir fikir ortaya çıxdı: InfluxDB vaxt seriyası verilənlər bazasını əsas yaddaş kimi istifadə etmək. Əməliyyatlar zaman nöqtələridir və onlar zaman seriyası modelinə yaxşı uyğun gəlir.

Aqreqasiya funksiyaları da çox rahat görünürdü - onlar uzun müddətə diaqramların işlənməsi üçün idealdır. İstifadəçiyə bir il ərzində diaqram lazımdır və verilənlər bazasında beş dəqiqəlik vaxt çərçivəsi olan məlumat dəsti var. Bütün yüz min balları ona göndərmək mənasızdır - uzun bir emal istisna olmaqla, onlar ekrana sığmayacaqlar. Siz vaxt çərçivəsini artırmaq üçün öz tətbiqinizi yaza və ya Influx-a daxil edilmiş toplama funksiyalarından istifadə edə bilərsiniz. Onların köməyi ilə siz məlumatları günlər üzrə qruplaşdıra və istədiyiniz 365 xal göndərə bilərsiniz.

Bu cür verilənlər bazalarının adətən ölçüləri toplamaq üçün istifadə edilməsi bir az utancverici idi. Serverlərin, IOT cihazlarının, “axın” formasında milyonlarla nöqtənin olduğu hər şeyin monitorinqi: [<zaman> - <metrik dəyər>]. Bəs verilənlər bazası böyük məlumat axını ilə yaxşı işləyirsə, niyə kiçik həcm problem yaratmalıdır? Bu düşüncə ilə InfluxDB-ni işə götürdülər.

InfluxDB-də başqa nə rahatdır

Qeyd olunan aqreqasiya funksiyalarına əlavə olaraq başqa bir gözəl şey var - davamlı sorğular (doc). Bu, verilənlər bazasına daxil edilmiş, cədvəl üzrə məlumatları emal edə bilən planlaşdırıcıdır. Məsələn, hər 24 saatdan bir gün üçün bütün qeydləri qruplaşdıra, ortalama hesablaya və öz velosipedinizi yazmadan bir yeni nöqtəni başqa bir cədvələ yaza bilərsiniz.

da var saxlama siyasəti (doc) - müəyyən müddətdən sonra məlumatların silinməsi üçün parametr. Məsələn, CPU-da yükü saniyədə bir dəfə ölçmə ilə bir həftə saxlamaq lazım olduqda faydalıdır, lakin bir neçə ay məsafədə belə dəqiqliyə ehtiyac yoxdur. Belə bir vəziyyətdə bunu edə bilərsiniz:

1. məlumatları başqa bir cədvələ toplamaq üçün davamlı sorğu yaratmaq;
2. birinci cədvəl üçün həmin həftədən köhnə olan metriklərin silinməsi üçün siyasət təyin edin.

Influx isə məlumatların ölçüsünü azaldacaq və lazımsız məlumatları öz-özünə siləcək.

Saxlanılan məlumatlar haqqında

Çox məlumat saxlanılmır: təxminən 70 min əməliyyat və bazar məlumatları ilə daha bir milyon nöqtə. Yeni girişlərin əlavə edilməsi - gündə 3000 baldan çox deyil. Sayt üçün ölçülər də var, lakin orada məlumat azdır və saxlama siyasətinə görə onlar bir aydan çox olmayaraq saxlanılır.

Problemləri

Xidmətin inkişafı və sonrakı sınaqları zamanı InfluxDB-nin işində getdikcə daha çox kritik problemlər yarandı.

1. Məlumatların silinməsi

Əməliyyatlarla bağlı bir sıra məlumatlar var:

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

Nəticə:

Məlumatları silmək üçün əmr göndərirəm:

DELETE FROM transactions WHERE symbol=’USDT’

Bundan əlavə, artıq silinmiş məlumatların əldə edilməsini xahiş edirəm. Və Influx, boş cavab əvəzinə, silinməli olan bir məlumat parçasını qaytarır.

Bütün cədvəli silməyə çalışıram:

DROP MEASUREMENT transactions

Cədvəlin silinməsini yoxlayıram:

SHOW MEASUREMENTS

Siyahıda cədvəli görmürəm, lakin yeni məlumat sorğusu yenə də eyni əməliyyatlar dəstini qaytarır.

Problem mənim üçün yalnız bir dəfə yarandı, çünki silinmə işi təcrid olunmuş bir haldır. Lakin verilənlər bazasının bu davranışı açıq şəkildə "düzgün" iş çərçivəsinə uyğun gəlmir. Daha sonra github açıq tapıldı bilet bu mövzuda demək olar ki, bir ildir.

Nəticədə, bütün verilənlər bazasının çıxarılması və sonradan bərpası kömək etdi.

2. Üzən nöqtəli ədədlər

InfluxDB-nin daxili funksiyalarından istifadə edən riyazi hesablamalar dəqiq səhvlər verir. Deyil ki, bu, qeyri-adi, lakin xoşagəlməz bir şey idi.

Mənim vəziyyətimdə məlumatların maliyyə komponenti var və mən onu yüksək dəqiqliklə emal etmək istərdim. Bu səbəbdən biz davamlı sorğulardan imtina etməyi planlaşdırırıq.

3. Davamlı sorğular müxtəlif vaxt zonalarına uyğunlaşdırıla bilməz

Xidmətdə gündəlik əməliyyat statistikası olan cədvəl var. Hər gün üçün həmin gün üçün bütün əməliyyatları qruplaşdırmalısınız. Ancaq hər bir istifadəçi üçün gün fərqli bir zamanda başlayacaq, buna görə də əməliyyatlar dəsti fərqlidir. UTC 37 variant məlumatı toplamaq istədiyiniz növbələr.

InfluxDB-də, vaxta görə qruplaşdırarkən, əlavə olaraq, məsələn, Moskva vaxtı (UTC + 3) üçün bir növbə təyin edə bilərsiniz:

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

Ancaq sorğunun nəticəsi səhv olacaq. Nədənsə, günə görə qruplaşdırılmış məlumatlar 1677-ci ildə başlayacaq (InfluxDB rəsmi olaraq bu ildən bir zaman aralığını dəstəkləyir):

Bu problemi aradan qaldırmaq üçün xidmət müvəqqəti olaraq UTC + 0-a köçürüldü.

4. Performans

İnternetdə InfluxDB və digər verilənlər bazalarının müqayisəsi ilə çoxlu meyarlar var. İlk baxışdan marketinq materiallarına oxşayırdılar, amma indi fikirləşirəm ki, onlarda bir həqiqət var.

İcazə verin sizə öz vəziyyətimi deyim.

Xidmət son XNUMX saat ərzində statistikanı qaytaran API metodu təqdim edir. Hesablamalar zamanı metod verilənlər bazasını üç dəfə aşağıdakı sorğularla sorğulayır:

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

Şərhlər:

1. İlk sorğuda bazar məlumatları ilə hər bir sikkə üçün ən son xalları alırıq. Mənim vəziyyətimdə səkkiz sikkə üçün səkkiz nöqtə.
2. İkinci sorğu ən yeni nöqtəni alır.
3. Üçüncüsü son XNUMX saat ərzində əməliyyatların siyahısını tələb edir, onlardan bir neçə yüz ola bilər.

Aydınlaşdırım ki, InfluxDB-də indeks avtomatik olaraq teqlər və zamanla qurulur, bu da sorğuları sürətləndirir. İlk müraciətdə simvolu etiketdir.

Bu API metodu üçün stress testi etdim. 25 RPS üçün server altı CPU-nun tam yükünü göstərdi:

Eyni zamanda, NodeJs prosesi ümumiyyətlə heç bir yük vermədi.

İcra sürəti artıq 7-10 RPS azalıb: əgər bir müştəri 200 ms-də cavab ala bilsəydi, 10 müştəri bir saniyə gözləməli oldu. 25 RPS - sabitliyin pozulduğu sərhəd, 500 səhv müştərilərə qaytarıldı.

Bu cür performansla layihəmizdə Influx-dan istifadə etmək mümkün deyil. Üstəlik, monitorinqin bir çox müştəriyə nümayiş etdirilməli olduğu layihədə oxşar problemlər yarana bilər və ölçülər serveri həddən artıq yüklənəcək.

Buraxılış

Qazanılan təcrübədən əldə edilən ən mühüm nəticə ondan ibarətdir ki, kifayət qədər analiz olmadan naməlum texnologiyanı layihəyə daxil edə bilməzsiniz. Github-da açıq biletlərin sadə bir yoxlanışı InfluxDB-ni əsas məlumat anbarı kimi qəbul etməmək üçün məlumat verə bilər.

InfluxDB layihəmin tapşırıqlarına yaxşı uyğunlaşmalı idi, lakin təcrübə göstərdiyi kimi, bu verilənlər bazası ehtiyaclara cavab vermir və çox qarışıqdır.

Layihə deposunda 2.0.0-beta versiyasını artıq tapa bilərsiniz, ikinci versiyada əhəmiyyətli təkmilləşdirmələrin olacağına ümid etmək qalır. Bu vaxt mən TimescaleDB sənədlərini öyrənməyə gedəcəm.

Mənbə: www.habr.com