Længe forbi er de tider, hvor "databasen" var enkelt Relational Database Management System installeret typisk på den mest kraftfulde server i datacentret. En sådan database tjente alle slags anmodninger - OLTP, OLAP, alt hvad der kræves forretning. I dag kører databaser på råvarehardware, de er også mere sofistikerede med hensyn til den høje tilgængelighed og specialiserede til at håndtere en bestemt type trafik. Specialisering giver dem mulighed for at opnå meget bedre ydeevne - alt er optimeret til at håndtere en bestemt type data:optimering, lagermotor, selv sprog behøver ikke at være SQL, som det plejede at være tidligere. Det kan være SQL-baseret med nogle udvidelser, der giver mulighed for mere effektiv datamanipulation, eller det kan også være noget helt nyt, skabt fra bunden.
I dag har vi analytiske, søjleformede databaser som ClickHouse eller MariaDB AX, vi har store dataplatforme som Hadoop, NoSQL-løsninger som MongoDB eller Cassandra, datastores med nøgleværdier som Redis. Vi har også Time-Series-databaser som Prometheus eller TimeScaleDB. Det er det, vi vil fokusere på i dette blogindlæg. Time-Series databaser - hvad er de, og hvorfor du ønsker at bruge endnu et datalager i dit miljø.
Hvad er tidsseriedatabaser til?
Som navnet antyder, er tidsseriedatabaser designet til at gemme data, der ændrer sig med tiden. Dette kan være enhver form for data, som er blevet indsamlet over tid. Det kan være metrics indsamlet fra nogle systemer - alle trendsystemer er eksempler på tidsseriedata.
Når du ser på dashboards i ClusterControl, ser du faktisk på den visuelle repræsentation af tidsseriedata gemt i Prometheus, en tidsseriedatabase.
Tidsseriedata er ikke begrænset til databasemetrics. Alt kan være et mål. Hvordan strømmen af mennesker, der kommer ind i et indkøbscenter, ændrer sig over tid? Hvordan ændrer trafikken sig i en by? Hvordan ændrer brugen af den offentlige transport sig i løbet af dagen? Vandstrømmen i en å eller en flod. Mængden af energi genereret af et vandværk. Alt dette og alt det andet, der kan måles i tid, er et eksempel på tidsseriedata. Sådanne data kan du forespørge, plotte, analysere for at finde sammenhænge mellem forskellige metrics.
Hvordan er data struktureret i en tidsseriedatabase?
Som du kan forestille dig, er det vigtigste stykke data i tidsseriedatabasen tid. Der er to hovedmåder at gemme data på. For det første kan noget, der ligner nøgleværdilagring, se sådan ud:
Tidsstempel | Metric 1 |
---|---|
2019-03-28 00:00:01 | 2356 |
2019-03-28 00:00:02 | 6874 |
2019-03-28 00:00:03 | 3245 |
2019-03-28 00:00:04 | 2340 |
Kort sagt, for hvert tidsstempel har vi en vis værdi for vores metrik.
Et andet eksempel vil involvere flere målinger. I stedet for at gemme hver metrik i en separat tabel eller samling, er det muligt at gemme flere metrics ved siden af.
Tidsstempel | Metric 1 | Metric 2 | Metric 3 | Metric 4 | Metric 5 |
---|---|---|---|---|---|
2019-03-28 00:00:01 | 765 | 873 | 124 | 98 | 0 |
2019-03-28 00:00:02 | 5876 | 765 | 872 | 7864 | 634 |
2019-03-28 00:00:03 | 234 | 7679 | 98 | 65 | 34 |
2019-03-28 00:00:04 | 345 | 3 | 598 | 0 | 7345 |
Denne datastruktur hjælper med at forespørge dataene mere effektivt, når metrikken er relateret. I stedet for at læse flere tabeller og samle dem for at få alle metrikkerne sammen, er det nok at læse en enkelt tabel, og alle data er klar til at blive behandlet og præsenteret.
Du undrer dig måske - hvad er egentlig nyt her? Hvordan adskiller dette sig fra en almindelig tabel i MySQL eller en anden relationel database? Tja, borddesignet er ret ens, men der er betydelige forskelle i arbejdsbyrden, som, når et datalager er designet til at udnytte dem, kan forbedre ydeevnen betydeligt.
Tidsseriedata er typisk kun tilføjet - det er ret usandsynligt, at du opdaterer gamle data. Du sletter typisk ikke bestemte rækker, på den anden side vil du måske have en form for sammenlægning af data over tid. Dette, når det tages i betragtning ved design af databasens interne elementer, vil gøre en væsentlig forskel i forhold til "standard" relationelle (og ikke relationelle også) databaser, der er beregnet til at tjene online transaktionsbehandlingstype af trafik:det vigtigste er evnen til konsekvent at gemme (jngest) store mængder data, der kommer ind med tiden.
Det er muligt at bruge en RDBMS til at gemme tidsseriedata, men RDBMS er ikke optimeret til det. Data og indekser, der genereres på bagsiden af det, kan blive meget store og langsomme at forespørge. Lagermotorer, der bruges i RDBMS, er designet til at gemme en række forskellige datatyper. De er typisk optimeret til online-transaktionsbehandling, som omfatter hyppige dataændringer og sletninger. Relationelle databaser har også en tendens til at mangle specialiserede funktioner og funktioner relateret til behandling af tidsseriedata. Vi nævnte, at du sandsynligvis ønsker at aggregere data, der er ældre end en vis periode. Du vil måske også nemt kunne køre nogle statistiske funktioner på dine tidsseriedata for at udjævne dem, bestemme og sammenligne tendenser, interpolere data og mange flere. For eksempel kan du her finde nogle af de funktioner, Prometheus stiller til rådighed for brugerne.
Eksempler på tidsseriedatabaser
Der er flere eksisterende tidsseriedatabaser på markedet, så det er ikke muligt at dække dem alle. Vi vil stadig gerne give nogle eksempler på de tidsseriedatabaser, som du måske kender eller måske endda brugte (vidende eller ej).
InfluxDB
InfluxDB er blevet skabt af InfluxData. Det er en open source tidsseriedatabase skrevet i Go. Datalageret leverer SQL-lignende sprog til at forespørge dataene, hvilket gør det nemt for udviklerne at integrere i deres applikationer. InfluxDB fungerer også som en del af et kommercielt tilbud, som dækker hele stakken designet til at give et fuldt udstyret, yderst tilgængeligt miljø til behandling af tidsseriedata.
Prometheus
Prometheus er et andet open source-projekt, der også er skrevet i Go. Det bruges almindeligvis som backend til forskellige open source-værktøjer og -projekter, for eksempel Percona Monitoring and Management. Prometheus har også været en valgfri tidsseriedatabase for ClusterControl.
Prometheus kan implementeres fra ClusterControl til at blive brugt til at gemme tidsseriedata indsamlet på databaseservere, der overvåges og administreres af ClusterControl:
Prometheus bliver brugt meget i open source-verdenen og er ret nem at integrere i dit eksisterende miljø ved hjælp af flere eksportører.
RRD-værktøj
Dette kan være et eksempel på en tidsseriedatabase, som mange mennesker bruger uden at vide, at de gør det. RRDtool er et meget populært open source-projekt til lagring og visualisering af tidsseriedata. Hvis du nogensinde har brugt Cacti, var det baseret på RRDtool. Hvis du har designet din egen løsning, er det ret sandsynligt, at du også har brugt RRDtool som backend til at gemme dine data. I dag er det ikke så populært som det plejede at være, men tilbage i 2000 - 2010 var dette den mest almindelige måde at gemme tidsseriedata på. Sjov fakta - tidlige versioner af ClusterControl gjorde brug af det.
Tidsskala
TimeScale er en tidsseriedatabase udviklet oven på PostgreSQL. Det er en udvidelse på PostgreSQL, som er afhængig af det underliggende datalager for at give adgang til data, hvilket betyder, at det accepterer al den SQL, du måtte ønske at bruge. Da den er en udvidelse, bruger den alle de andre funktioner og udvidelser af PostgreSQL. Du kan blande tidsserier og andre typer data, for eksempel for at forbinde tidsserier og metadata, hvilket beriger outputtet. Du kan også lave mere avanceret filtrering ved at bruge JOINs og ikke-tidsserietabeller. Udnyttelse af GIS-understøttelse i PostgreSQL TimeScale kan nemt bruges til at spore geografiske placeringer over tid. Det kan også udnytte alle de skaleringsmuligheder, som PostgreSQL tilbyder, inklusive replikering.
Tidsstrøm
Amazon Web Services har også et tilbud til tidsseriedatabaser. Timestream er blevet annonceret for ganske nylig, i november 2018. Det tilføjer endnu et datalager til AWS-porteføljen, og denne gang hjælper det brugere med at håndtere tidsseriedata, der kommer fra kilder som Internet of Things-apparater eller overvågede tjenester. Det kan også bruges til at gemme metrics afledt af logfiler oprettet af flere tjenester, hvilket giver brugerne mulighed for at køre analytiske forespørgsler på dem, hvilket hjælper med at forstå mønstre og betingelser, som tjenester fungerer under.
Timestream, som de fleste AWS-tjenester, giver en nem måde at skalere på, hvis behovet for at lagre og analysere dataene vokser med tiden.
Som du kan se, er der mange muligheder på markedet, og det er ikke overraskende. Tidsseriedataanalyse er blevet mere og mere indpas på det seneste, det bliver mere og mere kritisk for forretningsdrift. Heldigvis, i betragtning af det store antal tilbud, både open source og kommercielle, er det ret sandsynligt, at du kan finde et værktøj, der passer til dine behov.