Maailmas tehakse aina enam mõõtmisi ja tekib finantsandmeid ning nende tulemusi salvestatakse aegridadena (time-series). Viimastel aastatel on turule tulnud hulgaliselt aegridade andmebaasisüsteeme, mis on kohandatud aegridade andmete kiireks ning kettaruumi kokkuhoidvaks salvestamiseks ning mis pakuvad aegridade analüüsi lihtsustavaid funktsioone. Need andmebaasisüsteemid põhinevad erinevatel andmemudelitel (SQL, dokumendid, vektorid jne). Aegridade haldamise jaoks kohandatud SQL-andmebaasisüsteemid pakuvad laiadele massidele tuntud ja tuttavat SQL keelt, kuid "kapoti all" on andmebaasisüsteemi toimimist täiustatud.

2026. aasta märtsi seisuga oli andmebaasisüsteemide populaarsuse indeksis 47 aegridade andmebaasisüsteemi. Nendest neli kõige populaarsemat olid:
  • InfluxDB
  • Prometheus
  • Kdb
  • TimescaleDB
Järgnevalt on esitatud ühesugune näide nende andmebaasisüsteemide jaoks. Stsenaarium: Vaja on jälgida serverite protsessori temperatuuri.
  • Defineerin andmestruktuuri.
  • Lisan minutiliste vahedega kolm andmepunkti serveri server-A (asub regioonis eu-north-1) kohta.
  • Teen tüüpilise päringu: "Leia viimase 5 minuti protsessori keskmine temperatuur 1-minutiliste ajavahemike (akende) kaupa.
1. InfluxDB

InfluxDB kasutab kirjutamisel tekkiva skeemi lähenemist, mis tähendab, et andmestruktuuri ei pea eelnevalt defineerima. Andmestruktuur luuakse andmete sisestamisel automaatselt, tuginedes sildistruktuurile.
 
Andmestruktuur ja lisamine:
// Formaat: measurement,tag1=val,tag2=val fieldKey=fieldValue unix_timestamp
cpu_temperature,host=server-A,region=eu-north-1 value=45.5 1710000000
cpu_temperature,host=server-A,region=eu-north-1 value=46.2 1710000060
cpu_temperature,host=server-A,region=eu-north-1 value=47.0 1710000120

Päring (Flux päringukeel):
 
from(bucket: "metrics_bucket")
  |> range(start: 1709999700, stop: 1710000300) // Viimased 5 minutit (näiteks)
  |> filter(fn: (r) => r._measurement == "cpu_temperature" and r.host == "server-A")
  |> aggregateWindow(every: 1m, fn: mean)

2. Prometheus

Prometheus tõmbab andmeid rakendustelt ja andmestruktuur tekib samuti andmete lugemisel dünaamiliselt. Allpool on toodud andmete esitusformaat (mida rakendus Prometheusele välja näitaks) ja vastav päring.
 
Andmete väljanäitamine rakenduse poolt (Exposition Format):
# HELP cpu_temperature Protsessori temperatuur Celsiuses
# TYPE cpu_temperature gauge
cpu_temperature{host="server-A", region="eu-north-1"} 45.5 1710000000000
cpu_temperature{host="server-A", region="eu-north-1"} 46.2 1710000060000
cpu_temperature{host="server-A", region="eu-north-1"} 47.0 1710000120000

Seda teksti ei sisestata andmebaasi, vaid rakendus kuvab seda oma /metrics veebiaadressil, kust Prometheus seda ise lugemas käib.

Päring (PromQL):
# Prometheuses tehakse ajavahemikesse rühmitamine (step) HTTP API kaudu vahemike-päringut tehes.
# PromQL loogika 1-minutilise akna keskmise leidmiseks:
avg_over_time(cpu_temperature{host="server-A"}[1m])

3. TimescaleDB

TimescaleDB on ehitatud PostgreSQL-i peale, mis tähendab SQL andmebaasi struktuuri ja traditsioonilise SQL-i tuge, millele on lisatud aegridade funktsioonid.
 
CREATE TABLE cpu_temperature (
    time TIMESTAMPTZ NOT NULL,
    host TEXT NOT NULL,
    region TEXT NOT NULL,
    value DOUBLE PRECISION NOT NULL
);
 
-- Muudab tavalise tabeli ajaseerijateks optimeeritud hüpertabeliks
SELECT create_hypertable('cpu_temperature', 'time');

Andmete lisamine (SQL):
INSERT INTO cpu_temperature (time, host, region, value) VALUES
('2024-03-09 16:00:00+00', 'server-A', 'eu-north-1', 45.5),
('2024-03-09 16:01:00+00', 'server-A', 'eu-north-1', 46.2),
('2024-03-09 16:02:00+00', 'server-A', 'eu-north-1', 47.0);
 
Päring (SQL):
SELECT time_bucket('1 minute', time) AS bucket,
       AVG(value) AS avg_temp
FROM cpu_temperature
WHERE host = 'server-A' AND time >= '2024-03-09 15:55:00+00'
GROUP BY bucket
ORDER BY bucket DESC;

4. Kdb+

Kdb+ on äärmiselt kiire mälusisene (ja kettal baseeruv) veergorienteeritud andmebaasisüsteem, mis kasutab programmeerimiskeelt q. Seda kasutatakse laialdaselt finantssektoris.
 
Andmestruktuuri defineerimine:
// Defineerime tabeli struktuuri q keeles
cpu_temperature:([] time:`timestamp$(); host:`symbol$(); region:`symbol$(); value:`float$())

Andmete lisamine:
`cpu_temperature insert (2024.03.09D16:00:00.000000000; `$"server-A"; `$"eu-north-1"; 45.5)
`cpu_temperature insert (2024.03.09D16:01:00.000000000; `$"server-A"; `$"eu-north-1"; 46.2)
`cpu_temperature insert (2024.03.09D16:02:00.000000000; `$"server-A"; `$"eu-north-1"; 47.0)

Päring (q-SQL):
select avg_temp:avg value by bucket:time.minute from cpu_temperature where host=`$"server-A", time >= 2024.03.09D15:55:00.000000000


Millised on nende süsteemide põhilised erinevused?

Need neli süsteemi lahendavad sama probleemi, kuid nende arhitektuurilised otsused on tehtud täiesti erinevate kasutusjuhtude jaoks:
 
Andmemudel:
  • TimescaleDB on SQL-andmebaasisüsteem. Selle võiks valida kui tahta siduda ajaseeriaid tavaliste relatsiooniliste andmetega (teiste tabelitega) ja soovida hoida süsteemi PostgreSQL-i peal.
    • Selle tehnoloogia süda on hüpertabel. See on abstraktsioonikiht, mis lahendab suurandmetega kaasnevad jõudlusprobleemid, säilitades samal ajal tuttava SQL-i. Arendaja, analüütiku või rakenduse jaoks näeb hüpertabel välja ja käitub täpselt nagu tavaline PostgreSQL-i tabel. Kuid "kapoti all" ei ole andmed ühes suures failis. TimescaleDB tükeldab selle tabeli automaatselt ja lõppkasutaja jaoks nähtamatult paljudeks väiksemateks füüsilisteks tabeliteks, mida nimetatakse tükkideks (chunks). Jaotamine toimub esmaselt aja järgi (näiteks luuakse uus tükk iga päeva, nädala või kuu andmete jaoks). Vajadusel saab lisada ka teise dimensiooni (asukoht, seadme ID vms – space partitioning).
    • Hüpertabelid võimaldavad:
      • Kiire sisestamine: Kuna andmed sisestatakse reeglina "tänasesse päeva", lähevad kõik uued read kõige uuemasse tükki. Selle ühe tüki indeksid on väikesed ja mahuvad vahemällu. Sisestuskiirus püsib stabiilne ja kõrge ka siis, kui andmebaasis on juba miljardeid ridu.
      • Kiire otsimine: Aegridade puhul tahetakse peaaegu alati otsida andmeid kindla ajavahemiku kohta (nt WHERE time > CURRENT_TIMESTAMP - INTERVAL '7 days'). TimescaleDB teab täpselt, milline ajaperiood millises tükis asub. Päringu käivitamisel välistab see koheselt kõik ebaolulised füüsilised tabelid ega hakka nende indekseid isegi puutuma. Andmebaasisüsteem skaneerib ainult seda paari faili, kus otsitava ajaperioodi andmed päriselt asuvad.
      • Kiire kustutamine: Aegridade puhul on tavaline, et näiteks viis aastat vanu toorandmeid pole enam vaja. Tavalises andmebaasis on DELETE FROM tabel WHERE aeg < '2020-01-01' lause täitmine väga aeglane ja süsteemi koormav operatsioon, mis lukustab tabeli ja tekitab andefailides andmetesse "auke" (fragmentatsiooni). TimescaleDB eemaldab vanu andmeid lihtsalt terveid tükke ära visates (süsteem täidab sisuliselt failisüsteemi tasemel DROP TABLE lause). See operatsioon kestab murdosa sekundist ja vabastab kettaruumi koheselt.
      • Veerupõhine pakkimine: Reapõhine andmete salvestamine on kiire uute andmete sisestamiseks. Samas aegread on sageli väga korduvad (nt temperatuurisensor saadab pikalt sarnaseid väärtusi). TimescaleDB oskab vanemaid tükke (mida enam aktiivselt ei muudeta) automaatselt taustal kokku pakkida. Selleks muudetakse nende andmete salvestusviisi reapõhisest veerupõhiseks. See vähendab kettaruumi kulu sageli 90% või enam, kiirendades samas analüütilisi koondandmete leidmise päringuid (sest kettalt on vaja vähem andmeid mällu lugeda). Veerupõhine pakkimine toimub taustaprotsessina vanematele andmetele. Administraator seadistab kompressioonipoliitika, näiteks: "Paki kokku kõik andmetükid, mis on vanemad kui 7 päeva." See loob hübriidse arhitektuuri:
        • Kuumad andmed: Viimased seitse päeva. Reapõhine, kiiresti kirjutatav, kiiresti muudetav. Võtab rohkem kettaruumi.
        • Külmad/ajaloolised andmed: Vanemad kui seitse päeva. Veerupõhine, tugevalt pakitud (kuni 95% ruumisäästu). Neid andmeid on raske muuta (UPDATE/DELETE operatsioonid on pakitud andmetel piiratud või aeglasemad), aga neid on ülikiire analüüsida.
      • Kokkuvõte: Hüpertabelid annavad arendajale parima mõlemast maailmast: Nad töötavad justkui ühe suure ja tuttava PostgreSQL-tabeliga, kuid taustal toimetab arukas süsteem, mis jagab failid ja indeksid füüsiliselt väikesteks "ampsudeks". See hoiab mälu puhtana, ketta sisend/väljund operatsioonid minimaalsena ning päringud kiirena.
  • InfluxDB ja Prometheus põhinevad märgenditel (tag/label süsteem). Nad eeldavad, et mõõtmine on identifitseeritav nime ja võti-väärtus paaride kaudu.
    • Sildid (Prometheuses labels, InfluxDB-s tags) on tehniliselt võti-väärtus paarid (näiteks host="server-A", region="eu-north-1").  Erinevus NoSQL võti-väärtus paaride mudelist on selles, milleks neid kasutatakse. Klassikalises võti-väärtus andmebaasis on viitab iga unikaalne võti ühele kindlale väärtusele. Prometheuses ja InfluxDB-s moodustab mõõdiku nimi koos kõigi nende võti-väärtus paaridega unikaalse identifikaatori tervele andmevoole. Seda nimetatakse mitmemõõtmeliseks (multi-dimensional) andmemudeliks.
  • Kdb+ on veergorienteeritud massiiviandmebaas (vektoritel põhinev).
Andmete sisestamine:
  • InfluxDB, TimescaleDB ja Kdb+: rakendus saadab (kirjutab) andmed andmebaasi.
  • Prometheus: andmebaasisüsteem käib ise regulaarselt rakenduste (või eksportööride) otspunktidest uusi andmeid ära tõmbamas. See sobib hästi taristu jälgimiseks.
Päringukeeled ja õppimiskõver:
  • TimescaleDB: Madal õppimiskõver, kasutab tuttavat SQL-i ja pakub juurde mõnda mugavusfunktsiooni.
  • Prometheus: Kasutab PromQL-i, mis on spetsiaalselt loodud aegridade matemaatikaks ja hoiatuste tegemiseks. Tugev fookus ridade vektoritel ja aegreavõtmetel, traditsiooniliste päringute tegemine on algajale keerukas.
  • InfluxDB: Kasutab Fluxi (või InfluxQL-i). Flux sarnaneb andmetöötluskonveierile (vt torude |> kasutamine), väga võimekas spetsiifilise ajatöötluse jaoks.
  • Kdb+: Järsk õppimiskõver. Süntaks (q-keel) on omapärane ja raskesti loetav, kuid vastutasuks on süsteem analüütilistel päringutel nanosekundilise täpsuse juures palju kiirem kui teised. Kasutatakse peamiselt kõrgsageduskauplemises.
Tavalised SQL-andmebaasisüsteemid

Aegridade andmeid saab hoida ka tavaliste SQL-andmebaasisüsteemide abil loodud andmebaasides. Magistritöös "Aegridade esitamine SQL-andmebaasides OHLCV andmete näitel" esitatakse selle kohta mustri formaadis kaheksa disainilahendust. Nende lahenduste hulgast valiti konkreetse konteksti (näiterakendus, mis tegeleb väärtpaberite hinna liikumiste statistika loomisega) jaoks sobivaim kasutades Saaty meetodit.

Autor järeldas, et  õige disainilahenduse ja indeksitüübi valimisel on operatsioonide väikese töökiiruse suurenemise hinnaga võimalik oluliselt vähendada tabelite poolt kasutatavat andmemahtu. Lisaks võib järeldada, et päringute tegemiseks kulunud aeg ja ridade sisestamise kiirus oleneb tabelis olevatest ridade arvust ja kasutatavast indekstitüübist.