Yn 'e ôfrûne jierren binne databases fan tiidsearjes feroare fan in frjemd ding (heech spesjalisearre brûkt yn iepen tafersjochsystemen (en bûn oan spesifike oplossingen) as yn Big Data-projekten) yn in "konsumintprodukt". Op it grûngebiet fan 'e Russyske Federaasje moat spesjaal tank wurde jûn oan Yandex en ClickHouse foar dit. Oant dit punt, as jo in grutte hoemannichte tiidrige gegevens opslaan moasten, moasten jo óf yn 'e kunde komme mei de needsaak om in meunsterlike Hadoop-stapel te bouwen en it te ûnderhâlden, of kommunisearje mei protokollen yndividueel foar elk systeem.
It kin lykje dat yn 2019 in artikel oer hokker TSDB it wurdich is te brûken mar ien sin bestiet: "Gebrûk gewoan ClickHouse." Mar... der binne nuânses.
Yndied, ClickHouse is aktyf ûntwikkeljen, de brûkersbasis groeit, en stipe is tige aktyf, mar binne wy gizelders wurden foar it publike súkses fan ClickHouse, dy't oare, miskien effektiver / betroubere oplossingen oerskaad hat?
Begjin ferline jier binne wy begûn mei it werwurkjen fan ús eigen tafersjochsysteem, wêrby't de fraach opkaam fan it kiezen fan in gaadlike databank foar it opslaan fan gegevens. Ik wol it hjir oer de skiednis fan dizze kar hawwe.
Probleemintwurding
Earst fan alles, in needsaaklik foaropwurd. Wêrom hawwe wy ús eigen tafersjochsysteem überhaupt nedich en hoe is it ûntwurpen?
Wy begûnen yn 2008 stipetsjinsten te leverjen, en yn 2010 waard it dúdlik dat it lestich waard om gegevens te aggregearjen oer de prosessen dy't foarkomme yn 'e klantynfrastruktuer mei de oplossingen dy't op dat stuit bestien (wy prate oer, God ferjou my, Cacti, Zabbix en it opkommende Graphite).
Us wichtichste easken wiene:
- stipe (op dat stuit - tsientallen, en yn 'e takomst - hûnderten) fan kliïnten binnen ien systeem en tagelyk de oanwêzigens fan in sintralisearre warskôgingsbehearsysteem;
- fleksibiliteit by it behearen fan it warskôgingssysteem (eskalaasje fan warskôgings tusken tsjinstoffisieren, skema, kennisbasis);
- de mooglikheid om grafiken djip te detaillearjen (Zabbix makke op dat stuit grafiken yn 'e foarm fan foto's);
- lange-termyn opslach fan in grutte hoemannichte gegevens (in jier of mear) en de mooglikheid om fluch ophelje it.
Yn dit artikel binne wy ynteressearre yn it lêste punt.
Oer opslach sprutsen, de easken wiene as folget:
- it systeem moat fluch wurkje;
- it is winsklik dat it systeem hat in SQL ynterface;
- it systeem moat stabyl wêze en in aktive brûkersbasis en stipe hawwe (ienris waarden wy konfrontearre mei de needsaak om systemen te stypjen lykas MemcacheDB, dy't net mear ûntwikkele wie, of de MooseFS ferdielde opslach, wêrfan de bugtracker yn it Sineesk bewarre waard: wy werhelje dit ferhaal foar ús projekt woe net);
- neilibjen fan de CAP-stelling: Consitency (fereaske) - de gegevens moatte aktueel wêze, wy wolle net dat it warskôgingsbehearsysteem gjin nije gegevens ûntfangt en warskôgings útspylje oer de net-oankomst fan gegevens foar alle projekten; Partition Tolerance (ferplicht) - wy wolle net krije in Split Brain systeem; Beskikberens (net kritysk, as der in aktive replika is) - wy kinne sels oerskeakelje nei it reservekopysysteem yn gefal fan in ûngelok, mei help fan koade.
Geweldich genôch, op dat stuit die MySQL de ideale oplossing foar ús te wêzen. Us gegevensstruktuer wie ekstreem ienfâldich: server-id, teller-id, tiidstempel en wearde; snelle sampling fan hot gegevens waard fersoarge troch in grutte buffer pool, en sampling fan histoaryske gegevens waard fersoarge troch SSD.
Sa hawwe wy in stekproef fan farske gegevens fan twa wiken berikt, mei detail oant in twadde 200 ms foardat de gegevens folslein werjûn waarden, en libbe in hiel lange tiid yn dit systeem.
Underwilens gie de tiid foarby en groeide de hoemannichte gegevens. Tsjin 2016 berikten gegevensvoluminten tsientallen terabytes, wat in wichtige útjefte wie yn 'e kontekst fan hierde SSD-opslach.
Tsjin dizze tiid wiene kolomdatabases aktyf wiidferspraat wurden, wêr't wy aktyf oer begûnen te tinken: yn kolomdatabases wurde gegevens bewarre, lykas jo kinne begripe, yn kolommen, en as jo nei ús gegevens sjogge, is it maklik om in grutte te sjen oantal duplikaten dat koe, yn As jo brûke in columnar databank, compress it mei help fan kompresje.
It kaaisysteem fan it bedriuw bleau lykwols stabyl te wurkjen, en ik woe net eksperimintearje mei it wikseljen nei wat oars.
Yn 2017, op 'e Percona Live-konferinsje yn San Jose, kundige Clickhouse-ûntwikkelders har wierskynlik foar it earst oan. Op it earste each, it systeem wie produksje-klear (goed, Yandex.Metrica is in hurde produksje systeem), stipe wie fluch en ienfâldich, en, vooral, operaasje wie simpel. Sûnt 2018 binne wy begûn mei it oergongsproses. Mar tsjin dy tiid wiene d'r in protte "folwoeksen" en yn 'e tiid hifke TSDB-systemen, en wy besletten om in protte tiid te besteegjen en alternativen te fergelykjen om derfoar te soargjen dat d'r gjin alternative oplossingen wiene foar Clickhouse, neffens ús easken.
Neist de al oantsjutte opslacheasken binne nije ferskynd:
- it nije systeem moat op syn minst deselde prestaasjes leverje as MySQL op deselde hoemannichte hardware;
- de opslach fan it nije systeem moat flink minder romte ynnimme;
- It DBMS moat noch maklik te behearjen wêze;
- Ik woe de applikaasje minimaal feroarje by it feroarjen fan de DBMS.
Hokker systemen hawwe wy begon te beskôgjen?
Apache Hive / Apache Impala
In âlde, striid-testen Hadoop-stapel. Yn essinsje is it in SQL-ynterface boud boppe op it bewarjen fan gegevens yn native formaten op HDFS.
Pros.
- Mei stabile operaasje is it heul maklik om gegevens te skaaljen.
- D'r binne kolomoplossingen foar gegevensopslach (minder romte).
- Hiel rappe útfiering fan parallelle taken as boarnen beskikber binne.
Cons
- It is Hadoop, en it is lestich te brûken. As wy net ree binne om in klearmakke oplossing yn 'e wolk te nimmen (en wy binne net klear yn termen fan kosten), sil de heule stapel moatte wurde gearstald en stipe troch de hannen fan admins, en wy wolle echt net dit.
- Gegevens wurde aggregearre .
Lykwols:
Snelheid wurdt berikt troch it skaaljen fan it oantal komputerservers. Simply set, as wy in grut bedriuw binne, dwaande mei analytiken, en it is kritysk foar it bedriuw om ynformaasje sa rap mooglik te aggregearjen (sels op kosten fan it brûken fan in grutte hoemannichte komputerboarnen), kin dit ús kar wêze. Mar wy wiene net ree om de hardwarefloat te fermannichfâldigjen om taken te fersnellen.
Druid / Pinot
D'r is spesifyk folle mear oer TSDB, mar wer, de Hadoop-stapel.
der binne .
Yn in pear wurden: Druid / Pinot sjocht der better út dan Clickhouse yn gefallen wêr't:
- Jo hawwe in heterogene aard fan gegevens (yn ús gefal, wy registrearje allinnich timeseries fan tsjinner metrics, en, yn feite, dit is ien tabel. Mar der kinne oare gefallen: apparatuer tiid rige, ekonomyske tiid rige, ensfh - elk mei in eigen struktuer, dy't aggregearre en ferwurke wurde moat).
- Boppedat is d'r in protte fan dizze gegevens.
- Tabellen en gegevens mei tiid rige ferskine en ferdwine (dat is, guon set fan gegevens oankommen, waard analysearre en wiske).
- D'r is gjin dúdlik kritearium wêrmei gegevens kinne wurde ferdield.
Yn tsjinoerstelde gefallen docht ClickHouse better, en dit is ús gefal.
klikhûs
- SQL-like
- Maklik te behearjen.
- Minsken sizze dat it wurket.
Wurdt shortlist foar testen.
InfluxDB
In frjemd alternatyf foar ClickHouse. Fan 'e minussen: Hege beskikberens is allinich oanwêzich yn' e kommersjele ferzje, mar it moat wurde fergelike.
Wurdt shortlist foar testen.
Cassandra
Oan 'e iene kant witte wy dat it wurdt brûkt om metryske tiidseries op te slaan troch sokke monitoaringssystemen as, bygelyks, of OkMeter. D'r binne lykwols spesifiken.
Cassandra is gjin kollumnêre databank yn 'e tradisjonele sin. It liket mear op in rige werjefte, mar elke rigel kin in oar oantal kolommen hawwe, wêrtroch it maklik is om in kolom werjefte te organisearjen. Yn dizze sin is it dúdlik dat it mei in limyt fan 2 miljard kolommen mooglik is om guon gegevens yn kolommen (en deselde tiidrige) op te slaan. Bygelyks, yn MySQL is d'r in limyt fan 4096 kolommen en it is maklik om te stroffeljen op in flater mei koade 1117 as jo besykje itselde te dwaan.
De Cassandra-motor is rjochte op it bewarjen fan grutte hoemannichten gegevens yn in ferspraat systeem sûnder in master, en it boppeneamde Cassandra CAP-teorem giet mear oer AP, dat is oer gegevensbeskikberens en ferset tsjin partitionearring. Sa kin dit ark geweldich wêze as jo allinich nei dizze databank moatte skriuwe en der selden fan lêze. En hjir is it logysk om Cassandra te brûken as in "kâlde" opslach. Dat is, as in lange termyn, betrouber plak om grutte hoemannichten histoaryske gegevens op te slaan dy't selden nedich binne, mar kinne wurde ophelle as it nedich is. Dochs sille wy it foar de folsleinens ek testen. Mar, lykas ik earder sei, is d'r gjin winsk om de koade aktyf te herskriuwen foar de selekteare databankoplossing, dus wy sille it wat beheind testje - sûnder de databankstruktuer oan te passen oan 'e spesifiken fan Cassandra.
Prometheus
No, út nijsgjirrigens hawwe wy besletten de prestaasjes fan Prometheus-opslach te testen - gewoan om te begripen oft wy rapper of stadiger binne as hjoeddeistige oplossingen en mei hoefolle.
Testmetoade en resultaten
Dat, wy testen 5 databases yn 'e folgjende 6 konfiguraasjes: ClickHouse (1 knooppunt), ClickHouse (ferdield tabel foar 3 knooppunten), InfluxDB, Mysql 8, Cassandra (3 knooppunten) en Prometheus. It testplan is as folget:
- upload histoaryske gegevens foar in wike (840 miljoen wearden per dei; 208 tûzen metriken);
- wy generearje in opname load (6 load modes waarden beskôge, sjoch hjirûnder);
- Parallel mei opname meitsje wy periodyk seleksjes, emulearje de oanfragen fan in brûker dy't wurket mei diagrammen. Om dingen net te komplisearjen, hawwe wy gegevens foar 10 metriken (dat is krekt hoefolle d'r binne op 'e CPU-grafyk) foar in wike selektearre.
Wy laden troch it gedrach fan ús tafersjochagent te emulearjen, dy't ien kear yn 'e 15 sekonden wearden nei elke metrik stjoert. Tagelyk binne wy ynteressearre yn fariearjend:
- it totale oantal metriken dêr't gegevens yn skreaun binne;
- ynterval foar it ferstjoeren fan wearden nei ien metrysk;
- batch grutte.
Oer de batchgrutte. Sûnt it is net oan te rieden om te laden hast al ús eksperimintele databases mei inkele ynserts, wy sille nedich in estafette dat sammelet ynkommende metriken en groepearret se yn groepen en skriuwt se nei de databank as in batch ynfoegje.
Ek, om better te begripen hoe't jo de ûntfongen gegevens kinne ynterpretearje, litte wy ús foarstelle dat wy net allinich in boskje metriken stjoere, mar de metriken binne organisearre yn servers - 125 metriken per server. Hjir is de server gewoan in firtuele entiteit - gewoan om te begripen dat bygelyks 10000 metriken oerienkomme mei sawat 80 servers.
En hjir, mei dit alles yn rekken brocht, binne ús 6 skriuwladingsmodi foar databases:
Hjir binne twa punten. As earste, foar Cassandra bliken dizze batchgrutte te grut te wêzen, dêr brûkten wy wearden fan 50 of 100. En twadde, om't Prometheus strikt wurket yn pull-modus, d.w.s. it sels giet en sammelet gegevens út metrics boarnen (en sels pushgateway, nettsjinsteande de namme, net fûneminteel feroarje de situaasje), de oerienkommende loads waarden útfierd mei help fan in kombinaasje fan statyske configs.
De testresultaten binne as folget:
Wat is it wurdich op te merken: fantastysk flugge samples fan Prometheus, ferskriklik trage samples fan Cassandra, ûnakseptabel trage samples fan InfluxDB; Yn termen fan opname snelheid, ClickHouse wûn elkenien, en Prometheus net meidwaan oan 'e kompetysje, omdat it makket inserts sels en wy mjitte neat.
As gefolch,: ClickHouse en InfluxDB lieten harsels de bêste sjen, mar in kluster fan Influx kin allinich boud wurde op basis fan 'e Enterprise ferzje, dy't jild kostet, wylst ClickHouse neat kostet en makke wurdt yn Ruslân. It is logysk dat yn 'e FS de kar wierskynlik is yn it foardiel fan InfluxDB, en yn ús lân is it foar ClickHouse.
Boarne: www.habr.com