{"id":36737,"date":"2019-10-31T22:13:29","date_gmt":"2019-10-31T19:13:29","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-my-testirovali-neskolko-baz-dannyh-vremennyh-ryadov\/"},"modified":"2019-10-31T22:13:29","modified_gmt":"2019-10-31T19:13:29","slug":"kak-my-testirovali-neskolko-baz-dannyh-vremennyh-ryadov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/kak-my-testirovali-neskolko-baz-dannyh-vremennyh-ryadov","title":{"rendered":"Como testamos v\u00e1rios bancos de dados de s\u00e9ries temporais","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Como testamos v\u00e1rios bancos de dados de s\u00e9ries temporais\" src=\"\/wp-content\/uploads\/2019\/08\/14e07eac02df8d1276c46c33276d8a26.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNos \u00faltimos anos, os bancos de dados de s\u00e9ries temporais transformaram-se de algo ex\u00f3tico (aplic\u00e1vel de forma espec\u00edfica em sistemas de monitoramento abertos ou ligados a solu\u00e7\u00f5es concretas, ou em projetos de Big Data) em um \"produto de consumo popular\". No territ\u00f3rio da R\u00fassia, devemos um agradecimento especial ao Yandex e ao ClickHouse por isso. At\u00e9 aquele momento, se voc\u00ea precisava armazenar uma grande quantidade de dados de s\u00e9ries temporais, tinha que se conformar com a necessidade de configurar um monstruoso stack Hadoop e mant\u00ea-lo ou se comunicar com protocolos espec\u00edficos para cada sistema. <\/p>\n<p>Pode parecer que em 2019 um artigo sobre qual TSDB usar consistiria apenas em uma frase: \"simplesmente use ClickHouse\". Mas... h\u00e1 nuances. <\/p>\n<p>De fato, o ClickHouse est\u00e1 em constante evolu\u00e7\u00e3o, a base de usu\u00e1rios est\u00e1 crescendo e o suporte \u00e9 muito ativo, mas n\u00e3o ter\u00edamos nos tornado ref\u00e9ns do sucesso p\u00fablico do ClickHouse, que ofuscou outras solu\u00e7\u00f5es que podem ser mais eficazes\/fi\u00e1veis? <\/p>\n<p>No in\u00edcio do ano passado, come\u00e7amos a reformular nosso pr\u00f3prio sistema de monitoramento, durante o qual surgiu a quest\u00e3o da escolha do banco de dados adequado para armazenamento de dados. Quero contar a hist\u00f3ria dessa escolha aqui.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h4>Formula\u00e7\u00e3o do problema<\/h4>\n<p>\nPrimeiramente \u2014 uma introdu\u00e7\u00e3o necess\u00e1ria. Por que precisamos de um sistema de monitoramento pr\u00f3prio e como ele estava estruturado?<\/p>\n<p>Come\u00e7amos a oferecer servi\u00e7os de suporte em 2008, e em 2010 ficou claro que agregar dados sobre os processos na infraestrutura dos clientes usando solu\u00e7\u00f5es que existiam na \u00e9poca se tornou dif\u00edcil (falamos, perdoe-me, de Cacti, Zabbix e do emergente Graphite).<\/p>\n<p>Nossos principais requisitos foram:<\/p>\n<ul>\n<li>suporte (naquele momento \u2014 dezenas, e no futuro \u2014 centenas) de clientes dentro de um \u00fanico sistema e, ao mesmo tempo, ter um sistema centralizado de gerenciamento de notifica\u00e7\u00f5es;<\/li>\n<li>flexibilidade na gest\u00e3o do sistema de notifica\u00e7\u00f5es (escalonamento de notifica\u00e7\u00f5es entre operadores, acompanhamento de cronogramas, base de conhecimento);<\/li>\n<li>capacidade de detalhamento profundo dos gr\u00e1ficos (o Zabbix naquela \u00e9poca gerava gr\u00e1ficos na forma de imagens);<\/li>\n<li>armazenamento prolongado de grandes volumes de dados (um ano ou mais) e a possibilidade de recupera\u00e7\u00e3o r\u00e1pida desses dados.<\/li>\n<\/ul>\n<p>\nNeste artigo, estamos interessados no \u00faltimo ponto.<\/p>\n<p>Falando sobre armazenamento, os requisitos eram os seguintes:<\/p>\n<ul>\n<li>o sistema deve funcionar rapidamente;<\/li>\n<li>\u00e9 desej\u00e1vel que o sistema tenha uma interface SQL;<\/li>\n<li>o sistema deve ser est\u00e1vel e ter uma base de usu\u00e1rios ativa e suporte (em algum momento, nos deparamos com a necessidade de manter sistemas como o MemcacheDB, que deixou de ser desenvolvido, ou o armazenamento distribu\u00eddo MooseFS, cujo rastreador de bugs era mantido em chin\u00eas: n\u00e3o quer\u00edamos repetir essa hist\u00f3ria para o nosso projeto);<\/li>\n<li>conformidade com o teorema CAP: Consist\u00eancia (necess\u00e1rio) \u2014 os dados devem estar atualizados, n\u00e3o queremos que o sistema de gerenciamento de alertas n\u00e3o receba novos dados e acabe disparando alertas sobre a falta de dados em todos os projetos; Toler\u00e2ncia a Particionamento (necess\u00e1rio) \u2014 n\u00e3o queremos ter um sistema com Brain Dividido; Disponibilidade (n\u00e3o cr\u00edtico, em caso de uma r\u00e9plica ativa) \u2014 podemos n\u00f3s mesmos mudar para o sistema de backup em caso de falha, via c\u00f3digo.<\/li>\n<\/ul>\n<p>\nCuriosamente, na \u00e9poca, a solu\u00e7\u00e3o ideal para n\u00f3s foi o MySQL. Nossa estrutura de dados era extremamente simples: id do servidor, id do contador, timestamp e valor; a r\u00e1pida consulta de dados quentes era garantida por um grande tamanho de pool de buffer, e a consulta de dados hist\u00f3ricos \u2014 por SSD.<\/p>\n<p><img decoding=\"async\" alt=\"Como testamos v\u00e1rios bancos de dados de s\u00e9ries temporais\" src=\"\/wp-content\/uploads\/2019\/08\/555bff26c74badf85131c4d9198871af.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDessa forma, conseguimos consultar dados frescos de duas semanas, com detalhamento at\u00e9 o segundo, em 200 ms antes do momento da renderiza\u00e7\u00e3o completa dos dados, e vivemos nesse sistema por muito tempo.<\/p>\n<p>Entretanto, o tempo passou e a quantidade de dados cresceu. At\u00e9 2016, os volumes de dados atingiram dezenas de terabytes, o que era um custo significativo em condi\u00e7\u00f5es de armazenamento SSD alugado.<\/p>\n<p>Nesse momento, os bancos de dados colunares come\u00e7aram a se disseminar ativamente, e come\u00e7amos a pensar frequentemente sobre eles: nos bancos de dados colunares, os dados s\u00e3o armazenados, como se pode entender, em colunas, e se olharmos para nossos dados, \u00e9 f\u00e1cil ver um grande n\u00famero de duplicatas que poderiam, no caso de usarmos um banco de dados columnar, ser comprimidas.<\/p>\n<p><img decoding=\"async\" alt=\"Como testamos v\u00e1rios bancos de dados de s\u00e9ries temporais\" src=\"\/wp-content\/uploads\/2019\/08\/2e1a6010fcb09de8cd28ec826752d160.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNo entanto, o sistema central para o funcionamento da empresa continuava a operar de forma est\u00e1vel, e n\u00e3o quer\u00edamos arriscar a transi\u00e7\u00e3o para algo diferente.<\/p>\n<p>Em 2017, na confer\u00eancia Percona Live em San Jose, os desenvolvedores do Clickhouse fizeram sua primeira grande apari\u00e7\u00e3o. \u00c0 primeira vista, o sistema estava pronto para produ\u00e7\u00e3o (afinal, Yandex.Metrica \u00e9 um ambiente de produ\u00e7\u00e3o rigoroso), o suporte era r\u00e1pido e simples, e, o mais importante, a opera\u00e7\u00e3o era f\u00e1cil. Desde 2018, come\u00e7amos o processo de migra\u00e7\u00e3o. Mas naquele momento, havia muitas sistemas TSDB 'maduras' e testadas ao longo do tempo, e decidimos dedicar tempo significativo para comparar alternativas, a fim de garantir que n\u00e3o havia solu\u00e7\u00f5es alternativas ao Clickhouse que atendessem \u00e0s nossas necessidades.<\/p>\n<p>Al\u00e9m dos requisitos j\u00e1 mencionados para o armazenamento, surgiram novos:<\/p>\n<ul>\n<li>o novo sistema deve oferecer, no m\u00ednimo, o mesmo desempenho que o MySQL, com a mesma quantidade de hardware;<\/li>\n<li>o armazenamento do novo sistema deve ocupar significativamente menos espa\u00e7o;<\/li>\n<li>o SGBD ainda deve ser f\u00e1cil de gerenciar;<\/li>\n<li>gostaria de mudar o aplicativo o m\u00ednimo poss\u00edvel ao trocar de SGBD.<\/li>\n<\/ul>\n<p><\/p>\n<h4>Quais sistemas come\u00e7amos a considerar<\/h4>\n<p>\n<b><u>Apache Hive\/Apache Impala<\/u><\/b><br \/>\nUm stack Hadoop testado na pr\u00e1tica. Na ess\u00eancia, \u00e9 uma interface SQL constru\u00edda sobre a armazenagem de dados em seus pr\u00f3prios formatos no HDFS. <\/p>\n<p>Pr\u00f3s.<\/p>\n<ul>\n<li>Com uma opera\u00e7\u00e3o est\u00e1vel, \u00e9 muito f\u00e1cil escalar os dados.<\/li>\n<li>Existem solu\u00e7\u00f5es de armazenamento em colunas (menos espa\u00e7o).<\/li>\n<li>Execu\u00e7\u00e3o muito r\u00e1pida de tarefas paralelizadas quando h\u00e1 recursos dispon\u00edveis.<\/li>\n<\/ul>\n<p>\nContras.<\/p>\n<ul>\n<li>\u00c9 Hadoop, e \u00e9 complexo para opera\u00e7\u00e3o. Se n\u00e3o estamos prontos para optar por uma solu\u00e7\u00e3o pronta na nuvem (e n\u00e3o estamos prontos devido ao custo), todo o stack ter\u00e1 que ser montado e mantido manualmente pelos administradores, o que \u00e9 bastante indesejado.<\/li>\n<li>Os dados s\u00e3o agregados <noindex><a rel=\"nofollow\" href=\"https:\/\/www.percona.com\/blog\/2014\/04\/21\/using-apache-hadoop-and-impala-together-with-mysql-for-data-analysis\/\">realmente r\u00e1pido<\/a><\/noindex>.<\/li>\n<\/ul>\n<p>\nNo entanto:<\/p>\n<p><img decoding=\"async\" alt=\"Como testamos v\u00e1rios bancos de dados de s\u00e9ries temporais\" src=\"\/wp-content\/uploads\/2019\/08\/6baa1b6024def8c1c7518ef386cfc8d3.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA velocidade \u00e9 alcan\u00e7ada escalando o n\u00famero de servidores computacionais. Em outras palavras, se somos uma grande empresa, lidando com an\u00e1lises e \u00e9 cr\u00edtico para o neg\u00f3cio agregar informa\u00e7\u00f5es o mais r\u00e1pido poss\u00edvel (mesmo que isso custe o uso de muitos recursos computacionais), isso pode ser a nossa escolha. Mas n\u00e3o est\u00e1vamos prontos para aumentar significativamente nossa infraestrutura de hardware para acelerar a execu\u00e7\u00e3o das tarefas.<\/p>\n<p><b><u>Druid\/Pinot<\/u><\/b><\/p>\n<p>J\u00e1 temos muito mais sobre especificamente TSDB, mas novamente \u2014 stack Hadoop.<\/p>\n<p>H\u00e1 <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/@leventov\/comparison-of-the-open-source-olap-systems-for-big-data-clickhouse-druid-and-pinot-8e042a5ed1c7\">um excelente artigo comparando pr\u00f3s e contras do Druid e do Pinot em rela\u00e7\u00e3o ao ClickHouse <\/a><\/noindex>. <\/p>\n<p>Se em poucas palavras: Druid\/Pinot parecem mais adequados que o ClickHouse em casos onde:<\/p>\n<ul>\n<li>Voc\u00ea possui um car\u00e1ter de dados heterog\u00eaneo (no nosso caso, estamos registrando apenas s\u00e9ries temporais de m\u00e9tricas de servidores, e, na verdade, isso \u00e9 uma \u00fanica tabela. Mas podem existir outros casos: s\u00e9ries temporais de equipamentos, s\u00e9ries temporais econ\u00f4micas etc. \u2014 cada uma com sua pr\u00f3pria estrutura, que precisa ser agregada e processada).<\/li>\n<li>Por outro lado, h\u00e1 uma grande quantidade desses dados.<\/li>\n<li>Tabelas e dados com s\u00e9ries temporais aparecem e desaparecem (ou seja, um conjunto de dados chega, \u00e9 analisado e deletado).<\/li>\n<li>N\u00e3o h\u00e1 um crit\u00e9rio claro pelo qual os dados podem ser particionados.<\/li>\n<\/ul>\n<p>\nEm casos opostos, o ClickHouse se destaca melhor, e este \u00e9 o nosso caso.<\/p>\n<p><b><u>ClickHouse<\/u><\/b><\/p>\n<ul>\n<li>Semelhante ao SQL.<\/li>\n<li>F\u00e1cil de gerenciar.<\/li>\n<li>As pessoas dizem que ele funciona.<\/li>\n<\/ul>\n<p>\nEst\u00e1 na lista curta de testes.<\/p>\n<p><b><u>InfluxDB<\/u><\/b><\/p>\n<p>Alternativa internacional ao ClickHouse. Entre as desvantagens: High Availability est\u00e1 presente apenas na vers\u00e3o comercial, mas \u00e9 preciso comparar.<\/p>\n<p>Est\u00e1 na lista curta de testes.<\/p>\n<p><b><u>Cassandra<\/u><\/b> <\/p>\n<p>Por um lado, sabemos que ele \u00e9 usado para armazenar s\u00e9ries temporais m\u00e9tricas por sistemas de monitoramento como, por exemplo, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.signalfx.com\/blog\/making-cassandra-perform-as-a-tsdb\/\">SignalFX<\/a><\/noindex> ou OkMeter. No entanto, h\u00e1 particularidades.<\/p>\n<p>Cassandra n\u00e3o \u00e9 um banco de dados colunar em seu entendimento tradicional. Ela se parece mais com um banco de dados de linha, mas em cada linha pode haver um n\u00famero diferente de colunas, o que facilita a organiza\u00e7\u00e3o da representa\u00e7\u00e3o em colunas. Nesse sentido, \u00e9 claro que com uma limita\u00e7\u00e3o de 2 bilh\u00f5es de colunas, \u00e9 poss\u00edvel armazenar alguns dados exatamente em colunas (como as mesmas s\u00e9ries temporais). Por exemplo, no MySQL existe uma limita\u00e7\u00e3o de 4096 colunas e \u00e9 f\u00e1cil encontrar um erro de c\u00f3digo 1117 se tentar fazer o mesmo.<\/p>\n<p>O mecanismo Cassandra \u00e9 voltado para armazenar grandes volumes de dados em um sistema distribu\u00eddo sem mestre, e na mencionada teoria CAP, Cassandra se destaca mais no AP, ou seja, na disponibilidade de dados e resist\u00eancia \u00e0 separa\u00e7\u00e3o de parti\u00e7\u00f5es. Assim, essa ferramenta pode ser ideal se for necess\u00e1rio apenas inserir dados nesse banco e ler deles raramente. Aqui, faz sentido usar Cassandra como um armazenamento 'frio'. Ou seja, como um local confi\u00e1vel e de longo prazo para armazenar grandes volumes de dados hist\u00f3ricos que s\u00e3o raramente necess\u00e1rios, mas que podem ser acessados quando necess\u00e1rio. No entanto, para uma vis\u00e3o completa, vamos test\u00e1-la tamb\u00e9m. Mas, como mencionei anteriormente, n\u00e3o h\u00e1 desejo de reescrever ativamente o c\u00f3digo para o banco de dados escolhido, portanto, vamos test\u00e1-la de forma algo limitada \u2014 sem adaptar a estrutura do banco \u00e0 especificidade do Cassandra.<\/p>\n<p><b><u>Prometheus<\/u><\/b><\/p>\n<p>E por curiosidade, decidimos testar o desempenho do storage Prometheus \u2014 apenas para entender se somos mais r\u00e1pidos do que as solu\u00e7\u00f5es atuais ou mais lentos e em que medida.<\/p>\n<h4>Metodologia e resultados do teste<\/h4>\n<p>\nAssim, testamos 5 bancos de dados nas seguintes 6 configura\u00e7\u00f5es: ClickHouse (1 n\u00f3), ClickHouse (tabela distribu\u00edda em 3 n\u00f3s), InfluxDB, Mysql 8, Cassandra (3 n\u00f3s) e Prometheus. O plano de teste \u00e9 o seguinte:<\/p>\n<ol>\n<li>importamos dados hist\u00f3ricos por uma semana (840 milh\u00f5es de valores por dia; 208 mil m\u00e9tricas);<\/li>\n<li>geramos carga de escrita (consideramos 6 modos de carga, veja abaixo);<\/li>\n<li>paralelamente \u00e0 escrita, periodicamente fazemos consultas, simulando as solicita\u00e7\u00f5es de um usu\u00e1rio que trabalha com gr\u00e1ficos. Para n\u00e3o complicar muito, escolhemos os dados de 10 m\u00e9tricas (justamente o n\u00famero de m\u00e9tricas no gr\u00e1fico de CPU) para a semana.<\/li>\n<\/ol>\n<p>\nGeramos carga, simulando o comportamento do agente de monitoramento que envia valores para cada m\u00e9trica a cada 15 segundos. Neste processo, estamos interessados em variar:<\/p>\n<ul>\n<li>o n\u00famero total de m\u00e9tricas em que os dados s\u00e3o gravados;<\/li>\n<li>o intervalo de envio de valores para uma m\u00e9trica;<\/li>\n<li>o tamanho do lote.<\/li>\n<\/ul>\n<p>\nSobre o tamanho do lote. Como quase todos os nossos bancos de dados em teste n\u00e3o recomendam cargas com inser\u00e7\u00f5es \u00fanicas, precisaremos de um relay que agrupe as m\u00e9tricas recebidas e as escreva no banco em inser\u00e7\u00f5es em lote.<\/p>\n<p>Al\u00e9m disso, para entender melhor como interpretar os dados obtidos, vamos imaginar que n\u00e3o estamos apenas enviando uma quantidade de m\u00e9tricas, mas que as m\u00e9tricas est\u00e3o organizadas em servidores \u2014 125 m\u00e9tricas por servidor. Aqui, o servidor \u00e9 apenas uma entidade virtual \u2014 apenas para entender que, por exemplo, 10.000 m\u00e9tricas correspondem a aproximadamente 80 servidores.<\/p>\n<p>E assim, levando tudo isso em considera\u00e7\u00e3o, nossos 6 modos de carga do banco de dados para grava\u00e7\u00e3o:<\/p>\n<p><img decoding=\"async\" alt=\"Como testamos v\u00e1rios bancos de dados de s\u00e9ries temporais\" src=\"\/wp-content\/uploads\/2019\/08\/3ba70050dc7e711cb8f3d14ac1a6707b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAqui temos dois pontos. Primeiro, para o Cassandra, esses tamanhos de lotes se provaram grandes demais; l\u00e1 usamos valores de 50 ou 100. Em segundo lugar, uma vez que o Prometheus opera estritamente no modo pull, ou seja, ele mesmo coleta dados das fontes de m\u00e9tricas (e at\u00e9 o pushgateway, apesar do nome, n\u00e3o altera a situa\u00e7\u00e3o), as cargas correspondentes foram implementadas por meio de uma combina\u00e7\u00e3o de configura\u00e7\u00f5es est\u00e1ticas.<\/p>\n<p>Os resultados dos testes s\u00e3o os seguintes:<\/p>\n<p><img decoding=\"async\" alt=\"Como testamos v\u00e1rios bancos de dados de s\u00e9ries temporais\" src=\"\/wp-content\/uploads\/2019\/08\/9df12bee66ad8c5df720ba08472efead.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Como testamos v\u00e1rios bancos de dados de s\u00e9ries temporais\" src=\"\/wp-content\/uploads\/2019\/08\/891090bf0461c7e3c48e38eb36f9e217.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Como testamos v\u00e1rios bancos de dados de s\u00e9ries temporais\" src=\"\/wp-content\/uploads\/2019\/08\/137f944b3578ab5bad4ebc5fa6f96b79.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>O que vale a pena destacar<\/b>: sele\u00e7\u00f5es fant\u00e1sticas do Prometheus, sele\u00e7\u00f5es horrivelmente lentas do Cassandra e sele\u00e7\u00f5es inaceitavelmente lentas do InfluxDB; em termos de velocidade de escrita, o ClickHouse venceu em todos os aspectos, e o Prometheus n\u00e3o participa da competi\u00e7\u00e3o, pois faz inser\u00e7\u00f5es internamente e nada \u00e9 medido.<\/p>\n<p><u><b>Como resultado,<\/b><\/u>: ClickHouse e InfluxDB se destacaram melhor, mas um cluster do Influx s\u00f3 pode ser constru\u00eddo com a vers\u00e3o Enterprise, que tem custo, enquanto o ClickHouse \u00e9 gratuito e desenvolvido na R\u00fassia. Faz sentido que nos EUA a escolha provavelmente seja pelo InfluxDB, enquanto aqui \u00e9 pelo ClickHouse.<br \/>\n<br \/>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/462111\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0417\u0430 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0435 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043b\u0435\u0442 \u0431\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445 \u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u0445 \u0440\u044f\u0434\u043e\u0432 (Time-series databases) \u043f\u0440\u0435\u0432\u0440\u0430\u0442\u0438\u043b\u0438\u0441\u044c \u0438\u0437 \u0434\u0438\u043a\u043e\u0432\u0438\u043d\u043d\u043e\u0439 \u0448\u0442\u0443\u043a\u0438 (\u0443\u0437\u043a\u043e\u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e \u043f\u0440\u0438\u043c\u0435\u043d\u044f\u044e\u0449\u0435\u0439\u0441\u044f \u043b\u0438\u0431\u043e \u0432 \u043e\u0442\u043a\u0440\u044b\u0442\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c\u0430\u0445 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 (\u0438 \u043f\u0440\u0438\u0432\u044f\u0437\u0430\u043d\u043d\u043e\u0439 \u043a \u043a\u043e\u043d\u043a\u0440\u0435\u0442\u043d\u044b\u043c \u0440\u0435\u0448\u0435\u043d\u0438\u044f\u043c), \u043b\u0438\u0431\u043e \u0432 Big Data \u043f\u0440\u043e\u0435\u043a\u0442\u0430\u0445) \u0432 \u00ab\u0442\u043e\u0432\u0430\u0440 \u043d\u0430\u0440\u043e\u0434\u043d\u043e\u0433\u043e \u043f\u043e\u0442\u0440\u0435\u0431\u043b\u0435\u043d\u0438\u044f\u00bb. \u041d\u0430 \u0442\u0435\u0440\u0440\u0438\u0442\u043e\u0440\u0438\u0438 \u0420\u0424 \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u043e\u0435 \u0441\u043f\u0430\u0441\u0438\u0431\u043e \u0437\u0430 \u044d\u0442\u043e \u043d\u0430\u0434\u043e \u0441\u043a\u0430\u0437\u0430\u0442\u044c \u042f\u043d\u0434\u0435\u043a\u0441\u0443 \u0438 ClickHouse\u2019\u0443. \u0414\u043e \u044d\u0442\u043e\u0433\u043e \u043c\u043e\u043c\u0435\u043d\u0442\u0430, \u0435\u0441\u043b\u0438 \u0432\u0430\u043c \u0431\u044b\u043b\u043e \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u043e \u0441\u043e\u0445\u0440\u0430\u043d\u0438\u0442\u044c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27518,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-36737","post","type-post","status-publish","format-standard","has-post-thumbnail","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=\"\u0417\u0430 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0435 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043b\u0435\u0442 \u0431\u0430\u0437\u044b.\" \/>\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\/kak-my-testirovali-neskolko-baz-dannyh-vremennyh-ryadov\" \/>\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\udd47\u041a\u0430\u043a \u043c\u044b \u0442\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u043b\u0438 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445 \u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u0445 \u0440\u044f\u0434\u043e\u0432 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0417\u0430 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0435 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043b\u0435\u0442 \u0431\u0430\u0437\u044b.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/kak-my-testirovali-neskolko-baz-dannyh-vremennyh-ryadov\" \/>\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=\"2019-10-31T19:13:29+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:13:29+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\udd47 Como testamos v\u00e1rios bancos de dados de s\u00e9ries temporais | ProHoster","description":"Nos \u00faltimos anos, bancos de dados.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/kak-my-testirovali-neskolko-baz-dannyh-vremennyh-ryadov","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\udd47\u041a\u0430\u043a \u043c\u044b \u0442\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u043b\u0438 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445 \u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u0445 \u0440\u044f\u0434\u043e\u0432 | ProHoster","og:description":"\u0417\u0430 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0435 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043b\u0435\u0442 \u0431\u0430\u0437\u044b.","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/kak-my-testirovali-neskolko-baz-dannyh-vremennyh-ryadov","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":"2019-10-31T19:13:29+00:00","article:modified_time":"2019-10-31T19:13:29+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"36737","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":"2026-01-22 04:38:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:39:24","updated":"2026-01-22 04:38:20","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\/36737","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=36737"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/36737\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/27518"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=36737"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=36737"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=36737"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}