Länge borta är de tider då "databasen" var enstaka Relational Database Management System installerat vanligtvis på den mest kraftfulla servern i datacentret. En sådan databas serverade alla typer av förfrågningar - OLTP, OLAP, allt som krävdes för affärer. Nuförtiden körs databaser på råvaruhårdvara, de är också mer sofistikerade när det gäller den höga tillgängligheten och specialiserade för att hantera speciell typ av trafik. Specialisering tillåter dem att uppnå mycket bättre prestanda - allt är optimerat för att hantera en viss typ av data:optimerare, lagringsmotor, till och med språk behöver inte vara SQL, som det brukade vara förr. Det kan vara SQL-baserat med vissa tillägg som möjliggör effektivare datamanipulation, eller så kan det också vara något helt nytt, skapat från grunden.
Idag har vi analytiska, kolumnära databaser som ClickHouse eller MariaDB AX, vi har stora dataplattformar som Hadoop, NoSQL-lösningar som MongoDB eller Cassandra, nyckelvärdesdatabutiker som Redis. Vi har också tidsseriedatabaser som Prometheus eller TimeScaleDB. Det är detta vi kommer att fokusera på i det här blogginlägget. Time-Series-databaser - vad är de och varför du skulle vilja använda ännu en datalagring i din miljö.
Vad är tidsseriedatabaser till för?
Som namnet antyder är tidsseriedatabaser utformade för att lagra data som förändras med tiden. Detta kan vara vilken typ av data som helst som har samlats in över tid. Det kan vara mätvärden som samlats in från vissa system - alla trendsystem är exempel på tidsseriedata.
När du tittar på instrumentpanelerna i ClusterControl, tittar du faktiskt på den visuella representationen av tidsseriedata som lagras i Prometheus, en tidsseriedatabas.
Tidsseriedata är inte begränsad till databasmått. Allt kan vara ett mått. Hur flödet av människor som kommer in i en galleria förändras över tiden? Hur förändras trafiken i en stad? Hur förändras användningen av kollektivtrafiken under dagen? Vattenflöde i en bäck eller en flod. Mängd energi som genereras av en vattenanläggning. Allt detta och allt annat som kan mätas i tid är ett exempel på tidsseriedata. Sådan data kan du söka efter, plotta, analysera för att hitta korrelationer mellan olika mätvärden.
Hur är data strukturerad i en tidsseriedatabas?
Som du kan föreställa dig är den viktigaste delen av data i tidsseriedatabasen tid. Det finns två huvudsakliga sätt att lagra data. För det första kan något som liknar nyckel-värdelagring se ut så här:
Tidsstämpel | Mätvärde 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, för varje tidsstämpel har vi ett visst värde för vårt mått.
Ett annat exempel kommer att involvera fler mätvärden. Istället för att lagra varje mätvärde i en separat tabell eller samling, är det möjligt att lagra flera mätvärden bredvid.
Tidsstämpel | Mätvärde 1 | Mätvärde 2 | Mätvärde 3 | Mätvärde 4 | Mätvärde 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 |
Denna datastruktur hjälper till att söka efter data mer effektivt när mätvärdena är relaterade. Istället för att läsa flera tabeller och sammanfoga dem för att få ihop alla mätvärden, räcker det att läsa en enda tabell och all data är redo att bearbetas och presenteras.
Du kanske undrar - vad är egentligen nytt här? Hur skiljer sig detta från en vanlig tabell i MySQL eller annan relationsdatabas? Tja, tabelldesignen är ganska lik men det finns betydande skillnader i arbetsbelastningen som, när en databutik är designad för att utnyttja dem, kan förbättra prestandan avsevärt.
Tidsseriedata läggs vanligtvis bara till - det är ganska osannolikt att du kommer att uppdatera gamla data. Du tar vanligtvis inte bort vissa rader, å andra sidan kanske du vill ha någon form av aggregering av data över tiden. Detta, när det tas med i beräkningen vid utformningen av databasens interna delar, kommer att göra en betydande skillnad jämfört med "standard" relationsdatabaser (och inte heller relationella) databaser som är avsedda att betjäna trafik av typen onlinetransaktionsbearbetning:det viktigaste är förmågan att konsekvent lagra (jngest) stora mängder data som kommer in med tiden.
Det är möjligt att använda ett RDBMS för att lagra tidsseriedata, men RDBMS är inte optimerat för det. Data och index som genereras på baksidan av den kan bli mycket stora och långsamma att fråga. Lagringsmotorer som används i RDBMS är designade för att lagra en mängd olika datatyper. De är vanligtvis optimerade för arbetsbelastningen för onlinetransaktionsbearbetning som inkluderar frekventa dataändringar och radering. Relationsdatabaser tenderar också att sakna specialiserade funktioner och funktioner relaterade till bearbetning av tidsseriedata. Vi nämnde att du förmodligen vill samla data som är äldre än en viss tidsperiod. Du kanske också vill enkelt kunna köra vissa statistiska funktioner på dina tidsseriedata för att jämna ut det, fastställa och jämföra trender, interpolera data och mycket mer. Här kan du till exempel hitta några av de funktioner som Prometheus gör tillgängliga för användarna.
Exempel på tidsseriedatabaser
Det finns flera befintliga tidsseriedatabaser på marknaden så det är inte möjligt att täcka alla. Vi skulle ändå vilja ge några exempel på tidsseriedatabaser som du kanske känner till eller kanske till och med använder (medvetet eller inte).
InfluxDB
InfluxDB har skapats av InfluxData. Det är en tidsseriedatabas med öppen källkod skriven i Go. Datalagret tillhandahåller ett SQL-liknande språk för att söka efter data, vilket gör det enkelt för utvecklarna att integrera i sina applikationer. InfluxDB fungerar också som en del av ett kommersiellt erbjudande, som täcker hela stacken utformad för att tillhandahålla en fullfjädrad, mycket tillgänglig miljö för bearbetning av tidsseriedata.
Prometheus
Prometheus är ett annat projekt med öppen källkod som också är skrivet i Go. Det används ofta som backend för olika verktyg och projekt med öppen källkod, till exempel Percona Monitoring and Management. Prometheus har också varit en valfri tidsseriedatabas för ClusterControl.
Prometheus kan distribueras från ClusterControl för att användas för att lagra tidsseriedata som samlats in på databasservrarna som övervakas och hanteras av ClusterControl:
Prometheus används flitigt i världen med öppen källkod och är ganska lätt att integrera i din befintliga miljö med hjälp av flera exportörer.
RRD-verktyg
Detta kan vara ett exempel på en tidsseriedatabas som många människor använder utan att veta att de gör det. RRDtool är ett mycket populärt projekt med öppen källkod för att lagra och visualisera tidsseriedata. Om du någonsin använt Cacti så var den baserad på RRDtool. Om du designade din egen lösning är det ganska troligt att du också använde RRDtool som backend för att lagra dina data. Nuförtiden är det inte lika populärt som det brukade vara men tillbaka 2000 - 2010 var detta det vanligaste sättet att lagra tidsseriedata. Kul fakta - tidiga versioner av ClusterControl använde det.
Tidsskala
TimeScale är en tidsseriedatabas utvecklad ovanpå PostgreSQL. Det är en förlängning på PostgreSQL, som förlitar sig på den underliggande datalagringen för att ge tillgång till data, vilket innebär att den accepterar all SQL du kanske vill använda. Eftersom den är en förlängning använder den alla andra funktioner och tillägg av PostgreSQL. Du kan blanda tidsserier och andra typer av data, till exempel för att sammanfoga tidsserier och metadata, vilket berikar resultatet. Du kan också göra mer avancerad filtrering med JOINs och icke-tidsserietabeller. Att utnyttja GIS-stöd i PostgreSQL TimeScale kan enkelt användas för att spåra geografiska platser över tid. Det kan också utnyttja alla skalningsmöjligheter som PostgreSQL erbjuder, inklusive replikering.
Tidsström
Amazon Web Services har också ett erbjudande för tidsseriedatabaser. Timestream har tillkännagivits ganska nyligen, i november 2018. Den lägger till ytterligare en databutik till AWS-portföljen, den här gången hjälper användarna att hantera tidsseriedata som kommer från källor som Internet of Things-apparater eller övervakade tjänster. Den kan också användas för att lagra mätvärden som härrör från loggar som skapats av flera tjänster, vilket gör det möjligt för användare att köra analytiska frågor på dem, vilket hjälper till att förstå mönster och förhållanden under vilka tjänster fungerar.
Timestream, som de flesta AWS-tjänster, tillhandahåller ett enkelt sätt att skala om behovet av att lagra och analysera data växer med tiden.
Som du kan se finns det många alternativ på marknaden och det är inte förvånande. Tidsseriedataanalys har fått mer och mer dragkraft den senaste tiden, den blir mer och mer kritisk för affärsverksamheten. Lyckligtvis, med tanke på det stora antalet erbjudanden, både öppen källkod och kommersiella, är det ganska troligt att du kan hitta ett verktyg som passar dina behov.