An de leschte Joren hunn Zäit-Serie Datenbanken vun enger ongewéinlecher Saach (héich spezialiséiert benotzt entweder an oppenen Iwwerwaachungssystemer (a verbonne mat spezifesche Léisungen) oder a Big Data Projeten) an e "Konsumentenprodukt" ëmgewandelt. Um Territoire vun der russescher Federatioun muss speziell Merci un Yandex an ClickHouse ginn fir dëst. Bis zu dësem Zäitpunkt, wann Dir braucht eng grouss Quantitéit vun Zäit-Serie Donnéeën ze späicheren, musst Dir entweder mat der Noutwendegkeet kommen fir e monstréisen Hadoop Stack ze bauen an z'erhalen, oder mat Protokoller individuell fir all System kommunizéieren.
Et kann schéngen datt am Joer 2019 en Artikel iwwer deen TSDB et wäert ass ze benotzen nëmmen aus engem Saz besteet: "benotzt just ClickHouse." Mee ... et ginn Nuancen.
Tatsächlech ass ClickHouse aktiv entwéckelt, d'Benotzerbasis wiisst, an d'Ënnerstëtzung ass ganz aktiv, awer si mir Geiselen fir den ëffentlechen Erfolleg vu ClickHouse ginn, deen aner, vläicht méi effektiv / zouverlässeg Léisungen iwwerschësseg huet?
Am Ufank vum leschte Joer hu mir ugefaang eisen eegenen Iwwerwachungssystem ëmzeschaffen, während deem d'Fro opgestallt ass, eng gëeegent Datebank ze wielen fir Daten ze späicheren. Ech wëll iwwer d'Geschicht vun dëser Wiel hei schwätzen.
Problemerklärung
Éischt vun all, eng néideg Virwuert. Firwat brauche mir iwwerhaapt eisen eegenen Iwwerwaachungssystem a wéi gouf en entworf?
Mir hunn ugefaang Ënnerstëtzungsservicer am Joer 2008 ze liwweren, a bis 2010 gouf et kloer datt et schwéier gouf Daten iwwer d'Prozesser, déi an der Clientinfrastruktur optrieden, mat de Léisungen ze aggregéieren, déi zu där Zäit existéieren (mir schwätzen iwwer, Gott verzei mir, Cacti, Zabbix an den opkomende Graphite).
Eis Haaptfuerderunge waren:
- Ënnerstëtzung (zu där Zäit - Dosende, an an Zukunft - Honnerte) vu Clienten an engem System a gläichzäiteg d'Präsenz vun engem zentraliséierten Alarmmanagementsystem;
- Flexibilitéit bei der Gestioun vum Alarmsystem (Eskalatioun vun Alarmer tëscht Flichtoffizéier, Zäitplang, Wëssensbasis);
- d'Kapazitéit fir déif Grafiken ze detailléiert (Zabbix huet zu där Zäit Grafiken a Form vu Biller gemaach);
- laangfristeg Stockage vun enger grousser Quantitéit vun Donnéeën (e Joer oder méi) an d'Fähegkeet se séier ze recuperéieren.
An dësem Artikel si mir am leschte Punkt interesséiert.
Apropos Lagerung, d'Ufuerderunge waren wéi follegt:
- de System muss séier schaffen;
- et ass wënschenswäert datt de System eng SQL Interface huet;
- de System muss stabil sinn an eng aktiv Benotzerbasis an Ënnerstëtzung hunn (eemol ware mir konfrontéiert mat der Bedierfnes fir Systemer ze ënnerstëtzen wéi MemcacheDB, déi net méi entwéckelt gouf, oder de MooseFS verdeelt Späichere, de Bugs Tracker vun deem op Chinesesch gehale gouf: mir widderhuelen dës Geschicht fir eise Projet wollt net);
- Konformitéit mam CAP-Theorem: Konsequenz (obligatoresch) - d'Donnéeën mussen aktuell sinn, mir wëllen net datt den Alarmmanagementsystem keng nei Donnéeën kritt an d'Alarm iwwer d'Net-Arrivée vun den Donnéeën fir all Projeten ausspuckt; Partition Toleranz (obligatoresch) - mir wëllen net e Split Brain System kréien; Disponibilitéit (net kritesch, wann et eng aktiv Replika ass) - mir kënnen am Fall vun engem Accident selwer op de Backup-System wiesselen, andeems Dir Code benotzt.
Komesch genuch, zu där Zäit huet MySQL sech als déi ideal Léisung fir eis erausgestallt. Eis Datestruktur war extrem einfach: Server ID, Konter ID, Zäitstempel a Wäert; séier Echantillon vun waarm Donnéeën war vun engem grousse Puffer Pool gesuergt, an Echantillon vun historeschen Daten war vun SSD gesuergt.
Also hu mir eng Probe vu frëschen zwou Wochen Daten erreecht, mat Detail bis op eng zweet 200 ms ier d'Donnéeën komplett ofgeliwwert goufen, a liewen an dësem System fir eng zimlech laang Zäit.
Mëttlerweil ass d'Zäit vergaang an d'Quantitéit un Daten ass gewuess. Bis 2016 hunn d'Datevolumen Zénger vun Terabytes erreecht, wat e wesentleche Käschte war am Kontext vun der gelounter SSD-Späichere.
Zu dësem Zäitpunkt sinn d'Spaltdatenbanken aktiv verbreet ginn, iwwer déi mir ugefaang hunn aktiv nozedenken: a Kolumndatenbanken ginn Daten, wéi Dir versteet, a Kolonnen gespäichert, a wann Dir eis Date kuckt, ass et einfach eng grouss ze gesinn. Zuel vun Duplikaten déi kéinten, an Wann Dir eng Kolonn Datebank benotzt, kompriméiert se mat Kompressioun.
Wéi och ëmmer, de Schlësselsystem vun der Firma huet weider stabil geschafft, an ech wollt net experimentéieren mam Wiessel op eppes anescht.
Am 2017, op der Percona Live Konferenz zu San Jose, hunn Clickhouse Entwéckler sech wahrscheinlech fir d'éischte Kéier ugekënnegt. Op den éischte Bléck war de System Produktioun-prett (gutt, Yandex.Metrica ass eng haart Produktioun System), Ënnerstëtzung war séier an einfach, an, Wichteg, Operatioun war einfach. Zënter 2018 hu mir den Iwwergangsprozess ugefaang. Awer zu där Zäit waren et vill "Erwuessener" an Zäit-getest TSDB Systemer, a mir hu beschloss vill Zäit ze widmen an Alternativen ze vergläichen fir sécherzestellen datt et keng alternativ Léisunge fir Clickhouse gëtt, no eisen Ufuerderungen.
Zousätzlech zu de scho spezifizéierte Späicherfuerderunge sinn nei erschéngen:
- den neie System soll op d'mannst déi selwecht Leeschtung wéi MySQL op der selwechter Quantitéit vun Hardware ubidden;
- d'Lagerung vum neie System soll däitlech manner Plaz huelen;
- D'DBMS muss nach ëmmer einfach ze verwalten sinn;
- Ech wollt d'Applikatioun minimal änneren wann ech den DBMS änneren.
Wéi eng Systemer hu mir ugefaang ze berücksichtegen?
Apache Hive / Apache Impala
En alen, Schluechtgetest Hadoop Stack. Wesentlech ass et eng SQL Interface gebaut uewen op d'Späichere vun Daten an gebiertege Formater op HDFS.
Pros.
- Mat stabiler Operatioun ass et ganz einfach Daten ze skaléieren.
- Et gi Kolonnléisungen fir Datelagerung (manner Plaz).
- Ganz séier Ausféierung vun parallel Aufgaben wann Ressourcen sinn.
Contrôle.
- Et ass Hadoop, an et ass schwéier ze benotzen. Wa mir net prett sinn eng fäerdeg Léisung an der Wollek ze huelen (a mir sinn net prett wat d'Käschte ugeet), muss de ganze Stack vun den Hänn vun den Administrateuren zesummegesat an ënnerstëtzt ginn, a mir wëllen wierklech net dëst.
- Daten sinn aggregéiert .
Wéi och ëmmer:
Geschwindegkeet gëtt erreecht andeems d'Zuel vun de Rechenserveren skaléiert gëtt. Einfach gesot, wa mir eng grouss Firma sinn, an der Analyse engagéiert, an et ass kritesch fir d'Geschäft Informatioun sou séier wéi méiglech ze aggregéieren (och op d'Käschte fir eng grouss Quantitéit un Informatikressourcen ze benotzen), kann dëst eise Choix sinn. Awer mir waren net prett d'Hardwareflott ze multiplizéieren fir Aufgaben ze beschleunegen.
Druid / Pinot
Et gëtt vill méi iwwer TSDB spezifesch, awer nach eng Kéier, den Hadoop Stack.
et ginn .
An e puer Wierder: Druid / Pinot kucken besser wéi Clickhouse a Fäll wou:
- Dir hutt eng heterogen Natur vun Donnéeën (an eisem Fall, mir Rekord nëmmen Timeseries vun Server Metriken, an, an Tatsaach, ass dëst een Dësch. Mä et kann aner Fäll ginn: Equipement Zäit Serie, wirtschaftlech Zäit Serie, etc. - all mat seng eege Struktur, déi muss aggregéiert a veraarbecht ginn).
- Ausserdeem gëtt et vill vun dësen Donnéeën.
- Dëscher an Donnéeën mat Zäit Serie schéngen a verschwannen (dat ass, puer Formatioun vun Donnéeën ukomm, gouf analyséiert a geläscht).
- Et gëtt kee kloere Critère mat deem Daten opgedeelt kënne ginn.
A Géigendeel Fäll mécht ClickHouse besser, an dëst ass eise Fall.
clickhouse
- SQL-ähnlech
- Einfach ze managen.
- D'Leit soen et funktionnéiert.
Gitt op der Shortlist fir Tester.
Influx DB
Eng auslännesch Alternativ zu ClickHouse. Vun de Minusen: Héich Disponibilitéit ass nëmmen an der kommerzieller Versioun präsent, awer et muss verglach ginn.
Gitt op der Shortlist fir Tester.
Cassandra
Engersäits wësse mer datt et benotzt gëtt fir metresch Zäitreihe vu sou Iwwerwaachungssystemer wéi z.B. oder OkMeter. Allerdéngs ginn et Spezifizitéiten.
Cassandra ass keng spalten Datebank am traditionelle Sënn. Et gesäit méi wéi eng Zeilvisioun aus, awer all Linn kann eng aner Zuel vu Spalten hunn, sou datt et einfach ass eng Kolonnvisioun z'organiséieren. An dësem Sënn ass et kloer datt mat enger Limit vun 2 Milliarde Kolonnen et méiglech ass e puer Daten a Kolonnen (an déiselwecht Zäitreihe) ze späicheren. Zum Beispill, am MySQL gëtt et eng Limit vu 4096 Spalten an et ass einfach op e Feeler mam Code 1117 ze stoussen wann Dir probéiert datselwecht ze maachen.
De Cassandra-Motor konzentréiert sech op grouss Quantitéiten un Daten an engem verdeelte System ouni Master ze späicheren, an dat uewe genannte Cassandra CAP-Theorem ass méi iwwer AP, dat heescht iwwer Datenverfügbarkeet a Resistenz géint Partitionéierung. Also kann dëst Tool super sinn wann Dir nëmmen op dës Datebank schreiwe musst a seelen dovun liest. An hei ass et logesch Cassandra als "kal" Stockage ze benotzen. Dat ass, als laangfristeg, zouverlässeg Plaz fir grouss Quantitéiten vun historeschen Donnéeën ze späicheren, déi selten gebraucht ginn, awer wann et néideg ass. Trotzdem, fir d'Wuel vun der Vollständegkeet wäerte mir et och testen. Awer, wéi ech virdru gesot hunn, ass et kee Wonsch de Code fir déi gewielte Datebankléisung aktiv ëmzeschreiwen, sou datt mir et e bësse limitéiert testen - ouni d'Datebankstruktur un d'Spezifizitéite vu Cassandra unzepassen.
Prometheus
Gutt, aus Virwëtz, hu mir beschloss d'Leeschtung vun der Prometheus-Späichere ze testen - just fir ze verstoen ob mir méi séier oder méi lues si wéi déi aktuell Léisungen a wéi vill.
Testmethodologie a Resultater
Also hu mir 5 Datenbanken an de folgende 6 Konfiguratiounen getest: ClickHouse (1 Node), ClickHouse (verdeelt Dësch fir 3 Noden), InfluxDB, Mysql 8, Cassandra (3 Node) a Prometheus. Den Testplang ass wéi follegt:
- Eroplueden historesch Daten fir eng Woch (840 Millioune Wäerter pro Dag; 208 Tausend Metriken);
- mir generéieren eng Opzeechnung Laascht (6 Luede Modi goufen considéréiert, gesinn ënnert);
- Parallel mat der Opnam maachen mir periodesch Selektiounen, emuléieren d'Ufroe vun engem Benotzer deen mat Charts schafft. Fir d'Saachen net ze vill komplizéiert ze hunn, hu mir Daten fir 10 Metriken ausgewielt (dat ass genau wéi vill et op der CPU Grafik sinn) fir eng Woch.
Mir lueden andeems mir d'Verhalen vun eisem Iwwerwaachungsagent emuléieren, dee Wäerter un all Metrik eemol all 15 Sekonnen schéckt. Zur selwechter Zäit si mir interesséiert fir ze variéieren:
- d'Gesamtzuel vun de Metriken, an deenen d'Donnéeë geschriwwe ginn;
- Intervall fir Wäerter op eng Metrik ze schécken;
- Batch Gréisst.
Iwwer d'Batchgréisst. Well et net recommandéiert ass bal all eis experimentell Datenbanken mat eenzelen Inserts ze lueden, brauche mir e Relais deen erakommen Metriken sammelt a se a Gruppen gruppéiert an se als Batch-Insert an d'Datebank schreift.
Och, fir besser ze verstoen wéi een dann déi kritt Donnéeën interpretéiere kann, loosst eis virstellen datt mir net nëmmen eng Rëtsch Metriken schécken, mee d'Metriken sinn op Serveren organiséiert - 125 Metriken pro Server. Hei ass de Server einfach eng virtuell Entitéit - just fir ze verstoen datt zum Beispill 10000 Metriken ongeféier 80 Server entspriechen.
An hei, wann Dir dëst alles berücksichtegt, sinn eis 6 Datebank Schreiflaaschtmodi:
Et ginn zwee Punkten hei. Éischtens, fir Cassandra dës Batchgréissten ze grouss waren, do hu mir Wäerter vu 50 oder 100 benotzt. An zweetens, well de Prometheus strikt am Pullmodus funktionnéiert, d.h. et selwer geet a sammelt Daten aus Metrikquellen (a souguer pushgateway, trotz dem Numm, ännert d'Situatioun net grondsätzlech), déi entspriechend Laascht goufen mat enger Kombinatioun vu statesche Konfiguratiounen ëmgesat.
D'Testresultater si wéi follegt:
Wat ass derwäert ze notéieren: fantastesch séier Echantillon vum Prometheus, schrecklech lues Echantillon vun Cassandra, inakzeptabel lues Echantillon vun InfluxDB; Wat d'Aufnahmegeschwindegkeet ugeet, huet ClickHouse jidderee gewonnen, an de Prometheus bedeelegt net un der Konkurrenz, well et Inserts a sech selwer mécht a mir moossen näischt.
Als Resultat,: ClickHouse an InfluxDB hu sech als déi bescht gewisen, awer e Cluster vum Influx kann nëmmen op Basis vun der Enterprise Versioun gebaut ginn, déi Sue kascht, während ClickHouse näischt kascht an a Russland gemaach gëtt. Et ass logesch datt an den USA d'Wiel wahrscheinlech zugonschte vun InfluxDB ass, an an eisem Land ass et zugonschte vum ClickHouse.
Source: will.com