Pažiūrėsime, kaip Zabbix veikia su TimescaleDB duomenų baze kaip užpakaline programa. Parodysime, kaip pradėti nuo nulio ir kaip pereiti iš PostgreSQL. Taip pat pateiksime lyginamuosius dviejų konfigūracijų veikimo testus.
HighLoad++ Sibiras 2019. Tomsko salė. Birželio 24 d., 16:00 val. Tezės ir . Kita HighLoad++ konferencija vyks 6 metų balandžio 7 ir 2020 dienomis Sankt Peterburge. Išsami informacija ir bilietai .
Andrejus Guščinas (toliau – AG): – Esu ZABBIX techninės pagalbos inžinierius (toliau – „Zabbix“), treneris. Techninio aptarnavimo srityje dirbu daugiau nei 6 metus ir turiu tiesioginės veiklos patirties. Šiandien kalbėsiu apie našumą, kurį TimescaleDB gali užtikrinti, palyginti su įprastu PostgreSQL 10. Taip pat įvadinė dalis apie tai, kaip ji veikia apskritai.
Didžiausi našumo iššūkiai: nuo duomenų rinkimo iki duomenų valymo
Visų pirma, yra tam tikrų veiklos iššūkių, su kuriais susiduria kiekviena stebėjimo sistema. Pirmasis našumo iššūkis yra greitas duomenų rinkimas ir apdorojimas.
Gera stebėjimo sistema turi greitai, laiku gauti visus duomenis, apdoroti juos pagal trigerines išraiškas, tai yra apdoroti pagal tam tikrus kriterijus (skirtingose sistemose tai skiriasi) ir išsaugoti duomenų bazėje, kad šie duomenys būtų naudojami ateitis.
Antrasis našumo iššūkis yra istorijos saugojimas. Dažnai saugokite duomenų bazėje ir greitai bei patogiai pasiekite šią metriką, kuri buvo surinkta per tam tikrą laikotarpį. Svarbiausia, kad šiuos duomenis būtų patogu gauti, naudoti ataskaitose, diagramose, trigeriuose, kai kuriose slenkstinėse reikšmėse, įspėjimams ir pan.
Trečiasis našumo iššūkis yra istorijos išvalymas, ty kai pasiekiate tašką, kai jums nereikia saugoti jokios išsamios metrikos, surinktos per 5 metus (net mėnesius ar du mėnesius). Kai kurie tinklo mazgai buvo ištrinti arba kai kurie pagrindiniai kompiuteriai, metrikos nebereikalingos, nes jos jau pasenusios ir neberenkamos. Visa tai reikia išvalyti, kad jūsų duomenų bazė neišaugtų per didelė. Apskritai istorijos išvalymas dažniausiai yra rimtas saugyklos išbandymas – tai dažnai labai stipriai veikia našumą.
Kaip išspręsti talpyklos problemas?
Dabar kalbėsiu konkrečiai apie Zabbix. „Zabbix“ pirmasis ir antrasis skambučiai išsprendžiami naudojant talpyklą.
Duomenų rinkimas ir apdorojimas – Visiems šiems duomenims saugoti naudojame RAM. Dabar šie duomenys bus aptarti išsamiau.
Taip pat duomenų bazės pusėje yra keletas pagrindinių pasirinkimų - grafikų ir kitų dalykų - talpyklos.
Talpyklos kaupimas paties Zabbix serverio pusėje: turime ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Kas tai yra?
ConfigurationCache yra pagrindinė talpykla, kurioje saugome metriką, pagrindinius kompiuterius, duomenų elementus, trigerius; viskas, ko reikia išankstiniam apdorojimui, duomenų rinkimui, iš kurių kompiuterių rinkti, kokiu dažnumu. Visa tai saugoma „ConfigurationCache“, kad nepatektų į duomenų bazę ir nekurtumėte nereikalingų užklausų. Paleidus serverį šią talpyklą atnaujiname (sukuriame) ir periodiškai atnaujiname (priklausomai nuo konfigūracijos nustatymų).
Talpykla „Zabbix“. Duomenų rinkimas
Čia diagrama yra gana didelė:
Pagrindiniai schemoje yra šie kolektoriai:
Tai yra patys surinkimo procesai, įvairūs „polleriai“, atsakingi už įvairių tipų surinkimus. Jie renka duomenis naudodami icmp, ipmi ir įvairius protokolus ir visa tai perduoda išankstiniam apdorojimui.
Išankstinio apdorojimo istorijos talpykla
Be to, jei turime apskaičiuotų duomenų elementų (žino tie, kurie yra susipažinę su Zabbix), tai yra, skaičiuojamųjų, sumavimo duomenų elementus, paimame juos tiesiai iš „ValueCache“. Kaip jis užpildomas, pasakysiu vėliau. Visi šie rinkėjai naudoja ConfigurationCache, kad gautų savo užduotis ir perduotų juos išankstiniam apdorojimui.
Išankstinis apdorojimas taip pat naudoja ConfigurationCache, kad gautų išankstinio apdorojimo veiksmus ir apdorotų šiuos duomenis įvairiais būdais. Nuo 4.2 versijos mes perkėlėme ją į tarpinį serverį. Tai labai patogu, nes pats išankstinis apdorojimas yra gana sudėtinga operacija. Ir jei turite labai didelį „Zabbix“ su daugybe duomenų elementų ir dideliu rinkimo dažnumu, tai labai supaprastina darbą.
Atitinkamai, kai kokiu nors būdu apdorojome šiuos duomenis naudodami išankstinį apdorojimą, išsaugome juos HistoryCache, kad galėtume toliau apdoroti. Tuo duomenų rinkimas baigtas. Mes pereiname prie pagrindinio proceso.
Istorijos sinchronizatoriaus darbas
Pagrindinis Zabbix procesas (kadangi tai yra monolitinė architektūra) yra istorijos sinchronizavimas. Tai yra pagrindinis procesas, konkrečiai susijęs su kiekvieno duomenų elemento, ty kiekvienos vertės, atominiu apdorojimu:
- ateina reikšmė (ji paima iš HistoryCache);
- patikrina Konfigūracijos sinchronizatoriuje: ar yra skaičiavimo trigerių - juos apskaičiuoja;
jei yra - sukuria įvykius, sukuria eskalavimą, kad būtų sukurtas įspėjimas, jei reikia pagal konfigūraciją; - registruoja trigerius vėlesniam apdorojimui, agregavimui; jei apibendrinate per paskutinę valandą ir pan., šią reikšmę „ValueCache“ įsimena, kad nepatektų į istorijos lentelę; Taigi, „ValueCache“ užpildoma reikiamais duomenimis, kurie yra būtini trigeriams, skaičiuojamiesiems elementams ir pan. apskaičiuoti;
- tada History syncer įrašo visus duomenis į duomenų bazę;
- duomenų bazė juos įrašo į diską – čia apdorojimo procesas baigiasi.
Duomenų bazė. Talpykla
Duomenų bazės pusėje, kai norite peržiūrėti grafikus ar kai kurias įvykių ataskaitas, yra įvairios talpyklos. Tačiau šiame pranešime apie juos nekalbėsiu.
MySQL yra Innodb_buffer_pool ir daugybė skirtingų talpyklų, kurias taip pat galima konfigūruoti.
Bet tai yra pagrindiniai:
- Shared_buffers;
- efektyvus_talpyklos_dydis;
- Shared_pool.
Visoms duomenų bazėms sakiau, kad yra tam tikros talpyklos, kurios leidžia saugoti RAM duomenis, kurie dažnai reikalingi užklausoms. Tam jie turi savo technologijas.
Apie duomenų bazės našumą
Atitinkamai yra konkurencinė aplinka, tai yra, „Zabbix“ serveris renka duomenis ir juos įrašo. Paleidus iš naujo, jis taip pat nuskaito istoriją, kad užpildytų „ValueCache“ ir pan. Čia galite turėti scenarijus ir ataskaitas, naudojančias „Zabbix“ API, sukurtą žiniatinklio sąsajoje. Zabbix API patenka į duomenų bazę ir gauna reikiamus duomenis, kad gautų grafikus, ataskaitas ar kokį nors įvykių sąrašą, naujausias problemas.
Taip pat labai populiarus vizualizacijos sprendimas yra Grafana, kuria naudojasi mūsų vartotojai. Galimybė prisijungti tiesiogiai tiek per Zabbix API, tiek per duomenų bazę. Tai taip pat sukuria tam tikrą konkurenciją dėl duomenų gavimo: norint užtikrinti greitą rezultatų pateikimą ir testavimą, reikia tiksliau ir geriau suderinti duomenų bazę.
Istorijos išvalymas. Zabbix turi namų tvarkytoją
Trečiasis skambutis, naudojamas „Zabbix“, yra istorijos išvalymas naudojant „Housekeeper“. Namų tvarkytojas seka visus nustatymus, tai yra, mūsų duomenų elementai nurodo, kiek laiko saugoti (dienomis), kiek laiko saugoti tendencijas ir pokyčių dinamiką.
Nekalbėjau apie „TrendCache“, kurią skaičiuojame skrydžio metu: gaunami duomenys, sumuojame vieną valandą (dažniausiai tai yra paskutinės valandos skaičiai), suma yra vidutinė/minimali ir įrašome kartą per valandą į pokyčių dinamikos lentelė („Trends“) . „Namų tvarkytoja“ paleidžia ir ištrina duomenis iš duomenų bazės naudodama įprastus pasirinkimus, o tai ne visada efektyvu.
Kaip suprasti, kad tai neveiksminga? Vidinių procesų našumo diagramose galite pamatyti šį paveikslėlį:
Jūsų istorijos sinchronizatorius nuolat užimtas (raudona diagrama). Ir viršuje esanti „raudona“ grafika. Tai yra „namų tvarkytoja“, kuri paleidžiama ir laukia, kol duomenų bazė ištrins visas nurodytas eilutes.
Paimkime kokį nors Prekės ID: reikia ištrinti paskutinius 5 tūkst. žinoma, pagal indeksus. Tačiau dažniausiai duomenų rinkinys yra gana didelis – duomenų bazė vis tiek nuskaito jį iš disko ir įdeda į talpyklą, o tai labai brangi operacija duomenų bazei. Atsižvelgiant į jo dydį, tai gali sukelti tam tikrų veikimo problemų.
Galite išjungti „Housekeeper“ paprastu būdu – turime pažįstamą žiniatinklio sąsają. Bendrieji administravimo nustatymai (nustatymai „Namų tvarkytoja“) išjungiame vidinį namų ruošą, kad pamatytumėte vidinę istoriją ir tendencijas. Atitinkamai namų tvarkytoja nebekontroliuoja:
Ką daryti toliau? Jūs jį išjungėte, jūsų grafikai išsilygino... Kokios dar gali kilti problemų šiuo atveju? Kas gali padėti?
Perskirstymas (skirstymas)
Paprastai kiekvienoje mano išvardytoje reliacinėje duomenų bazėje tai sukonfigūruojama skirtingai. MySQL turi savo technologiją. Tačiau apskritai jie yra labai panašūs, kai kalbama apie „PostgreSQL 10“ ir „MySQL“. Žinoma, yra daug vidinių skirtumų, kaip visa tai įgyvendinama ir kaip visa tai veikia našumą. Tačiau apskritai naujo skaidinio sukūrimas dažnai taip pat sukelia tam tikrų problemų.
Priklausomai nuo jūsų sąrankos (kiek duomenų sukuriate per vieną dieną), jie paprastai nustato minimumą - tai yra 1 diena / paketas, o „tendencijų“ pokyčių dinamika - 1 mėnuo / nauja siunta. Tai gali pasikeisti, jei turite labai didelę sąranką.
Iš karto pasakykime apie sąrankos dydį: iki 5 tūkstančių naujų reikšmių per sekundę (vadinamieji nvps) - tai bus laikoma maža „sąranka“. Vidutinis – nuo 5 iki 25 tūkstančių reikšmių per sekundę. Viskas, kas aprašyta aukščiau, jau yra dideli ir labai dideli įrenginiai, kuriems reikia labai kruopštaus duomenų bazės konfigūravimo.
Labai dideliuose įrenginiuose 1 diena gali būti netinkama. Aš asmeniškai mačiau 40 gigabaitų per dieną skirsnius MySQL (ir gali būti daugiau). Tai labai didelis duomenų kiekis, todėl gali kilti tam tikrų problemų. Jį reikia sumažinti.
Kodėl jums reikia skaidymo?
Tai, ką suteikia skaidymas, manau, visi žino, yra lentelės skaidymas. Dažnai tai yra atskiri failai diske ir užklausos. Jis parenka vieną skaidinį optimaliau, jei jis yra įprasto skaidymo dalis.
Visų pirma „Zabbix“ jis naudojamas pagal diapazoną, pagal diapazoną, tai yra, mes naudojame laiko žymą (įprastas skaičius, laikas nuo epochos pradžios). Nurodote dienos pradžią / dienos pabaigą, ir tai yra skaidinys. Atitinkamai, jei prašote dviejų dienų senumo duomenų, viskas iš duomenų bazės išimama greičiau, nes tereikia vieną failą įkelti į talpyklą ir grąžinti (o ne didelę lentelę).
Daugelis duomenų bazių taip pat pagreitina įterpimą (įterpimą į vieną antrinę lentelę). Kol kas kalbu abstrakčiai, bet tai taip pat įmanoma. Atskyrimas dažnai padeda.
Elasticsearch, skirta NoSQL
Neseniai, 3.4 versijoje, įdiegėme NoSQL sprendimą. Pridėta galimybė rašyti Elasticsearch. Galite rašyti tam tikrus tipus: pasirenkate – arba rašyti skaičius, arba kokius nors ženklus; mes turime eilutės tekstą, galite rašyti žurnalus į Elasticsearch... Atitinkamai žiniatinklio sąsaja taip pat pasieks Elasticsearch. Kai kuriais atvejais tai puikiai veikia, tačiau šiuo metu jį galima naudoti.
Laiko skalėDB. Hipertabletės
4.4.2 atveju atkreipėme dėmesį į vieną dalyką, pvz., TimescaleDB. Kas tai yra? Tai yra PostgreSQL plėtinys, tai yra, jis turi savąją PostgreSQL sąsają. Be to, šis plėtinys leidžia daug efektyviau dirbti su laiko sekų duomenimis ir turėti automatinį skaidymą. Kaip tai atrodo:
Tai hipertable – tokia sąvoka yra „Timescale“. Tai jūsų sukurta hiperlentelė, kurioje yra gabalėlių. Gabalai yra pertvaros, tai yra vaikų lentelės, jei neklystu. Tai tikrai veiksminga.
TimescaleDB ir PostgreSQL
Kaip tikina TimescaleDB gamintojai, jie naudoja teisingesnį užklausų, ypač intarpų, apdorojimo algoritmą, kuris leidžia užtikrinti maždaug pastovų našumą didėjant duomenų rinkinio įterpimo dydžiui. Tai reiškia, kad po 200 milijonų „Postgres“ eilučių įprasta eilučių pradeda labai smukti ir praranda našumą tiesiogine prasme iki nulio, o „Timescale“ leidžia kuo efektyviau įterpti įterpimus naudojant bet kokį duomenų kiekį.
Kaip įdiegti TimescaleDB? Tai paprasta!
Tai yra dokumentacijoje, ji aprašyta - galite ją įdiegti iš bet kokių paketų... Tai priklauso nuo oficialių Postgres paketų. Galima kompiliuoti rankiniu būdu. Taip atsitiko, kad turėjau kompiliuoti duomenų bazei.
„Zabbix“ tiesiog suaktyviname plėtinį. Manau, kad tie, kurie naudojo plėtinį „Postgres“... Jūs tiesiog suaktyvinate plėtinį, sukuriate jį jūsų naudojamai „Zabbix“ duomenų bazei.
Ir paskutinis žingsnis...
Laiko skalėDB. Istorijos lentelių migracija
Reikia sukurti hiperlentelę. Tam yra speciali funkcija – Sukurti hipertable. Jame pirmasis parametras yra lentelė, kuri reikalinga šioje duomenų bazėje (kuriai reikia sukurti hiperlentelę).
Laukas, pagal kurį reikia kurti, ir chunk_time_interval (tai yra gabalų (skyrių, kurias reikia naudoti) intervalas. 86 400 yra viena diena.
Parametras „Migrate_data“: jei įterpsite į „true“, visi dabartiniai duomenys bus perkelti į iš anksto sukurtas dalis.
Pats naudojau migrate_data – tai užtrunka nemažai laiko, priklausomai nuo jūsų duomenų bazės dydžio. Turėjau daugiau nei terabaitą – sukurti prireikė daugiau nei valandos. Kai kuriais atvejais testavimo metu ištryniau istorinius teksto duomenis (history_text) ir eilutę (history_str), kad jų neperkelčiau – jie man nelabai buvo įdomūs.
Ir mes atliekame paskutinį savo db_extention atnaujinimą: įdiegiame timescaledb, kad duomenų bazė ir ypač mūsų Zabbix suprastų, kad yra db_extention. Jis jį suaktyvina ir naudoja teisingą sintaksę bei duomenų bazės užklausas, naudodamas tas „funkcijas“, kurios yra būtinos TimescaleDB.
Serverio konfigūracija
Naudojau du serverius. Pirmasis serveris yra gana maža virtuali mašina, 20 procesorių, 16 gigabaitų RAM. Jame sukonfigūravau Postgres 10.8:
Operacinė sistema buvo Debian, failų sistema – xfs. Aš padariau minimalius nustatymus, kad naudočiau šią konkrečią duomenų bazę, atėmus tuos, kuriuos naudos pats „Zabbix“. Toje pačioje mašinoje buvo Zabbix serveris, PostgreSQL ir įkėlimo agentai.
Naudojau 50 aktyvių agentų, kurie naudoja LoadableModule, kad greitai gautų skirtingus rezultatus. Jie yra tie, kurie sugeneravo eilutes, skaičius ir pan. Aš užpildžiau duomenų bazę daugybe duomenų. Iš pradžių konfigūracijoje buvo 5 tūkstančiai duomenų elementų viename pagrindiniame kompiuteryje, o maždaug kiekviename duomenų elemente buvo trigeris – kad tai būtų tikra sąranka. Kartais net reikia naudoti daugiau nei vieną paleidiklį.
Atnaujinimo intervalą ir patį įkėlimą reguliavau ne tik naudodamas 50 agentų (pridėdamas daugiau), bet ir naudodamas dinaminius duomenų elementus bei sumažindamas atnaujinimo intervalą iki 4 sekundžių.
Veikimo testas. PostgreSQL: 36 tūkst. NVP
Pirmasis paleidimas, pirmoji sąranka, kurią turėjau, buvo gryna PostreSQL 10 šioje aparatinėje įrangoje (35 tūkst. reikšmių per sekundę). Apskritai, kaip matote ekrane, duomenų įdėjimas užtrunka sekundės dalis – viskas gerai ir greitai, SSD diskai (200 gigabaitų). Vienintelis dalykas, kad 20 GB prisipildo gana greitai.
Ateityje tokių grafikų bus gana daug. Tai standartinė „Zabbix“ serverio našumo prietaisų skydelis.
Pirmas grafikas rodo reikšmių skaičių per sekundę (mėlyna, viršuje kairėje), šiuo atveju 35 tūkst. Tai (viršuje centre) yra kūrimo procesų įkėlimas, o šis (viršuje dešinėje) yra vidinių procesų įkėlimas: istorijos sinchronizatoriai ir namų tvarkytoja, kuri čia (apačioje centre) veikia gana ilgą laiką.
Šioje diagramoje (apačioje centre) rodomas „ValueCache“ naudojimas – kiek „ValueCache“ įvykių suaktyvina (keli tūkstančiai reikšmių per sekundę). Kitas svarbus grafikas yra ketvirtasis (apačioje kairėje), kuriame rodomas HistoryCache, apie kurį kalbėjau, naudojimas, kuris yra buferis prieš įterpiant į duomenų bazę.
Veikimo testas. PostgreSQL: 50 tūkst. NVP
Tada padidinau apkrovą iki 50 tūkstančių verčių per sekundę toje pačioje aparatinėje įrangoje. Kai įkėlė „Housekeeper“, skaičiuojant per 10–2 sekundes buvo užfiksuota 3 tūkst. Kas iš tikrųjų parodyta šioje ekrano kopijoje:
„Namų tvarkytojas“ jau pradeda trukdyti darbui, tačiau apskritai istoriją griaunančių gaudyklių apkrova vis dar siekia 60% (trečias grafikas, viršuje dešinėje). Istorijos talpykla jau pradeda aktyviai pildytis, kol veikia namų šeimininkė (apačioje kairėje). Tai buvo maždaug pusė gigabaito, 20% užpildyta.
Veikimo testas. PostgreSQL: 80 tūkst. NVP
Tada padidinau iki 80 tūkstančių reikšmių per sekundę:
Tai buvo maždaug 400 tūkstančių duomenų elementų, 280 tūkstančių trigerių. Įdėklas, kaip matote, pagal istorijos grimzlių krūvį (jų buvo 30) jau buvo gana didelis. Tada padidinau įvairius parametrus: istorijos kaupiklius, talpyklą... Šioje aparatinėje įrangoje istorijos griovelių apkrova pradėjo didėti iki maksimumo, beveik „lentynoje“ - atitinkamai HistoryCache buvo labai apkrauta:
Visą tą laiką stebėjau visus sistemos parametrus (kaip naudojamas procesorius, RAM) ir atradau, kad disko panaudojimas yra maksimalus – pasiekiau maksimalią šio disko talpą šioje aparatinėje įrangoje, šioje virtualioje mašinoje. „Postgres“ tokiu intensyvumu gana aktyviai pradėjo kaupti duomenis, o diskas nebeturėjo laiko rašyti, skaityti...
Paėmiau kitą serverį, kuriame jau buvo 48 procesoriai ir 128 gigabaitai RAM:
Aš taip pat jį „sureguliavau“ - įdiegiau istorijos sinchronizatorių (60 vienetų) ir pasiekiau priimtiną našumą. Tiesą sakant, mes nesame „ant lentynos“, bet tai tikriausiai yra produktyvumo riba, kur jau reikia ką nors padaryti.
Veikimo testas. TimescaleDB: 80 tūkstančių NVP
Mano pagrindinė užduotis buvo naudoti TimescaleDB. Kiekviena diagrama rodo kritimą:
Šios gedimai yra būtent duomenų perkėlimas. Po to Zabbix serveryje, kaip matote, istorijos grimzlių įkėlimo profilis labai pasikeitė. Tai leidžia įterpti duomenis beveik 3 kartus greičiau ir naudoti mažiau HistoryCache – atitinkamai duomenys bus pristatyti laiku. Vėlgi, 80 tūkstančių verčių per sekundę yra gana didelis rodiklis (žinoma, ne „Yandex“). Apskritai tai yra gana didelė sąranka su vienu serveriu.
PostgreSQL našumo testas: 120 tūkstančių NVP
Tada padidinau duomenų elementų skaičių iki pusės milijono ir gavau apskaičiuotą 125 tūkst. per sekundę vertę:
Ir aš gavau tokius grafikus:
Iš esmės tai yra veikianti sąranka, ji gali veikti gana ilgą laiką. Bet kadangi turėjau tik 1,5 terabaito diską, jį sunaudojau per porą dienų. Svarbiausia, kad tuo pačiu metu TimescaleDB buvo sukurti nauji skaidiniai, ir tai buvo visiškai nepastebėta dėl našumo, ko negalima pasakyti apie MySQL.
Paprastai skaidiniai kuriami naktį, nes tai paprastai blokuoja įterpimą ir darbą su lentelėmis ir gali pabloginti paslaugą. Šiuo atveju taip nėra! Pagrindinė užduotis buvo išbandyti TimescaleDB galimybes. Rezultatas buvo toks skaičius: 120 tūkstančių verčių per sekundę.
Taip pat bendruomenėje yra pavyzdžių:
Asmuo taip pat įjungė TimescaleDB ir procesoriaus apkrova naudojant io.weight sumažėjo; o vidinių proceso elementų naudojimas taip pat sumažėjo dėl TimescaleDB įtraukimo. Be to, tai yra įprasti blynų diskai, tai yra, įprasta virtuali mašina įprastuose diskuose (ne SSD)!
Kai kurioms mažoms sąrankoms, kurias riboja disko našumas, TimescaleDB, mano nuomone, yra labai geras sprendimas. Tai leis jums tęsti darbą prieš pereinant prie greitesnės duomenų bazės aparatinės įrangos.
Kviečiu visus į mūsų renginius: konferenciją Maskvoje, viršūnių susitikimą Rygoje. Naudokite mūsų kanalus - Telegramą, forumą, IRC. Jei turite klausimų, užsukite pas mus, viską aptarsime.
Klausimai publikai
Klausimas iš auditorijos (toliau – A): - Jei TimescaleDB taip lengva konfigūruoti ir ji taip padidina našumą, galbūt tai turėtų būti naudojama kaip geriausia praktika konfigūruojant Zabbix su Postgres? Ir ar yra šio sprendimo spąstų ir trūkumų, ar galų gale, jei aš nusprendžiau padaryti Zabbix sau, galiu lengvai paimti Postgres, įdiegti Timescale iš karto, naudoti jį ir negalvoti apie jokias problemas?
AG: – Taip, sakyčiau, kad tai gera rekomendacija: nedelsdami naudokite Postgres su TimescaleDB plėtiniu. Kaip jau sakiau, daug gerų atsiliepimų, nepaisant to, kad ši „funkcija“ yra eksperimentinė. Tačiau iš tikrųjų testai rodo, kad tai puikus sprendimas (su TimescaleDB) ir manau, kad jis vystysis! Stebime, kaip šis plėtinys vystosi, ir prireikus atliksime pakeitimus.
Net ir kurdami rėmėmės viena iš gerai žinomų jų „ypatybių“: su gabalėliais buvo galima dirbti kiek kitaip. Bet tada jie jį iškirpo kitame leidime, ir mes turėjome nustoti pasikliauti šiuo kodu. Šį sprendimą rekomenduočiau naudoti daugelyje sąrankų. Jei naudojate MySQL... Vidutinėms sąrankoms bet koks sprendimas veikia gerai.
A: – Paskutiniuose bendruomenės grafikuose buvo grafikas su „Namų tvarkytoja“:
Jis toliau dirbo. Ką namų šeimininkė daro su TimescaleDB?
AG: – Dabar negaliu tiksliai pasakyti – pažiūrėsiu kodą ir papasakosiu plačiau. Jis naudoja TimescaleDB užklausas ne tam, kad ištrintų gabalus, o tam, kad kažkaip juos apibendrintų. Dar nesu pasiruošęs atsakyti į šį techninį klausimą. Daugiau sužinosime stende šiandien arba rytoj.
A: – Turiu panašų klausimą – apie ištrynimo operacijos atlikimą Timescale.
A (atsakymas iš auditorijos): – Kai ištrinate duomenis iš lentelės, jei tai darote per trynimą, tuomet reikia pereiti lentelę – ištrinti, išvalyti, pažymėti viską būsimam vakuumui. Laiko skalėje, kadangi turite dalių, galite atsisakyti. Grubiai tariant, jūs tiesiog pasakote failui, kuriame yra dideli duomenys: „Ištrinti!
Laiko skalė tiesiog supranta, kad tokio gabalo nebėra. Ir kadangi jis yra integruotas į užklausų planavimo priemonę, jis naudoja kabliukus, kad gautų jūsų sąlygas pasirinktose ar kitose operacijose ir iš karto supranta, kad šio gabalo nebėra - „Aš ten daugiau neisiu! (duomenys neskelbtini). Tai viskas! Tai yra, lentelės nuskaitymas pakeičiamas dvejetainiu failo ištrynimu, todėl jis yra greitas.
A: – Ne SQL temą jau palietėme. Kiek suprantu, Zabbix tikrai nereikia keisti duomenų, ir visa tai yra kažkas panašaus į žurnalą. Ar galima naudoti specializuotas duomenų bazes, kurios negali pakeisti savo duomenų, bet tuo pačiu išsaugoti, kaupti, platinti daug greičiau - Clickhouse, pavyzdžiui, kažkas panašaus į kafką?.. Kafka taip pat yra žurnalas! Ar įmanoma juos kaip nors integruoti?
AG: - Galima iškrauti. Nuo 3.4 versijos turime tam tikrą „ypatybę“: į failus galite įrašyti visus istorinius failus, įvykius, visa kita; ir tada nusiųskite jį į bet kurią kitą duomenų bazę naudodami tam tikrą tvarkyklę. Tiesą sakant, daugelis žmonių perdirba ir rašo tiesiai į duomenų bazę. Skrydžio metu istorijos griovėjai visa tai įrašo į failus, sukasi šiuos failus ir pan., o jūs galite perkelti tai į Clickhouse. Negaliu pasakyti apie planus, bet galbūt toliau bus palaikomi NoSQL sprendimai (pvz., Clickhouse).
A: – Apskritai, pasirodo, galite visiškai atsikratyti postgres?
AG: – Žinoma, sunkiausia „Zabbix“ dalis yra istorinės lentelės, kurios sukelia daugiausia problemų, ir įvykiai. Tokiu atveju, jei ilgai nesaugosite įvykių, o istoriją su tendencijomis kaupsite kitoje greitoje saugykloje, tai apskritai, manau, problemų nebus.
A: – Ar galite įvertinti, kiek greičiau viskas veiks, jei, pavyzdžiui, pereisite prie „Clickhouse“?
AG: – Neišbandžiau. Manau, kad bent tuos pačius skaičius galima pasiekti gana paprastai, turint omenyje, kad Clickhouse turi savo sąsają, bet negaliu tiksliai pasakyti. Geriau išbandyti. Viskas priklauso nuo konfigūracijos: kiek turite hostų ir pan. Įterpimas yra vienas dalykas, bet jūs taip pat turite gauti šiuos duomenis - Grafana ar kažkas kita.
A: – Vadinasi, kalbame apie lygiavertę kovą, o ne apie didelį šių greitų duomenų bazių pranašumą?
AG: – Manau, kai integruosime, bus tikslesni testai.
A: – Kur dingo senas geras RRD? Kas paskatino jus pereiti prie SQL duomenų bazių? Iš pradžių visi rodikliai buvo renkami RRD.
AG: – Zabbix turėjo RRD, galbūt labai seną versiją. Visada egzistavo SQL duomenų bazės – klasikinis požiūris. Klasikinis požiūris yra MySQL, PostgreSQL (jie egzistuoja labai ilgą laiką). Beveik niekada nenaudojome bendros sąsajos SQL ir RRD duomenų bazėms.
Kai kurie skelbimai 🙂
Dėkojame, kad likote su mumis. Ar jums patinka mūsų straipsniai? Norite pamatyti įdomesnio turinio? Palaikykite mus pateikdami užsakymą ar rekomenduodami draugams, , unikalus pradinio lygio serverių analogas, kurį mes sugalvojome jums: (galima su RAID1 ir RAID10, iki 24 branduolių ir iki 40 GB DDR4).
„Dell R730xd“ 2 kartus pigiau „Equinix Tier IV“ duomenų centre Amsterdame? Tik čia Olandijoje! „Dell R420“ – 2 x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbps 100 TB – nuo 99 USD! Skaityti apie
Šaltinis: www.habr.com