{"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 Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Me arutame Zabbixi ja TimescaleDB andmebaasi koost\u00f6\u00f6d taustal. N\u00e4itame, kuidas alustada nullist ja kuidas migreerida PostgreSQL-ilt. Toome ka v\u00f5rdlevad j\u00f5udlustestid kahe konfiguratsiooni kohta.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne 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. Teesid 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. aastal Peterburis. \u00dcksikasjad ja piletid <noindex><a rel=\"nofollow\" href=\"http:\/\/bit.ly\/2sSxgBx\">linki pidi<\/a><\/noindex>.<\/p>\n<p><b>Andrei Gushchin (edasi \u2013 AG):<\/b> \u2013 Olen ZABBIX-i (edasi \u2013 \"Zabbix\") tehnilise toe insener ning treener. Olen t\u00f6\u00f6tanud tehnilises toetuses \u00fcle 6 aasta ja olen otseselt kokku puutunud j\u00f5udlusega. T\u00e4na r\u00e4\u00e4gin sellest, millist j\u00f5udlust TimescaleDB v\u00f5ib anda, v\u00f5rreldes tavalise PostgreSQL 10-ga. Toomega ka m\u00f5ningane sissejuhatus \u2013 kuidas see k\u00f5ik toimib.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Peamised j\u00f5udlusv\u00e4ljakutsed: andmete kogumisest kuni puhastamiseni<\/h3>\n<p>\nAlustame sellest, et olemas on teatud j\u00f5udlusv\u00e4ljakutsed, millega igas s\u00fcsteemis j\u00e4lgimine silmitsi seisab. Esimene j\u00f5udlusv\u00e4ljakutse on kiire andmete kogumine ja t\u00f6\u00f6tlemine.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/a2cb78b549a55c3b59d7fcdb8b8865b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHea j\u00e4lgimiss\u00fcsteem peab kiiresti ja \u00f5igeaegselt saama k\u00f5ik andmed, t\u00f6\u00f6tlema neid vastavalt alarmeerimise v\u00e4ljenditele, see t\u00e4hendab t\u00f6\u00f6tlema neid teatud kriteeriumide alusel (erinevates s\u00fcsteemides on see erinev) ja salvestama andmebaasi, et neid hiljem kasutada.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/a3ce55c3aec3eb93948150684838a5b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTeine j\u00f5udlusv\u00e4ljakutse on ajaloo salvestamine. Andmeid tuleb salvestada andmebaasis ning millele tuleb tagada kiire ja mugav juurdep\u00e4\u00e4s nendele m\u00f5\u00f5dikutele, mis on kogutud mingil ajavahemikul. K\u00f5ige t\u00e4htsam on, et need andmed oleks mugavalt k\u00e4ttesaadavad, et neid kasutada aruannetes, graafikutes, alarmeerimises, mingites l\u00e4vendites, teavitustes jne.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/325363d79f0270d620f956eeb8ab3402.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKolmas j\u00f5udlusv\u00e4ljakutse on ajaloo puhastamine, st kui tuleb p\u00e4ev, mil ei ole tarvis s\u00e4ilitada teatud \u00fcksikasjalikke m\u00f5\u00f5dikuid, mis on kogutud 5 aasta jooksul (isegi kuude v\u00f5i kahe kuu p\u00e4rast). M\u00f5ned v\u00f5rgu s\u00f5lmed on eemaldatud v\u00f5i m\u00f5ned hostid, m\u00f5\u00f5dikud ei ole enam vajalikud, kuna need on ajale jalgu j\u00e4\u00e4nud ja l\u00f5petanud kogumise. K\u00f5ik see tuleb puhastada, et teie andmebaas ei kasvaks liiga suureks. \u00dcldiselt on ajaloo puhastamine sageli t\u00f5sine proovikivi andmehoidla jaoks \u2013 see m\u00f5jutab sageli j\u00f5udlust oluliselt.<\/p>\n<h3>Kuidas lahendada vahem\u00e4luprobleeme?<\/h3>\n<p>\nMa r\u00e4\u00e4gin n\u00fc\u00fcd konkreetselt Zabbixist. Zabbixis on esimese ja teise kutsungiga seotud probleemid lahendatud vahem\u00e4lu abil.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne 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 k\u00f5ikide nende andmete salvestamiseks m\u00e4lupilti. N\u00fc\u00fcd r\u00e4\u00e4gitakse neist andmetest l\u00e4hemalt.<\/p>\n<p>Samuti on andmebaasi poolel olemas teatud vahem\u00e4lu peamiste valikute jaoks \u2013 graafikute ja muu suhtes.<\/p>\n<p>Vahem\u00e4lu Zabbix-serveri poolel: meil on ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Mis need on?<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/241a131145eccd280a7411c43b2cdce4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nConfigurationCache on peamine vahem\u00e4lu, kus me salvestame m\u00f5\u00f5dikud, hostid, andmeelemendid, triggrid; k\u00f5ik, mis on vajalik andmete eelt\u00f6\u00f6tlemiseks, andmete kogumiseks, millistest hostidest andmeid koguda ja kui tihti. K\u00f5ik see salvestatakse ConfigurationCache'i, et mitte minna andmebaasi, et mitte luua liigseid p\u00e4ringuid. Serveri k\u00e4ivitamisel v\u00e4rskendame seda vahem\u00e4lu (loome) ja v\u00e4rskendame seda perioodiliselt (s\u00f5ltuvalt konfiguratsiooni seadistustest).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne 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 Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/a6ad9dbd5deebac5440433a47c693fcf.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPeamised skeemis on need kogujad:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/feb932586302e2284bd44595caf9ee1b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNeed on kogumise protsessid, erinevad pollerid, mis vastutavad erinevate kogumiste t\u00fc\u00fcpide eest. Need koguvad andmeid icmp, ipmi ja erinevate protokollide kaudu ning edastavad need eelt\u00f6\u00f6tlemiseks.<\/p>\n<h3>Eelprotsessimise Ajaloo vahem\u00e4lu<\/h3>\n<p>\nSamuti, kui meil on arvutatud andmeelemendid (kes on Zabbixiga tuttav, see teab), st arvutatud, agregatiivsed andmeelemendid, siis v\u00f5tame need otse ValueCache'ist. Kuidas see t\u00e4idetakse, r\u00e4\u00e4gin hiljem. K\u00f5ik need kogujad kasutavad ConfigurationCache'i, et saada oma \u00fclesandeid ja edastavad need edasi eelt\u00f6\u00f6tlemiseks.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/3948ee1167c52856949c25e2043be974.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEelt\u00f6\u00f6tlemine kasutab samuti ConfigurationCache'i, et saada eelt\u00f6\u00f6tlemise samme, t\u00f6\u00f6tleb neid andmeid erinevate meetoditega. Alates versioonist 4.2 on see meil v\u00e4lja viidud proksisse. See on v\u00e4ga mugav, kuna eelt\u00f6\u00f6tlemine on \u00fcsna t\u00f6\u00f6mahukas operatsioon. Ja kui teil on v\u00e4ga suur Zabbix, kus on palju andmeelemente ja k\u00f5rge kogumise sagedus, siis see h\u00f5lbustab t\u00f6\u00f6d oluliselt.<\/p>\n<p>Seega, p\u00e4rast seda, kui me oleme andmeid mingil moel eelt\u00f6\u00f6tlemise abil t\u00f6\u00f6tlenud, salvestame need HistoryCache'i, et neid hiljem t\u00f6\u00f6delda. Sellega l\u00f5peb andmete kogumine. Liigume peamise protsessi juurde.<\/p>\n<h3>History syncer t\u00f6\u00f6<\/h3>\n<p>\n<img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/66539e4184d041ed84f797080226ba24.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPeamine protsess \u00abZabbixis\u00bb (kuna see on monoliitne arhitektuur) on History syncer. See on peamine protsess, mis tegeleb iga andmeelemendi atomaarse t\u00f6\u00f6tlemisega, st iga v\u00e4\u00e4rtusega:<\/p>\n<ul>\n<li>saab v\u00e4\u00e4rtuse (ta v\u00f5tab selle HistoryCache'ist);<\/li>\n<li>kontrollib Configuration syncer'it: kas on olemas m\u00f5ni triggereid arvutamiseks \u2013 arvutab need v\u00e4lja;<br \/>\nkui on \u2013 loob s\u00fcndmused, loob eskalatsiooni, et luua teavitamine, kui see on vajalik konfiguratsiooni j\u00e4rgi;<\/li>\n<li>salvestab triggereid edasisteks t\u00f6\u00f6tlemiseks, aggregatsiooniks; kui aggregaadite viimase tunni jooksul jne, siis see v\u00e4\u00e4rtus talletatakse ValueCache'i, et mitte p\u00f6\u00f6rduda ajaloo tabeli poole; seel\u00e4bi t\u00e4idetakse ValueCache vajalike andmetega, mis on vajalikud triggereid arvutamiseks, arvutatavate elementide jne;<\/li>\n<li>edasi kirjutab History syncer k\u00f5ik andmed andmebaasi;<\/li>\n<li>andmebaas kirjutab need kettale \u2013 sellega protsess l\u00f5petatakse.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Andmebaasid. Vahem\u00e4lu<\/h3>\n<p>\nAndmebaasi poolel, kui soovite vaadata diagramme v\u00f5i m\u00f5nda aruannet s\u00fcndmuste kohta, on erinevaid vahem\u00e4lusid. Kuid selle ettekande raames ma neist r\u00e4\u00e4kima ei hakka.<\/p>\n<p>MySQL-i jaoks on olemas Innodb_buffer_pool, veel palju erinevaid vahem\u00e4lusid, mida saab ka seadistada.<br \/>\nAga 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 Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/925e7abb21cfaa2516ff2b33ab161dc0.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMa olen k\u00f5ikide andmebaaside jaoks toonud v\u00e4lja, et on olemas teatud vahem\u00e4lud, mis v\u00f5imaldavad hoida RAM-is andmeid, mida sageli on tulemuste jaoks vaja. Seal on neil oma tehnoloogiad selle jaoks.<\/p>\n<h3>Andmebaasi j\u00f5udlusest<\/h3>\n<p>\nSeega on olemas konkurentsikeskkond, st \u00abZabbix\u00bb server kogub andmeid ja salvestab neid. Ta loeb ajaloo j\u00e4rgi ka p\u00e4rast taask\u00e4ivitamist ValueCache'i t\u00e4itmiseks jne. Samuti v\u00f5ivad teil olla skriptid ja aruanded, mis kasutavad \u00abZabbix\u00bb API-d, mis p\u00f5hineb veebiliidesele. \u00abZabbix\u00bb API siseneb andmebaasi ja saab vajalikud andmed diagrammide, aruannete v\u00f5i mingite s\u00fcndmuste, viimaste probleemide loendi saamiseks.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne 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 sisse minna nii l\u00e4bi \u00abZabbix\u00bb API kui ka andmebaasi. See loob samuti teatud konkurentsi andmete hankimise osas: on vajalik t\u00e4iendav, hea andmebaasi seadistus, et vastata kiirele tulemuste v\u00e4ljastamisele ja testimisele.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne 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 k\u00e4sk, mida kasutatakse \u00abZabbixis\u00bb, on ajaloo puhastamine Housekeeperi abil. \u00abHousekeeper\u00bb j\u00e4rgib k\u00f5iki seadistusi, see t\u00e4hendab, et meie andmeelementides on n\u00e4idatud, kui kaua (p\u00e4evades) andmeid s\u00e4ilitada, kui kaua s\u00e4ilitada trende ja muutuste d\u00fcnaamikat.<\/p>\n<p>Ma ei maininud TrendCache'i, mida me reaalajas arvutame: andmed sisenevad, me kogume need tunni kaupa (peamiselt on need arvud viimase tunni kohta), keskmine \/ minimaalne hulk ja salvestame need \u00fcks kord tunnis muutuste d\u00fcnaamikatabelisse (\u00abTrendid\u00bb). \u00abHousekeeper\u00bb k\u00e4ivitatakse ja eemaldab tavaliste selektide abil andmed andmebaasist, mis ei ole alati efektiivne.<\/p>\n<p>Kuidas m\u00f5ista, et see ei ole efektiivne? V\u00f5ite siseprotsesside j\u00f5udluse graafikutel n\u00e4ha sellist pilti:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/f413ec989491d4186a05c779978e2f6d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTeie Ajaloo s\u00fcnkroniseerija on pidevalt h\u00f5ivatud (punane graafik). Ja \u00aboran\u017e\u00bb graafik, mis jookseb peal. See on \u00abHousekeeper\u00bb, mis k\u00e4ivitub ja ootab andmebaasist, millal see eemaldab k\u00f5ik read, mille ta on m\u00e4\u00e4ranud.<\/p>\n<p>V\u00f5tame mingi Item ID: viimase 5000 kustutamine; loomulikult indekseid m\u00f6\u00f6da. Kuid tavaliselt on andmekogum piisavalt suur \u2013 andmebaas loeb ikkagi selle kettalt v\u00e4lja ja t\u00f5stab selle vahem\u00e4llu, mis on andmebaasile v\u00e4ga kulukas operatsioon. S\u00f5ltuvalt selle suurusest v\u00f5ib see tekitada teatud j\u00f5udlusprobleeme.<\/p>\n<p>\u00abHousekeeperi\u00bb saab v\u00e4lja l\u00fclitada lihtsa viisi kaudu \u2013 meil on tuttav veebiliides. Seaded Administration general (seaded \u00abHousekeeperi\u00bb jaoks) keelame sisemise hoolduse sisemise ajaloo ja trendide jaoks. Seega \u00abHousekeeper\u00bb ei halda enam seda:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/c9dc3ca86e7fd0c1229f6b9bc5d31270.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMida edasi teha? Olete selle v\u00e4lja l\u00fclitanud, teie graafikud on joondunud... Millised v\u00f5ivad olla edasised probleemid? Mis v\u00f5iks aidata?<\/p>\n<h3>Partitsioneerimine (sektsioonideks jagamine)<\/h3>\n<p>\nTavaliselt seadistatakse see igal relatsioonilisel andmebaasil, mida ma loetlesin, erinevalt. MySQL-il on oma tehnoloogia. Kuid \u00fcldiselt on need v\u00e4ga sarnased, kui r\u00e4\u00e4kida PostgreSQL 10-st ja MySQL-st. Loomulikult on seal palju sisemisi erinevusi selle asja elluviimisel ja sellel, kuidas see m\u00f5jutab j\u00f5udlust. Kuid \u00fcldiselt toob uue partitsiooni loomine sageli kaasa teatud probleeme.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne 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 \u00fche p\u00e4eva jooksul) m\u00e4\u00e4ratakse tavaliselt minimaalne aeg \u2013 1 p\u00e4ev\/partitsioon, ning \u201etrendid\u201d, muutuste d\u00fcnaamika \u2013 1 kuu\/uus partitsioon. See v\u00f5ib muutuda, kui teil on v\u00e4ga suur seadistus.<\/p>\n<p>Las ma \u00fctlen kohe seadistuse suuruste kohta: kuni 5000 uut v\u00e4\u00e4rtust sekundis (tuntud kui nvps) loetakse v\u00e4ikeseks \u201eseadistuseks\u201d. Keskmine on vahemikus 5 kuni 25 tuhat v\u00e4\u00e4rtust sekundis. K\u00f5ik, mis on \u00fcle selle, on suured ja v\u00e4ga suured installatsioonid, mis vajavad v\u00e4ga hoolikat andmebaasi seadistamist.<\/p>\n<p>V\u00e4ga suurtes installatsioonides v\u00f5ib 1 p\u00e4ev osutuda mitte optimaalseks. Olen isiklikult n\u00e4inud MySQL-s partitsioone, mis on 40 gigabaiti p\u00e4evas (ja rohkemgi). See on v\u00e4ga suur andmemaht, mis v\u00f5ib p\u00f5hjustada probleeme. Seda tuleb v\u00e4hendada.<\/p>\n<h3>Miks on partitsioneerimine vajalik?<\/h3>\n<p>\nMa arvan, et k\u00f5ik teavad, mida partitsioneerimine t\u00e4hendab \u2013 see on tabelite jagamine. Sageli on need eraldi failid kettal ja span-k\u00fcsimused. See valib \u00fche partitsiooni optimaalselt, kui see sobib tavalisse partitsioneerimisse.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/4920fb3415733799f0a90b1bc7af0114.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nZabbixi puhul kasutatakse, nimelt vahemiku j\u00e4rgi, st kasutame ajatemplit (tavaline number, aeg alates ajastu algusest). M\u00e4\u00e4rate p\u00e4eva alguse\/l\u00f5pu, ja see on partitsioon. Seega, kui p\u00f6\u00f6rdute kahe p\u00e4eva taguste andmete poole, valitakse need andmed andmebaasist kiiremini, sest tuleb ainult \u00fcks fail laadida vahem\u00e4llu ja esitada (mitte suur tabel).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/f5ee4e0b471eb5ebe701615aa617d66d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPaljud andmebaasid kiirendavad ka andmete sisestamist (sisestamine \u00fchte laps-tabelisse). Kui ma r\u00e4\u00e4gin abstraktselt, siis see on samuti v\u00f5imalik. Partitsioneerimine aitab sageli.<\/p>\n<h3>Elasticsearch NoSQL jaoks<\/h3>\n<p>\nHiljuti, versioonis 3.4, tegevusime NoSQL lahenduste rakendamisega. Lisatud on v\u00f5imalus kirjutada Elasticsearchi. Saate kirjutada erinevaid t\u00fc\u00fcpe: valite \u2013 kas kirjutada numbreid v\u00f5i mingeid m\u00e4rke; meil on string-tekst, logisid saate kirjutada Elasticsearchi\u2026 Seega, veebiliides hakkab samuti p\u00f6\u00f6rduma Elasticsearchi poole. See t\u00f6\u00f6tab teatud juhtudel suurep\u00e4raselt, kuid hetkel saab seda kasutada.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/24fe7d19c9e42474cd786ba59846c18c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>TimescaleDB. H\u00fcppertabelid<\/h3>\n<p>\n4.4.2 jaoks p\u00f6\u00f6rasime t\u00e4helepanu \u00fchele asjale, nimelt TimescaleDB-le. Mis see on? See on laiendus PostgreSQL jaoks, seega omab see natiivset PostgreSQL liidest. Lisaks v\u00f5imaldab see laiendus palju t\u00f5husamalt t\u00f6\u00f6tada ajaseeriandmetega ja omada automaatset partitsioneerimist. Kuidas see v\u00e4lja n\u00e4eb:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/de921f06453476215b6240ab9da6fae1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSee on hypertable \u2013 selline m\u00f5isted on Timescale\u2019is. See on h\u00fcpertabel, mille te loote, ja selles on t\u00fckid (chunk). T\u00fckid \u2013 need on partitsioonid, need on laps-tabelid, kui ma ei eksi. See on t\u00f5eliselt t\u00f5hus.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne 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 tootjate kinnituste kohaselt kasutavad nad paremat p\u00e4ringute t\u00f6\u00f6tlemise algoritmi, eriti insert'id, mis v\u00f5imaldab hoida enam-v\u00e4hem stabiilset j\u00f5udlust suureneva andmehulkade sisestamisel. See t\u00e4hendab, et peale 200 miljoni m\u00e4rke hakkab PostgreSQL tavaliselt tugevalt aeglustuma ja kaotab j\u00f5udluse sisuliselt nulli, samas kui Timescale v\u00f5imaldab sisestada insert'e v\u00f5imalikult t\u00f5husalt, olenemata andmete hulgast.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/a613d505a9dfe6008551ce981da7b24e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Kuidas installida TimescaleDB? See on \u00fcsna lihtne!<\/h3>\n<p>\nDokumentatsioonis on see kirjas \u2013 saab paigaldada pakkidena igasugustele\u2026 See s\u00f5ltub ametlikest PostgreSQL pakkidest. V\u00f5ib k\u00e4sitsi kompileerida. Nii juhtus, et pidin andmebaasi jaoks kompileerima.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/6767927fa92260103d318f9aa70ef5b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nZabbixis aktiveerime lihtsalt laienduse. Arvan, et need, kes on PostgreSQL'is laiendust kasutanud... Lihtsalt aktiveerite laienduse, loote selle Zabbixi andmebaasi jaoks, mida kasutate.<\/p>\n<p>Ja viimane samm...<\/p>\n<h3>TimescaleDB. Ajaloo tabelite migratsioon<\/h3>\n<p>\nOn vaja luua hypertable. Selleks on olemas spetsiaalne funktsioon \u2013 Create hypertable. Esimeseks parameetriks m\u00e4\u00e4rate tabeli, mis on selle andmebaasi jaoks vajalik (mille jaoks tuleb luua h\u00fcpertabel).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/47350f79fd9829c12685c1df8f0ff9a6.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKohandage v\u00e4li, mille alusel on vaja luua, ja chunk_time_interval (see on partitsioonide (chunkide) vaheline intervall, mida tuleb kasutada). 86 400 \u2013 see on \u00fcks p\u00e4ev. <\/p>\n<p>Migrate_data parameeter: kui sisestate true, siis see kannab k\u00f5ik praegused andmed eelnevalt loodud chunkidesse.<\/p>\n<p>Kasutasin ise migrate_data - see v\u00f5tab korralikult aega, olenevalt teie andmebaasi suurusest. Mul oli \u00fcle \u00fche terabaiti \u2013 loomine kestis kauem kui tund. M\u00f5ningatel juhtudel testimise k\u00e4igus kustutasin ajaloolisi andmeid (history_text) ja stringi (history_str), et mitte edasi kanda \u2013 need ei olnud mulle tegelikult huvitavad.<\/p>\n<p>Ja viimane v\u00e4rskendus, mille teeme meie db_extention'is: me paigaldame timescaledb, et andmebaas ja eriti meie \u00abZabbix\u00bb m\u00f5istaks, et on olemas db_extention. See aktiveerib ja kasutab \u00f5igesti s\u00fcntaksit ja p\u00e4ringuid andmebaasi, kasutades juba tarvitusele v\u00f5etud \u00abfunktsioone\u00bb, 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 m\u00e4lu. Seadsin sellele \u00fcles \u00abPostgreSQL\u00bb 10.8:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/990805374a2380a5c645c578404489bd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSisendoperatsioonis\u00fcsteem oli Debian, failis\u00fcsteem \u2013 xfs. Teostasime minimaalset seadistamist, et kasutada just seda andmebaasi, v\u00e4lja arvatud need, mis kasutab \u00abZabbix\u00bb. Samal masinal oli installitud \u00abZabbix\u00bb server, PostgreSQL ja koormuse agendid.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/a6efa9ab9cd58f0061d04f13fe31018c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKasutasin 50 aktiivset agenti, mis kasutasid LoadableModule'i, et kiiresti genereerida erinevaid tulemusi. Need genereerisid ridu, numbreid jne. T\u00e4itsin andmebaasi suure hulga andmetega. Algne konfiguratsioon sisaldas 5000 andmeelementi iga hosti kohta, kusjuures iga andmeelement sisaldas k\u00e4ivituspunkti \u2013 et see oleks t\u00f5eline seadistus. M\u00f5nikord on isegi \u00fche k\u00e4ivituspunkti kasutamine vajalik.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne 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 kaudu ja v\u00e4hendasin uuendamise intervalli 4 sekundini.<\/p>\n<h3>Tulemuslikkuse test. PostgreSQL: 36 tuhat NVP-d<\/h3>\n<p>\nEsimene k\u00e4ivitamine, esimene seadistus oli mul puhtal PostgreSQL 10-l selle riistvara peal (35 tuhat v\u00e4\u00e4rtust sekundis). \u00dcldiselt, nagu ekraanil n\u00e4ha, kestab andmete sisestamine murrangulise aja jooksul \u2013 k\u00f5ik on hea ja kiire, SSD-d (200 gigabaiti). Ainsaks probleemiks on, et 20 GB t\u00e4ituvad \u00fcsna kiiresti.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/6803a64fedd26093b9117a036d2993ae.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEdasi on piisavalt palju selliseid diagramme. See on standardne \u00abZabbix\u00bb serveri tulemuslikkuse armatuurlaud.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/081cc11c6bf42db3f8f16b6cc4e6ee0c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEsimene diagramm \u2013 v\u00e4\u00e4rtuste arv sekundis (sinine, \u00fcleval vasakul), 35 tuhat v\u00e4\u00e4rtust antud juhul. See (\u00fcleval keskel) on koormusprotsesside kogumise osas, ja see (\u00fcleval paremal) \u2013 on koormus t\u00e4pselt sisemiste protsesside osas: history syncers ja housekeeper, mis siin (alumisel keskel) t\u00f6\u00f6delda piisava aja jooksul.<\/p>\n<p>See all available plans for our services<\/p>\n<h3>Performance Test. PostgreSQL: 50,000 NVPs<\/h3>\n<p>\nNext, I increased the load to 50,000 values per second on the same hardware. When loading with 'Housekeeper', 10,000 values were already being written in 2-3 seconds with computation. This is shown in the next screenshot:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/80824da986dbee2f8d5ebe0ead4fbcfd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n'Housekeeper' already starts to interfere with operations, but overall the load on the history syncers is still at 60% (the third graph, top right). HistoryCache is actively filling up during the operation of 'Housekeeper' (bottom left). It was about half a gigabyte, filling up to 20%.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/9e1bcd4f3b9f3e8a1c9a36b2083ec61b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Performance Test. PostgreSQL: 80,000 NVPs<\/h3>\n<p>\nI then increased it to 80,000 values per second:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/13ae1589d6b9d35b4dda9c6c7d989cc2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nThis was approximately 400,000 data items, 280,000 triggers. The insertion, as you can see, based on the load of the history syncers (there were 30 of them) was already quite high. I then adjusted various parameters: history syncers, cache... On this hardware, the load on the history syncers started to approach maximum capacity, virtually 'on the shelf' - accordingly, HistoryCache went into a very high load:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/0ec528256c8fa7b16e1c7c95c8119535.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAll this time I monitored all system parameters (how the CPU is used, RAM) and found that disk utilization was at maximum - I reached the disk's maximum capability on this hardware, on this virtual machine. 'Postgres' began to actively flush data at such intensity, and the disk could not keep up with writing and reading...<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/0809dbd7638e7ee003ea24c611984a0c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI took another server, which already had 48 processors and 128 gigabytes of RAM:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/53410b502a4574aac5d40f1a2a6d3f42.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI also 'tuned it' - installed 60 History syncers and achieved acceptable performance. In fact, we are not 'on the shelf', but this is probably the performance limit where something needs to be done.<\/p>\n<h3>Performance Test. TimescaleDB: 80,000 NVPs<\/h3>\n<p>\nMy main task was to use TimescaleDB. Each graph shows a drop:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/b0064068895a34b93b5aa6771aba05cb.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNeed kaovad on andmete migreerimine. P\u00e4rast seda on Zabbix-serveris ajaloos\u00fcnkronisaatorite laadimisprofiil, nagu n\u00e4ete, v\u00e4ga tugevalt muutunud. See v\u00f5imaldab praktiliselt kolm korda kiiremini andmeid sisestada ja kasutada v\u00e4hem HistoryCache'i \u2013 seega saadetakse teile andmed \u00f5igeaegselt. J\u00e4lle, 80 tuhat v\u00e4\u00e4rtust sekundis on piisavalt k\u00f5rge kiirus (muidugi mitte Yandexi jaoks). \u00dcldiselt on see piisavalt suur seadistus \u00fchel serveril.<\/p>\n<h3>PostgreSQL j\u00f5udluse test: 120 tuhat NVP-d<\/h3>\n<p>\nSeej\u00e4rel suurendasin andmeelementide arvu poolmiljonini ja sain arvutatud v\u00e4\u00e4rtuseks 125 tuhat sekundis:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/7d0cf2ef7c6691c1bbf4b90afd34e4bb.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJa sain sellised graafikud:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/9c09333a50e016921a8a5b70e00397a1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nP\u00f5him\u00f5tteliselt on see t\u00f6\u00f6korras seadistus, mis saab piisavalt kaua t\u00f6\u00f6tada. Kuid kuna mul oli ainult 1,5 terabaidise suurusega k\u00f5vaketas, siis kulutasin selle paariga p\u00e4evaga. K\u00f5ige t\u00e4htsam on see, et samal ajal loodi uusi partitsioone TimescaleDB-s ja see ei m\u00f5jutanud j\u00f5udlust \u00fcldse, mida ei saa \u00f6elda MySQL kohta.<\/p>\n<p>Tavaliselt luuakse partitsioonid \u00f6\u00f6sel, kuna see blokeerib t\u00e4ielikult sisestamise ja t\u00f6\u00f6 tabelitega, mis v\u00f5ib viia teenuse halvenemiseni. Sel juhul seda pole! Peamine \u00fclesanne oli kontrollida TimescaleDB v\u00f5imekust. Tuli v\u00e4lja selline number: 120 tuhat v\u00e4\u00e4rtust sekundis.<\/p>\n<p>Samuti on kogukonnas n\u00e4iteid:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/66aa6b1d4c559d12082e4d91b6a1ca10.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nInimene l\u00fclitas ka TimescaleDB sisse ja IO kaalumise koormus protsessoris langes; samuti v\u00e4henes sisemiste protsesside kasutamine TimescaleDB sissel\u00fclitamise t\u00f5ttu. Ja need on tavalised plaadid, st tavaline virtuaalmasin tavalistel ketastel (mitte SSD)!<\/p>\n<p>M\u00f5ne v\u00e4ikese seadistuse jaoks, mis j\u00e4\u00e4b ketta j\u00f5udluse piiridesse, on TimescaleDB, nagu mulle tundub, v\u00e4ga hea lahendus. See v\u00f5imaldab suhteliselt h\u00e4sti j\u00e4tkata t\u00f6\u00f6tamist enne, kui migreerite kiiremaks andmebaasi riistvaraks.<\/p>\n<p>Kutsun teid k\u00f5iki meie \u00fcritustele: Konverents Moskvasse, Tippkohtumine Riiga. Kasutage meie kanaleid \u2013 Telegram, foorum, IRC. Kui teil on k\u00fcsimusi \u2013 tulge meie stendile, v\u00f5ime r\u00e4\u00e4kida k\u00f5igest.<\/p>\n<h3>K\u00fcsimused publikult<\/h3>\n<p>\nK\u00fcsimus publikust (edaspidi \u2013 A): \u2013 Kui TimescaleDB on nii lihtne seadistada ja see pakub sellist j\u00f5udluse kasvu, kas siis tasub seda kasutada kui parimat praktikat \u201eZabbixi\u201c seadistamiseks koos \u201ePostgreSQL-iga\u201c? Kas sellel lahendusel on mingeid peidetud probleeme v\u00f5i miinuseid, v\u00f5i v\u00f5in ma rahulikult v\u00f5tta \u201ePostgreSQL-i\u201c, paigaldada sinna \u201eTimescale-i\u201c kohe, kasutada seda ja mitte muretseda probleemide p\u00e4rast?<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/314845a019724806283a957b15d857cc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>AG:<\/b> \u2013 Jah, ma \u00fctleksin, et see on hea soovitus: kasutada \u201ePostgreSQL-i\u201c kohe koos TimescaleDB laiendusega. Nagu ma juba mainisin, on palju h\u00e4id arvustusi, vaatamata sellele, et see \u201efunktsioon\u201c on eksperimentaalne. Kuid tegelikult n\u00e4itavad testid, et see on suurep\u00e4rane lahendus (koos TimescaleDB-ga), ja ma arvan, et see areneb edasi! Me j\u00e4lgime, kuidas see laiendus areneb ja teeme vajalikud parandused.<\/p>\n<p>Oleme isegi arendamise ajal toetanud \u00fchte nende tuntud \u201efunktsiooni\u201c: seal sai chunk-dega veidi teisiti t\u00f6\u00f6tada. Kuid see eemaldati j\u00e4rgmistes v\u00e4ljaannetes, ja me pidime l\u00f5petama selle koodi toetamise. Soovitaksin seda lahendust kasutada paljudes seadistustes. Kui te kasutate MySQL... Keskmiste seadistuste jaoks t\u00f6\u00f6tab igasugune lahendus h\u00e4sti.<\/p>\n<p><b>A:<\/b> \u2013 Viimastel graafikutel, mis tulid kogukonnalt, oli graafik \u201eHousekeeper'ist\u201c:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne partitsioneerimine\" src=\"\/wp-content\/uploads\/2020\/01\/d01549b6b9b97d8bdf5372efe05d9039.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTa j\u00e4tkas t\u00f6\u00f6d. Mida teeb \u201eHousekeeper\u201c TimescaleDB korral?<\/p>\n<p><b>AG:<\/b> \u2013 Praegu ei oska ma t\u00e4pselt \u00f6elda \u2013 vaatan koodi ja \u00fctlen rohkem \u00fcksikasju. Ta kasutab TimescaleDB p\u00e4ringuid mitte chunk-de eemaldamiseks, vaid agregatsiooniks. Praegu ei ole ma valmis sellele tehnilisele k\u00fcsimusele vastama. T\u00e4na v\u00f5i homme selgitame seda standil.<\/p>\n<p><b>A:<\/b> \u2013 Mul on sarnane k\u00fcsimus \u2013 Timescale-i kustutamise operatsiooni j\u00f5udluse kohta.<br \/>\nA (k\u00fcsimus publikust): \u2013 Kui kustutate andmeid tabelist, kui teete seda delete kaudu, peate te tabeliga l\u00e4bi k\u00e4ima \u2013 kustutama, puhastama, m\u00e4rkima k\u00f5ik tulevase t\u00fchi. Timescale'is, kuna teil on chunk'id, saate neid kas maha visata. \u00dctleme nii, et te \u00fctlete failile, mis asub suurtes andmetes: \u201eKustuta!\u201c<\/p>\n<p>\u00abTimeScale\u00bb lihtsalt m\u00f5istab, et sellist chunk'i enam ei ole. Ja kuna see integreerub p\u00e4ringute ajakavasse, p\u00fc\u00fcab see teie tingimusi select'is v\u00f5i muudes operatsioonides hook'ide kaudu ja m\u00f5istab kohe, et seda chunk'i enam ei ole \u2013 \u00abMa sinna enam ei l\u00e4he!\u00bb (andmed puuduvad). Nii et k\u00f5ik \u2013 tabeli skaneerimine asendatakse binaarfaili kustutamisega, seega on see kiire.<\/p>\n<p><b>A:<\/b> \u2013 Oleme juba puudutanud mitte-SQLi teemat. Nii palju kui ma aru saan, ei ole \u00abZabbixile\u00bb v\u00e4ga vajalik andmete modifitseerimine, ja k\u00f5ik see on midagi sarnast logiga. Kas on v\u00f5imalik kasutada spetsialiseeritud andmebaase, mis ei saa oma andmeid muuta, kuid samas salvestavad, koguvad ja annavad palju kiiremini \u2013 n\u00e4iteks Clickhouse, miski Kafka-taoline?.. Kafka on ju ka log! Kas neid on v\u00f5imalik kuidagi integreerida?<\/p>\n<p><b>AG:<\/b> \u2013 Ekspordi saab teha. Meil on alates versioonist 3.4 teatud \u00abfunktsioon\u00bb: saate kirjutada k\u00f5ik ajaloolised failid, s\u00fcndmused ja k\u00f5ik muu failidesse; ja seej\u00e4rel saata need m\u00f5ne t\u00f6\u00f6tleja kaudu mis tahes teise andmebaasi. Tegelikult paljud teevad \u00fcmber ja kirjutavad otse andmebaasi. K\u00f5ik need ajaloo-s\u00fcnkronisaatorid kirjutavad otse failidesse, p\u00f6\u00f6ravad neid ja nii edasi, ja selle saate edastada \u00abClickhouse'i\u00bb. Ma ei saa planeeringutest r\u00e4\u00e4kida, kuid v\u00f5ib-olla j\u00e4tkub tulevane toetus NoSQL-lahendustele (nagu \u00abClickhouse\u00bb).<\/p>\n<p><b>A:<\/b> \u2013 Kas on \u00fcldse v\u00f5imalik t\u00e4ielikult loobuda Postgresist?<\/p>\n<p><b>AG:<\/b> \u2013 Loomulikult on \u00abZabbixis\u00bb k\u00f5ige keerulisem osa ajaloolised tabelid, mis tekitavad k\u00f5ige rohkem probleeme, ja s\u00fcndmused. Sel juhul, kui te ei hoia s\u00fcndmusi kaua ja hoiate ajaloo trende m\u00f5nes muus kiiremas salvestuses, siis \u00fcldiselt ei tohiks probleeme olla.<\/p>\n<p><b>A:<\/b> \u2013 Kas saaksite hinnata, kui palju kiiremini k\u00f5ik t\u00f6\u00f6tab, kui l\u00e4hete n\u00e4iteks \u00abClickhouse'i\u00bb?<\/p>\n<p><b>AG:<\/b> \u2013 Ma ei ole testinud. Arvan, et v\u00e4hemalt samu numbreid on \u00fcsna lihtne saavutada, arvestades, et \u00abClickhouse'il\u00bb on oma liides, kuid ei saa kindlalt \u00f6elda. Parim on testida. K\u00f5ik s\u00f5ltub konfiguratsioonist: kui palju teil on hoste ja nii edasi. Salvestamine on \u00fcks asi, kuid andmete hankimine on veel vajalik \u2013 Grafana v\u00f5i millegi muu kaudu.<\/p>\n<p><b>A:<\/b> \u2013 Nii et jutt on v\u00f5rdsest v\u00f5itlusest, mitte nende kiirete andmebaaside suurest eelisega?<\/p>\n<p><b>AG:<\/b> \u2013 Arvan, et kui integreerime, siis on t\u00e4psemad testid.<\/p>\n<p><b>A:<\/b> \u2013 Kus j\u00e4i vanamoodne RRD? Mis t\u00f5i kaasa \u00fclemineku SQL-andmebaasidele? Alguses koguti k\u00f5ik m\u00f5\u00f5dikud ju RRD-s.<\/p>\n<p><b>AG:<\/b> \u2013 \"Zabbixis\" oli RRD v\u00f5ibolla v\u00e4ga vanas versioonis. SQL-andmebaasid on alati olnud - klassikaline l\u00e4henemine. Klassikaline l\u00e4henemine on MySQL, PostgreSQL (need on juba v\u00e4ga kaua olemas). Meil on \u00fchine kasutajaliides SQL-andmebaaside jaoks ja RRD-d oleme praktiliselt kunagi ei kasutanud.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0161in (Zabbix): k\u00f5rge j\u00f5udlus ja natiivne 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=\"M\u00e4ngi 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 huvitavat sisu? Toetage meid, tellides teenuse 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 entry-level 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 jagada serverit \u00f5igesti?<\/a><\/noindex> (saadaval RAID1 ja RAID10 variandid, kuni 24 tuuma ja kuni 40GB DDR4).<\/p>\n<p><b>Dell R730xd on Equinixi Tier IV andmekeskuses Amsterdamis kaks korda odavam?<\/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> Hollandis! <b>Dell R420 \u2014 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB \u2014 alates $99!<\/b><\/b> Lugege sellest <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/ua-hosting\/blog\/329618\/\">Kuidas luua ettev\u00f5tte tasemel infrastruktuuri, kasutades Dell R730xd E5-2650 v4 servereid, mille hind on 9000 eurot, taskukohase hinna eest?<\/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.1.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.1.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 Gu\u0161tin (Zabbix): k\u00f5rge j\u00f5udlus ja loomulik partitsioneerimine | ProHoster","description":"K\u00e4sitleme Zabbixi t\u00f6\u00f6d TimescaleDB andmebaasiga tagaplaanina. N\u00e4itame, kuidas alustada nullist ja kuidas migreerida PostgreSQL-ilt.","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}]}}