{"id":55734,"date":"2020-01-27T00:00:00","date_gmt":"2020-01-26T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie"},"modified":"2020-02-18T14:03:52","modified_gmt":"2020-02-18T11:03:52","slug":"highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","title":{"rendered":"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>K\u00e4ime l\u00e4bi Zabbixi toimimist TimescaleDB andmebaasiga tagaplaanina. N\u00e4itame, kuidas alustada nullist ja kuidas migreerida PostgreSQLilt. Samuti toome v\u00e4lja kahte konfiguratsiooni v\u00f5rdlevad j\u00f5udlustestid.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/fb4f7ea4585b6dcdafec9d0d1e3a71e4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHighLoad++ Siberia 2019. Saal \"Tomsk\". 24. juuni, 16:00. Teemad ja <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/siberia\/2019\/abstracts\/5390\">esitlus<\/a><\/noindex>. J\u00e4rgmine HighLoad++ konverents toimub 6. ja 7. aprillil 2020 Peterburis. \u00dcksikasjad ja piletid <noindex><a rel=\"nofollow\" href=\"http:\/\/bit.ly\/2sSxgBx\">lingi kaudu<\/a><\/noindex>.<\/p>\n<p><b>Andrei Gushchin (edasi \u2013 AG):<\/b> \u2013 Olen ZABBIXi (edasi \u2013 \"Zabbix\") tehnilise toe insener, koolitaja. Olen t\u00f6\u00f6tanud tehnilises toestuses \u00fcle 6 aasta ja olen otseselt tegelenud j\u00f5udluse k\u00fcsimustega. T\u00e4na r\u00e4\u00e4gin, millist j\u00f5udlust TimescaleDB suudab pakkuda v\u00f5rreldes tavalise PostgreSQL 10-ga. Samuti annan natuke sissejuhatavat teavet selle kohta, kuidas see \u00fcldse toimib.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Peamised j\u00f5udluse v\u00e4ljakutsed: andmete kogumisest kuni nende puhastamiseni<\/h3>\n<p>\nAlustame sellega, et igas j\u00e4lgimisse s\u00fcsteemis esineb teatud j\u00f5udluse v\u00e4ljakutseid. Esimene j\u00f5udluse v\u00e4ljakutse on kiire andmete kogumine ja t\u00f6\u00f6tlemine.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/a2cb78b549a55c3b59d7fcdb8b8865b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHea j\u00e4lgimiss\u00fcsteem peab k\u00f5ik andmed \u00f5igeaegselt ja kiiresti k\u00e4tte saama, t\u00f6\u00f6tlema need vastavalt triggereile, st t\u00f6\u00f6tlema neid mingite kriteeriumide alusel (erinevates s\u00fcsteemides on see erinev) ja salvestama andmebaasi, et neid hiljem kasutada.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/a3ce55c3aec3eb93948150684838a5b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTeine j\u00f5udluse v\u00e4ljakutse on ajaloo s\u00e4ilitamine. Andmete salvestamine andmebaasis ja kiire ning mugav ligip\u00e4\u00e4s nendele m\u00f5\u00f5dikutele, mis on kogutud teatud ajavahemiku jooksul. K\u00f5ige olulisem on see, et nendest andmetest oleks lihtne v\u00e4lja v\u00f5tta ja kasutada neid raportites, graafikutes, triggereites, v\u00e4hemalt m\u00f5nede k\u00fcnniste v\u00e4\u00e4rtuste jaoks, teavitusteks jne.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/325363d79f0270d620f956eeb8ab3402.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKolmas j\u00f5udluse v\u00e4ljakutse on ajaloo puhastamine, ehk siis p\u00e4ev, mil te ei vaja enam s\u00e4ilitada \u00fcksikasjalikke m\u00f5\u00f5dikuid, mis on kogutud 5 aasta jooksul (isegi kuude v\u00f5i kahe kuu jooksul). M\u00f5ned v\u00f5rgu s\u00f5lmed on eemaldatud v\u00f5i m\u00f5ned hostid, m\u00f5\u00f5dikud ei ole enam vajalikud, kuna need on juba aegunud ja l\u00f5petanud kogumise. K\u00f5ik see tuleb eemaldada, et teie andmebaas ei kasvaks liiga suureks. Ja \u00fcldiselt on ajaloo puhastamine enamasti t\u00f5sine proovikivi salvestusruumile \u2013 see m\u00f5jutab sageli j\u00f5udlust.<\/p>\n<h3>Kuidas lahendada vahem\u00e4lu probleeme?<\/h3>\n<p>\nR\u00e4\u00e4gin n\u00fc\u00fcd konkreetselt \"Zabbixist\". \"Zabbixis\" on esimesed ja teised v\u00e4ljakutsed lahendatud vahem\u00e4lu abil.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/d5510b31553ee8e63a0c240789d51622.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAndmete kogumine ja t\u00f6\u00f6tlemine \u2013 me kasutame nende andmete salvestamiseks t\u00f6\u00f6m\u00e4lu. N\u00fc\u00fcdsest r\u00e4\u00e4gin sellest tulenevatest andmetest l\u00e4hemalt.<\/p>\n<p>Samuti on andmebaaside pooles spetsiifiline vahem\u00e4lu peamiste p\u00e4ringute jaoks \u2013 graafikute ja muude asjade jaoks.<\/p>\n<p>Vahem\u00e4lu Zabbix serveri poolel: meil on olemas ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Mis need on?<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/241a131145eccd280a7411c43b2cdce4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nConfigurationCache \u2013 see on peamine vahem\u00e4lu, kus salvestame m\u00f5\u00f5dikud, hostid, andmeelemendid, triggereid; k\u00f5ik, mis on vajalik andmete ettevalmistamiseks, kogumiseks, millistelt hostidelt andmeid koguda ja kui tihti. K\u00f5ik see salvestatakse ConfigurationCache\u2019i, et mitte minna andmebaasi ja luua liigseid p\u00e4ringuid. P\u00e4rast serveri k\u00e4ivitamist uuendame (loome) selle vahem\u00e4lu ja uuendame seda perioodiliselt (vastavalt konfiguratsiooniseadetele).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/474ac0db2e46aa945a0da62197f72987.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Vahem\u00e4lu Zabbixis. Andmete kogumine<\/h3>\n<p>\nSiin on skeem piisavalt suur:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/a6ad9dbd5deebac5440433a47c693fcf.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKesksetes skeemides on need andmete kogujad:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/feb932586302e2284bd44595caf9ee1b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNeed on ise kogumise protsessid, erinevad \"poller\u2019id\", mis vastutavad erinevate kogumise liikide eest. Nad koguvad andmeid icmp, ipmi, erinevate protokollide kaudu ja edastavad need k\u00f5ik ettevalmistamiseks.<\/p>\n<h3>PreProcessing HistoryCache<\/h3>\n<p>\nKui meil on ka arvutuslikud andmeelemendid (kes tunneb \"Zabbixit\" \u2013 teab), siis korjame need otse ValueCache\u2019st. R\u00e4\u00e4gin hiljem, kuidas see t\u00e4itub. K\u00f5ik need kogujad kasutavad ConfigurationCache\u2019i oma \u00fclesannete saamiseks ja edastavad need edasi ettevalmistamiseks.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/3948ee1167c52856949c25e2043be974.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEttevalmistamine kasutab samuti ConfigurationCache\u2019i ettevalmistamise sammude saamiseks, t\u00f6\u00f6tleb neid andmeid erinevatel viisidel. Alates versioonist 4.2 on see meil v\u00e4lja viidud proksi peale. See on v\u00e4ga mugav, kuna ettevalmistamine on piisavalt keeruline operatsioon. Ja kui teil on v\u00e4ga suur \"Zabbix\", koos suure hulga andmeelementidega ja suure kogumise sagedusega, siis see lihtsustab t\u00f6\u00f6d oluliselt.<\/p>\n<p>Seega, p\u00e4rast seda, kui oleme neid andmeid mingil moel ettevalmistuse abil t\u00f6\u00f6tlenud, salvestame need HistoryCache\u2019i, et neid hiljem t\u00f6\u00f6delda. Sellega l\u00f5peb andmete kogumine. Liigume peamise protsessi juurde.<\/p>\n<h3>Ajalugu synceri t\u00f6\u00f6<\/h3>\n<p>\n<img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/66539e4184d041ed84f797080226ba24.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nZabbixi peamine protsess (kuna see on monoliitne arhitektuur) on History syncer. See on p\u00f5hiprotsess, mis tegeleb iga andmeelementi, st iga v\u00e4\u00e4rtuse aatomaarse t\u00f6\u00f6tlemisega.<\/p>\n<ul>\n<li>Saab v\u00e4\u00e4rtuse (v\u00f5tab selle HistoryCache'ist);<\/li>\n<li>kontrollib Configuration syncer'is: kas on olemas teatud k\u00e4ivitajad arvutamiseks \u2013 arvutab need v\u00e4lja;<br \/>\nkui neid on \u2013 loob s\u00fcndmusi, teeb eskaleerimise, et luua teade, kui see on konfigureerimise kohaselt vajalik;<\/li>\n<li>salvestab k\u00e4ivitajad j\u00e4rgnevalt t\u00f6\u00f6tlemiseks, aggregeerimiseks; kui te aggregeerite viimase tunni jooksul jne, salvestab selle v\u00e4\u00e4rtuse ValueCache, et mitte p\u00f6\u00f6rduda ajaloo tabeli poole; seega t\u00e4idetakse ValueCache vajalike andmetega, mis on vajalikud k\u00e4ivitajate, arvutatavate elementide jms arvutamiseks;<\/li>\n<li>edasi History syncer salvestab k\u00f5ik andmed andmebaasi;<\/li>\n<li>andmebaas salvestab need kettale \u2013 sellega protsessi t\u00f6\u00f6tlemine l\u00f5peb.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Andmebaasid. Vahem\u00e4lu<\/h3>\n<p>\nAndmebaasi k\u00fcljel, kui soovite vaadata graafikuid v\u00f5i teatud aruandeid s\u00fcndmuste kohta, on erinevad vahem\u00e4lud. Kuid selles ettekandes ei r\u00e4\u00e4gi ma neist.<\/p>\n<p>MySQL jaoks on olemas Innodb_buffer_pool, ning rida erinevaid vahem\u00e4lusid, mida saab ka seadistada.<br \/>\nKuid need on peamised:<\/p>\n<ul>\n<li>shared_buffers;<\/li>\n<li>effective_cache_size;<\/li>\n<li>shared_pool.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/925e7abb21cfaa2516ff2b33ab161dc0.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMa toomasin k\u00f5ikide andmebaaside jaoks, et on olemas teatud vahem\u00e4lud, mis v\u00f5imaldavad hoida RAM-is andmeid, mis on sageli vajalikud p\u00e4ringute jaoks. Seal on nende jaoks oma tehnoloogiad.<\/p>\n<h3>Andmebaasi j\u00f5udlusest<\/h3>\n<p>\nSeega on olemas konkurentsikeskkond, st Zabbixi server kogub andmeid ja salvestab need. Ta loeb ka ajaloo andmeid ValueCache'i t\u00e4itmiseks jne. Samuti v\u00f5ivad teil olla skriptid ja aruanded, mis kasutavad Zabbixi API-d, mis on ehitatud veebiliidese p\u00f5hjal. Zabbixi API p\u00e4\u00e4seb andmebaasi ja saab vajalikud andmed graafikute, aruannete v\u00f5i mingite s\u00fcndmuste, viimaste probleemide loendite jaoks.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/10a55cb1af660aace3172a572bea6692.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSamuti on v\u00e4ga 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\u00e4ljund ja testimine.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/8a008e55dbee5635d386cec2fc1c40f5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Ajaloo puhastamine. Zabbixis on Housekeeper<\/h3>\n<p>\nKolmas kutse, mida Zabbixis kasutatakse \u2013 on ajaloo puhastamine Housekeeperi abil. Housekeeper j\u00e4rgib k\u00f5iki seadeid, st meie andmeelementides on m\u00e4rgitud, kui kaua andmeid hoida (p\u00e4evades), kui kaua hoida trende, muutuste d\u00fcnaamikat.<\/p>\n<p>Ma ei r\u00e4\u00e4kinud 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\u00fcnaamika tabelisse (Trends). Housekeeper k\u00e4ivitatakse ja kustutab andmed andmebaasist tavaliste valikutega, mis ei ole alati t\u00f5husad.<\/p>\n<p>Kuidas m\u00f5ista, et see ei ole t\u00f5hus? Te n\u00e4ete sisemiste protsesside j\u00f5udluse graafikutelt sellist pilti:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/f413ec989491d4186a05c779978e2f6d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTeie History syncer on pidevalt h\u00f5ivatud (punane graafik). Ja \u00fclevalt liigub 'oran\u017e' graafik. See on Housekeeper, mis k\u00e4ivitatakse ja ootab andmebaasist, millal ta kustutab k\u00f5ik read, mis ta m\u00e4\u00e4ras.<\/p>\n<p>V\u00f5tame m\u00f5ne Item ID: tuleb kustutada viimased 5000; loomulikult indeksite p\u00f5hjal. Kuid \u00fcldiselt on andmehulk piisavalt suur \u2013 andmebaas loeb selle ikkagi kettalt ja t\u00f5stab see m\u00e4llu, mis on andmebaasi jaoks v\u00e4ga kulukas operatsioon. S\u00f5ltuvalt selle suurusest v\u00f5ib see tekitada teatud j\u00f5udlusprobleeme.<\/p>\n<p>Housekeeper'i saab v\u00e4lja l\u00fclitada lihtsal viisil \u2013 meil on tuttav veebiliides. Seadistus Administration general'is (seaded Housekeeper'i jaoks), l\u00fclitame v\u00e4lja sisemise housekeeping'i sisemiste ajaloo ja trendide jaoks. Seega, Housekeeper ei halda enam seda:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/c9dc3ca86e7fd0c1229f6b9bc5d31270.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKuidas edasi minna? Olete v\u00e4lja l\u00fclitanud, teie graafikud on tasakaalustunud... Millised v\u00f5ivad olla j\u00e4rgmised probleemid? Mis v\u00f5iks abiks olla?<\/p>\n<h3>Partitsioneerimine (sektsioneerimine)<\/h3>\n<p>\nTavaliselt seadistatakse see iga rikkaandmebaasi puhul, mida olen nimetunud, erineval viisil. MySQL-l on oma tehnoloogia. Kuid \u00fcldiselt on need v\u00e4ga sarnased, kui r\u00e4\u00e4kida PostgreSQL 10 ja MySQL-st. Loomulikult on seal palju sisemisi erinevusi, kuidas k\u00f5ik see on rakendatud ja kuidas see k\u00f5ik m\u00f5jutab j\u00f5udlust. Kuid \u00fcldiselt toob uue partitsiooni loomine sageli ka teatud probleeme.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/729114d61794314e19383f09ee9b5d61.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nS\u00f5ltuvalt teie seadistusest (kui palju andmeid luuakse p\u00e4evas) on tavaliselt m\u00e4\u00e4ratud k\u00f5ige minimaalne \u2013 1 p\u00e4ev\/partei, ning \u201etrendide\u201d, muutuste d\u00fcnaamika jaoks \u2013 1 kuu\/uue partei. See v\u00f5ib muutuda, kui teil on v\u00e4ga suur seadistus.<\/p>\n<p>Las ma \u00fctlen kohe seadise suuruste kohta: kuni 5000 uut v\u00e4\u00e4rtust sekundis (nn nvps) - seda peetakse v\u00e4ikseks seadiseks. Keskmine - 5 kuni 25 tuhat v\u00e4\u00e4rtust sekundis. K\u00f5ik, mis on \u00fcle - on juba suured ja v\u00e4ga suured installatsioonid, mis vajavad andmebaasi eriti hoolikat seadistamist.<\/p>\n<p>V\u00e4ga suurtes installatsioonides v\u00f5ib 1 p\u00e4ev olla mitteoptimaalne. Olen isiklikult n\u00e4inud MySQL\u2019is parteisid 40 gigabaiti p\u00e4evas (ja rohkem v\u00f5ib olla). See on v\u00e4ga suur andmemahu, mis v\u00f5ib tekitada probleeme. Seda tuleb v\u00e4hendada.<\/p>\n<h3>Miks on vajalik partitsioneerimine?<\/h3>\n<p>\nMida annab partitsioneerimine, arvan ma, et k\u00f5ik teavad - see on tabelite sektsioneerimine. Sageli on need eraldi failid kettal ja span-p\u00e4ringud. See valib \u00fche partei optimaalsemalt, kui see kuulub tavalisse partitsioneerimisse.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/4920fb3415733799f0a90b1bc7af0114.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nZabbix'i puhul kasutatakse eriti vahemikku, st kasutame ajatemplit (tavalis number, aeg alates ajaloost). M\u00e4\u00e4rate p\u00e4eva alguse\/l\u00f5pu ja see on partei. Seega, kui te k\u00fcsite kahe p\u00e4eva taguste andmete j\u00e4rele, valitakse see k\u00f5ik andmebaasist kiiremini, sest tuleb alla laadida vaid \u00fcks fail vahem\u00e4lu ja anda v\u00e4lja (mitte suur tabel).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/f5ee4e0b471eb5ebe701615aa617d66d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPaljud andmebaasid kiirendavad ka sisestamist (\u00fche lapse-tabelisse). Kuigi ma r\u00e4\u00e4gin abstraktselt, on see samuti v\u00f5imalik. Partitsioneerimine aitab sageli.<\/p>\n<h3>Elasticsearch NoSQL jaoks<\/h3>\n<p>\nHiljuti, versioonis 3.4, k\u00e4ivitasime lahenduse NoSQL. Lisatud on v\u00f5imalus kirjutada Elasticsearch'i. Saate kirjutada erinevaid t\u00fc\u00fcpe: valite - kas kirjutate numbreid v\u00f5i mingeid m\u00e4rke; meil on string-tekst, logisid saate kirjutada Elasticsearch'i... Seega, veebiliides hakkab samuti p\u00f6\u00f6rduma Elasticsearch'i poole. See t\u00f6\u00f6tab m\u00f5nel juhul suurep\u00e4raselt, kuid praegu on seda v\u00f5imalik kasutada.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/24fe7d19c9e42474cd786ba59846c18c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>TimescaleDB. H\u00fcper tabelid<\/h3>\n<p>\nVersioonis 4.4.2 p\u00f6\u00f6rasime t\u00e4helepanu \u00fchele asjale, nimelt TimescaleDB-le. Mis see on? See on laiendus PostgreSQL\u2019ile, st see omab natiivset PostgreSQL liidest. Pluss, see laiendus v\u00f5imaldab palju efektiivsemalt t\u00f6\u00f6tada ajaseeriate andmetega ja omada automaatset partitsioneerimist. Kuidas see v\u00e4lja n\u00e4eb:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/de921f06453476215b6240ab9da6fae1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSee on h\u00fcper tabel - selline m\u00f5isted on Timescale\u2019is. See on h\u00fcper tabel, mille loote, ja seal asuvad t\u00fckid (chunk). T\u00fckid - need on parteid, need on lapse tabelid, kui ma ei eksi. See on t\u00f5eliselt efektiivne.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/719eb3f5d8c9f57544dfc4010850610c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>TimescaleDB ja PostgreSQL<\/h3>\n<p>\nTimescaleDB tootjad kinnitavad, et nad kasutavad \u00f5iget p\u00e4ringute t\u00f6\u00f6tlemise algoritmi, eriti insertide puhul, mis v\u00f5imaldab omada enam-v\u00e4hem konstantset j\u00f5udlust andmestiku sisestamise suuruse suurenedes. See t\u00e4hendab, et p\u00e4rast 200 miljonit rida tavalisel PostgreSQL'il hakkab j\u00f5udlus v\u00e4ga kiiresti langema ning see kaob peaaegu nullini, samas kui Timescale v\u00f5imaldab sisestada insertid v\u00f5imalikult efektiivselt olenemata andmete hulgast.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/a613d505a9dfe6008551ce981da7b24e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Kuidas installida TimescaleDB? K\u00f5ik on lihtne!<\/h3>\n<p>\nDokumentatsioonis on see kirjas - saate installida \u00fcksk\u00f5ik millistelt\u2026 see s\u00f5ltub ametlikest PostgreSQL paketidest. Saate kompileerida k\u00e4sitsi. Nii juhtus, et ma pidin andmebaasi jaoks kompileerima.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/6767927fa92260103d318f9aa70ef5b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nZabbix'is aktiveerime lihtsalt laiendi. Ma arvan, et need, kes on kasutanud PostgreSQL\u2019i laiendit... Lihtsalt aktiveerite laiendi, loote selle Zabbix\u2019i andmebaasile, mida kasutate.<\/p>\n<p>Ja viimane samm\u2026<\/p>\n<h3>TimescaleDB. Ajalooliste tabelite migreerimine<\/h3>\n<p>\nTeil on vaja luua h\u00fcper tabel. Selle jaoks on eriline funktsioon \u2013 Create hypertable. Esimeses parameetris m\u00e4\u00e4rate tabeli, mis on selles andmebaasis vajalik (mille jaoks tuleb luua h\u00fcper tabel).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/47350f79fd9829c12685c1df8f0ff9a6.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nV\u00e4li, mille alusel tuleb luua, ja chunk_time_interval (see on t\u00fckkide (parteide, mida tuleb kasutada) intervall). 86 400 \u2013 see on \u00fcks p\u00e4ev. <\/p>\n<p>Parameeter migrate_data: kui sisestate true, siis see kolib k\u00f5ik olemasolevad andmed eelnevalt loodud chunkidesse.<\/p>\n<p>Ma ise kasutasin migrate_data \u2013 see v\u00f5tab m\u00e4rkimisv\u00e4\u00e4rselt aega, s\u00f5ltuvalt teie andmebaasi suurusest. Mul oli \u00fcle terabaiti \u2013 loomine v\u00f5ttis rohkem kui tunni. M\u00f5nes olukorras, testimise k\u00e4igus, kustutasin ajaloolised andmed tekstide (history_text) ja stringide (history_str) kohta, et mitte migreerida \u2013 need ei olnud mulle tegelikult huvitavad.<\/p>\n<p>Ja viimane uuendus, mille me teeme meie db_extentionis: seadistame timescaledb, et andmebaas ja eriti meie \"Zabbix\" m\u00f5istaks, et on olemas db_extention. See aktiveerib selle ja kasutab \u00f5igesti s\u00fcntaksi ja p\u00e4ringuid andmebaasi, kasutades juba neid \"funktsioone\", mis on vajalikud TimescaleDB jaoks.<\/p>\n<h3>Serveri konfiguratsioon<\/h3>\n<p>\nKasutasin kahte serverit. Esimene server on piisavalt v\u00e4ike virtuaalmasin, 20 protsessorit, 16 gigabaiti operatiivm\u00e4lu. Seadsin sellel \u00fcles \"PostgreSQL\" 10.8:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/990805374a2380a5c645c578404489bd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOperatsioonis\u00fcsteem oli Debian, failis\u00fcsteem \u2013 xfs. Tehtud olid minimaalne seadistused, et kasutada just seda andmebaasi, arvestamata, et kasutab ka \"Zabbix\". Samas masinas t\u00f6\u00f6tas \"Zabbix\" server, PostgreSQL ja koormuseagentid.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/a6efa9ab9cd58f0061d04f13fe31018c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKasutasin 50 aktiivset agenti, kes kasutavad LoadableModule, et kiiresti genereerida erinevaid tulemusi. Need genereerisid ridu, numbreid ja nii edasi. T\u00e4itsin andmebaasi suure hulga andmetega. Esialgne konfiguratsioon sisaldas 5000 andmeelementi iga hosti jaoks ning igal andmeelemendil oli ligikaudu \u00fcks triger \u2013 et see oleks t\u00f5eline seadistus. M\u00f5nikord on kasutamise jaoks isegi vajalik rohkem kui \u00fcks triger.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/d5a3c306402e08bf2532eb6203a4aab4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUuendamise intervalli, koormust reguleerisin sellega, et kasutasin mitte ainult 50 agenti (lisades veel), vaid ka d\u00fcnaamiliste andmeelementide abil ning alandasin uuendamisintervalli 4 sekundini.<\/p>\n<h3>J\u00f5udluse test. PostgreSQL: 36 tuhat NVP-d<\/h3>\n<p>\nEsimene k\u00e4ivitamine, esimene seadistus oli mul puhtal PostgreSQL 10 sellel riistvaral (35 tuhat v\u00e4\u00e4rtust sekundis). Kuidas n\u00e4ha ekraanilt, andmete sisestamine kestab murdosa sekundist \u2013 k\u00f5ik on h\u00e4sti ja kiiresti, SSD-d (200 gigabaiti). Ainus probleem on see, et 20 GB t\u00e4ituvad piisavalt kiiresti.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/6803a64fedd26093b9117a036d2993ae.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEdasi on piisavalt palju selliseid graafikuid. See on Zabbixi serveri standardne j\u00f5udluse armatuurlaud.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/081cc11c6bf42db3f8f16b6cc4e6ee0c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEsimene graafik \u2013 v\u00e4\u00e4rtuste arv sekundis (sinine, vasakul \u00fclal), 35 tuhat v\u00e4\u00e4rtust antud juhul. See (\u00fcleval keskel) on kogumise protsesside koormus, ja see (\u00fcleval paremal) \u2013 sisemiste protsesside koormus: ajaloos\u00fcnergid ja housekeeper, mis siin (alumisel keskel) tegutses piisavalt pikka aega.<\/p>\n<p>See graafik (alumisel keskel) n\u00e4itab ValueCache kasutust \u2013 kui palju ValueCache hitte triggereid (mitu tuhat v\u00e4\u00e4rtust sekundis). Veel oluline graafik \u2013 neljas (alumisel vasakul), mis n\u00e4itab HistoryCache kasutust, millest r\u00e4\u00e4kisin, mis on bufer enne andmebaasi sisestamist.<\/p>\n<h3>J\u00f5udluse test. PostgreSQL: 50 tuhat NVP-d<\/h3>\n<p>\nSeej\u00e4rel suurendasin koormust 50 tuhande v\u00e4\u00e4rtuseni sekundis sellel samal riistvaral. Koormuse all \"Housekeeper\" 10 tuhat v\u00e4\u00e4rtust salvestati juba 2-3 sekundiga koos arvutamisega. See on tegelikult n\u00e4idatud j\u00e4rgmises ekraanipildis:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/80824da986dbee2f8d5ebe0ead4fbcfd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\"Housekeeper\" hakkab juba t\u00f6\u00f6le segama, kuid \u00fcldiselt j\u00e4\u00e4b trapperite ajaloos\u00fcnergite koormus ikka 60 % tasemele (kolmas graafik, paremal \u00fclal). HistoryCache hakkab juba \"Housekeeperi\" t\u00f6\u00f6 ajal aktiivselt t\u00e4ituma (alumisel vasakul). See oli umbes pool gigabaiti, t\u00e4itus 20%.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/9e1bcd4f3b9f3e8a1c9a36b2083ec61b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>J\u00f5udluse test. PostgreSQL: 80 tuhat NVP-d<\/h3>\n<p>\nEdasi suurendasin 80 tuhande v\u00e4\u00e4rtuseni sekundis:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/13ae1589d6b9d35b4dda9c6c7d989cc2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSee oli umbes 400 tuhat andmeelementi, 280 tuhat triggereid. Sisestamise, nagu n\u00e4ete, p\u00f5hjal on ajaloos\u00fcngerite koormus (neid oli 30) juba piisavalt k\u00f5rge. Hiljem suurendasin erinevaid parameetreid: ajaloos\u00fcngerid, cache\u2026 Selles olekus ajaloos\u00fcngerite koormus hakkas maksimaalset taset saavutama, praktiliselt \"sellel kohal\" \u2013 vastavalt, HistoryCache l\u00e4ks v\u00e4ga k\u00f5rge koormuse alla:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/0ec528256c8fa7b16e1c7c95c8119535.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKogu selle aja j\u00e4lgisin k\u00f5iki s\u00fcsteemi parameetreid (kuidas protsessorit kasutatakse, operatiivm\u00e4lu) ja avastasin, et ketaste utiliteerimine oli maksimaalne \u2013 saavutasin selle kettaseadmest maksimaalse v\u00f5imaluse, sellel riistvaral, sellel virtuaalses masinas. \"PostgreSQL\" hakkas selle intensiivsuse juures aktiivselt andmeid koormama ja ketas ei j\u00f5udnud enam kirjutada, lugeda...<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/0809dbd7638e7ee003ea24c611984a0c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nV\u00f5tsin teise serveri, millel oli juba 48 protsessorit ja 128 gigabaiti operatiivm\u00e4lu:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/53410b502a4574aac5d40f1a2a6d3f42.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSamuti \"tuunisin\" selle \u2013 panin ajaloos\u00fcngerite (60 tk) ja saavutasin vastuv\u00f5etava j\u00f5udluse. Tegelikult me ei ole \"sellel kohal\", aga see on ilmselt juba j\u00f5udluse piir, kus tuleb midagi ette v\u00f5tta.<\/p>\n<h3>J\u00f5udluse test. TimescaleDB: 80 tuhat NVP-d<\/h3>\n<p>\nMinu peamine \u00fclesanne oli kasutada TimescaleDB. Iga graafiku pealt on n\u00e4ha langus:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/b0064068895a34b93b5aa6771aba05cb.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNeed-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.<\/p>\n<h3>PostgreSQL performance test: 120 thousand NVPs<\/h3>\n<p>\nNext, I increased the number of data elements to half a million and achieved a calculated value of 125 thousand per second:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/7d0cf2ef7c6691c1bbf4b90afd34e4bb.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI obtained these graphs:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/9c09333a50e016921a8a5b70e00397a1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEssentially, 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.<\/p>\n<p>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.<\/p>\n<p>There are examples in the community:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/66aa6b1d4c559d12082e4d91b6a1ca10.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAnother 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)!<\/p>\n<p>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.<\/p>\n<p>I invite all of you to our events: Conference in Moscow, Summit in Riga. Use our channels \u2013 Telegram, forum, IRC. If you have any questions, come visit us at our booth; we can discuss everything.<\/p>\n<h3>Audience Questions<\/h3>\n<p>\nAudience question (A): \u2013 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?<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/314845a019724806283a957b15d857cc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>AG:<\/b> \u2013 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\u2019s 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.<\/p>\n<p>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.<\/p>\n<p><b>A:<\/b> \u2013 In the latest graphs shared by the community, there was one with 'Housekeeper':<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/d01549b6b9b97d8bdf5372efe05d9039.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIt continued to operate. What does 'Housekeeper' do with TimescaleDB?<\/p>\n<p><b>AG:<\/b> \u2013 I can\u2019t say for certain right now \u2013 I'll check the code and provide more details. It uses TimescaleDB queries not for chunk deletion but perhaps for aggregation. For now, I\u2019m not prepared to answer this technical question. We will clarify at the booth today or tomorrow.<\/p>\n<p><b>A:<\/b> \u2013 I have a similar question regarding the performance of deletion operations in 'Timescale'.<br \/>\nA (audience response): \u2013 When you delete data from a table, if you do it via delete, you have to scan through the table \u2013 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!'<\/p>\n<p>'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 \u2013 'I won\u2019t go there!' (the data is absent). That\u2019s it! So, scanning the table is replaced by deleting a binary file, making it fast.<\/p>\n<p><b>A:<\/b> \u2013 Oleme juba puudutanud teemat, mis ei ole SQL. Nagu ma aru saan, ei vajada \u201eZabbix\u201c andmete muutmist v\u00e4ga, vaid see on pigem midagi nagu logi. Kas on v\u00f5imalik kasutada spetsialiseeritud andmebaase, mis ei suuda oma andmeid muuta, kuid on samas palju kiirem andmete salvestamisel, kogumisel ja edastamisel \u2013 n\u00e4iteks Clickhouse, midagi Kafka sarnast?.. Kafka on ju samuti logi! Kas on v\u00f5imalik neid kuidagi integreerida?<\/p>\n<p><b>AG:<\/b> \u2013 Andmeid saab eksportida. Meil on versioonis 3.4 teatav \u201efunktsioon\u201c: saate kirjutada k\u00f5iki ajaloolisi faile, s\u00fcndmusi ja muud failidesse ning seej\u00e4rel saata need m\u00f5ne t\u00f6\u00f6tlejaga teise andmebaasi. Tegelikult palju inimesi kirjutab ja kuvab andmed otse andmebaasi. \u201eLive history-sinkers\u201c kirjutavad k\u00f5ik need andmed failidesse, roteerivad need failid ja nii edasi, ja need saab seej\u00e4rel saata \u201eClickhouse'i\u201c. Ei oska tulevikuperspektiivide kohta midagi \u00f6elda, kuid v\u00f5ib-olla j\u00e4tkub edaspidine toetus NoSQL-lahendustele (n\u00e4iteks \u201eClickhouse\u201c) ka edaspidi.<\/p>\n<p><b>A:<\/b> \u2013 Kas on v\u00f5imalik t\u00e4iesti loobuda PostgreSQL-ist?<\/p>\n<p><b>AG:<\/b> \u2013 Muidugi, k\u00f5ige keerulisem osa \u201eZabbixis\u201c on ajaloolised tabelid, mis tekitavad k\u00f5ige rohkem probleeme, ja s\u00fcndmused. Sel juhul, kui te ei hoia s\u00fcndmusi kaua ja hoidate ajalugu trendidega m\u00f5nes muus kiiremas salvestis, ei tohiks \u00fcldiselt mingeid probleeme tekkida.<\/p>\n<p><b>A:<\/b> \u2013 Kas saate hinnata, kui palju kiirem k\u00f5ik t\u00f6\u00f6tab, kui n\u00e4iteks minna \u00fcle \u201eClickhouse\u2019ile\u201c?<\/p>\n<p><b>AG:<\/b> \u2013 Ma ei ole testinud. Arvan, et minimaalselt samu numbreid on suhteliselt lihtne saavutada, arvestades, et \u201eClickhouse\u201c omab oma liidest, kuid ei saa kindlalt \u00f6elda. Parim on testida. K\u00f5ik s\u00f5ltub konfiguratsioonist: kui palju teil on hoste ja nii edasi. Andmete sisestamine on \u00fcks asi, aga neid andmeid tuleb ka v\u00e4lja v\u00f5tta \u2013 n\u00e4iteks Grafana v\u00f5i muu tarkvaraga.<\/p>\n<p><b>A:<\/b> \u2013 Kas r\u00e4\u00e4gime seega tasav\u00e4gisest v\u00f5itlusest, mitte nendest kiiretest andmebaasidest tulenevast suurest eelisest?<\/p>\n<p><b>AG:<\/b> \u2013 Arvan, et kui integreerime, siis saavad t\u00e4psemad testid.<\/p>\n<p><b>A:<\/b> \u2013 Kuhu j\u00e4i vana hea RRD? Mis sundis liikuma SQL andmebaaside poole? Alguses koguti k\u00f5ik meetmed RRD-sse.<\/p>\n<p><b>AG:<\/b> \u2013 \u201eZabbixis\u201c oli RRD, v\u00f5ib-olla v\u00e4ga vanas versioonis. Alati on olnud SQL andmebaasid \u2013 klassikaline l\u00e4henemine. Klassikaline l\u00e4henemine on MySQL ja PostgreSQL (on juba v\u00e4ga kaua olemas). Meil on \u00fchine liides SQL andmebaaside jaoks ja RRD-d oleme praktiliselt kunagi kasutanud.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja kohandatud partitsioneerimine.\" src=\"\/wp-content\/uploads\/2020\/01\/ac5f02494c63983601cc09c0b22e722b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<center><div class=\"youtube-placeholder\" data-id=\"umRk94j5M8o\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/umRk94j5M8o\/hqdefault.jpg\" alt=\"Vaata videot\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><\/p>\n<h3>Veidi reklaami \ud83d\ude42<\/h3>\n<p>\nAit\u00e4h, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite n\u00e4ha rohkem huvitavaid materjale? Toetage meid, tehes tellimuse v\u00f5i soovitades meid tuttavatele. <noindex><a rel=\"nofollow\" href=\"https:\/\/ua-hosting.company\/cloudvps\/nl\">pilve VPS arendajatele alates $4,99<\/a><\/noindex>, <b>ainulaadne sisenemise taseme serverite analoog, mille oleme teie jaoks v\u00e4lja m\u00f5elnud:<\/b> <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/ua-hosting\/blog\/347386\/\">Kogu t\u00f5de VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps alates $19 v\u00f5i kuidas \u00f5ieti serverit jagada?<\/a><\/noindex> (saadaval on RAID1 ja RAID10 variandid, kuni 24 s\u00fcdamikku ja kuni 40GB DDR4).<\/p>\n<p><b>Kas Dell R730xd on kaks korda odavam Equinixi Tier IV andmete keskuses Amsterdamis?<\/b> Ainult meie juures <b><noindex><a rel=\"nofollow\" href=\"https:\/\/ua-hosting.company\/serversnl\">2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB alates $199<\/a><\/noindex> Hollandi turul! <b>Dell R420 \u2014 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB \u2014 alates $99!<\/b><\/b> Lugege, kuidas <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/ua-hosting\/blog\/329618\/\">Luua ettev\u00f5tte tasemel infrastruktuur Dell R730xd E5-2650 v4 serveritega, mille hind on 9000 eurot, madala hinnaga?<\/a><\/noindex><br \/>\n<br \/>Allikas: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/ua-hosting\/blog\/485470\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0440\u0430\u0431\u043e\u0442\u0443 Zabbix \u0441 \u0431\u0430\u0437\u043e\u0439 \u0434\u0430\u043d\u043d\u044b\u0445 TimescaleDB \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 backend. \u041f\u043e\u043a\u0430\u0436\u0435\u043c, \u043a\u0430\u043a \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0441 \u043d\u0443\u043b\u044f \u0438 \u043a\u0430\u043a \u043c\u0438\u0433\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441 PostgreSQL. \u0422\u0430\u043a\u0436\u0435 \u043f\u0440\u0438\u0432\u0435\u0434\u0435\u043c \u0441\u0440\u0430\u0432\u043d\u0438\u0442\u0435\u043b\u044c\u043d\u044b\u0435 \u0442\u0435\u0441\u0442\u044b \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0434\u0432\u0443\u0445 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u0439. HighLoad++ Siberia 2019. \u0417\u0430\u043b \u00ab\u0422\u043e\u043c\u0441\u043a\u00bb. 24 \u0438\u044e\u043d\u044f, 16:00. \u0422\u0435\u0437\u0438\u0441\u044b \u0438 \u043f\u0440\u0435\u0437\u0435\u043d\u0442\u0430\u0446\u0438\u044f. \u0421\u043b\u0435\u0434\u0443\u044e\u0449\u0430\u044f \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u044f HighLoad++ \u043f\u0440\u043e\u0439\u0434\u0435\u0442 6 \u0438 7 \u0430\u043f\u0440\u0435\u043b\u044f 2020 \u0433\u043e\u0434\u0430 \u0432 \u0421\u0430\u043d\u043a\u0442-\u041f\u0435\u0442\u0435\u0440\u0431\u0443\u0440\u0433\u0435. \u041f\u043e\u0434\u0440\u043e\u0431\u043d\u043e\u0441\u0442\u0438 \u0438 \u0431\u0438\u043b\u0435\u0442\u044b \u043f\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-55734","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.0.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0440\u0430\u0431\u043e\u0442\u0443 Zabbix \u0441 \u0431\u0430\u0437\u043e\u0439 \u0434\u0430\u043d\u043d\u044b\u0445 TimescaleDB \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 backend. \u041f\u043e\u043a\u0430\u0436\u0435\u043c, \u043a\u0430\u043a \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0441 \u043d\u0443\u043b\u044f \u0438 \u043a\u0430\u043a \u043c\u0438\u0433\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441 PostgreSQL.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.0.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"et_EE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): \u0432\u044b\u0441\u043e\u043a\u0430\u044f \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u0438 \u043d\u0430\u0442\u0438\u0432\u043d\u043e\u0435 \u043f\u0430\u0440\u0442\u0438\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0440\u0430\u0431\u043e\u0442\u0443 Zabbix \u0441 \u0431\u0430\u0437\u043e\u0439 \u0434\u0430\u043d\u043d\u044b\u0445 TimescaleDB \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 backend. \u041f\u043e\u043a\u0430\u0436\u0435\u043c, \u043a\u0430\u043a \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0441 \u043d\u0443\u043b\u044f \u0438 \u043a\u0430\u043a \u043c\u0438\u0433\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441 PostgreSQL.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-01-26T21:00:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-18T11:03:52+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47HighLoad++, Andrei Gushchin (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine | ProHoster","description":"Me r\u00e4\u00e4gime Zabbixi t\u00f6\u00f6dest TimescaleDB andmebaasi backendina. N\u00e4itame, kuidas alustada nullist ja kuidas migreerida PostgreSQL-lt.","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): \u0432\u044b\u0441\u043e\u043a\u0430\u044f \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u0438 \u043d\u0430\u0442\u0438\u0432\u043d\u043e\u0435 \u043f\u0430\u0440\u0442\u0438\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 | ProHoster","og:description":"\u041c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0440\u0430\u0431\u043e\u0442\u0443 Zabbix \u0441 \u0431\u0430\u0437\u043e\u0439 \u0434\u0430\u043d\u043d\u044b\u0445 TimescaleDB \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 backend. \u041f\u043e\u043a\u0430\u0436\u0435\u043c, \u043a\u0430\u043a \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0441 \u043d\u0443\u043b\u044f \u0438 \u043a\u0430\u043a \u043c\u0438\u0433\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441 PostgreSQL.","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-01-26T21:00:00+00:00","article:modified_time":"2020-02-18T11:03:52+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"55734","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 19:37:39","updated":"2022-09-28 01:51:35","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/55734","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=55734"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/55734\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=55734"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=55734"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=55734"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}