TimescaleDB: PostgreSQL laiko eilučių

Kas yra TimescaleDB ir kodėl tai svarbu

Jei kada nors teko dirbti su IoT įrenginių duomenimis, serverių metrikomis ar finansinėmis laiko eilutėmis, tikriausiai žinote, kaip greitai tokie duomenys gali užversti net ir galingą duomenų bazę. Tradicinės reliacinės duomenų bazės paprasčiausiai nebuvo sukurtos tokiam duomenų srautui apdoroti. Čia ir ateina į pagalbą TimescaleDB – PostgreSQL plėtinys, kuris paverčia jūsų mėgstamą duomenų bazę tikru laiko eilučių duomenų (time-series data) apdorojimo žvėrimi.

TimescaleDB nėra atskira duomenų bazė – tai PostgreSQL plėtinys, kuris prideda specialias galimybes laiko eilučių duomenims valdyti. Tai reiškia, kad galite naudoti visas PostgreSQL funkcijas, kurias jau pažįstate: SQL užklausas, indeksus, JSONB palaikymą, triggerius ir visa kita. Tik dabar jūsų duomenų bazė gali efektyviai apdoroti milijonus įrašų per sekundę ir saugoti terabaitus laiko eilučių duomenų.

Pagrindinė TimescaleDB idėja – automatinis duomenų skaidymas į mažesnius gabalus pagal laiką, vadinamus „chunks”. Tai leidžia sistemai efektyviai valdyti didžiulius duomenų kiekius, nes užklausos gali dirbti tik su reikalingais duomenų gabalais, o ne skenuoti visą lentelę.

Kaip veikia hypertables – TimescaleDB pagrindas

Hypertable – tai TimescaleDB magijos centras. Iš išorės tai atrodo kaip paprasta PostgreSQL lentelė, bet viduje tai sudėtinga struktūra, kuri automatiškai skaido duomenis į mažesnius gabalus.

Kai sukuriate hypertable, TimescaleDB automatiškai pradeda skaidyti duomenis į chunks pagal laiko intervalus. Pavyzdžiui, jei turite sensorių duomenis, kiekvienas chunk gali saugoti vienos savaitės duomenis. Kai ateina nauja savaitė, automatiškai sukuriamas naujas chunk.

Štai paprastas pavyzdys, kaip sukurti hypertable:


CREATE TABLE sensor_data (
time TIMESTAMPTZ NOT NULL,
sensor_id INTEGER,
temperature DOUBLE PRECISION,
humidity DOUBLE PRECISION
);

SELECT create_hypertable('sensor_data', 'time');


Ir viskas! Dabar jūsų lentelė yra hypertable. Galite įterpti duomenis kaip įprastai, bet TimescaleDB automatiškai pasirūpins efektyviu jų saugojimu. Nereikia jokių sudėtingų konfigūracijų ar specialių užklausų sintaksių.

Chunks dydis yra konfigūruojamas. Mažesni chunks leidžia efektyviau ištrinti senus duomenis, bet per daug mažų chunks gali sumažinti užklausų efektyvumą. Paprastai rekomenduojama, kad vienas chunk saugotų apie 25% jūsų serverio RAM atminties vertės duomenų, bet tai labai priklauso nuo konkrečios situacijos.

Duomenų suspaudimas ir saugojimo optimizavimas

Viena iš didžiausių problemų dirbant su laiko eilučių duomenimis – jie užima baisiai daug vietos. Jei renkate metrikos kas sekundę iš šimto serverių, per mėnesį susikaups nemažai duomenų. TimescaleDB siūlo kelis būdus, kaip su tuo susidoroti.

Pirmiausia – natyvus stulpelinis suspaudimas. TimescaleDB gali automatiškai suspausti senus chunks, sumažinant jų dydį iki 90-95%. Suspausti duomenys vis tiek išlieka užklausoms prieinami, tik įrašymas į juos tampa negalimas. Tai puikiai tinka senesnėms metrikoms, kurios jau nebesikeičia.


ALTER TABLE sensor_data SET (
timescaledb.compress,
timescaledb.compress_segmentby = 'sensor_id',
timescaledb.compress_orderby = 'time DESC'
);

SELECT add_compression_policy('sensor_data', INTERVAL '7 days');


Šis kodas nurodo TimescaleDB automatiškai suspausti duomenis, kurie senesni nei 7 dienos. Parametras `compress_segmentby` nurodo, pagal kokius stulpelius grupuoti duomenis suspaudžiant – tai labai svarbu užklausų efektyvumumui.

Kitas svarbus dalykas – duomenų agregavimas. Jei turite minutines metrikos, bet analizei dažniausiai naudojate valandines ar dienines suvestines, galite naudoti continuous aggregates. Tai kaip materialized views su steroidais – jos automatiškai atsinaujina, kai ateina nauji duomenys.

Continuous aggregates – realaus laiko suvestinės

Continuous aggregates yra viena iš galingiausių TimescaleDB funkcijų. Įsivaizduokite, kad turite milijardus įrašų su sekundinėmis metrikomis, bet jūsų dashboard’e rodote valandines vidurkius. Be continuous aggregates, kiekvienas dashboard’o atnaujinimas reikštų sunkią agregavimo užklausą milijardams įrašų.

Su continuous aggregates, TimescaleDB automatiškai palaiko atnaujintą agregacijų lentelę. Kai ateina nauji duomenys, tik reikalinga dalis agregacijų perskaičiuojama, o ne viskas iš naujo.


CREATE MATERIALIZED VIEW sensor_data_hourly
WITH (timescaledb.continuous) AS
SELECT
time_bucket('1 hour', time) AS bucket,
sensor_id,
AVG(temperature) as avg_temp,
MAX(temperature) as max_temp,
MIN(temperature) as min_temp
FROM sensor_data
GROUP BY bucket, sensor_id;

SELECT add_continuous_aggregate_policy('sensor_data_hourly',
start_offset => INTERVAL '3 hours',
end_offset => INTERVAL '1 hour',
schedule_interval => INTERVAL '1 hour');


Šis pavyzdys sukuria valandinę agregaciją, kuri automatiškai atsinaujina kas valandą. `start_offset` ir `end_offset` parametrai nurodo, kokį laiko langą atnaujinti – čia atnaujinami duomenys nuo prieš 3 valandas iki prieš 1 valandą, palikant laiko tarpą naujiems duomenims ateiti.

Continuous aggregates gali būti daugiapakopės – galite sukurti dienines agregacijas iš valandinių, mėnesines iš dieninių ir taip toliau. Tai leidžia efektyviai dirbti su istoriniais duomenimis bet kokiame detalumo lygyje.

Retention policies – automatinis senų duomenų valymas

Niekas nenori saugoti visų duomenų amžinai. Serverių metrikos iš prieš trejų metų tikriausiai nebereikalingos, o saugojimo kaštai auga. TimescaleDB retention policies leidžia automatiškai ištrinti senus duomenis.


SELECT add_retention_policy('sensor_data', INTERVAL '90 days');


Viena eilutė – ir visi duomenys senesni nei 90 dienų bus automatiškai ištrinami. TimescaleDB tai daro efektyviai, tiesiog išmesdamas senus chunks, o ne trinant įrašus po vieną.

Galite derinti retention policies su suspaudimu ir agregacijomis. Pavyzdžiui, galite saugoti detalius duomenis 7 dienas, suspaustas metrikos – 90 dienų, valandines agregacijas – metus, o dienines – amžinai. Taip gaunate ir greitą prieigą prie naujausių duomenų, ir galimybę analizuoti ilgalaikius trendus.

Svarbu suprasti, kad retention policy trina visą chunk’ą, ne atskirus įrašus. Tai reiškia, kad jei jūsų chunk’ai yra per dideli, galite prarasti daugiau duomenų nei planuojate. Pavyzdžiui, jei chunk’as saugo savaitės duomenis, o retention policy nustatytas 30 dienų, realiai duomenys bus trinami kas 7 dienas, kai chunk’as taps senesnis nei 30 dienų.

Užklausų optimizavimas ir best practices

Nors TimescaleDB automatiškai daro daug optimizavimo darbo, vis tiek yra dalykų, kuriuos reikia žinoti, kad gauti maksimalų našumą.

Pirmiausia – visada naudokite laiko filtrą užklausose. TimescaleDB gali praleisti nereikalingus chunks tik tada, kai žino, kokio laiko periodo duomenys jums reikalingi. Užklausa be laiko filtro turės skenuoti visus chunks.


-- Gera užklausa
SELECT AVG(temperature)
FROM sensor_data
WHERE time > NOW() - INTERVAL '1 day'
AND sensor_id = 123;

-- Bloga užklausa (skensuos visus chunks)
SELECT AVG(temperature)
FROM sensor_data
WHERE sensor_id = 123;


Antra – naudokite tinkamus indeksus. TimescaleDB automatiškai sukuria indeksą laiko stulpeliui, bet jei dažnai filtruojate pagal kitus stulpelius, reikės papildomų indeksų. Tačiau nepersistenkite – per daug indeksų sulėtina įrašymo operacijas.

Trečia – apgalvokite `compress_segmentby` parametrą. Jei dažnai filtruojate pagal `sensor_id`, įtraukite jį į `compress_segmentby`. Tai leis TimescaleDB efektyviau dirbti su suspaudžiais duomenimis.

Ketvirta – naudokite `time_bucket()` funkciją agregacijoms. Ji optimizuota darbui su laiko eilutėmis ir veikia daug greičiau nei standartinės PostgreSQL grupavimo funkcijos:


SELECT
time_bucket('5 minutes', time) AS five_min,
sensor_id,
AVG(temperature)
FROM sensor_data
WHERE time > NOW() - INTERVAL '1 day'
GROUP BY five_min, sensor_id
ORDER BY five_min DESC;


Praktinis pavyzdys: monitoring sistema

Pažiūrėkime, kaip visa tai veikia praktikoje. Tarkime, kuriate monitoring sistemą, kuri renka metrikos iš 1000 serverių kas 10 sekundžių. Tai 6000 įrašų per minutę arba 8.64 milijono per dieną.

Pirmiausia, sukuriame pagrindinę lentelę:


CREATE TABLE server_metrics (
time TIMESTAMPTZ NOT NULL,
server_id INTEGER NOT NULL,
cpu_usage DOUBLE PRECISION,
memory_usage DOUBLE PRECISION,
disk_io DOUBLE PRECISION,
network_io DOUBLE PRECISION
);

CREATE INDEX ON server_metrics (server_id, time DESC);


Nustatome suspaudimą senesnėms metrikoms:


ALTER TABLE server_metrics SET (
timescaledb.compress,
timescaledb.compress_segmentby = 'server_id',
timescaledb.compress_orderby = 'time DESC'
);

SELECT add_compression_policy('server_metrics', INTERVAL '3 days');


Sukuriame continuous aggregates skirtingiems laiko intervalams:


-- 5 minučių agregacija
CREATE MATERIALIZED VIEW server_metrics_5min
WITH (timescaledb.continuous) AS
SELECT
time_bucket('5 minutes', time) AS bucket,
server_id,
AVG(cpu_usage) as avg_cpu,
MAX(cpu_usage) as max_cpu,
AVG(memory_usage) as avg_memory,
AVG(disk_io) as avg_disk_io,
AVG(network_io) as avg_network_io
FROM server_metrics
GROUP BY bucket, server_id;

-- Valandinė agregacija
CREATE MATERIALIZED VIEW server_metrics_hourly
WITH (timescaledb.continuous) AS
SELECT
time_bucket('1 hour', time) AS bucket,
server_id,
AVG(cpu_usage) as avg_cpu,
MAX(cpu_usage) as max_cpu,
AVG(memory_usage) as avg_memory
FROM server_metrics
GROUP BY bucket, server_id;


Ir nustatome retention policies:


-- Detalūs duomenys - 30 dienų
SELECT add_retention_policy('server_metrics', INTERVAL '30 days');

-- Valandinės agregacijos - saugome amžinai (nenustatome retention)


Dabar turite visiškai automatizuotą sistemą, kuri efektyviai saugo ir apdoroja metrikos, automatiškai suspaudžia senus duomenis ir palaiko įvairių lygių agregacijas.

Migracija iš kitų sprendimų ir kas toliau

Jei jau naudojate InfluxDB, Prometheus ar kitą laiko eilučių duomenų bazę, migracija į TimescaleDB gali būti labai patraukli. Ypač jei jau turite PostgreSQL infrastruktūrą ir komandą, kuri gerai ją pažįsta.

TimescaleDB palaiko Prometheus remote storage API, todėl galite naudoti jį kaip Prometheus backend’ą be jokių pakeitimų Prometheus konfigūracijoje. Tai leidžia išlaikyti visą esamą Prometheus setup’ą, tik pakeičiant saugojimo backend’ą.

Migracija iš InfluxDB reikalauja daugiau darbo, bet TimescaleDB bendruomenė turi įvairių įrankių, kurie padeda konvertuoti duomenis. Didžiausias privalumas – galite naudoti standartinį SQL vietoj InfluxQL ar Flux, o tai reiškia, kad galite integruoti laiko eilučių duomenis su kitais jūsų duomenimis vienoje duomenų bazėje.

Našumo požiūriu, TimescaleDB paprastai lenkia tradicinį PostgreSQL 10-100 kartų laiko eilučių užklausose, o suspaudimo rodikliai yra panašūs ar geresni už specializuotas laiko eilučių duomenų bazes. Tačiau svarbu suprasti, kad TimescaleDB nėra sidabrinė kulka – jei jūsų use case reikalauja ekstremalaus write throughput (milijonai įrašų per sekundę), gali reikėti žiūrėti į paskirstytas sistemas kaip TimescaleDB Distributed arba specializuotas kolonines duomenų bazes.

Ateities planuose TimescaleDB komanda dirba prie dar geresnio suspaudimo, multi-node clustering tobulinimų ir glaudesnės integracijos su populiariais monitoring įrankiais. Projektas aktyviai vystomas, turi stiprią bendruomenę ir komercinį palaikymą per Timescale kompaniją.

Jei tik pradėjote kelionę su laiko eilučių duomenimis, TimescaleDB yra puikus pasirinkimas. Jei jau turite PostgreSQL patirties, mokymosi kreivė bus minimali. O jei dar neturite – išmoksite ne tik laiko eilučių duomenų bazę, bet ir vieną populiariausių reliacinių duomenų bazių pasaulyje. Tai investicija, kuri tikrai atsipirks.