Aikasarjatietokannat puolustustelemetriaan: tallennus, säilytys, kyselyt

Nykyaikainen panssaroitu ajoneuvo lähettää satoja anturilukemia sekunnissa – moottorin kierrosluku, öljynpaine, vaihteiston lämpötila, jousituksen kuormitus, polttoaineen virtaus, akun jännite, GPS-sijainti ja yhteyden laatu jokaisella siihen liitetyllä radiolla. 200 ajoneuvon kalusto tuottaa kymmeniä miljoonia datapisteitä minuutissa. Sota-alus, jossa on täysi koneiston valvonta, tuottaa enemmän. Tämän telemetrian tallentaminen relaatiotietokantaan ei ole koskaan ollut mahdollista laajassa mittakaavassa; kirjoitusmallit, kyselymuodot ja säilytysvaatimukset eroavat perustavasti transaktiotyökuormista. Aikasarjatietokannat (TSDB) ovat olemassa juuri tämän ongelman ratkaisemiseksi, ja sellaista käyttöönotettaessa tehdyt insinööripäätökset – skeeman suunnittelu, eräparametrit, alasnäytteistyskäytäntö, tunnisteiden kardinaliteetti – ratkaisevat, kykeneekö järjestelmä ylläpitämään operatiivista tempoa vai romahtaako se kuormituksen alla muutamassa päivässä käyttöönotosta. Tämä artikkeli kattaa koko elinkaaren: anturiverkon tallennuksesta säilytystasojen ja kyselymallien kautta puolustusanalytiikkaan.

Miksi aikasarjatietokannat ovat olemassa

Aikasarjatietokanta on tallennusmoottori, joka on rakennettu varta vasten lisäyspainotteiselle, aikaleimajärjestyksessä olevalle datalle, jossa kyselyt sisältävät lähes aina aikavälin ja jossa datan pääarvo on sen ajallisessa suhteessa – kuinka metriikka muuttuu ajan myötä, ei kuinka yksittäinen lukema liittyy toiseen entiteettiin.

Keskeinen tekninen ero relaatiotietokantoihin on tallennuksen asettelu. TSDB:t käyttävät sarakemuotoista tallennusta automaattisella aikaperusteisella ositetuksella (tuotteesta riippuen nimeltään shardit, chunkit tai bucketit). Kaikki tietyn metriikan lukemat aikaikkunan sisällä tallennetaan fyysisesti vierekkäin levylle. Tämä tarkoittaa, että aikavälin aggregaatiokysely – "anna minulle alustan P moottorin keskilämpötila viimeisten 24 tunnin ajalta" – lukee yhtenäisen levylohkon, ei hajallaan olevia kekosivuja. 10 000 anturikirjoituksella sekunnissa TSDB voi ylläpitää tätä työkuormaa yksinumeroisella millisekuntien kirjoitusviiveellä tavanomaisella NVMe-tallennuksella. Relaatiotietokanta kyllästäisi I/O-alijärjestelmänsä samalla kirjoitusnopeudella, koska jokaisen lisäyksen on päivitettävä useita indeksejä.

Pakkaus on toinen kriittinen etu. Peräkkäisten aikaleimojen liukulukumuotoiset anturilukemat ovat usein lähes identtisiä – lämpötila muuttuu asteen murto-osilla näytteiden välillä. TSDB:t käyttävät delta-koodausta, XOR-pakkausta (IEEE 754 -doubleille) ja juoksupituuskoodausta saavuttaakseen 10:1 tai paremmat pakkaussuhteet tyypillisillä telemetriavuoilla. Raaka telemetriavuo, joka veisi 1 TB relaatiotietokannassa, tallentuu 80–120 GB:hen TSDB:ssä.

Skeeman suunnittelu: measurementit, tunnisteet ja kentät

Ennen ensimmäistä kirjoitusta tehdyt skeemapäätökset ovat vaikeimpia perua. Huonosti suunniteltu tunnistejoukko aiheuttaa sarjojen kardinaliteettiräjähdyksen – tilan, jossa tietokannan erillisten aikasarjojen määrä kasvaa rajoittamattomasti, kuluttaa indeksimuistia ja heikentää kaikkia kyselyitä. Tämä on TSDB-käyttöönottojen yleisin tuotantovirhetila ja se on täysin vältettävissä oikealla suunnittelulla.

Measurementit

Measurement (joissakin tuotteissa nimeltään metriikkaperhe) on toisiinsa liittyvien kenttien looginen ryhmittely, jotka kirjoitetaan aina yhdessä samalla aikaleimalla. Järkeviä measurement-rajoja puolustusalustojen telemetrialle ovat: engine_telemetry (kierrosluku, öljynpaine, jäähdytysnesteen lämpötila, polttoaineen virtausnopeus), nav_position (leveysaste, pituusaste, korkeus, suunta, maanopeus), power_systems (akun jännite, laturin teho, kuormavirta väylää kohden) ja radio_link_quality (signaalin voimakkuus, kohinataso, pakettivirhesuhde, uudelleenlähetysten määrä). Saman measurementin kentät jakavat aikaleiman ja tallentuvat yhdessä, joten ryhmittely kirjoitustahdin ja operatiivisen koheesion mukaan tuottaa tehokkaimman asettelun.

Tunnisteet vastaan kentät

Tunnisteet ovat indeksoitua metadataa, joka identifioi sarjan. Jokainen ainutlaatuinen tunnistearvojen yhdistelmä luo erillisen sarjan indeksiin. Kentät ovat numeerisia arvoja, jotka kirjoitetaan jokaisella aikaleimalla – niitä ei indeksoida, vain tallennetaan. Suunnittelusääntö on: jos sinun on suodatettava tai ryhmiteltävä dimension mukaan kyselyn predikaatissa, sen on oltava tunniste. Jos sinun täytyy vain lukea arvo, sen tulisi olla kenttä.

Sotilasalustojen telemetrialle sopivia tunnisteita ovat: platform_id (vakaa lyhyt tunniste, esim. "VH-041"), platform_type (esim. "M1A2", "BTR-4", "Mi-8"), unit_id (pataljoonan tai laivueen tunniste), sensor_class (esim. "engine", "nav", "comms") ja base tai grid_zone karkeaa sijaintikontekstia varten. Nämä ovat matalan kardinaliteetin: 500 ajoneuvon kalusto, jossa on 20 yksikkösijoitusta ja 5 alustatyyppiä, tuottaa enintään 50 000 erillistä sarjaa – hyvin minkä tahansa tuotanto-TSDB:n mukavan toiminta-alueen sisällä.

Mitä EI saa olla tunnisteita: raakoja GPS-koordinaatteja, tapahtuma-UUID:eita, vapaatekstisiä vikakoodeja tai mitään muuta kenttää, jonka kardinaliteetti on verrannollinen datapisteiden määrään. Raa'an leveysasteen asettaminen tunnisteeksi luo uuden sarjan jokaiselle datapisteelle – indeksi kasvaa rajoittamattomasti ja kyselysuorituskyky heikkenee tunneissa. Korkean kardinaliteetin tunnisteet kuuluvat kenttiin tai erilliseen relaatiopohjaiseen metadatasäiliöön, joka liittyy TSDB-sarjaan vakaiden matalan kardinaliteetin tunnisteiden kautta.

Suuren nopeuden tallennus: erät, puskurointi ja epäjärjestyskirjoitukset

Puolustusanturit – erityisesti ajoneuvoalustoilla tai UAV-laitteilla olevat – eivät kirjoita suoraan TSDB:hen. Reunakeräin toimii alustalla tai yhdyskäytävällä, joka aggregoi dataa ajoneuvon osastosta, puskuroi lukemat paikallisesti ja tyhjentää erät TSDB:hen taktisen verkon yli. Tallennusarkkitehtuurissa on kolme parametria, jotka ratkaisevat, voiko se imeä jatkuvan kirjoituskuorman menettämättä dataa tai kyllästämättä verkkoa.

Eräkoko. Yhden pisteen kirjoittaminen kerrallaan tuottaa yhden verkon edestakaisen matkan anturilukemaa kohden – täysin kestämätöntä suurilla nopeuksilla. 1 000–5 000 pisteen eräkoot kirjoituspyyntöä kohden vähentävät verkon yleiskustannuksia kolmella suuruusluokalla. Kompromissi on kirjoitusviive: 1 000 pisteen erällä ja 100 Hz:n anturilla data viivästyy jopa 10 sekuntia ennen erän tyhjentymistä. Operatiivisessa valvonnassa, jossa 10–30 sekunnin viive on hyväksyttävää, suuret erät ovat optimaalisia. Lähes reaaliaikaiselle hälytykselle pienemmät erät aikaperusteisella tyhjennysvälillä (esim. tyhjennys 2 sekunnin välein erän täyttymisestä riippumatta) ovat sopivampia.

Kirjoituslokipuskurointi (write-ahead). Taktiset radioyhteydet kokevat katkoksia. Kun yhteys on poikki, reunakeräimen on puskuroitava lähettämätön data paikallisesti – pysyvään tallennukseen, ei vain muistiin, jotta data selviää prosessin uudelleenkäynnistyksestä tai virtakatkosta. Puskurin mitoitus tulisi laskea enimmäisoletetun yhteyskatkoksen keston ja huippukirjoitusnopeuden tulosta: 10 minuutin katkos 5 000 pistettä sekunnissa -anturivuolla vaatii 3 miljoonan pisteen puskurikapasiteetin, noin 150 MB tyypillisillä liukulukukenttäleveyksillä. Keräimet, jotka käyttävät vain muistinsisäisiä puskureita, menettävät dataa jokaisella yhteyskatkoksella.

Epäjärjestyskirjoitusten hyväksyntä. Kun puskuroitu data saapuu yhteyden palauduttua, se kantaa menneisyyden aikaleimoja. TSDB:t vaihtelevat merkittävästi epäjärjestyskirjoitusten sietokyvyssään: jotkut hylkäävät kirjoitukset, joiden aikaleimat ovat vanhempia kuin määritettävä ikkuna; toiset hyväksyvät minkä tahansa historiallisen kirjoituksen, mutta suorituskykykustannuksin. Hyväksymisikkuna on määritettävä vastaamaan alustatyypin enimmäisoletettua yhteyskatkosta. Ajoneuvoalustoille taktisella radiolla 300–600 sekuntia on tyypillistä. Satelliittireleellä toimiville alustoille, joilla yhteyskatkos ohitusvälin aikana voi kestää 90 minuuttia, ikkunan on oltava 5 400 sekuntia tai enemmän.

Säilytyskäytännöt ja alasnäytteistys

Raaka telemetria täydellä resoluutiolla on kallista tallentaa pitkäaikaisesti ja harvoin tarpeen lyhyttä operatiivista ikkunaa pidemmälle. Kolmitasoinen säilytyskäytäntö kattaa käytännössä kaikki puolustustelemetrian vaatimukset ilman tarpeetonta tallennuskustannusta.

Taso 1 – Raaka. Täyden resoluution data (10–100 Hz anturityypistä riippuen) säilytettynä 7–30 päivää. Tämä ikkuna tukee reaaliaikaista valvontaa, välitöntä jälkitapahtuma-analyysiä ja kynnyshälytysten tarkastelua. 500 alustan kalustolle, jossa on 50 anturia alustaa kohden kirjoittamassa 10 Hz:llä, täyden resoluution tallennus kuluttaa noin 2–4 TB päivässä pakatussa TSDB-tallennuksessa – hallittavissa 30 päivän säilytykselle tavanomaisella NAS-laitteistolla.

Taso 2 – 1 minuutin aggregaatit. Laskettuna jatkuvakyselyllä tai alasnäytteistystehtävällä: keskiarvo, minimi, maksimi ja lukumäärä jokaiselle kentälle jokaisella 1 minuutin ikkunalla. Säilytettynä 6–12 kuukautta. Tämä resoluutio tukee trendianalyysiä, ennakoivan kunnossapidon piirteiden suunnittelua ja poikkeamien havaitsemista kaluston mittakaavassa. Tallennus 1 minuutin resoluutiolla on noin 600× pienempi kuin raakataso.

Taso 3 – 1 tunnin aggregaatit. Säilytettynä 3–7 vuotta pitkän aikavälin kaluston kuntoanalyysiä, elinkaaren suunnittelua ja ylläpito-ohjelmien tarkastelua varten. Tällä resoluutiolla 7 vuoden historia 500 alustan kalustolle vie selvästi alle 100 GB – mitättömän halpaa suhteessa historiatietueen operatiiviseen arvoon.

Alasnäytteistystehtävät on ajastettava tarkoituksellisella siirtymällä ikkunarajasta. Tehtävä, joka ajastetaan suorittumaan tarkalleen minuuttirajalla, lukee usein epätäydellisen ikkunan – datan viimeiset sekunnit eivät ehkä ole vielä tyhjentyneet tallennusputkesta. 30 sekunnin siirtymä varmistaa, että ikkuna on täydellinen ennen aggregaatiota. Tämä yksityiskohta poistaa kokonaisen luokan hienovaraisia reuna-artefakteja, jotka ilmenevät poikkeavina notkahduksina tai piikkeinä säännöllisin väliajoin alasnäytteistetyssä datassa.

Kyselymallit puolustustelemetrian analytiikkaan

Viisi kyselymallia muodostavat valtaosan operatiivisesta ja analyyttisestä käytöstä puolustustelemetrian TSDB:tä vastaan. Tuotantokäyttöönoton on käsiteltävä kaikki viisi vain indeksiin perustuvalla suorituksella – ei täyssarjatarkistuksia – 6–12 kuukauden kertymän jälkeen odotetuilla datamäärillä.

Viimeisen arvon kyselyt. "Mikä on ajoneuvon VH-041 moottorin nykyinen lämpötila?" Tämä on yleisin kysely operatiivisessa valvontakojelaudassa. Tähän malliin optimoidut TSDB:t ylläpitävät viimeisen arvon indeksiä sarjaa kohden, joten kysely palaa vakioajassa riippumatta siitä, kuinka paljon historiallista dataa on olemassa. Ilman tätä optimointia viimeisen arvon kyselyt rappeutuvat käänteiseksi aikatarkistukseksi raakasarjan yli – hyväksyttävää matalalla kardinaliteetilla, ei hyväksyttävää kaluston mittakaavassa.

Aikavälin aggregaatiot. "Mikä oli kaikkien Unit-7:n M1A2-alustojen keskimääräinen polttoaineenkulutusnopeus viimeisten 72 tunnin aikana?" Tämä on keskeinen analytiikkakysely: tunnistesuodatin, joka valitsee relevantit sarjat, aikavälitarkistus ja aggregaatiofunktio, joka sovelletaan sekä aikadimensioon että suodatettuihin sarjoihin. Suoritusajan tulisi mitata kymmenissä millisekunneissa 12 kuukauden datamäärillä oikein indeksoidulle skeemalle; sadat millisekunnit viittaavat kardinaliteettiongelmaan.

Kynnysrajan ylityksen havaitseminen. "Milloin minkä tahansa kaluston ajoneuvon vaihteistoöljyn lämpötila ensimmäistä kertaa ylitti 120 °C viimeisten 30 päivän aikana?" Tämä kysely vaatii tarkistuksen aikavälin yli predikaatilla kenttäarvoon. Jotkut TSDB:t suorittavat tämän tehokkaasti sarakemuotoisella minimi-/maksimi-metadatalla, joka karsii chunkit, joissa ei ole kynnyksen ylittäviä arvoja; toiset vaativat täyden kenttätarkistuksen. Sen ymmärtäminen, mitä suoritusstrategiaa valittu tuote käyttää, on kriittistä hälytysjärjestelmän viivebudjettien mitoittamiseksi.

Monisarjavertailu. "Näytä minulle polttoaineenkulutus kaikille BTR-4-tyypin ajoneuvoille viimeisen viikon ajalta, ryhmiteltynä yksikön mukaan." Tämä on kaluston vertailukysely, jota kunnossapidon suunnittelijat käyttävät poikkeavien alustojen tunnistamiseen. Se vaatii, että tunnisteindeksi luettelee tehokkaasti kaikki platform_type-suodatinta vastaavat sarjat ja aggregoi sitten kunkin. Tulos on yksi aikasarja yksikköä kohden – pieni määrä tulossarjoja kaluston koosta riippumatta, jos tunnisteskeema on oikea.

Derivaattakyselyt. "Mikä on tärinän amplitudin muutosnopeus VH-041:n vasemmanpuoleisessa moottorissa viimeisten 6 tunnin aikana?" Muutosnopeus on keskeinen piirre mekaanisten poikkeamien havaitsemisessa – tärinä- tai lämpötilasarjan derivaatan äkillinen kasvu edeltää usein komponenttivikaa tunneilla tai päivillä. Tämä syöttää suoraan viestijonoputkeen, joka toimittaa poikkeamatapahtumat kunnossapidon operaatiokeskukseen. Useimmat TSDB:t tukevat derivaattalaskentaa natiivifunktiona; ne, jotka eivät tue, vaativat sovellustason laskennan tiheän aikavälikyselyn tuloksen yli, mikä on toteutettavissa mutta lisää viivettä.

Integraatio laajempaan dataplatformiin

TSDB ei toimi eristyksissä. Puolustusdataplatformissa se on yksi komponentti putkessa, joka sisältää myös reunakeräimet, viestijonot reaaliaikaiseen tapahtumien reititykseen, datajärven pitkäaikaiseen monimuotoiseen tallennukseen sekä analytiikka- ja valvontakäyttöliittymät. TSDB:n ja näiden komponenttien välinen integraatiosopimus on määriteltävä eksplisiittisesti.

Loppupään kuluttajille, jotka tarvitsevat lähes reaaliaikaista telemetriaa – hälytysjärjestelmät, operatiiviset kojelaudat, fuusiomoottorit – suositeltu malli on, että reunakeräin julkaisee jokaisen erän sekä TSDB:hen (pysyvyyttä ja historiallista kyselyä varten) että viestijonon aiheeseen (matalan viiveen tapahtumien reititykseen kuluttajille). Tämä irrottaa TSDB:n reaaliaikaisesta toimituspolusta: kuluttajat saavat tapahtumat sekunneissa anturin kaappauksesta, ilman TSDB:n kyselyä, ja TSDB palvelee vain historiallisia ja aggregaatiokyselyitä, joihin sen tallennusasettelu on optimoitu.

Integraatiota varten puolustusdatajärven kanssa TSDB:n alasnäytteistystasot ovat oikea lähde: vie 1 minuutin aggregaattivedoksia Parquet- tai CSV-muodossa ajastetusti ja laske ne järven tallennusvyöhykkeelle. Raakadatan vieminen TSDB:stä järveen on tarpeetonta, jos reunakeräin kirjoittaa raakadatan jo molempiin kohteisiin – mutta TSDB pysyy auktoritatiivisena lähteenä aikavälikyselyille tuoreesta datasta, koska sen tallennusmuoto on suuruusluokkia nopeampi tälle mallille kuin järven objektitallennukseen perustuvat sarakemuotoiset tiedostot.