Tarkastellaan kuinka Zabbix toimii TimescaleDB-tietokannan kanssa taustaohjelmana. Näytämme sinulle, kuinka aloittaa alusta ja kuinka siirtyä PostgreSQL:stä. Tarjoamme myös vertailevia suorituskykytestejä kahdelle kokoonpanolle.
HighLoad++ Siperia 2019. Tomsk Hall. 24. kesäkuuta klo 16. Opinnäytetyöt ja . Seuraava HighLoad++-konferenssi järjestetään 6. ja 7 Pietarissa. Lisätiedot ja liput .
Andrey Gushchin (jäljempänä – AG): – Olen ZABBIXin teknisen tuen insinööri (jäljempänä "Zabbix"), kouluttaja. Olen työskennellyt teknisen tuen parissa yli 6 vuotta ja minulla on suoraa kokemusta suorituksesta. Tänään puhun suorituskyvystä, jonka TimescaleDB voi tarjota verrattuna tavalliseen PostgreSQL 10:een. Lisäksi muutama johdanto-osa sen toiminnasta yleensä.
Tärkeimmät tuottavuushaasteet: tiedonkeruusta tietojen puhdistamiseen
Ensinnäkin jokainen valvontajärjestelmä kohtaa tiettyjä suorituskykyhaasteita. Ensimmäinen tuottavuuden haaste on tiedon nopea kerääminen ja käsittely.
Hyvän valvontajärjestelmän tulee vastaanottaa kaikki tiedot nopeasti, oikea-aikaisesti, käsitellä se trigger-lausekkeiden mukaan, eli käsitellä se tiettyjen kriteerien mukaan (tämä on erilaista eri järjestelmissä) ja tallentaa se tietokantaan käyttääkseen näitä tietoja tulevaisuutta.
Toinen suorituskykyhaaste on historian tallennus. Tallenna tietokantaan usein ja pääset nopeasti ja kätevästi käsiksi näihin mittareihin, jotka on kerätty tietyn ajanjakson aikana. Tärkeintä on, että nämä tiedot on helppo hankkia, käyttää niitä raporteissa, kaavioissa, triggereissä, joissakin kynnysarvoissa, hälytyksissä jne.
Kolmas suorituskykyhaaste on historian tyhjennys, eli kun pääset siihen pisteeseen, että sinun ei tarvitse tallentaa yksityiskohtaisia mittareita, jotka on kerätty 5 vuoden aikana (jopa kuukausi tai kaksi kuukautta). Jotkut verkkosolmut poistettiin tai jotkut isännät, mittareita ei enää tarvita, koska ne ovat jo vanhentuneita eikä niitä enää kerätä. Kaikki tämä on siivottava, jotta tietokanta ei kasva liian suureksi. Yleisesti ottaen historian tyhjentäminen on useimmiten vakava testi tallennustilalle - sillä on usein erittäin vahva vaikutus suorituskykyyn.
Kuinka ratkaista välimuistiongelmia?
Puhun nyt erityisesti Zabbixista. Zabbixissa ensimmäinen ja toinen puhelu ratkaistaan välimuistin avulla.
Tiedonkeruu ja käsittely - Käytämme RAM-muistia kaikkien näiden tietojen tallentamiseen. Näitä tietoja käsitellään nyt tarkemmin.
Myös tietokantapuolella on välimuistia päävalinnoille - kaavioille ja muille asioille.
Välimuisti Zabbix-palvelimen puolella: meillä on ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Mikä se on?
ConfigurationCache on päävälimuisti, johon tallennamme mittareita, isäntiä, tietokohteita ja laukaisimia; kaikki mitä tarvitset esikäsittelyyn, kerää dataa, mistä isännistä kerätä, millä taajuudella. Kaikki tämä on tallennettu ConfigurationCacheen, jotta ei mene tietokantaan ja luo tarpeettomia kyselyitä. Kun palvelin käynnistyy, päivitämme tämän välimuistin (luomme sen) ja päivitämme sen säännöllisesti (kokoonpanoasetuksista riippuen).
Välimuisti Zabbixissa. Tiedonkeruu
Tässä kaavio on melko suuri:
Tärkeimmät järjestelmässä ovat nämä keräilijät:
Nämä ovat itse kokoamisprosesseja, erilaisia "pollereita", jotka vastaavat erityyppisistä kokoonpanoista. He keräävät dataa icmp:n, ipmi:n ja eri protokollien kautta ja siirtävät sen kaiken esikäsittelyyn.
Esikäsittelyhistoriavälimuisti
Lisäksi, jos meillä on laskettuja tietoelementtejä (Zabbixin tuntevat tietävät), eli laskettuja aggregoituja tietoelementtejä, otamme ne suoraan ValueCachesta. Kerron myöhemmin kuinka se täytetään. Kaikki nämä kerääjät käyttävät ConfigurationCachea vastaanottaakseen työnsä ja välittääkseen ne sitten esikäsittelyyn.
Esikäsittely käyttää myös ConfigurationCachea esikäsittelyvaiheiden hankkimiseen ja näiden tietojen käsittelemiseen eri tavoin. Versiosta 4.2 alkaen olemme siirtäneet sen välityspalvelimelle. Tämä on erittäin kätevää, koska itse esikäsittely on melko vaikea toimenpide. Ja jos sinulla on erittäin suuri Zabbix, jossa on suuri määrä tietoelementtejä ja korkea keräystaajuus, tämä yksinkertaistaa työtä huomattavasti.
Соответственно, после того как мы обработали эти данные каким-либо образом с помощью препроцессинга, сохраняем их в HistoryCache для того, чтобы их дальше обработать. На этом заканчивается сбор данных. Мы переходим к главному процессу.
Historian synkronoijan työ
Zabbixin pääprosessi (koska se on monoliittinen arkkitehtuuri) on Historian synkronointi. Tämä on pääprosessi, joka käsittelee erityisesti kunkin tietoelementin eli jokaisen arvon atomikäsittelyä:
- arvo tulee (se ottaa sen HistoryCachesta);
- tarkistaa Configuration Syncer:ssä: onko laskennassa laukaisuja - laskee ne;
jos on - luo tapahtumia, luo eskaloinnin hälytyksen luomiseksi, tarvittaessa konfiguraation mukaan; - tallentaa laukaisimia myöhempää käsittelyä, yhdistämistä varten; jos kokoat viimeisen tunnin ajalta ja niin edelleen, ValueCache muistaa tämän arvon, jotta se ei mene historiataulukkoon; Siten ValueCache on täytetty tarvittavilla tiedoilla, joita tarvitaan laukaisimien, laskettujen elementtien jne. laskemiseen;
- sitten History syncer kirjoittaa kaikki tiedot tietokantaan;
- tietokanta kirjoittaa ne levylle - tähän käsittelyprosessi päättyy.
Tietokanta. Välimuisti
Tietokannan puolella, kun haluat tarkastella kaavioita tai joitain raportteja tapahtumista, on erilaisia välimuistia. Mutta tässä raportissa en puhu niistä.
MySQL:lle on Innodb_buffer_pool ja joukko erilaisia välimuistia, jotka voidaan myös määrittää.
Mutta nämä ovat tärkeimmät:
- jaetut_puskurit;
- tehokas_välimuistin_koko;
- jaettu_allas.
Kaikille tietokannoille sanoin, että on tiettyjä välimuistia, joiden avulla voit tallentaa RAM-muistiin tiedot, joita usein tarvitaan kyselyihin. Heillä on omat teknologiansa tätä varten.
Tietoja tietokannan suorituskyvystä
Vastaavasti on olemassa kilpailuympäristö, eli Zabbix-palvelin kerää tietoja ja tallentaa sen. Kun se käynnistetään uudelleen, se lukee myös historiasta ValueCachen täyttämiseksi ja niin edelleen. Täällä voit käyttää komentosarjoja ja raportteja, jotka käyttävät Zabbix API:ta, joka on rakennettu verkkokäyttöliittymään. Zabbix API tulee tietokantaan ja vastaanottaa tarvittavat tiedot kaavioiden, raporttien tai jonkinlaisen tapahtumaluettelon, viimeaikaisten ongelmien saamiseksi.
Myös erittäin suosittu visualisointiratkaisu on Grafana, jota käyttäjämme käyttävät. Pystyy kirjautumaan suoraan sisään sekä Zabbix API:n että tietokannan kautta. Se luo myös tietynlaista kilpailua tiedon saamisesta: tietokannan tarkempaa ja parempaa viritystä tarvitaan tulosten nopean toimituksen ja testauksen noudattamiseksi.
Tyhjennä historia. Zabbixilla on taloudenhoitaja
Kolmas Zabbixissa käytetty puhelu on historian tyhjennys Housekeeperin avulla. Taloudenhoitaja seuraa kaikkia asetuksia, eli tietoelementit osoittavat, kuinka kauan säilytetään (päivissä), kuinka kauan säilytetään trendejä ja muutosten dynamiikkaa.
En puhunut TrendCachesta, jonka laskemme lennossa: tiedot saapuvat, aggregoimme niitä yhdeltä tunnilta (useimmiten nämä ovat viimeisen tunnin lukuja), määrä on keskimääräinen/minimi ja tallennamme sen kerran tunnissa taulukko muutosten dynamiikasta ("Trendit") . "Housekeeper" käynnistää ja poistaa tiedot tietokannasta tavallisilla valinnoilla, mikä ei aina ole tehokasta.
Kuinka ymmärtää, että se on tehoton? Voit nähdä seuraavan kuvan sisäisten prosessien suorituskykykaavioista:
Historian synkronointi on jatkuvasti varattu (punainen kaavio). Ja "punainen" kaavio, joka menee päälle. Tämä on "talonhoitaja", joka käynnistyy ja odottaa, että tietokanta poistaa kaikki sen määrittämät rivit.
Otetaan jokin tuotetunnus: sinun on poistettava viimeiset 5 tuhatta; tietysti indekseillä. Mutta yleensä tietojoukko on melko suuri - tietokanta silti lukee sen levyltä ja laittaa sen välimuistiin, ja tämä on tietokannan kannalta erittäin kallis toimenpide. Sen koosta riippuen tämä voi johtaa tiettyihin suorituskykyongelmiin.
Voit poistaa Housekeeperin käytöstä yksinkertaisella tavalla - meillä on tuttu verkkokäyttöliittymä. Asetukset kohdassa Hallinta yleiset (asetukset "Taloudenhoitaja") poistamme sisäisen taloudenpidon käytöstä sisäisen historian ja trendien vuoksi. Näin ollen taloudenhoitaja ei enää hallitse tätä:
Mitä voit tehdä seuraavaksi? Sammutit sen, kaaviosi ovat tasoittuneet... Mitä muita ongelmia tässä tapauksessa voi ilmetä? Mikä voi auttaa?
Osiointi (osioiminen)
Tyypillisesti tämä on määritetty eri tavalla jokaisessa luettelossani relaatiotietokannassa. MySQL:llä on oma tekniikkansa. Mutta kaiken kaikkiaan ne ovat hyvin samankaltaisia, kun kyse on PostgreSQL 10:stä ja MySQL:stä. Tietysti on monia sisäisiä eroja siinä, miten se kaikki toteutetaan ja miten se kaikki vaikuttaa suorituskykyyn. Mutta yleensä uuden osion luominen johtaa usein myös tiettyihin ongelmiin.
Asetuksistasi riippuen (kuinka paljon dataa luot yhdessä päivässä), he asettavat yleensä minimin - tämä on 1 päivä / erä, ja "trendeille" muutosten dynamiikalle - 1 kuukausi / uusi erä. Tämä voi muuttua, jos sinulla on erittäin suuri kokoonpano.
Sanotaan heti asennuksen koosta: jopa 5 tuhatta uutta arvoa sekunnissa (ns. nvps) - tätä pidetään pienenä "asennuksena". Keskiarvo - 5 - 25 tuhatta arvoa sekunnissa. Kaikki yllä oleva on jo suuria ja erittäin suuria asennuksia, jotka vaativat erittäin huolellista tietokannan konfigurointia.
Erittäin suurissa asennuksissa 1 päivä ei ehkä ole optimaalinen. Olen henkilökohtaisesti nähnyt MySQL:n osioiden 40 gigatavua päivässä (ja niitä voi olla enemmän). Tämä on erittäin suuri tietomäärä, mikä voi johtaa joihinkin ongelmiin. Sitä on vähennettävä.
Miksi tarvitset osiointia?
Luulen, että kaikki tietävät, mitä osiointi tarjoaa, on taulukkoosiointi. Usein nämä ovat erillisiä levy- ja span-pyyntöjä. Se valitsee yhden osion optimaalisesti, jos se on osa normaalia osiointia.
Varsinkin Zabbixissa sitä käytetään alueen mukaan, eli käytämme aikaleimaa (säännöllinen luku, aika aikakauden alusta). Määrität päivän alun/päivän lopun, ja tämä on osio. Vastaavasti, jos pyydät kaksi päivää vanhoja tietoja, kaikki haetaan tietokannasta nopeammin, koska sinun tarvitsee ladata vain yksi tiedosto välimuistiin ja palauttaa se (eikä suuri taulukko).
Monet tietokannat myös nopeuttavat lisäystä (lisääminen yhteen alitaulukkoon). Puhun nyt abstraktisti, mutta tämäkin on mahdollista. Jakaminen auttaa usein.
Elasticsearch for NoSQL
Äskettäin 3.4:ssä otimme käyttöön NoSQL-ratkaisun. Lisätty kyky kirjoittaa Elasticsearchissa. Voit kirjoittaa tiettyjä tyyppejä: valitset - joko kirjoita numeroita tai joitain merkkejä; meillä on merkkijonotekstiä, voit kirjoittaa lokeja Elasticsearchiin... Vastaavasti web-käyttöliittymä käyttää myös Elasticsearchia. Tämä toimii joissain tapauksissa hyvin, mutta tällä hetkellä sitä voidaan käyttää.
TimescaleDB. Hypertabletit
4.4.2:ssa kiinnitimme huomiota yhteen asiaan, kuten TimescaleDB. Mikä se on? Tämä on PostgreSQL-laajennus, eli sillä on natiivi PostgreSQL-käyttöliittymä. Lisäksi tämän laajennuksen avulla voit työskennellä paljon tehokkaammin aikasarjatietojen kanssa ja automaattisen osioinnin. Miltä se näyttää:
Tämä on hypertabletti - aikaskaalassa on sellainen käsite. Tämä on luomasi hypertaulukko, joka sisältää paloja. Palat ovat osioita, nämä ovat lapsitaulukoita, jos en erehdy. Se on todella tehokasta.
TimescaleDB ja PostgreSQL
Kuten TimescaleDB-valmistajat vakuuttavat, he käyttävät oikeampaa algoritmia kyselyjen, erityisesti lisäysten, käsittelyyn, mikä mahdollistaa niiden suorituskyvyn suunnilleen vakiona tietojoukkolisäyksen kasvaessa. Toisin sanoen 200 miljoonan Postgres-rivin jälkeen tavallinen alkaa painua voimakkaasti ja menettää suorituskyvyn kirjaimellisesti nollaan, kun taas Timescale mahdollistaa lisäosien lisäämisen mahdollisimman tehokkaasti millä tahansa tietomäärällä.
Kuinka asentaa TimescaleDB? Se on yksinkertaista!
Se on dokumentaatiossa, se on kuvattu - voit asentaa sen minkä tahansa paketeista... Se riippuu virallisista Postgres-paketeista. Voidaan koota manuaalisesti. Kävi niin, että minun piti kääntää tietokantaa varten.
Zabbixissa yksinkertaisesti aktivoimme laajennuksen. Luulen, että ne, jotka käyttivät laajennusta Postgresissa... Aktivoit vain laajennuksen ja luot sen käyttämääsi Zabbix-tietokantaan.
Ja viimeinen askel...
TimescaleDB. Historiataulukoiden siirto
Sinun on luotava hypertaulukko. Tätä varten on erityinen toiminto - Luo hypertaulukko. Siinä ensimmäinen parametri on taulukko, jota tarvitaan tässä tietokannassa (jolle sinun on luotava hypertaulukko).
Kenttä, jolla luodaan, ja chunk_time_interval (tämä on kappaleiden (käytettävät osiot) väli. 86 400 on yksi päivä.
Migrate_data-parametri: Jos lisäät arvoon true, tämä siirtää kaikki nykyiset tiedot valmiiksi luotuihin osiin.
Olen itse käyttänyt migrate_dataa - se vie melko paljon aikaa tietokannan koosta riippuen. Minulla oli yli teratavu – luomiseen meni yli tunti. Joissakin tapauksissa testauksen aikana poistin historialliset tiedot tekstistä (history_text) ja merkkijonosta (history_str), jotta en siirtäisi niitä - ne eivät olleet minulle todella kiinnostavia.
Ja teemme viimeisen päivityksen db_extention:iin: asennamme timescaledb:n, jotta tietokanta ja erityisesti Zabbix ymmärtävät, että db_extention on olemassa. Hän aktivoi sen ja käyttää oikeaa syntaksia ja kyselyitä tietokantaan käyttämällä TimescaleDB:lle välttämättömiä "ominaisuuksia".
Palvelimen määritykset
Käytin kahta palvelinta. Ensimmäinen palvelin on melko pieni virtuaalikone, 20 prosessoria, 16 gigatavua RAM-muistia. Asensin siihen Postgres 10.8:n:
Käyttöjärjestelmä oli Debian, tiedostojärjestelmä xfs. Tein minimaaliset asetukset tämän tietokannan käyttöä varten, miinus mitä Zabbix itse käyttää. Samassa koneessa oli Zabbix-palvelin, PostgreSQL ja latausagentit.
Olen käyttänyt 50 aktiivista ainetta, jotka käyttävät LoadableModulea erilaisten tulosten nopeaan luomiseen. He ovat luoneet merkkijonot, numerot ja niin edelleen. Täytin tietokannan paljon dataa. Aluksi konfiguraatio sisälsi 5 tuhatta tietoelementtiä isäntä kohden, ja suunnilleen jokainen tietoelementti sisälsi liipaisimen - jotta tämä olisi todellinen kokoonpano. Joskus tarvitset jopa useamman kuin yhden liipaisimen käytettäväksi.
Säädin päivitysväliä ja itse kuormitusta käyttämällä 50 agentin lisäksi dynaamisia tietoelementtejä ja vähentämällä päivitysväliä 4 sekuntiin.
Suorituskykytesti. PostgreSQL: 36 tuhatta NVP:tä
Ensimmäinen käynnistys, ensimmäinen asennus, joka minulla oli, oli puhdas PostreSQL 10 tällä laitteistolla (35 tuhatta arvoa sekunnissa). Yleensä, kuten näytöltä näkyy, tietojen lisääminen kestää sekunnin murto-osan - kaikki on hyvää ja nopeaa, SSD-asemat (200 gigatavua). Ainoa asia on, että 20 Gt täyttyy melko nopeasti.
Tällaisia kaavioita tulee olemaan tulevaisuudessa melko paljon. Tämä on tavallinen Zabbix-palvelimen suorituskyvyn kojelauta.
Ensimmäinen kaavio on arvojen lukumäärä sekunnissa (sininen, ylävasen), tässä tapauksessa 35 tuhatta arvoa. Tämä (ylhäällä keskellä) on rakennusprosessien lataus, ja tämä (ylhäällä oikealla) on sisäisten prosessien lataus: historian synkronoijat ja taloudenhoitaja, joka täällä (alhaalla keskellä) on ollut käynnissä jo jonkin aikaa.
Tämä kaavio (alhaalla keskellä) näyttää ValueCachen käytön – kuinka monta ValueCache-osumia laukaisimia varten (useita tuhansia arvoja sekunnissa). Toinen tärkeä kaavio on neljäs (alhaalla vasemmalla), joka näyttää HistoryCachen käytön, josta puhuin, joka on puskuri ennen tietokantaan lisäämistä.
Suorituskykytesti. PostgreSQL: 50 tuhatta NVP:tä
Seuraavaksi lisäsin kuormitusta 50 tuhanteen arvoon sekunnissa samalla laitteistolla. Housekeeperin lataamana 10 tuhatta arvoa kirjattiin 2-3 sekunnissa laskennalla. Mitä itse asiassa näkyy seuraavassa kuvakaappauksessa:
"Taloudenhoitaja" alkaa jo häiritä työntekoa, mutta yleisesti ottaen historian uppoajien ansojen kuormitus on edelleen 60% tasolla (kolmas kaavio, ylhäällä oikea). HistoryCache alkaa jo täyttyä aktiivisesti taloudenhoitajan ollessa käynnissä (alas vasemmalla). Se oli noin puoli gigatavua, 20 % täynnä.
Suorituskykytesti. PostgreSQL: 80 tuhatta NVP:tä
Sitten lisäsin sen 80 tuhanteen arvoon sekunnissa:
Se oli noin 400 tuhatta tietoelementtiä, 280 tuhatta laukaisua. Insertti, kuten näette, oli historian uppoajien kuormituksella (niitä oli 30) jo melko korkealla. Sitten lisäsin erilaisia parametreja: historian uppoajia, välimuistia... Tällä laitteistolla historian uppoajien kuormitus alkoi kasvaa maksimiin, melkein "hyllylle" - vastaavasti HistoryCache meni erittäin suureen kuormaan:
Koko tämän ajan seurasin kaikkia järjestelmäparametreja (miten prosessoria käytetään, RAM) ja huomasin, että levyn käyttöaste oli maksimaalinen - saavutin tämän levyn enimmäiskapasiteetin tällä laitteistolla, tässä virtuaalikoneessa. "Postgres" alkoi tyhjentää dataa melko aktiivisesti sellaisella intensiteetillä, eikä levyllä enää ehtinyt kirjoittaa, lukea...
Otin toisen palvelimen, jossa oli jo 48 prosessoria ja 128 gigatavua RAM-muistia:
Myös "viritin" sitä - asensin History syncerin (60 kpl) ja saavutin hyväksyttävän suorituskyvyn. Itse asiassa emme ole "hyllyssä", mutta tämä on luultavasti tuottavuuden raja, jossa asialle on jo pakko tehdä jotain.
Suorituskykytesti. TimescaleDB: 80 tuhatta NVP:tä
Päätehtäväni oli käyttää TimescaleDB:tä. Jokainen kaavio näyttää laskun:
Nämä viat ovat juuri tietojen siirtoa. Sen jälkeen Zabbix-palvelimella historian uppoajien latausprofiili, kuten näet, muuttui paljon. Sen avulla voit lisätä tietoja lähes 3 kertaa nopeammin ja käyttää vähemmän HistoryCachea - näin ollen tiedot toimitetaan ajoissa. Jälleen 80 tuhatta arvoa sekunnissa on melko korkea nopeus (ei tietenkään Yandexille). Kaiken kaikkiaan tämä on melko suuri kokoonpano, jossa on yksi palvelin.
PostgreSQL-suorituskykytesti: 120 tuhatta NVP:tä
Seuraavaksi lisäsin tietoelementtien määrän puoleen miljoonaan ja sain laskennallisen arvon 125 tuhatta sekunnissa:
Ja sain nämä kaaviot:
Periaatteessa tämä on toimiva asennus, se voi toimia melko pitkään. Mutta koska minulla oli vain 1,5 teratavun levy, käytin sen loppuun parissa päivässä. Tärkeintä on, että samaan aikaan TimescaleDB:hen luotiin uusia osioita, ja tämä oli täysin huomaamaton suorituskyvyn suhteen, mitä ei voi sanoa MySQL:stä.
Tyypillisesti osiot luodaan yöllä, koska tämä yleensä estää lisäämisen ja työskentelyn taulukoiden kanssa ja voi johtaa palvelun heikkenemiseen. Tässä tapauksessa näin ei ole! Päätehtävänä oli testata TimescaleDB:n ominaisuuksia. Tuloksena oli seuraava luku: 120 tuhatta arvoa sekunnissa.
Yhteisössä on myös esimerkkejä:
Henkilö otti myös TimescaleDB:n käyttöön ja prosessorin io.weight-käytön kuormitus putosi; ja myös sisäisten prosessielementtien käyttö on vähentynyt TimescaleDB:n sisällyttämisen vuoksi. Lisäksi nämä ovat tavallisia pannukakkulevyjä, eli tavallisia virtuaalikoneita tavallisilla levyillä (ei SSD-levyillä)!
Joillekin pienille asetuksille, joita levyn suorituskyky rajoittaa, TimescaleDB on mielestäni erittäin hyvä ratkaisu. Sen avulla voit jatkaa työskentelyä ennen siirtymistä nopeampaan tietokannan laitteistoon.
Kutsun teidät kaikki tapahtumiimme: konferenssi Moskovaan, huippukokous Riikaan. Käytä kanaviamme - Telegram, foorumi, IRC. Jos sinulla on kysyttävää, tule tiskillemme, voimme keskustella kaikesta.
Yleisön kysymyksiä
Kysymys yleisöltä (jäljempänä - A): - Jos TimescaleDB on niin helppo konfiguroida ja se parantaa suorituskykyä, niin ehkä tätä pitäisi käyttää parhaana käytäntönä Zabbixin määrittämisessä Postgresin kanssa? Ja onko tässä ratkaisussa sudenkuoppia ja haittoja, tai jos päätin tehdä Zabbixin itselleni, voin helposti ottaa Postgresin, asentaa Timescalen sinne heti, käyttää sitä enkä ajattele mitään ongelmia?
AG: – Kyllä, sanoisin, että tämä on hyvä suositus: käytä Postgresia välittömästi TimescaleDB-laajennuksella. Kuten jo sanoin, paljon hyviä arvosteluja huolimatta siitä, että tämä "ominaisuus" on kokeellinen. Mutta itse asiassa testit osoittavat, että tämä on loistava ratkaisu (TimescaleDB:n kanssa) ja uskon, että se kehittyy! Seuraamme tämän laajennuksen kehittymistä ja teemme muutoksia tarpeen mukaan.
Jo kehitystyön aikana luotimme yhteen heidän tunnetuista "ominaisuuksistaan": paloja oli mahdollista työskennellä hieman eri tavalla. Mutta sitten he leikkasivat sen pois seuraavassa julkaisussa, ja meidän täytyi lopettaa luottaminen tähän koodiin. Suosittelen tämän ratkaisun käyttöä monissa asetuksissa. Jos käytät MySQL:ää... Keskimääräisissä asetuksissa mikä tahansa ratkaisu toimii hyvin.
ja: – Yhteisön viimeisissä kaavioissa oli kaavio "Taloudenhoitaja":
Hän jatkoi työskentelyä. Mitä taloudenhoitaja tekee TimescaleDB:n kanssa?
AG: – Nyt en voi sanoa varmaksi – katson koodia ja kerron tarkemmin. Se ei käytä TimescaleDB-kyselyjä osien poistamiseen, vaan niiden jotenkin yhdistämiseen. En ole vielä valmis vastaamaan tähän tekniseen kysymykseen. Katsomme lisää osastolla tänään tai huomenna.
ja: – Minulla on samanlainen kysymys – poistotoiminnon suorituskyvystä aikaskaalassa.
A (vastaus yleisöltä): – Kun poistat dataa taulukosta, jos teet sen poistamisen kautta, sinun täytyy käydä taulukko läpi - poista, puhdista, merkitse kaikki tulevaa tyhjiötä varten. Aikaskaalassa, koska sinulla on paloja, voit pudottaa. Karkeasti sanottuna sanot vain big datassa olevalle tiedostolle: "Poista!"
Ajan mittakaava yksinkertaisesti ymmärtää, ettei tällaista palaa ole enää olemassa. Ja koska se on integroitu kyselysuunnittelijaan, se käyttää koukkuja löytääkseen ehtosi valituissa tai muissa toimissa ja ymmärtää heti, että tätä palaa ei enää ole - "En mene sinne enää!" (tietoja ei saatavilla). Siinä kaikki! Toisin sanoen taulukon tarkistus korvataan binääritiedoston poistamisella, joten se on nopea.
ja: – Olemme jo käsitelleet ei-SQL:n aihetta. Ymmärtääkseni Zabbixin ei todellakaan tarvitse muokata tietoja, ja kaikki tämä on jotain lokin kaltaista. Onko mahdollista käyttää erikoistuneita tietokantoja, jotka eivät voi muuttaa tietojaan, mutta samalla tallentaa, kerääntyä ja levittää paljon nopeammin - Clickhouse esimerkiksi jotain kafkalaista?.. Kafka on myös loki! Onko mahdollista yhdistää ne jotenkin?
AG: - Purku voidaan tehdä. Meillä on tietty "ominaisuus" versiosta 3.4 lähtien: voit kirjoittaa kaikki historialliset tiedostot, tapahtumat ja kaikki muu tiedostoihin; ja lähetä se sitten mihin tahansa muuhun tietokantaan jollakin käsittelijällä. Itse asiassa monet ihmiset työskentelevät uudelleen ja kirjoittavat suoraan tietokantaan. Lennossa historian uppoavat kirjoittavat kaiken tämän tiedostoihin, kiertävät näitä tiedostoja ja niin edelleen, ja voit siirtää tämän Clickhouseen. Suunnitelmista en osaa sanoa, mutta ehkä lisätuki NoSQL-ratkaisuille (kuten Clickhouse) jatkuu.
ja: – Yleisesti ottaen käy ilmi, että voit päästä kokonaan eroon postgresista?
AG: – Tietysti Zabbixissa vaikein osa on historialliset taulukot, jotka aiheuttavat eniten ongelmia, ja tapahtumat. Tässä tapauksessa, jos et tallenna tapahtumia pitkään aikaan ja tallenna historiaa trendien kanssa johonkin muuhun nopeaan tallennustilaan, niin yleensä ei mielestäni tule ongelmia.
ja: – Osaatko arvioida, kuinka paljon nopeammin kaikki toimii, jos vaihdat esimerkiksi Clickhouseen?
AG: – En ole testannut. Uskon, että ainakin samat luvut voidaan saavuttaa melko yksinkertaisesti, koska Clickhousella on oma käyttöliittymä, mutta en voi sanoa varmaksi. On parempi testata. Kaikki riippuu kokoonpanosta: kuinka monta isäntäkonetta sinulla on ja niin edelleen. Lisääminen on yksi asia, mutta sinun on myös haettava nämä tiedot - Grafana tai jotain muuta.
ja: – Puhumme siis tasa-arvoisesta taistelusta, emme näiden nopeiden tietokantojen suuresta edusta?
AG: – Uskon, että kun integroimme, tulee tarkempia testejä.
ja: – Mihin vanha hyvä RRD katosi? Mikä sai sinut vaihtamaan SQL-tietokantoihin? Aluksi kaikki mittarit kerättiin RRD:stä.
AG: – Zabbixilla oli RRD, ehkä hyvin muinaisessa versiossa. SQL-tietokantoja on aina ollut – klassinen lähestymistapa. Klassinen lähestymistapa on MySQL, PostgreSQL (ne ovat olleet olemassa hyvin pitkään). Emme juuri koskaan käyttäneet yhteistä käyttöliittymää SQL- ja RRD-tietokannoille.
Muutamia mainoksia 🙂
Kiitos, että pysyt kanssamme. Pidätkö artikkeleistamme? Haluatko nähdä mielenkiintoisempaa sisältöä? Tue meitä tekemällä tilauksen tai suosittelemalla ystäville, , ainutlaatuinen lähtötason palvelimien analogi, jonka me keksimme sinulle: (saatavana RAID1:n ja RAID10:n kanssa, jopa 24 ydintä ja jopa 40 Gt DDR4-muistia).
Dell R730xd 2 kertaa halvempi Equinix Tier IV -palvelinkeskuksessa Amsterdamissa? Vain täällä Alankomaissa! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - alkaen 99 dollaria! Lukea
Lähde: will.com