Vaatame, kuidas Zabbix töötab TimescaleDB andmebaasiga taustaprogrammina. Näitame teile, kuidas nullist alustada ja PostgreSQL-ist üle minna. Pakume ka kahe konfiguratsiooni võrdlevaid toimivusteste.
HighLoad++ Siber 2019. Tomski saal. 24. juuni kell 16. Teesid ja . Järgmine HighLoad++ konverents peetakse 6. ja 7. aprillil 2020 Peterburis. Üksikasjad ja piletid .
Andrei Guštšin (edaspidi – AG): – Olen ZABBIXi tehnilise toe insener (edaspidi "Zabbix"), koolitaja. Olen töötanud tehnilise toe alal üle 6 aasta ja omanud vahetut kogemust tulemuslikkusega. Täna räägin jõudlusest, mida TimescaleDB suudab pakkuda võrreldes tavalise PostgreSQL 10-ga. Samuti tutvustan mõnda sissejuhatavat osa selle toimimise kohta üldiselt.
Peamised tootlikkuse väljakutsed: andmete kogumisest andmete puhastamiseni
Alustuseks on teatud jõudlusprobleemid, millega iga seiresüsteem silmitsi seisab. Esimene tootlikkuse väljakutse on andmete kiire kogumine ja töötlemine.
Hea monitooringusüsteem peaks kõik andmed kiiresti ja õigeaegselt vastu võtma, neid trigeravaldiste järgi töötlema ehk töötlema mingi kriteeriumi järgi (eri süsteemides on see erinev) ja salvestama andmebaasi, et neid andmeid kasutada tulevik.
Teine jõudluse väljakutse on ajaloo salvestamine. Salvestage sageli andmebaasis ning omage kiiret ja mugavat juurdepääsu neile teatud aja jooksul kogutud mõõdikutele. Kõige tähtsam on see, et neid andmeid oleks mugav hankida, kasutada aruannetes, graafikutes, trigerites, mõnes läviväärtuses, hoiatustes jne.
Kolmas jõudluse väljakutse on ajaloo puhastamine, st kui jõuate punkti, kus pole vaja salvestada üksikasjalikke mõõdikuid, mida on kogutud 5 aasta (isegi kuu või kahe kuu) jooksul. Mõned võrgusõlmed või mõned hostid kustutati, mõõdikuid pole enam vaja, kuna need on juba aegunud ja neid enam ei koguta. Kõik see tuleb puhastada, et teie andmebaas liiga suureks ei kasvaks. Üldiselt on ajaloo kustutamine salvestusruumi jaoks enamasti tõsine proovikivi – sellel on sageli väga tugev mõju jõudlusele.
Kuidas lahendada vahemälu probleeme?
Räägin nüüd konkreetselt Zabbixist. Zabbixis lahendatakse esimene ja teine kõne vahemällu kasutades.
Andmete kogumine ja töötlemine – kõigi nende andmete salvestamiseks kasutame RAM-i. Neid andmeid käsitletakse nüüd üksikasjalikumalt.
Ka andmebaasi poolel on peamiste valikute jaoks - graafikute ja muude asjade jaoks - vahemälu.
Vahemällu salvestamine Zabbixi serveri enda küljel: meil on ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Mis see on?
ConfigurationCache on peamine vahemälu, kuhu me salvestame mõõdikuid, hoste, andmeüksusi, käivitajaid; kõik vajalik eeltöötluse töötlemiseks, andmete kogumiseks, millistelt hostidelt koguda, millise sagedusega. Kõik see salvestatakse ConfigurationCache'i, et mitte minna andmebaasi ja luua tarbetuid päringuid. Pärast serveri käivitumist värskendame seda vahemälu (loome selle) ja värskendame seda perioodiliselt (olenevalt konfiguratsiooniseadetest).
Vahemällu salvestamine Zabbixis. Andmete kogumine
Siin on diagramm üsna suur:
Peamised skeemis on järgmised kollektsionäärid:
Need on montaažiprotsessid ise, erinevad “pollerid”, mis vastutavad erinevat tüüpi koostude eest. Nad koguvad andmeid icmp, ipmi ja erinevate protokollide kaudu ning edastavad need kõik eeltöötlusele.
Eeltöötluse ajaloo vahemälu
Samuti, kui meil on arvutatud andmeelemendid (need, kes Zabbixiga tuttavad, teavad), st arvutatud, koondatud andmeelemendid, võtame need otse ValueCache'ist. Kuidas see täidetakse, räägin hiljem. Kõik need kogujad kasutavad ConfigurationCache'i oma tööde vastuvõtmiseks ja seejärel eeltöötlusele edastamiseks.
Eeltöötlus kasutab ka ConfigurationCache'i, et hankida eeltöötlusetapid ja töödelda neid andmeid mitmel viisil. Alates versioonist 4.2 oleme selle teisaldanud puhverserverile. See on väga mugav, sest eeltöötlus ise on üsna keeruline toiming. Ja kui teil on väga suur Zabbix, millel on palju andmeelemente ja kõrge kogumissagedus, lihtsustab see tööd oluliselt.
Seetõttu salvestame pärast seda, kui oleme neid andmeid mingil viisil eeltöötluse abil töötlenud, need HistoryCache'i, et neid edasi töödelda. Sellega on andmete kogumine lõpetatud. Liigume edasi põhiprotsessi juurde.
Ajaloo sünkronisaatori töö
Zabbixi põhiprotsess (kuna see on monoliitne arhitektuur) on ajaloo sünkroonimine. See on põhiprotsess, mis käsitleb konkreetselt iga andmeelemendi, st iga väärtuse aatomitöötlust:
- väärtus tuleb (see võtab selle HistoryCache'ist);
- kontrollib Konfiguratsiooni sünkronisaatoris: kas arvutamiseks on käivitajaid - arvutab need välja;
kui on - loob sündmused, loob eskalatsiooni, et tekitada hoiatus, vajadusel vastavalt konfiguratsioonile; - salvestab trigerid järgnevaks töötlemiseks, koondamiseks; kui koondate viimase tunni ja nii edasi, jätab ValueCache selle väärtuse meelde, et mitte minna ajalootabelisse; Seega on ValueCache täidetud vajalike andmetega, mis on vajalikud päästikute, arvutatud elementide jms arvutamiseks;
- siis History syncer kirjutab kõik andmed andmebaasi;
- andmebaas kirjutab need kettale – sellega töötlemisprotsess lõpeb.
Andmebaas. Vahemällu salvestamine
Andmebaasi poolel, kui soovite vaadata sündmuste graafikuid või mõnda aruannet, on erinevad vahemälud. Kuid selles raportis ma neist ei räägi.
MySQL-i jaoks on olemas Innodb_buffer_pool ja hulk erinevaid vahemälu, mida saab samuti konfigureerida.
Kuid need on peamised:
- jagatud_puhvrid;
- efektiivne_vahemälu_suurus;
- jagatud_bassein.
Kõikide andmebaaside puhul ütlesin, et on teatud vahemälud, mis võimaldavad salvestada RAM-i andmeid, mida sageli päringute jaoks vaja läheb. Neil on selleks oma tehnoloogiad.
Andmebaasi jõudluse kohta
Sellest lähtuvalt on olemas konkurentsikeskkond, st Zabbixi server kogub andmeid ja salvestab need. Taaskäivitamisel loeb see ka ajaloost, et täita ValueCache ja nii edasi. Siin saate kasutada skripte ja aruandeid, mis kasutavad veebiliidesele üles ehitatud Zabbixi API-d. Zabbix API siseneb andmebaasi ja saab vajalikud andmed, et saada graafikuid, aruandeid või mingisugust sündmuste loendit, hiljutisi probleeme.
Väga populaarne visualiseerimislahendus on ka Grafana, mida meie kasutajad kasutavad. Võimalus otse sisse logida nii Zabbixi API kui ka andmebaasi kaudu. See loob ka teatud konkurentsi andmete hankimisel: tulemuste kiireks edastamiseks ja testimiseks on vaja andmebaasi peenemat ja paremat häälestamist.
Ajaloo kustutamine. Zabbixil on majahoidja
Kolmas kõne, mida Zabbixis kasutatakse, on ajaloo tühjendamine Housekeeperi abil. Majahoidja järgib kõiki seadistusi, st meie andmeelemendid näitavad, kui kaua salvestada (päevades), kui kaua säilitada trende ja muudatuste dünaamikat.
TrendCache'ist ma ei rääkinud, mida me käigu pealt arvutame: andmed saabuvad, koondame need ühe tunni kohta (enamasti on need viimase tunni numbrid), summa on keskmine/minimaalne ja salvestame korra tunnis muutuste dünaamika tabel (“Trendid”) . “Majahoidja” käivitab ja kustutab andmed andmebaasist tavaliste valikute abil, mis ei ole alati efektiivne.
Kuidas aru saada, et see on ebaefektiivne? Sisemiste protsesside toimivusgraafikutel näete järgmist pilti:
Teie ajaloo sünkroonija on pidevalt hõivatud (punane graafik). Ja peal olev "punane" graafik. See on "majahoidja", mis käivitub ja ootab, kuni andmebaas kustutab kõik määratud read.
Võtame mõne üksuse ID: peate kustutama viimased 5 tuhat; muidugi indeksite järgi. Kuid tavaliselt on andmestik üsna suur - andmebaas loeb selle ikkagi kettalt ja paneb vahemällu ning see on andmebaasi jaoks väga kallis operatsioon. Olenevalt selle suurusest võib see põhjustada teatud jõudlusprobleeme.
Majapidaja saab keelata lihtsal viisil – meil on tuttav veebiliides. Seadistused jaotises Haldus üldine (Seaded "Majahoidja" jaoks) keelame sisemise majapidamise sisemise ajaloo ja trendide jaoks. Sellest tulenevalt ei kontrolli majapidaja enam seda:
Mida saate edasi teha? Lülitasite selle välja, teie graafikud on ühtlustunud... Millised probleemid võivad sel juhul veel tekkida? Mis saab aidata?
Partitsioneerimine (jaotamine)
Tavaliselt on see igas loetletud relatsiooniandmebaasis konfigureeritud erineval viisil. MySQL-il on oma tehnoloogia. Kuid üldiselt on need PostgreSQL 10 ja MySQL-i osas väga sarnased. Muidugi on palju sisemisi erinevusi selles, kuidas seda kõike rakendatakse ja kuidas see kõik toimivust mõjutab. Kuid üldiselt toob uue partitsiooni loomine sageli kaasa ka teatud probleeme.
Sõltuvalt teie seadistusest (kui palju andmeid ühe päeva jooksul loote) määravad nad tavaliselt miinimumi - see on 1 päev / partii ja "trendide" muudatuste dünaamika jaoks - 1 kuu / uus partii. See võib muutuda, kui teil on väga suur seadistus.
Ütleme kohe seadistuse suuruse kohta: kuni 5 tuhat uut väärtust sekundis (nn nvps) - seda peetakse väikeseks seadistuseks. Keskmine - 5 kuni 25 tuhat väärtust sekundis. Kõik ülaltoodud on juba suured ja väga suured installid, mis nõuavad andmebaasi väga hoolikat seadistamist.
Väga suurte paigalduste puhul ei pruugi 1 päev olla optimaalne. Olen isiklikult näinud MySQL-is partitsioone 40 gigabaiti päevas (ja neid võib olla rohkem). Tegemist on väga suure andmemahuga, mis võib kaasa tuua mõningaid probleeme. Seda tuleb vähendada.
Miks vajate partitsiooni?
Arvan, et kõik teavad, mida partitsioonid pakuvad, on tabelipartitsioonid. Sageli on need eraldi failid kettal ja span päringud. See valib ühe partitsiooni optimaalsemalt, kui see on osa tavalisest partitsioonist.
Eelkõige Zabbixi puhul kasutatakse seda vahemiku, vahemiku järgi, st me kasutame ajatemplit (tavaline arv, aeg epohhi algusest). Määrate päeva alguse/päeva lõpu ja see on partitsioon. Seega, kui küsite kahe päeva vanuseid andmeid, hangitakse andmebaasist kõik kiiremini, kuna peate laadima vahemällu ainult ühe faili ja tagastama selle (mitte suure tabeli).
Paljud andmebaasid kiirendavad ka sisestamist (ühte alamtabelisse sisestamist). Ma räägin praegu abstraktselt, kuid see on ka võimalik. Sageli aitab jagamine.
Elasticsearch NoSQL jaoks
Hiljuti juurutasime versioonis 3.4 NoSQL-i lahenduse. Lisatud võimalus kirjutada Elasticsearchis. Kirjutada saab teatud tüüpe: valid ise – kas kirjuta numbrid või mingid märgid; meil on stringtekst, saate Elasticsearchi logisid kirjutada... Vastavalt sellele pääseb veebiliides juurde ka Elasticsearchi. Mõnel juhul töötab see suurepäraselt, kuid hetkel saab seda kasutada.
TimescaleDB. Hüpertabelid
4.4.2 puhul pöörasime tähelepanu ühele asjale, nagu TimescaleDB. Mis see on? See on PostgreSQL-i laiendus, see tähendab, et sellel on natiivne PostgreSQL-i liides. Lisaks võimaldab see laiendus teil ajaridade andmetega palju tõhusamalt töötada ja kasutada automaatset partitsiooni. Milline see välja näeb:
See on hüpertabel – selline mõiste on ajaskaalas olemas. See on teie loodud hüpertabel ja see sisaldab tükke. Tükid on vaheseinad, need on alamlauad, kui ma ei eksi. See on tõesti tõhus.
TimescaleDB ja PostgreSQL
Nagu TimescaleDB tootjad kinnitavad, kasutavad nad päringute, eriti sisestuste töötlemiseks õigemat algoritmi, mis võimaldab neil andmestiku lisamise suuruse suurenemisel olla ligikaudu konstantne jõudlus. See tähendab, et pärast 200 miljonit Postgresi rida hakkab tavaline rida väga alla vajuma ja kaotab jõudluse sõna otseses mõttes nullini, samas kui ajaskaala võimaldab teil sisestada sisestusi võimalikult tõhusalt mis tahes andmehulgaga.
Kuidas installida TimescaleDB? See on lihtne!
See on dokumentatsioonis, see on kirjeldatud - saate selle installida mis tahes pakettidest... See sõltub ametlikest Postgresi pakettidest. Saab käsitsi koostada. Juhtus nii, et pidin andmebaasi jaoks koostama.
Zabbixis aktiveerime lihtsalt laienduse. Arvan, et need, kes Postgresis Extentioni kasutasid... Te lihtsalt aktiveerite Extention, loote selle kasutatava Zabbixi andmebaasi jaoks.
Ja viimane samm...
TimescaleDB. Ajalootabelite migratsioon
Peate looma hüpertabeli. Selleks on spetsiaalne funktsioon – Loo hüpertabel. Selles on esimene parameeter selles andmebaasis vajalik tabel (mille jaoks peate looma hüpertabeli).
Väli, mille järgi luua, ja chunk_time_interval (see on tükkide (kasutamist vajavate partitsioonide) intervall. 86 400 on üks päev.
Parameeter Migrate_data: kui sisestate väärtuse tõene, migreeritakse kõik praegused andmed eelnevalt loodud tükkidesse.
Olen ise migrate_datat kasutanud – see võtab üsna palju aega, olenevalt sellest, kui suur su andmebaas on. Mul oli üle terabaidi – loomiseks kulus üle tunni. Mõnel juhul kustutasin testimise ajal teksti (ajalugu_tekst) ja stringi (ajalugu_str) ajaloolised andmed, et mitte neid üle kanda – need polnud minu jaoks tegelikult huvitavad.
Ja me teeme oma db_extentioni viimase värskenduse: installime timescaledb, et andmebaas ja eriti meie Zabbix saaksid aru, et on olemas db_extention. Ta aktiveerib selle ja kasutab andmebaasi õiget süntaksit ja päringuid, kasutades neid "funktsioone", mis on TimescaleDB jaoks vajalikud.
Serveri konfiguratsioon
Kasutasin kahte serverit. Esimene server on üsna väike virtuaalne masin, 20 protsessorit, 16 gigabaiti muutmälu. Seadistasin sellele Postgres 10.8:
Operatsioonisüsteemiks oli Debian, failisüsteemiks xfs. Tegin selle konkreetse andmebaasi kasutamiseks minimaalsed sätted, miinus see, mida Zabbix ise kasutab. Samas masinas olid Zabbixi server, PostgreSQL ja laadimisagendid.
Olen kasutanud 50 aktiivset agenti, mis kasutavad LoadableModule'i erinevate tulemuste kiireks genereerimiseks. Nemad on need, kes genereerisid stringid, numbrid ja nii edasi. Täitsin andmebaasi suure hulga andmetega. Algselt sisaldas konfiguratsioon 5 tuhat andmeelementi hosti kohta ja ligikaudu iga andmeelement sisaldas päästikut - selleks, et see oleks tõeline seadistus. Mõnikord on teil isegi vaja kasutada rohkem kui ühte päästikut.
Reguleerisin värskendusintervalli ja laadimist ennast mitte ainult 50 agendi kasutamisega (lisades rohkem), vaid ka dünaamiliste andmeelementide kasutamisega ja vähendasin uuendusintervalli 4 sekundini.
Jõudluskatse. PostgreSQL: 36 tuhat NVP-d
Esimene käivitamine, esimene seadistus, mis mul oli, toimus sellel riistvaral puhtal PostreSQL 10-l (35 tuhat väärtust sekundis). Üldiselt, nagu ekraanilt näha, võtab andmete sisestamine sekundi murdosa – kõik on hea ja kiire, SSD-draivid (200 gigabaiti). Ainuke asi on see, et 20 GB saab üsna kiiresti täis.
Selliseid graafikuid tuleb tulevikus päris palju. See on standardne Zabbixi serveri jõudluse armatuurlaud.
Esimene graafik on väärtuste arv sekundis (sinine, üleval vasakul), antud juhul 35 tuhat väärtust. See (üleval keskel) on ehitusprotsesside laadimine ja see (paremal ülanurgas) sisemiste protsesside laadimine: ajaloo sünkronisaatorid ja majahoidja, mis siin (all keskel) on juba mõnda aega töötanud.
See graafik (all keskel) näitab ValueCache'i kasutust – kui palju ValueCache'i tabamust on käivitajatele (mitu tuhat väärtust sekundis). Teine oluline graafik on neljas (vasakul all), mis näitab, kuidas kasutatakse HistoryCache'i, millest ma rääkisin, mis on puhver enne andmebaasi sisestamist.
Jõudluskatse. PostgreSQL: 50 tuhat NVP-d
Järgmisena suurendasin sama riistvara koormust 50 tuhande väärtuseni sekundis. Majahoidja laadimisel registreeriti 10 tuhat väärtust 2-3 sekundi jooksul koos arvutustega. Mida on tegelikult näidatud järgmisel ekraanipildil:
“Majahoidja” hakkab juba tööd segama, kuid üldiselt on ajaloo uppujate püüdjate koormus endiselt 60% tasemel (kolmas graafik, üleval paremal). HistoryCache hakkab juba aktiivselt täitma, kui Housekeeper töötab (all vasakul). See oli umbes pool gigabaiti, 20% täis.
Jõudluskatse. PostgreSQL: 80 tuhat NVP-d
Seejärel suurendasin seda 80 tuhande väärtuseni sekundis:
See oli ligikaudu 400 tuhat andmeelementi, 280 tuhat käivitajat. Vahetükk, nagu näha, oli ajaloo uppujate (neid oli 30) koormuse poolest juba päris kõrge. Seejärel suurendasin erinevaid parameetreid: ajaloo uppujad, vahemälu ... Sellel riistvaral hakkas ajaloo uppujate koormus tõusma maksimumini, peaaegu "riiulil" - vastavalt läks HistoryCache väga suurele koormusele:
Kogu selle aja jälgisin kõiki süsteemi parameetreid (kuidas protsessorit kasutatakse, RAM-i) ja avastasin, et ketta kasutus on maksimaalne – saavutasin selle ketta maksimaalse mahutavuse sellel riistvaral, selles virtuaalmasinas. "Postgres" hakkas sellise intensiivsusega andmeid üsna aktiivselt tühjendama ja kettal ei olnud enam aega kirjutada, lugeda...
Võtsin teise serveri, millel oli juba 48 protsessorit ja 128 gigabaiti muutmälu:
Samuti "tuunisin" seda - installisin History syncer (60 tükki) ja saavutasin vastuvõetava jõudluse. Tegelikult me ei ole “riiulil”, aga see on ilmselt tootlikkuse piir, kus on juba vaja midagi ette võtta.
Jõudluskatse. TimescaleDB: 80 tuhat NVP-d
Minu põhiülesanne oli TimescaleDB kasutamine. Iga graafik näitab langust:
Need tõrked on täpselt andmete migratsioon. Pärast seda muutus Zabbixi serveris ajaloo uppujate laadimisprofiil, nagu näete, palju. See võimaldab teil sisestada andmeid peaaegu 3 korda kiiremini ja kasutada vähem HistoryCache'i - vastavalt sellele edastatakse teile andmed õigeaegselt. Jällegi on 80 tuhat väärtust sekundis üsna kõrge (muidugi mitte Yandexi puhul). Üldiselt on see ühe serveriga üsna suur seadistus.
PostgreSQL-i jõudlustest: 120 tuhat NVP-d
Järgmisena suurendasin andmeelementide arvu poole miljonini ja sain arvutatud väärtuseks 125 tuhat sekundis:
Ja ma sain sellised graafikud:
Põhimõtteliselt on see töötav seadistus, see võib töötada üsna pikka aega. Aga kuna mul oli ainult 1,5 terabaidine ketas, siis kasutasin selle paari päevaga ära. Kõige olulisem on see, et samal ajal loodi TimescaleDB-s uued partitsioonid ja see jäi jõudlusele täiesti märkamatuks, mida MySQL-i kohta öelda ei saa.
Tavaliselt luuakse partitsioonid öösel, kuna see blokeerib üldiselt sisestamise ja töö tabelitega ning võib põhjustada teenuse halvenemist. Sel juhul see nii ei ole! Peamine ülesanne oli TimescaleDB võimaluste testimine. Tulemuseks oli järgmine arv: 120 tuhat väärtust sekundis.
Kogukonnas on ka näiteid:
Inimene lülitas sisse ka TimescaleDB ja io.weight kasutamise koormus protsessorile langes; ja ka sisemiste protsessielementide kasutamine on tänu TimescaleDB kaasamisele vähenenud. Pealegi on need tavalised pannkoogikettad, st tavaline virtuaalne masin tavalistel ketastel (mitte SSD-del)!
Mõne väikese seadistuse jaoks, mida ketta jõudlus piirab, on TimescaleDB minu arvates väga hea lahendus. See võimaldab teil jätkata tööd enne andmebaasi kiiremale riistvarale üleminekut.
Kutsun teid kõiki meie üritustele: konverents Moskvas, tippkohtumine Riias. Kasutage meie kanaleid - Telegram, foorum, IRC. Küsimuste korral tulge meie laua juurde, saame kõigest rääkida.
Publiku küsimused
Küsimus publikult (edaspidi - A): - Kui TimescaleDB-d on nii lihtne konfigureerida ja see annab sellise jõudluse tõuke, siis võib-olla tuleks seda kasutada parima tavana Zabbixi konfigureerimiseks Postgresiga? Ja kas sellel lahendusel on mingeid lõkse ja miinuseid või lõppude lõpuks, kui ma otsustasin endale Zabbixi teha, saan hõlpsalt võtta Postgresi, installida sinna kohe Timescale, kasutada seda ja mitte mõelda probleemidele?
AG: – Jah, ma ütleksin, et see on hea soovitus: kasutage Postgresi kohe koos TimescaleDB laiendiga. Nagu ma juba ütlesin, on palju häid arvustusi, hoolimata asjaolust, et see "funktsioon" on eksperimentaalne. Kuid tegelikult näitavad testid, et see on suurepärane lahendus (koos TimescaleDB-ga) ja ma arvan, et see areneb! Jälgime selle laienduse arengut ja teeme vajadusel muudatusi.
Isegi arenduse ajal toetusime ühele nende tuntud "omadusele": tükkidega oli võimalik töötada veidi teistmoodi. Kuid siis nad lõikasid selle järgmises väljaandes välja ja me pidime sellele koodile tuginemise lõpetama. Soovitan seda lahendust kasutada paljudes seadistustes. Kui kasutate MySQL-i... Keskmiste seadistuste korral töötab iga lahendus hästi.
A: – Kommuuni viimastel graafikutel oli graafik “Majahoidja”:
Ta jätkas tööd. Mida teeb majapidaja TimescaleDB-ga?
AG: – Nüüd ei saa ma kindlalt öelda – ma vaatan koodi ja räägin sulle täpsemalt. See ei kasuta TimescaleDB päringuid mitte tükkide kustutamiseks, vaid nende kuidagi koondamiseks. Ma ei ole veel valmis sellele tehnilisele küsimusele vastama. Täpsemalt saame teada täna või homme stendis.
A: – Mul on sarnane küsimus – ajaskaala kustutamistoimingu toimivuse kohta.
A (vastus publikult): – Kui kustutate tabelist andmeid, kui teete seda kustutamise kaudu, siis peate tabeli läbi käima - kustutage, puhastage, märkige kõik tulevaseks vaakumiks. Ajaskaalas, kuna teil on tükke, võite loobuda. Jämedalt öeldes ütlete lihtsalt suurandmetes olevale failile: "Kustuta!"
Ajaskaala lihtsalt mõistab, et sellist tükki enam ei eksisteeri. Ja kuna see on integreeritud päringuplaneerijasse, kasutab see konkse teie tingimuste tuvastamiseks valitud või muudes toimingutes ja saab kohe aru, et seda tükki enam pole – "Ma ei lähe sinna enam!" (andmed puuduvad). See on kõik! See tähendab, et tabeli skannimine asendatakse binaarfaili kustutamisega, nii et see on kiire.
A: – Mitte-SQL-i teemat oleme juba puudutanud. Niipalju kui ma aru saan, ei pea Zabbix tegelikult andmeid muutma ja see kõik on midagi logi sarnast. Kas on võimalik kasutada spetsiaalseid andmebaase, mis ei suuda oma andmeid muuta, aga samas salvestavad, koguvad ja levitavad palju kiiremini - Clickhouse näiteks midagi kafkalikku?.. Kafka on ka logi! Kas neid on võimalik kuidagi integreerida?
AG: - Mahalaadimist saab teha. Meil on alates versioonist 3.4 teatud "funktsioon": saate failidesse kirjutada kõik ajaloolised failid, sündmused ja kõik muu; ja seejärel saatke see mõne töötleja abil mis tahes muusse andmebaasi. Tegelikult töötavad paljud inimesed ümber ja kirjutavad otse andmebaasi. Käigupealt kirjutavad ajaloo uputajad selle kõik failidesse, pööravad neid faile ja nii edasi ning saate selle Clickhouse'i üle kanda. Plaanide kohta ei oska öelda, aga võib-olla jätkub ka NoSQL-i lahenduste (nt Clickhouse) edasine tugi.
A: – Üldiselt selgub, et saate postgresist täielikult lahti saada?
AG: - Muidugi on Zabbixi kõige keerulisem osa ajaloolised tabelid, mis tekitavad kõige rohkem probleeme ja sündmusi. Sellisel juhul, kui te ei salvesta sündmusi pikka aega ja salvestate ajalugu koos trendidega mõnes teises kiires salvestusruumis, siis üldiselt arvan, et probleeme ei teki.
A: – Kas oskate hinnata, kui palju kiiremini kõik toimima hakkab, kui lähete näiteks Clickhouse’ile üle?
AG: - Ma pole seda testinud. Ma arvan, et vähemalt samad numbrid on saavutatavad üsna lihtsalt, arvestades, et Clickhouse'il on oma liides, kuid ma ei saa seda kindlalt öelda. Parem on katsetada. Kõik sõltub konfiguratsioonist: mitu hosti teil on ja nii edasi. Sisestamine on üks asi, aga need andmed tuleb ka hankida – Grafana või midagi muud.
A: – Nii et me räägime võrdsest võitlusest, mitte nende kiirete andmebaaside suurest eelisest?
AG: – Arvan, et kui me integreerime, on täpsemad testid.
A: – Kuhu kadus vana hea RRD? Mis sundis teid SQL-andmebaasidele üle minema? Algselt koguti kõik mõõdikud RRD-le.
AG: - Zabbixil oli RRD, võib-olla väga iidses versioonis. SQL-andmebaase on alati olnud – klassikaline lähenemine. Klassikaline lähenemine on MySQL, PostgreSQL (need on eksisteerinud väga pikka aega). Me ei kasutanud peaaegu kunagi SQL-i ja RRD-andmebaaside jaoks ühist liidest.
Mõned reklaamid 🙂
Täname, et jäite meiega. Kas teile meeldivad meie artiklid? Kas soovite näha huvitavamat sisu? Toeta meid, esitades tellimuse või soovitades sõpradele, , algtaseme serverite ainulaadne analoog, mille me teie jaoks leiutasime: (saadaval RAID1 ja RAID10, kuni 24 tuuma ja kuni 40 GB DDR4-ga).
Dell R730xd 2x odavam Amsterdami Equinixi Tier IV andmekeskuses? Ainult siin Hollandis! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – alates 99 dollarist! Millegi kohta lugema
Allikas: www.habr.com