Asosiy kontentga o‘tish
Innovialabs

Vaqt qatorlari bazasi nima: TimescaleDB, InfluxDB va boshqalar

Asoslar4 daq

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

VazifaMos keladiNega
Biznes ma’lumotlari bilan birga IoT sensorlar (qurilmalar, mijozlar, shartnomalar)TimescaleDBJOIN, agregatlar va saqlash bitta bazada
Oddiy yozish va dashbordli IoT yoki metrikalarInfluxDBOddiy yozish modeli, tayyor yig‘uvchilar
Server va ilovalar monitoringi, alertlarPrometheusPull-model, PromQL, alertlar ekotizimi
Katta hodisalar va kliklar oqimi analitikasiClickHouseUlkan hajmlarda tez agregatsiya
Fintech metrikalari: kurslar, bitimlar tarixi, balans suratlariTimescaleDB yoki ClickHouseAniq 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.

Ko‘p beriladigan savollar

Yo‘q, to‘ldiradi. Foydalanuvchilar, buyurtmalar va to‘lovlar tranzaksion bazada qoladi, o‘lchovlar va metrikalar TSDB’ga ketadi.

Bunda yordam beramiz

O‘zingiz shug‘ullanmasdan natija olishni istasangiz — biz har kuni shu bilan shug‘ullanamiz.

Loyihani muhokama qilish

Yana o‘qing

G‘oya yoki vazifangiz bormi? Bizga aytib bering

Ish kuni davomida javob beramiz va yechim taklif qilamiz. Konsultatsiya bepul.