I løpet av de siste årene har tidsseriedatabaser blitt fra en merkelig ting (høyt spesialisert brukt enten i åpne overvåkingssystemer (og knyttet til spesifikke løsninger) eller i Big Data-prosjekter) til et "forbrukerprodukt". På den russiske føderasjonens territorium må en spesiell takk gis til Yandex og ClickHouse for dette. Frem til dette tidspunktet, hvis du trengte å lagre en stor mengde tidsseriedata, måtte du enten innse behovet for å bygge en monstrøs Hadoop-stack og vedlikeholde den, eller kommunisere med individuelle protokoller for hvert system.
Det kan se ut til at en artikkel om hvilken TSDB er verdt å bruke i 2019 bare vil bestå av én setning: "bare bruk ClickHouse." Men... det er nyanser.
Faktisk utvikler ClickHouse aktivt, brukerbasen vokser, og støtten er veldig aktiv, men har vi blitt gisler for den offentlige suksessen til ClickHouse, som har overskygget andre, kanskje mer effektive/pålitelige løsninger?
I begynnelsen av fjoråret begynte vi å omarbeide vårt eget overvåkingssystem, der spørsmålet dukket opp om å velge en passende database for lagring av data. Jeg vil snakke om historien til dette valget her.
Formulering av problemet
Først og fremst et nødvendig forord. Hvorfor trenger vi i det hele tatt vårt eget overvåkingssystem og hvordan ble det utformet?
Vi begynte å tilby støttetjenester i 2008, og i 2010 ble det klart at det ble vanskelig å samle data om prosessene som skjer i klientinfrastrukturen med løsningene som eksisterte på den tiden (vi snakker om, Gud tilgi meg, Cacti, Zabbix og den nye grafitten).
Våre hovedkrav var:
- støtte (på den tiden - dusinvis, og i fremtiden - hundrevis) av klienter i ett system og samtidig tilstedeværelsen av et sentralisert varslingsstyringssystem;
- fleksibilitet i styring av varslingssystemet (eskalering av varsler mellom vaktledere, planlegging, kunnskapsbase);
- evnen til dypt detaljerte grafer (Zabbix på den tiden gjengitt grafer i form av bilder);
- langsiktig lagring av en stor mengde data (et år eller mer) og muligheten til å raskt hente den.
I denne artikkelen er vi interessert i det siste punktet.
Når vi snakker om lagring, var kravene som følger:
- systemet må fungere raskt;
- det er ønskelig at systemet har et SQL-grensesnitt;
- systemet må være stabilt og ha en aktiv brukerbase og støtte (en gang ble vi møtt med behovet for å støtte systemer som MemcacheDB, som ikke lenger ble utviklet, eller MooseFS-distribuert lagring, hvis feilsporing ble holdt på kinesisk: vi gjentar denne historien for prosjektet vårt ikke ønsket);
- samsvar med CAP-teoremet: Consitency (påkrevd) - dataene må være oppdaterte, vi ønsker ikke at varslingsstyringssystemet ikke mottar nye data og spytter ut varsler om manglende data for alle prosjekter; Partisjonstoleranse (påkrevd) - vi ønsker ikke å få et Split Brain-system; Tilgjengelighet (ikke kritisk, hvis det er en aktiv replika) - vi kan selv bytte til backup-systemet i tilfelle en ulykke, ved hjelp av kode.
Merkelig nok, på den tiden viste MySQL seg å være den ideelle løsningen for oss. Datastrukturen vår var ekstremt enkel: server-id, teller-id, tidsstempel og verdi; rask sampling av varme data ble sikret av en stor bufferpool, og sampling av historiske data ble sikret av SSD.
Dermed oppnådde vi et utvalg av ferske to-ukers data, med detaljer ned til en sekund 200 ms før dataene ble fullstendig gjengitt, og levde i dette systemet i ganske lang tid.
I mellomtiden gikk tiden og datamengden vokste. I 2016 nådde datavolumene titalls terabyte, noe som var en betydelig utgift i sammenheng med leid SSD-lagring.
På dette tidspunktet hadde kolonnedatabaser blitt aktivt utbredt, noe vi begynte å tenke aktivt på: i kolonneformede databaser lagres data, som du kan forstå, i kolonner, og hvis du ser på dataene våre, er det lett å se en stor antall duplikater som kan, i Hvis du bruker en kolonneformet database, komprimere den ved hjelp av komprimering.
Imidlertid fortsatte selskapets nøkkelsystem å fungere stabilt, og jeg ønsket ikke å eksperimentere med å bytte til noe annet.
I 2017, på Percona Live-konferansen i San Jose, kunngjorde Clickhouse-utviklere seg sannsynligvis for første gang. Ved første øyekast var systemet produksjonsklart (vel, Yandex.Metrica er et tøft produksjonssystem), støtten var rask og enkel, og viktigst av alt, operasjonen var enkel. Siden 2018 har vi startet overgangsprosessen. Men på den tiden var det mange "voksne" og tidstestede TSDB-systemer, og vi bestemte oss for å bruke mye tid og sammenligne alternativer for å sikre at det ikke fantes alternative løsninger til Clickhouse, i henhold til våre krav.
I tillegg til de allerede spesifiserte lagringskravene, har nye dukket opp:
- det nye systemet skal gi minst samme ytelse som MySQL på samme mengde maskinvare;
- lagringen av det nye systemet bør ta betydelig mindre plass;
- DBMS må fortsatt være enkelt å administrere;
- Jeg ønsket å endre applikasjonen minimalt når jeg endret DBMS.
Hvilke systemer begynte vi å vurdere?
Apache Hive/Apache Impala
En gammel, kamptestet Hadoop-stabel. I hovedsak er det et SQL-grensesnitt bygget på toppen av lagring av data i opprinnelige formater på HDFS.
Pros.
- Med stabil drift er det veldig enkelt å skalere data.
- Det finnes kolonneløsninger for datalagring (mindre plass).
- Meget rask utførelse av parallelle oppgaver når ressurser er tilgjengelige.
Cons.
- Det er Hadoop, og det er vanskelig å bruke. Hvis vi ikke er klare til å ta en ferdig løsning i skyen (og vi ikke er klare kostnadsmessig), må hele stabelen settes sammen og støttes av administratorens hender, og vi vil egentlig ikke dette.
- Data er aggregert .
Men:
Hastighet oppnås ved å skalere antall dataservere. Enkelt sagt, hvis vi er et stort selskap, engasjert i analyser, og det er avgjørende for virksomheten å samle informasjon så raskt som mulig (selv på bekostning av å bruke en stor mengde dataressurser), kan dette være vårt valg. Men vi var ikke klare til å multiplisere maskinvareflåten for å få fart på oppgavene.
Druid/Pinot
Det er mye mer spesifikt om TSDB, men igjen, Hadoop-stakken.
Det er .
Med noen få ord: Druid/Pinot ser bedre ut enn Clickhouse i tilfeller der:
- Du har en heterogen natur av data (i vårt tilfelle registrerer vi bare tidsserier med servermålinger, og dette er faktisk én tabell. Men det kan være andre tilfeller: utstyrstidsserier, økonomiske tidsserier osv. - hver med sin egen struktur, som må aggregeres og behandles).
- Dessuten er det mye av disse dataene.
- Tabeller og data med tidsserier vises og forsvinner (det vil si at et sett med data ankom, ble analysert og slettet).
- Det er ikke noe klart kriterium for hvordan data kan partisjoneres.
I motsatte tilfeller presterer ClickHouse bedre, og dette er vårt tilfelle.
ClickHouse
- SQL-lignende
- Enkel å administrere.
- Folk sier det fungerer.
Blir nominert for testing.
TilstrømningDB
Et utenlandsk alternativ til ClickHouse. Av minusene: Høy tilgjengelighet er kun til stede i den kommersielle versjonen, men den må sammenlignes.
Blir nominert for testing.
Cassandra
På den ene siden vet vi at den brukes til å lagre metriske tidsserier av slike overvåkingssystemer som f.eks. eller OkMeter. Det er imidlertid detaljer.
Cassandra er ikke en kolonneformet database i tradisjonell forstand. Det ser mer ut som en radvisning, men hver linje kan ha et annet antall kolonner, noe som gjør det enkelt å organisere en kolonnevisning. Slik sett er det klart at med en grense på 2 milliarder kolonner er det mulig å lagre noen data i kolonner (og samme tidsserier). For eksempel, i MySQL er det en grense på 4096 kolonner og det er lett å snuble over en feil med kode 1117 hvis du prøver å gjøre det samme.
Cassandra-motoren er fokusert på å lagre store mengder data i et distribuert system uten en master, og det ovenfor nevnte Cassandra CAP-teoremet handler mer om AP, det vil si om datatilgjengelighet og motstand mot partisjonering. Dermed kan dette verktøyet være flott hvis du bare trenger å skrive til denne databasen og sjelden leser fra den. Og her er det logisk å bruke Cassandra som "kald" lagring. Det vil si som et langsiktig, pålitelig sted å lagre store mengder historiske data som sjelden trengs, men som kan hentes frem om nødvendig. For fullstendighetens skyld vil vi likevel teste det også. Men, som jeg sa tidligere, er det ikke noe ønske om å aktivt omskrive koden for den valgte databaseløsningen, så vi vil teste den noe begrenset – uten å tilpasse databasestrukturen til Cassandras spesifikasjoner.
Prometheus
Vel, av nysgjerrighet bestemte vi oss for å teste ytelsen til Prometheus-lagring – bare for å forstå om vi er raskere eller tregere enn dagens løsninger og med hvor mye.
Testmetodikk og resultater
Så vi testet 5 databaser i følgende 6 konfigurasjoner: ClickHouse (1 node), ClickHouse (distribuert tabell for 3 noder), InfluxDB, Mysql 8, Cassandra (3 noder) og Prometheus. Testplanen er som følger:
- last opp historiske data for en uke (840 millioner verdier per dag; 208 tusen beregninger);
- vi genererer en opptaksbelastning (6 belastningsmoduser ble vurdert, se nedenfor);
- Parallelt med opptak gjør vi med jevne mellomrom valg, etterligner forespørslene fra en bruker som arbeider med diagrammer. For ikke å komplisere ting for mye, valgte vi data for 10 beregninger (det er nøyaktig hvor mange det er på CPU-grafen) for en uke.
Vi laster inn ved å emulere oppførselen til overvåkingsagenten vår, som sender verdier til hver beregning en gang hvert 15. sekund. Samtidig er vi interessert i å variere:
- det totale antallet beregninger som data er skrevet inn i;
- intervall for å sende verdier til en beregning;
- Partistørrelse, Gruppestørrelse.
Om batchstørrelsen. Siden det ikke anbefales å laste nesten alle våre eksperimentelle databaser med enkeltinnlegg, vil vi trenge et relé som samler inn innkommende metrikker og grupperer dem i grupper og skriver dem til databasen som et batchinnlegg.
For bedre å forstå hvordan vi deretter tolker de mottatte dataene, la oss forestille oss at vi ikke bare sender en haug med beregninger, men beregningene er organisert i servere - 125 beregninger per server. Her er serveren rett og slett en virtuell enhet - bare for å forstå at for eksempel 10000 80 metrikker tilsvarer omtrent XNUMX servere.
Og her, med alt dette i betraktning, er våre 6 databaseskrivelastmoduser:
Det er to punkter her. For det første, for Cassandra viste disse batchstørrelsene seg å være for store, der brukte vi verdier på 50 eller 100. Og for det andre, siden Prometheus arbeider strengt i pull-modus, dvs. den selv går og samler inn data fra metriske kilder (og til og med pushgateway, til tross for navnet, endrer ikke situasjonen fundamentalt), de tilsvarende belastningene ble implementert ved hjelp av en kombinasjon av statiske konfigurasjoner.
Testresultatene er som følger:
Hva er verdt å merke seg: fantastisk raske prøver fra Prometheus, fryktelig langsomme prøver fra Cassandra, uakseptabelt langsomme prøver fra InfluxDB; Når det gjelder opptakshastighet, vant ClickHouse alle, og Prometheus deltar ikke i konkurransen, fordi den lager innlegg i seg selv og vi måler ingenting.
Som et resultat,: ClickHouse og InfluxDB viste seg å være best, men en klynge fra Influx kan kun bygges på grunnlag av Enterprise-versjonen, som koster penger, mens ClickHouse ikke koster noe og er laget i Russland. Det er logisk at i USA er valget sannsynligvis til fordel for inFluxDB, og i vårt land er det til fordel for ClickHouse.
Kilde: www.habr.com