Vaqt qatorlari bazasi nima: TimescaleDB, InfluxDB va boshqalar
Asoslar4 daqInnovialabs tahririyati
Qisqacha
Vaqt qatorlari bazasi asosan qo‘shib boriladigan, vaqt oraliqlari bo‘yicha so‘raladigan va vaqt o‘tib eskiradigan vaqt belgili o‘lchovlar uchun optimallashtirilgan; PostgreSQL’dan boshlang, hajm, saqlash muddati yoki agregatlar muammoga aylanganda TimescaleDB, InfluxDB, ClickHouse yoki Prometheus’ga o‘ting.
Qisqa javob
Vaqt qatorlari bazasi (TSDB) vaqtga bog‘langan o‘lchovlarni saqlaydi: sensor ko‘rsatkichlari, serverlarning CPU yuklamasi, valyuta kurslari, daqiqadagi buyurtmalar soni. Bunday ma’lumotlar oldindan aytish mumkin bo‘lgan shaklga ega va TSDB’lar aynan shunga moslab qurilgan: yangi nuqtalarni tez yozish, vaqt oraliqlari bo‘yicha tez so‘rovlar, eski ma’lumotlarni avtomatik o‘chirish va oldindan hisoblangan agregatlar.
Birinchi kundanoq u kerak emas. Yaxshi indekslangan PostgreSQL jadvali ko‘p narsaga bardosh beradi. TSDB ma’lumotlar doimiy o‘sib borsa, xom nuqtalarni cheklangan muddat saqlash kerak bo‘lsa va dashbordlarga daqiqa, soat va kun bo‘yicha agregatlar kerak bo‘lsa, o‘zini oqlaydi.
Vaqt qatorlari nimasi bilan alohida
- Faqat qo‘shib borish. Yangi nuqtalar doimiy keladi, eskilari deyarli o‘zgarmaydi.
- Vaqt bo‘yicha so‘rovlar. Deyarli har bir so‘rov — «shu qurilma yoki metrika uchun, shu davrda, interval bo‘yicha guruhlab».
- Saqlash muddati (retention). Xom ma’lumotlar vaqt o‘tishi bilan qadrini yo‘qotadi. Soniyali ko‘rsatkichlarni yillab saqlash qimmat va ko‘pincha foydasiz.
- Siyraklashtirish (downsampling). Eski ma’lumotlar agregat ko‘rinishida saqlanadi: har bir nuqta o‘rniga daqiqa yoki soat bo‘yicha o‘rtacha, minimum va maksimum.
- Yuqori kardinallik xavfi. Belgilarning (qurilma, hudud, mijoz) har bir unikal kombinatsiyasi alohida qator yaratadi. Kombinatsiyalar juda ko‘p bo‘lsa, ko‘pchilik TSDB’lar sekinlashadi.
Qachon oddiy PostgreSQL jadvali yetarli
Qurilmalar yoki metrikalar soni o‘rtacha, so‘rovlar oddiy bo‘lsa, shundan boshlang:
CREATE TABLE readings (
device_id integer NOT NULL,
ts timestamptz NOT NULL,
temperature numeric(5,2),
PRIMARY KEY (device_id, ts)
);
-- vaqt tartibida yoziladigan ma’lumotlar uchun ixcham BRIN indeks oraliq bo‘yicha tanlovni tezlashtiradi
CREATE INDEX readings_ts_brin ON readings USING brin (ts);
Jadval kattalashganda vaqt bo‘yicha deklarativ bo‘limlash (partitioning) qo‘shing (masalan, oylar bo‘yicha): eski bo‘limni o‘chirish katta DELETE’dan ancha arzon. Bu sxemadan o‘sib chiqqaningiz belgilari: bo‘limlarni boshqarish qo‘l mehnatiga aylanadi, agregat so‘rovlar sekinlashadi, saqlash hajmi byudjetdan tezroq o‘sadi.
Asosiy variantlar
TimescaleDB
PostgreSQL kengaytmasi. Jadvallar avtomatik ravishda vaqt bo‘laklariga (chunk) ajratiladigan gipertabllarga aylanadi. Siqish, saqlash siyosatlari va uzluksiz agregatlar (bosqichma-bosqich yangilanadigan materiallashtirilgan jamlanmalar) qo‘shiladi. To‘liq SQL, oddiy biznes jadvallari bilan JOIN va tanish PostgreSQL vositalari saqlanib qoladi. Ayrim funksiyalar vendorning o‘z litsenziyasi ostida tarqatiladi — o‘z xosting variantingiz uchun shartlarni tekshiring.
InfluxDB
O‘z ma’lumot modeliga ega maxsus TSDB: measurements, tags (indekslanadigan belgilar) va fields (qiymatlar). Yozish oddiy, saqlash muddati ichiga o‘rnatilgan, yig‘uvchilarning katta ekotizimi bor, avvalo Telegraf. So‘rovlar tili asosiy versiyalar orasida o‘zgargan, shuning uchun unga tayanib tizim qurishdan oldin versiyangizda qaysi til ekanini aniqlang.
ClickHouse
Ustunli analitik MBBT — rasman TSDB emas, lekin katta hajmdagi hodisalar va metrikalarda juda kuchli. Vaqt bo‘yicha bo‘limlash, o‘chirish uchun TTL qoidalari va agregatlar uchun materiallashtirilgan ko‘rinishlar vaqt qatorlarining odatiy vazifalarini qoplaydi. Milliardlab qatorlarni a’lo darajada skanerlaydi va agregatlaydi; tez-tez yangilash va alohida qatorlarni o‘chirish uning kuchli tomoni emas.
Prometheus
Ichki TSDB’ga ega monitoring tizimi. Metrikalarni servislardan o‘zi oladi, mahalliy saqlaydi va PromQL’dagi so‘rovlarga javob beradi; alerting ekotizimning bir qismi. Mahalliy ombor operativ saqlash muddatiga mo‘ljallangan, uzoq muddatli saqlash odatda remote-write bekendlariga chiqariladi. Uning o‘z hujjatlari har bir hodisa bo‘yicha mutlaqo aniq ma’lumot kerak bo‘lgan joyda, masalan billingda, undan foydalanishni tavsiya qilmaydi.
Vazifaga qarab qanday tanlash kerak
| Vazifa | Mos keladi | Nega |
|---|---|---|
| Biznes ma’lumotlari bilan birga IoT sensorlar (qurilmalar, mijozlar, shartnomalar) | TimescaleDB | JOIN, agregatlar va saqlash bitta bazada |
| Oddiy yozish va dashbordli IoT yoki metrikalar | InfluxDB | Oddiy yozish modeli, tayyor yig‘uvchilar |
| Server va ilovalar monitoringi, alertlar | Prometheus | Pull-model, PromQL, alertlar ekotizimi |
| Katta hodisalar va kliklar oqimi analitikasi | ClickHouse | Ulkan hajmlarda tez agregatsiya |
| Fintech metrikalari: kurslar, bitimlar tarixi, balans suratlari | TimescaleDB yoki ClickHouse | Aniq sonli turlar, SQL, tekshiriluvchanlik |
Pullarni aniq o‘nlik turlarda saqlang, operatsiyalarning asosiy reyestrini esa tranzaksion bazada yuriting; TSDB’da — analitik nusxa.
Ko‘p uchraydigan xatolar
- Belgilarda foydalanuvchi yoki so‘rov ID’lari — kardinallik portlashi.
- Saqlash va siyraklashtirish rejasisiz xom ma’lumotlarni abadiy saqlash.
- Aslida PostgreSQL’da bitta qo‘shimcha indeks kerak bo‘lgan joyda alohida TSDB.
- Prometheus metrikalariga aniq biznes yozuvlari sifatida qarash.