Vi skal se på hvordan Zabbix fungerer med TimescaleDB-databasen som backend. Vi viser deg hvordan du starter fra bunnen av og hvordan du migrerer fra PostgreSQL. Vi vil også gi sammenlignende ytelsestester av de to konfigurasjonene.
HighLoad++ Sibir 2019. Tomsk Hall. 24. juni, 16:00. Avhandlinger og . Den neste HighLoad++-konferansen holdes 6. og 7. april 2020 i St. Petersburg. Detaljer og billetter .
Andrey Gushchin (heretter – AG): – Jeg er en ZABBIX teknisk støtteingeniør (heretter referert til som "Zabbix"), en trener. Jeg har jobbet med teknisk support i mer enn 6 år og har hatt direkte erfaring med ytelse. I dag skal jeg snakke om ytelsen som TimescaleDB kan gi sammenlignet med vanlig PostgreSQL 10. Også en introduksjonsdel om hvordan det fungerer generelt.
Topp produktivitetsutfordringer: fra datainnsamling til datarensing
Til å begynne med er det visse ytelsesutfordringer som hvert overvåkingssystem står overfor. Den første produktivitetsutfordringen er å samle inn og behandle data raskt.
Et godt overvåkingssystem bør raskt, rettidig motta alle data, behandle det i henhold til trigger-uttrykk, det vil si behandle det i henhold til noen kriterier (dette er forskjellig i forskjellige systemer) og lagre det i en database for å bruke disse dataene i framtid.
Den andre ytelsesutfordringen er historielagring. Lagre i en database ofte og ha rask og praktisk tilgang til disse beregningene som ble samlet inn over en periode. Det viktigste er at disse dataene er praktiske å få tak i, bruke dem i rapporter, grafer, triggere, i noen terskelverdier, for varsler osv.
Den tredje ytelsesutfordringen er historierydding, det vil si når du kommer til et punkt hvor du ikke trenger å lagre noen detaljerte beregninger som har blitt samlet inn over 5 år (selv måneder eller to måneder). Noen nettverksnoder ble slettet, eller noen verter, beregningene er ikke lenger nødvendige fordi de allerede er utdaterte og ikke lenger samlet inn. Alt dette må ryddes ut slik at databasen din ikke blir for stor. Generelt er tømmehistorikk oftest en seriøs test for lagringen – den har ofte en veldig sterk innvirkning på ytelsen.
Hvordan løse caching-problemer?
Jeg vil nå snakke spesifikt om Zabbix. I Zabbix løses det første og andre anropet ved hjelp av caching.
Datainnsamling og behandling – Vi bruker RAM til å lagre alle disse dataene. Disse dataene vil nå bli diskutert mer detaljert.
Også på databasesiden er det noe caching for hovedvalg - for grafer og andre ting.
Bufring på siden av selve Zabbix-serveren: vi har ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Hva det er?
ConfigurationCache er hovedbufferen der vi lagrer beregninger, verter, dataelementer, triggere; alt du trenger for å behandle forbehandling, samle inn data, fra hvilke verter du skal samle inn, med hvilken frekvens. Alt dette lagres i ConfigurationCache for ikke å gå til databasen og lage unødvendige spørringer. Etter at serveren starter oppdaterer vi denne cachen (oppretter den) og oppdaterer den med jevne mellomrom (avhengig av konfigurasjonsinnstillingene).
Caching i Zabbix. Datainnsamling
Her er diagrammet ganske stort:
De viktigste i ordningen er disse samlerne:
Dette er selve monteringsprosessene, ulike «pollere» som er ansvarlige for ulike typer sammenstillinger. De samler inn data via icmp, ipmi og ulike protokoller og overfører alt til forbehandling.
PreProcessing HistoryCache
Dessuten, hvis vi har beregnede dataelementer (det vet de som er kjent med Zabbix), det vil si beregnede, aggregerte dataelementer, tar vi dem direkte fra ValueCache. Jeg skal fortelle deg hvordan den fylles senere. Alle disse samlerne bruker ConfigurationCache for å motta jobbene sine og deretter sende dem videre til forbehandling.
Forbehandling bruker også ConfigurationCache for å innhente forhåndsbehandlingstrinn og behandler disse dataene på ulike måter. Fra og med versjon 4.2 har vi flyttet den til en proxy. Dette er veldig praktisk, fordi forbehandling i seg selv er en ganske vanskelig operasjon. Og hvis du har en veldig stor Zabbix, med et stort antall dataelementer og høy innsamlingsfrekvens, så forenkler dette arbeidet betraktelig.
Følgelig, etter at vi har behandlet disse dataene på en eller annen måte ved hjelp av forhåndsbehandling, lagrer vi dem i HistoryCache for å behandle dem videre. Dette avslutter datainnsamlingen. Vi går videre til hovedprosessen.
Historiesynkroniseringsarbeid
Hovedprosessen i Zabbix (siden det er en monolitisk arkitektur) er History syncer. Dette er hovedprosessen som spesifikt omhandler atombehandlingen av hvert dataelement, det vil si hver verdi:
- verdien kommer (den tar den fra HistoryCache);
- sjekker i konfigurasjonssynkronisering: om det er noen triggere for beregning - beregner dem;
hvis det er - oppretter hendelser, oppretter eskalering for å opprette et varsel, om nødvendig i henhold til konfigurasjonen; - registrerer utløsere for påfølgende behandling, aggregering; hvis du aggregerer den siste timen og så videre, huskes denne verdien av ValueCache for ikke å gå til historikktabellen; Dermed er ValueCache fylt med de nødvendige dataene som er nødvendige for å beregne triggere, beregnede elementer osv.;
- så skriver History syncer alle data til databasen;
- databasen skriver dem til disk - det er her behandlingsprosessen slutter.
Database. Buffer
På databasesiden, når du ønsker å se grafer eller noen rapporter om hendelser, er det forskjellige cacher. Men i denne rapporten skal jeg ikke snakke om dem.
For MySQL er det Innodb_buffer_pool, og en haug med forskjellige cacher som også kan konfigureres.
Men dette er de viktigste:
- delte_buffere;
- effektiv_cache_size;
- shared_pool.
For alle databaser sa jeg at det er visse cacher som lar deg lagre i RAM dataene som ofte er nødvendig for spørringer. De har sine egne teknologier for dette.
Om databaseytelse
Følgelig er det et konkurransedyktig miljø, det vil si at Zabbix-serveren samler inn data og registrerer dem. Når den startes på nytt, leser den også fra historien for å fylle ValueCache og så videre. Her kan du ha skript og rapporter som bruker Zabbix API, som er bygget på et webgrensesnitt. Zabbix API går inn i databasen og mottar de nødvendige dataene for å få grafer, rapporter eller en slags liste over hendelser, nylige problemer.
Også en veldig populær visualiseringsløsning er Grafana, som brukerne våre bruker. Kunne logge inn direkte både gjennom Zabbix API og gjennom databasen. Det skaper også en viss konkurranse om å skaffe data: en finere, bedre tuning av databasen er nødvendig for å overholde rask levering av resultater og testing.
Sletter historikk. Zabbix har husholderske
Den tredje samtalen som brukes i Zabbix er å tømme historikk ved å bruke Housekeeper. Housekeeper følger alle innstillingene, det vil si at dataelementene våre indikerer hvor lenge du skal lagre (i dager), hvor lenge trender skal lagres og dynamikken til endringer.
Jeg snakket ikke om TrendCache, som vi regner ut i farten: data kommer, vi aggregerer dem i én time (for det meste er dette tall for den siste timen), mengden er gjennomsnittlig/minimum og vi registrerer den en gang i timen i tabell over dynamikken i endringer ("trender") . "Housekeeper" starter og sletter data fra databasen ved å bruke vanlige valg, noe som ikke alltid er effektivt.
Hvordan forstå at det er ineffektivt? Du kan se følgende bilde på ytelsesgrafene til interne prosesser:
Historiesynkroniseringen din er konstant opptatt (rød graf). Og den "røde" grafen som går på toppen. Dette er en "husholderske" som starter og venter på at databasen skal slette alle radene den har spesifisert.
La oss ta litt vare-ID: du må slette de siste 5 tusen; selvfølgelig etter indekser. Men vanligvis er datasettet ganske stort - databasen leser det fortsatt fra disken og legger det inn i cachen, og dette er en veldig kostbar operasjon for databasen. Avhengig av størrelsen kan dette føre til visse ytelsesproblemer.
Du kan deaktivere Housekeeper på en enkel måte - vi har et kjent webgrensesnitt. Innstillinger i Administrasjon generelt (innstillinger for "Husholderske") vi deaktiverer intern husholdning for intern historikk og trender. Følgelig kontrollerer ikke husholderske dette lenger:
Hva kan du gjøre videre? Du slo den av, grafene dine har jevnet seg ut... Hvilke ytterligere problemer kan oppstå i dette tilfellet? Hva kan hjelpe?
Partisjonering (seksjonering)
Vanligvis er dette konfigurert på en annen måte på hver relasjonsdatabase jeg har listet opp. MySQL har sin egen teknologi. Men totalt sett er de veldig like når det kommer til PostgreSQL 10 og MySQL. Selvfølgelig er det mange interne forskjeller i hvordan det hele er implementert og hvordan det hele påvirker ytelsen. Men generelt fører opprettelsen av en ny partisjon ofte også til visse problemer.
Avhengig av oppsettet ditt (hvor mye data du lager på en dag), setter de vanligvis minimum - dette er 1 dag / batch, og for "trender", dynamikk av endringer - 1 måned / ny batch. Dette kan endres hvis du har et veldig stort oppsett.
La oss si med en gang om størrelsen på oppsettet: opptil 5 tusen nye verdier per sekund (såkalte nvps) - dette vil bli betraktet som et lite "oppsett". Gjennomsnittlig - fra 5 til 25 tusen verdier per sekund. Alt som er ovenfor er allerede store og veldig store installasjoner som krever svært nøye konfigurasjon av databasen.
På veldig store installasjoner er 1 dag kanskje ikke optimalt. Jeg personlig har sett partisjoner på MySQL på 40 gigabyte per dag (og det kan være flere). Dette er en veldig stor mengde data, som kan føre til noen problemer. Det må reduseres.
Hvorfor trenger du partisjonering?
Det partisjonering gir, tror jeg alle vet, er tabellpartisjonering. Ofte er dette separate filer på disk og span-forespørsler. Den velger en partisjon mer optimalt hvis den er en del av normal partisjonering.
For Zabbix, spesielt, brukes det etter område, etter område, det vil si at vi bruker et tidsstempel (et vanlig tall, tid siden begynnelsen av epoken). Du spesifiserer starten på dagen/slutten av dagen, og dette er partisjonen. Følgelig, hvis du ber om data som er to dager gamle, hentes alt fra databasen raskere, fordi du bare trenger å laste en fil inn i cachen og returnere den (i stedet for en stor tabell).
Mange databaser gir også raskere innsetting (innsetting i én underordnet tabell). Jeg snakker abstrakt foreløpig, men dette er også mulig. Partitonering hjelper ofte.
Elasticsearch for NoSQL
Nylig, i 3.4, implementerte vi en NoSQL-løsning. Lagt til muligheten til å skrive i Elasticsearch. Du kan skrive visse typer: du velger - enten skrive tall eller noen tegn; vi har strengtekst, du kan skrive logger til Elasticsearch... Følgelig vil nettgrensesnittet også få tilgang til Elasticsearch. Dette fungerer utmerket i noen tilfeller, men for øyeblikket kan det brukes.
TidsskalaDB. Hypertabeller
For 4.4.2 la vi oppmerksomhet til én ting som TimescaleDB. Hva det er? Dette er en utvidelse for PostgreSQL, det vil si at den har et innebygd PostgreSQL-grensesnitt. I tillegg lar denne utvidelsen deg jobbe mye mer effektivt med tidsseriedata og ha automatisk partisjonering. Hva det ser ut som:
Dette er hypertabell - det er et slikt konsept i Timescale. Dette er en hypertabell du lager, og den inneholder biter. Chunks er partisjoner, dette er underordnede tabeller, hvis jeg ikke tar feil. Det er veldig effektivt.
TimescaleDB og PostgreSQL
Som TimescaleDB-produsentene forsikrer, bruker de en mer korrekt algoritme for å behandle spørringer, spesielt innlegg, som lar dem ha tilnærmet konstant ytelse med økende størrelse på datasettinnlegget. Det vil si at etter 200 millioner rader med Postgres, begynner den vanlige å synke veldig mye og mister ytelsen bokstavelig talt til null, mens Timescale lar deg sette inn innlegg så effektivt som mulig med en hvilken som helst mengde data.
Hvordan installere TimescaleDB? Det er enkelt!
Det er i dokumentasjonen, det er beskrevet - du kan installere det fra pakker for alle ... Det avhenger av de offisielle Postgres-pakkene. Kan kompileres manuelt. Det hendte at jeg måtte kompilere for databasen.
På Zabbix aktiverer vi ganske enkelt utvidelse. Jeg tror at de som brukte Extention i Postgres... Du aktiverer ganske enkelt Extention, oppretter den for Zabbix-databasen du bruker.
Og det siste trinnet...
TidsskalaDB. Migrering av historietabeller
Du må lage en hypertabell. Det er en spesiell funksjon for dette – Lag hypertabell. I den er den første parameteren tabellen som er nødvendig i denne databasen (som du må lage en hypertabell for).
Feltet for å opprette, og chunk_time_interval (dette er intervallet av chunks (partisjoner som må brukes). 86 400 er én dag.
Migrate_data-parameter: Hvis du setter inn til true, vil dette migrere alle gjeldende data til forhåndslagrede deler.
Jeg har selv brukt migrate_data - det tar ganske lang tid, avhengig av hvor stor databasen din er. Jeg hadde over en terabyte - det tok over en time å lage. I noen tilfeller, under testing, slettet jeg historiske data for tekst (history_text) og string (history_str) for ikke å overføre dem - de var egentlig ikke interessante for meg.
Og vi gjør den siste oppdateringen i vår db_extention: vi installerer timescaledb slik at databasen og spesielt vår Zabbix forstår at det er db_extention. Han aktiverer den og bruker riktig syntaks og spørringer til databasen, ved å bruke de "funksjonene" som er nødvendige for TimescaleDB.
Serverkonfigurasjon
Jeg brukte to servere. Den første serveren er en ganske liten virtuell maskin, 20 prosessorer, 16 gigabyte RAM. Jeg konfigurerte Postgres 10.8 på den:
Operativsystemet var Debian, filsystemet var xfs. Jeg gjorde minimale innstillinger for å bruke denne databasen, minus hva Zabbix selv vil bruke. På samme maskin var det en Zabbix-server, PostgreSQL og load-agenter.
Jeg har brukt 50 aktive agenter som bruker LoadableModule for raskt å generere forskjellige resultater. Det er de som genererte strengene, tallene og så videre. Jeg fylte databasen med mye data. Opprinnelig inneholdt konfigurasjonen 5 tusen dataelementer per vert, og omtrent hvert dataelement inneholdt en trigger - for at dette skulle være et reelt oppsett. Noen ganger trenger du til og med mer enn én utløser for å bruke.
Jeg regulerte oppdateringsintervallet og selve belastningen ved å ikke bare bruke 50 agenter (legge til flere), men også bruke dynamiske dataelementer og redusere oppdateringsintervallet til 4 sekunder.
Ytelsestest. PostgreSQL: 36 tusen NVP-er
Den første lanseringen, det første oppsettet jeg hadde, var på ren PostreSQL 10 på denne maskinvaren (35 tusen verdier per sekund). Generelt, som du kan se på skjermen, tar det å sette inn data brøkdeler av et sekund - alt er bra og raskt, SSD-stasjoner (200 gigabyte). Det eneste er at 20 GB fylles opp ganske raskt.
Det vil bli ganske mange slike grafer i fremtiden. Dette er et standard dashbord for Zabbix-serverytelse.
Den første grafen er antall verdier per sekund (blå, øverst til venstre), 35 tusen verdier i dette tilfellet. Dette (øverst i midten) er lasting av byggeprosesser, og dette (øverst til høyre) er lasting av interne prosesser: historiesyncere og husholderske, som her (nederst i midten) har vært i gang en god stund.
Denne grafen (nederst i midten) viser ValueCache-bruk - hvor mange ValueCache-treff for utløsere (flere tusen verdier per sekund). En annen viktig graf er den fjerde (nederst til venstre), som viser bruken av HistoryCache, som jeg snakket om, som er en buffer før den settes inn i databasen.
Ytelsestest. PostgreSQL: 50 tusen NVP-er
Deretter økte jeg belastningen til 50 tusen verdier per sekund på samme maskinvare. Når den ble lastet av Housekeeper, ble 10 tusen verdier registrert på 2-3 sekunder med beregning. Det som faktisk vises i følgende skjermbilde:
"Husholderske" begynner allerede å forstyrre arbeidet, men generelt er belastningen på fangstmenn med historiesynker fortsatt på nivået 60 % (tredje graf øverst til høyre). HistoryCache begynner allerede å fylles aktivt mens Housekeeper kjører (nederst til venstre). Den var omtrent en halv gigabyte, 20 % full.
Ytelsestest. PostgreSQL: 80 tusen NVP-er
Så økte jeg det til 80 tusen verdier per sekund:
Det var omtrent 400 tusen dataelementer, 280 tusen triggere. Innsatsen, som du kan se, når det gjelder belastningen av historiesynker (det var 30 av dem) var allerede ganske høy. Deretter økte jeg forskjellige parametere: historikk, cache ... På denne maskinvaren begynte belastningen på historikk å øke til et maksimum, nesten "på hyllen" - følgelig gikk HistoryCache inn i en veldig høy belastning:
Hele denne tiden overvåket jeg alle systemparametrene (hvordan prosessoren brukes, RAM) og oppdaget at diskutnyttelsen var maksimal – jeg oppnådde maksimal kapasitet på denne disken på denne maskinvaren, på denne virtuelle maskinen. "Postgres" begynte å dumpe data ganske aktivt med en slik intensitet, og disken hadde ikke lenger tid til å skrive, lese ...
Jeg tok en annen server som allerede hadde 48 prosessorer og 128 gigabyte RAM:
Jeg "tunet" den også - installerte History syncer (60 stykker) og oppnådde akseptabel ytelse. Faktisk er vi ikke "på hylla", men dette er sannsynligvis grensen for produktivitet, der det allerede er nødvendig å gjøre noe med det.
Ytelsestest. TidsskalaDB: 80 tusen NVPer
Min hovedoppgave var å bruke TimescaleDB. Hver graf viser et fall:
Disse feilene er nettopp datamigrering. Etter det, i Zabbix-serveren, endret lasteprofilen til historiesynkere seg mye, som du kan se. Den lar deg sette inn data nesten 3 ganger raskere og bruke mindre HistoryCache - følgelig vil du få data levert i tide. Igjen, 80 tusen verdier per sekund er en ganske høy hastighet (selvfølgelig ikke for Yandex). Totalt sett er dette et ganske stort oppsett, med en server.
PostgreSQL ytelsestest: 120 tusen NVPer
Deretter økte jeg verdien av antall dataelementer til en halv million og fikk en beregnet verdi på 125 tusen per sekund:
Og jeg fikk disse grafene:
I prinsippet er dette et fungerende oppsett, det kan fungere ganske lenge. Men siden jeg bare hadde en disk på 1,5 terabyte brukte jeg den opp på et par dager. Det viktigste er at det samtidig ble opprettet nye partisjoner på TimescaleDB, og dette var helt ubemerket for ytelsen, noe som ikke kan sies om MySQL.
Vanligvis opprettes partisjoner om natten, fordi dette generelt blokkerer innsetting og arbeid med tabeller og kan føre til forringelse av tjenesten. I dette tilfellet er ikke dette tilfellet! Hovedoppgaven var å teste egenskapene til TimescaleDB. Resultatet var følgende tall: 120 tusen verdier per sekund.
Det er også eksempler i samfunnet:
Personen satte også på TimescaleDB og belastningen på å bruke io.weight falt på prosessoren; og bruken av interne prosesselementer har også gått ned på grunn av inkluderingen av TimescaleDB. Dessuten er dette vanlige pannekakedisker, det vil si en vanlig virtuell maskin på vanlige disker (ikke SSD-er)!
For noen små oppsett som er begrenset av diskytelse, er TimescaleDB, etter min mening, en veldig god løsning. Det vil tillate deg å fortsette å jobbe før du migrerer til raskere maskinvare for databasen.
Jeg inviterer dere alle til våre arrangementer: Konferanse i Moskva, toppmøte i Riga. Bruk våre kanaler - Telegram, forum, IRC. Hvis du har spørsmål, kom til pulten vår, vi kan snakke om alt.
Publikumsspørsmål
Spørsmål fra publikum (heretter - A): - Hvis TimescaleDB er så enkelt å konfigurere, og det gir et slikt ytelsesløft, bør kanskje dette brukes som en beste praksis for å konfigurere Zabbix med Postgres? Og er det noen fallgruver og ulemper med denne løsningen, eller tross alt, hvis jeg bestemte meg for å lage Zabbix for meg selv, kan jeg enkelt ta Postgres, installere Timescale der med en gang, bruke den og ikke tenke på noen problemer?
AG: – Ja, jeg vil si at dette er en god anbefaling: bruk Postgres umiddelbart med TimescaleDB-utvidelsen. Som jeg allerede har sagt, mange gode anmeldelser, til tross for at denne "funksjonen" er eksperimentell. Men faktisk viser tester at dette er en flott løsning (med TimescaleDB) og jeg tror den vil utvikle seg! Vi følger med på hvordan denne utvidelsen utvikler seg og vil gjøre endringer etter behov.
Selv under utviklingen stolte vi på en av deres velkjente "funksjoner": det var mulig å jobbe med biter litt annerledes. Men så kuttet de ut i neste utgivelse, og vi måtte slutte å stole på denne koden. Jeg vil anbefale å bruke denne løsningen på mange oppsett. Hvis du bruker MySQL... For gjennomsnittlige oppsett fungerer enhver løsning bra.
og: – På de siste grafene fra samfunnet var det en graf med "Husholderske":
Han fortsatte å jobbe. Hva gjør Housekeeper med TimescaleDB?
AG: – Nå kan jeg ikke si det sikkert – jeg skal se på koden og fortelle deg mer detaljert. Den bruker TimescaleDB-spørringer for ikke å slette biter, men for å samle dem på en eller annen måte. Jeg er ikke klar til å svare på dette tekniske spørsmålet ennå. Vi får vite mer på standen i dag eller i morgen.
og: – Jeg har et lignende spørsmål – om ytelsen til sletteoperasjonen i Timescale.
A (svar fra publikum): – Når du sletter data fra en tabell, hvis du gjør det via sletting, så må du gå gjennom tabellen - slett, rens, merk alt for fremtidig vakuum. I Timescale, siden du har biter, kan du slippe. Grovt sett forteller du ganske enkelt filen som er i big data: "Slett!"
Timescale forstår ganske enkelt at en slik del ikke lenger eksisterer. Og siden den er integrert i spørringsplanleggeren, bruker den kroker for å fange opp forholdene dine i utvalgte eller andre operasjoner og forstår umiddelbart at denne delen ikke lenger eksisterer - "Jeg vil ikke gå dit lenger!" (data ikke tilgjengelig). Det er alt! Det vil si at en tabellskanning erstattes av en binær filsletting, så det er raskt.
og: – Vi har allerede vært inne på temaet ikke-SQL. Så vidt jeg forstår, trenger ikke Zabbix å endre dataene, og alt dette er noe som en logg. Er det mulig å bruke spesialiserte databaser som ikke kan endre dataene sine, men samtidig lagre, akkumulere og distribuere mye raskere - Clickhouse, for eksempel, noe Kafka-aktig?.. Kafka er også en logg! Er det mulig å integrere dem på en eller annen måte?
AG: – Lossing kan gjøres. Vi har en viss "funksjon" siden versjon 3.4: du kan skrive alle historiske filer, hendelser, alt annet til filer; og send den til en hvilken som helst annen database ved å bruke en eller annen behandler. Faktisk er det mange som omarbeider og skriver direkte til databasen. På farten skriver historiesynker alt dette inn i filer, roterer disse filene, og så videre, og du kan overføre dette til Clickhouse. Jeg kan ikke si noe om planene, men kanskje vil ytterligere støtte for NoSQL-løsninger (som Clickhouse) fortsette.
og: – Generelt viser det seg at du kan bli helt kvitt postgres?
AG: – Den vanskeligste delen i Zabbix er selvfølgelig de historiske tabellene, som skaper flest problemer og hendelser. I dette tilfellet, hvis du ikke lagrer hendelser på lenge og lagrer historien med trender i annen rask lagring, så tror jeg generelt at det ikke vil være noen problemer.
og: – Kan du anslå hvor mye raskere alt vil fungere hvis du for eksempel bytter til Clickhouse?
AG: – Jeg har ikke testet det. Jeg tror at minst de samme tallene kan oppnås ganske enkelt, gitt at Clickhouse har sitt eget grensesnitt, men jeg kan ikke si det sikkert. Det er bedre å teste. Alt avhenger av konfigurasjonen: hvor mange verter du har, og så videre. Å sette inn er én ting, men du må også hente disse dataene – Grafana eller noe annet.
og: – Så vi snakker om en likeverdig kamp, og ikke om den store fordelen med disse raske databasene?
AG: – Jeg tror at når vi integrerer, vil det være mer nøyaktige tester.
og: – Hvor ble det av gode gamle RRD? Hva fikk deg til å bytte til SQL-databaser? Opprinnelig ble alle beregninger samlet på RRD.
AG: – Zabbix hadde RRD, kanskje i en veldig gammel versjon. Det har alltid vært SQL-databaser – en klassisk tilnærming. Den klassiske tilnærmingen er MySQL, PostgreSQL (de har eksistert veldig lenge). Vi brukte nesten aldri et felles grensesnitt for SQL- og RRD-databaser.
Noen annonser 🙂
Takk for at du bor hos oss. Liker du artiklene våre? Vil du se mer interessant innhold? Støtt oss ved å legge inn en bestilling eller anbefale til venner, , en unik analog av entry-level servere, som ble oppfunnet av oss for deg: (tilgjengelig med RAID1 og RAID10, opptil 24 kjerner og opptil 40 GB DDR4).
Dell R730xd 2x billigere i Equinix Tier IV datasenter i Amsterdam? Bare her i Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Lese om
Kilde: www.habr.com