I løbet af de sidste par år er tidsseriedatabaser blevet fra en besynderlig ting (højt specialiseret brugt enten i åbne overvågningssystemer (og knyttet til specifikke løsninger) eller i Big Data-projekter) til et "forbrugerprodukt". På Den Russiske Føderations territorium skal der gives en særlig tak til Yandex og ClickHouse for dette. Indtil dette tidspunkt, hvis du havde brug for at gemme en stor mængde tidsseriedata, måtte du enten affinde dig med behovet for at bygge en monstrøs Hadoop-stack og vedligeholde den, eller kommunikere med protokoller, der er individuelle for hvert system.
Det kan se ud til, at en artikel om, hvilken TSDB er værd at bruge i 2019, kun vil bestå af én sætning: "brug bare ClickHouse." Men... der er nuancer.
ClickHouse er faktisk aktivt i udvikling, brugerbasen vokser, og supporten er meget aktiv, men er vi blevet gidsler for den offentlige succes med ClickHouse, som har overskygget andre, måske mere effektive/pålidelige løsninger?
I begyndelsen af sidste år begyndte vi at omarbejde vores eget overvågningssystem, hvor der opstod spørgsmålet om at vælge en passende database til lagring af data. Jeg vil gerne tale om historien bag dette valg her.
Formulering af problemet
Først og fremmest et nødvendigt forord. Hvorfor har vi overhovedet brug for vores eget overvågningssystem, og hvordan er det designet?
Vi begyndte at levere supporttjenester i 2008, og i 2010 blev det klart, at det blev vanskeligt at aggregere data om de processer, der foregår i klientinfrastrukturen med de løsninger, der eksisterede på det tidspunkt (vi taler om, Gud tilgive mig, Cacti, Zabbix og den nye grafit).
Vores vigtigste krav var:
- støtte (på det tidspunkt - snesevis og i fremtiden - hundredvis) af kunder inden for et system og samtidig tilstedeværelsen af et centraliseret alarmstyringssystem;
- fleksibilitet i styringen af varslingssystemet (eskalering af advarsler mellem vagtchefer, tidsplan, videnbase);
- evnen til dybt detaljerede grafer (Zabbix på det tidspunkt gengivet grafer i form af billeder);
- langtidslagring af en stor mængde data (et år eller mere) og mulighed for hurtigt at hente dem.
I denne artikel er vi interesserede i det sidste punkt.
Når vi taler om opbevaring, var kravene som følger:
- systemet skal fungere hurtigt;
- det er ønskeligt, at systemet har en SQL-grænseflade;
- systemet skal være stabilt og have en aktiv brugerbase og support (engang stod vi over for behovet for at understøtte systemer såsom MemcacheDB, som ikke længere var udviklet, eller MooseFS distribueret lager, hvis fejlsporing blev holdt på kinesisk: vi gentager denne historie for vores projekt ønskede ikke);
- overholdelse af CAP-sætningen: Konsistens (påkrævet) - dataene skal være opdaterede, vi ønsker ikke, at alarmstyringssystemet ikke modtager nye data og spytter advarsler ud om, at data ikke kommer til alle projekter; Partitionstolerance (påkrævet) - vi ønsker ikke at få et Split Brain-system; Tilgængelighed (ikke kritisk, hvis der er en aktiv replika) - vi kan selv skifte til backup-systemet i tilfælde af uheld ved hjælp af kode.
Mærkeligt nok viste MySQL sig på det tidspunkt at være den ideelle løsning for os. Vores datastruktur var ekstremt enkel: server-id, tæller-id, tidsstempel og værdi; hurtig sampling af varme data blev sikret af en stor bufferpool, og sampling af historiske data blev sikret af SSD.
Således opnåede vi en prøve af friske to-ugers data, med detaljer ned til en anden 200 ms, før dataene var fuldstændig gengivet, og levede i dette system i ret lang tid.
I mellemtiden gik tiden, og mængden af data voksede. I 2016 nåede datamængderne op på snesevis af terabyte, hvilket var en betydelig udgift i forbindelse med lejet SSD-lager.
På dette tidspunkt var søjledatabaser blevet aktivt udbredt, hvilket vi begyndte at tænke aktivt over: i søjlebaser lagres data, som du kan forstå, i kolonner, og hvis man ser på vores data, er det nemt at se en stor antal dubletter, der kunne, i Hvis du bruger en kolonneformet database, skal du komprimere den ved hjælp af komprimering.
Virksomhedens nøglesystem fortsatte dog med at fungere stabilt, og jeg ville ikke eksperimentere med at skifte til noget andet.
I 2017, på Percona Live-konferencen i San Jose, annoncerede Clickhouse-udviklere sandsynligvis sig selv for første gang. Ved første øjekast var systemet produktionsklar (godt, Yandex.Metrica er et barskt produktionssystem), support var hurtig og enkel, og vigtigst af alt var betjeningen enkel. Siden 2018 har vi startet overgangsprocessen. Men på det tidspunkt var der en masse "voksne" og tidstestede TSDB-systemer, og vi besluttede at bruge en del tid og sammenligne alternativer for at sikre, at der ikke var alternative løsninger til Clickhouse, i henhold til vores krav.
Ud over de allerede specificerede opbevaringskrav er der dukket nye op:
- det nye system skal give mindst samme ydeevne som MySQL på den samme mængde hardware;
- opbevaringen af det nye system skulle fylde væsentligt mindre;
- DBMS skal stadig være let at administrere;
- Jeg ønskede at ændre applikationen minimalt, når jeg ændrede DBMS.
Hvilke systemer begyndte vi at overveje?
Apache Hive/Apache Impala
En gammel, kamptestet Hadoop-stak. Grundlæggende er det en SQL-grænseflade bygget oven på lagring af data i native formater på HDFS.
Fordele.
- Med stabil drift er det meget nemt at skalere data.
- Der findes kolonneløsninger til datalagring (mindre plads).
- Meget hurtig udførelse af parallelle opgaver, når ressourcer er tilgængelige.
Ulemper.
- Det er Hadoop, og det er svært at bruge. Hvis vi ikke er klar til at tage en færdiglavet løsning i skyen (og vi er ikke klar med hensyn til omkostningerne), skal hele stakken samles og understøttes af administratorernes hænder, og vi vil virkelig ikke det her.
- Data er aggregeret .
dog:
Hastighed opnås ved at skalere antallet af computerservere. Kort sagt, hvis vi er en stor virksomhed, der beskæftiger os med analyser, og det er afgørende for virksomheden at aggregere information så hurtigt som muligt (selv på bekostning af at bruge en stor mængde computerressourcer), kan dette være vores valg. Men vi var ikke klar til at mangedoble hardwareflåden for at fremskynde opgaverne.
Druid/Pinot
Der er meget mere om TSDB specifikt, men igen, Hadoop-stakken.
Der er .
Med få ord: Druid/Pinot ser bedre ud end Clickhouse i tilfælde, hvor:
- Du har en heterogen karakter af data (i vores tilfælde registrerer vi kun tidsserier af servermetrikker, og i virkeligheden er dette én tabel. Men der kan være andre tilfælde: udstyrs tidsserier, økonomiske tidsserier osv. - hver med sin egen struktur, som skal aggregeres og bearbejdes).
- Desuden er der mange af disse data.
- Tabeller og data med tidsserier vises og forsvinder (det vil sige, at et sæt data ankom, blev analyseret og slettet).
- Der er ikke noget klart kriterium, efter hvilket data kan opdeles.
I modsatte tilfælde klarer ClickHouse sig bedre, og det er vores tilfælde.
klikhus
- SQL-lignende
- Nem at administrere.
- Folk siger, det virker.
Bliver nomineret til test.
TilstrømningDB
Et udenlandsk alternativ til ClickHouse. Af minusser: High Availability er kun til stede i den kommercielle version, men det skal sammenlignes.
Bliver nomineret til test.
Cassandra
På den ene side ved vi, at det bruges til at gemme metriske tidsserier af sådanne overvågningssystemer som f.eks. eller OkMeter. Der er dog specifikationer.
Cassandra er ikke en søjleformet database i traditionel forstand. Det ligner mere en rækkevisning, men hver linje kan have et forskelligt antal kolonner, hvilket gør det nemt at organisere en kolonnevisning. I denne forstand er det klart, at med en grænse på 2 milliarder kolonner er det muligt at gemme nogle data i kolonner (og samme tidsserier). For eksempel er der i MySQL en grænse på 4096 kolonner, og det er nemt at falde over en fejl med kode 1117, hvis du forsøger at gøre det samme.
Cassandra-motoren er fokuseret på at gemme store mængder data i et distribueret system uden en master, og den ovennævnte Cassandra CAP-sætning handler mere om AP, det vil sige om datatilgængelighed og modstand mod partitionering. Dette værktøj kan således være fantastisk, hvis du kun skal skrive til denne database og sjældent læser fra den. Og her er det logisk at bruge Cassandra som "kold" opbevaring. Det vil sige som et langsigtet, pålideligt sted at opbevare store mængder historiske data, der sjældent er nødvendige, men som kan hentes frem, hvis det er nødvendigt. Ikke desto mindre vil vi for fuldstændighedens skyld også teste det. Men, som jeg sagde tidligere, er der ikke noget ønske om aktivt at omskrive koden til den valgte databaseløsning, så vi vil teste den noget begrænset – uden at tilpasse databasestrukturen til Cassandras detaljer.
Prometheus
Nå, af nysgerrighed besluttede vi at teste ydeevnen af Prometheus-lagring - bare for at forstå, om vi er hurtigere eller langsommere end nuværende løsninger og med hvor meget.
Testmetode og resultater
Så vi testede 5 databaser i følgende 6 konfigurationer: ClickHouse (1 node), ClickHouse (fordelt tabel for 3 noder), InfluxDB, Mysql 8, Cassandra (3 noder) og Prometheus. Testplanen er som følger:
- upload historiske data for en uge (840 millioner værdier pr. dag; 208 tusinde målinger);
- vi genererer en registreringsbelastning (6 belastningstilstande blev overvejet, se nedenfor);
- Parallelt med optagelsen foretager vi med jævne mellemrum valg og efterligner anmodningerne fra en bruger, der arbejder med diagrammer. For ikke at komplicere tingene for meget, valgte vi data for 10 metrics (det er præcis, hvor mange der er på CPU-grafen) i en uge.
Vi indlæser ved at efterligne adfærden af vores overvågningsagent, som sender værdier til hver metrik en gang hvert 15. sekund. Samtidig er vi interesserede i at variere:
- det samlede antal målinger, som data er skrevet ind i;
- interval for at sende værdier til en metrik;
- batch størrelse.
Om batchstørrelsen. Da det ikke anbefales at indlæse næsten alle vores eksperimentelle databaser med enkelte inserts, skal vi bruge et relæ, der samler indgående metrics og grupperer dem i grupper og skriver dem til databasen som et batch-indsæt.
For bedre at forstå, hvordan man derefter fortolker de modtagne data, lad os forestille os, at vi ikke bare sender en masse metrics, men metrics er organiseret i servere - 125 metrics pr. server. Her er serveren simpelthen en virtuel enhed – bare for at forstå, at for eksempel 10000 metrics svarer til omkring 80 servere.
Og her, med alt dette i betragtning, er vores 6 database skriveindlæsningstilstande:
Der er to punkter her. For det første viste disse batchstørrelser sig for Cassandra at være for store, der brugte vi værdier på 50 eller 100. Og for det andet, da Prometheus arbejder strengt i pull-tilstand, dvs. den selv går og indsamler data fra metriske kilder (og endda pushgateway, på trods af navnet, ændrer ikke fundamentalt på situationen), de tilsvarende belastninger blev implementeret ved hjælp af en kombination af statiske konfigurationer.
Testresultaterne er som følger:
Hvad er værd at bemærke: fantastisk hurtige prøver fra Prometheus, frygtelig langsomme prøver fra Cassandra, uacceptabelt langsomme prøver fra InfluxDB; Med hensyn til optagehastighed vandt ClickHouse alle, og Prometheus deltager ikke i konkurrencen, fordi den laver selv indstik, og vi måler ikke noget.
Som følge heraf: ClickHouse og InfluxDB viste sig som de bedste, men en klynge fra Influx kan kun bygges på basis af Enterprise-versionen, som koster penge, mens ClickHouse ikke koster noget og er lavet i Rusland. Det er logisk, at valget i USA formentlig er til fordel for inInfluxDB, og i vores land er det til fordel for ClickHouse.
Kilde: www.habr.com