{"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\/sv\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","title":{"rendered":"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Vi kommer att titta p\u00e5 Zabbix arbete med databasen TimescaleDB som backend. Vi visar hur man startar fr\u00e5n grunden och hur man migrerar fr\u00e5n PostgreSQL. Vi kommer ocks\u00e5 att ge j\u00e4mf\u00f6rande prestandatester av de tv\u00e5 konfigurationerna.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/fb4f7ea4585b6dcdafec9d0d1e3a71e4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHighLoad++ Sibirien 2019. Sal \"Tomsk\". 24 juni, 16:00. Texter och <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/siberia\/2019\/abstracts\/5390\">presentation<\/a><\/noindex>. N\u00e4sta konferens HighLoad++ kommer att h\u00e5llas den 6 och 7 april 2020 i Sankt Petersburg. Detaljer och biljetter <noindex><a rel=\"nofollow\" href=\"http:\/\/bit.ly\/2sSxgBx\">via l\u00e4nken<\/a><\/noindex>.<\/p>\n<p><b>Andrey Gushin (h\u00e4danefter \u2013 AG):<\/b> \u2013 Jag \u00e4r ingenj\u00f6r inom teknisk support f\u00f6r ZABBIX (h\u00e4danefter \u2013 \"Zabbix\"), tr\u00e4nare. Jag har arbetat mer \u00e4n 6 \u00e5r inom teknisk support och har direkt erfarenhet av prestanda. Idag kommer jag att ber\u00e4tta om den prestanda som TimescaleDB kan erbjuda i j\u00e4mf\u00f6relse med vanlig PostgreSQL 10. Jag ger ocks\u00e5 en viss introduktion \u2013 om hur det \u00f6verhuvudtaget fungerar.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>De st\u00f6rsta prestandautmaningarna: fr\u00e5n insamling till rensning av data<\/h3>\n<p>\nL\u00e5t oss b\u00f6rja med att det finns vissa prestandautmaningar som varje \u00f6vervakningssystem st\u00f6ter p\u00e5. Den f\u00f6rsta prestandautmaningen \u00e4r snabb insamling och bearbetning av data.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/a2cb78b549a55c3b59d7fcdb8b8865b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEtt bra \u00f6vervakningssystem b\u00f6r snabbt och i tid f\u00e5 all information, bearbeta den i enlighet med triggeruttryck, det vill s\u00e4ga bearbeta den enligt vissa kriterier (detta varierar mellan olika system) och sedan spara den i databasen f\u00f6r framtida anv\u00e4ndning.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/a3ce55c3aec3eb93948150684838a5b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDen andra prestandautmaningen \u00e4r att lagra historia. Att lagra data i databasen och samtidigt ha snabb och enkel tillg\u00e5ng till dessa m\u00e4tv\u00e4rden som samlats in under en viss tidsperiod. Det viktigaste \u00e4r att det ska vara enkelt att f\u00e5 tillg\u00e5ng till dessa uppgifter, anv\u00e4nda dem i rapporter, diagram, triggertabeller, i n\u00e5got tr\u00f6skelv\u00e4rde, f\u00f6r meddelanden, osv.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/325363d79f0270d620f956eeb8ab3402.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDet tredje prestationsutmaningen \u00e4r rensning av historik, det vill s\u00e4ga n\u00e4r det kommer en dag d\u00e5 du inte beh\u00f6ver lagra detaljerade m\u00e4tningar som har samlats in under 5 \u00e5r (\u00e4ven m\u00e5nader eller tv\u00e5 m\u00e5nader). Vissa n\u00e4tverksnoder har tagits bort, eller vissa v\u00e4rdar, m\u00e4tningarna \u00e4r redan on\u00f6diga eftersom de har blivit f\u00f6r\u00e5ldrade och inte l\u00e4ngre samlas in. Allt detta m\u00e5ste rensas bort s\u00e5 att din databas inte v\u00e4xer till en storlek. Och \u00f6verlag \u00e4r rensning av historik ofta en allvarlig pr\u00f6vning f\u00f6r lagringssystemet - det p\u00e5verkar ofta prestandan mycket.<\/p>\n<h3>Hur l\u00f6ser man cache-problem?<\/h3>\n<p>\nJag kommer nu att prata specifikt om \"Zabbix\". I \"Zabbix\" har den f\u00f6rsta och andra utmaningen l\u00f6sts med hj\u00e4lp av caching.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/d5510b31553ee8e63a0c240789d51622.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nInsamling och bearbetning av data - vi anv\u00e4nder RAM f\u00f6r att lagra all denna data. Nu kommer jag att ber\u00e4tta mer om dessa data.<\/p>\n<p>Det finns ocks\u00e5 viss caching p\u00e5 databasniv\u00e5 f\u00f6r huvudsakliga urval - f\u00f6r grafer och andra saker.<\/p>\n<p>Caching p\u00e5 sidan av sj\u00e4lva Zabbix-servern: vi har ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Vad \u00e4r detta?<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/241a131145eccd280a7411c43b2cdce4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nConfigurationCache \u00e4r den huvudsakliga cachen d\u00e4r vi lagrar m\u00e4tningar, v\u00e4rdar, datainslag, trigger; allt som beh\u00f6vs f\u00f6r att bearbeta preprocessing, samla data, fr\u00e5n vilka v\u00e4rdar man ska samla och med vilken frekvens. Allt detta lagras i ConfigurationCache s\u00e5 att vi inte beh\u00f6ver g\u00e5 till databasen och skapa on\u00f6diga f\u00f6rfr\u00e5gningar. Efter serverstart uppdaterar vi denna cache (skapar) och uppdaterar den periodiskt (beroende p\u00e5 konfigurationsinst\u00e4llningarna).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/474ac0db2e46aa945a0da62197f72987.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Caching i Zabbix. Datainsamling<\/h3>\n<p>\nH\u00e4r \u00e4r schemat ganska stort:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/a6ad9dbd5deebac5440433a47c693fcf.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDe viktigaste i schemat \u00e4r dessa insamlare:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/feb932586302e2284bd44595caf9ee1b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDetta \u00e4r sj\u00e4lva insamlingsprocesserna, olika \"pollers\" som ansvarar f\u00f6r olika typer av insamlingar. De samlar in data via icmp, ipmi, olika protokoll och skickar allt detta f\u00f6r preprocessing.<\/p>\n<h3>PreProcessing HistoryCache<\/h3>\n<p>\nOm vi har ber\u00e4knade datainslag (de som \u00e4r bekanta med \"Zabbix\" vet), det vill s\u00e4ga ber\u00e4knade, aggregationsdata - h\u00e4mtar vi dem direkt fr\u00e5n ValueCache. Jag kommer att ber\u00e4tta mer om hur den fylls senare. Alla dessa insamlare anv\u00e4nder ConfigurationCache f\u00f6r att h\u00e4mta sina uppgifter och vidarebefordrar sedan till preprocessing.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/3948ee1167c52856949c25e2043be974.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPreprocesseringen anv\u00e4nder \u00e4ven ConfigurationCache f\u00f6r att h\u00e4mta preprocesseringstegen och bearbetar dessa data p\u00e5 olika s\u00e4tt. Fr\u00e5n och med version 4.2 har vi flyttat det till en proxy. Detta \u00e4r mycket praktiskt eftersom sj\u00e4lva preprocesseringen \u00e4r en ganska tung operation. Och om du har en mycket stor 'Zabbix', med ett stort antal datatelement och h\u00f6g insamlingsfrekvens, s\u00e5 underl\u00e4ttar det arbetet avsev\u00e4rt.<\/p>\n<p>D\u00e4rf\u00f6r, efter att vi har bearbetat dessa data p\u00e5 n\u00e5got s\u00e4tt med hj\u00e4lp av preprocessering, sparar vi dem i HistoryCache f\u00f6r att vidare bearbeta dem. H\u00e4r slutar datainsamlingen. Vi g\u00e5r vidare till huvudprocessen.<\/p>\n<h3>Arbete med History syncer<\/h3>\n<p>\n<img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/66539e4184d041ed84f797080226ba24.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHuvudprocessen i 'Zabbix' (eftersom detta \u00e4r en monolitisk arkitektur) \u00e4r History syncer. Detta \u00e4r huvudprocessen som sysslar med den atom\u00e4ra bearbetningen av varje datatelelement, det vill s\u00e4ga varje v\u00e4rde:<\/p>\n<ul>\n<li>ett v\u00e4rde kommer in (den tar det fr\u00e5n HistoryCache);<\/li>\n<li>kontrollerar i Configuration syncer: finns det n\u00e5gra triggers f\u00f6r ber\u00e4kning \u2013 ber\u00e4knar dem;<br \/>\nom det finns \u2013 skapar h\u00e4ndelser, skapar eskaleringar f\u00f6r att generera ett meddelande om det \u00e4r n\u00f6dv\u00e4ndigt enligt konfigurationen;<\/li>\n<li>skriver triggers f\u00f6r vidare bearbetning, aggregering; om du aggregerar f\u00f6r den senaste timmen och s\u00e5 vidare, sparar detta v\u00e4rde ValueCache, s\u00e5 att du inte beh\u00f6ver g\u00e5 tillbaka till historiktabellen; p\u00e5 s\u00e5 s\u00e4tt fylls ValueCache med de n\u00f6dv\u00e4ndiga data som beh\u00f6vs f\u00f6r att ber\u00e4kna triggers, ber\u00e4knade element och s\u00e5 vidare;<\/li>\n<li>sedan skriver History syncer all data till databasen;<\/li>\n<li>databasen skriver dem till disken \u2013 vid denna punkt avslutas bearbetningsprocessen.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Databaser. Cachning<\/h3>\n<p>\nP\u00e5 databassidan, n\u00e4r du vill titta p\u00e5 grafer eller rapporter om h\u00e4ndelser, finns det olika caches. Men inom ramen f\u00f6r denna presentation kommer jag inte att g\u00e5 in p\u00e5 dem.<\/p>\n<p>F\u00f6r MySQL finns Innodb_buffer_pool, och en m\u00e4ngd olika andra cacher som ocks\u00e5 kan konfigureras.<br \/>\nMen dessa \u00e4r huvudpunkterna:<\/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++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/925e7abb21cfaa2516ff2b33ab161dc0.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJag har angivit f\u00f6r alla databaser att det finns specifika cacher som g\u00f6r det m\u00f6jligt att h\u00e5lla i RAM de data som ofta beh\u00f6vs f\u00f6r f\u00f6rfr\u00e5gningar. D\u00e4r har de sina egna teknologier f\u00f6r detta.<\/p>\n<h3>Om databasens prestanda<\/h3>\n<p>\nDet finns en konkurrenssituation, vilket inneb\u00e4r att \u00abZabbix\u00bb-servern samlar in data och registrerar den. Vid omstart l\u00e4ser den ocks\u00e5 fr\u00e5n historiken f\u00f6r att fylla ValueCache och s\u00e5 vidare. H\u00e4r kan ni ocks\u00e5 ha skript och rapporter som anv\u00e4nder \u00abZabbix\u00bb-API, som \u00e4r byggt p\u00e5 webbgr\u00e4nssnittet. \u00abZabbix\u00bb-API g\u00e5r in i databasen och h\u00e4mtar n\u00f6dv\u00e4ndig data f\u00f6r att skapa grafer, rapporter eller n\u00e5gon lista \u00f6ver h\u00e4ndelser och senaste problem.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/10a55cb1af660aace3172a572bea6692.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEn annan mycket popul\u00e4r l\u00f6sning f\u00f6r visualisering \u00e4r Grafana, som anv\u00e4nds av v\u00e5ra kunder. Den kan direkt ansluta b\u00e5de via \u00abZabbix\u00bb-API och via databasen. Det skapar ocks\u00e5 en viss konkurrens f\u00f6r att h\u00e4mta data: en mer detaljerad och bra inst\u00e4llning av databasen kr\u00e4vs f\u00f6r att kunna ge snabba resultat och tester.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/8a008e55dbee5635d386cec2fc1c40f5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Rensning av historik. I Zabbix finns Housekeeper.<\/h3>\n<p>\nDet tredje samtalet som anv\u00e4nds i \u00abZabbix\u00bb \u00e4r rensning av historik med hj\u00e4lp av Housekeeper. \u00abHousekeeper\u00bb f\u00f6ljer alla inst\u00e4llningar, det vill s\u00e4ga att vi i datatekniskan har angivit hur l\u00e4nge som ska sparas (i dagar), hur mycket som ska sparas av trender och dynamik i f\u00f6r\u00e4ndringar.<\/p>\n<p>Jag n\u00e4mnde inte TrendCache, som vi ber\u00e4knar i realtid: data kommer in, vi aggregerar dem p\u00e5 en timme (fr\u00e4mst dessa \u00e4r siffror fr\u00e5n den senaste timmen), medelv\u00e4rde\/minimum och registrerar detta en g\u00e5ng i timmen i tabellen f\u00f6r dynamik i f\u00f6r\u00e4ndringar (\u00abTrender\u00bb). \u00abHousekeeper\u00bb k\u00f6rs och tar bort data fr\u00e5n databasen med vanliga select-kommandon, vilket inte alltid \u00e4r effektivt.<\/p>\n<p>Hur g\u00f6r man f\u00f6r att f\u00f6rst\u00e5 att detta \u00e4r ineffektivt? P\u00e5 prestationsgraferna f\u00f6r interna processer kan man se en s\u00e5dan bild:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/f413ec989491d4186a05c779978e2f6d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nErt History syncer \u00e4r st\u00e4ndigt upptaget (r\u00f6d graf). Och den \u00aborangea\u00bb grafen som g\u00e5r ovanp\u00e5. Det \u00e4r \u00abHousekeeper\u00bb, som k\u00f6rs och v\u00e4ntar p\u00e5 databasen f\u00f6r att ta bort alla rader som den har angivit.<\/p>\n<p>L\u00e5t oss ta ett exempel p\u00e5 Item ID: vi beh\u00f6ver ta bort de senaste 5 tusen; sj\u00e4lvklart baserat p\u00e5 index. Men vanligtvis \u00e4r datasetet tillr\u00e4ckligt stort \u2013 databasen l\u00e4ser fortfarande detta fr\u00e5n disken och laddar upp i cache, vilket \u00e4r en v\u00e4ldigt kostsam operation f\u00f6r databasen. Beroende p\u00e5 dess storlek kan detta orsaka vissa prestationsproblem.<\/p>\n<p>Du kan enkelt st\u00e4nga av \"Housekeeper\" \u2013 vi har det bekanta webbgr\u00e4nssnittet. I Administration general (inst\u00e4llningar f\u00f6r \"Housekeeper\") st\u00e4nger vi av intern housekeeping f\u00f6r intern historik och trender. D\u00e4rf\u00f6r hanterar inte \"Housekeeper\" detta l\u00e4ngre:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/c9dc3ca86e7fd0c1229f6b9bc5d31270.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVad kan man g\u00f6ra h\u00e4rn\u00e4st? Du har st\u00e4ngt av, dina diagram har stabiliserats\u2026 Vilka problem kan uppst\u00e5 h\u00e4rn\u00e4st? Vad kan hj\u00e4lpa?<\/p>\n<h3>Partitionering<\/h3>\n<p>\nDetta st\u00e4lls vanligtvis in f\u00f6r varje relationsdatabas som jag har n\u00e4mnt p\u00e5 olika s\u00e4tt. MySQL har sin egen teknologi. Men generellt sett \u00e4r de mycket lika om man pratar om PostgreSQL 10 och MySQL. Sj\u00e4lvklart finns det m\u00e5nga interna skillnader i hur detta \u00e4r implementerat och hur det p\u00e5verkar prestandan. Men totalt sett leder skapandet av en ny partition ofta ocks\u00e5 till vissa problem.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/729114d61794314e19383f09ee9b5d61.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nBeroende p\u00e5 din setup (hur mycket data som skapas p\u00e5 en dag), anger man vanligtvis den minsta \u2013 det \u00e4r 1 dag\/partition, och f\u00f6r \"trender\", dynamiken av f\u00f6r\u00e4ndringar \u2013 1 m\u00e5nad \/ ny partition. Detta kan \u00e4ndras om du har en v\u00e4ldigt stor setup.<\/p>\n<p>L\u00e5t mig direkt s\u00e4ga n\u00e5got om storlekarna p\u00e5 setup: upp till 5 000 nya v\u00e4rden per sekund (s\u00e5 kallade nvps) r\u00e4knas som en liten setup. Medium \u2013 fr\u00e5n 5 000 till 25 000 v\u00e4rden per sekund. Allt \u00f6ver det \u00e4r stora och mycket stora installationer som kr\u00e4ver mycket noggrann konfiguration av just databasen.<\/p>\n<p>Vid mycket stora installationer \u00e4r 1 dag kanske inte optimalt. Jag har personligen sett MySQL-partitioner p\u00e5 40 gigabyte per dag (och mer kan f\u00f6rekomma). Detta \u00e4r en mycket stor datavolym som kan orsaka n\u00e5gra problem. Det beh\u00f6ver minskas.<\/p>\n<h3>Varf\u00f6r beh\u00f6vs partitionering?<\/h3>\n<p>\nVad ger partitionering, tror jag att alla vet \u2013 det \u00e4r sektorisering av tabeller. Ofta \u00e4r det separata filer p\u00e5 disken och sp\u00e4nningsfr\u00e5gor. Det v\u00e4ljer mer optimalt en partition om det ing\u00e5r i den vanliga partitioneringen.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/4920fb3415733799f0a90b1bc7af0114.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nF\u00f6r \u00abZabbix\u00bb anv\u00e4nds det specifikt inom ett intervall, det vill s\u00e4ga vi anv\u00e4nder en tidsst\u00e4mpel (ett vanligt nummer, tiden sedan epoken b\u00f6rjade). Du st\u00e4ller in b\u00f6rjan av dagen \/ slutet av dagen, och detta fungerar som partition. Om du beg\u00e4r data fr\u00e5n tv\u00e5 dagar tillbaka, h\u00e4mtas allt detta fr\u00e5n databasen snabbare, eftersom endast en fil beh\u00f6ver laddas in i cachen och levereras (och inte en stor tabell).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/f5ee4e0b471eb5ebe701615aa617d66d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nM\u00e5nga databaser snabbar ocks\u00e5 upp ins\u00e4ttningar (inl\u00e4gg i en child-tabell). Jag pratar fortfarande abstrakt, men detta \u00e4r ocks\u00e5 m\u00f6jligt. Partitionering hj\u00e4lper ofta.<\/p>\n<h3>Elasticsearch f\u00f6r NoSQL<\/h3>\n<p>\nNyligen, i version 3.4, implementerade vi en l\u00f6sning f\u00f6r NoSQL. Vi lade till m\u00f6jligheten att skriva till Elasticsearch. Du kan skriva vissa typer: v\u00e4lja \u2013 antingen skriva siffror eller specifika tecken; vi har str\u00e4ngtext, loggar kan skrivas till Elasticsearch\u2026 Webbgr\u00e4nssnittet kommer ocks\u00e5 att kommunicera med Elasticsearch. Detta fungerar utm\u00e4rkt i vissa fall, men f\u00f6r tillf\u00e4llet kan detta anv\u00e4ndas.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/24fe7d19c9e42474cd786ba59846c18c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>TimescaleDB. Hypertabeller<\/h3>\n<p>\nF\u00f6r 4.4.2 observerade vi en sak, kring TimescaleDB. Vad \u00e4r det? Det \u00e4r en till\u00e4gg f\u00f6r \u00abPostgres\u00bb, vilket inneb\u00e4r att det har ett inhemskt PostgreSQL-gr\u00e4nssnitt. Dessutom till\u00e5ter detta till\u00e4gg att arbeta mycket effektivare med tidsseriedata och ha automatisk partitionering. S\u00e5 h\u00e4r ser det ut:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/de921f06453476215b6240ab9da6fae1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDetta \u00e4r en hypertabell \u2013 det \u00e4r ett begrepp inom Timescale. Det \u00e4r en hypertabell som du skapar, och i den finns det chunkar. Chunkar \u00e4r partitioner, det \u00e4r child-tabeller, om jag inte minns fel. Detta \u00e4r verkligen effektivt.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/719eb3f5d8c9f57544dfc4010850610c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>TimescaleDB och PostgreSQL<\/h3>\n<p>\nSom tillverkarna av TimescaleDB f\u00f6rs\u00e4krar, anv\u00e4nder de en mer korrekt algoritm f\u00f6r att bearbeta f\u00f6rfr\u00e5gningar, s\u00e4rskilt ins\u00e4ttningar, vilket m\u00f6jligg\u00f6r ungef\u00e4r konstant prestanda vid \u00f6kande storlek p\u00e5 dataset-inl\u00e4gg. Det betyder att efter 200 miljoner rader b\u00f6rjar vanlig \u00abPostgres\u00bb att kraftigt f\u00f6rs\u00e4mras och tappar prestanda bokstavligen till noll, medan \u00abTimescale\u00bb m\u00f6jligg\u00f6r ins\u00e4ttningar s\u00e5 effektivt som m\u00f6jligt oavsett datam\u00e4ngd.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/a613d505a9dfe6008551ce981da7b24e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Hur installerar man TimescaleDB? Det \u00e4r enkelt!<\/h3>\n<p>\nDet finns beskrivningar i dokumentationen \u2013 det kan installeras fr\u00e5n paket f\u00f6r alla\u2026 Det beror p\u00e5 de officiella paketen f\u00f6r \u00abPostgres\u00bb. Man kan kompilera manuellt. Det r\u00e5kade bli s\u00e5 att jag beh\u00f6vde kompilera f\u00f6r databasen.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/6767927fa92260103d318f9aa70ef5b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nP\u00e5 \"Zabbix\" aktiverar vi bara Extention. Jag tror att de som har anv\u00e4nt Extention i \"PostgreSQL\"... Du aktiverar bara Extention, skapar den f\u00f6r databasen \"Zabbix\" som du anv\u00e4nder.<\/p>\n<p>Och det sista steget...<\/p>\n<h3>TimescaleDB. Migration av historiktabeller<\/h3>\n<p>\nDu beh\u00f6ver skapa en hypertable. Det finns en speciell funktion f\u00f6r detta \u2013 Create hypertable. I den anger du som f\u00f6rsta parameter den tabell som beh\u00f6vs i denna databas (f\u00f6r vilken du vill skapa hypertabellen).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/47350f79fd9829c12685c1df8f0ff9a6.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nF\u00e4ltet som ska skapas och chunk_time_interval (detta \u00e4r tidsintervallet f\u00f6r chunkar (partitioner) som ska anv\u00e4ndas). 86 400 \u2013 det \u00e4r en dag. <\/p>\n<p>Parameter migrate_data: om du s\u00e4tter den till true, s\u00e5 flyttar den alla aktuella data till f\u00f6rut skapade chunkar.<\/p>\n<p>Jag anv\u00e4nde sj\u00e4lv migrate_data \u2013 det tar en hel del tid, beroende p\u00e5 storleken p\u00e5 din databas. Jag hade \u00f6ver en terabyte \u2013 skapandet tog mer \u00e4n en timme. I vissa fall under testning tog jag bort historiska data f\u00f6r text (history_text) och str\u00e4ng (history_str) f\u00f6r att inte flytta dem \u2013 jag var egentligen inte intresserad av dem.<\/p>\n<p>Och den sista uppdateringen g\u00f6r vi i v\u00e5r db_extention: vi installerar timescaledb, s\u00e5 att databasen och, speciellt v\u00e5r \"Zabbix\", f\u00f6rst\u00e5r att det finns en db_extention. Den aktiverar den och anv\u00e4nder korrekt syntax och fr\u00e5gor till databasen, med de \"funktioner\" som \u00e4r n\u00f6dv\u00e4ndiga f\u00f6r TimescaleDB.<\/p>\n<h3>Serverkonfiguration<\/h3>\n<p>\nJag anv\u00e4nde tv\u00e5 servrar. Den f\u00f6rsta servern \u00e4r en ganska liten virtuell maskin, 20 processorer, 16 gigabyte RAM. Jag installerade \"PostgreSQL\" 10.8 p\u00e5 den:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/990805374a2380a5c645c578404489bd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOperativsystemet var Debian, filsystemet \u2013 xfs. Jag gjorde minimala inst\u00e4llningar f\u00f6r att anv\u00e4nda just denna databas, med undantag av vad som kommer att anv\u00e4ndas av \"Zabbix\" sj\u00e4lv. P\u00e5 samma maskin var \"Zabbix\"-servern, PostgreSQL och belastningsagenterna installerade.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/a6efa9ab9cd58f0061d04f13fe31018c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJag anv\u00e4nde 50 aktiva agenter som anv\u00e4nder LoadableModule f\u00f6r att snabbt generera olika resultat. De genererade rader, nummer och s\u00e5 vidare. Jag fyllde databasen med en stor m\u00e4ngd data. Ursprungligen inneh\u00f6ll konfigurationen 5 000 datakElement per v\u00e4rd, och varje datakElement hade en trigger \u2013 f\u00f6r att det skulle vara en riktig setup. Ibland kr\u00e4vs till och med mer \u00e4n en trigger f\u00f6r anv\u00e4ndning.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/d5a3c306402e08bf2532eb6203a4aab4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUppdateringsintervallet, sj\u00e4lva belastningen justerade jag genom att inte bara anv\u00e4nda 50 agenter (jag lade till fler) utan ocks\u00e5 med hj\u00e4lp av dynamiska datadelar och s\u00e4nkte uppdateringsintervallet till 4 sekunder.<\/p>\n<h3>Prestandatest. PostgreSQL: 36 tusen NVP:er<\/h3>\n<p>\nDen f\u00f6rsta starten, f\u00f6rsta installationen hade jag p\u00e5 ren PostgreSQL 10 p\u00e5 denna h\u00e5rdvara (35 tusen v\u00e4rden per sekund). Som man kan se p\u00e5 sk\u00e4rmen tar datainf\u00f6rseln br\u00e5kdelar av en sekund \u2013 allt fungerar bra och snabbt, SSD-enheter (200 gigabyte). Det enda som \u00e4r att 20 GB fylls snabbt.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/6803a64fedd26093b9117a036d2993ae.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDet kommer att finnas m\u00e5nga s\u00e5dana grafer fram\u00f6ver. Detta \u00e4r den standardprestanda\u00f6versikten f\u00f6r Zabbix-servern.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/081cc11c6bf42db3f8f16b6cc4e6ee0c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDen f\u00f6rsta grafen \u2013 antalet v\u00e4rden per sekund (bl\u00e5, h\u00f6gst upp till v\u00e4nster), 35 tusen v\u00e4rden i detta fall. Detta (uppe i mitten) \u00e4r belastningen p\u00e5 processerna f\u00f6r insamling, och detta (uppe till h\u00f6ger) \u2013 belastningen p\u00e5 sj\u00e4lva interna processerna: history syncers och housekeeper, som h\u00e4r (nere i mitten) utf\u00f6rdes under en viss tid.<\/p>\n<p>Denna graf (nere i mitten) visar anv\u00e4ndningen av ValueCache \u2013 hur m\u00e5nga tr\u00e4ffar ValueCache har f\u00f6r triggers (flera tusen v\u00e4rden per sekund). En annan viktig graf \u2013 den fj\u00e4rde (nere till v\u00e4nster), som visar anv\u00e4ndningen av HistoryCache, som jag n\u00e4mnde, som \u00e4r en buffer f\u00f6re inf\u00f6rsel i databasen.<\/p>\n<h3>Prestandatest. PostgreSQL: 50 tusen NVP:er<\/h3>\n<p>\nD\u00e4refter \u00f6kade jag belastningen till 50 tusen v\u00e4rden per sekund p\u00e5 samma h\u00e5rdvara. Vid insamling med Housekeeper skrevs 10 tusen v\u00e4rden in p\u00e5 2-3 sekunder med ber\u00e4kningar. Det som faktiskt visas p\u00e5 n\u00e4sta sk\u00e4rmdump:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/80824da986dbee2f8d5ebe0ead4fbcfd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHousekeeper b\u00f6rjat st\u00f6ra arbetet, men i stort sett ligger belastningen p\u00e5 history syncers fortfarande p\u00e5 60 % (den tredje grafen, uppe till h\u00f6ger). HistoryCache b\u00f6rjade aktivera och fyllas under Housekeepers arbete (nere till v\u00e4nster). Den var omkring en halv gigabyte, fylldes med 20%.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/9e1bcd4f3b9f3e8a1c9a36b2083ec61b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Prestandatest. PostgreSQL: 80 tusen NVP:er<\/h3>\n<p>\nJag \u00f6kade sedan till 80 tusen v\u00e4rden per sekund:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/13ae1589d6b9d35b4dda9c6c7d989cc2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDet handlade om cirka 400 000 datapunkter och 280 000 triggers. Inf\u00f6randet, som ni ser, var redan ganska h\u00f6g med belastningen av history-syncers (det fanns 30 av dem). Jag \u00f6kade d\u00e4refter olika parametrar: history-syncers, cache\u2026 P\u00e5 den h\u00e4r h\u00e5rdvaran b\u00f6rjade belastningen av history-syncers \u00f6ka till max, n\u00e4stan 'i taket' \u2013 d\u00e4rf\u00f6r gick HistoryCache till mycket h\u00f6g belastning:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/0ec528256c8fa7b16e1c7c95c8119535.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUnder hela denna tid har jag \u00f6vervakat alla systemparametrar (hur CPU:n anv\u00e4nds, RAM-minnet) och uppt\u00e4ckte att diskutnyttjandet var maximalt \u2013 jag hade uppn\u00e5tt maximal kapacitet p\u00e5 denna disk p\u00e5 denna h\u00e5rdvara, p\u00e5 denna virtuella maskin. 'Postgres' b\u00f6rjade dumpa data ganska aktivt vid denna intensitet, och disken hann inte med att skriva eller l\u00e4sa\u2026<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/0809dbd7638e7ee003ea24c611984a0c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJag tog en annan server som redan hade 48 processorer och 128 gigabyte RAM-minne:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/53410b502a4574aac5d40f1a2a6d3f42.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJag 'tunade' ocks\u00e5 den \u2013 installerade 60 History syncers och uppn\u00e5dde acceptabel prestanda. Egentligen \u00e4r vi inte 'i taket', men det \u00e4r nog redan gr\u00e4nsen f\u00f6r prestandan d\u00e4r man verkligen beh\u00f6ver ta n\u00e5got steg.<\/p>\n<h3>Prestandatest. TimescaleDB: 80 000 NVPs<\/h3>\n<p>\nMin huvuduppgift var att anv\u00e4nda TimescaleDB. P\u00e5 varje graf syns ett fall:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/b0064068895a34b93b5aa6771aba05cb.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDessa fall \u00e4r just datamigreringen. Efter detta har profilen f\u00f6r belastningen av history-syncers i 'Zabbix'-servern, som ni ser, f\u00f6r\u00e4ndrats kraftigt. Den m\u00f6jligg\u00f6r n\u00e4stan tre g\u00e5nger snabbare infogning av data och anv\u00e4nder mindre HistoryCache \u2013 d\u00e4rmed kommer ni att f\u00e5 data i tid. \u00c5terigen, 80 000 v\u00e4rden per sekund \u2013 det \u00e4r ett ganska h\u00f6gt rate (naturligtvis inte f\u00f6r 'Yandex'). \u00d6verlag \u00e4r detta en ganska stor setup, med en server.<\/p>\n<h3>Prestandatest av PostgreSQL: 120 000 NVPs<\/h3>\n<p>\nSedan \u00f6kade jag antalet datapunkter till en halv miljon och fick ett ber\u00e4knat v\u00e4rde av 125 000 per sekund:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/7d0cf2ef7c6691c1bbf4b90afd34e4bb.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOch fick s\u00e5dana h\u00e4r grafer:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/9c09333a50e016921a8a5b70e00397a1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI princip \u00e4r detta en fungerande setup, den kan fungera ganska l\u00e4nge. Men eftersom jag hade en disk p\u00e5 endast 1,5 terabyte f\u00f6rbrukade jag den p\u00e5 ett par dagar. Det viktigaste \u00e4r att nya partitioner skapades p\u00e5 TimescaleDB samtidigt, och det p\u00e5verkade prestandan helt osynligt, vilket inte g\u00e5r att s\u00e4ga om MySQL.<\/p>\n<p>Vanligtvis skapas partitioner p\u00e5 natten eftersom det blockerar all ins\u00e4ttning och arbete med tabeller, vilket kan leda till degradering av tj\u00e4nsten. I det h\u00e4r fallet \u00e4r det inte s\u00e5! Huvuduppgiften var att kontrollera m\u00f6jligheterna med TimescaleDB. Resultatet blev: 120 000 v\u00e4rden per sekund.<\/p>\n<p>Det finns ocks\u00e5 exempel i \"communityn\":<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/66aa6b1d4c559d12082e4d91b6a1ca10.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEn person aktiverade ocks\u00e5 TimescaleDB och belastningen fr\u00e5n io.weight sj\u00f6nk p\u00e5 processorn; och anv\u00e4ndningen av interna processkomponenter minskade ocks\u00e5 tack vare aktiveringen av TimescaleDB. Och det \u00e4r vanliga h\u00e5rddiskar, det vill s\u00e4ga en vanlig virtuell maskin p\u00e5 vanliga diskar (inte SSD)!<\/p>\n<p>F\u00f6r vissa sm\u00e5 setup:ar som \u00e4r begr\u00e4nsade av diskens prestanda, tycker jag att TimescaleDB \u00e4r en mycket bra l\u00f6sning. Det l\u00e5ter er forts\u00e4tta arbeta tills ni migrerar till snabbare h\u00e5rdvara f\u00f6r databasen.<\/p>\n<p>Jag bjuder in er alla till v\u00e5ra evenemang: Conference \u2013 i Moskva, Summit \u2013 i Riga. Anv\u00e4nd v\u00e5ra kanaler \u2013 \"Telegram\", forum, IRC. Om ni har n\u00e5gra fr\u00e5gor \u2013 kom g\u00e4rna till v\u00e5r disk, vi kan prata om allt.<\/p>\n<h3>Fr\u00e5gor fr\u00e5n publiken<\/h3>\n<p>\nFr\u00e5ga fr\u00e5n publiken (nedan \u2013 A): \u2013 Om TimescaleDB \u00e4r s\u00e5 enkelt att konfigurera, och ger en s\u00e5dan prestanda\u00f6kning, kanske det \u00e4r v\u00e4rt att anv\u00e4nda som b\u00e4sta praxis f\u00f6r att konfigurera \"Zabbix\" med \"Postgres\"? Finns det n\u00e5gra fallgropar eller nackdelar med denna l\u00f6sning, eller om jag har best\u00e4mt mig f\u00f6r att anv\u00e4nda \"Zabbix\", kan jag d\u00e5 lugnt ta \"Postgres\", installera \"Timescale\" d\u00e4r direkt, anv\u00e4nda det och inte t\u00e4nka p\u00e5 n\u00e5gra problem?<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/314845a019724806283a957b15d857cc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>AG:<\/b> \u2013 Ja, jag skulle s\u00e4ga att det \u00e4r en bra rekommendation: att anv\u00e4nda \"Postgres\" direkt med TimescaleDB-till\u00e4gget. Som jag redan har sagt, har jag h\u00f6rt m\u00e5nga goda omd\u00f6men, trots att denna \"funktion\" \u00e4r experimentell. Men tester visar faktiskt att det \u00e4r en utm\u00e4rkt l\u00f6sning (med TimescaleDB), och jag tror att den kommer att utvecklas! Vi f\u00f6ljer hur detta till\u00e4gg utvecklas och kommer att justera det som beh\u00f6vs.<\/p>\n<p>Under utvecklingen lutade vi oss till och med p\u00e5 en av deras k\u00e4nda \"funktioner\": d\u00e4r kunde man arbeta med chunks p\u00e5 ett lite annat s\u00e4tt. Men sedan tog de bort det i n\u00e4sta version, och vi tvingades sluta f\u00f6rlita oss p\u00e5 den koden. Jag skulle rekommendera att anv\u00e4nda denna l\u00f6sning p\u00e5 m\u00e5nga setup:ar. Om du anv\u00e4nder MySQL\u2026 F\u00f6r medelstora setup:ar fungerar vilken l\u00f6sning som helst ganska bra.<\/p>\n<p><b>A:<\/b> \u2013 P\u00e5 de senaste graferna fr\u00e5n communityn fanns det en graf med \"Housekeeper\":<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" src=\"\/wp-content\/uploads\/2020\/01\/d01549b6b9b97d8bdf5372efe05d9039.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHan fortsatte att arbeta. Vad g\u00f6r \"Housekeeper\" i fallet med TimescaleDB?<\/p>\n<p><b>AG:<\/b> \u2013 Jag kan inte s\u00e4ga exakt just nu \u2013 jag ska kolla koden och ge en mer detaljerad f\u00f6rklaring. Han anv\u00e4nder f\u00f6rfr\u00e5gningar exakt fr\u00e5n TimescaleDB inte f\u00f6r att ta bort chunks, utan han aggregerar p\u00e5 n\u00e5got s\u00e4tt. Jag \u00e4r inte redo att svara p\u00e5 den tekniska fr\u00e5gan \u00e4n. Vi kommer att klarg\u00f6ra det p\u00e5 m\u00e4ssan idag eller imorgon.<\/p>\n<p><b>A:<\/b> \u2013 Jag har en liknande fr\u00e5ga \u2013 om prestandan vid borttagning av data i \"Timescale\".<br \/>\nA (svar fr\u00e5n publiken): \u2013 N\u00e4r du tar bort data fr\u00e5n tabellen, om du g\u00f6r det genom delete, s\u00e5 m\u00e5ste du g\u00e5 igenom tabellen \u2013 ta bort, rensa, m\u00e4rka allt f\u00f6r framtida vakuum. I \"Timescale\", eftersom du har chunks, kan du droppa. Rent konkret s\u00e4ger du bara till filen som ligger i big data: \"Ta bort!\"<\/p>\n<p>\"Timescale\" f\u00f6rst\u00e5r helt enkelt att den chunken inte l\u00e4ngre finns. Och eftersom den integreras i fr\u00e5geplaneraren f\u00e5ngar den upp dina villkor i select-satsen eller andra operationer och f\u00f6rst\u00e5r direkt att den chunken inte l\u00e4ngre existerar \u2013 \"Jag g\u00e5r inte dit l\u00e4ngre!\" (data saknas). S\u00e5 \u00e4r det! Det vill s\u00e4ga att tabellscanningen ers\u00e4tts med borttagning av en bin\u00e4r fil, vilket g\u00f6r det snabbt.<\/p>\n<p><b>A:<\/b> \u2013 Vi har redan ber\u00f6rt \u00e4mnet icke-SQL. S\u00e5vitt jag f\u00f6rst\u00e5r beh\u00f6ver \"Zabbix\" inte modifiera data s\u00e4rskilt mycket, utan allt detta \u00e4r n\u00e5got som ett logg. Kan man anv\u00e4nda specialiserade databaser som inte kan f\u00f6r\u00e4ndra sina data, men som samtidigt mycket snabbare lagrar, ackumulerar och ger \u2013 Clickhouse, till exempel n\u00e5got kafkaliknande? .. Kafka \u00e4r ju ocks\u00e5 en logg! Kan de integreras p\u00e5 n\u00e5got s\u00e4tt?<\/p>\n<p><b>AG:<\/b> \u2013 Export kan g\u00f6ras. Vi har en viss \"funktion\" fr\u00e5n version 3.4: du kan skriva alla historiska filer, h\u00e4ndelser och allt annat till filer; och sedan skickar du det med n\u00e5gon typ av processor till vilken annan databas som helst. Faktiskt \u00e4r det m\u00e5nga som g\u00f6r om det och skriver direkt till databasen. \u00d6gonblickligt skriver histori-synkronisatorerna allt detta till filer, roterar dessa filer med mera, och detta kan du \u00f6verf\u00f6ra till \"Clickhouse\". Jag kan inte s\u00e4ga n\u00e5got om planerna, men det \u00e4r m\u00f6jligt att vidare st\u00f6d f\u00f6r NoSQL-l\u00f6sningar (som \"Clickhouse\") kommer att forts\u00e4tta.<\/p>\n<p><b>A:<\/b> \u2013 S\u00e5 det g\u00e5r verkligen att helt bli av med PostgreSQL?<\/p>\n<p><b>AG:<\/b> \u2013 Sj\u00e4lvklart, den mest utmanande delen i \"Zabbix\" \u00e4r historiska tabeller som skapar flest problem, och h\u00e4ndelser. I det h\u00e4r fallet, om du inte lagrar h\u00e4ndelser f\u00f6r l\u00e4nge och ist\u00e4llet lagrar historik med trender i n\u00e5got annat snabbt lagringsutrymme, s\u00e5 b\u00f6r det inte bli n\u00e5gra problem, tror jag.<\/p>\n<p><b>A:<\/b> \u2013 Kan du uppskatta hur mycket snabbare allt skulle fungera om man g\u00e5r \u00f6ver till \"ClickHouse\", till exempel?<\/p>\n<p><b>AG:<\/b> \u2013 Jag har inte testat. Jag tror att man \u00e5tminstone kan n\u00e5 samma siffror ganska enkelt, med tanke p\u00e5 att \"ClickHouse\" har sitt eget gr\u00e4nssnitt, men kan inte s\u00e4ga det definitivt. B\u00e4ttre att testa. Det beror helt p\u00e5 konfigurationen: hur m\u00e5nga v\u00e4rdar ni har och s\u00e5 vidare. Inf\u00f6rsel \u00e4r en sak, men man m\u00e5ste ocks\u00e5 h\u00e4mta dessa data \u2013 med Grafana eller n\u00e5got annat.<\/p>\n<p><b>A:<\/b> \u2013 S\u00e5 det handlar om en j\u00e4mlik kamp, inte ett stort \u00f6vertag hos dessa snabba databaser?<\/p>\n<p><b>AG:<\/b> \u2013 Jag tror att vi n\u00e4r vi integrerar kommer att f\u00e5 mer exakta tester.<\/p>\n<p><b>A:<\/b> \u2013 Men vart tog den gamla goda RRD v\u00e4gen? Vad fick er att g\u00e5 \u00f6ver till SQL-databaser? Ursprungligen samlades ju alla metrik i RRD.<\/p>\n<p><b>AG:<\/b> \u2013 I \"Zabbix\" fanns RRD kanske i en mycket gammal version. Det har alltid funnits SQL-databaser \u2013 den klassiska metoden. Den klassiska metoden \u00e4r MySQL, PostgreSQL (som faktiskt funnits l\u00e4nge nu). Vi har ett gemensamt gr\u00e4nssnitt f\u00f6r SQL-databaser och RRD har vi knappt anv\u00e4nt.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushin (Zabbix): h\u00f6g prestanda och inbyggd partitionering\" 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=\"Spela video\" 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>Lite reklam \ud83d\ude42<\/h3>\n<p>\nTack f\u00f6r att ni stannar kvar hos oss. Gillar ni v\u00e5ra artiklar? Vill ni se fler intressanta material? St\u00f6d oss genom att g\u00f6ra en best\u00e4llning eller rekommendera oss till era v\u00e4nner, <noindex><a rel=\"nofollow\" href=\"https:\/\/ua-hosting.company\/cloudvps\/nl\">moln-VPS f\u00f6r utvecklare fr\u00e5n $4,99<\/a><\/noindex>, <b>en unik motsvarighet till entry-level servrar som vi har skapat f\u00f6r er:<\/b> <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/ua-hosting\/blog\/347386\/\">Allt om VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps fr\u00e5n $19 eller hur man korrekt delar en server?<\/a><\/noindex> (alternativ med RAID1 och RAID10 finns tillg\u00e4ngliga, upp till 24 k\u00e4rnor och upp till 40GB DDR4).<\/p>\n<p><b>Dell R730xd \u00e4r tv\u00e5 g\u00e5nger billigare i datacentret Equinix Tier IV i Amsterdam?<\/b> Bara hos oss <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 100TB fr\u00e5n $199<\/a><\/noindex> i Nederl\u00e4nderna! <b>Dell R420 \u2014 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB \u2014 fr\u00e5n $99!<\/b><\/b> L\u00e4s om <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/ua-hosting\/blog\/329618\/\">Hur man bygger en f\u00f6retagsinfrastruktur med Dell R730xd E5-2650 v4-servrar som kostar 9000 euro f\u00f6r en br\u00e5kdel?<\/a><\/noindex><br \/>\n<br \/>K\u00e4lla: <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.4 - 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\/sv\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"sv_SE\" \/>\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\/sv\/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++, Andrey Gushchin (Zabbix): h\u00f6g prestanda och inbyggd partitionering | ProHoster","description":"Vi kommer att titta p\u00e5 hur Zabbix fungerar med TimescaleDB som backend. Vi visar hur man startar fr\u00e5n grunden och hur man migrerar fr\u00e5n PostgreSQL.","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","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\/sv\/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\/sv\/wp-json\/wp\/v2\/posts\/55734","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=55734"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/55734\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=55734"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=55734"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=55734"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}