InfluxDB vs. TimescaleDB: Iedziļināšanās laika virkņu datu titānos

Mūsu savstarpēji savienotajā pasaulē dati tiek ģenerēti vēl nebijušā ātrumā. No sensoriem viedajā rūpnīcā Vācijā līdz finanšu kursiem Volstrītā un no lietojumprogrammu veiktspējas metrikiem SaaS uzņēmumam Singapūrā līdz vides monitoringam Amazonijas lietus mežā, šīs revolūcijas pamatā ir īpašs datu veids: laika virkņu dati.

Laika virkņu dati ir datu punktu secība, kas indeksēta laika secībā. To nepārtrauktā, liela apjoma daba rada unikālus izaicinājumus glabāšanai, izgūšanai un analīzei, ko tradicionālās relāciju datu bāzes nebija paredzētas apstrādāt. Tas ir radījis specializētu datu bāzu kategoriju, kas pazīstama kā Laika virkņu datu bāzes (TSDB).

Starp daudzajiem spēlētājiem TSDB telpā divi vārdi vienmēr dominē sarunā: InfluxDB un TimescaleDB. Abas ir jaudīgas, populāras un ļoti spējīgas, taču tās pieiet problēmai no fundamentāli atšķirīgām arhitektūras filozofijām. Izvēle starp tām ir kritisks lēmums, kas var ievērojami ietekmēt jūsu lietojumprogrammas veiktspēju, mērogojamību un darbības sarežģītību.

Šis visaptverošais ceļvedis analizēs šos divus titānus, izpētot to arhitektūru, datu modeļus, vaicājumu valodas, veiktspējas raksturlielumus un ideālos lietošanas gadījumus. Līdz beigām jums būs skaidrs ietvars, lai noteiktu, kura datu bāze ir vispiemērotākā jūsu īpašajām vajadzībām.

Kas ir InfluxDB? Speciāli izstrādāts spēkstacija

InfluxDB ir no nulles veidota, speciāli izstrādāta laika virkņu datu bāze, kas rakstīta Go programmēšanas valodā. Tā tika izstrādāta ar vienu galveno mērķi: apstrādāt ārkārtīgus laika zīmogu datu apjomus ar maksimālu efektivitāti. Tai nav vispārējas nozīmes datu bāzes bagāžas, kas ļauj to ļoti optimizēt konkrētiem laika virkņu datu darba slodzēm: augstas caurlaidspējas ierakstiem un laika centrētiem vaicājumiem.

Pamat arhitektūra un datu modelis

InfluxDB arhitektūra ir veidota ātrumam un vienkāršībai. Gadiem ilgi tās pamatā ir Time-Structured Merge Tree (TSM) krātuves dzinējs, kas ir optimizēts augstiem ievades ātrumiem un efektīvai kompresijai. Dati InfluxDB ir sakārtoti vienkāršā, intuitīvā modelī:

• Mērījums: jūsu laika virkņu datu konteiners, līdzīgs tabulai SQL. Piemērs: cpu_usage.
• Atzīmes: atslēgas un vērtības virkņu pāri, kas saglabā datus par datiem. Atzīmes vienmēr tiek indeksētas un ir ļoti svarīgas efektīvai vaicāšanai. Piemērs: host=serverA, region=us-west-1.
• Lauki: faktiskās datu vērtības, kas var būt peldoši punkti, veseli skaitļi, virknes vai loģiskās vērtības. Lauki netiek indeksēti. Piemērs: usage_user=98.5, usage_system=1.5.
• Laika zīmogs: augstas precizitātes laika zīmogs, kas saistīts ar lauka vērtībām.

Viens datu punkts InfluxDB varētu izskatīties šādi: cpu_usage,host=serverA,region=us-west-1 usage_user=98.5,usage_system=1.5 1672531200000000000. Atšķirības izpratne starp atzīmēm (indeksētiem metadatiem) un laukiem (neindeksētiem datiem) ir būtiska, veidojot efektīvu InfluxDB shēmu.

Vaicājumu valodas: InfluxQL un Flux

InfluxDB piedāvā divas vaicājumu valodas:

1. InfluxQL: SQL līdzīga vaicājumu valoda, kas ir intuitīva ikvienam ar pieredzi tradicionālajās datu bāzēs. Tas ir lieliski piemērots vienkāršai agregācijai un datu izgūšanai.
2. Flux: jaudīga, funkcionāla datu skriptu valoda. Flux ir daudz spējīgāks nekā InfluxQL, un tas nodrošina sarežģītas transformācijas, savienojumus starp mērījumiem un integrāciju ar ārējiem datu avotiem. Tomēr tam ir ievērojami stāvāka mācību līkne.

Galvenās funkcijas un ekosistēma

• Augsta rakstīšanas caurlaidspēja: paredzēts, lai ielādētu miljoniem datu punktu sekundē.
• Iebūvēta platforma: InfluxDB 2.0 un jaunākas versijas piedāvā vienotu platformu, kas ietver datu vākšanu (piemēram, Telegraf), vizualizāciju (informācijas paneļi) un brīdinājumus (uzdevumus) vienā binārā failā. Tas aizstāj vecāko TICK Stack (Telegraf, InfluxDB, Chronograf, Kapacitor).
• Datu dzīves cikla pārvaldība: automatizētas datu saglabāšanas politikas ļauj viegli pārvaldīt datu krātuvi, automātiski samazinot veco datu paraugu vai izdzēšot tos.
• Savrupatnējoša vienkāršība: atvērtā koda versija ir viens binārais fails bez ārējām atkarībām, padarot to ļoti viegli iedarbināmu un darbojošos.

Kas ir TimescaleDB? SQL laika virknēm

TimescaleDB izmanto pilnīgi atšķirīgu pieeju. Tā vietā, lai veidotu datu bāzi no nulles, tā ir veidota kā jaudīgs paplašinājums PostgreSQL. Tas nozīmē, ka tā manto visu stabilitāti, uzticamību un bagātīgās funkcijas no vienas no pasaules vismodernākajām atvērtā koda relāciju datu bāzēm, vienlaikus pievienojot specializētas optimizācijas laika virkņu datiem.

Pamat arhitektūra un datu modelis

Kad instalējat TimescaleDB, jūs būtībā uzlādējat standarta PostgreSQL instanci. Maģija slēpjas tās pamatkoncepcijās:

• Hipertabulas: tās ir lietotāja redzamās tabulas, kurās glabājat savus laika virkņu datus. Tās izskatās un darbojas kā parastās PostgreSQL tabulas.
• Daļas: iekšēji TimescaleDB automātiski sadala hipertabulas datus daudzās mazākās bērnu tabulās, ko sauc par daļām, pamatojoties uz laiku. Katra daļa ir standarta PostgreSQL tabula. Šī sadalīšana ir lietotājam caurspīdīga, bet ir atslēga TimescaleDB veiktspējai.

Tā kā tas ir veidots uz PostgreSQL, datu modelis ir pilnībā relācijas. Jūs izveidojat standarta SQL tabulu ar kolonnām savam laika zīmogam, metadatiem (piemēram, ierīces ID vai atrašanās vieta) un datu vērtībām. Nav jauna datu modeļa, kas būtu jāapgūst, ja jau pārzināt SQL.

CREATE TABLE conditions ( time TIMESTAMPTZ NOT NULL, location TEXT NOT NULL, temperature DOUBLE PRECISION NULL, humidity DOUBLE PRECISION NULL ); SELECT create_hypertable('conditions', 'time');

Vaicājumu valoda: pilna SQL spēks

TimescaleDB lielākais pārdošanas punkts ir tā vaicājumu valoda: standarta SQL. Šim ir milzīgas priekšrocības vairāku iemeslu dēļ:

• Nulles mācīšanās līkne: jebkurš izstrādātājs, analītiķis vai rīks, kas runā SQL, var nekavējoties strādāt ar TimescaleDB.
• Nepārspējams spēks: jūs iegūstat piekļuvi pilnam SQL analīzes spēkam, tostarp apakšvaicājumiem, logu funkcijām un, pats galvenais, SAVIENOJUMIEM.
• Bagātīga ekosistēma: visa, plašā PostgreSQL ekosistēma ar rīkiem, savienotājiem un paplašinājumiem (piemēram, PostGIS papildu ģeotelpiskajiem vaicājumiem) ir pieejama.

TimescaleDB arī pievieno simtiem specializētu laika virkņu funkciju SQL, piemēram, time_bucket(), first() un last(), lai vienkāršotu un paātrinātu izplatītākos laika virkņu vaicājumus.

Galvenās funkcijas un ekosistēma

• Pilns SQL atbalsts: izmantojiet esošo SQL pieredzi un rīkus bez izmaiņām.
• Relāciju un laika virkņu dati kopā: nevainojami SAVIENOJIET savus laika virkņu datus (piemēram, sensoru rādījumus) ar saviem relāciju biznesa datiem (piemēram, ierīces metadati, informācija par klientiem).
• Pierādīta uzticamība: manto PostgreSQL gadu desmitu izstrādi, akmens cietu uzticamību un ACID atbilstību.
• Papildu kompresija: piedāvā labāko kolonnu kompresiju, kas var samazināt krātuves nospiedumus par vairāk nekā 90%.

Salīdzinājums: InfluxDB vs. TimescaleDB

Sadalīsim pamat atšķirības pēc vairākiem galvenajiem kritērijiem, lai palīdzētu jums pieņemt informētu lēmumu.

Pamatfilozofija un arhitektūra

• InfluxDB: speciāli veidota, atsevišķa sistēma. Tā prioritāte ir veiktspēja un lietošanas vienkāršība laika virkņu darba slodzēm, veidojot visu no nulles. Tas rada ļoti optimizētu, bet potenciāli mazāk elastīgu sistēmu.
• TimescaleDB: paplašinājums, kas uzlabo vispārējas nozīmes datu bāzi. Tā prioritāte ir uzticamība, vaicājumu jauda un ekosistēmas saderība, veidojot uz nobrieduša PostgreSQL pamata. Tas piedāvā neticamu elastību, bet var radīt pilnīgas RDBMS darbības pārslodzi.

Globālā perspektīva: jaunuzņēmums Bangalore varētu atbalstīt InfluxDB vienkāršo, viss vienā iestatīšanu ātrai prototipēšanai. Savukārt liela finanšu iestāde Londonā varētu dot priekšroku TimescaleDB spējai integrēties ar esošo PostgreSQL infrastruktūru un pierādīto datu integritāti.

Datu modelis un shēmas elastība

• InfluxDB: izmanto nesaistītu mērījumu, atzīmju un lauku modeli. Tas ir ļoti efektīvs standarta laika virkņu modeļiem, bet relāciju loģiku apgrūtina. Augsta kardinalitāte (augsts unikālu atzīmju vērtību skaits) var būt veiktspējas izaicinājums vecākās versijās.
• TimescaleDB: izmanto standarta relācijas (SQL) modeli. Tas prasa iepriekš definēt shēmu, bet nodrošina milzīgu elastību sarežģītām datu attiecībām, izmantojot SAVIENOJUMUS. Tas labi apstrādā augstu kardinalitāti, uzskatot to par jebkuru citu indeksētu kolonnu PostgreSQL.

Vaicājumu valoda

• InfluxDB: divvalodu pasaule. InfluxQL ir vienkāršs, bet ierobežots. Flux ir ārkārtīgi jaudīgs laika virkņu analīzei, bet ir patentēta valoda, kas prasa ievērojamu mācību ieguldījumu jūsu komandā.
• TimescaleDB: standarta SQL. Tas, iespējams, ir tā pārliecinošākais elements. Tas pazemina ienākšanas barjeru, atslēdz milzīgu talantu fondu un nodrošina sarežģītus analītiskos vaicājumus, kas ir triviāli SQL, bet sarežģīti vai neiespējami InfluxQL.

Veiktspēja: ievadīšana, vaicāšana un krātuve

Veiktspējas etaloni ir ārkārtīgi sarežģīti un atkarīgi no darba slodzes. Tomēr mēs varam apspriest vispārīgas īpašības.

• Ievades caurlaidspēja: abas datu bāzes piedāvā fenomenālu rakstīšanas veiktspēju un var apstrādāt miljoniem metrisko rādītāju sekundē uz atbilstoša aparatūras. Ilgu laiku InfluxDB bieži vien bija neliels pārsvars vienkāršā, neapstrādātā ievades ātrumā, pateicoties tā specializētajam TSM dzinējam. TimescaleDB veiktspēja ir ļoti konkurētspējīga un gūst lielu labumu no pakešu ierakstiem.
• Vaicājumu veiktspēja:
  • Attiecībā uz vienkāršām uz laiku balstītām agregācijām (piemēram, `AVG(cpu_usage)` pēdējās stundas laikā, grupēti pēc resursdatora), abas datu bāzes ir zibenīgi ātras.
  • Attiecībā uz sarežģītiem analītiskiem vaicājumiem, kas ietver SAVIENOJUMUS ar relāciju metadatiem, TimescaleDB ir neapstrīdēts uzvarētājs. Šāda veida vaicājumu izpilde InfluxDB prasa Flux izmantošanu, un tas var būt ievērojami sarežģītāks un mazāk efektīvs.
• Datu kompresija: abi piedāvā izcilu, nozares vadošo kompresiju. InfluxDB TSM izmanto tādas metodes kā delta kodēšana un palaides garuma kodēšana. TimescaleDB piedāvā caurspīdīgu, kolonnu kompresiju katrai kolonnai, ļaujot sajaukt un saskaņot labākos kompresijas algoritmus jūsu datu tipiem, bieži sasniedzot 90–98% kompresiju.

Ekosistēma un integrācijas

• InfluxDB: ir spēcīga, nobriedusi ekosistēma, īpaši DevOps un uzraudzības telpā. Tam ir vietējās klientu bibliotēkas daudzās valodās un tas nevainojami integrējas ar tādiem rīkiem kā Grafana. All-in-one InfluxDB 2.0+ platforma ir pilnīgs risinājums, kas ir gatavs lietošanai.
• TimescaleDB: tā ekosistēma ir visa PostgreSQL ekosistēma. Šī ir milzīga priekšrocība. Jebkura lietojumprogramma, savienotājs (JDBC, ODBC), BI rīks (Tableau, Power BI) vai paplašinājums, kas darbojas ar PostgreSQL, darbojas ar TimescaleDB. Tas ietver jaudīgus paplašinājumus, piemēram, PostGIS pasaules klases ģeotelpiskajai analīzei, padarot to ideāli piemērotu tādiem lietošanas gadījumiem kā loģistika vai aktīvu izsekošana.

Mērogojamība un klasterizācija

• InfluxDB: atvērtā koda versija ir viena mezgla instances. Horizontālā mērogošana un augsta pieejamība ir komerciālo InfluxDB Enterprise un InfluxDB Cloud produktu funkcijas.
• TimescaleDB: atvērtā koda versija var mērogojums vertikāli, lai apstrādātu ļoti lielus datu kopas uz viena jaudīga servera. Daudzmezglu klasterizācija horizontālai mērogošanai un augstai pieejamībai ir pieejama viņu mākoņa un pašapkalpošanās uzņēmuma piedāvājumos.

Lietošanas gadījuma dziļa izpēte: kad izvēlēties kuru?

Izvēle nav atkarīga no tā, kura datu bāze objektīvi ir “labāka”, bet kura ir “pareizais risinājums” jūsu projektam, komandai un datiem.

Izvēlieties InfluxDB, kad...

• Jūsu lietošanas gadījums ir tīri DevOps/Metrisko rādītāju uzraudzība: InfluxDB platforma ir pielāgota metrisko rādītāju vākšanai un analīzei no serveriem, lietojumprogrammām un tīkliem. Telegraf kolektoram ir simtiem spraudņu, padarot to par plug-and-play risinājumu.
• Jūs prioritāte ir iestatīšanas vienkāršība: Ātrai, atsevišķai TSDB bez ārējām atkarībām InfluxDB viens binārais fails ir grūti pārspējams.
• Jūsu vaicājumu vajadzības galvenokārt ir uz laiku balstīta agregācija: ja jūs galvenokārt veicat `GROUP BY time()` un jums nav nepieciešams SAVIENOJUMS ar sarežģītiem biznesa datiem, InfluxDB ir ļoti efektīvs.
• Jūsu komanda vēlas ieguldīt Flux: ja jūs saskatāt vērtību Flux jaudīgajās analītiskajās iespējās un esat gatavi mācību līknei, tas var būt ievērojams aktīvs.

Izvēlieties TimescaleDB, kad...

• Jūs jau izmantojat PostgreSQL: ja jūsu organizācijai jau ir PostgreSQL pieredze un infrastruktūra, TimescaleDB pievienošana ir dabiska un zemas pārslodzes izvēle.
• Jums ir jāapvieno laika virknes un relāciju dati: šī ir TimescaleDB slepenā funkcija. Ja jums ir jāpalaiž tādi vaicājumi kā “Parādiet man vidējo sensora temperatūru visām ierīcēm, kas ražotas noteiktā rūpnīcā, kas pieder klientiem “premium” līmenī”, TimescaleDB ir skaidra izvēle.
• Jūsu komanda dzīvo un elpo SQL: esošo jūsu izstrādes un datu analīzes komandu zināšanu izmantošana ir milzīgs produktivitātes paātrinātājs.
• Jums nepieciešama ģeo-temporālā analīze: TimescaleDB un PostGIS paplašinājuma kombinācija rada nepārspējamu platformu datu analīzei, kurai ir gan laika, gan atrašanās vietas komponents (piemēram, globālā kuģu flotes izsekošana).
• Jums ir nepieciešama nobriedušas RDBMS uzticamība un datu integritāte: finanšu pakalpojumiem, rūpnieciskās kontroles sistēmām vai jebkurai lietojumprogrammai, kur datu zudums nav opcija, PostgreSQL kaujās pārbaudītais pamats ir liels ieguvums.

Nākotne: InfluxDB 3.0 un Timescale attīstība

Datu bāzes vide pastāvīgi attīstās. Būtiska attīstība ir InfluxDB 3.0. Šī jaunā versija pārstāv pilnīgu arhitektūras pārbūvi, pārveidojot krātuves dzinēju (ar nosaukumu IOx) programmā Rust, izmantojot modernas datu ekosistēmas tehnoloģijas, piemēram, Apache Arrow un Apache Parquet. Tas sniedz transformējošas izmaiņas:

• Praktiski neierobežota kardinalitāte: jaunais dzinējs ir paredzēts gandrīz bezgalīgas sērijas kardinalitātes apstrādei, vēsturiski sāpīgs punkts.
• SQL atbalsts: InfluxDB 3.0 piedāvā pirmās klases atbalstu SQL kā primārajai vaicājumu valodai, tiešu soli, lai konkurētu ar TimescaleDB lielāko priekšrocību.
• Kolonnu krātuve: izmantojot Parquet nodrošina ļoti efektīvu, standartizētu kolonnu krātuvi.

Šī attīstība izpludina robežas starp abām datu bāzēm. Kad InfluxDB 3.0 nogatavosies, tas piedāvās daudzas priekšrocības (piemēram, SQL un kolonnu krātuve), kas reiz bija unikālas TimescaleDB, vienlaikus saglabājot savu speciāli izstrādāto fokusu.

Tikmēr TimescaleDB turpina ieviest jauninājumus, pievienojot tādas funkcijas kā progresīvāka kompresija, labāka daudzmezglu veiktspēja un dziļāka integrācija ar mākoņdatoru ekosistēmu, nostiprinot savu pozīciju kā augstākā laika virkņu risinājums PostgreSQL pasaulē.

Secinājums: pareizās izvēles veikšana savai globālajai lietojumprogrammai

Cīņa starp InfluxDB un TimescaleDB ir klasisks stāsts par divām filozofijām: specializēta, speciāli izstrādāta sistēma pret elastīgu, vispārējas nozīmes spēkstaciju. Nav universāla uzvarētāja.

Pareizā izvēle ir atkarīga no rūpīgas jūsu īpašo vajadzību izvērtēšanas:

1. Datu modeļa sarežģītība: vai jums ir nepieciešams SAVIENOJUMS laika virkņu datiem ar citiem biznesa datiem? Ja jā, tiecieties uz TimescaleDB. Ja nē, InfluxDB ir spēcīgs konkurents.
2. Esošās komandas prasmes: vai jūsu komanda ir pilna ar SQL ekspertiem? TimescaleDB jutīsies kā mājās. Vai viņi ir atvērti jaunas, jaudīgas valodas apguvei, piemēram, Flux, vai sākt no jauna? InfluxDB varētu būt piemērots.
3. Darbības pārslodze: vai vēlaties vienkāršu, atsevišķu bināro failu? InfluxDB. Vai jūs jau pārvaldāt PostgreSQL vai jūtaties ērti to darot? TimescaleDB.
4. Ekosistēmas vajadzības: vai jums ir nepieciešami specifiski PostgreSQL paplašinājumi, piemēram, PostGIS? TimescaleDB ir jūsu vienīgā iespēja. Vai uz DevOps vērstā ekosistēma ar Telegraf un InfluxDB platformu ir ideāla saderība? Dodieties uz InfluxDB.

Ar InfluxDB 3.0 parādīšanos un tās atbalstu SQL lēmums kļūst niansētāks. Tomēr pamatfilozofijas paliek nemainīgas. InfluxDB ir laika virkņu platforma, bet TimescaleDB ir PostgreSQL platforma ar izcilām laika virkņu iespējām.

Galu galā labākais padoms jebkurai globālajai komandai ir veikt koncepcijas pierādījumu. Iestatiet abas datu bāzes, ievadiet savu datu reprezentatīvo paraugu un palaidiet vaicājumus, kas būs nepieciešami jūsu lietojumprogrammai. Praktiskā pieredze atklās, kura datu bāze ne tikai vislabāk darbojas jūsu darba slodzei, bet arī jūtas vislabāk jūsu komandai.