{"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\/pt\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","title":{"rendered":"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Vamos examinar o funcionamento do Zabbix com o banco de dados TimescaleDB como backend. Vamos mostrar como configurar do zero e como migrar do PostgreSQL. Tamb\u00e9m apresentaremos testes comparativos de desempenho de duas configura\u00e7\u00f5es.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/fb4f7ea4585b6dcdafec9d0d1e3a71e4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHighLoad++ Sib\u00e9ria 2019. Sala \"Tomsk\". 24 de junho, 16:00. Resumos e <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/siberia\/2019\/abstracts\/5390\">apresenta\u00e7\u00e3o<\/a><\/noindex>. A pr\u00f3xima confer\u00eancia HighLoad++ ocorrer\u00e1 nos dias 6 e 7 de abril de 2020 em S\u00e3o Petersburgo. Detalhes e ingressos <noindex><a rel=\"nofollow\" href=\"http:\/\/bit.ly\/2sSxgBx\">no link<\/a><\/noindex>.<\/p>\n<p><b>Andrei Gushchin (daqui em diante \u2013 AG):<\/b> \u2013 Eu sou engenheiro de suporte t\u00e9cnico do ZABBIX (daqui em diante \u2013 \"Zabbix\"), treinador. Trabalho h\u00e1 mais de 6 anos no suporte t\u00e9cnico e j\u00e1 enfrentei quest\u00f5es de desempenho. Hoje, vou falar sobre o desempenho que o TimescaleDB pode oferecer em compara\u00e7\u00e3o com o PostgreSQL 10. Tamb\u00e9m farei uma introdu\u00e7\u00e3o sobre como isso funciona.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Os principais desafios de desempenho: da coleta \u00e0 limpeza de dados<\/h3>\n<p>\nCome\u00e7aremos com o fato de que existem certos desafios de desempenho que cada sistema de monitoramento enfrenta. O primeiro desafio de desempenho \u00e9 a coleta e processamento r\u00e1pidos de dados.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/a2cb78b549a55c3b59d7fcdb8b8865b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUm bom sistema de monitoramento deve receber todos os dados de forma \u00e1gil, process\u00e1-los de acordo com express\u00f5es de gatilho, ou seja, process\u00e1-los com base em certos crit\u00e9rios (que variam de sistema para sistema) e armazen\u00e1-los em um banco de dados, para que esses dados possam ser utilizados posteriormente.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/a3ce55c3aec3eb93948150684838a5b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nO segundo desafio de desempenho \u00e9 o armazenamento hist\u00f3rico. \u00c9 preciso armazenar dados no banco de dados e ter acesso r\u00e1pido e conveniente a essas m\u00e9tricas que foram coletadas em um determinado per\u00edodo de tempo. O mais importante \u00e9 que esses dados sejam f\u00e1ceis de obter e possam ser utilizados em relat\u00f3rios, gr\u00e1ficos, gatilhos, em certos valores de limite, para notifica\u00e7\u00f5es, etc.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/325363d79f0270d620f956eeb8ab3402.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nO terceiro desafio de desempenho \u00e9 a limpeza do hist\u00f3rico, ou seja, quando chega o dia em que voc\u00ea n\u00e3o precisa mais armazenar certas m\u00e9tricas detalhadas que foram coletadas durante 5 anos (ou at\u00e9 mesmo meses ou dois meses). Alguns n\u00f3s de rede foram removidos, ou alguns hosts, m\u00e9tricas que j\u00e1 n\u00e3o s\u00e3o mais necess\u00e1rias porque se tornaram obsoletas e deixaram de ser coletadas. Isso tudo precisa ser limpo para que seu banco de dados n\u00e3o cres\u00e7a de forma descontrolada. E, geralmente, a limpeza do hist\u00f3rico costuma ser um teste s\u00e9rio para o armazenamento \u2013 muitas vezes afeta consideravelmente o desempenho.<\/p>\n<h3>Como resolver problemas de cache?<\/h3>\n<p>\nAgora vou falar especificamente sobre o Zabbix. No Zabbix, as primeiras e segundas chamadas s\u00e3o resolvidas por meio de cache.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/d5510b31553ee8e63a0c240789d51622.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nColeta e processamento de dados \u2013 usamos a mem\u00f3ria RAM para armazenar todos esses dados. Agora falaremos mais sobre esses dados.<\/p>\n<p>Al\u00e9m disso, do lado do banco de dados, h\u00e1 um certo cache para as principais consultas \u2013 para gr\u00e1ficos e outras coisas.<\/p>\n<p>Cache do lado do pr\u00f3prio servidor Zabbix: temos ConfigurationCache, ValueCache, HistoryCache, TrendsCache. O que \u00e9 isso?<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/241a131145eccd280a7411c43b2cdce4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nConfigurationCache \u2013 este \u00e9 o cache principal, onde armazenamos m\u00e9tricas, hosts, itens de dados, gatilhos; tudo o que \u00e9 necess\u00e1rio para o processamento, coleta de dados, de quais hosts coletar e com que frequ\u00eancia. Tudo isso \u00e9 mantido no ConfigurationCache para n\u00e3o ter que acessar o banco de dados e evitar consultas desnecess\u00e1rias. Ap\u00f3s a inicializa\u00e7\u00e3o do servidor, atualizamos esse cache (criamos) e o atualizamos periodicamente (dependendo das configura\u00e7\u00f5es).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/474ac0db2e46aa945a0da62197f72987.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Cache no Zabbix. Coleta de dados<\/h3>\n<p>\nAqui o esquema \u00e9 bastante extenso:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/a6ad9dbd5deebac5440433a47c693fcf.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOs principais no esquema s\u00e3o os seguintes coletores:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/feb932586302e2284bd44595caf9ee1b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEsses s\u00e3o os pr\u00f3prios processos de coleta, diferentes 'pollers', que s\u00e3o respons\u00e1veis por diferentes tipos de coleta. Eles re\u00fanem dados via ICMP, IPMI, por diferentes protocolos e transmitem tudo para o pr\u00e9-processamento.<\/p>\n<h3>PreProcessing HistoryCache<\/h3>\n<p>\nAl\u00e9m disso, se tivermos itens de dados calculados (quem conhece o Zabbix sabe), ou seja, itens de dados agregados, coletamos diretamente do ValueCache. Vou falar sobre como ele \u00e9 preenchido mais tarde. Todos esses coletores utilizam o ConfigurationCache para obter suas tarefas e depois passam para o pr\u00e9-processamento.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/3948ee1167c52856949c25e2043be974.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nO pr\u00e9-processamento tamb\u00e9m usa o ConfigurationCache para obter as etapas de pr\u00e9-processamento, processando esses dados de v\u00e1rias maneiras. A partir da vers\u00e3o 4.2, isso foi transferido para o proxy. Isso \u00e9 muito conveniente, pois o pr\u00f3prio pr\u00e9-processamento \u00e9 uma opera\u00e7\u00e3o bastante pesada. E se voc\u00ea tiver um Zabbix muito grande, com muitos itens de dados e alta frequ\u00eancia de coleta, isso facilita bastante o trabalho.<\/p>\n<p>Consequentemente, depois de processarmos esses dados de alguma forma por meio do pr\u00e9-processamento, salvamos no HistoryCache para que possam ser processados posteriormente. Aqui termina a coleta de dados. Passamos para o processo principal.<\/p>\n<h3>Opera\u00e7\u00e3o do History syncer<\/h3>\n<p>\n<img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/66539e4184d041ed84f797080226ba24.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nO processo principal no \u00abZabbix\u00bb (j\u00e1 que \u00e9 uma arquitetura monol\u00edtica) \u00e9 o History syncer. Este \u00e9 o processo principal que cuida do processamento at\u00f4mico de cada elemento de dados, ou seja, de cada valor:<\/p>\n<ul>\n<li>recebe um valor (ele o obt\u00e9m do HistoryCache);<\/li>\n<li>verifica no Configuration syncer: se h\u00e1 algum gatilho para c\u00e1lculo \u2013 o calcula;<br \/>\nse houver \u2013 cria eventos, cria uma escalonamento para emitir um alerta, se necess\u00e1rio, conforme a configura\u00e7\u00e3o;<\/li>\n<li>grava os gatilhos para processamento e agrega\u00e7\u00e3o posterior; se voc\u00ea agrega pelos \u00faltimos hor\u00e1rios e assim por diante, esse valor \u00e9 armazenado no ValueCache, para n\u00e3o consultar a tabela de hist\u00f3rico; dessa forma, o ValueCache \u00e9 preenchido com os dados necess\u00e1rios para c\u00e1lculo dos gatilhos, elementos calcul\u00e1veis etc.;<\/li>\n<li>em seguida, o History syncer grava todos os dados no banco de dados;<\/li>\n<li>o banco de dados os grava no disco \u2013 neste ponto, o processo de processamento termina.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Bancos de dados. Cache<\/h3>\n<p>\nNo lado do banco de dados, quando voc\u00ea quer visualizar gr\u00e1ficos ou relat\u00f3rios sobre eventos, h\u00e1 v\u00e1rios caches. Mas neste relat\u00f3rio n\u00e3o falarei sobre eles.<\/p>\n<p>Para o MySQL, existe o Innodb_buffer_pool, al\u00e9m de uma s\u00e9rie de outros caches que tamb\u00e9m podem ser configurados.<br \/>\nMas estes s\u00e3o os principais:<\/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++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/925e7abb21cfaa2516ff2b33ab161dc0.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPara todos os bancos de dados, eu mencionei que existem certos caches que permitem manter na mem\u00f3ria aqueles dados que s\u00e3o frequentemente necess\u00e1rios para consultas. Eles t\u00eam suas pr\u00f3prias tecnologias para isso.<\/p>\n<h3>Sobre o desempenho do banco de dados<\/h3>\n<p>\nConsequentemente, existe um ambiente competitivo, ou seja, o servidor \u00abZabbix\u00bb coleta dados e os grava. Ao reiniciar, ele tamb\u00e9m l\u00ea do hist\u00f3rico para preencher o ValueCache e assim por diante. Aqui voc\u00ea pode ter scripts e relat\u00f3rios que usam a API \u00abZabbix\u00bb, que \u00e9 constru\u00edda sobre a interface web. A API \u00abZabbix\u00bb entra no BD e obt\u00e9m os dados necess\u00e1rios para gerar gr\u00e1ficos, relat\u00f3rios ou algum tipo de lista de eventos, os problemas mais recentes.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/10a55cb1af660aace3172a572bea6692.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOutra solu\u00e7\u00e3o muito popular para visualiza\u00e7\u00e3o \u00e9 o Grafana, que nossos usu\u00e1rios utilizam. Ele pode se conectar diretamente tanto atrav\u00e9s da API \u00abZabbix\u00bb quanto atrav\u00e9s do banco de dados. Isso tamb\u00e9m cria uma certa concorr\u00eancia para obten\u00e7\u00e3o de dados: \u00e9 necess\u00e1ria uma configura\u00e7\u00e3o mais aprofundada e precisa do banco de dados para garantir uma resposta r\u00e1pida e testes.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/8a008e55dbee5635d386cec2fc1c40f5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Limpeza de hist\u00f3rico. No Zabbix, existe o Housekeeper<\/h3>\n<p>\nA terceira chamada que \u00e9 utilizada no 'Zabbix' \u00e9 a limpeza de hist\u00f3rico atrav\u00e9s do Housekeeper. O 'Housekeeper' respeita todas as configura\u00e7\u00f5es, ou seja, nos itens de dados est\u00e1 especificado quanto deve ser mantido (em dias), quanto manter os dados de tend\u00eancias e a din\u00e2mica das mudan\u00e7as.<\/p>\n<p>Eu n\u00e3o falei sobre o TrendCache, que calculamos em tempo real: os dados chegam, os agregamos por uma hora (principalmente s\u00e3o n\u00fameros da \u00faltima hora), a quantidade m\u00e9dia \/ m\u00ednima e gravamos isso uma vez por hora na tabela de din\u00e2mica de mudan\u00e7as ('Trends'). O 'Housekeeper' \u00e9 acionado e apaga os dados da DB atrav\u00e9s de selects comuns, o que nem sempre \u00e9 eficaz.<\/p>\n<p>Como entender que isso n\u00e3o \u00e9 eficiente? Voc\u00ea pode ver essa situa\u00e7\u00e3o nos gr\u00e1ficos de desempenho dos processos internos:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/f413ec989491d4186a05c779978e2f6d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nO seu History syncer est\u00e1 constantemente ocupado (gr\u00e1fico vermelho). E o gr\u00e1fico 'alaranjado', que vai por cima. Esse \u00e9 o 'Housekeeper', que \u00e9 acionado e espera da DB quando ela apagar\u00e1 todas as linhas que ele definiu.<\/p>\n<p>Vamos pegar algum Item ID: precisa apagar os \u00faltimos 5 mil; claro, pelos \u00edndices. Mas normalmente o dataset \u00e9 grande o suficiente \u2013 o banco de dados ainda l\u00ea isso do disco e carrega para o cache, e isso \u00e9 uma opera\u00e7\u00e3o muito cara para a DB. Dependendo do seu tamanho, isso pode causar certos problemas de desempenho.<\/p>\n<p>Desativar o 'Housekeeper' pode ser feito de uma maneira simples \u2013 temos a interface web familiar. A configura\u00e7\u00e3o em Administration general (configura\u00e7\u00f5es para o 'Housekeeper') desabilita a manuten\u00e7\u00e3o interna para o hist\u00f3rico e tend\u00eancias. Consequentemente, o 'Housekeeper' n\u00e3o gerencia mais isso:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/c9dc3ca86e7fd0c1229f6b9bc5d31270.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nO que se pode fazer a seguir? Voc\u00ea desativou, os seus gr\u00e1ficos se alinharam... Quais podem ser os problemas a partir de agora? O que pode ajudar?<\/p>\n<h3>Particionamento<\/h3>\n<p>\nGeralmente isso \u00e9 configurado em cada banco de dados relacional que mencionei, de v\u00e1rias maneiras. No MySQL h\u00e1 sua pr\u00f3pria tecnologia. Mas, em geral, s\u00e3o muito semelhantes ao falar sobre PostgreSQL 10 e MySQL. Claro, existem muitas diferen\u00e7as internas em como tudo isso \u00e9 implementado e como isso afeta o desempenho. Mas, de modo geral, a cria\u00e7\u00e3o de uma nova parti\u00e7\u00e3o tamb\u00e9m leva frequentemente a certos problemas.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/729114d61794314e19383f09ee9b5d61.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDependendo da sua configura\u00e7\u00e3o (quanto dado \u00e9 gerado por dia), geralmente estabelece-se o m\u00ednimo \u2013 que \u00e9 1 dia\/parti\u00e7\u00e3o, e para \"tend\u00eancias\", din\u00e2micas de mudan\u00e7as \u2013 1 m\u00eas\/nova parti\u00e7\u00e3o. Isso pode mudar se voc\u00ea tiver uma configura\u00e7\u00e3o muito grande.<\/p>\n<p>Deixe-me dizer sobre o tamanho da configura\u00e7\u00e3o: at\u00e9 5 mil novos valores por segundo (nvps) \u00e9 considerado uma \"pequena configura\u00e7\u00e3o\". M\u00e9dio \u2013 de 5 a 25 mil valores por segundo. Qualquer coisa acima disso j\u00e1 \u00e9 considerada uma instala\u00e7\u00e3o grande ou muito grande, que requer uma configura\u00e7\u00e3o muito cuidadosa do banco de dados.<\/p>\n<p>Em instala\u00e7\u00f5es muito grandes, 1 dia pode n\u00e3o ser ideal. Eu j\u00e1 vi parti\u00e7\u00f5es no MySQL de 40 gigabytes por dia (e maiores podem existir). Esse \u00e9 um volume de dados muito grande, que pode causar alguns problemas. \u00c9 preciso reduzi-lo.<\/p>\n<h3>Por que particionamento \u00e9 necess\u00e1rio?<\/h3>\n<p>\nO que o particionamento oferece, creio que todos sabem \u2013 \u00e9 a segmenta\u00e7\u00e3o de tabelas. Muitas vezes, s\u00e3o arquivos separados no disco e consultas span. Ele seleciona mais otimamente uma parti\u00e7\u00e3o, se isso faz parte do particionamento usual.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/4920fb3415733799f0a90b1bc7af0114.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPara o \u2018Zabbix\u2019, em particular, usa-se por faixa, ou seja, utilizamos timestamp (um n\u00famero comum, tempo desde o in\u00edcio da \u00e9poca). Voc\u00ea define o in\u00edcio do dia\/fim do dia, e isso se torna uma parti\u00e7\u00e3o. Assim, se voc\u00ea est\u00e1 requisitando dados de dois dias atr\u00e1s, tudo isso \u00e9 recuperado do banco de dados mais rapidamente, pois apenas um arquivo precisa ser carregado na cache e entregue (em vez de uma tabela grande).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/f5ee4e0b471eb5ebe701615aa617d66d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMuitos bancos de dados tamb\u00e9m aceleram inser\u00e7\u00f5es (inser\u00e7\u00f5es em uma child-table). Enquanto estou falando de maneira abstrata, isso tamb\u00e9m \u00e9 poss\u00edvel. O particionamento muitas vezes ajuda.<\/p>\n<h3>Elasticsearch para NoSQL<\/h3>\n<p>\nRecentemente, na vers\u00e3o 3.4, implementamos uma solu\u00e7\u00e3o para NoSQL. Adicionamos a capacidade de escrever no Elasticsearch. Voc\u00ea pode escrever tipos espec\u00edficos: escolher \u2013 ou escrever n\u00fameros ou alguns caracteres; temos string-texto, logs que voc\u00ea pode escrever no Elasticsearch\u2026 Assim, a interface da web tamb\u00e9m se comunicar\u00e1 com o Elasticsearch. Isso funciona muito bem em alguns casos, mas no momento, pode ser utilizado.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/24fe7d19c9e42474cd786ba59846c18c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>TimescaleDB. Hiper-tabelas<\/h3>\n<p>\nPara a vers\u00e3o 4.4.2, notamos uma coisa sobre o TimescaleDB. O que \u00e9 isso? \u00c9 uma extens\u00e3o para o PostgreSQL, ou seja, possui uma interface nativa do PostgreSQL. Al\u00e9m disso, essa extens\u00e3o permite trabalhar de forma muito mais eficiente com dados de s\u00e9ries temporais e tem particionamento autom\u00e1tico. Como isso se parece:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/de921f06453476215b6240ab9da6fae1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEste \u00e9 um hypertable \u2013 existe esse conceito no Timescale. \u00c9 uma hipertabela que voc\u00ea cria, e nela existem chunks. Chunks s\u00e3o parti\u00e7\u00f5es, s\u00e3o tabelas filhas, se n\u00e3o me engano. Isso realmente \u00e9 eficiente.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/719eb3f5d8c9f57544dfc4010850610c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>TimescaleDB e PostgreSQL<\/h3>\n<p>\nComo afirmam os desenvolvedores do TimescaleDB, eles utilizam um algoritmo mais correto para processamento de consultas, especialmente para inserts, que permite ter um desempenho aproximadamente constante \u00e0 medida que o tamanho do conjunto de dados aumenta. Ou seja, ap\u00f3s 200 milh\u00f5es de linhas, o PostgreSQL normal come\u00e7a a cair muito e perde desempenho praticamente a zero, enquanto o Timescale permite que inserts sejam feitos de forma mais eficiente independentemente da quantidade de dados.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/a613d505a9dfe6008551ce981da7b24e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Como instalar o TimescaleDB? \u00c9 simples!<\/h3>\n<p>\nTem na documenta\u00e7\u00e3o deles, est\u00e1 descrito \u2013 voc\u00ea pode instalar a partir de pacotes para qualquer\u2026 Ele depende dos pacotes oficiais do PostgreSQL. Voc\u00ea pode compilar manualmente. Aconteceu que tive que compilar para o banco de dados.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/6767927fa92260103d318f9aa70ef5b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNo Zabbix, n\u00f3s simplesmente ativamos a Extens\u00e3o. Eu acho que aqueles que usaram a Extens\u00e3o no PostgreSQL... Voc\u00ea simplesmente a ativa, cria-a para o banco de dados Zabbix que voc\u00ea usa.<\/p>\n<p>E o \u00faltimo passo...<\/p>\n<h3>TimescaleDB. Migra\u00e7\u00e3o de tabelas de hist\u00f3rico<\/h3>\n<p>\nVoc\u00ea precisa criar um hypertable. Para isso, h\u00e1 uma fun\u00e7\u00e3o especial \u2013 Create hypertable. Nela, o primeiro par\u00e2metro \u00e9 a tabela que precisa ser criada nesta base de dados (para a qual o hypertable deve ser criado).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/47350f79fd9829c12685c1df8f0ff9a6.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nO campo pelo qual deve ser criado e chunk_time_interval (que \u00e9 o intervalo dos chunks (parti\u00e7\u00f5es que devem ser utilizadas). 86 400 \u2013 \u00e9 um dia. <\/p>\n<p>O par\u00e2metro migrate_data: se voc\u00ea definir como true, isso move todos os dados atuais para os chunks criados anteriormente.<\/p>\n<p>Eu mesmo usei migrate_data \u2013 isso leva um bom tempo, dependendo do tamanho do seu banco de dados. Eu tinha mais de um terabyte \u2013 a cria\u00e7\u00e3o levou mais de uma hora. Em alguns casos, durante os testes, eu exclu\u00ed dados hist\u00f3ricos para texto (history_text) e string (history_str), para n\u00e3o os transferir \u2013 eles realmente n\u00e3o me interessavam.<\/p>\n<p>E a \u00faltima atualiza\u00e7\u00e3o que fazemos em nossa db_extention: instalamos o timescaledb para que o banco de dados e, em particular, nosso \"Zabbix\", entendesse que h\u00e1 uma db_extention. Ele a ativa e utiliza corretamente a sintaxe e as consultas ao banco de dados, usando j\u00e1 os \"recursos\" necess\u00e1rios para o TimescaleDB.<\/p>\n<h3>Configura\u00e7\u00e3o do servidor<\/h3>\n<p>\nUtilizei dois servidores. O primeiro servidor \u00e9 uma m\u00e1quina virtual bastante pequena, com 20 processadores e 16 gigabytes de mem\u00f3ria RAM. Configurei nele o \"PostgreSQL\" 10.8:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/990805374a2380a5c645c578404489bd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nO sistema operacional era Debian, e o sistema de arquivos \u2013 xfs. Fiz configura\u00e7\u00f5es m\u00ednimas para usar exatamente este banco de dados, al\u00e9m do que ser\u00e1 utilizado pelo pr\u00f3prio \"Zabbix\". Neste mesmo computador, estavam o servidor \"Zabbix\", o PostgreSQL e os agentes de carga.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/a6efa9ab9cd58f0061d04f13fe31018c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUsei 50 agentes ativos, que utilizam o LoadableModule para gerar rapidamente v\u00e1rios resultados. Eles geraram linhas, n\u00fameros e assim por diante. Eu preenchia o banco de dados com uma grande quantidade de dados. Inicialmente, a configura\u00e7\u00e3o continha 5 mil elementos de dados por host, e aproximadamente cada elemento de dados continha um gatilho \u2013 para que isso fosse uma configura\u00e7\u00e3o real. \u00c0s vezes, para uso, \u00e9 necess\u00e1rio mais de um gatilho.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/d5a3c306402e08bf2532eb6203a4aab4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nRegulava o intervalo de atualiza\u00e7\u00e3o e a carga, n\u00e3o apenas usando os 50 agentes (acrescentava mais), mas tamb\u00e9m com a ajuda de elementos de dados din\u00e2micos e reduzia o intervalo de atualiza\u00e7\u00e3o para 4 segundos.<\/p>\n<h3>Teste de desempenho. PostgreSQL: 36 mil NVPs<\/h3>\n<p>\nA primeira execu\u00e7\u00e3o, a primeira configura\u00e7\u00e3o foi feita em um PostgreSQL 10 limpo neste hardware (35 mil valores por segundo). No geral, como pode ser visto na tela, a inser\u00e7\u00e3o de dados leva fra\u00e7\u00f5es de segundo \u2013 tudo bem e r\u00e1pido, discos SSD (200 gigabytes). A \u00fanica coisa \u00e9 que 20 GB se preenchem rapidamente.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/6803a64fedd26093b9117a036d2993ae.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHaver\u00e1 muitos desses gr\u00e1ficos. Este \u00e9 o dashboard padr\u00e3o de desempenho do servidor \"Zabbix\".<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/081cc11c6bf42db3f8f16b6cc4e6ee0c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nO primeiro gr\u00e1fico \u2013 n\u00famero de valores por segundo (azul, na parte superior esquerda), 35 mil valores neste caso. Este (na parte superior central) \u00e9 a carga dos processos de coleta, e este (na parte superior direita) \u2013 a carga dos processos internos: history syncers e housekeeper, que aqui (na parte inferior central) foi executado por bastante tempo.<\/p>\n<p>Este gr\u00e1fico (na parte inferior central) mostra o uso do ValueCache - quantas consultas do ValueCache para gatilhos (v\u00e1rios milhares de valores por segundo). Um gr\u00e1fico importante tamb\u00e9m \u00e9 o quarto (na parte inferior esquerda), que mostra o uso do HistoryCache, sobre o qual falei, que \u00e9 um buffer antes da inser\u00e7\u00e3o no BD.<\/p>\n<h3>Teste de desempenho. PostgreSQL: 50 mil NVPs<\/h3>\n<p>\nEm seguida, aumentei a carga para 50 mil valores por segundo neste mesmo hardware. Ao carregar pelo 'Housekeeper', 10 mil valores eram gravados em 2-3 segundos com o processamento. Isso est\u00e1, na verdade, mostrado na pr\u00f3xima captura de tela:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/80824da986dbee2f8d5ebe0ead4fbcfd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nO 'Housekeeper' j\u00e1 come\u00e7a a interferir no trabalho, mas, no geral, a carga dos trapper history-syncers ainda est\u00e1 em torno de 60% (terceiro gr\u00e1fico, no canto superior direito). O HistoryCache come\u00e7ou a ser preenchido ativamente mesmo durante a opera\u00e7\u00e3o do 'Housekeeper' (na parte inferior esquerda). Ele estava em cerca de meio gigabyte, preenchendo-se em 20%.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/9e1bcd4f3b9f3e8a1c9a36b2083ec61b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Teste de desempenho. PostgreSQL: 80 mil NVPs<\/h3>\n<p>\nDepois, aumentei para 80 mil valores por segundo:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/13ae1589d6b9d35b4dda9c6c7d989cc2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEram cerca de 400 mil elementos de dados, 280 mil gatilhos. A inser\u00e7\u00e3o, como voc\u00ea pode ver, pela carga dos history-syncers (eram 30) j\u00e1 estava bastante alta. Em seguida, aumentei v\u00e1rios par\u00e2metros: history-syncers, cache\u2026 Neste hardware, a carga dos history-syncers come\u00e7ou a aumentar at\u00e9 o m\u00e1ximo, praticamente 'estagnando' - consequentemente, o HistoryCache entrou em uma carga muito alta:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/0ec528256c8fa7b16e1c7c95c8119535.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTodo esse tempo, observei todos os par\u00e2metros do sistema (como o processador \u00e9 utilizado, a mem\u00f3ria RAM) e descobri que a utiliza\u00e7\u00e3o dos discos estava no m\u00e1ximo - alcancei a capacidade m\u00e1xima desse disco neste hardware, nesta m\u00e1quina virtual. O 'Postgres' come\u00e7ou, com tal intensidade, a descartar dados de forma bastante ativa, e o disco j\u00e1 n\u00e3o conseguia acompanhar a grava\u00e7\u00e3o, leitura\u2026<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/0809dbd7638e7ee003ea24c611984a0c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPeguei outro servidor, que j\u00e1 tinha 48 processadores e 128 gigabytes de mem\u00f3ria RAM:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/53410b502a4574aac5d40f1a2a6d3f42.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAl\u00e9m disso, eu o 'tunei' \u2013 instalei 60 history syncers e alcancei um desempenho aceit\u00e1vel. De fato, n\u00e3o estamos 'estagnados', mas esse j\u00e1 deve ser o limite de desempenho, onde \u00e9 necess\u00e1rio tomar alguma atitude.<\/p>\n<h3>Teste de desempenho. TimescaleDB: 80 mil NVPs<\/h3>\n<p>\nMeu principal objetivo era usar TimescaleDB. Em cada gr\u00e1fico, \u00e9 vis\u00edvel uma queda:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/b0064068895a34b93b5aa6771aba05cb.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEsses desvios s\u00e3o exatamente a migra\u00e7\u00e3o de dados. Ap\u00f3s isso, no servidor 'Zabbix', o perfil de carregamento dos history syncers, como voc\u00ea pode ver, mudou bastante. Ele permite inserir dados quase tr\u00eas vezes mais r\u00e1pido e usar menos HistoryCache \u2013 portanto, voc\u00ea receber\u00e1 os dados em tempo h\u00e1bil. Novamente, 80 mil valores por segundo \u2013 \u00e9 uma taxa bastante alta (claro, n\u00e3o para o 'Yandex'). No geral, \u00e9 uma configura\u00e7\u00e3o bastante robusta, com um servidor.<\/p>\n<h3>Teste de desempenho PostgreSQL: 120 mil NVPs<\/h3>\n<p>\nEm seguida, aumentei o n\u00famero de elementos de dados para meio milh\u00e3o e obtive um valor estimado de 125 mil por segundo:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/7d0cf2ef7c6691c1bbf4b90afd34e4bb.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nE obtive gr\u00e1ficos assim:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/9c09333a50e016921a8a5b70e00397a1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDe forma geral, esta \u00e9 uma configura\u00e7\u00e3o funcional, que pode operar por um per\u00edodo consider\u00e1vel. Mas como eu tinha um disco de apenas 1,5 terabyte, eu o consumi em poucos dias. O mais importante \u00e9 que, ao mesmo tempo, novas parti\u00e7\u00f5es estavam sendo criadas no TimescaleDB, e isso ocorria de forma completamente invis\u00edvel para o desempenho, o que n\u00e3o se pode dizer sobre o MySQL.<\/p>\n<p>Normalmente, as parti\u00e7\u00f5es s\u00e3o criadas durante a noite, pois isso bloqueia completamente a inser\u00e7\u00e3o e o trabalho com as tabelas, podendo levar \u00e0 degrada\u00e7\u00e3o do servi\u00e7o. Neste caso, isso n\u00e3o ocorreu! A principal tarefa era verificar as capacidades do TimescaleDB. O resultado foi: 120 mil valores por segundo.<\/p>\n<p>Tamb\u00e9m h\u00e1 exemplos na 'comunidade':<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/66aa6b1d4c559d12082e4d91b6a1ca10.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUma pessoa tamb\u00e9m ativou o TimescaleDB e a carga pelo uso de io.weight caiu no processador; e o uso de elementos de processos internos tamb\u00e9m diminuiu gra\u00e7as \u00e0 ativa\u00e7\u00e3o do TimescaleDB. E isso em discos normais, ou seja, em uma m\u00e1quina virtual comum com discos normais (n\u00e3o SSD)!<\/p>\n<p>Para algumas pequenas configura\u00e7\u00f5es que est\u00e3o limitadas pelo desempenho do disco, o TimescaleDB, na minha opini\u00e3o, \u00e9 uma solu\u00e7\u00e3o muito boa. Ele permitir\u00e1 continuar a operar bem antes de migrar para um hardware mais r\u00e1pido para o banco de dados.<\/p>\n<p>Convido todos voc\u00eas para os nossos eventos: Confer\u00eancia \u2013 em Moscovo, C\u00fapula \u2013 em Riga. Use nossos canais \u2013 'Telegram', f\u00f3rum, IRC. Se voc\u00ea tiver alguma d\u00favida \u2013 venha at\u00e9 n\u00f3s no balc\u00e3o, podemos conversar sobre tudo.<\/p>\n<h3>Perguntas da audi\u00eancia<\/h3>\n<p>\nPergunta da audi\u00eancia (daqui em diante \u2013 A): \u2013 Se o TimescaleDB \u00e9 t\u00e3o simples de configurar e oferece um aumento de desempenho t\u00e3o significativo, talvez deva ser utilizado como uma melhor pr\u00e1tica para configurar o 'Zabbix' com o 'PostgreSQL'? E existem alguma armadilhas ou desvantagens nessa solu\u00e7\u00e3o, ou, se eu decidi que vou usar 'Zabbix', posso simplesmente usar o 'PostgreSQL', instalar o 'Timescale' e usar sem me preocupar com problemas?<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/314845a019724806283a957b15d857cc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>AG:<\/b> \u2013 Sim, eu diria que \u00e9 uma boa recomenda\u00e7\u00e3o: usar o 'PostgreSQL' logo com a extens\u00e3o TimescaleDB. Como mencionei, h\u00e1 muitos relatos positivos, apesar de essa 'funcionalidade' ser experimental. Mas, de fato, os testes mostram que \u00e9 uma \u00f3tima solu\u00e7\u00e3o (com TimescaleDB), e eu acredito que ela continuar\u00e1 a evoluir! Estamos acompanhando como essa extens\u00e3o se desenvolve e faremos ajustes quando necess\u00e1rio.<\/p>\n<p>Durante o desenvolvimento, nos baseamos em uma de suas funcionalidades conhecidas: l\u00e1 voc\u00ea poderia trabalhar com chunks de forma um pouco diferente. Mas depois, eles removeram isso na pr\u00f3xima vers\u00e3o, e tivemos que deixar de lado aquele c\u00f3digo. Eu recomendaria usar essa solu\u00e7\u00e3o em muitas configura\u00e7\u00f5es. Se voc\u00ea est\u00e1 usando MySQL... Para configura\u00e7\u00f5es medianas, qualquer solu\u00e7\u00e3o funciona bem.<\/p>\n<p><b>A:<\/b> \u2013 Nos \u00faltimos gr\u00e1ficos, que s\u00e3o da comunidade, havia um gr\u00e1fico com o 'Housekeeper':<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/d01549b6b9b97d8bdf5372efe05d9039.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEle continuou funcionando. O que o 'Housekeeper' faz no caso do TimescaleDB?<\/p>\n<p><b>AG:<\/b> \u2013 N\u00e3o posso afirmar com certeza agora \u2013 vou olhar o c\u00f3digo e darei mais detalhes. Ele utiliza consultas do TimescaleDB n\u00e3o para remover chunks, mas de alguma forma agrega. Por enquanto, n\u00e3o estou preparado para responder essa quest\u00e3o t\u00e9cnica. No estande, hoje ou amanh\u00e3, esclareceremos.<\/p>\n<p><b>A:<\/b> \u2013 Eu tenho uma pergunta similar \u2013 sobre o desempenho da opera\u00e7\u00e3o de exclus\u00e3o no 'Timescale'.<br \/>\nA (resposta da audi\u00eancia): \u2013 Quando voc\u00ea exclui dados de uma tabela, se voc\u00ea faz isso atrav\u00e9s de delete, voc\u00ea precisa percorrer a tabela \u2013 excluir, limpar, marcar tudo para o futuro vacuum. No 'Timescale', como voc\u00ea tem chunks, voc\u00ea pode descart\u00e1-los. Grosso modo, voc\u00ea simplesmente diz ao arquivo, que est\u00e1 na big data: 'Excluir!'<\/p>\n<p>O \u00abTimescale\u00bb simplesmente entende que esse chunk n\u00e3o existe mais. E como ele se integra ao planejador de consultas, ele captura suas condi\u00e7\u00f5es no select ou em outras opera\u00e7\u00f5es e imediatamente compreende que esse chunk n\u00e3o existe mais \u2013 \u00abN\u00e3o vou mais l\u00e1!\u00bb (dados ausentes). E \u00e9 isso! Ou seja, a verifica\u00e7\u00e3o da tabela \u00e9 substitu\u00edda pela remo\u00e7\u00e3o do arquivo bin\u00e1rio, portanto \u00e9 r\u00e1pido.<\/p>\n<p><b>A:<\/b> \u2013 J\u00e1 tocamos no assunto de n\u00e3o SQL. Pelo que entendo, o \u00abZabbix\u00bb n\u00e3o precisa modificar muito os dados, e tudo isso \u00e9 algo como um log. \u00c9 poss\u00edvel usar bancos de dados especializados que n\u00e3o podem alterar seus dados, mas que s\u00e3o muito mais r\u00e1pidos ao salvar, acumular, entregar \u2013 Clickhouse, por exemplo, algo semelhante ao Kafka? \u2026 Kafka tamb\u00e9m \u00e9 um log! Podemos integr\u00e1-los de alguma forma?<\/p>\n<p><b>AG:<\/b> \u2013 A exporta\u00e7\u00e3o pode ser feita. Temos um certo recurso desde a vers\u00e3o 3.4: voc\u00ea pode escrever em arquivos todos os arquivos hist\u00f3ricos, eventos, tudo mais; e depois, com algum processador, enviar para qualquer outro banco de dados. Na verdade, muitos reescrevem e escrevem diretamente no banco de dados. Os history-syncers escrevem tudo isso em arquivos em tempo real, rotacionam esses arquivos e assim por diante, e voc\u00ea pode transferir para o \u00abClickhouse\u00bb. N\u00e3o posso comentar sobre planos, mas talvez o suporte futuro para solu\u00e7\u00f5es NoSQL (como \u00abClickhouse\u00bb) continue.<\/p>\n<p><b>A:<\/b> \u2013 Ou seja, \u00e9 poss\u00edvel se livrar completamente do PostgreSQL?<\/p>\n<p><b>AG:<\/b> \u2013 Claro, a parte mais dif\u00edcil no \u00abZabbix\u00bb s\u00e3o as tabelas hist\u00f3ricas, que causam mais problemas, e eventos. Nesse caso, se voc\u00ea n\u00e3o armazenar eventos por muito tempo e mantiver a hist\u00f3ria com tend\u00eancias em algum outro armazenamento r\u00e1pido, ent\u00e3o, em geral, n\u00e3o deve haver problemas.<\/p>\n<p><b>A:<\/b> \u2013 Voc\u00ea pode avaliar qu\u00e3o mais r\u00e1pido tudo funcionar\u00e1 se migrarmos para o \u00abClickhouse\u00bb, por exemplo?<\/p>\n<p><b>AG:<\/b> \u2013 Eu n\u00e3o testei. Acho que, pelo menos, os mesmos n\u00fameros podem ser alcan\u00e7ados bastante facilmente, considerando que o \u00abClickhouse\u00bb tem sua pr\u00f3pria interface, mas n\u00e3o posso afirmar com certeza. \u00c9 melhor fazer testes. Tudo depende da configura\u00e7\u00e3o: quantos hosts voc\u00ea tem e assim por diante. A inser\u00e7\u00e3o \u00e9 uma coisa, mas voc\u00ea tamb\u00e9m precisa recuperar esses dados \u2013 Grafana ou outro software.<\/p>\n<p><b>A:<\/b> \u2013 Ou seja, estamos falando de uma competi\u00e7\u00e3o justa, e n\u00e3o de uma grande vantagem desses bancos de dados r\u00e1pidos?<\/p>\n<p><b>AG:<\/b> \u2013 Acho que, quando integrarmos, teremos testes mais precisos.<\/p>\n<p><b>A:<\/b> \u2013 E onde foi parar o velho RRD? O que motivou a transi\u00e7\u00e3o para bancos de dados SQL? Inicialmente, todas as m\u00e9tricas eram coletadas em RRD.<\/p>\n<p><b>AG:<\/b> \u2013 No \u00abZabbix\u00bb, o RRD pode ter existido em uma vers\u00e3o muito antiga. Sempre houve bancos de dados SQL \u2013 essa \u00e9 a abordagem cl\u00e1ssica. A abordagem cl\u00e1ssica \u00e9 MySQL, PostgreSQL (j\u00e1 existem h\u00e1 muito tempo). Nosso interface era comum para bancos de dados SQL e raramente usamos RRD.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): alto desempenho e particionamento nativo\" 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=\"Por que no hosting comum a administra\u00e7\u00e3o do PrestaShop \u00e9 lenta, e no seu n\u00e3o \u00e9?\" 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>Um pouco de publicidade \ud83d\ude42<\/h3>\n<p>\nObrigado por permanecer conosco. Voc\u00ea gosta dos nossos artigos? Quer ver mais materiais interessantes? Apoie-nos fazendo um pedido ou recomendando para conhecidos. <noindex><a rel=\"nofollow\" href=\"https:\/\/ua-hosting.company\/cloudvps\/nl\">VPS em nuvem para desenvolvedores a partir de $4.99<\/a><\/noindex>, <b>uma alternativa \u00fanica aos servidores entry-level, que criamos para voc\u00ea:<\/b> <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/ua-hosting\/blog\/347386\/\">Toda a verdade sobre VPS (KVM) E5-2697 v3 (6 N\u00facleos) 10GB DDR4 480GB SSD 1Gbps a partir de $19 ou como dividir um servidor corretamente?<\/a><\/noindex> (dispon\u00edveis op\u00e7\u00f5es com RAID1 e RAID10, at\u00e9 24 n\u00facleos e at\u00e9 40GB DDR4).<\/p>\n<p><b>Dell R730xd por 2 vezes mais barato no datacenter Equinix Tier IV em Amsterd\u00e3?<\/b> Somente conosco <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 a partir de $199<\/a><\/noindex> na Holanda! <b>Dell R420 \u2014 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB \u2014 a partir de $99!<\/b><\/b> Leia sobre <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/ua-hosting\/blog\/329618\/\">Como construir uma infraestrutura de classe corporativa utilizando servidores Dell R730xd E5-2650 v4 com custo de 9000 euros por centavos?<\/a><\/noindex><br \/>\n<br \/>Fonte: <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.3 - 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\/pt\/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.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"pt_PT\" \/>\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\/pt\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-01-26T21:00:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-18T11:03:52+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47HighLoad++, Andrei Gushchin (Zabbix): alto desempenho e particionamento nativo | ProHoster","description":"Vamos explorar o funcionamento do Zabbix com o banco de dados TimescaleDB como backend. Mostraremos como iniciar do zero e como migrar do PostgreSQL.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","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\/pt\/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\/pt\/wp-json\/wp\/v2\/posts\/55734","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=55734"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/55734\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=55734"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=55734"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=55734"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}