Ech proposéieren Iech den Transkript vum spéiden 2019 Bericht vum Alexander Valyalkin "Go Optimizations in VictoriaMetrics" ze liesen
- e séieren a skalierbare DBMS fir Daten a Form vun enger Zäitserie ze späicheren an ze veraarbecht (de Rekord formt Zäit an eng Rei vu Wäerter, déi zu dëser Zäit entspriechen, zum Beispill duerch periodesch Ëmfroe vum Status vu Sensoren oder Sammlung vun Metriken).
Hei ass e Link op de Video vun dësem Bericht -
Sot eis iwwer Iech selwer. Ech sinn den Alexander Valyalkin. Hei . Ech sinn passionéierte iwwer Go a Leeschtungsoptimiséierung. Ech hunn vill nëtzlech an net sou nëtzlech Bibliothéiken geschriwwen. Si fänken mat entweder fast, oder mat quick Präfix.
Ech schaffen am Moment un VictoriaMetrics. Wat ass et a wat maachen ech do? Ech wäert iwwer dëst an dëser Presentatioun schwätzen.
D'Kontur vum Bericht ass wéi follegt:
- Als éischt wäert ech Iech soen wat VictoriaMetrics ass.
- Da wäert ech Iech soen wat Zäit Serie sinn.
- Da wäert ech Iech soen wéi eng Zäitserie Datebank funktionnéiert.
- Als nächst wäert ech Iech iwwer d'Datebankarchitektur soen: aus wat et besteet.
- An da loosse mer op d'Optimisatiounen goen, déi VictoriaMetrics huet. Dëst ass eng Optimiséierung fir den ëmgekéierten Index an eng Optimiséierung fir d'Bitset Implementatioun am Go.
Weess een am Publikum wat VictoriaMetrics ass? Wow, vill Leit wëssen et scho. Et ass eng gutt Noriicht. Fir déi, déi et net wëssen, ass dëst eng Zäitserie-Datebank. Et baséiert op der ClickHouse Architektur, op e puer Detailer vun der ClickHouse Implementatioun. Zum Beispill, op wéi: MergeTree, parallel Berechnung op all verfügbare Prozessorkären a Leeschtungsoptimiséierung andeems Dir un Datenblocken schafft, déi am Prozessor-Cache plazéiert sinn.
VictoriaMetrics liwwert besser Datekompressioun wéi aner Zäitseriedatenbanken.
Et skaléiert vertikal - dat ass, Dir kënnt méi Prozessoren, méi RAM op engem Computer addéieren. VictoriaMetrics wäert dës verfügbar Ressourcen erfollegräich benotzen a wäert d'linear Produktivitéit verbesseren.
VictoriaMetrics skaléiert och horizontal - dat ass, Dir kënnt zousätzlech Wirbelen un de VictoriaMetrics Stärekoup addéieren, a seng Leeschtung wäert bal linear eropgoen.
Wéi Dir et scho geduecht hutt, ass VictoriaMetrics eng séier Datebank, well ech kann anerer net schreiwen. An et ass a Go geschriwwen, also schwätzen ech doriwwer op dësem Meetup.
Wien weess wat eng Zäitserie ass? Hie kennt och vill Leit. Eng Zäitserie ass eng Serie vu Pairen (timestamp, значение), wou dës Koppelen no Zäit zortéiert ginn. De Wäert ass eng Floating Point Zuel - float64.
All Zäitserie gëtt eenzegaarteg duerch e Schlëssel identifizéiert. Aus wat besteet dëse Schlëssel? Et besteet aus engem net eidelen Set vu Schlësselwäertpaaren.
Hei ass e Beispill vun enger Zäitserie. De Schlëssel vun dëser Serie ass eng Lëscht vu Pairen: __name__="cpu_usage" ass den Numm vun der Metrik, instance="my-server" - dëst ass de Computer op deem dës Metrik gesammelt gëtt, datacenter="us-east" - dëst ass den Datenzenter wou dëse Computer läit.
Mir hunn op en Enn mat engem Zäitserienumm aus dräi Schlësselwäertpaaren besteet. Dëse Schlëssel entsprécht enger Lëscht vu Pairen (timestamp, value). t1, t3, t3, ..., tN - dëst sinn Zäitstempel, 10, 20, 12, ..., 15 - déi entspriechend Wäerter. Dëst ass d'Cpu-Notzung zu enger bestëmmter Zäit fir eng bestëmmte Rei.
Wou kann Zäit Serie benotzt ginn? Huet iergendeen eng Iddi?
- An DevOps kënnt Dir CPU, RAM, Netzwierk, rps, Zuel vu Feeler, etc.
- IoT - mir kënnen Temperatur, Drock, Geo Koordinaten an soss eppes moossen.
- Och finanzéieren - mir kënne Präisser fir all Zorte vu Aktien a Währungen iwwerwaachen.
- Zousätzlech kënnen Zäitreihe benotzt ginn fir d'Produktiounsprozesser an de Fabriken ze iwwerwaachen. Mir hunn Benotzer déi VictoriaMetrics benotzen Wandturbinen ze kontrolléieren, fir Roboteren.
- Zäitreihe sinn och nëtzlech fir Informatioun vu Sensoren vu verschiddenen Apparater ze sammelen. Zum Beispill, fir e Motor; fir d'Messung vun de Pneuendrock; fir Geschwindegkeet, Distanz ze moossen; fir Benzinverbrauch ze moossen etc.
- Zäitserie kann och benotzt ginn fir Fligeren ze iwwerwaachen. All Fliger huet eng schwaarz Këscht déi Zäitreihe fir verschidde Parameteren vun der Gesondheet vum Fliger sammelt. Zäit Serien ginn och an der Raumfaartindustrie benotzt.
- Gesondheetsversuergung ass Blutdrock, Puls, etc.
Et kënne méi Applikatiounen sinn, déi ech vergiess hunn, awer ech hoffen Dir verstitt datt d'Zäitserie aktiv an der moderner Welt benotzt gëtt. An de Volume vun hirer Notzung wiisst all Joer.
Firwat braucht Dir eng Zäit Serie Datebank? Firwat kënnt Dir net eng regulär relational Datebank benotzen fir Zäitreihe ze späicheren?
Well Zäitreihe normalerweis eng grouss Quantitéit un Informatioun enthalen, déi schwéier a konventionell Datenbanken ze späicheren an ze veraarbechten. Dofir sinn spezialiséiert Datenbanken fir Zäitreihe opgetaucht. Dës Basen späicheren effektiv Punkten (timestamp, value) mat dem bestëmmte Schlëssel. Si bidden eng API fir gespäichert Daten duerch Schlëssel ze liesen, vun engem eenzege Schlësselwäertpaar, oder vu multiple Schlësselwäertpaaren, oder duerch Regexp. Zum Beispill wëllt Dir d'CPU Belaaschtung vun all Äre Servicer an engem Datenzenter an Amerika fannen, da musst Dir dës Pseudo-Query benotzen.
Typesch Zäit Serie Datenbanken bidden spezialiséiert Ufro Sproochen well Zäit Serie SQL ass net ganz gutt gëeegent. Och wann et Datenbanken sinn déi SQL ënnerstëtzen, ass et net ganz gëeegent. Ufro Sprooche wéi , , , . Ech hoffen, datt een op d'mannst eng vun dëse Sproochen héieren huet. Vill Leit hu wahrscheinlech iwwer PromQL héieren. Dëst ass d'Prometheus Query Sprooch.
Dëst ass wéi eng modern Zäitserie Datebankarchitektur ausgesäit mat VictoriaMetrics als Beispill.
Et besteet aus zwee Deeler. Dëst ass Späichere fir den ëmgekéierten Index a Späichere fir Zäitseriewäerter. Dës Repositories sinn getrennt.
Wann en neie Rekord an d'Datebank ukomm ass, kréie mir als éischt den ëmgekéierten Index op fir den Zäitserieidentifizéierer fir e bestëmmte Set ze fannen label=value fir eng bestëmmte Metrik. Mir fannen dësen Identifizéierer a späicheren de Wäert am Dategeschäft.
Wann eng Ufro kënnt fir Daten aus TSDB ze recuperéieren, gi mir als éischt op den ëmgedréint Index. Loosst eis alles kréien timeseries_ids records déi dëse Set passen label=value. An da kréie mir all déi néideg Donnéeën aus dem Datelager, indexéiert vun timeseries_ids.
Loosst eis e Beispill kucken wéi eng Zäitserie-Datebank eng erakommende Selektiounsufro veraarbecht.
- Als éischt kritt hatt alles
timeseries_idsaus engem ëmgedréint Index deen déi gegebene Pairen enthältlabel=value, oder e bestëmmten regulären Ausdrock zefridden stellen. - Duerno recuperéiert et all Datepunkte vun der Datelagerung zu engem bestëmmten Zäitintervall fir déi fonnt
timeseries_ids. - Duerno mécht d'Datebank e puer Berechnungen op dësen Datepunkte, no der Ufro vum Benotzer. An duerno gëtt d'Äntwert zréck.
An dëser Presentatioun wäert ech Iech iwwer den éischten Deel erzielen. Dëst ass eng Sich timeseries_ids duerch ëmgedréint Index. Den zweeten Deel an den drëtten Deel kënnt Dir méi spéit kucken oder waart bis ech aner Berichter preparéieren :)
Loosst eis op den invertéierten Index goen. Vill mengen datt dëst einfach ass. Wien weess wat en ëmgedréint Index ass a wéi et funktionnéiert? Oh, net méi sou vill Leit. Loosst eis probéieren ze verstoen wat et ass.
Et ass eigentlech einfach. Et ass einfach e Wierderbuch dat e Schlëssel fir e Wäert mapt. Wat ass e Schlëssel? Dës Koppel label=valuewou label и value - dëst sinn Linnen. An d'Wäerter sinn e Set timeseries_ids, déi de gegebene Paar enthält label=value.
Inverted Index erlaabt Iech séier alles ze fannen timeseries_ids, déi ginn hunn label=value.
Et erlaabt Iech och séier ze fannen timeseries_ids Zäitserie fir e puer Puer label=value, oder fir Koppelen label=regexp. Wéi geschitt dat? Andeems Dir d'Kräizung vum Set fënnt timeseries_ids fir all Paar label=value.
Loosst eis verschidde Implementatioune vum ëmgekéierten Index kucken. Loosst d'mat der einfachsten naiv Ëmsetzung ufänken. Si gesäit esou aus.
Funktioun getMetricIDs kritt eng Lëscht vu Saiten. All Linn enthält label=value. Dës Funktioun gëtt eng Lëscht zréck metricIDs.
Wéi funktionéiert et? Hei hu mir eng global Variabel genannt invertedIndex. Dëst ass e regelméisseg Wierderbuch (map), déi d'String op Slice Ints mapéiert. D'Linn enthält label=value.
Funktioun Ëmsetzung: kréien metricIDs fir déi éischt label=value, da gi mer duerch alles anescht label=value, mir kréien et metricIDs fir hinnen. A ruffen d'Funktioun intersectInts, déi ënnert diskutéiert ginn. An dës Funktioun gëtt d'Kräizung vun dëse Lëschte zréck.
Wéi Dir kënnt gesinn, ass d'Ëmsetzung vun engem ëmgedréint Index net ganz komplizéiert. Awer dëst ass eng naiv Ëmsetzung. Wéi eng Nodeeler huet et? Den Haaptnodeel vun der naiver Ëmsetzung ass datt sou en ëmgedréint Index am RAM gespäichert ass. Nodeems mir d'Applikatioun nei gestart hunn, verléieren mir dësen Index. Et gëtt keen Spueren vun dësem Index op Disk. Esou en ëmgedréint Index ass onwahrscheinlech gëeegent fir eng Datebank.
Den zweeten Nodeel ass och mat Erënnerung verbonnen. Den ëmgedréint Index muss an RAM passen. Wann et d'Gréisst vum RAM iwwerschreift, da wäerte mir selbstverständlech kréien - aus Erënnerungsfehler. An de Programm wäert net schaffen.
Dëse Problem kann mat prett-feieren Léisungen geléist ginn wéi z , oder .
Kuerz gesot, mir brauchen eng Datebank, déi eis erlaabt dräi Operatiounen séier ze maachen.
- Déi éischt Operatioun ass Opnam
ключ-значениеzu dëser Datebank. Si mécht dat ganz séier, wouключ-значениеsinn arbiträr Saiten. - Déi zweet Operatioun ass eng séier Sich no engem Wäert mat engem bestëmmte Schlëssel.
- An déi drëtt Operatioun ass eng séier Sich no all Wäerter vun engem bestëmmte Präfix.
LevelDB a RocksDB - dës Datenbanken goufen vu Google a Facebook entwéckelt. Éischt koum LevelDB. Dunn hunn d'Jongen vu Facebook LevelDB geholl an ugefaang et ze verbesseren, si hunn RocksDB gemaach. Elo funktionnéieren bal all intern Datenbanken op RocksDB a Facebook, och déi, déi op RocksDB a MySQL transferéiert goufen. Si hunn hien genannt .
En invertéierten Index ka mat LevelDB implementéiert ginn. Wéi maachen ech et? Mir späicheren als Schlëssel label=value. An de Wäert ass den Identifizéierer vun der Zäitserie wou de Pair präsent ass label=value.
Wa mir vill Zäit Serie mat engem bestëmmte Pair hunn label=value, da ginn et vill Reihen an dëser Datebank mat deemselwechte Schlëssel a verschiddene timeseries_ids. Fir eng Lëscht vun all ze kréien timeseries_ids, déi mat dësem ufänken label=prefix, mir maachen e Range Scan fir deen dës Datebank optimiséiert ass. Dat ass, mir wielt all Linnen déi ufänken mat label=prefix a kréien déi néideg timeseries_ids.
Hei ass e Beispill Implementatioun vu wéi et am Go ausgesäit. Mir hunn en ëmgedréint Index. Dëst ass LevelDB.
D'Funktioun ass déiselwecht wéi fir déi naiv Ëmsetzung. Et widderhëlt déi naiv Ëmsetzung bal Linn fir Zeil. Deen eenzege Punkt ass, datt amplaz ze dréien map mir Zougang zu der ëmgedréint Index. Mir kréien all Wäerter fir d'éischt label=value. Da gi mir duerch all déi verbleiwen Pairen label=value a kritt déi entspriechend Sätze vu MetricIDs fir si. Da fanne mir d'Kräizung.
Alles schéngt gutt ze sinn, awer et ginn Nodeeler fir dës Léisung. VictoriaMetrics huet am Ufank en ëmgedréint Index implementéiert baséiert op LevelDB. Awer um Enn hunn ech et missen opginn.
Firwat? Well LevelDB ass méi lues wéi déi naiv Ëmsetzung. An enger naiver Ëmsetzung, mat engem bestëmmte Schlëssel, recuperéieren mir direkt de ganze Slice metricIDs. Dëst ass eng ganz séier Operatioun - de ganze Slice ass prett fir ze benotzen.
Am LevelDB, all Kéier wann eng Funktioun genannt gëtt GetValues Dir musst duerch all Linnen goen, déi mat ufänken label=value. A kritt de Wäert fir all Linn timeseries_ids. Vun esou timeseries_ids sammelen e Stéck vun dësen timeseries_ids. Natierlech ass dëst vill méi lues wéi einfach Zougang zu enger regulärer Kaart mam Schlëssel.
Den zweeten Nodeel ass datt LevelDB an C geschriwwe gëtt. C-Funktioune vu Go uruffen ass net ganz séier. Et dauert Honnerte vun Nanosekonnen. Dëst ass net ganz séier, well am Verglach mat engem reguläre Funktiounsopruff geschriwwe ginn, deen 1-5 Nanosekonnen dauert, ass den Ënnerscheed an der Leeschtung Zéngfach. Fir VictoriaMetrics war dëst e fatale Feeler :)
Also hunn ech meng eegen Ëmsetzung vum ëmgekéierten Index geschriwwen. An hien huet hir genannt .
Mergeset baséiert op der MergeTree Datenstruktur. Dës Datestruktur gëtt aus ClickHouse geléint. Selbstverständlech soll Mergeset fir séier Sich optimiséiert ginn timeseries_ids no dem bestëmmte Schlëssel. Mergeset ass ganz a Go geschriwwen. Du kanns gesinn . D'Ëmsetzung vu Mergeset ass am Dossier . Dir kënnt probéieren erauszefannen wat do lass ass.
De Mergeset API ass ganz ähnlech wéi LevelDB a RocksDB. Dat ass, et erlaabt Iech séier nei records do ze retten a séier records vun engem bestëmmte Präfix auswielen.
Mir schwätzen iwwer d'Nodeeler vum Mergeset méi spéit. Loosst eis elo schwätzen iwwer wéi eng Probleemer mat VictoriaMetrics an der Produktioun entstane sinn wann Dir en ëmgedréint Index implementéiert.
Firwat sinn se entstanen?
Den éischte Grond ass den héije Churn Taux. Iwwersat op Russesch, ass dëst eng heefeg Ännerung vun Zäit Serie. Dëst ass wann eng Zäitserie ophält an eng nei Serie ufänkt, oder vill nei Zäitreihe fänken un. An dëst geschitt dacks.
Déi zweet Ursaach ass déi grouss Zuel vun Zäit Serien. Am Ufank, wann d'Iwwerwaachung Popularitéit gewonnen huet, war d'Zuel vun Zäitreihe kleng. Zum Beispill, fir all Computer musst Dir CPU, Erënnerung, Netzwierk an Diskbelaaschtung iwwerwaachen. 4 Zäit Serie pro Computer. Loosst d'soen Dir hutt 100 Computeren an 400 Zäit Serie. Dëst ass ganz wéineg.
Mat der Zäit hunn d'Leit erausfonnt datt se méi granulär Informatioun moossen. Zum Beispill moosst d'Laascht net vum ganze Prozessor, awer getrennt vun all Prozessorkär. Wann Dir 40 Prozessor Cores hutt, da hutt Dir 40 Mol méi Zäitserie fir d'Prozessorbelaaschtung ze moossen.
Mä dat ass net alles. All Prozessor Kär kann e puer Staaten hunn, wéi Idle, wann et Idle ass. A schafft och am Benotzerraum, schafft am Kernelraum an aner Staaten. An all esou Staat kann och als separat Zäit Serie gemooss ginn. Dëst erhéicht zousätzlech d'Zuel vun de Reihen ëm 7-8 Mol.
Vun enger Metrik hu mir 40 x 8 = 320 Metriken fir just ee Computer. Multiplizéieren mat 100, mir kréien 32 amplaz 000.
Dunn koumen Kubernetes. An et ass verschlechtert ginn well Kubernetes vill verschidde Servicer kënne hosten. All Service zu Kubernetes besteet aus ville Pods. An dat alles muss iwwerwaacht ginn. Zousätzlech hu mir e konstante Détachement vun neie Versioune vun Äre Servicer. Fir all nei Versioun muss nei Zäitserie erstallt ginn. Als Resultat, d'Zuel vun Zäit Serie wiisst exponentially a mir sinn mat de Problem vun enger grousser Zuel vun Zäit Serie konfrontéiert, déi héich-Kardinalitéit genannt ass. VictoriaMetrics copes et erfollegräich am Verglach mat anere Zäit Serie Datenbanken.
Loosst eis den héije Churn Taux méi no kucken. Wat verursaacht en héije Churn Taux an der Produktioun? Well e puer Bedeitunge vun Etiketten an Tags dauernd änneren.
Huelt zum Beispill Kubernetes, deen d'Konzept huet deployment, dh wann eng nei Versioun vun Ärer Applikatioun ausgerullt gëtt. Aus e puer Grënn hunn d'Kubernetes Entwéckler décidéiert d'Deployment ID op de Label ze addéieren.
Wat huet dat gefouert? Ausserdeem, mat all neien Deployment, ginn all déi al Zäitreihe ënnerbrach, an amplaz vun hinnen fänken déi nei Zäitserie mat engem neie Labelwäert un. deployment_id. Et kann honnerte vun dausende an esouguer Millioune vun esou Zeile ginn.
Déi wichteg Saach iwwer all dëst ass datt d'total Zuel vun Zäitreihe wiisst, awer d'Zuel vun Zäitreihen déi momentan aktiv sinn an Daten kréien, bleift konstant. Dëse Staat gëtt héich Churn Taux genannt.
Den Haaptproblem vum héije Churnrate ass eng konstant Sichgeschwindegkeet fir all Zäitserie fir e bestëmmte Set vun Etiketten iwwer e gewëssen Zäitintervall ze garantéieren. Normalerweis ass dëst den Zäitintervall fir déi lescht Stonn oder de leschten Dag.
Wéi dëse Problem ze léisen? Hei ass déi éischt Optioun. Dëst ass fir den ëmgedréint Index an onofhängeg Deeler iwwer Zäit opzedeelen. Dat ass, e puer Zäitintervall passéiert, mir schaffen mat dem aktuellen ëmgedréint Index fäerdeg. A erstellt en neien ëmgedréint Index. En aneren Zäitintervall passéiert, mir kreéieren en aneren an en aneren.
A wa mir aus dësen ëmgedréint Indizes probéieren, fanne mir eng Rei vun invertéierten Indizes déi am gegebene Intervall falen. An deementspriechend wielt mir d'ID vun der Zäitserie vun do aus.
Dëst spuert Ressourcen well mir net op Deeler musse kucken déi net am bestëmmten Intervall falen. Dat ass, normalerweis, wa mir Daten fir déi lescht Stonn auswielen, da sprange mir fir virdrun Zäitintervaller Ufroen.
Et gëtt eng aner Optioun fir dëse Problem ze léisen. Dëst ass fir all Dag eng separat Lëscht vun Ids vun Zäitreihe ze späicheren déi op deem Dag geschitt sinn.
De Virdeel vun dëser Léisung iwwer déi viregt Léisung ass datt mir keng Zäitserieinformatioun duplizéieren déi net mat der Zäit verschwannen. Si sinn stänneg präsent an änneren net.
Den Nodeel ass datt sou eng Léisung méi schwéier ass ze implementéieren a méi schwéier ze debuggen. An VictoriaMetrics huet dës Léisung gewielt. Dëst ass wéi et historesch geschitt ass. Dës Léisung funktionnéiert och gutt am Verglach mat der viregter. Well dës Léisung net ëmgesat gouf wéinst der Tatsaach datt et néideg ass fir Daten an all Partition fir Zäitreihen ze duplizéieren déi net änneren, also déi net mat der Zäit verschwannen. VictoriaMetrics gouf haaptsächlech fir Disk Space Konsum optimiséiert, an déi viregt Implementatioun huet den Disk Space Konsum verschlechtert. Awer dës Implementatioun ass besser fir den Disk Space Konsum ze minimiséieren, sou datt se gewielt gouf.
Ech hu misse géint hatt kämpfen. De Kampf war datt Dir an dëser Ëmsetzung nach ëmmer eng vill méi grouss Zuel muss wielen timeseries_ids fir Daten wéi wann den ëmgedréint Index Zäit opgedeelt ass.
Wéi hu mir dëse Problem geléist? Mir hunn et op eng originell Manéier geléist - andeems mir e puer Zäitserieidentifizéierer an all ëmgedréint Indexentrée amplaz vun engem Identifizéierer späicheren. Dat ass, mir hunn e Schlëssel label=value, déi an all Zäitreihe geschitt. An elo spuere mir e puer timeseries_ids an engem Entrée.
Hei ass e Beispill. Virdrun hate mir N Entréen, awer elo hu mir eng Entrée, deem säi Präfix d'selwecht ass wéi all déi aner. Fir déi viregt Entrée enthält de Wäert all Zäitserie IDen.
Dëst huet et méiglech gemaach d'Scannengeschwindegkeet vun esou engem ëmgedréint Index bis zu 10 Mol ze erhéijen. An et huet eis erlaabt Erënnerungsverbrauch fir de Cache ze reduzéieren, well elo späichere mir de String label=value nëmmen eemol am Cache zesummen N mol. An dës Linn kann grouss sinn wann Dir laang Zeilen an Ären Tags an Etiketten späichert, déi Kubernetes gär dohinner dréckt.
Eng aner Optioun fir d'Sich op engem ëmgekéierten Index ze beschleunegen ass Sharding. Erstellt e puer ëmgedréint Indexen amplaz vun engem an sharding Daten tëscht hinnen duerch Schlëssel. Dëst ass e Set key=value Damp. Dat ass, mir kréien e puer onofhängeg ëmgedréint Indexen, déi mir parallel op verschiddene Prozessoren Ufro kënnen. Virdrun Implementatiounen erlaabt nëmmen Operatioun am Single-Prozessor Modus, dh Scannen Daten op nëmmen engem Kär. Dës Léisung erlaabt Iech Daten op e puer Käre gläichzäiteg ze scannen, sou wéi ClickHouse gär mécht. Dëst ass wat mir plangen ëmzesetzen.
Loosst eis elo zréck op eis Schof - op d'Kräizungsfunktioun timeseries_ids. Loosst eis kucken wéi eng Implementatiounen et kënne sinn. Dës Funktioun erlaabt Iech ze fannen timeseries_ids fir e bestëmmte Set label=value.
Déi éischt Optioun ass eng naiv Ëmsetzung. Zwee verstoppt Schleifen. Hei kréie mir d'Funktiounsinput intersectInts zwee Scheiwen - a и b. Beim Ausgang sollt et eis d'Kräizung vun dëse Scheiwen zréckginn.
Eng naiv Ëmsetzung gesäit esou aus. Mir iteréieren iwwer all Wäerter aus Slice a, bannent dëser Loop gi mir duerch all d'Wäerter vum Slice b. A mir vergläichen se. Wa se passen, dann hu mir eng Kräizung fonnt. A späichert et an result.
Wat sinn d'Nodeeler? Quadratesch Komplexitéit ass säin Haapt Nodeel. Zum Beispill, wann Är Dimensiounen Slice sinn a и b eng Millioun op enger Zäit, da gëtt dës Funktioun ni eng Äntwert op Iech zréck. Well et muss eng Billioun Iteratiounen maachen, wat vill ass souguer fir modern Computeren.
Déi zweet Ëmsetzung baséiert op Kaart. Mir kreéieren eng Kaart. Mir setzen all Wäerter aus Slice op dës Kaart a. Da gi mir duerch Slice an enger separater Loop b. A mir kontrolléieren ob dëse Wäert aus Slice ass b op der Kaart. Wann et existéiert, füügt et dann un d'Resultat.
Wat sinn d'Virdeeler? De Virdeel ass datt et nëmmen linear Komplexitéit gëtt. Dat ass, d'Funktioun wäert vill méi séier fir méi grouss Scheiwen ausféieren. Fir eng Millioun Gréisst Slice wäert dës Funktioun an 2 Milliounen Iteratiounen ausféieren, am Géigesaz zu den Billioun Iteratiounen vun der viregter Funktioun.
De Nodeel ass datt dës Funktioun méi Erënnerung erfuerdert fir dës Kaart ze kreéieren.
Den zweeten Nodeel ass déi grouss Overhead fir Hashing. Dësen Nodeel ass net ganz kloer. A fir eis war et och net ganz offensichtlech, also fir d'éischt an VictoriaMetrics war d'Ëmsetzung vun der Kräizung duerch eng Kaart. Awer dann huet d'Profiling gewisen datt d'Haaptprozessor Zäit op d'Kaart geschriwwe gëtt an d'Präsenz vun engem Wäert op dëser Kaart iwwerpréift.
Firwat gëtt CPU Zäit op dëse Plazen verschwend? Well Go mécht eng hashing Operatioun op dëse Linnen. Dat ass, et berechent den Hash vum Schlëssel fir dann op e bestëmmten Index an der HashMap Zougang ze kréien. D'Hash Berechnungsoperatioun gëtt an Zénger vun Nanosekonnen ofgeschloss. Dëst ass lues fir VictoriaMetrics.
Ech hu beschloss e Bitset ëmzesetzen deen speziell fir dëse Fall optiméiert ass. Sou gesäit elo d'Kräizung vun zwee Scheiwen aus. Hei kreéiere mir e Bitset. Mir addéieren Elementer vun der éischter Slice. Da kontrolléiere mir d'Präsenz vun dësen Elementer an der zweeter Slice. A fügen se un d'Resultat. Dat ass, et ass bal net anescht wéi dat viregt Beispill. Déi eenzeg Saach hei ass datt mir den Zougang zu der Kaart mat personaliséierte Funktiounen ersat hunn add и has.
Op den éischte Bléck schéngt et datt dëst méi lues funktionnéiert, wann virdrun eng Standardkaart do benotzt gouf, an da ginn e puer aner Funktiounen genannt, awer d'Profiling weist datt dës Saach 10 Mol méi séier funktionnéiert wéi d'Standardkaart am Fall vun VictoriaMetrics.
Zousätzlech benotzt et vill manner Erënnerung am Verglach mat der Kaartimplementatioun. Well mir späichere Bits hei amplaz vun aacht-Byte Wäerter.
Den Nodeel vun dëser Ëmsetzung ass datt et net sou offensichtlech ass, net trivial.
En aneren Nodeel, dee vill vläicht net bemierken, ass datt dës Ëmsetzung an e puer Fäll net gutt funktionnéiert. Dat ass, et ass fir e spezifesche Fall optimiséiert, fir dëse Fall vun Kräizung vun VictoriaMetrics Zäit Serie IDen. Dëst bedeit net datt et fir all Fäll gëeegent ass. Wann et falsch benotzt gëtt, wäerte mir keng Leeschtungserhéijung kréien, awer en aus Erënnerungsfehler an e Verloscht vun der Leeschtung.
Loosst eis d'Ëmsetzung vun dëser Struktur betruechten. Wann Dir wëllt kucken, ass et an de VictoriaMetrics Quellen, am Dossier . Et ass speziell fir de VictoriaMetrics Fall optimiséiert, wou timeseries_id ass e 64-Bit Wäert, wou déi éischt 32 Bits grondsätzlech konstant sinn an nëmmen déi lescht 32 Bits änneren.
Dës Datestruktur gëtt net op Disk gespäichert, et funktionnéiert nëmmen an der Erënnerung.
Hei ass seng API. Et ass net ganz komplizéiert. D'API ass speziell op e spezifescht Beispill fir VictoriaMetrics benotzt. Dat ass, et gi keng onnéideg Funktiounen hei. Hei sinn d'Funktiounen déi explizit vu VictoriaMetrics benotzt ginn.
Et gi Funktiounen add, déi nei Wäerter bäidréit. Et gëtt eng Funktioun has, déi fir nei Wäerter kontrolléiert. An et gëtt eng Funktioun del, déi Wäerter läscht. Et gëtt eng Hëllefsfunktioun len, déi d'Gréisst vum Set zréckginn. Funktioun clone klonen vill. A Funktioun appendto konvertéiert dëse Set op Slice timeseries_ids.
Dëst ass wéi d'Ëmsetzung vun dëser Datestruktur ausgesäit. Set huet zwee Elementer:
-
ItemsCountass en Helferfeld fir d'Zuel vun den Elementer an engem Set séier zréckzekommen. Et wier méiglech ouni dëst Hilfsfeld ze maachen, awer et muss hei bäigefüügt ginn, well VictoriaMetrics dacks d'Bitsetlängt a sengen Algorithmen ufroen. -
Déi zweet Feld ass
buckets. Dëst ass Slice vun der Strukturbucket32. All Struktur GeschäfterhiFeld. Dëst sinn déi iewescht 32 Bits. An zwee Scheiwen -b16hisиbucketsausbucket16Strukturen.
Déi Top 16 Bits vum zweeten Deel vun der 64-Bit Struktur ginn hei gespäichert. An hei ginn Bitsets fir déi ënnescht 16 Bits vun all Byte gespäichert.
Bucket64 besteet aus enger Array uint64. D'Längt gëtt mat dëse Konstanten berechent. An engem bucket16 maximal kann gespäichert ginn 2^16=65536 bëssen. Wann Dir dëst mat 8 deelt, dann ass et 8 Kilobytes. Wann Dir nach eng Kéier mat 8 deelt, ass et 1000 uint64 Bedeitung. Dat ass Bucket16 - dëst ass eis 8-Kilobyte Struktur.
Loosst eis kucken wéi eng vun de Methode vun dëser Struktur fir en neie Wäert derbäigesat gëtt.
Et fänkt alles mat uint64 Bedeitungen. Mir berechnen déi iewescht 32 Bits, mir berechnen déi ënnescht 32 Bits. Loosst eis alles duerchgoen buckets. Mir vergläichen déi Top 32 Bits an all Eemer mam Wäert, deen dobäigesat gëtt. A wa se passen, da ruffe mir d'Funktioun add an der Struktur b32 buckets. A fügen déi ënnescht 32 Bits dohinner. A wann et zréck true, dann heescht dat, datt mir esou e Wäert do bäigefüügt hunn a mir net esou e Wäert haten. Wann et zréck false, dann gouf et schonn esou eng Bedeitung. Dann erhéijen mir d'Zuel vun Elementer an der Struktur.
Wa mir deen deen Dir braucht net fonnt hunn bucket mat dem erfuerderlechen Hi-Wäert, da ruffe mir d'Funktioun addAlloc, déi en neien produzéiere wäert bucket, fügen se an d'Eemer Struktur.
Dëst ass d'Ëmsetzung vun der Funktioun b32.add. Et ass ähnlech mat der viregter Ëmsetzung. Mir berechnen déi bedeitendst 16 Bits, déi mannst bedeitend 16 Bits.
Da gi mir duerch all déi iewescht 16 Bits. Mir fannen Matcher. A wann et e Match ass, ruffe mir d'Add-Method, déi mir op der nächster Säit betruechten bucket16.
An hei ass den niddregsten Niveau, dee sou vill wéi méiglech optimiséiert soll ginn. Mir rechnen fir uint64 ID Wäert am Slice Bit an och bitmask. Dëst ass eng Mask fir e bestëmmte 64-Bit Wäert, déi benotzt ka ginn fir d'Präsenz vun dësem Bit z'iwwerpréiwen oder ze setzen. Mir kontrolléieren fir ze kucken ob dëst Bit agestallt ass a setzt se, a Präsenz zréck. Dëst ass eis Implementatioun, déi et eis erlaabt huet d'Operatioun vun de Kräizungs-IDen vun der Zäitserie ëm 10 Mol am Verglach mat konventionelle Kaarten ze beschleunegen.
Zousätzlech zu dëser Optimiséierung huet VictoriaMetrics vill aner Optimisatiounen. Déi meescht vun dësen Optimisatiounen goufen aus engem Grond bäigefüügt, awer nodeems de Code an der Produktioun profiléiert gouf.
Dëst ass d'Haaptregel vun der Optimiséierung - füügt keng Optimiséierung derbäi, wann ugeholl datt et hei e Flaschenhals gëtt, well et ka sech erausstellen datt et kee Flaschenhals do gëtt. Optimisatioun degradéiert normalerweis d'Qualitéit vum Code. Dofir ass et derwäert ze optimiséieren nëmmen no der Profiléierung an am léifsten an der Produktioun, sou datt dëst richteg Daten ass. Wann iergendeen interesséiert ass, kënnt Dir de VictoriaMetrics Quellcode kucken an aner Optimisatiounen entdecken déi do sinn.
Ech hunn eng Fro iwwer Bitset. Ganz ähnlech zu der C ++ Vector bool Ëmsetzung, optimiséiert Bitset. Hutt Dir d'Ëmsetzung vun do geholl?
Nee, net vun do aus. Wann ech dëse Bitset ëmsetzen, gouf ech vum Wëssen iwwer d'Struktur vun dësen Id-Timeseries guidéiert, déi a VictoriaMetrics benotzt ginn. An hir Struktur ass sou datt déi iewescht 32 Bits grondsätzlech konstant sinn. Déi ënnescht 32 Bits ënnerleien ze änneren. Wat méi niddereg ass, dest méi dacks kann et änneren. Dofir ass dës Implementatioun speziell fir dës Datestruktur optimiséiert. D'C ++ Ëmsetzung, souwäit ech weess, ass fir den allgemenge Fall optimiséiert. Wann Dir fir den allgemenge Fall optiméiert, heescht dat datt et net déi optimalst fir e spezifesche Fall ass.
Ech roden Iech och de Bericht vum Alexey Milovid ze kucken. Virun engem Mount huet hien iwwer Optimisatioun am ClickHouse fir spezifesch Spezialisatiounen geschwat. Hie seet just datt am allgemenge Fall eng C++ Implementatioun oder eng aner Implementatioun ugepasst ass fir am Duerchschnëtt gutt an engem Spidol ze schaffen. Et ka méi schlëmm Leeschtunge wéi eng Wëssensspezifesch Implementatioun wéi eis, wou mir wëssen datt déi Top 32 Bits meeschtens konstant sinn.
Ech hunn eng zweet Fro. Wat ass de fundamentalen Ënnerscheed vun InfluxDB?
Et gi vill fundamental Differenzen. Am Sënn vun Leeschtung an Erënnerung Konsum weist InfluxDB an Tester 10 Mol méi Erënnerung Konsum fir héich Kardinalitéit Zäit Serie, wann Dir hutt vill vun hinnen, Zum Beispill, Millioune. Zum Beispill verbraucht VictoriaMetrics 1 GB pro Millioun aktiv Zeilen, während InfluxDB 10 GB verbraucht. An dat ass e groussen Ënnerscheed.
Den zweeten fundamentalen Ënnerscheed ass datt InfluxDB komesch Ufro Sproochen huet - Flux an InfluxQL. Si sinn net ganz praktesch fir mat Zäit Serie ze schaffen am Verglach zu , déi vun VictoriaMetrics ënnerstëtzt gëtt. PromQL ass eng Ufrosprooch vum Prometheus.
An e weideren Ënnerscheed ass datt InfluxDB e liicht komeschen Datemodell huet, wou all Linn verschidde Felder mat enger anerer Set Tags späichere kann. Dës Linnen sinn weider an verschidden Dëscher ënnerdeelt. Dës zousätzlech Komplikatioune komplizéiere spéider Aarbecht mat dëser Datebank. Et ass schwéier ze ënnerstëtzen a verstoen.
An VictoriaMetrics ass alles vill méi einfach. Do ass all Zäitserie e Schlësselwäert. De Wäert ass eng Rei vu Punkten - (timestamp, value), an de Schlëssel ass de Set label=value. Et gëtt keng Trennung tëscht Felder a Miessunge. Et erlaabt Iech all Donnéeën ze wielen an dann ze kombinéieren, addéieren, subtrahéieren, multiplizéieren, deelen, am Géigesaz zu InfluxDB wou Berechnungen tëscht verschiddene Reihen nach ëmmer net implementéiert sinn sou wäit wéi ech weess. Och wa se ëmgesat sinn, ass et schwéier, Dir musst vill Code schreiwen.
Ech hunn eng Erklärungsfro. Huet ech richteg verstanen datt et eng Zort Problem war, vun deem Dir geschwat hutt, datt dësen ëmgedréint Index net an d'Erënnerung passt, also do ass eng Partitionéierung?
Als éischt hunn ech eng naiv Ëmsetzung vun engem ëmgedréint Index op enger Standard Go Kaart gewisen. Dës Implementatioun ass net gëeegent fir Datenbanken, well dësen ëmgekéierten Index net op Disk gespäichert ass, an d'Datebank muss op Disk späicheren, sou datt dës Donnéeën beim Neistart verfügbar bleiwen. An dëser Ëmsetzung, wann Dir d'Applikatioun nei start, wäert Ären ëmgedréint Index verschwannen. An Dir wäert den Zougang zu all Daten verléieren, well Dir se net fanne wäert.
Hallo! Merci fir de Bericht! Mäin Numm ass Pavel. Ech sinn aus Wildberries. Ech hunn e puer Froen fir Iech. Fro eng. Denkt Dir datt wann Dir en anere Prinzip gewielt hutt wann Dir d'Architektur vun Ärer Applikatioun baut an d'Daten mat der Zäit partitionéiert hätt, da wier Dir vläicht fäeg Donnéeën ze intersectéieren wann Dir sicht, baséiert nëmmen op der Tatsaach datt eng Partition Daten fir een enthält Zäitperiod , dat ass, an engem Zäitintervall an Dir musst Iech keng Suergen iwwer d'Tatsaach maachen datt Är Stécker anescht verspreet sinn? Fro Nummer 2 - well Dir en ähnlechen Algorithmus mat Bitset an alles anescht implementéiert, da probéiert Dir vläicht Prozessorinstruktiounen ze benotzen? Vläicht hutt Dir esou Optimisatiounen probéiert?
Ech äntweren déi zweet direkt. Mir sinn nach net op dee Punkt ukomm. Awer wann néideg, komme mir dohinner. An déi éischt, wat war d'Fro?
Dir hutt zwee Szenarie diskutéiert. A si soten datt se déi zweet mat enger méi komplexer Ëmsetzung gewielt hunn. A si hunn net déi éischt léiwer, wou d'Donnéeën duerch Zäit opgedeelt sinn.
Jo. Am éischte Fall wier de Gesamtvolumen vum Index méi grouss, well an all Partition musse mir duplizéiert Daten fir déi Zäitreihe späicheren, déi duerch all dës Partitionen weidergoen. A wann Är Zäitserie Churn Taux kleng ass, dh déi selwecht Serie gi stänneg benotzt, da wäerte mir am éischte Fall vill méi verléieren an der Quantitéit vun der Disk Space besat am Verglach zum zweete Fall.
An dofir - jo, Zäitpartitionéierung ass eng gutt Optioun. Prometheus benotzt et. Awer Prometheus huet en aneren Nodeel. Wann Dir dës Stécker vun Daten fusionéiert, muss et Meta-Informatioune fir all Etiketten an Zäitserie an Erënnerung behalen. Dofir, wann d'Stécker vun Daten, déi et fusionéiert, grouss sinn, erhéicht de Gedächtnisverbrauch ganz vill wärend der Fusioun, am Géigesaz zu VictoriaMetrics. Beim Fusioun verbraucht VictoriaMetrics guer net Erënnerung; nëmmen e puer Kilobyte gi verbraucht, onofhängeg vun der Gréisst vun de fusionéierte Stécker vun Daten.
Den Algorithmus deen Dir benotzt benotzt Erënnerung. Et markéiert Zäitserie Tags déi Wäerter enthalen. An op dës Manéier kontrolléiert Dir op gepaart Präsenz an engem Datarray an an engem aneren. An Dir verstitt ob Kräizung geschitt ass oder net. Typesch implementéieren Datenbanken Cursoren an Iteratoren déi hiren aktuellen Inhalt späicheren an duerch déi zortéiert Donnéeë lafen wéinst der einfacher Komplexitéit vun dësen Operatiounen.
Firwat benotze mir net Cursoren fir Daten duerchzegoen?
Jo.
Mir späicheren zortéiert Reihen am LevelDB oder Mergeset. Mir kënnen de Cursor bewegen an d'Kräizung fannen. Firwat benotze mir et net? Well et ass lues. Well Cursoren heescht, datt Dir eng Funktioun fir all Linn ruffen muss. E Funktiounsopruff ass 5 Nanosekonnen. A wann Dir 100 Linnen hutt, da stellt sech eraus datt mir eng hallef Sekonn just d'Funktioun ruffen.
Et gëtt esou eppes, jo. A meng lescht Fro. D'Fro kléngt vläicht e bësse komesch. Firwat ass et net méiglech all déi néideg Aggregaten ze liesen am Moment wou d'Donnéeën ukommen an se an der erfuerderter Form späicheren? Firwat enorm Bänn spueren an e puer Systemer wéi VictoriaMetrics, ClickHouse, etc., an dann vill Zäit op hinnen verbréngen?
Ech ginn e Beispill fir et méi kloer ze maachen. Loosst eis soen wéi funktionnéiert e klenge Speedometer? Et registréiert d'Distanz déi Dir gereest hutt, déi ganzen Zäit bäidréit et zu engem Wäert, an déi zweet - Zäit. An deelt. A kritt duerchschnëttlech Vitesse. Dir kënnt ongeféier déi selwecht Saach maachen. Füügt all déi néideg Fakten op der Flucht.
Okay, ech verstinn d'Fro. Äert Beispill huet seng Plaz. Wann Dir wësst wat Aggregaten Dir braucht, dann ass dëst déi bescht Ëmsetzung. Awer de Problem ass datt d'Leit dës Metriken späicheren, e puer Donnéeën am ClickHouse a si wësse nach net wéi se se an Zukunft aggregéiert a filteren, sou datt se all déi rau Donnéeën späicheren. Awer wann Dir wësst datt Dir eppes am Duerchschnëtt muss berechnen, firwat berechent et dann net anstatt eng Rëtsch Matière Wäerter do ze späicheren? Awer dëst ass nëmmen wann Dir wësst genau wat Dir braucht.
Iwwregens, Datenbanken fir d'Späichere vun der Zäitreihe ënnerstëtzen d'Zuel vun den Aggregaten. Zum Beispill ënnerstëtzt Prometheus . Dat ass, dëst kann gemaach ginn wann Dir wësst wat Unitéiten Dir braucht. VictoriaMetrics huet dëst nach net, awer et gëtt normalerweis vum Prometheus virausgesot, an deem dëst an de Recodéierungsregele gemaach ka ginn.
Zum Beispill, a menger viregter Aarbecht brauch ech d'Zuel vun den Eventer an enger rutschen Fënster iwwer déi lescht Stonn ze zielen. De Problem ass datt ech eng personaliséiert Implementatioun am Go muss maachen, dat heescht e Service fir dës Saach ze zielen. Dëse Service war schlussendlech net trivial, well et schwéier ass ze berechnen. D'Ëmsetzung kann einfach sinn wann Dir e puer Aggregaten a fixen Zäitintervaller ziele musst. Wann Dir Eventer an enger Schieberfenster ziele wëllt, dann ass et net sou einfach wéi et schéngt. Ech mengen dat ass nach net a ClickHouse oder an Zäitserie-Datenbanken ëmgesat ginn, well et schwéier ëmzesetzen ass.
An nach eng Fro. Mir hu just iwwer d'Duerchschnëtt geschwat, an ech hu mech drun erënnert datt et eemol sou eppes war wéi Graphite mat engem Kuelestoff-Backend. An hie wousst, wéi een al Donnéeën ausdënnegt, dat heescht, ee Punkt pro Minutt, ee Punkt pro Stonn, asw. ausgedünnt ginn. Awer Prometheus a VictoriaMetrics ënnerstëtzen dës Funktionalitéit net. Ass et geplangt et z'ënnerstëtzen? Wann net, firwat net?
Merci fir d'Fro. Eis Benotzer stellen dës Fro periodesch. Si froe wéini mir Ënnerstëtzung fir Downsampling addéieren. Et gi verschidde Problemer hei. Éischtens, all Benotzer versteet downsampling eppes anescht: een wëll all arbiträr Punkt op engem bestëmmten Intervall kréien, een wëll maximal, Minimum, Moyenne Wäerter. Wa vill Systemer Daten op Är Datebank schreiwen, da kënnt Dir et net alles zesummeklappen. Et kann sinn, datt all System verschidden thinning verlaangt. An dëst ass schwéier ëmzesetzen.
An déi zweet Saach ass datt VictoriaMetrics, wéi ClickHouse, optimiséiert ass fir mat grousse Volumen vu Rohdaten ze schaffen, sou datt et eng Milliard Linnen a manner wéi enger Sekonn ka schëdden wann Dir vill Kären an Ärem System hutt. Scannen Zäit Serie Punkten an VictoriaMetrics - 50 Punkten pro Sekonn pro Kär. An dës Leeschtung skaléiert op existent Kären. Dat ass, wann Dir hutt 000 Kär, zum Beispill, Scanner Dir eng Milliard Punkten pro Sekonn. An dëser Propriétéit vun VictoriaMetrics an ClickHouse reduzéiert de Besoin fir downsamling.
Eng aner Feature ass datt VictoriaMetrics dës Donnéeën effektiv kompriméiert. Kompressioun am Duerchschnëtt an der Produktioun ass vun 0,4 bis 0,8 Bytes pro Punkt. All Punkt ass en Zäitstempel + Wäert. An et ass am Duerchschnëtt a manner wéi ee Byte kompriméiert.
Sergey. Ech hunn eng Fro. Wat ass de Minimum Opnamzäit Quantephysik?
Eng Millisekonnen. Mir haten viru kuerzem e Gespréich mat aneren Zäitserie Datebank Entwéckler. Hir Minimum Zäit Slice ass eng Sekonn. An am Graphite, zum Beispill, ass et och eng Sekonn. An OpenTSDB ass et och eng Sekonn. InfluxDB huet Nanosekonne Präzisioun. A VictoriaMetrics ass et eng Millisekonnen, well am Prometheus ass et eng Millisekonnen. A VictoriaMetrics gouf ursprénglech als Fernlagerung fir Prometheus entwéckelt. Awer elo kann et Daten aus anere Systemer späicheren.
Déi Persoun mat deenen ech geschwat hunn seet datt si zweet-zu-zweet Genauegkeet hunn - dat ass genuch fir si, well et hänkt vun der Aart vun Daten of, déi an der Zäitserie Datebank gespäichert ginn. Wann dëst DevOps Daten oder Daten aus Infrastruktur ass, wou Dir se mat Intervalle vun 30 Sekonnen pro Minutt sammelt, dann ass déi zweet Genauegkeet genuch, Dir braucht näischt manner. A wann Dir dës Donnéeën aus Héichfrequenz Handelssystemer sammelt, da braucht Dir Nanosekonne Genauegkeet.
Millisekonne Genauegkeet an VictoriaMetrics ass och gëeegent fir den DevOps Fall, a ka gëeegent sinn fir déi meescht Fäll déi ech am Ufank vum Bericht ernimmt hunn. Déi eenzeg Saach fir déi et net gëeegent ass ass héich Frequenz Handelssystemer.
Merci! An eng aner Fro. Wat ass Kompatibilitéit a PromQL?
Voll Réckkompatibilitéit. VictoriaMetrics ënnerstëtzt voll PromQL. Zousätzlech füügt et zousätzlech fortgeschratt Funktionalitéit an PromQL, déi genannt gëtt . Et gëtt e Gespréich op YouTube iwwer dës erweidert Funktionalitéit. Ech geschwat um Monitoring Meetup am Fréijoer zu St.
Telegramm Kanal .
Nëmme registréiert Benotzer kënnen un der Ëmfro deelhuelen. , wann ech glift.
Wat verhënnert Iech fir op VictoriaMetrics als Är laangfristeg Lagerung fir Prometheus ze wiesselen? (Schreift an de Kommentaren, ech addéieren et an d'Ëmfro))
-
71,4%Ech benotzen net Prometheus5
-
28,6%Wousst net iwwer VictoriaMetrics2
7 Benotzer hunn gestëmmt. 12 Benotzer hu sech enthalen.
Source: will.com