HighLoad++, Andrei Gushchin (Zabbix): kõrge jõudlus ja kohandatud partitsioneerimine.

Käime läbi Zabbixi toimimist TimescaleDB andmebaasiga tagaplaanina. Näitame, kuidas alustada nullist ja kuidas migreerida PostgreSQLilt. Samuti toome välja kahte konfiguratsiooni võrdlevad jõudlustestid.

HighLoad++ Siberia 2019. Saal "Tomsk". 24. juuni, 16:00. Teemad ja esitlus. Järgmine HighLoad++ konverents toimub 6. ja 7. aprillil 2020 Peterburis. Üksikasjad ja piletid lingi kaudu.

Andrei Gushchin (edasi – AG): – Olen ZABBIXi (edasi – "Zabbix") tehnilise toe insener, koolitaja. Olen töötanud tehnilises toestuses üle 6 aasta ja olen otseselt tegelenud jõudluse küsimustega. Täna räägin, millist jõudlust TimescaleDB suudab pakkuda võrreldes tavalise PostgreSQL 10-ga. Samuti annan natuke sissejuhatavat teavet selle kohta, kuidas see üldse toimib.

Peamised jõudluse väljakutsed: andmete kogumisest kuni nende puhastamiseni

Alustame sellega, et igas jälgimisse süsteemis esineb teatud jõudluse väljakutseid. Esimene jõudluse väljakutse on kiire andmete kogumine ja töötlemine.

Hea jälgimissüsteem peab kõik andmed õigeaegselt ja kiiresti kätte saama, töötlema need vastavalt triggereile, st töötlema neid mingite kriteeriumide alusel (erinevates süsteemides on see erinev) ja salvestama andmebaasi, et neid hiljem kasutada.

Teine jõudluse väljakutse on ajaloo säilitamine. Andmete salvestamine andmebaasis ja kiire ning mugav ligipääs nendele mõõdikutele, mis on kogutud teatud ajavahemiku jooksul. Kõige olulisem on see, et nendest andmetest oleks lihtne välja võtta ja kasutada neid raportites, graafikutes, triggereites, vähemalt mõnede künniste väärtuste jaoks, teavitusteks jne.

Kolmas jõudluse väljakutse on ajaloo puhastamine, ehk siis päev, mil te ei vaja enam säilitada üksikasjalikke mõõdikuid, mis on kogutud 5 aasta jooksul (isegi kuude või kahe kuu jooksul). Mõned võrgu sõlmed on eemaldatud või mõned hostid, mõõdikud ei ole enam vajalikud, kuna need on juba aegunud ja lõpetanud kogumise. Kõik see tuleb eemaldada, et teie andmebaas ei kasvaks liiga suureks. Ja üldiselt on ajaloo puhastamine enamasti tõsine proovikivi salvestusruumile – see mõjutab sageli jõudlust.

Kuidas lahendada vahemälu probleeme?

Räägin nüüd konkreetselt "Zabbixist". "Zabbixis" on esimesed ja teised väljakutsed lahendatud vahemälu abil.

Andmete kogumine ja töötlemine – me kasutame nende andmete salvestamiseks töömälu. Nüüdsest räägin sellest tulenevatest andmetest lähemalt.

Samuti on andmebaaside pooles spetsiifiline vahemälu peamiste päringute jaoks – graafikute ja muude asjade jaoks.

Vahemälu Zabbix serveri poolel: meil on olemas ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Mis need on?

ConfigurationCache – see on peamine vahemälu, kus salvestame mõõdikud, hostid, andmeelemendid, triggereid; kõik, mis on vajalik andmete ettevalmistamiseks, kogumiseks, millistelt hostidelt andmeid koguda ja kui tihti. Kõik see salvestatakse ConfigurationCache’i, et mitte minna andmebaasi ja luua liigseid päringuid. Pärast serveri käivitamist uuendame (loome) selle vahemälu ja uuendame seda perioodiliselt (vastavalt konfiguratsiooniseadetele).

Vahemälu Zabbixis. Andmete kogumine

Siin on skeem piisavalt suur:

Kesksetes skeemides on need andmete kogujad:

Need on ise kogumise protsessid, erinevad "poller’id", mis vastutavad erinevate kogumise liikide eest. Nad koguvad andmeid icmp, ipmi, erinevate protokollide kaudu ja edastavad need kõik ettevalmistamiseks.

PreProcessing HistoryCache

Kui meil on ka arvutuslikud andmeelemendid (kes tunneb "Zabbixit" – teab), siis korjame need otse ValueCache’st. Räägin hiljem, kuidas see täitub. Kõik need kogujad kasutavad ConfigurationCache’i oma ülesannete saamiseks ja edastavad need edasi ettevalmistamiseks.

Ettevalmistamine kasutab samuti ConfigurationCache’i ettevalmistamise sammude saamiseks, töötleb neid andmeid erinevatel viisidel. Alates versioonist 4.2 on see meil välja viidud proksi peale. See on väga mugav, kuna ettevalmistamine on piisavalt keeruline operatsioon. Ja kui teil on väga suur "Zabbix", koos suure hulga andmeelementidega ja suure kogumise sagedusega, siis see lihtsustab tööd oluliselt.

Seega, pärast seda, kui oleme neid andmeid mingil moel ettevalmistuse abil töötlenud, salvestame need HistoryCache’i, et neid hiljem töödelda. Sellega lõpeb andmete kogumine. Liigume peamise protsessi juurde.

Ajalugu synceri töö

Zabbixi peamine protsess (kuna see on monoliitne arhitektuur) on History syncer. See on põhiprotsess, mis tegeleb iga andmeelementi, st iga väärtuse aatomaarse töötlemisega.

• Saab väärtuse (võtab selle HistoryCache'ist);
• kontrollib Configuration syncer'is: kas on olemas teatud käivitajad arvutamiseks – arvutab need välja;
  kui neid on – loob sündmusi, teeb eskaleerimise, et luua teade, kui see on konfigureerimise kohaselt vajalik;
• salvestab käivitajad järgnevalt töötlemiseks, aggregeerimiseks; kui te aggregeerite viimase tunni jooksul jne, salvestab selle väärtuse ValueCache, et mitte pöörduda ajaloo tabeli poole; seega täidetakse ValueCache vajalike andmetega, mis on vajalikud käivitajate, arvutatavate elementide jms arvutamiseks;
• edasi History syncer salvestab kõik andmed andmebaasi;
• andmebaas salvestab need kettale – sellega protsessi töötlemine lõpeb.

Andmebaasid. Vahemälu

Andmebaasi küljel, kui soovite vaadata graafikuid või teatud aruandeid sündmuste kohta, on erinevad vahemälud. Kuid selles ettekandes ei räägi ma neist.

MySQL jaoks on olemas Innodb_buffer_pool, ning rida erinevaid vahemälusid, mida saab ka seadistada.
Kuid need on peamised:

• shared_buffers;
• effective_cache_size;
• shared_pool.

Ma toomasin kõikide andmebaaside jaoks, et on olemas teatud vahemälud, mis võimaldavad hoida RAM-is andmeid, mis on sageli vajalikud päringute jaoks. Seal on nende jaoks oma tehnoloogiad.

Andmebaasi jõudlusest

Seega on olemas konkurentsikeskkond, st Zabbixi server kogub andmeid ja salvestab need. Ta loeb ka ajaloo andmeid ValueCache'i täitmiseks jne. Samuti võivad teil olla skriptid ja aruanded, mis kasutavad Zabbixi API-d, mis on ehitatud veebiliidese põhjal. Zabbixi API pääseb andmebaasi ja saab vajalikud andmed graafikute, aruannete või mingite sündmuste, viimaste probleemide loendite jaoks.

Samuti on väga populaarne lahendus visualiseerimiseks Grafana, mida meie kasutajad kasutavad. See oskab otse siseneda nii Zabbixi API kaudu kui ka andmebaasi kaudu. See loob ka teatud konkurentsi andmete saamiseks: on vajalik peen, hea andmebaasi seadistus, et tagada kiire tulemuste väljund ja testimine.

Ajaloo puhastamine. Zabbixis on Housekeeper

Kolmas kutse, mida Zabbixis kasutatakse – on ajaloo puhastamine Housekeeperi abil. Housekeeper järgib kõiki seadeid, st meie andmeelementides on märgitud, kui kaua andmeid hoida (päevades), kui kaua hoida trende, muutuste dünaamikat.

Ma ei rääkinud TrendCache'ist, mida me arvutame kohapeal: andmed saabuvad, me aggregeerime need tunni jooksul (peamiselt need on numbrid viimase tunni jooksul), keskmine/minimaalne kogus ja salvestame selle tunni ajal muutuste dünaamika tabelisse (Trends). Housekeeper käivitatakse ja kustutab andmed andmebaasist tavaliste valikutega, mis ei ole alati tõhusad.

Kuidas mõista, et see ei ole tõhus? Te näete sisemiste protsesside jõudluse graafikutelt sellist pilti:

Teie History syncer on pidevalt hõivatud (punane graafik). Ja ülevalt liigub 'oranž' graafik. See on Housekeeper, mis käivitatakse ja ootab andmebaasist, millal ta kustutab kõik read, mis ta määras.

Võtame mõne Item ID: tuleb kustutada viimased 5000; loomulikult indeksite põhjal. Kuid üldiselt on andmehulk piisavalt suur – andmebaas loeb selle ikkagi kettalt ja tõstab see mällu, mis on andmebaasi jaoks väga kulukas operatsioon. Sõltuvalt selle suurusest võib see tekitada teatud jõudlusprobleeme.

Housekeeper'i saab välja lülitada lihtsal viisil – meil on tuttav veebiliides. Seadistus Administration general'is (seaded Housekeeper'i jaoks), lülitame välja sisemise housekeeping'i sisemiste ajaloo ja trendide jaoks. Seega, Housekeeper ei halda enam seda:

Kuidas edasi minna? Olete välja lülitanud, teie graafikud on tasakaalustunud... Millised võivad olla järgmised probleemid? Mis võiks abiks olla?

Partitsioneerimine (sektsioneerimine)

Tavaliselt seadistatakse see iga rikkaandmebaasi puhul, mida olen nimetunud, erineval viisil. MySQL-l on oma tehnoloogia. Kuid üldiselt on need väga sarnased, kui rääkida PostgreSQL 10 ja MySQL-st. Loomulikult on seal palju sisemisi erinevusi, kuidas kõik see on rakendatud ja kuidas see kõik mõjutab jõudlust. Kuid üldiselt toob uue partitsiooni loomine sageli ka teatud probleeme.

Sõltuvalt teie seadistusest (kui palju andmeid luuakse päevas) on tavaliselt määratud kõige minimaalne – 1 päev/partei, ning „trendide”, muutuste dünaamika jaoks – 1 kuu/uue partei. See võib muutuda, kui teil on väga suur seadistus.

Las ma ütlen kohe seadise suuruste kohta: kuni 5000 uut väärtust sekundis (nn nvps) - seda peetakse väikseks seadiseks. Keskmine - 5 kuni 25 tuhat väärtust sekundis. Kõik, mis on üle - on juba suured ja väga suured installatsioonid, mis vajavad andmebaasi eriti hoolikat seadistamist.

Väga suurtes installatsioonides võib 1 päev olla mitteoptimaalne. Olen isiklikult näinud MySQL’is parteisid 40 gigabaiti päevas (ja rohkem võib olla). See on väga suur andmemahu, mis võib tekitada probleeme. Seda tuleb vähendada.

Miks on vajalik partitsioneerimine?

Mida annab partitsioneerimine, arvan ma, et kõik teavad - see on tabelite sektsioneerimine. Sageli on need eraldi failid kettal ja span-päringud. See valib ühe partei optimaalsemalt, kui see kuulub tavalisse partitsioneerimisse.

Zabbix'i puhul kasutatakse eriti vahemikku, st kasutame ajatemplit (tavalis number, aeg alates ajaloost). Määrate päeva alguse/lõpu ja see on partei. Seega, kui te küsite kahe päeva taguste andmete järele, valitakse see kõik andmebaasist kiiremini, sest tuleb alla laadida vaid üks fail vahemälu ja anda välja (mitte suur tabel).

Paljud andmebaasid kiirendavad ka sisestamist (ühe lapse-tabelisse). Kuigi ma räägin abstraktselt, on see samuti võimalik. Partitsioneerimine aitab sageli.

Elasticsearch NoSQL jaoks

Hiljuti, versioonis 3.4, käivitasime lahenduse NoSQL. Lisatud on võimalus kirjutada Elasticsearch'i. Saate kirjutada erinevaid tüüpe: valite - kas kirjutate numbreid või mingeid märke; meil on string-tekst, logisid saate kirjutada Elasticsearch'i... Seega, veebiliides hakkab samuti pöörduma Elasticsearch'i poole. See töötab mõnel juhul suurepäraselt, kuid praegu on seda võimalik kasutada.

TimescaleDB. Hüper tabelid

Versioonis 4.4.2 pöörasime tähelepanu ühele asjale, nimelt TimescaleDB-le. Mis see on? See on laiendus PostgreSQL’ile, st see omab natiivset PostgreSQL liidest. Pluss, see laiendus võimaldab palju efektiivsemalt töötada ajaseeriate andmetega ja omada automaatset partitsioneerimist. Kuidas see välja näeb:

See on hüper tabel - selline mõisted on Timescale’is. See on hüper tabel, mille loote, ja seal asuvad tükid (chunk). Tükid - need on parteid, need on lapse tabelid, kui ma ei eksi. See on tõeliselt efektiivne.

TimescaleDB ja PostgreSQL

TimescaleDB tootjad kinnitavad, et nad kasutavad õiget päringute töötlemise algoritmi, eriti insertide puhul, mis võimaldab omada enam-vähem konstantset jõudlust andmestiku sisestamise suuruse suurenedes. See tähendab, et pärast 200 miljonit rida tavalisel PostgreSQL'il hakkab jõudlus väga kiiresti langema ning see kaob peaaegu nullini, samas kui Timescale võimaldab sisestada insertid võimalikult efektiivselt olenemata andmete hulgast.

Kuidas installida TimescaleDB? Kõik on lihtne!

Dokumentatsioonis on see kirjas - saate installida ükskõik millistelt… see sõltub ametlikest PostgreSQL paketidest. Saate kompileerida käsitsi. Nii juhtus, et ma pidin andmebaasi jaoks kompileerima.

Zabbix'is aktiveerime lihtsalt laiendi. Ma arvan, et need, kes on kasutanud PostgreSQL’i laiendit... Lihtsalt aktiveerite laiendi, loote selle Zabbix’i andmebaasile, mida kasutate.

Ja viimane samm…

TimescaleDB. Ajalooliste tabelite migreerimine

Teil on vaja luua hüper tabel. Selle jaoks on eriline funktsioon – Create hypertable. Esimeses parameetris määrate tabeli, mis on selles andmebaasis vajalik (mille jaoks tuleb luua hüper tabel).

Väli, mille alusel tuleb luua, ja chunk_time_interval (see on tükkide (parteide, mida tuleb kasutada) intervall). 86 400 – see on üks päev.

Parameeter migrate_data: kui sisestate true, siis see kolib kõik olemasolevad andmed eelnevalt loodud chunkidesse.

Ma ise kasutasin migrate_data – see võtab märkimisväärselt aega, sõltuvalt teie andmebaasi suurusest. Mul oli üle terabaiti – loomine võttis rohkem kui tunni. Mõnes olukorras, testimise käigus, kustutasin ajaloolised andmed tekstide (history_text) ja stringide (history_str) kohta, et mitte migreerida – need ei olnud mulle tegelikult huvitavad.

Ja viimane uuendus, mille me teeme meie db_extentionis: seadistame timescaledb, et andmebaas ja eriti meie "Zabbix" mõistaks, et on olemas db_extention. See aktiveerib selle ja kasutab õigesti süntaksi ja päringuid andmebaasi, kasutades juba neid "funktsioone", mis on vajalikud TimescaleDB jaoks.

Serveri konfiguratsioon

Kasutasin kahte serverit. Esimene server on piisavalt väike virtuaalmasin, 20 protsessorit, 16 gigabaiti operatiivmälu. Seadsin sellel üles "PostgreSQL" 10.8:

Operatsioonisüsteem oli Debian, failisüsteem – xfs. Tehtud olid minimaalne seadistused, et kasutada just seda andmebaasi, arvestamata, et kasutab ka "Zabbix". Samas masinas töötas "Zabbix" server, PostgreSQL ja koormuseagentid.

Kasutasin 50 aktiivset agenti, kes kasutavad LoadableModule, et kiiresti genereerida erinevaid tulemusi. Need genereerisid ridu, numbreid ja nii edasi. Täitsin andmebaasi suure hulga andmetega. Esialgne konfiguratsioon sisaldas 5000 andmeelementi iga hosti jaoks ning igal andmeelemendil oli ligikaudu üks triger – et see oleks tõeline seadistus. Mõnikord on kasutamise jaoks isegi vajalik rohkem kui üks triger.

Uuendamise intervalli, koormust reguleerisin sellega, et kasutasin mitte ainult 50 agenti (lisades veel), vaid ka dünaamiliste andmeelementide abil ning alandasin uuendamisintervalli 4 sekundini.

Jõudluse test. PostgreSQL: 36 tuhat NVP-d

Esimene käivitamine, esimene seadistus oli mul puhtal PostgreSQL 10 sellel riistvaral (35 tuhat väärtust sekundis). Kuidas näha ekraanilt, andmete sisestamine kestab murdosa sekundist – kõik on hästi ja kiiresti, SSD-d (200 gigabaiti). Ainus probleem on see, et 20 GB täituvad piisavalt kiiresti.

Edasi on piisavalt palju selliseid graafikuid. See on Zabbixi serveri standardne jõudluse armatuurlaud.

Esimene graafik – väärtuste arv sekundis (sinine, vasakul ülal), 35 tuhat väärtust antud juhul. See (üleval keskel) on kogumise protsesside koormus, ja see (üleval paremal) – sisemiste protsesside koormus: ajaloosünergid ja housekeeper, mis siin (alumisel keskel) tegutses piisavalt pikka aega.

See graafik (alumisel keskel) näitab ValueCache kasutust – kui palju ValueCache hitte triggereid (mitu tuhat väärtust sekundis). Veel oluline graafik – neljas (alumisel vasakul), mis näitab HistoryCache kasutust, millest rääkisin, mis on bufer enne andmebaasi sisestamist.

Jõudluse test. PostgreSQL: 50 tuhat NVP-d

Seejärel suurendasin koormust 50 tuhande väärtuseni sekundis sellel samal riistvaral. Koormuse all "Housekeeper" 10 tuhat väärtust salvestati juba 2-3 sekundiga koos arvutamisega. See on tegelikult näidatud järgmises ekraanipildis:

"Housekeeper" hakkab juba tööle segama, kuid üldiselt jääb trapperite ajaloosünergite koormus ikka 60 % tasemele (kolmas graafik, paremal ülal). HistoryCache hakkab juba "Housekeeperi" töö ajal aktiivselt täituma (alumisel vasakul). See oli umbes pool gigabaiti, täitus 20%.

Jõudluse test. PostgreSQL: 80 tuhat NVP-d

Edasi suurendasin 80 tuhande väärtuseni sekundis:

See oli umbes 400 tuhat andmeelementi, 280 tuhat triggereid. Sisestamise, nagu näete, põhjal on ajaloosüngerite koormus (neid oli 30) juba piisavalt kõrge. Hiljem suurendasin erinevaid parameetreid: ajaloosüngerid, cache… Selles olekus ajaloosüngerite koormus hakkas maksimaalset taset saavutama, praktiliselt "sellel kohal" – vastavalt, HistoryCache läks väga kõrge koormuse alla:

Kogu selle aja jälgisin kõiki süsteemi parameetreid (kuidas protsessorit kasutatakse, operatiivmälu) ja avastasin, et ketaste utiliteerimine oli maksimaalne – saavutasin selle kettaseadmest maksimaalse võimaluse, sellel riistvaral, sellel virtuaalses masinas. "PostgreSQL" hakkas selle intensiivsuse juures aktiivselt andmeid koormama ja ketas ei jõudnud enam kirjutada, lugeda...

Võtsin teise serveri, millel oli juba 48 protsessorit ja 128 gigabaiti operatiivmälu:

Samuti "tuunisin" selle – panin ajaloosüngerite (60 tk) ja saavutasin vastuvõetava jõudluse. Tegelikult me ei ole "sellel kohal", aga see on ilmselt juba jõudluse piir, kus tuleb midagi ette võtta.

Jõudluse test. TimescaleDB: 80 tuhat NVP-d

Minu peamine ülesanne oli kasutada TimescaleDB. Iga graafiku pealt on näha langus:

Need-to-know data migrations are crucial. After this, as you can see, the profile of the history syncers in the 'Zabbix' server changed significantly. It now allows data insertion nearly three times faster while using less HistoryCache, ensuring timely data delivery. Again, 80 thousand values per second is a fairly high rate (of course, not for 'Yandex'). Overall, this is quite a large setup with one server.

PostgreSQL performance test: 120 thousand NVPs

Next, I increased the number of data elements to half a million and achieved a calculated value of 125 thousand per second:

I obtained these graphs:

Essentially, this is a working setup and can operate effectively for a significant duration. However, since I only had a 1.5 terabyte disk, I exhausted it within a few days. Importantly, as new partitions were created in TimescaleDB, the performance impact went unnoticed, unlike MySQL.

Usually, partitions are created overnight since it blocks any insertions and operations with tables, potentially leading to service degradation. In this case, that was not an issue! The main task was to test TimescaleDB's capabilities. The resulting figure: 120 thousand values per second.

There are examples in the community:

Another individual also implemented TimescaleDB, and the load on io.weight decreased on the processor; the usage of internal process elements also dropped thanks to TimescaleDB. And this was on ordinary spinning disks, meaning a standard virtual machine on traditional disks (not SSD)!

For smaller setups that are limited by disk performance, TimescaleDB seems to be an excellent solution. It allows you to continue operation before upgrading to faster database hardware.

I invite all of you to our events: Conference in Moscow, Summit in Riga. Use our channels – Telegram, forum, IRC. If you have any questions, come visit us at our booth; we can discuss everything.

Audience Questions

Audience question (A): – If TimescaleDB is so easy to set up and provides such performance boosts, perhaps it should be used as best practice for configuring 'Zabbix' with 'Postgres'? Are there any hidden pitfalls or downsides to this solution, or can I confidently use 'Postgres' with 'Timescale' right from the start?

AG: – Yes, I would say that it's a good recommendation to use 'Postgres' right along with the TimescaleDB extension. As I mentioned, there are many positive reviews even though this 'feature' is experimental. But tests show that it’s an excellent solution (with TimescaleDB), and I believe it will continue to evolve! We're monitoring the development of this extension and will address necessary adjustments.

During development, we relied on one of its well-known 'features': where chunk handling was slightly different. However, they removed that in the next release, and we had to discard that code. I would recommend this solution for many setups. If you're using MySQL... it works well for medium setups regardless.

A: – In the latest graphs shared by the community, there was one with 'Housekeeper':

It continued to operate. What does 'Housekeeper' do with TimescaleDB?

AG: – I can’t say for certain right now – I'll check the code and provide more details. It uses TimescaleDB queries not for chunk deletion but perhaps for aggregation. For now, I’m not prepared to answer this technical question. We will clarify at the booth today or tomorrow.

A: – I have a similar question regarding the performance of deletion operations in 'Timescale'.
A (audience response): – When you delete data from a table, if you do it via delete, you have to scan through the table – remove, clean, and mark everything for future vacuuming. In 'Timescale', as you have chunks, you can simply drop them. Basically, you just tell the file in big data: 'Delete!'

'Timescale' simply understands that such a chunk no longer exists. And since it integrates into the query planner, it catches your conditions in the select or other operations and immediately realizes that this chunk is no longer available – 'I won’t go there!' (the data is absent). That’s it! So, scanning the table is replaced by deleting a binary file, making it fast.

A: – Oleme juba puudutanud teemat, mis ei ole SQL. Nagu ma aru saan, ei vajada „Zabbix“ andmete muutmist väga, vaid see on pigem midagi nagu logi. Kas on võimalik kasutada spetsialiseeritud andmebaase, mis ei suuda oma andmeid muuta, kuid on samas palju kiirem andmete salvestamisel, kogumisel ja edastamisel – näiteks Clickhouse, midagi Kafka sarnast?.. Kafka on ju samuti logi! Kas on võimalik neid kuidagi integreerida?

AG: – Andmeid saab eksportida. Meil on versioonis 3.4 teatav „funktsioon“: saate kirjutada kõiki ajaloolisi faile, sündmusi ja muud failidesse ning seejärel saata need mõne töötlejaga teise andmebaasi. Tegelikult palju inimesi kirjutab ja kuvab andmed otse andmebaasi. „Live history-sinkers“ kirjutavad kõik need andmed failidesse, roteerivad need failid ja nii edasi, ja need saab seejärel saata „Clickhouse'i“. Ei oska tulevikuperspektiivide kohta midagi öelda, kuid võib-olla jätkub edaspidine toetus NoSQL-lahendustele (näiteks „Clickhouse“) ka edaspidi.

A: – Kas on võimalik täiesti loobuda PostgreSQL-ist?

AG: – Muidugi, kõige keerulisem osa „Zabbixis“ on ajaloolised tabelid, mis tekitavad kõige rohkem probleeme, ja sündmused. Sel juhul, kui te ei hoia sündmusi kaua ja hoidate ajalugu trendidega mõnes muus kiiremas salvestis, ei tohiks üldiselt mingeid probleeme tekkida.

A: – Kas saate hinnata, kui palju kiirem kõik töötab, kui näiteks minna üle „Clickhouse’ile“?

AG: – Ma ei ole testinud. Arvan, et minimaalselt samu numbreid on suhteliselt lihtne saavutada, arvestades, et „Clickhouse“ omab oma liidest, kuid ei saa kindlalt öelda. Parim on testida. Kõik sõltub konfiguratsioonist: kui palju teil on hoste ja nii edasi. Andmete sisestamine on üks asi, aga neid andmeid tuleb ka välja võtta – näiteks Grafana või muu tarkvaraga.

A: – Kas räägime seega tasavägisest võitlusest, mitte nendest kiiretest andmebaasidest tulenevast suurest eelisest?

AG: – Arvan, et kui integreerime, siis saavad täpsemad testid.

A: – Kuhu jäi vana hea RRD? Mis sundis liikuma SQL andmebaaside poole? Alguses koguti kõik meetmed RRD-sse.

AG: – „Zabbixis“ oli RRD, võib-olla väga vanas versioonis. Alati on olnud SQL andmebaasid – klassikaline lähenemine. Klassikaline lähenemine on MySQL ja PostgreSQL (on juba väga kaua olemas). Meil on ühine liides SQL andmebaaside jaoks ja RRD-d oleme praktiliselt kunagi kasutanud.

Veidi reklaami 🙂

Aitäh, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite näha rohkem huvitavaid materjale? Toetage meid, tehes tellimuse või soovitades meid tuttavatele. pilve VPS arendajatele alates $4,99, ainulaadne sisenemise taseme serverite analoog, mille oleme teie jaoks välja mõelnud: Kogu tõde VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps alates $19 või kuidas õieti serverit jagada? (saadaval on RAID1 ja RAID10 variandid, kuni 24 südamikku ja kuni 40GB DDR4).

Kas Dell R730xd on kaks korda odavam Equinixi Tier IV andmete keskuses Amsterdamis? Ainult meie juures 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB alates $199 Hollandi turul! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege, kuidas Luua ettevõtte tasemel infrastruktuur Dell R730xd E5-2650 v4 serveritega, mille hind on 9000 eurot, madala hinnaga?

Allikas: habr.com