Oor die afgelope paar jaar het tydreeksdatabasisse verander van 'n vreemde ding (hoogs gespesialiseerde gebruik óf in oop moniteringstelsels (en gekoppel aan spesifieke oplossings) óf in Big Data-projekte) in 'n "verbruikersproduk". Op die grondgebied van die Russiese Federasie moet spesiale dank aan Yandex en ClickHouse hiervoor gegee word. Tot op hierdie stadium, as jy 'n groot hoeveelheid tydreeksdata moes stoor, moes jy óf vrede maak met die behoefte om 'n monsteragtige Hadoop-stapel te bou en dit in stand te hou, óf met protokolle individueel vir elke stelsel kommunikeer.
Dit mag lyk asof 'n artikel in 2019 waaroor TSDB die moeite werd is om te gebruik slegs uit een sin sal bestaan: "gebruik net ClickHouse." Maar ... daar is nuanses.
Inderdaad, ClickHouse ontwikkel aktief, die gebruikersbasis groei en ondersteuning is baie aktief, maar het ons gyselaars geword vir die publieke sukses van ClickHouse, wat ander, miskien meer effektiewe/betroubare oplossings oorskadu het?
Aan die begin van verlede jaar het ons begin om ons eie moniteringstelsel te herwerk, waartydens die vraag ontstaan het om 'n geskikte databasis vir die stoor van data te kies. Ek wil hier oor die geskiedenis van hierdie keuse praat.
Probleemstelling
Eerstens 'n noodsaaklike voorwoord. Hoekom het ons hoegenaamd ons eie moniteringstelsel nodig en hoe is dit ontwerp?
Ons het in 2008 begin om ondersteuningsdienste te verskaf, en teen 2010 het dit duidelik geword dat dit moeilik geword het om data oor die prosesse wat in die kliëntinfrastruktuur plaasvind saam te voeg met die oplossings wat op daardie stadium bestaan het (ons praat van, God vergewe my, Cacti, Zabbix en die opkomende Grafiet).
Ons hoofvereistes was:
- ondersteun (op daardie tydstip - dosyne, en in die toekoms - honderde) kliënte binne een stelsel en terselfdertyd die teenwoordigheid van 'n gesentraliseerde waarskuwingsbestuurstelsel;
- buigsaamheid in die bestuur van die waarskuwingstelsel (eskalering van waarskuwings tussen diensbeamptes, skedulering, kennisbasis);
- die vermoë om grafieke diep te beskryf (Zabbix het destyds grafieke in die vorm van prente weergegee);
- langtermynberging van 'n groot hoeveelheid data ('n jaar of meer) en die vermoë om dit vinnig te herwin.
In hierdie artikel stel ons belang in die laaste punt.
Van berging gepraat, die vereistes was soos volg:
- die stelsel moet vinnig werk;
- dit is wenslik dat die stelsel 'n SQL-koppelvlak het;
- die stelsel moet stabiel wees en 'n aktiewe gebruikersbasis en ondersteuning hê (eens het ons gekonfronteer met die behoefte om stelsels soos MemcacheDB, wat nie meer ontwikkel is nie, of die MooseFS-verspreide berging te ondersteun, waarvan die foutopsporing in Chinees gehou is: ons herhaal hierdie storie vir ons projek wou nie);
- voldoening aan die GLB-stelling: Konsekwentheid (vereis) - die data moet op datum wees, ons wil nie hê dat die waarskuwingsbestuurstelsel nie nuwe data moet ontvang nie en waarskuwings uitspoeg oor die nie-aankoms van data vir alle projekte; Partisieverdraagsaamheid (vereis) - ons wil nie 'n gesplete breinstelsel kry nie; Beskikbaarheid (nie krities nie, as daar 'n aktiewe replika is) - ons kan self na die rugsteunstelsel oorskakel in die geval van 'n ongeluk, deur kode te gebruik.
Vreemd genoeg was MySQL destyds die ideale oplossing vir ons. Ons datastruktuur was uiters eenvoudig: bediener-ID, teller-ID, tydstempel en waarde; vinnige monsterneming van warm data is verseker deur 'n groot bufferpoel, en monsterneming van historiese data is verseker deur SSD.
Ons het dus 'n steekproef van vars twee-week data verkry, met detail tot 'n tweede 200 ms voordat die data heeltemal weergegee is, en het vir 'n redelike lang tyd in hierdie stelsel gewoon.
Intussen het die tyd verbygegaan en die hoeveelheid data het gegroei. Teen 2016 het datavolumes tientalle teragrepe bereik, wat 'n aansienlike uitgawe was in die konteks van gehuurde SSD-berging.
Teen hierdie tyd het kolomdatabasisse aktief wydverspreid geraak, waaroor ons aktief begin dink het: in kolomdatabasisse word data, soos jy kan verstaan, in kolomme gestoor, en as jy na ons data kyk, is dit maklik om 'n groot aantal duplikate wat in As jy 'n kolomdatabasis gebruik, dit kan saamdruk deur kompressie te gebruik.
Die maatskappy se sleutelstelsel het egter stabiel bly werk, en ek wou nie eksperimenteer om na iets anders oor te skakel nie.
In 2017, by die Percona Live-konferensie in San Jose, het Clickhouse-ontwikkelaars hulself waarskynlik vir die eerste keer aangekondig. Met die eerste oogopslag was die stelsel produksiegereed (wel, Yandex.Metrica is 'n harde produksiestelsel), ondersteuning was vinnig en eenvoudig, en, bowenal, die werking was eenvoudig. Sedert 2018 het ons die oorgangsproses begin. Maar teen daardie tyd was daar baie "volwasse" en beproefde TSDB-stelsels, en ons het besluit om heelwat tyd te bestee en alternatiewe te vergelyk om seker te maak dat daar geen alternatiewe oplossings vir Clickhouse was nie, volgens ons vereistes.
Benewens die reeds gespesifiseerde bergingsvereistes, het nuwes verskyn:
- die nuwe stelsel moet ten minste dieselfde werkverrigting as MySQL op dieselfde hoeveelheid hardeware lewer;
- die berging van die nuwe stelsel behoort aansienlik minder spasie op te neem;
- Die DBBS moet steeds maklik wees om te bestuur;
- Ek wou die toepassing minimaal verander wanneer ek die DBBS verander.
Watter stelsels het ons begin oorweeg?
Apache Hive/Apache Rooibok
'n Ou, stryd-getoetste Hadoop-stapel. In wese is dit 'n SQL-koppelvlak wat bo-op die stoor van data in inheemse formate op HDFS gebou is.
Voor.
- Met stabiele werking is dit baie maklik om data te skaal.
- Daar is kolomoplossings vir databerging (minder spasie).
- Baie vinnige uitvoering van parallelle take wanneer hulpbronne beskikbaar is.
Nadele.
- Dit is Hadoop, en dit is moeilik om te gebruik. As ons nie gereed is om 'n klaargemaakte oplossing in die wolk te neem nie (en ons is nie gereed in terme van koste nie), sal die hele stapel saamgestel en ondersteun moet word deur die hande van admins, en ons wil regtig nie hierdie.
- Data word saamgevoeg .
Maar:
Spoed word bereik deur die aantal rekenaarbedieners te skaal. Eenvoudig gestel, as ons 'n groot maatskappy is wat besig is met analise, en dit is van kritieke belang vir die onderneming om inligting so vinnig as moontlik te versamel (selfs ten koste van die gebruik van 'n groot hoeveelheid rekenaarhulpbronne), kan dit ons keuse wees. Maar ons was nie gereed om die hardewarevloot te vermeerder om take te bespoedig nie.
Druïde/Pinot
Daar is baie meer spesifiek oor TSDB, maar weereens, die Hadoop-stapel.
Daar is .
In 'n paar woorde: Druid/Pinot lyk beter as Clickhouse in gevalle waar:
- Jy het 'n heterogene aard van data (in ons geval teken ons slegs tydreekse van bedienerstatistieke aan, en dit is eintlik een tabel. Maar daar kan ander gevalle wees: toerustingtydreekse, ekonomiese tydreekse, ens. - elk met sy eie struktuur, wat saamgevoeg en verwerk moet word).
- Boonop is daar baie van hierdie data.
- Tabelle en data met tydreekse verskyn en verdwyn (dit wil sê, 'n stel data het aangekom, is ontleed en uitgevee).
- Daar is geen duidelike maatstaf waarvolgens data verdeel kan word nie.
In teenoorgestelde gevalle vaar ClickHouse beter, en dit is ons geval.
klikhuis
- SQL-agtig
- Maklik om te bestuur.
- Mense sê dit werk.
Word op die kortlys vir toetsing.
InstromingDB
'n Buitelandse alternatief vir ClickHouse. Van die nadele: Hoë beskikbaarheid is slegs teenwoordig in die kommersiële weergawe, maar dit moet vergelyk word.
Word op die kortlys vir toetsing.
Cassandra
Aan die een kant weet ons dat dit gebruik word om metrieke tydreekse te stoor deur sulke moniteringstelsels soos bv. of OkMeter. Daar is egter besonderhede.
Cassandra is nie 'n kolomdatabasis in die tradisionele sin nie. Dit lyk meer soos 'n ry-aansig, maar elke lyn kan 'n ander aantal kolomme hê, wat dit maklik maak om 'n kolomaansig te organiseer. In hierdie sin is dit duidelik dat dit met 'n limiet van 2 miljard kolomme moontlik is om sommige data in kolomme (en dieselfde tydreekse) te stoor. Byvoorbeeld, in MySQL is daar 'n limiet van 4096 kolomme en dit is maklik om op 'n fout met kode 1117 te struikel as jy dieselfde probeer doen.
Die Cassandra-enjin is daarop gefokus om groot hoeveelhede data in 'n verspreide stelsel sonder 'n meester te stoor, en die bogenoemde Cassandra CAP-stelling gaan meer oor AP, dit wil sê, oor databeskikbaarheid en weerstand teen partisionering. Hierdie instrument kan dus wonderlik wees as jy net na hierdie databasis hoef te skryf en selde daaruit lees. En hier is dit logies om Cassandra as 'n "koue" stoor te gebruik. Dit is, as 'n langtermyn, betroubare plek om groot hoeveelhede historiese data te stoor wat selde nodig is, maar kan herwin word indien nodig. Nietemin sal ons dit volledigheidshalwe ook toets. Maar, soos ek vroeër gesê het, is daar geen begeerte om aktief die kode vir die geselekteerde databasisoplossing te herskryf nie, so ons sal dit ietwat beperk toets - sonder om die databasisstruktuur aan te pas by die besonderhede van Cassandra.
Prometheus
Wel, uit nuuskierigheid het ons besluit om die werkverrigting van Prometheus-berging te toets - net om te verstaan of ons vinniger of stadiger is as huidige oplossings en met hoeveel.
Toetsmetodologie en resultate
Dus, ons het 5 databasisse in die volgende 6 konfigurasies getoets: ClickHouse (1 nodus), ClickHouse (verspreide tabel vir 3 nodusse), InfluxDB, Mysql 8, Cassandra (3 nodusse) en Prometheus. Die toetsplan is soos volg:
- laai historiese data vir 'n week op (840 miljoen waardes per dag; 208 duisend metrieke);
- ons genereer 'n opnamelading (6 lasmodusse is oorweeg, sien hieronder);
- Parallel met opname, maak ons periodiek keuses, wat die versoeke van 'n gebruiker naboots wat met kaarte werk. Om dinge nie te veel te kompliseer nie, het ons data vir 10 statistieke (dit is presies hoeveel daar op die SVE-grafiek is) vir 'n week gekies.
Ons laai deur die gedrag van ons moniteringsagent na te boots, wat een keer elke 15 sekondes waardes na elke maatstaf stuur. Terselfdertyd stel ons daarin belang om te wissel:
- die totale aantal metrieke waarin data geskryf is;
- interval vir die stuur van waardes na een metriek;
- bondel grote.
Oor die bondelgrootte. Aangesien dit nie aanbeveel word om byna al ons eksperimentele databasisse met enkele insetsels te laai nie, sal ons 'n aflos benodig wat inkomende maatstawwe versamel en dit in groepe groepeer en as 'n bondelinsetsel na die databasis skryf.
Om ook beter te verstaan hoe om die ontvangde data te interpreteer, laat ons ons voorstel dat ons nie net 'n klomp statistieke stuur nie, maar die statistieke is in bedieners georganiseer - 125 statistieke per bediener. Hier is die bediener bloot 'n virtuele entiteit - net om te verstaan dat, byvoorbeeld, 10000 80 metrieke ooreenstem met ongeveer XNUMX bedieners.
En hier, met dit alles in ag geneem, is ons 6 databasis skryfladingsmodusse:
Daar is twee punte hier. Eerstens, vir Cassandra het hierdie bondelgroottes te groot geblyk te wees, daar het ons waardes van 50 of 100 gebruik. En tweedens, aangesien Prometheus streng in trekmodus werk, d.w.s. dit self gaan en versamel data van metrieke bronne (en selfs pushgateway, ten spyte van die naam, verander nie die situasie fundamenteel nie), die ooreenstemmende vragte is geïmplementeer met behulp van 'n kombinasie van statiese konfigurasies.
Die toetsuitslae is soos volg:
Wat die moeite werd is om op te let: fantasties vinnige monsters van Prometheus, verskriklik stadige monsters van Cassandra, onaanvaarbaar stadige monsters van InfluxDB; Wat die opnamespoed betref, het ClickHouse almal gewen, en Prometheus neem nie aan die kompetisie deel nie, want dit maak self insetsels en ons meet niks.
Uiteindelik: ClickHouse en InfluxDB het getoon dat hulle die beste is, maar 'n cluster van Influx kan slegs gebou word op grond van die Enterprise-weergawe, wat geld kos, terwyl ClickHouse niks kos nie en in Rusland gemaak word. Dit is logies dat in die VSA die keuse waarskynlik ten gunste van inInfluxDB is, en in ons land is dit ten gunste van ClickHouse.
Bron: will.com