Vi vil se på, hvordan Zabbix fungerer med TimescaleDB-databasen som backend. Vi viser dig, hvordan du starter fra bunden, og hvordan du migrerer fra PostgreSQL. Vi vil også levere sammenlignende præstationstest af de to konfigurationer.
HighLoad++ Sibirien 2019. Tomsk Hall. 24. juni, 16:00. Specialer og . Den næste HighLoad++ konference afholdes den 6. og 7. april 2020 i St. Petersborg. Detaljer og billetter .
Andrey Gushchin (i det følgende – AG): – Jeg er ZABBIX teknisk supportingeniør (i det følgende benævnt "Zabbix"), en underviser. Jeg har arbejdet med teknisk support i mere end 6 år og har haft direkte erfaring med ydeevne. I dag vil jeg tale om den ydeevne, som TimescaleDB kan levere sammenlignet med almindelig PostgreSQL 10. Også en introduktionsdel om, hvordan det fungerer generelt.
Top produktivitetsudfordringer: fra dataindsamling til datarensning
Til at begynde med er der visse præstationsudfordringer, som ethvert overvågningssystem står over for. Den første produktivitetsudfordring er at indsamle og behandle data hurtigt.
Et godt overvågningssystem bør hurtigt, rettidigt modtage alle data, behandle dem i henhold til trigger-udtryk, dvs. behandle dem efter nogle kriterier (dette er forskelligt i forskellige systemer) og gemme dem i en database for at bruge disse data i fremtid.
Den anden ydeevneudfordring er historielagring. Gem ofte i en database og få hurtig og bekvem adgang til disse metrics, der blev indsamlet over en periode. Det vigtigste er, at disse data er praktiske at få, bruge dem i rapporter, grafer, triggere, i nogle tærskelværdier, til advarsler osv.
Den tredje præstationsudfordring er historierydning, det vil sige, når du kommer til det punkt, hvor du ikke behøver at gemme nogen detaljerede metrics, der er blevet indsamlet over 5 år (selv måneder eller to måneder). Nogle netværksknuder blev slettet, eller nogle værter, metrics er ikke længere nødvendige, fordi de allerede er forældede og ikke længere indsamlet. Alt dette skal renses ud, så din database ikke bliver for stor. Generelt er rydningshistorik oftest en seriøs test for lageret – det har ofte en meget stærk indflydelse på ydeevnen.
Hvordan løser man caching-problemer?
Jeg vil nu tale specifikt om Zabbix. I Zabbix løses det første og andet opkald ved hjælp af caching.
Dataindsamling og -behandling - Vi bruger RAM til at gemme alle disse data. Disse data vil nu blive diskuteret mere detaljeret.
Også på databasesiden er der en del caching til hovedvalg - til grafer og andet.
Caching på siden af selve Zabbix-serveren: vi har ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Hvad er det?
ConfigurationCache er hovedcachen, hvori vi gemmer metrics, værter, dataelementer, triggere; alt hvad du behøver for at behandle forbehandling, indsamle data, fra hvilke værter der skal indsamles, med hvilken frekvens. Alt dette er gemt i ConfigurationCache for ikke at gå til databasen og oprette unødvendige forespørgsler. Når serveren er startet, opdaterer vi denne cache (opretter den) og opdaterer den med jævne mellemrum (afhængigt af konfigurationsindstillingerne).
Caching i Zabbix. Dataindsamling
Her er diagrammet ret stort:
De vigtigste i ordningen er disse samlere:
Det er selve montageprocesserne, forskellige "pollere", der er ansvarlige for forskellige typer forsamlinger. De indsamler data via icmp, ipmi og forskellige protokoller og overfører det hele til forbehandling.
PreProcessing HistoryCache
Desuden, hvis vi har beregnede dataelementer (det ved dem, der er bekendt med Zabbix), det vil sige beregnede, aggregerede dataelementer, tager vi dem direkte fra ValueCache. Jeg fortæller dig, hvordan den fyldes senere. Alle disse samlere bruger ConfigurationCache til at modtage deres job og derefter videregive dem til forbehandling.
Forbehandling bruger også ConfigurationCache til at hente forbehandlingstrin og behandler disse data på forskellige måder. Fra version 4.2 har vi flyttet den til en proxy. Dette er meget praktisk, fordi selve forbehandlingen er en ret vanskelig operation. Og hvis du har en meget stor Zabbix, med et stort antal dataelementer og en høj indsamlingsfrekvens, så forenkler dette arbejdet meget.
Derfor, efter at vi har behandlet disse data på en eller anden måde ved hjælp af forbehandling, gemmer vi dem i HistoryCache for at behandle dem yderligere. Dette afslutter dataindsamlingen. Vi går videre til hovedprocessen.
History syncer's arbejde
Hovedprocessen i Zabbix (da det er en monolitisk arkitektur) er History syncer. Dette er hovedprocessen, der specifikt beskæftiger sig med den atomare behandling af hvert dataelement, det vil sige hver værdi:
- værdien kommer (den tager den fra HistoryCache);
- kontrollerer i Konfigurationssynkronisering: om der er nogen udløsere til beregning - beregner dem;
hvis der er - opretter begivenheder, skaber eskalering for at oprette en advarsel, hvis det er nødvendigt i henhold til konfigurationen; - registrerer triggere for efterfølgende behandling, aggregering; hvis du aggregerer i løbet af den sidste time og så videre, huskes denne værdi af ValueCache for ikke at gå til historiktabellen; Således er ValueCache fyldt med de nødvendige data, der er nødvendige for at beregne triggere, beregnede elementer osv.;
- så skriver History syncer alle data til databasen;
- databasen skriver dem til disk - det er her, behandlingsprocessen slutter.
Database. Caching
På databasesiden, når du vil se grafer eller nogle rapporter om hændelser, er der forskellige caches. Men i denne rapport vil jeg ikke tale om dem.
Til MySQL er der Innodb_buffer_pool, og en masse forskellige caches, der også kan konfigureres.
Men disse er de vigtigste:
- delte_buffere;
- effektiv_cache_størrelse;
- shared_pool.
For alle databaser sagde jeg, at der er visse caches, der giver dig mulighed for at gemme de data, der ofte er nødvendige for forespørgsler, i RAM. De har deres egne teknologier til dette.
Om databaseydelse
Derfor er der et konkurrencepræget miljø, det vil sige, at Zabbix-serveren indsamler data og registrerer dem. Når den genstartes, læser den også fra historien for at fylde ValueCache og så videre. Her kan du have scripts og rapporter, der bruger Zabbix API, som er bygget på en webgrænseflade. Zabbix API går ind i databasen og modtager de nødvendige data for at få grafer, rapporter eller en slags liste over begivenheder, seneste problemer.
Også en meget populær visualiseringsløsning er Grafana, som vores brugere bruger. I stand til at logge direkte ind både via Zabbix API og gennem databasen. Det skaber også en vis konkurrence om at få data: en finere, bedre tuning af databasen er nødvendig for at overholde den hurtige levering af resultater og test.
Rydning af historik. Zabbix har husholderske
Det tredje opkald, der bruges i Zabbix, er at rydde historie ved hjælp af Housekeeper. Housekeeper følger alle indstillingerne, det vil sige, at vores dataelementer angiver, hvor længe der skal opbevares (i dage), hvor længe der skal lagres trends og dynamikken i ændringer.
Jeg talte ikke om TrendCache, som vi beregner med det samme: data ankommer, vi aggregerer dem i en time (for det meste er det tal for den sidste time), mængden er gennemsnitlig/minimum, og vi registrerer den en gang i timen i tabel over ændringers dynamik ("Trends"). "Husholderske" starter og sletter data fra databasen ved hjælp af almindelige valg, hvilket ikke altid er effektivt.
Hvordan forstår man, at det er ineffektivt? Du kan se følgende billede på præstationsgraferne for interne processer:
Din historie-synkronisering er konstant optaget (rød graf). Og den "røde" graf, der går ovenpå. Dette er en "Husholderske", der starter og venter på, at databasen sletter alle de rækker, den har angivet.
Lad os tage noget vare-id: du skal slette de sidste 5 tusinde; selvfølgelig efter indekser. Men normalt er datasættet ret stort - databasen læser det stadig fra disken og lægger det ind i cachen, og det er en meget dyr operation for databasen. Afhængigt af størrelsen kan dette føre til visse præstationsproblemer.
Du kan deaktivere Housekeeper på en enkel måde - vi har en velkendt webgrænseflade. Indstillinger i Administration generelt (indstillinger for "Husholderske") vi deaktiverer intern husholdning for intern historie og tendenser. Derfor kontrollerer Housekeeper ikke længere dette:
Hvad kan du gøre næste gang? Du har slået det fra, dine grafer er jævnet ud... Hvilke yderligere problemer kan der opstå i dette tilfælde? Hvad kan hjælpe?
Opdeling (sektionering)
Dette er typisk konfigureret på en anden måde på hver relationsdatabase, jeg har angivet. MySQL har sin egen teknologi. Men overordnet ligner de meget, når det kommer til PostgreSQL 10 og MySQL. Selvfølgelig er der mange interne forskelle i, hvordan det hele implementeres, og hvordan det hele påvirker ydeevnen. Men generelt fører oprettelsen af en ny partition ofte også til visse problemer.
Afhængigt af din opsætning (hvor meget data du opretter på en dag), sætter de normalt minimum - dette er 1 dag / batch, og for "trends", dynamik af ændringer - 1 måned / ny batch. Dette kan ændre sig, hvis du har en meget stor opsætning.
Lad os sige med det samme om størrelsen af opsætningen: op til 5 tusinde nye værdier pr. sekund (såkaldte nvps) - dette vil blive betragtet som en lille "opsætning". Gennemsnit - fra 5 til 25 tusinde værdier pr. sekund. Alt, hvad der er ovenfor, er allerede store og meget store installationer, der kræver meget omhyggelig konfiguration af databasen.
På meget store installationer er 1 dag måske ikke optimalt. Jeg har personligt set partitioner på MySQL på 40 gigabyte om dagen (og der kan være flere). Dette er en meget stor mængde data, som kan føre til nogle problemer. Det skal reduceres.
Hvorfor har du brug for partitionering?
Det, som partitionering giver, tror jeg alle ved, er tabelopdeling. Ofte er disse separate filer på disk og span-anmodninger. Den vælger en partition mere optimalt, hvis den er en del af normal partitionering.
For Zabbix er det især brugt af område, efter område, det vil sige, vi bruger et tidsstempel (et regulært tal, tid siden begyndelsen af epoken). Du angiver starten på dagen/slutningen af dagen, og dette er partitionen. Derfor, hvis du beder om data, der er to dage gamle, hentes alt hurtigere fra databasen, fordi du kun behøver at indlæse én fil i cachen og returnere den (i stedet for en stor tabel).
Mange databaser fremskynder også indsættelse (indsættelse i én undertabel). Jeg taler abstrakt for nu, men det er også muligt. Partitonering hjælper ofte.
Elasticsearch for NoSQL
For nylig, i 3.4, implementerede vi en NoSQL-løsning. Tilføjet muligheden for at skrive i Elasticsearch. Du kan skrive visse typer: du vælger - enten skrive tal eller nogle tegn; vi har strengtekst, du kan skrive logs til Elasticsearch... Følgelig vil webgrænsefladen også få adgang til Elasticsearch. Dette fungerer godt i nogle tilfælde, men i øjeblikket kan det bruges.
TidsskalaDB. Hypertabeller
For 4.4.2 var vi opmærksomme på én ting som TimescaleDB. Hvad er det? Dette er en udvidelse til PostgreSQL, det vil sige, den har en indbygget PostgreSQL-grænseflade. Plus, denne udvidelse giver dig mulighed for at arbejde meget mere effektivt med tidsseriedata og have automatisk partitionering. Hvad det ligner:
Dette er hypertabel - der er sådan et koncept i Timescale. Dette er en hypertabel, som du opretter, og den indeholder bidder. Chunks er partitioner, det er underordnede tabeller, hvis jeg ikke tager fejl. Det er virkelig effektivt.
TimescaleDB og PostgreSQL
Som TimescaleDB-producenterne forsikrer, bruger de en mere korrekt algoritme til behandling af forespørgsler, især inserts, hvilket giver dem mulighed for at have nogenlunde konstant ydeevne med en stigende størrelse af datasætindsatsen. Det vil sige, efter 200 millioner rækker Postgres, begynder den sædvanlige at synke meget og mister ydelsen bogstaveligt talt til nul, mens Timescale giver dig mulighed for at indsætte indstik så effektivt som muligt med enhver mængde data.
Hvordan installeres TimescaleDB? Det er simpelt!
Det er i dokumentationen, det er beskrevet - du kan installere det fra pakker til enhver... Det afhænger af de officielle Postgres-pakker. Kan kompileres manuelt. Det skete så, at jeg var nødt til at kompilere til databasen.
På Zabbix aktiverer vi blot Extention. Jeg tror, at dem, der brugte Extention i Postgres... Du aktiverer blot Extention, opretter den til Zabbix-databasen, som du bruger.
Og det sidste skridt...
TidsskalaDB. Migration af historietabeller
Du skal oprette en hypertabel. Der er en speciel funktion til dette – Opret hypertabel. I den er den første parameter den tabel, der er nødvendig i denne database (som du skal oprette en hypertabel til).
Feltet til at oprette, og chunk_time_interval (dette er intervallet af chunks (partitioner, der skal bruges). 86 er én dag.
Migrate_data-parameter: Hvis du indsætter til true, vil dette migrere alle aktuelle data til præ-oprettede bidder.
Jeg har selv brugt migrate_data - det tager en del tid, alt efter hvor stor din database er. Jeg havde over en terabyte - det tog over en time at skabe. I nogle tilfælde, under test, slettede jeg historiske data for tekst (history_text) og string (history_str) for ikke at overføre dem - de var ikke rigtig interessante for mig.
Og vi laver den sidste opdatering i vores db_extention: vi installerer timescaledb, så databasen og især vores Zabbix forstår, at der er db_extention. Han aktiverer det og bruger den korrekte syntaks og forespørgsler til databasen ved at bruge de "funktioner", der er nødvendige for TimescaleDB.
Server konfiguration
Jeg brugte to servere. Den første server er en ret lille virtuel maskine, 20 processorer, 16 gigabyte RAM. Jeg konfigurerede Postgres 10.8 på det:
Operativsystemet var Debian, filsystemet var xfs. Jeg lavede minimale indstillinger for at bruge denne særlige database, minus hvad Zabbix selv vil bruge. På samme maskine var der en Zabbix server, PostgreSQL og load agents.
Jeg har brugt 50 aktive agenter, der bruger LoadableModule til hurtigt at generere forskellige resultater. Det er dem, der genererede strengene, tallene og så videre. Jeg fyldte databasen med en masse data. Oprindeligt indeholdt konfigurationen 5 tusinde dataelementer pr. vært, og cirka hvert dataelement indeholdt en trigger - for at dette skulle være en rigtig opsætning. Nogle gange har du endda brug for mere end én trigger for at bruge.
Jeg regulerede opdateringsintervallet og selve belastningen ved ikke kun at bruge 50 agenter (tilføje flere), men også ved at bruge dynamiske dataelementer og reducere opdateringsintervallet til 4 sekunder.
Præstationstest. PostgreSQL: 36 tusinde NVP'er
Den første lancering, den første opsætning, jeg havde, var på ren PostreSQL 10 på denne hardware (35 tusinde værdier pr. sekund). Generelt, som du kan se på skærmen, tager indsættelse af data brøkdele af et sekund – alt er godt og hurtigt, SSD-drev (200 gigabyte). Det eneste er, at 20 GB fyldes ret hurtigt.
Der vil være ret mange af den slags grafer i fremtiden. Dette er et standard Zabbix-serverydelses-dashboard.
Den første graf er antallet af værdier pr. sekund (blå, øverst til venstre), 35 tusinde værdier i dette tilfælde. Dette (øverst i midten) er indlæsningen af byggeprocesser, og dette (øverst til højre) er indlæsningen af interne processer: historiesyncere og husholderske, som her (nederst i midten) har kørt i et stykke tid.
Denne graf (nederst i midten) viser ValueCache-brug - hvor mange ValueCache-hits for triggere (flere tusinde værdier pr. sekund). En anden vigtig graf er den fjerde (nederst til venstre), som viser brugen af HistoryCache, som jeg talte om, som er en buffer før indsættelse i databasen.
Præstationstest. PostgreSQL: 50 tusinde NVP'er
Dernæst øgede jeg belastningen til 50 tusinde værdier pr. sekund på den samme hardware. Når den blev indlæst af Housekeeper, blev 10 tusinde værdier registreret på 2-3 sekunder med beregning. Hvad der faktisk vises i følgende skærmbillede:
"Husholderske" er allerede begyndt at forstyrre arbejdet, men generelt er belastningen på historiesynkefangere stadig på niveauet 60% (tredje graf, øverst til højre). HistoryCache begynder allerede at fylde aktivt, mens Housekeeper kører (nederst til venstre). Den var omkring en halv gigabyte, 20 % fuld.
Præstationstest. PostgreSQL: 80 tusinde NVP'er
Så øgede jeg det til 80 tusinde værdier pr. sekund:
Det var cirka 400 tusinde dataelementer, 280 tusinde triggere. Indsatsen, som du kan se, med hensyn til belastningen af historiesynker (der var 30 af dem) var allerede ret høj. Derefter øgede jeg forskellige parametre: historiesynker, cache... På denne hardware begyndte belastningen på historiesynker at stige til et maksimum, næsten "på hylden" - følgelig gik HistoryCache i en meget høj belastning:
Hele denne tid overvågede jeg alle systemparametre (hvordan processoren bruges, RAM) og opdagede, at diskudnyttelsen var maksimal - jeg opnåede den maksimale kapacitet af denne disk på denne hardware, på denne virtuelle maskine. "Postgres" begyndte at dumpe data ret aktivt med en sådan intensitet, og disken havde ikke længere tid til at skrive, læse...
Jeg tog en anden server, der allerede havde 48 processorer og 128 gigabyte RAM:
Jeg "tunede" den også - installerede History syncer (60 stykker) og opnåede acceptabel ydeevne. Faktisk er vi ikke "på hylden", men det er nok grænsen for produktiviteten, hvor det allerede er nødvendigt at gøre noget ved det.
Præstationstest. TidsskalaDB: 80 tusinde NVP'er
Min primære opgave var at bruge TimescaleDB. Hver graf viser et fald:
Disse fejl er netop datamigrering. Derefter, i Zabbix-serveren, ændrede ladningsprofilen for historiesænkere sig meget, som du kan se. Det giver dig mulighed for at indsætte data næsten 3 gange hurtigere og bruge mindre HistoryCache - derfor vil du få data leveret til tiden. Igen er 80 tusinde værdier pr. sekund en ret høj hastighed (selvfølgelig ikke for Yandex). Alt i alt er dette et ret stort setup med én server.
PostgreSQL præstationstest: 120 tusinde NVP'er
Dernæst øgede jeg værdien af antallet af dataelementer til en halv million og modtog en beregnet værdi på 125 tusinde pr. sekund:
Og jeg fik disse grafer:
I princippet er dette et fungerende setup, det kan fungere i ret lang tid. Men da jeg kun havde en 1,5 terabyte disk, brugte jeg den op på et par dage. Det vigtigste er, at der samtidig blev oprettet nye partitioner på TimescaleDB, og det var helt ubemærket for ydeevnen, hvilket ikke kan siges om MySQL.
Typisk oprettes partitioner om natten, fordi dette generelt blokerer for indsættelse og arbejde med tabeller og kan føre til forringelse af tjenesten. I dette tilfælde er dette ikke tilfældet! Hovedopgaven var at teste funktionerne i TimescaleDB. Resultatet var følgende tal: 120 tusinde værdier pr. sekund.
Der er også eksempler i samfundet:
Personen tændte også for TimescaleDB og belastningen på at bruge io.weight faldt på processoren; og brugen af interne proceselementer er også faldet på grund af medtagelsen af TimescaleDB. Desuden er der tale om almindelige pandekagediske, det vil sige en almindelig virtuel maskine på almindelige diske (ikke SSD'er)!
For nogle små opsætninger, der er begrænset af diskens ydeevne, er TimescaleDB efter min mening en meget god løsning. Det giver dig mulighed for at fortsætte med at arbejde, før du migrerer til hurtigere hardware til databasen.
Jeg inviterer jer alle til vores arrangementer: Konference i Moskva, topmøde i Riga. Brug vores kanaler - Telegram, forum, IRC. Hvis du har spørgsmål, så kom til vores skrivebord, vi kan tale om alt.
Spørgsmål fra publikum
Spørgsmål fra publikum (i det følgende - A): - Hvis TimescaleDB er så let at konfigurere, og det giver sådan et ydelsesboost, så burde dette måske bruges som en best practice til at konfigurere Zabbix med Postgres? Og er der nogle faldgruber og ulemper ved denne løsning, eller når alt kommer til alt, hvis jeg besluttede at lave Zabbix for mig selv, kan jeg sagtens tage Postgres, installere Timescale der med det samme, bruge det og ikke tænke på problemer?
AG: – Ja, jeg vil sige, at dette er en god anbefaling: brug Postgres med det samme med TimescaleDB-udvidelsen. Som jeg allerede sagde, mange gode anmeldelser, på trods af at denne "funktion" er eksperimentel. Men faktisk viser test, at dette er en fantastisk løsning (med TimescaleDB), og jeg tror, den vil udvikle sig! Vi overvåger, hvordan denne udvidelse udvikler sig og vil foretage ændringer efter behov.
Selv under udviklingen stolede vi på en af deres velkendte "funktioner": det var muligt at arbejde med chunks lidt anderledes. Men så skar de det ud i den næste udgivelse, og vi behøvede ikke længere at stole på denne kode. Jeg vil anbefale at bruge denne løsning på mange opsætninger. Hvis du bruger MySQL... For gennemsnitlige opsætninger fungerer enhver løsning godt.
EN: – På de sidste grafer fra fællesskabet var der en graf med "Husholderske":
Han fortsatte med at arbejde. Hvad laver Housekeeper med TimescaleDB?
AG: - Nu kan jeg ikke sige det med sikkerhed - jeg vil se på koden og fortælle dig mere detaljeret. Den bruger TimescaleDB-forespørgsler til ikke at slette bidder, men til på en eller anden måde at aggregere dem. Jeg er ikke klar til at besvare dette tekniske spørgsmål endnu. Vi finder ud af mere på standen i dag eller i morgen.
EN: – Jeg har et lignende spørgsmål – om udførelsen af sletteoperationen i Timescale.
A (svar fra publikum): – Når du sletter data fra en tabel, hvis du gør det via slet, så skal du gennemgå tabellen - slette, rense, markere alt til fremtidig vakuum. I Timescale, da du har bidder, kan du slippe. Groft sagt fortæller du blot filen, der er i big data: "Slet!"
Timescale forstår simpelthen, at sådan en del ikke længere eksisterer. Og da den er integreret i forespørgselsplanlæggeren, bruger den kroge til at fange dine forhold i udvalgte eller andre operationer og forstår straks, at denne del ikke længere eksisterer - "Jeg vil ikke gå derhen mere!" (data ikke tilgængelige). Det er alt! Det vil sige, at en tabelscanning erstattes af en binær filsletning, så det er hurtigt.
EN: – Vi har allerede berørt emnet ikke-SQL. Så vidt jeg forstår, behøver Zabbix ikke rigtig at ændre dataene, og alt dette er noget som en log. Er det muligt at bruge specialiserede databaser, der ikke kan ændre deres data, men samtidig gemme, akkumulere og distribuere meget hurtigere - Clickhouse, for eksempel noget Kafka-agtigt?.. Kafka er også en log! Er det muligt på en eller anden måde at integrere dem?
AG: - Aflæsning kan ske. Vi har en vis "funktion" siden version 3.4: du kan skrive alle historiske filer, begivenheder, alt andet til filer; og derefter sende den til en hvilken som helst anden database ved hjælp af en eller anden handler. Faktisk omarbejder og skriver mange mennesker direkte til databasen. På farten skriver historiesynker alt dette til filer, roterer disse filer og så videre, og du kan overføre dette til Clickhouse. Jeg kan ikke sige noget om planer, men måske vil yderligere support til NoSQL-løsninger (såsom Clickhouse) fortsætte.
EN: – Generelt viser det sig, at man helt kan slippe af med postgres?
AG: – Selvfølgelig er den sværeste del i Zabbix de historiske tabeller, som skaber flest problemer og begivenheder. I dette tilfælde, hvis du ikke gemmer begivenheder i lang tid og gemmer historien med tendenser i en anden hurtig opbevaring, så tror jeg generelt, at der ikke vil være nogen problemer.
EN: – Kan du vurdere, hvor meget hurtigere alting vil fungere, hvis du for eksempel skifter til Clickhouse?
AG: - Jeg har ikke testet det. Jeg tror, at i det mindste de samme tal kan opnås ganske enkelt, givet at Clickhouse har sin egen grænseflade, men jeg kan ikke sige det med sikkerhed. Det er bedre at teste. Det hele afhænger af konfigurationen: hvor mange værter du har, og så videre. Indsættelse er én ting, men du skal også hente disse data - Grafana eller noget andet.
EN: – Så vi taler om en lige kamp, og ikke om den store fordel ved disse hurtige databaser?
AG: - Jeg tror, at når vi integrerer, vil der være mere præcise tests.
EN: – Hvor blev gode gamle RRD af? Hvad fik dig til at skifte til SQL-databaser? Til at begynde med blev alle metrics indsamlet på RRD.
AG: – Zabbix havde RRD, måske i en meget gammel version. Der har altid været SQL-databaser – en klassisk tilgang. Den klassiske tilgang er MySQL, PostgreSQL (de har eksisteret i meget lang tid). Vi brugte næsten aldrig en fælles grænseflade til SQL- og RRD-databaser.
Nogle annoncer 🙂
Tak fordi du blev hos os. Kan du lide vores artikler? Vil du se mere interessant indhold? Støt os ved at afgive en ordre eller anbefale til venner, , en unik analog af entry-level servere, som blev opfundet af os til dig: (tilgængelig med RAID1 og RAID10, op til 24 kerner og op til 40 GB DDR4).
Dell R730xd 2 gange billigere i Equinix Tier IV datacenter i Amsterdam? Kun her i Holland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Læse om
Kilde: www.habr.com