Under de senaste åren har tidsseriedatabaser förvandlats från en besynnerlig sak (mycket specialiserad som används antingen i öppna övervakningssystem (och kopplade till specifika lösningar) eller i Big Data-projekt) till en "konsumentprodukt". På Ryska federationens territorium måste ett särskilt tack ges till Yandex och ClickHouse för detta. Fram till denna punkt, om du behövde lagra en stor mängd tidsseriedata, var du antingen tvungen att förlika dig med behovet av att bygga en monstruös Hadoop-stack och underhålla den, eller kommunicera med individuella protokoll för varje system.
Det kan tyckas att en artikel om vilken TSDB är värd att använda under 2019 bara kommer att bestå av en mening: "använd bara ClickHouse." Men... det finns nyanser.
Visserligen utvecklas ClickHouse aktivt, användarbasen växer och supporten är mycket aktiv, men har vi blivit gisslan för den offentliga framgången med ClickHouse, som har överskuggat andra, kanske mer effektiva/tillförlitliga lösningar?
I början av förra året började vi omarbeta vårt eget övervakningssystem, då uppstod frågan om att välja en lämplig databas för lagring av data. Jag vill prata om historien bakom detta val här.
Problem uttalande
Först och främst ett nödvändigt förord. Varför behöver vi överhuvudtaget ett eget övervakningssystem och hur utformades det?
Vi började tillhandahålla supporttjänster 2008, och 2010 stod det klart att det blev svårt att aggregera data om de processer som förekommer i klientinfrastrukturen med de lösningar som fanns vid den tiden (vi pratar om, Gud förlåt mig, Cacti, Zabbix och den framväxande grafiten).
Våra huvudkrav var:
- stödja (vid den tiden - dussintals, och i framtiden - hundratals) kunder inom ett system och samtidigt närvaron av ett centraliserat varningshanteringssystem;
- flexibilitet i hanteringen av varningssystemet (eskalering av varningar mellan tjänstemän, schemaläggning, kunskapsbas);
- förmågan att detaljera grafer på djupet (Zabbix återgav vid den tiden grafer i form av bilder);
- långtidslagring av en stor mängd data (ett år eller mer) och möjligheten att snabbt hämta den.
I den här artikeln är vi intresserade av den sista punkten.
På tal om lagring var kraven följande:
- systemet måste fungera snabbt;
- det är önskvärt att systemet har ett SQL-gränssnitt;
- systemet måste vara stabilt och ha en aktiv användarbas och support (en gång stod vi inför behovet av att stödja system som MemcacheDB, som inte längre utvecklades, eller MooseFS distribuerad lagring, vars buggspårare hölls på kinesiska: vi upprepar den här historien för vårt projekt ville inte);
- överensstämmelse med CAP-teoremet: Consitency (obligatoriskt) - uppgifterna måste vara uppdaterade, vi vill inte att varningshanteringssystemet inte ska ta emot nya data och spotta ut varningar om att data inte kommer fram för alla projekt; Partitionstolerans (krävs) - vi vill inte skaffa ett Split Brain-system; Tillgänglighet (inte kritisk, om det finns en aktiv replika) - vi kan byta till backupsystemet själva i händelse av en olycka, med hjälp av kod.
Konstigt nog visade sig MySQL vid den tiden vara den idealiska lösningen för oss. Vår datastruktur var extremt enkel: server-id, räknar-id, tidsstämpel och värde; snabb sampling av heta data säkerställdes av en stor buffertpool, och sampling av historiska data säkerställdes av SSD.
Således uppnådde vi ett urval av färska tvåveckorsdata, med detaljer ner till en sekund 200 ms innan datan var fullständigt återgiven, och levde i detta system under ganska lång tid.
Under tiden gick tiden och mängden data växte. År 2016 nådde datavolymerna tiotals terabyte, vilket var en betydande kostnad i samband med hyrd SSD-lagring.
Vid det här laget hade kolumnära databaser blivit aktivt utbredda, vilket vi aktivt började tänka på: i kolumnära databaser lagras data, som ni förstår, i kolumner, och om man tittar på vår data är det lätt att se en stor antal dubbletter som skulle kunna, i Om du använder en kolumnär databas, komprimera den med komprimering.
Företagets nyckelsystem fortsatte dock att fungera stabilt och jag ville inte experimentera med att byta till något annat.
2017, vid Percona Live-konferensen i San Jose, tillkännagav Clickhouse-utvecklare sig förmodligen för första gången. Vid första anblicken var systemet produktionsfärdigt (ja, Yandex.Metrica är ett hårt produktionssystem), supporten var snabb och enkel och, viktigast av allt, driften var enkel. Sedan 2018 har vi påbörjat övergångsprocessen. Men vid den tiden fanns det många "vuxna" och tidstestade TSDB-system, och vi bestämde oss för att ägna mycket tid och jämföra alternativ för att säkerställa att det inte fanns några alternativa lösningar till Clickhouse, enligt våra krav.
Utöver de redan specificerade lagringskraven har nya dykt upp:
- det nya systemet bör ge minst samma prestanda som MySQL på samma mängd hårdvara;
- lagringen av det nya systemet bör ta betydligt mindre plats;
- DBMS måste fortfarande vara lätt att hantera;
- Jag ville ändra applikationen minimalt när jag ändrade DBMS.
Vilka system började vi överväga?
Apache Hive/Apache Impala
En gammal, stridstestad Hadoop-stack. I huvudsak är det ett SQL-gränssnitt byggt ovanpå lagring av data i inbyggda format på HDFS.
Pros.
- Med stabil drift är det mycket enkelt att skala data.
- Det finns kolumnlösningar för datalagring (mindre utrymme).
- Mycket snabb utförande av parallella uppgifter när resurser finns tillgängliga.
Cons.
- Det är Hadoop, och det är svårt att använda. Om vi inte är redo att ta en färdig lösning i molnet (och vi är inte redo kostnadsmässigt) måste hela stacken monteras och stödjas av administratörernas händer, och vi vill verkligen inte detta.
- Data är aggregerade .
Men:
Hastighet uppnås genom att skala antalet datorservrar. Enkelt uttryckt, om vi är ett stort företag som sysslar med analys och det är avgörande för verksamheten att samla information så snabbt som möjligt (även till priset av att använda en stor mängd datorresurser), kan detta vara vårt val. Men vi var inte redo att multiplicera hårdvaruflottan för att påskynda uppgifterna.
Druid/Pinot
Det finns mycket mer om TSDB specifikt, men återigen, Hadoop-stacken.
Det finns .
Med några få ord: Druid/Pinot ser bättre ut än Clickhouse i fall där:
- Du har en heterogen natur av data (i vårt fall registrerar vi endast tidsserier av servermått, och i själva verket är detta en tabell. Men det kan finnas andra fall: utrustningens tidsserier, ekonomiska tidsserier, etc. - var och en med sin egen struktur, som behöver aggregeras och bearbetas).
- Dessutom finns det mycket av denna data.
- Tabeller och data med tidsserier dyker upp och försvinner (det vill säga att någon uppsättning data anlände, analyserades och raderades).
- Det finns inget tydligt kriterium efter vilket data kan partitioneras.
I motsatta fall presterar ClickHouse bättre, och detta är vårt fall.
klickhus
- SQL-liknande
- Lätt att hantera.
- Folk säger att det fungerar.
Blir nominerad för testning.
InfluxDB
Ett främmande alternativ till ClickHouse. Av nackdelarna: High Availability finns bara i den kommersiella versionen, men den måste jämföras.
Blir nominerad för testning.
Cassandra
Å ena sidan vet vi att det används för att lagra metriska tidsserier av sådana övervakningssystem som t.ex. eller OkMeter. Det finns dock detaljer.
Cassandra är inte en kolumnär databas i traditionell mening. Det ser mer ut som en radvy, men varje rad kan ha olika antal kolumner, vilket gör det enkelt att organisera en kolumnvy. I denna mening är det tydligt att med en gräns på 2 miljarder kolumner är det möjligt att lagra vissa data i kolumner (och samma tidsserier). Till exempel i MySQL finns en gräns på 4096 kolumner och det är lätt att snubbla över ett fel med kod 1117 om du försöker göra detsamma.
Cassandra-motorn är inriktad på att lagra stora mängder data i ett distribuerat system utan master, och det ovan nämnda Cassandra CAP-teoremet handlar mer om AP, det vill säga om datatillgänglighet och motstånd mot partitionering. Det här verktyget kan alltså vara bra om du bara behöver skriva till denna databas och sällan läser från den. Och här är det logiskt att använda Cassandra som en "kall" förvaring. Det vill säga som en långsiktig, pålitlig plats att lagra stora mängder historisk data som sällan behövs, men som kan hämtas vid behov. Men för fullständighetens skull kommer vi att testa det också. Men, som jag sa tidigare, finns det ingen önskan att aktivt skriva om koden för den valda databaslösningen, så vi kommer att testa den något begränsat – utan att anpassa databasstrukturen till Cassandras detaljer.
Prometheus
Tja, av nyfikenhet bestämde vi oss för att testa prestandan hos Prometheus-lagring - bara för att förstå om vi är snabbare eller långsammare än nuvarande lösningar och med hur mycket.
Testmetodik och resultat
Så vi testade 5 databaser i följande 6 konfigurationer: ClickHouse (1 nod), ClickHouse (distribuerad tabell för 3 noder), InfluxDB, Mysql 8, Cassandra (3 noder) och Prometheus. Testplanen är som följer:
- ladda upp historiska data för en vecka (840 miljoner värden per dag; 208 tusen mätvärden);
- vi genererar en inspelningsbelastning (6 belastningslägen övervägdes, se nedan);
- Parallellt med inspelningen gör vi med jämna mellanrum urval och efterliknar önskemål från en användare som arbetar med diagram. För att inte komplicera allt för mycket valde vi data för 10 mätvärden (det är exakt hur många det finns på CPU-diagrammet) för en vecka.
Vi laddar genom att emulera beteendet hos vår övervakningsagent, som skickar värden till varje mätvärde en gång var 15:e sekund. Samtidigt är vi intresserade av att variera:
- det totala antalet mätvärden som data skrivs in i;
- intervall för att skicka värden till ett mått;
- satsstorlek.
Om batchstorleken. Eftersom det inte rekommenderas att ladda nästan alla våra experimentella databaser med enstaka inlägg, kommer vi att behöva ett relä som samlar in inkommande mätvärden och grupperar dem i grupper och skriver dem till databasen som en batchinlaga.
För att bättre förstå hur man sedan tolkar mottagna data, låt oss föreställa oss att vi inte bara skickar ett gäng mätvärden, utan mätvärdena är organiserade i servrar - 125 mätvärden per server. Här är servern helt enkelt en virtuell enhet - bara för att förstå att till exempel 10000 80 mätvärden motsvarar cirka XNUMX servrar.
Och här, med hänsyn till allt detta, är våra 6 databasskrivladdningslägen:
Det finns två punkter här. För det första, för Cassandra visade sig dessa batchstorlekar vara för stora, där använde vi värden på 50 eller 100. Och för det andra, eftersom Prometheus arbetar strikt i pull-läge, d.v.s. den själv går och samlar in data från mätkällor (och till och med pushgateway, trots namnet, förändrar inte situationen i grunden), motsvarande laddningar implementerades med en kombination av statiska konfigurationer.
Testresultaten är följande:
Vad är värt att notera: fantastiskt snabba prover från Prometheus, fruktansvärt långsamma prover från Cassandra, oacceptabelt långsamma prover från InfluxDB; När det gäller inspelningshastighet vann ClickHouse alla, och Prometheus deltar inte i tävlingen, eftersom den gör insatser själv och vi mäter ingenting.
Som ett resultat,: ClickHouse och InfluxDB visade sig vara bäst, men ett kluster från Influx kan bara byggas på basis av Enterprise-versionen, som kostar pengar, medan ClickHouse inte kostar något och tillverkas i Ryssland. Det är logiskt att i USA är valet förmodligen till förmån för inInfluxDB, och i vårt land är det till förmån för ClickHouse.
Källa: will.com