Ons sal kyk hoe Zabbix werk met die TimescaleDB-databasis as 'n backend. Ons sal jou wys hoe om van voor af te begin en hoe om van PostgreSQL af te migreer. Ons verskaf ook vergelykende prestasietoetse van die twee konfigurasies.
HighLoad++ Siberië 2019. Tomsk Hall. 24 Junie, 16:00. Opsommings en . Die volgende HighLoad++-konferensie sal op 6 en 7 April 2020 in St. Petersburg plaasvind. Besonderhede en kaartjies .
Andrey Gushchin (hierna - AG): – Ek is 'n ZABBIX tegniese ondersteuningsingenieur (hierna na verwys as "Zabbix"), 'n afrigter. Ek werk al meer as 6 jaar in tegniese ondersteuning en het direkte ondervinding met prestasie gehad. Vandag sal ek praat oor die prestasie wat TimescaleDB kan lewer in vergelyking met gewone PostgreSQL 10. Ook 'n paar inleidende deel oor hoe dit in die algemeen werk.
Topprestasie-uitdagings: van data-insameling tot data-suiwering
Om mee te begin, is daar sekere prestasie-uitdagings wat elke moniteringstelsel in die gesig staar. Die eerste prestasie-uitdaging is die vinnige insameling en verwerking van data.
'n Goeie moniteringstelsel moet stiptelik en betyds al die data ontvang, dit volgens sneller-uitdrukkings verwerk, dit wil sê, dit volgens sekere kriteria verwerk (dit verskil in verskillende stelsels) en stoor dit in die databasis om hierdie data te gebruik in in die toekoms.
Die tweede prestasie-uitdaging is geskiedenisberging. Stoor gereeld in 'n databasis en kry vinnige en maklike toegang tot hierdie maatstawwe wat oor 'n tydperk ingesamel is. Die belangrikste ding is dat hierdie data gerieflik moet wees om te ontvang, dit te gebruik in verslae, grafieke, snellers, in een of ander soort drempelwaardes, vir waarskuwings, ens.
Die derde prestasie-uitdaging is geskiedenisopruiming, dit wil sê wanneer jy so 'n dag het dat jy nie 'n paar gedetailleerde statistieke hoef te stoor wat oor 5 jaar (selfs maande of twee maande) ingesamel is nie. Sommige netwerknodusse is verwyder, of sommige gashere, metrieke is nie meer nodig nie, want hulle is reeds verouderd en nie meer versamel nie. Dit alles moet skoongemaak word sodat jou databasis nie groot word nie. En oor die algemeen is die skoonmaak van die geskiedenis meestal 'n ernstige toets vir die berging - dit beïnvloed dikwels prestasie baie.
Hoe om kasprobleme op te los?
Ek sal nou spesifiek oor Zabbix praat. In Zabbix word die eerste en tweede oproepe opgelos met behulp van caching.
Data-insameling en verwerking - ons gebruik RAM om al hierdie data te stoor. Hierdie data sal nou in meer besonderhede bespreek word.
Ook aan die databasiskant is daar 'n sekere kas vir die hoofkeuses - vir grafieke, ander dinge.
Kas aan die kant van die Zabbix-bediener self: ons het ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Wat dit is?
ConfigurationCache is die hoofkas waar ons statistieke, gashere, items, snellers stoor; alles wat jy nodig het om voorafverwerking te verwerk, data in te samel, van watter gashere om te versamel, met watter frekwensie. Dit alles word in die ConfigurationCache gestoor om nie na die databasis te gaan nie, om nie onnodige versoeke te skep nie. Nadat die bediener begin het, werk ons hierdie kas op (skep dit) en werk dit gereeld op (afhangende van die konfigurasie-instellings).
Kas in Zabbix. Data-insameling
Hier is die diagram redelik groot:
Die belangrikste in die skema is hierdie samestellers:
Dit is die bouprosesse self, verskeie "pollers" wat verantwoordelik is vir verskillende tipes bouwerk. Hulle samel data in via icmp, ipmi, met behulp van verskillende protokolle en dra dit alles oor na voorafverwerking.
Voorverwerking HistoryCache
Ook, as ons berekende data-elemente het (diegene wat vertroud is met Zabbix weet), dit wil sê, berekende, samevoegingsdata-elemente, neem ons dit direk vanaf ValueCache. Hoe dit gevul word, sal ek later vertel. Al hierdie versamelaars gebruik die ConfigurationCache om hul poste te ontvang en gee dit dan oor na voorafverwerking.
Voorverwerking gebruik ook die ConfigurationCache om voorafverwerkingstappe te kry, en verwerk hierdie data op 'n ander manier. Vanaf weergawe 4.2 het ons dit na 'n instaanbediener geskuif. Dit is baie gerieflik, want voorverwerking self is 'n taamlike swaar operasie. En as jy 'n baie groot Zabbix het, met 'n groot aantal data-items en 'n hoë frekwensie van versameling, dan vergemaklik dit die werk baie.
Gevolglik, nadat ons hierdie data op een of ander manier met voorafverwerking verwerk het, stoor ons dit in HistoryCache om dit verder te verwerk. Dit voltooi die data-insameling. Ons gaan aan na die hoofproses.
Geskiedenis sinchronisasie werking
Die hoofproses in Zabbix (aangesien dit 'n monolitiese argitektuur is) is die Geskiedenis-sincer. Dit is die hoofproses wat handel oor die atoomverwerking van elke data-element, dit wil sê elke waarde:
- waarde kom (hy neem dit uit HistoryCache);
- kontroleer in die konfigurasie-sinchronisasie: as daar enige snellers vir berekening is - bereken dit;
indien teenwoordig, skep gebeurtenisse, skep 'n eskalasie om 'n waarskuwing te skep, indien nodig deur konfigurasie; - skryf snellers vir verdere verwerking, samevoeging; as jy oor die laaste uur ensovoorts saamvoeg, word hierdie waarde deur ValueCache onthou sodat dit nie na die geskiedenistabel gaan nie; dus word die ValueCache gevul met die nodige data wat nodig is om snellers, berekende items, ens. te evalueer;
- dan skryf die History syncer al die data na die databasis;
- die databasis skryf hulle na skyf - dit voltooi die verwerking.
Databasis. kas
Aan die databasiskant, wanneer jy kaarte of 'n soort gebeurtenisverslae wil bekyk, is daar verskeie kas. Maar in die raamwerk van hierdie verslag sal ek nie daaroor praat nie.
Vir MySQL is daar Innodb_buffer_pool, en 'n klomp verskillende kas wat ook gekonfigureer kan word.
Maar dit is die belangrikste:
- gedeelde_buffers;
- effektiewe_kas_grootte;
- gedeelde_poel.
Ek het vir alle databasisse gebring dat daar sekere caches is wat jou toelaat om die data wat dikwels vir navrae benodig word in RAM te hou. Hulle het hul eie tegnologie hiervoor.
Oor databasis prestasie
Gevolglik is daar 'n mededingende omgewing, dit wil sê die Zabbix-bediener versamel data en skryf dit neer. Wanneer dit weer begin word, lees dit ook uit die geskiedenis om die ValueCache te vul en so aan. Net daar kan jy skrifte en verslae hê wat Zabbix-API gebruik, wat op die basis van die webkoppelvlak gebou is. "Zabbix"-API gaan die databasis binne en ontvang die nodige data om grafieke, verslae, of 'n soort lys van gebeure, onlangse probleme te verkry.
Nog 'n baie gewilde visualiseringsoplossing is Grafana, wat deur ons gebruikers gebruik word. In staat om direk in te voer beide deur die "Zabbix" -API, en deur die databasis. Dit skep ook 'n mate van kompetisie om data te kry: fyner, beter databasisinstelling is nodig om by die vinnige aflewering van resultate en toetsing te pas.
Vee geskiedenis uit. Zabbix het huishoudster
Die derde oproep wat in Zabbix gebruik word, is om geskiedenis met Housekeeper skoon te maak. Huishoudster respekteer alle instellings, dit wil sê, in ons data-elemente word aangedui hoeveel om te stoor (in dae), hoe lank om tendense te stoor, en die dinamika van veranderinge.
Ek het nie gepraat oor die TrendCash nie, wat ons dadelik bereken: data kom in, ons versamel dit in een uur (meestal getalle vir die laaste uur), die gemiddelde / minimum bedrag en skryf dit een keer per uur na die tendenstabel ("Tendense"). Die huishoudster begin en vee data uit die databasis uit met die gewone keuses, wat nie altyd effektief is nie.
Hoe om te verstaan dat dit ondoeltreffend is? Jy kan die volgende prentjie op die prestasiegrafieke van interne prosesse sien:
Jou Geskiedenis-sinchroniseerder is voortdurend besig (rooi grafiek). En die "rooi" grafiek wat bo-aan gaan. Dit is die "Housekeeper" wat hardloop en wag vir die databasis om al die rye wat dit gestel het uit te vee.
Kom ons neem 'n paar Item ID: jy moet die laaste 5 duisend uitvee; natuurlik deur indekse. Maar gewoonlik is die datastel redelik groot - die databasis lees dit steeds van skyf af en plaas dit in die kas, en dit is 'n baie duur bewerking vir die databasis. Afhangende van die grootte daarvan, kan dit lei tot sekere prestasieprobleme.
Jy kan Housekeeper op 'n eenvoudige manier deaktiveer - ons het 'n bekende webkoppelvlak vir almal. Instelling in Administrasie-algemeen (Instellings vir "Huishulp") deaktiveer ons interne huishouding vir interne geskiedenis en neigings. Gevolglik bestuur huishoudster dit nie meer nie:
Wat kan volgende gedoen word? Jy het dit afgeskakel, jou grafieke het afgeplat ... Watter probleme kan daar in hierdie geval wees? Wat kan help?
Partisionering (partisionering)
Dit word gewoonlik op elke relasionele databasis opgestel wat ek op 'n ander manier gelys het. MySQL het sy eie tegnologie. Maar oor die algemeen is hulle baie soortgelyk wanneer dit kom by PostgreSQL 10 en MySQL. Natuurlik is daar baie interne verskille, hoe dit alles geïmplementeer word en hoe dit alles prestasie beïnvloed. Maar oor die algemeen lei die skep van 'n nuwe partisie dikwels ook tot sekere probleme.
Afhangende van jou opstelling (hoeveel data jy op een dag skep), stel hulle gewoonlik die mees minimale - dit is 1 dag / partisie, en vir "tendense" is die dinamika van veranderinge 1 maand / nuwe partisie. Dit kan verander as jy 'n baie groot opstelling het.
Kom ons praat dadelik oor die grootte van die opstelling: tot 5 duisend nuwe waardes per sekonde (sogenaamde nvps) - dit sal as 'n klein "opstelling" beskou word. Medium - van 5 tot 25 duisend waardes per sekonde. Alles hierbo is reeds groot en baie groot installasies wat baie noukeurige tuning van die databasis self vereis.
Op baie groot installasies is 1 dag dalk nie optimaal nie. Ek het persoonlik op MySQL partisies van 40 gigagrepe per dag gesien (en daar kan meer wees). Dit is 'n baie groot hoeveelheid data, wat tot 'n paar probleme kan lei. Dit moet verminder word.
Hoekom is partisie nodig?
Wat partisionering doen, dink ek almal weet, is tafelpartisionering. Dikwels is dit aparte lêers op skyf en spanversoeke. Dit kies een partisie meer optimaal as dit by die normale partisionering ingesluit is.
Vir Zabbix, in die besonder, word dit gebruik deur reeks, deur reeks, dit wil sê, ons gebruik 'n tydstempel ('n gereelde getal, tyd sedert die begin van die epog). Jy spesifiseer begin van dag/einde van dag en dit is die partisie. Gevolglik, as jy toegang tot data van twee dae gelede verkry, word dit alles vinniger uit die databasis gekies, want jy benodig net een lêer om in die kas te laai en te vertoon (eerder as 'n groot tabel).
Baie databasisse bespoedig ook invoeging (invoeging in een kindtabel). Terwyl ek abstrak praat, maar dit is ook moontlik. Partitonering help dikwels.
Elasticsearch vir NoSQL
Onlangs, in 3.4, het ons 'n oplossing vir NoSQL geïmplementeer. Bygevoeg die vermoë om te skryf aan Elasticsearch. Jy kan 'n paar aparte tipes skryf: kies - óf skryf nommers, óf sommige tekens; ons het 'n string teks, jy kan logs in Elasticsearch skryf ... Gevolglik sal die webkoppelvlak ook toegang tot Elasticsearch kry. Dit werk goed in sommige gevalle, maar op die oomblik kan dit gebruik word.
tydskaalb. Hipertabelle
Vir 4.4.2 het ons aandag gegee aan een ding soos TimescaleDB. Wat dit is? Dit is 'n uitbreiding vir Postgres, dit wil sê, dit het 'n inheemse PostgreSQL-koppelvlak. Boonop laat hierdie uitbreiding jou toe om baie meer doeltreffend met tydreeksdata te werk en outomatiese partisionering te hê. Hoe dit lyk:
Dit is hipertabel - daar is so iets in Timescale. Dit is 'n hipertabel wat jy skep, en dit bevat stukke. Chunks is partisies, dit is kindertafels, as ek my nie misgis nie. Dit is regtig effektief.
TimescaleDB en PostgreSQL
Soos TimescaleDB-vervaardigers verseker, gebruik hulle 'n meer korrekte navraagverwerkingsalgoritme, veral insetsels, wat jou toelaat om ongeveer konstante werkverrigting te hê met 'n toenemende datastel-insetselgrootte. Dit wil sê, ná 200 miljoen reëls begin Postgres baie erg sak en verloor werkverrigting letterlik tot nul, terwyl Timescale jou toelaat om insetsels so doeltreffend moontlik met enige hoeveelheid data in te voeg.
Hoe om TimescaleDB te installeer? Alles is eenvoudig!
Hy het dit in die dokumentasie, dit word beskryf - jy kan dit installeer vanaf pakkette vir enige ... Dit hang af van die amptelike Postgres-pakkette. Kan met die hand saamgestel word. Dit het so gebeur dat ek vir die DB moes saamstel.
Op Zabbix aktiveer ons eenvoudig die uitbreiding. Ek dink dat diegene wat Uitbreiding in Postgres gebruik het ... Jy aktiveer net Uitbreiding, skep dit vir die Zabbix-databasis wat jy gebruik.
En die laaste stap...
tydskaalb. Migreer geskiedenistabelle
Jy moet 'n hipertabel skep. Daar is 'n spesiale funksie hiervoor - Skep hipertabel. Spesifiseer daarin, as die eerste parameter, die tabel wat in hierdie databasis benodig word (waarvoor u 'n hipertabel moet skep).
Die veld om te skep en chunk_time_interval (dit is die interval van stukke (partisies wat gebruik moet word). 86 is een dag.
migrate_data parameter: As jy plak na waar, migreer dit alle huidige data in voorafgeskepte stukke.
Ek het self migrate_data gebruik - dit neem 'n ordentlike hoeveelheid tyd, afhangend van hoe groot jou databasis is. Ek het meer as 'n teragreep gehad - dit het meer as 'n uur geneem om te skep. In sommige gevalle, toe ek getoets het, het ek die historiese data vir die teks (geskiedenis_teks) en string (geskiedenis_str) uitgevee om nie oor te dra nie - dit was nie regtig vir my interessant nie.
En ons maak die laaste opdatering in ons db_extention: ons stel timescaledb sodat die databasis en veral ons Zabbix verstaan dat daar 'n db_extention is. Dit aktiveer dit en gebruik die korrekte sintaksis en navrae na die databasis, en gebruik reeds daardie "kenmerke" wat nodig is vir TimescaleDB.
Bedienerkonfigurasie
Ek het twee bedieners gebruik. Die eerste bediener is 'n taamlik klein virtuele masjien, 20 verwerkers, 16 gigagrepe RAM. Stel Postgres 10.8 daarop op:
Die bedryfstelsel was Debian, die lêerstelsel was xfs. Ek het die minimum instellings gemaak om hierdie spesifieke databasis te gebruik, minus wat Zabbix self sal gebruik. Op dieselfde masjien was daar 'n Zabbix-bediener, PostgreSQL en laaiagente.
Ek het 50 aktiewe agente gebruik wat LoadableModule gebruik om vinnig verskillende resultate te genereer. Dit was hulle wat die snare, getalle, ensovoorts gegenereer het. Ek het die databasis met baie data gevul. Aanvanklik het die konfigurasie 5 duisend data-items per gasheer bevat, en omtrent elke data-item het 'n sneller bevat - sodat dit 'n regte opstelling kon wees. Soms neem dit selfs meer as een sneller om te gebruik.
Ek het die opdateringsinterval, die las self, gereguleer deur nie net 50 agente te gebruik nie (meer by te voeg), maar ook dinamiese data-elemente te gebruik en die opdateringsinterval tot 4 sekondes te verminder.
Optredetoets. PostgreSQL: 36k NVP's
Die eerste lopie, die eerste opstelling wat ek gehad het, was op suiwer PostreSQL 10 op hierdie hardeware (35 duisend waardes per sekonde). Oor die algemeen, soos jy op die skerm kan sien, neem die invoeging van data breukdele van 'n sekonde - alles is goed en vinnig, SSD-dryf (200 gigagrepe). Die enigste ding is dat 20 GB vinnig genoeg vol raak.
Daar sal in die toekoms baie sulke kaarte wees. Dit is die standaard werkverrigting dashboard van die Zabbix-bediener.
Die eerste grafiek is die aantal waardes per sekonde (blou, links bo), 35 duisend waardes in hierdie geval. Dit (middel bo) laai bouprosesse, en dit (regs bo) laai presies die interne prosesse: geskiedenissinkers en huishoudster, wat hier (middel onder) al 'n geruime tyd aan die gang is.
Hierdie grafiek (middel onder) wys ValueCache-gebruik - hoeveel ValueCache-treffers vir snellers ('n paar duisend waardes per sekonde). Nog 'n belangrike grafiek is die vierde een (links onder), wat die gebruik toon van die HistoryCache waarvan ek gepraat het, wat 'n buffer is voordat dit in die databasis ingevoeg word.
Optredetoets. PostgreSQL: 50k NVP's
Vervolgens het ek die las verhoog tot 50 duisend waardes per sekonde op dieselfde hardeware. Wanneer dit deur die huishoudster gelaai is, is 10 duisend waardes reeds in 2-3 sekondes met die berekening aangeteken. Wat in werklikheid in die volgende skermkiekie gewys word:
Die huishoudster begin reeds in die pad staan, maar die algehele geskiedenis van sinker trapper gebruik is steeds op 60% (derde grafiek, regs bo). HistoryCache reeds tydens die operasie van die "Housekeeper" begin aktief te vul (links onder). Dit was omtrent 'n halwe gigagreep, 20% vol.
Optredetoets. PostgreSQL: 80k NVP's
Verder verhoog tot 80 duisend waardes per sekonde:
Dit was ongeveer 400 duisend data-elemente, 280 duisend snellers. Die insetsel, soos jy kan sien, in terme van laai geskiedenis sinkers (daar was 30 van hulle) was reeds redelik hoog. Toe het ek verskeie parameters verhoog: geskiedenissinks, kas ... Op hierdie hardeware het die laai van geskiedenissinks tot die maksimum begin toeneem, amper "tot op die rak" - dienooreenkomstig het HistoryCache 'n baie hoë lading gegaan:
Al hierdie tyd het ek al die parameters van die stelsel gemonitor (hoe die verwerker gebruik word, RAM) en gevind dat skyfbenutting maksimum was - ek het die maksimum kapasiteit van hierdie skyf op hierdie hardeware bereik, in hierdie virtuele masjien. Postgres het begin om data redelik aktief te stort teen so 'n intensiteit, en die skyf het nie meer tyd gehad om te skryf, lees nie ...
Ek het 'n ander bediener geneem wat reeds 48 verwerkers 128 gigagrepe RAM gehad het:
Ek het dit ook “getune” - ek het die History syncer (60 stukke) geïnstalleer en aanvaarbare prestasie behaal. Eintlik is ons nie “in die rak” nie, maar dit is waarskynlik die limiet van produktiwiteit, waar dit reeds nodig is om iets daaraan te doen.
Optredetoets. TydskaalDB: 80k NVP's
My hooftaak was om TimescaleDB te gebruik. Elke grafiek toon 'n daling:
Hierdie mislukkings is net data-migrasie. Daarna, in die Zabbix-bediener, het die aflaaiprofiel van geskiedenis-sinkers, soos jy kan sien, baie verander. Dit laat jou toe om data byna 3 keer vinniger in te voeg en minder HistoryCache te gebruik - dienooreenkomstig sal jy data betyds ontvang. Weereens, 80 duisend waardes per sekonde is 'n redelik hoë koers (natuurlik nie vir Yandex nie). Oor die algemeen is dit 'n redelike groot opstelling, met een bediener.
PostgreSQL-maatstaf: 120K NVP's
Vervolgens het ek die waarde van die aantal data-elemente tot 'n halfmiljoen verhoog en 'n berekende waarde van 125 duisend per sekonde gekry:
En het hierdie kaarte gekry:
In beginsel is dit 'n werkende opstelling, dit kan nogal lank werk. Maar aangesien ek 'n skyf van slegs 1,5 teragrepe gehad het, het ek dit binne 'n paar dae spandeer. Die belangrikste is dat nuwe partisies terselfdertyd op TimescaleDB geskep is, en dit was heeltemal onopvallend vir prestasie, wat nie oor MySQL gesê kan word nie.
Partisies word gewoonlik snags geskep, want dit blokkeer invoeging en werk met tabelle in die algemeen, en kan lei tot agteruitgang van die diens. In hierdie geval doen dit nie! Die hooftaak was om die vermoëns van TimescaleDB te toets. Dit blyk so 'n syfer: 120 duisend waardes per sekonde.
Daar is ook voorbeelde in die "gemeenskap":
Die persoon het ook TimescaleDB aangeskakel en die las op die gebruik van io.weight het op die verwerker geval; en die gebruik van interne proseselemente is ook verminder deur die insluiting van TimescaleDB. En dit is gewone pannekoekskywe, dit wil sê 'n gewone virtuele masjien op gewone skywe (nie SSD's nie)!
Vir sommige klein opstellings wat beperk word deur skyfwerkverrigting, lyk TimescaleDB vir my na 'n baie goeie oplossing. Dit is 'n goeie idee om aan te hou werk voordat jy na vinniger databasishardeware migreer.
Ek nooi julle almal uit na ons geleenthede: Konferensie - in Moskou, Beraad - in Riga. Gebruik ons kanale - Telegram, forum, IRC. As jy enige vrae het, kom na ons toonbank, ons kan oor alles praat.
Gehoor vrae
Vraag van die gehoor (hierna - A): - As TimescaleDB so maklik is om op te stel, en dit gee so 'n prestasie-hupstoot, moet dit miskien gebruik word as die beste praktyk om Zabbix met Postgres op te stel? En is daar enige slaggate en nadele van hierdie oplossing, of steeds, as ek besluit om Zabbix vir myself te maak, kan ek gerus Postgres neem, Timescale dadelik daar sit, dit gebruik en nie aan enige probleme dink nie?
AG: - Ja, ek sou sê dat dit 'n goeie aanbeveling is om Postgres dadelik te gebruik met die TimescaleDB-uitbreiding. Soos ek gesê het, baie goeie resensies, ten spyte van die feit dat hierdie "funksie" eksperimenteel is. Maar eintlik wys toetse dit is 'n wonderlike oplossing (met TimescaleDB) en ek dink dit sal ontwikkel! Ons monitor hoe hierdie uitbreiding ontwikkel en sal regstel wat nodig is.
Ons het selfs op een van hul bekende "kenmerke" staatgemaak tydens ontwikkeling: dit was moontlik om met stukke 'n bietjie anders daar te werk. Maar toe sny hulle dit in die volgende uitgawe uit, en ons hoef nie meer op hierdie kode staat te maak nie. Ek sal aanbeveel om hierdie oplossing op baie opstellings te gebruik. As jy MySQL gebruik... Vir medium opstellings werk enige oplossing goed.
A: - Op die jongste kaarte, wat uit die gemeenskap kom, was daar 'n grafiek met die "Huisbediende":
Hy het aangehou werk. Wat doen huishoudster met TimescaleDB?
AG: - Nou kan ek nie met sekerheid sê nie - ek sal na die kode kyk en jou in meer besonderhede vertel. Dit gebruik TimescaleDB-navrae om nie stukke te verwyder nie, maar op een of ander manier saam te voeg. Terwyl ek nie gereed is om hierdie tegniese vraag te beantwoord nie. By die stand vandag of môre sal ons uitklaar.
A: - Ek het 'n soortgelyke vraag - oor die werkverrigting van die verwyderingsoperasie in Tydskaal.
A (antwoord van die gehoor): - Wanneer jy data uit 'n tabel uitvee, as jy dit deur delete doen, dan moet jy deur die tabel gaan - uitvee, skoonmaak, merk alles vir toekomstige vakuum. In Tydskaal, aangesien jy stukke het, kan jy val. Rofweg sê jy net vir die lêer wat in die groot data is: "Delete!"
Tydskaal verstaan eenvoudig dat daar nie meer so 'n stuk is nie. En aangesien dit by die navraagbeplanner integreer, sluit dit jou toestande vas in uitgesoekte of in ander bedrywighede en verstaan dadelik dat hierdie deel nie meer is nie - "Ek sal nie weer soontoe gaan nie!" (data nie beskikbaar nie). Dis al! Dit wil sê, 'n tabelskandering word vervang deur 'n binêre lêerskraping, so dit is vinnig.
A: - Ons het reeds die onderwerp aangeraak, nie SQL nie. Sover ek verstaan, hoef Zabbix nie regtig die data te wysig nie, en dit alles is iets soos 'n log. Is dit moontlik om gespesialiseerde databasisse te gebruik wat nie hul data kan verander nie, maar terselfdertyd baie vinniger kan stoor, opgaar, teruggee - Clickhouse, byvoorbeeld, iets Kafka-vormig? .. Kafka is ook 'n log! Is dit moontlik om hulle op een of ander manier te integreer?
AG: - Aflaai kan gedoen word. Ons het 'n sekere "kenmerk" sedert weergawe 3.4: jy kan alle historiese lêers, gebeurtenisse, alles anders na lêers skryf; en stuur dan een of ander hanteerder na enige ander databasis. Trouens, baie mense herwerk en skryf direk na die databasis. On the fly, geskiedenis sinkers skryf dit alles na lêers, draai hierdie lêers, ensovoorts, en jy kan dit na Clickhouse oordra. Ek kan nie sê wat die planne is nie, maar dalk sal verdere ondersteuning vir NoSQL-oplossings (soos Clickhouse) voortgaan.
A: – In die algemeen blyk dit dat jy heeltemal van postgres ontslae kan raak?
AG: - Natuurlik is die moeilikste deel in Zabbix die historiese tabelle, wat die meeste probleme en gebeure skep. In hierdie geval, as u nie gebeurtenisse vir 'n lang tyd stoor nie en die geskiedenis met tendense in 'n ander vinnige berging stoor, dan dink ek oor die algemeen dat daar geen probleme sal wees nie.
A: - Kan jy skat hoeveel vinniger alles sal werk as jy byvoorbeeld na Clickhouse oorskakel?
AG: - Ek het dit nie getoets nie. Ek dink dat ten minste dieselfde getalle redelik eenvoudig bereik kan word, aangesien Clickhouse sy eie koppelvlak het, maar ek kan nie met sekerheid sê nie. Beter om te toets. Dit hang alles af van die konfigurasie: hoeveel gashere jy het en so aan. Invoeging is een ding, maar jy moet ook hierdie data neem - Grafana of iets anders.
A: - Dit wil sê, ons praat van 'n gelyke stryd, en nie oor die groot voordeel van hierdie vinnige databasisse nie?
AG: - Ek dink wanneer ons integreer, sal daar meer akkurate toetse wees.
A: Waar is die goeie ou RRD heen? Wat het jou laat oorskakel na SQL-databasisse? Aanvanklik is alle maatstawwe op RRD ingesamel.
AG: - In "Zabbix" RRD, miskien in 'n baie ou weergawe. Daar was nog altyd SQL-databasisse - 'n klassieke benadering. Die klassieke benadering is MySQL, PostgreSQL (hulle bestaan al baie lank). Ons het amper nooit 'n algemene koppelvlak vir SQL- en RRD-databasisse gebruik nie.
Sommige advertensies 🙂
Dankie dat jy by ons gebly het. Hou jy van ons artikels? Wil jy meer interessante inhoud sien? Ondersteun ons deur 'n bestelling te plaas of by vriende aan te beveel, , 'n unieke analoog van intreevlakbedieners, wat deur ons vir jou uitgevind is: (beskikbaar met RAID1 en RAID10, tot 24 kerne en tot 40 GB DDR4).
Dell R730xd 2x goedkoper in Equinix Tier IV-datasentrum in Amsterdam? Net hier in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees van
Bron: will.com