Vaqt seriyasi ma'lumotlar bazasidan foydalansangiz (vaqt seriyasi db, ) statistik ma'lumotlarga ega sayt uchun asosiy saqlash joyi sifatida, keyin muammoni hal qilish o'rniga siz juda ko'p bosh og'rig'iga duch kelishingiz mumkin. Men bunday ma'lumotlar bazasidan foydalanadigan loyiha ustida ishlayapman va ba'zida muhokama qilinadigan InfluxDB butunlay kutilmagan kutilmagan hodisalarni taqdim etdi.
Masʼuliyatdan voz kechish: Roʻyxatdagi muammolar InfluxDB 1.7.4 versiyasiga tegishli.
Nima uchun vaqt seriyasi?
Loyiha turli blokcheynlardagi tranzaktsiyalarni kuzatish va statistikani ko'rsatishdan iborat. Xususan, biz barqaror tangalarning emissiyasi va yonishini ko'rib chiqamiz (). Ushbu tranzaktsiyalar asosida siz grafiklarni qurishingiz va xulosa jadvallarini ko'rsatishingiz kerak.
Tranzaktsiyalarni tahlil qilishda g'oya paydo bo'ldi: InfluxDB vaqt seriyasi ma'lumotlar bazasidan asosiy xotira sifatida foydalanish. Tranzaktsiyalar vaqt nuqtalari va ular vaqt seriyasi modeliga yaxshi mos keladi.
Birlashtirish funktsiyalari ham juda qulay ko'rinardi - uzoq vaqt davomida grafiklarni qayta ishlash uchun ideal. Foydalanuvchiga bir yil davomida grafik kerak va ma'lumotlar bazasida besh daqiqalik vaqt oralig'i bo'lgan ma'lumotlar to'plami mavjud. Unga yuz ming nuqtani yuborish befoyda - uzoq ishlov berishdan tashqari, ular hatto ekranga ham sig'maydi. Vaqtni oshirish bo'yicha o'zingizning dasturingizni yozishingiz yoki Influx-ga o'rnatilgan yig'ish funktsiyalaridan foydalanishingiz mumkin. Ularning yordami bilan siz ma'lumotlarni kun bo'yicha guruhlashingiz va kerakli 365 ballni yuborishingiz mumkin.
Bunday ma'lumotlar bazalari odatda ko'rsatkichlarni yig'ish uchun ishlatilishi biroz chalkash edi. "Oqim" shaklidagi millionlab nuqtalar bo'lgan serverlar, iot qurilmalari monitoringi: [<vaqt> - <metrik qiymat>]. Ammo agar ma'lumotlar bazasi katta ma'lumotlar oqimi bilan yaxshi ishlayotgan bo'lsa, unda nima uchun kichik hajm muammolarga olib kelishi kerak? Buni hisobga olib, biz InfluxDB ni ishga oldik.
InfluxDB-da yana nima qulay
Yuqorida aytib o'tilgan agregatsiya funktsiyalaridan tashqari, yana bir ajoyib narsa bor - doimiy so'rovlar (). Bu jadval bo'yicha ma'lumotlarni qayta ishlay oladigan ma'lumotlar bazasiga o'rnatilgan rejalashtiruvchi. Misol uchun, har 24 soatda siz o'zingizning velosipedlaringizni yozmasdan, kun uchun barcha yozuvlarni guruhlashingiz, o'rtacha qiymatni hisoblashingiz va boshqa jadvalga bitta yangi nuqta yozishingiz mumkin.
Bundan tashqari, mavjud saqlash siyosati ()—maʼlum vaqtdan keyin maʼlumotlarni oʻchirishni sozlash. Masalan, protsessor yukini soniyada bir marta o'lchovlar bilan bir hafta davomida saqlashingiz kerak bo'lganda foydali bo'ladi, lekin bir necha oylik masofada bunday aniqlik kerak emas. Bunday vaziyatda siz buni qilishingiz mumkin:
- ma'lumotlarni boshqa jadvalga jamlash uchun uzluksiz so'rov yaratish;
- birinchi jadval uchun o'sha haftadan eski ko'rsatkichlarni o'chirish siyosatini belgilang.
Va Influx mustaqil ravishda ma'lumotlar hajmini kamaytiradi va keraksiz narsalarni o'chiradi.
Saqlangan ma'lumotlar haqida
Ko'p ma'lumotlar saqlanmaydi: taxminan 70 ming tranzaktsiyalar va bozor ma'lumotlari bilan yana bir million nuqta. Yangi yozuvlarni qo'shish - kuniga 3000 balldan oshmasligi kerak. Sayt uchun ko'rsatkichlar ham mavjud, ammo u erda ma'lumotlar kam va saqlash siyosatiga ko'ra, ular bir oydan ko'p bo'lmagan muddatda saqlanadi.
Muammolar
Xizmatni ishlab chiqish va undan keyingi sinovdan o'tkazish jarayonida InfluxDB ishlashida tobora ko'proq jiddiy muammolar paydo bo'ldi.
1. Ma'lumotlarni o'chirish
Tranzaktsiyalar bilan bir qator ma'lumotlar mavjud:
SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'natija:
Men ma'lumotlarni o'chirish uchun buyruq yuboraman:
DELETE FROM transactions WHERE symbol=’USDT’Keyin men allaqachon o'chirilgan ma'lumotlarni olish uchun so'rov yuboraman. Va bo'sh javob o'rniga, Influx o'chirilishi kerak bo'lgan ma'lumotlarning bir qismini qaytaradi.
Men butun jadvalni o'chirishga harakat qilaman:
DROP MEASUREMENT transactionsJadvalni o'chirishni tekshiraman:
SHOW MEASUREMENTSRo'yxatdagi jadvalni ko'rmayapman, lekin yangi ma'lumotlar so'rovi hali ham bir xil tranzaktsiyalar to'plamini qaytaradi.
Muammo menda faqat bir marta paydo bo'ldi, chunki o'chirish ishi alohida holat edi. Ammo ma'lumotlar bazasining bunday xatti-harakati "to'g'ri" operatsiya doirasiga to'g'ri kelmaydi. Keyinchalik men uni githubda ochiq deb topdim deyarli bir yil oldin bu mavzuda.
Natijada, butun ma'lumotlar bazasini o'chirish va keyin qayta tiklash yordam berdi.
2. Suzuvchi nuqtali sonlar
InfluxDB-da o'rnatilgan funktsiyalardan foydalanganda matematik hisob-kitoblarda aniqlik xatolari mavjud. Bu g'ayrioddiy narsa emas, lekin bu yoqimsiz.
Mening vaziyatimda ma'lumotlar moliyaviy komponentga ega va men uni yuqori aniqlik bilan qayta ishlashni xohlayman. Shu sababli, biz doimiy so'rovlardan voz kechishni rejalashtirmoqdamiz.
3. Uzluksiz so‘rovlarni turli vaqt zonalariga moslab bo‘lmaydi
Xizmatda kunlik tranzaktsiyalar statistikasi mavjud jadval mavjud. Har bir kun uchun siz o'sha kun uchun barcha operatsiyalarni guruhlashingiz kerak. Ammo har bir foydalanuvchining kuni boshqa vaqtda boshlanadi va shuning uchun tranzaktsiyalar to'plami boshqacha bo'ladi. UTC tomonidan ha ma'lumotlarni jamlashingiz kerak bo'lgan siljishlar.
InfluxDB-da vaqt bo'yicha guruhlashda siz qo'shimcha ravishda siljishni belgilashingiz mumkin, masalan, Moskva vaqti (UTC+3):
SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)Ammo so'rov natijasi noto'g'ri bo'ladi. Ba'zi sabablarga ko'ra, kun bo'yicha guruhlangan ma'lumotlar 1677 yilgacha boshlanadi (InfluxDB bu yildan boshlab rasman vaqt oralig'ini qo'llab-quvvatlaydi):
Ushbu muammoni hal qilish uchun biz xizmatni vaqtincha UTC+0 ga almashtirdik.
4. Ishlash
Internetda InfluxDB va boshqa ma'lumotlar bazalarini taqqoslaydigan ko'plab ko'rsatkichlar mavjud. Bir qarashda ular marketing materiallariga o'xshardi, ammo hozir menimcha, ularda qandaydir haqiqat bor.
Men sizga o'z ishimni aytib beraman.
Xizmat oxirgi kun statistikasini qaytaradigan API usulini taqdim etadi. Hisob-kitoblarni amalga oshirishda usul ma'lumotlar bazasini quyidagi so'rovlar bilan uch marta so'raydi:
SELECT * FROM coins_info WHERE time <= NOW() GROUP BY symbol ORDER BY time DESC LIMIT 1SELECT * FROM dominance_info ORDER BY time DESC LIMIT 1SELECT * FROM transactions WHERE time >= NOW() - 24h ORDER BY time DESCIzoh:
- Birinchi so'rovda biz bozor ma'lumotlari bilan har bir tanga uchun oxirgi ball olamiz. Mening ishimda sakkiz tanga uchun sakkiz ball.
- Ikkinchi so'rov eng yangi nuqtalardan birini oladi.
- Uchinchisi so'nggi XNUMX soat ichida tranzaktsiyalar ro'yxatini so'raydi; ularning bir necha yuztasi bo'lishi mumkin.
Aniqlik kiritamanki, InfluxDB avtomatik ravishda teglar va vaqtga asoslangan indeks yaratadi, bu esa so'rovlarni tezlashtiradi. Birinchi so'rovda Belgisi teg hisoblanadi.
Ushbu API usulida stress testini o'tkazdim. 25 RPS uchun server oltita protsessorning to'liq yukini namoyish etdi:
Shu bilan birga, NodeJs jarayoni umuman yuklamadi.
Amalga oshirish tezligi allaqachon 7-10 RPS ga pasaygan: agar bitta mijoz 200 ms ichida javob olsa, 10 mijoz bir soniya kutishga majbur bo'ldi. 25 RPS - barqarorlik buzilgan chegara; 500 ta xato mijozlarga qaytarildi.
Bunday ishlash bilan bizning loyihamizda Influx-dan foydalanish mumkin emas. Bundan tashqari: ko'plab mijozlarga monitoringni ko'rsatish kerak bo'lgan loyihada shunga o'xshash muammolar paydo bo'lishi mumkin va ko'rsatkichlar serveri haddan tashqari yuklanadi.
xulosa
Olingan tajribadan eng muhim xulosa shuki, noma'lum texnologiyani yetarlicha tahlil qilmasdan loyihaga kiritish mumkin emas. Github-da ochiq muammolarni oddiy skrining qilish InfluxDB-ni asosiy ma'lumotlar ombori sifatida tanlamaslik uchun ma'lumot berishi mumkin.
InfluxDB mening loyihamning vazifalari uchun juda mos bo'lishi kerak edi, ammo amaliyot shuni ko'rsatadiki, bu ma'lumotlar bazasi ehtiyojlarga javob bermaydi va juda ko'p xatolarga ega.
Siz allaqachon loyiha omborida 2.0.0-beta versiyasini topishingiz mumkin; biz faqat ikkinchi versiyada sezilarli yaxshilanishlarga ega bo'lishiga umid qilishimiz mumkin. Bu orada men TimescaleDB hujjatlarini o'rganaman.
Manba: www.habr.com