Een primer op tijdreeksgegevens, en waarom u geen “normale” database wilt gebruiken om deze op te slaan.
Hier is een raadsel: wat hebben zelfrijdende Teslas, autonome Wall Street handelsalgoritmen, slimme huizen, transportnetwerken die razendsnelle leveringen op dezelfde dag vervullen en een open-data-publishing NYPD met elkaar gemeen?
Ten eerste zijn het tekenen dat onze wereld aan het veranderen is met warpsnelheid, vanwege ons vermogen om steeds meer data op een snellere manier vast te leggen en te analyseren dan voorheen.
Als u echter goed kijkt, zult u merken dat elk van die toepassingen een speciale, vrij grote hoeveelheid gegevens vereist:
Zelfrijdende auto’s verzamelen voortdurend gegevens over hoe hun lokale omgeving verandert.
Autonome handelsalgoritmen verzamelen continu gegevens over hoe de markten veranderen.
Onze slimme huizen houden in de gaten wat er in hen gebeurt om de temperatuur te beheersen, indringers te identificeren en onze wenken te beantwoorden (“Alexa, speel wat ontspannende muziek”).
Onze detailhandel houdt in de gaten hoe hun activa zich bewegen met zo’n precisie en efficiëntie dat goedkope levering op dezelfde dag een luxe kan zijn die door veel mensen als vanzelfsprekend wordt beschouwd.
De NYPD volgt zijn voertuigen om ons toe te laten ze meer verantwoordingsplichtig te dragen (bijvoorbeeld voor het analyseren van 911 reactietijden).
Deze toepassingen geloven een soort van gegevens die meten hoe dingen veranderen in de loop van de tijd. Waar tijd niet alleen een metrische, maar ook een primaire as is. Dit is vaak tijdreeksgegevens en het begint een grotere rol te spelen in onze wereld.
Gebruikspatronen van softwareontwikkelaars weerspiegelen dit al. Sterker nog, in de afgelopen 24 maanden zijn tijdreeksendatabases (TSDB’s) gestaag de snelst groeiende categorie van databases gebleven:
Wat zijn tijdreeksgegevens?
Sommigen beschouwen “tijdreeksgegevens” als een opeenvolging van kennispunten, waarbij een equivalent in de tijd wordt gemeten, opgeslagen in tijdsvolgorde. Dat is waar, maar het is gewoon een krasje op het oppervlak.
Anderen kunnen zich een reeks numerieke waarden voorstellen, elk gekoppeld aan een tijdstempel, gedefinieerd door een reputatie en een groep gelabelde afmetingen (of “tags”). Dit is misschien wel een methode om tijdreeksgegevens te modelleren, maar niet een definitie van de informatie zelf.
Hier is een basisillustratie. Stel je voor dat sensoren gegevens verzamelen van drie instellingen: een stad, een boerderij en een fabriek. tijdens dit voorbeeld stuurt elk van deze bronnen periodiek nieuwe metingen, waardoor een reeks van metingen die in de loop van de tijd worden verzameld, wordt gecreëerd.
Hier is een ander voorbeeld, met echte gegevens van de stad York, die taxicabattracties tonen voor de eerste paar seconden van 2018. Zoals u zult zien, kan elke rij een “meting” zijn die op een geselecteerd tijdstip is verzameld:
Er zijn vele andere vormen van tijdreeksgegevens. Om er een paar te noemen: DevOps monitoring data, mobile/web applicatie event streams, industriële machine data, wetenschappelijke metingen.
Deze datasets hebben vooral 3 dingen gemeen:
De data die binnenkomt wordt bijna altijd geregistreerd als een vervangende invoer
De gegevens komen meestal op tijd aan
Tijd kan een primaire as zijn (tijdsintervallen zijn vaak regelmatig of onregelmatig)
Met andere woorden, time-series data workloads zijn over het algemeen “append-only”. Hoewel ze foutieve gegevens moeten corrigeren na het feit, of vertraagde of buiten de orde zijnde gegevens moeten verwerken, zijn dit uitzonderingen, niet de norm.
U kunt zich afvragen: Hoe is dat anders dan het hebben van een tijdveld tijdens een dataset? Wel, het hangt ervan af: hoe verandert uw dataset track? Door de huidige invoer bij te werken, of door een vervangende invoer in te voegen?
Wanneer u een vervangende meting voor sensor_x verzamelt, overschrijft men dan uw vorige meting, of maakt men een nieuwe meting aan tijdens een aparte rij? Beide methoden geven u de huidige status van het systeem, maar alleen door de nieuwe meting in een aparte rij te schrijven bent u klaar om alle toestanden van het systeem in de loop van de tijd bij te houden.
Simpel gezegd: time-series datasets volgen veranderingen in het algemene systeem als INSERTs, niet UPDATEs.
Deze praktijk van het registreren van elke verandering in het systeem als een vervanging , verschillende rij is wat de time-series data zo krachtig maakt. Het stelt ons in staat om verandering te leven: analyseren hoe iets veranderde in het verleden, monitoren hoe iets verandert in het heden, voorspellen hoe het gaat veranderen in de toekomst.
Simpel gezegd, hier is hoe ik het liefst tijdreeksgegevens definieer: gegevens die collectief weergeven hoe een systeem/proces/gedrag in de loop van de tijd verandert.
Dit is gewoon een tutorial onderscheid. Door onze definitie te centreren rond “verandering”, zullen we beginnen met het opsporen van tijdreeksen datasets die we vandaag niet verzamelen, maar die we altijd zouden moeten verzamelen in de toekomst. In feite hebben mensen vaak wel tijdreeksgegevens, maar weten ze die niet.
Stel je voor dat je een internetapplicatie onderhoudt. Wanneer een gebruiker inlogt, zal je gewoon een “last_login” tijdstempel voor die gebruiker updaten tijdens een enkele rij in je “gebruikers” tabel. Maar wat als je elke login als een aparte gebeurtenis behandeld en in de loop van de tijd opgepikt hebt? Dan zou u: historische login activiteit kunnen bijhouden, zien hoe het gebruik (in-/de-)kreukelt in de loop van de tijd, bucket gebruikers door hoe vaak ze toegang hebben tot de app, en nog veel meer.
Dit voorbeeld illustreert een belangrijk punt: door de inherente tijdreeksen van onze gegevens te bewaren, zijn we bereid om waardevolle informatie te bewaren over hoe die gegevens in de loop van de tijd veranderen. Een ander punt: gebeurtenisgegevens zijn extra tijdreeksgegevens.
Het opslaan van gegevens bij deze resolutie brengt natuurlijk een duidelijk probleem met zich mee: je eindigt met tonnen kennis, vrij snel. Dat is dus het addertje onder het gras: tijdreeksgegevens stapelen zich zeer snel op.
Het hebben van tonnen kennis levert problemen op bij zowel het opnemen ervan als het opvragen ervan tijdens een performante manier, vandaar dat men zich nu tot de tijdreeksendatabases wendt.
Waarom wil ik een tijdreeksendatabase?
U kunt zich afvragen: Waarom kan ik niet gewoon een “normale” (d.w.z. niet-tijdseries) database gebruiken?
De waarheid is dat je dat gewoon kan, en een paar mensen doen dat ook. Maar waarom zijn TSDB’s vandaag de dag de snelst groeiende categorie van databases? Twee redenen: (1) schaal en (2) bruikbaarheid.
Schaal: Tijdseriegegevens stapelen zich zeer snel op. (Bijvoorbeeld, één aangesloten auto verzamelt 4.000 GB aan kennis per dag.) En normale databases zijn niet ontworpen om met die schaal om te gaan. Relationele databases doen het slecht met zeer grote datasets; NoSQL-databases doen het beter op schaal, maar kunnen nog steeds worden overtroffen door een database die is afgestemd op tijdreeksgegevens. Tijdseries-databases (die vaak worden ondersteund door relationele of NoSQL-databases) gaan daarentegen wel om met schaalvergroting door de introductie van efficiëntie die alleen mogelijk is als u de tijd als een primaire klasse burger behandelt. Deze efficiënties eindigen in prestatieverbeteringen, inclusief hogere ingest rates, snellere queries op schaal (hoewel sommige meer queries ondersteunen dan andere), en betere datacompressie.
Bruikbaarheid: TSDB’s bevatten doorgaans ook functies en bewerkingen die gemeenschappelijk zijn voor de analyse van tijdreeksgegevens, zoals het retentiebeleid voor gegevens, continue query’s, flexibele tijdaggregaties, enz. Hoewel het niet direct een prioriteit is (bijvoorbeeld als u net begint met het verzamelen van gegevens), kunnen deze functies nog steeds een veel betere gebruikerservaring bieden en uw leven gemakkelijker maken.
Dit is de reden waarom ontwikkelaars steeds vaker databases met tijdreeksen gebruiken en deze gebruiken voor een spreiding van use cases:
Monitoring van softwaresystemen: Virtuele machines, containers, diensten, applicaties
Bewaking van fysieke systemen: Apparatuur, machines, aangesloten apparaten, het milieu, onze huizen, ons lichaam
Toepassingen voor het traceren van activa: Voertuigen, vrachtwagens, fysieke containers, pallets
Financiële handelssystemen: Klassieke effecten, nieuwere cryptocurrencies
Eventing toepassingen: Volgen van de interactiegegevens tussen gebruiker en klant
Business intelligence tools: Het bijhouden van de belangrijkste statistieken en dus de algemene gezondheid van het bedrijf
(en meer)
Zelfs dan moet u een tijdreeksendatabase kiezen die het beste past bij uw datamodel en uw schrijf-/leespatronen.
Een afscheidsgedachte: Is alle data tijdreeksgegevens?
De afgelopen tien jaar hebben we ongeveer in het tijdperk van “Big Data” geleefd, waarbij we enorme hoeveelheden gegevens over onze wereld hebben verzameld en rekenhulpmiddelen hebben toegepast om er gevoel voor te krijgen.
Hoewel dit tijdperk begon met bescheiden computertechnologie, is ons vermogen om gegevens vast te leggen, op te slaan en te analyseren in een exponentieel tempo verbeterd, vanwege de grote macro-trends: Moore’s wet, Kryder’s wet, cloud computing, een hele industrie van “big data” technologieën.
Nu willen we meer. We zijn niet langer tevreden met het observeren van de toestand van de planeet, maar we willen nu leven hoe onze wereld in de loop van de tijd verandert, tot in subseconde-intervallen. Onze “big data” datasets worden nu in het nauw gedreven door een ander soort data, een die sterk afhankelijk is van de tijd om informatie te bewaren over de verandering die zich voordoet.
Beginnen alle gegevens als tijdreeksgegevens? Denk aan het snellere voorbeeld van een webapplicatie: we hadden tijdreeksgegevens, maar wisten het niet. Of denk aan een “normale” dataset. Zeg, de huidige rekeningen en saldi bij een serieuze retail bank. Of het ASCII-tekstbestand voor een softwareproject. Of de tekst voor deze tekst .
Meestal kiezen we ervoor om de nieuwste stand van het systeem op te slaan, maar wat als we elke verandering opslaan en de nieuwste stand op het moment van opvragen berekenen? Is een “normale” dataset niet gewoon een weergave bovenop een inherente tijdreeks dataset (cache voor prestatie-redenen)? Hebben banken geen transactieregisters? (En zijn blockchains niet gewoon gedistribueerde, onveranderlijke tijdreeks logs?) Zou een softwareproject geen versiebeheer hebben (b.v. git commits)? Heeft deze tekst geen revisiegeschiedenis? Ongedaan maken. Opnieuw maken.
Anders gezegd: Hebben niet alle databases logs?
We erkennen dat veel applicaties nooit tijdreeksgegevens nodig hebben (en zouden beter gediend zijn met een “current state view”). Maar als we verder gaan met de grafiek van de technologische vooruitgang, lijkt het erop dat deze “current state views” zijn verdwenen. Door steeds meer gegevens in de vorm van tijdreeksen op te slaan, zouden we deze ook beter kunnen leren kennen.