HighLoad++ Moscou 2018, Salão de Congressos. 9 de novembro, 15h
Resumos e apresentação:
Yuri Nasretdinov (VKontakte): o relatório falará sobre a experiência de implementação do ClickHouse em nossa empresa - por que precisamos dele, quantos dados armazenamos, como os escrevemos e assim por diante.
Materiais adicionais:
Yuri Nasretdinov: - Olá a todos! Meu nome é Yuri Nasretdinov, pois já fui apresentado. Eu trabalho no VKontakte. Falarei sobre como inserimos dados de nossa frota de servidores (dezenas de milhares) no ClickHouse.
O que são logs e por que coletá-los?
O que vamos te contar: o que fizemos, por que precisávamos do “ClickHouse”, respectivamente, por que o escolhemos, que tipo de desempenho você pode obter aproximadamente sem configurar nada de especial. Falarei mais sobre tabelas de buffer, sobre os problemas que tivemos com elas e sobre nossas soluções que desenvolvemos a partir de código aberto - KittenHouse e Lighthouse.
Por que precisávamos fazer alguma coisa (tudo é sempre bom no VKontakte, certo?). Queríamos coletar logs de depuração (e havia centenas de terabytes de dados lá), talvez de alguma forma fosse mais conveniente calcular estatísticas; e temos uma frota de dezenas de milhares de servidores a partir dos quais tudo isso precisa ser feito.
Por que decidimos? Provavelmente tínhamos soluções para armazenar logs. Aqui – existe um “Backend VK” público. Eu recomendo fortemente assiná-lo.
O que são registros? Este é um mecanismo que retorna arrays vazios. Os motores no VK são o que outros chamam de microsserviços. E aqui está um adesivo sorridente (muitas curtidas). Como assim? Bem, ouça mais!
O que pode ser usado para armazenar logs? É impossível não mencionar Hadup. Depois, por exemplo, Rsyslog (armazenando esses logs em arquivos). LSD. Quem sabe o que é LSD? Não, não esse LSD. Armazene arquivos, respectivamente, também. Bem, ClickHouse é uma opção estranha.
Clickhouse e concorrentes: requisitos e oportunidades
O que queremos? Queremos garantir que não precisamos nos preocupar muito com o funcionamento, para que funcione imediatamente, de preferência com configuração mínima. Queremos escrever muito e escrever rápido. E queremos mantê-lo por todos os meses, anos, ou seja, por muito tempo. Podemos querer entender algum problema que eles vieram até nós e disseram: “Algo não está funcionando aqui”, e isso foi há 3 meses), e queremos ser capazes de ver o que aconteceu há 3 meses " Compressão de dados – é claro por que seria uma vantagem – porque reduz a quantidade de espaço que ocupa.
E temos um requisito tão interessante: às vezes escrevemos a saída de alguns comandos (por exemplo, logs), que pode facilmente ter mais de 4 kilobytes. E se isso funcionar em UDP, então não precisa gastar... não terá nenhum “overhead” para a conexão, e para um grande número de servidores isso será um plus.
Vamos ver o que o código aberto nos oferece. Em primeiro lugar, temos o Logs Engine - este é o nosso motor; Em princípio, ele pode fazer tudo, pode até escrever longas filas. Bem, ele não compacta dados de forma transparente - nós mesmos podemos compactar grandes colunas se quisermos... nós, é claro, não queremos (se possível). O único problema é que ele só pode dar o que cabe na sua memória; Para ler o resto, você precisa obter o binlog deste mecanismo e, portanto, leva bastante tempo.
Que outras opções existem? Por exemplo, "Hadup". Facilidade de operação... Quem acha que o Hadup é fácil de configurar? Claro, não há problemas com a gravação. Durante a leitura, às vezes surgem dúvidas. Em princípio, eu diria que provavelmente não, especialmente para logs. Armazenamento de longo prazo - claro, sim, compactação de dados - sim, strings longas - é claro que você pode gravar. Mas gravar de um grande número de servidores... Você ainda precisa fazer algo sozinho!
Rsyslog. Na verdade, nós o usamos como uma opção de backup para que pudéssemos lê-lo sem descartar o binlog, mas ele não pode escrever linhas longas; em princípio, não pode escrever mais de 4 kilobytes. Você mesmo deve fazer a compactação de dados da mesma maneira. A leitura virá de arquivos.
Depois, há o desenvolvimento “badushka” do LSD. Essencialmente igual ao “Rsyslog”: suporta strings longas, mas não funciona em UDP e, na verdade, por causa disso, infelizmente, há muita coisa que precisa ser reescrita. O LSD precisa ser redesenhado para poder gravar em dezenas de milhares de servidores.
E aqui! Uma opção engraçada é o ElasticSearch. Como dizer? Ele está indo bem na leitura, ou seja, lê rápido, mas não muito bem na escrita. Em primeiro lugar, se comprimir dados, é muito fraco. Muito provavelmente, uma pesquisa completa requer estruturas de dados maiores que o volume original. É difícil de operar e muitas vezes surgem problemas com ele. E, novamente, gravando no Elastic - temos que fazer tudo sozinhos.
Aqui o ClickHouse é a opção ideal, claro. A única coisa é que a gravação de dezenas de milhares de servidores é um problema. Mas pelo menos há um problema, podemos tentar resolvê-lo de alguma forma. E o resto do relatório é sobre esse problema. Que tipo de desempenho você pode esperar do ClickHouse?
Como vamos inseri-lo? Mesclar Árvore
Quem entre vocês nunca ouviu falar ou conhece “ClickHouse”? Preciso te contar, não é? Muito rápido. A inserção lá - 1-2 gigabits por segundo, rajadas de até 10 gigabits por segundo podem realmente suportar essa configuração - há dois Xeons de 6 núcleos (ou seja, nem mesmo os mais poderosos), 256 gigabytes de RAM, 20 terabytes em RAID (ninguém configurado, configurações padrão). Alexey Milovidov, desenvolvedor do ClickHouse, provavelmente está chorando porque não configuramos nada (tudo funcionou assim para nós). Conseqüentemente, uma velocidade de varredura de, digamos, cerca de 6 bilhões de linhas por segundo pode ser obtida se os dados forem bem compactados. Se você gosta de % em uma string de texto - 100 milhões de linhas por segundo, ou seja, parece bastante rápido.
Como vamos inseri-lo? Bem, você sabe que VK usa PHP. Iremos inserir de cada trabalhador PHP via HTTP em “ClickHouse”, na tabela MergeTree para cada registro. Quem vê problema neste esquema? Por alguma razão, nem todos levantaram a mão. Deixe-me dizer-lhe.
Em primeiro lugar, existem muitos servidores - portanto, haverá muitas conexões (ruins). Então é melhor inserir dados no MergeTree no máximo uma vez por segundo. E quem sabe por quê? Está bem, está bem. Vou contar um pouco mais sobre isso. Outra questão interessante é que não estamos fazendo análises, não precisamos enriquecer os dados, não precisamos de servidores intermediários, queremos inserir diretamente no “ClickHouse” (de preferência – quanto mais diretamente, melhor).
Além disso, como é feita a inserção no MergeTree? Por que é melhor inseri-lo no máximo uma vez por segundo ou com menos frequência? O fato é que “ClickHouse” é um banco de dados colunar e ordena os dados em ordem crescente da chave primária, e quando você faz uma inserção, é criado um número de arquivos pelo menos igual ao número de colunas em que os dados são ordenados em ordem crescente da chave primária (é criado um diretório separado, um conjunto de arquivos no disco para cada inserção). Então vem a próxima inserção e, no fundo, eles são combinados em “partições” maiores. Como os dados estão ordenados, é possível “mesclar” dois arquivos ordenados sem consumir muita memória.
Mas, como você pode imaginar, se você gravar 10 arquivos para cada inserção, o ClickHouse (ou seu servidor) terminará rapidamente, por isso é recomendável inserir em lotes grandes. Conseqüentemente, nunca lançamos o primeiro esquema em produção. Imediatamente lançamos um, que aqui é o número 2:
Imagine aqui que existem cerca de mil servidores nos quais lançamos, existe apenas PHP. E em cada servidor está nosso agente local, que chamamos de “Kittenhouse”, que mantém uma conexão com o “ClickHouse” e insere dados a cada poucos segundos. Insere dados não no MergeTree, mas em uma tabela de buffer, que serve justamente para evitar a inserção direta no MergeTree logo de cara.
Trabalhando com tabelas de buffer
O que é isso? As tabelas de buffer são um pedaço de memória fragmentado (ou seja, pode ser inserido nela com frequência). Eles consistem em várias peças, e cada uma das peças funciona como um buffer independente e são liberadas de forma independente (se você tiver muitas peças no buffer, haverá muitas inserções por segundo). É possível ler essas tabelas - então você lê a união do conteúdo do buffer e da tabela pai, mas neste momento a gravação está bloqueada, então é melhor não ler daí. E as tabelas de buffer apresentam QPS muito bons, ou seja, até 3 mil QPS você não terá nenhum problema na hora de inserir. É claro que se o servidor ficar sem energia, os dados podem ser perdidos, pois estavam armazenados apenas na memória.
Ao mesmo tempo, o esquema com buffer complica ALTER, porque primeiro você precisa descartar a tabela de buffer antiga com o esquema antigo (os dados não desaparecerão em lugar nenhum, porque serão liberados antes que a tabela seja excluída). Então você “altera” a tabela necessária e cria a tabela de buffer novamente. Conseqüentemente, embora não haja uma tabela de buffer, seus dados não fluirão para lugar nenhum, mas você poderá tê-los no disco, pelo menos localmente.
O que é Kittenhouse e como funciona?
O que é KittenHouse? Este é um proxy. Adivinhe qual idioma? Coletei os tópicos mais badalados em meu relatório - “Clickhouse”, vá, talvez me lembre de outra coisa. Sim, isso está escrito em Go, porque eu realmente não sei escrever em C, não quero.
Assim, ele mantém uma conexão com cada servidor e pode gravar na memória. Por exemplo, se escrevermos logs de erros no Clickhouse, se o Clickhouse não tiver tempo para inserir dados (afinal, se muitos forem gravados), não aumentaremos a memória - simplesmente descartaremos o resto. Porque se escrevermos vários gigabits por segundo de erros, provavelmente poderemos descartar alguns. A Kittenhouse pode fazer isso. Além disso, ele pode realizar uma entrega confiável, ou seja, gravar em disco na máquina local e uma vez por vez (lá, uma vez a cada dois segundos) tentar entregar dados desse arquivo. E a princípio usamos o formato Regular Values - não algum formato binário, um formato de texto (como no SQL normal).
Mas então isso aconteceu. Usamos entrega confiável, escrevemos logs e então decidimos (era um cluster de teste condicional)... Ele foi colocado no ar por várias horas e trazido de volta, e uma inserção começou a partir de mil servidores - descobriu-se que Clickhouse ainda tinha um “Thread on connection” - portanto, em mil conexões, uma inserção ativa leva a uma carga média no servidor de cerca de mil e quinhentos. Surpreendentemente, o servidor aceitou as solicitações, mas os dados ainda foram inseridos depois de algum tempo; mas foi muito difícil para o servidor atendê-lo...
Adicionar nginx
Essa solução para o modelo Thread por conexão é o nginx. Instalamos o nginx na frente do Clickhouse, ao mesmo tempo configuramos o balanceamento para duas réplicas (nossa velocidade de inserção aumentou 2 vezes, embora não seja fato que deva ser assim) e limitamos o número de conexões ao Clickhouse, ao upstream e, portanto, mais , do que em 50 conexões, parece que não faz sentido inserir.
Então percebemos que esse esquema geralmente tem desvantagens, pois temos apenas um nginx aqui. Assim, se este nginx travar, apesar da presença de réplicas, perderemos dados ou, pelo menos, não escreveremos em lugar nenhum. É por isso que fizemos nosso próprio balanceamento de carga. Também percebemos que “Clickhouse” ainda é adequado para logs, e o “demônio” também começou a escrever seus logs em “Clickhouse” - muito conveniente, para ser sincero. Ainda o usamos para outros “demônios”.
Então descobrimos este problema interessante: se você usar um método de inserção não padrão no modo SQL, ele forçará um analisador SQL completo baseado em AST, que é bastante lento. Conseqüentemente, adicionamos configurações para garantir que isso nunca aconteça. Fizemos balanceamento de carga, verificações de integridade, para que, se alguém morresse, ainda deixaríamos os dados. Agora temos muitas tabelas que precisamos para ter diferentes clusters Clickhouse. E também começamos a pensar em outros usos - por exemplo, queríamos escrever logs de módulos nginx, mas eles não sabem como se comunicar usando nosso RPC. Bem, eu gostaria de ensiná-los a enviar de alguma forma - por exemplo, receber eventos no localhost via UDP e depois encaminhá-los para Clickhouse.
A um passo da solução
O esquema final começou a ficar assim (a quarta versão deste esquema): em cada servidor na frente do Clickhouse existe o nginx (no mesmo servidor) e ele simplesmente faz proxy das solicitações para localhost com um limite no número de conexões de 50 peças. E esse esquema já estava funcionando bastante, estava tudo muito bem com ele.
Vivemos assim por cerca de um mês. Todos ficaram felizes, adicionaram tabelas, adicionaram, adicionaram... Em geral, descobriu-se que a forma como adicionamos tabelas de buffer não era muito ideal (vamos colocar dessa forma). Fizemos 16 peças em cada mesa e um intervalo de flash de alguns segundos; tínhamos 20 tabelas e cada tabela recebia 8 inserções por segundo - e nesse ponto começou o “Clickhouse”... os registros começaram a desacelerar. Não só eles não passaram... Por padrão, o nginx tinha uma coisa tão interessante que se as conexões terminassem no upstream, ele simplesmente retornava “502” para todas as novas solicitações.
E aqui temos (acabei de olhar os logs no próprio Clickhouse) cerca de meio por cento das solicitações falharam. Conseqüentemente, a utilização do disco foi alta e houve muitas fusões. Bem, o que eu fiz? Naturalmente, não me preocupei em descobrir por que exatamente a conexão e o upstream terminaram.
Substituindo o nginx por um proxy reverso
Decidi que precisamos gerenciar isso sozinhos, não precisamos deixar isso para o nginx - o nginx não sabe quais tabelas existem no Clickhouse e substituí o nginx por um proxy reverso, que também escrevi.
O que ele está fazendo? Funciona baseado na biblioteca fasthttp “goshnoy”, ou seja, rápido, quase tão rápido quanto o nginx. Desculpe, Igor, se você está presente aqui (nota: Igor Sysoev é um programador russo que criou o servidor web nginx). Ele pode entender que tipo de consultas são – INSERT ou SELECT – respectivamente, ele mantém diferentes conjuntos de conexões para diferentes tipos de consultas.
Dessa forma, mesmo que não tenhamos tempo para concluir as solicitações de inserção, os “selects” serão aprovados e vice-versa. E agrupa os dados em tabelas de buffer - com um buffer pequeno: se houver algum erro, erro de sintaxe e assim por diante - para que não afetem muito o restante dos dados, porque quando simplesmente inserimos em tabelas de buffer, nós tinha um "bachi" pequeno, e todos os erros de sintaxe só afectaram este pequeno pedaço; e aqui eles já afetarão um grande buffer. Pequeno é 1 megabyte, ou seja, não tão pequeno.
Inserir uma sincronização e essencialmente substituir o nginx faz essencialmente a mesma coisa que o nginx fazia antes - você não precisa alterar o “Kittenhouse” local para isso. E como usa fasthttp, é muito rápido - você pode fazer mais de 100 mil solicitações por segundo para inserções únicas por meio de um proxy reverso. Teoricamente, você pode inserir uma linha de cada vez no proxy reverso da Kittenhouse, mas é claro que não fazemos isso.
O esquema começou a ficar assim: “Kittenhouse”, o proxy reverso agrupa muitas solicitações em tabelas e, por sua vez, as tabelas buffer as inserem nas principais.
Killer é uma solução temporária, Kitten é permanente
Este é um problema interessante... Algum de vocês já usou o fasthttp? Quem usou fasthttp com solicitações POST? Provavelmente, isso realmente não deveria ter sido feito, porque armazena em buffer o corpo da solicitação por padrão e nosso tamanho de buffer foi definido como 16 megabytes. A inserção parou de acompanhar em algum momento, e pedaços de 16 megabytes começaram a chegar de todas as dezenas de milhares de servidores, e todos foram armazenados em buffer na memória antes de serem enviados para Clickhouse. Assim, a memória acabou, o Out-Of-Memory Killer veio e matou o proxy reverso (ou “Clickhouse”, que teoricamente poderia “comer” mais do que o proxy reverso). O ciclo se repetiu. Não é um problema muito agradável. Embora só tenhamos descoberto isso depois de vários meses de operação.
O que eu fiz? Novamente, eu realmente não gosto de entender o que exatamente aconteceu. Acho que é bastante óbvio que você não deve armazenar em buffer na memória. Não consegui corrigir o fasthttp, embora tenha tentado. Mas descobri uma maneira de fazer com que não houvesse necessidade de corrigir nada e criei meu próprio método em HTTP - chamei-o de KITTEN. Bem, é lógico - “VK”, “Kitten”... O que mais?..
Se uma solicitação chegar ao servidor com o método Kitten, o servidor deverá responder “miau” - logicamente. Se ele responder a isso, considera-se que ele entende esse protocolo, e então eu intercepto a conexão (o fasthttp possui esse método), e a conexão entra no modo “bruto”. Por que eu preciso disso? Quero controlar como acontece a leitura das conexões TCP. O TCP tem uma propriedade maravilhosa: se ninguém estiver lendo do outro lado, a gravação começará a esperar e a memória não será particularmente gasta nisso.
E então eu li cerca de 50 clientes por vez (de cinquenta porque cinquenta definitivamente deveria ser suficiente, mesmo que a tarifa venha de outro CD)... O consumo diminuiu com essa abordagem pelo menos 20 vezes, mas eu, para ser sincero , não consegui mensurar exatamente que horas, porque já é inútil (já atingiu o nível de erro). O protocolo é binário, ou seja, contém o nome da tabela e os dados; não há cabeçalhos http, então não usei um web socket (não preciso me comunicar com navegadores - criei um protocolo que atende às nossas necessidades). E tudo ficou bem com ele.
A tabela de buffer está triste
Recentemente nos deparamos com outro recurso interessante das tabelas de buffer. E esse problema já é muito mais doloroso que os outros. Vamos imaginar esta situação: você já usa ativamente o Clickhouse, tem dezenas de servidores Clickhouse e tem algumas solicitações que demoram muito para serem lidas (digamos, mais de 60 segundos); e você vem e faz Alter neste momento... Enquanto isso, “selects” que começaram antes de “Alter” não serão incluídos nesta tabela, “Alter” não será iniciado - provavelmente algumas características de como “Clickhouse” funciona em Esse lugar. Talvez isso possa ser consertado? Ou é impossível?
Em geral, é claro que na realidade isso não é um problema tão grande, mas com tabelas de buffer fica mais doloroso. Porque, se, digamos, o tempo limite do seu “Alter” atingir o tempo limite (e pode atingir o tempo limite em outro host - não no seu, mas em uma réplica, por exemplo), então... Você excluiu a tabela de buffer, seu “Alter” ( ou algum outro host) expirou. então ocorreu um erro “Alter”) - você ainda precisa garantir que os dados continuem sendo gravados: você cria as tabelas de buffer de volta (de acordo com o mesmo esquema da tabela pai), então “Alter” passa, afinal termina, e o buffer da tabela começa a diferir em esquema do pai. Dependendo de qual foi o “Alter”, o insert pode não ir mais para esta tabela de buffer – isso é muito triste.
Também existe esse sinal (talvez alguém tenha notado) - é chamado query_thread_log nas novas versões do Clickhouse. Por padrão, em alguma versão havia um. Aqui acumulamos 840 milhões de registros em alguns meses (100 gigabytes). Isso se deve ao fato de que ali foram escritos “inserções” (talvez agora, aliás, não estejam escritas). Como eu disse, nossas “inserções” são pequenas - tínhamos muitas “inserções” nas tabelas de buffer. É claro que isso está desabilitado - só estou contando o que vi em nosso servidor. Por que? Este é outro argumento contra o uso de tabelas buffer! Spotty está muito triste.
Quem diria que o nome desse cara era Spotty? Os funcionários da VK levantaram as mãos. OK.
Sobre os planos para “KitttenHouse”
Os planos geralmente não são compartilhados, certo? De repente, você não os cumprirá e não parecerá muito bem aos olhos das outras pessoas. Mas vou correr o risco! Queremos fazer o seguinte: parece-me que as tabelas de buffer ainda são uma muleta e precisamos armazenar nós mesmos a inserção. Mas ainda não queremos armazená-lo em buffer no disco, então armazenaremos a inserção em buffer na memória.
Assim, quando uma “inserção” for feita, ela não será mais síncrona - já funcionará como uma tabela de buffer, será inserida na tabela pai (bem, algum dia depois) e reportará através de um canal separado quais inserções passaram e quais não tem.
Por que não consigo sair da inserção síncrona? É muito mais conveniente. O fato é que se você inserir a partir de 10 mil hosts, então está tudo bem - você vai pegar um pouquinho de cada host, você insere ali uma vez por segundo, está tudo bem. Mas eu gostaria que esse esquema funcionasse, por exemplo, em duas máquinas, para que você possa fazer download em alta velocidade - talvez não tirar o máximo proveito do Clickhouse, mas gravar pelo menos 100 megabytes por segundo de uma máquina por meio de um proxy reverso - isso o esquema deve ser dimensionado para quantidades grandes e pequenas, portanto não podemos esperar um segundo para cada inserção, portanto deve ser assíncrono. E da mesma forma, as confirmações assíncronas devem vir após a conclusão da inserção. Saberemos se passou ou não.
O mais importante é que neste esquema saibamos com certeza se a inserção ocorreu ou não. Imagine esta situação: você tem uma tabela de buffer, escreveu algo nela e então, digamos, a tabela entrou no modo somente leitura e tentou liberar o buffer. Para onde irão os dados? Eles permanecerão no buffer. Mas não podemos ter certeza disso - e se houver algum outro erro, devido ao qual os dados não permanecerão no buffer... (Dirige-se a Alexey Milovidov, Yandex, desenvolvedor ClickHouse) Ou permanecerá? Sempre? Alexey nos convence de que tudo ficará bem. Não temos motivos para não acreditar nele. Mas mesmo assim: se não usarmos tabelas de buffer, não haverá problemas com elas. Criar o dobro de tabelas também é inconveniente, embora em princípio não haja grandes problemas. Este é o plano.
Vamos falar sobre leitura
Agora vamos falar sobre leitura. Também escrevemos nossa própria ferramenta aqui. Parece, bem, por que escrever seu próprio instrumento aqui?.. E quem usou o Tabix? De alguma forma, poucas pessoas levantaram a mão... E quem está satisfeito com o desempenho do Tabix? Bem, não estamos satisfeitos com isso e não é muito conveniente para visualizar dados. É bom para análises, mas apenas para visualização claramente não está otimizado. Então eu escrevi minha própria interface.
É muito simples – só pode ler dados. Ele não sabe mostrar gráficos, não sabe fazer nada. Mas pode mostrar o que precisamos: por exemplo, quantas linhas tem a tabela, quanto espaço ela ocupa (sem dividir em colunas), ou seja, uma interface bem básica é o que precisamos.
E é muito parecido com o Sequel Pro, mas feito apenas no Bootstrap do Twitter, e na segunda versão. Você pergunta: “Yuri, por que na segunda versão?” Que ano? 2018? Em geral, eu fiz isso há muito tempo para “Muscle” (MySQL) e apenas mudei algumas linhas nas consultas lá, e começou a funcionar para “Clickhouse”, pelo qual um agradecimento especial! Porque o analisador é muito semelhante ao “muscular” e as consultas são muito semelhantes - muito convenientes, especialmente no início.
Pois bem, ele pode filtrar tabelas, pode mostrar a estrutura e o conteúdo da tabela, permite ordenar, filtrar por colunas, mostra a consulta que resultou no resultado, as linhas afetadas (quantas como resultado), ou seja, o coisas básicas para visualizar dados. Muito rápido.
Há também um editor. Sinceramente, tentei roubar todo o editor do Tabix, mas não consegui. Mas de alguma forma funciona. Em princípio, isso é tudo.
"Clickhouse" é adequado para tocas
Quero dizer que Clickhouse, apesar de todos os problemas descritos, é muito adequado para logs. Mais importante ainda, resolve nosso problema - é muito rápido e permite filtrar logs por colunas. Em princípio, as tabelas de buffer não tiveram um bom desempenho, mas geralmente ninguém sabe por quê... Talvez agora você saiba melhor onde terá problemas.
TCP? Em geral, no VK costuma-se usar UDP. E quando usei TCP... Claro, ninguém me disse: “Yuri, do que você está falando! Você não pode, você precisa do UDP.” Acontece que o TCP não é tão assustador. A única coisa é que, se você tem dezenas de milhares de compostos ativos que escreve, precisa prepará-los com um pouco mais de cuidado; mas é possível e muito fácil.
Prometi postar “Kittenhouse” e “Lighthouse” no HighLoad Siberia se todos se inscrevessem em nosso “backend VK” público... E você sabe, nem todos se inscreveram... Claro, não vou exigir que você assine nosso público. Ainda são muitos de vocês, alguém pode até ficar ofendido, mas mesmo assim, inscreva-se (e aqui tenho que fazer olhos de gato). Isso é . Muito obrigado! Github é nosso . Com Clickhouse seus cabelos ficarão macios e sedosos.
Chumbo: - Amigos, agora para perguntas. Logo após apresentamos o certificado de agradecimento e sua reportagem em VHS.
Yuri Nasretdinov (doravante denominado YN): – Como você conseguiu gravar minha reportagem em VHS se ela acabou de terminar?
Chumbo: – Você também não pode determinar totalmente como “Clickhouse” funcionará ou não! Amigos, 5 minutos para perguntas!
perguntas
Pergunta do público (doravante denominada Q): - Boa tarde. Muito obrigado pelo relatório. Eu tenho duas perguntas. Vou começar com algo frívolo: o número de letras t no nome "Kittenhouse" nos diagramas (3, 4, 7...) afeta a satisfação dos gatos?
SIM: - Quantidade de quê?
Z: – Carta t. Existem três t's, algo em torno de três t's.
SIM: - Eu não consertei? Bem, claro que sim! São produtos diferentes - eu estava enganando você esse tempo todo. Ok, estou brincando - não importa. Ah, bem aqui! Não, é a mesma coisa, cometi um erro de digitação.
Z: - Obrigado. A segunda questão é séria. Pelo que entendi, no Clickhouse, as tabelas de buffer residem exclusivamente na memória, não são armazenadas em buffer no disco e, portanto, não são persistentes.
SIM: - Sim.
Z: – E ao mesmo tempo, o seu cliente armazena em buffer no disco, o que implica alguma garantia de entrega desses mesmos logs. Mas isso não é de forma alguma garantido na Clickhouse. Explique como é realizada a garantia, por quê?.. Aqui está esse mecanismo com mais detalhes
SIM: – Sim, teoricamente não há contradições aqui, porque quando o Clickhouse cai, você pode detectá-lo de um milhão de maneiras diferentes. Se o Clickhouse travar (se terminar incorretamente), você pode, grosso modo, retroceder um pouco do seu log que anotou e começar a partir do momento em que tudo estava exatamente bem. Digamos que você retroceda um minuto, ou seja, considera-se que você liberou tudo em um minuto.
Z: – Ou seja, “Kittenhouse” segura a janela por mais tempo e, em caso de queda, consegue reconhecê-la e rebobiná-la?
SIM: – Mas isso é em teoria. Na prática, não fazemos isso e a entrega confiável vai de zero a infinitas vezes. Mas em média um. Estamos convencidos de que se o Clickhouse travar por algum motivo ou os servidores “reiniciarem”, perderemos um pouco. Em todos os outros casos, nada acontecerá.
Z: - Olá. Desde o início, pareceu-me que você realmente usaria o UDP desde o início do relatório. Você tem http, tudo isso... E a maioria dos problemas que você descreveu, pelo que entendi, foram causados por esta solução específica...
SIM: – O que usamos TCP?
Z: - Essencialmente sim.
SIM: -Não.
Z: – Foi com o fasthttp que você teve problemas, com a conexão você teve problemas. Se você tivesse usado o UDP, você teria economizado algum tempo. Bem, haveria problemas com mensagens longas ou algo mais...
SIM: - Com o que?
Z: – Com mensagens longas, já que pode não caber no MTU, outra coisa... Bem, pode haver problemas próprios. A questão é: por que não o UDP?
SIM: – Acredito que os autores que desenvolveram o TCP/IP são muito mais espertos que eu e sabem melhor que eu como serializar pacotes (para que eles vão), ao mesmo tempo ajustar a janela de envio, não sobrecarregar a rede, dar feedback sobre o que não é lido, sem contar do outro lado... Todos esses problemas, na minha opinião, existiriam no UDP, só que eu teria que escrever ainda mais código do que já escrevi para implementar a mesma coisa sozinho e muito provavelmente mal. Eu nem gosto muito de escrever em C, muito menos aí...
Z: - Simplesmente conveniente! Enviado ok e não espere nada - é totalmente assíncrono. Chegou uma notificação de que estava tudo bem - isso significa que chegou; Se não vier, significa que é ruim.
SIM: – Preciso dos dois – preciso poder enviar os dois com garantia de entrega e sem garantia de entrega. Estes são dois cenários diferentes. Preciso não perder alguns logs ou não perdê-los dentro do razoável.
Z: – Não vou perder tempo. Isso precisa ser mais discutido. Obrigado.
Chumbo: – Quem tem dúvidas – mãos para o céu!
Z: - Olá, sou Sasha. Em algum lugar no meio do relatório, surgiu a sensação de que, além do TCP, era possível usar uma solução pronta - uma espécie de Kafka.
SIM: – Bem... eu te disse que não quero usar servidores intermediários, porque... no Kafka, acontece que temos dez mil hosts; na verdade, temos mais – dezenas de milhares de hosts. Também pode ser doloroso trabalhar com Kafka sem nenhum proxy. Além disso, o mais importante, ainda dá “latência”, dá hosts extras que você precisa ter. Mas eu não quero tê-los - eu quero...
Z: “Mas no final acabou assim de qualquer maneira.”
SIM: – Não, não há anfitriões! Tudo isso funciona em hosts Clickhouse.
Z: - Bom, e “Kittenhouse”, que é o contrário – onde ele mora?
SIM: – No host Clickhouse, ele não grava nada no disco.
Z: - Suponhamos.
Chumbo: - Você está satisfeito? Podemos te dar um salário?
Z: - Sim você pode. Na verdade, existem muitas muletas para se conseguir a mesma coisa, e agora - a resposta anterior sobre o tema TCP contradiz, na minha opinião, esta situação. Parece que tudo poderia ter sido feito de joelhos em muito menos tempo.
SIM: – E também porque não quis usar o Kafka, porque houve muitas reclamações no chat do Clickhouse Telegram de que, por exemplo, mensagens do Kafka foram perdidas. Não do próprio Kafka, mas na integração de Kafka e Clickhaus; ou algo não conectou lá. Grosso modo, seria então necessário escrever um cliente para Kafka. Não creio que possa haver uma solução mais simples ou mais confiável.
Z: – Me conta, por que você não tentou alguma fila ou algum tipo de ônibus comum? Já que você diz que com a assincronia você poderia enviar os próprios logs pela fila e receber a resposta de forma assíncrona pela fila?
SIM: – Por favor, sugira quais filas poderiam ser usadas?
Z: – Qualquer um, mesmo sem garantia de que estão em ordem. Algum tipo de Redis, RMQ...
SIM: – Tenho a sensação de que o Redis provavelmente não será capaz de extrair tal volume de inserção, mesmo em um host (no sentido de vários servidores) que extrai o Clickhouse. Não posso comprovar isso com nenhuma evidência (não fiz benchmarking), mas me parece que o Redis não é a melhor solução aqui. Em princípio, este sistema pode ser considerado como uma fila de mensagens improvisada, mas que é adaptada apenas para “Clickhouse”
Chumbo: – Yuri, muito obrigado. Proponho encerrar aqui as perguntas e respostas e dizer a qual dos que fizeram a pergunta daremos o livro.
SIM: – Gostaria de dar um livro para a primeira pessoa que fizer uma pergunta.
Chumbo: - Maravilhoso! Ótimo! Fabuloso! Muito obrigado!
Alguns anúncios 🙂
Obrigado por ficar com a gente. Gostou dos nossos artigos? Quer ver mais conteúdos interessantes? Apoie-nos fazendo um pedido ou recomendando a amigos, , um análogo exclusivo de servidores básicos, que foi inventado por nós para você: (disponível com RAID1 e RAID10, até 24 núcleos e até 40 GB DDR4).
Dell R730xd 2x mais barato no data center Equinix Tier IV em Amsterdã? Só aqui na Holanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de US$ 99! Ler sobre
Fonte: habr.com