a fun\u00e7\u00e3o da tabela input<\/a><\/noindex>.<\/p>\n<\/p>\n
<\/p>\n
Outro antipadr\u00e3o \u00e9 o microsharding. Por exemplo, voc\u00ea precisa shardizar seus dados e tem 5 servidores, mas amanh\u00e3 haver\u00e1 6 servidores. E voc\u00ea est\u00e1 pensando em como reequilibrar esses dados. Em vez disso, voc\u00ea divide n\u00e3o em 5 shards, mas em 1.000 shards. E depois mapeia cada um desses microshards para um servidor separado. Assim, em um servidor, voc\u00ea pode ter, por exemplo, 200 ClickHouse. Inst\u00e2ncias separadas em portas diferentes ou bancos de dados distintos. <\/p>\n
<\/p>\n
<\/p>\n
Mas no ClickHouse isso n\u00e3o \u00e9 muito bom. Porque at\u00e9 mesmo uma inst\u00e2ncia do ClickHouse tenta usar todos os recursos dispon\u00edveis do servidor para processar uma \u00fanica consulta. Ou seja, voc\u00ea tem um servidor e, por exemplo, 56 n\u00facleos de processador. Voc\u00ea executa uma consulta que leva um segundo e ela usar\u00e1 56 n\u00facleos. E se voc\u00ea tem 200 ClickHouse no mesmo servidor, surgir\u00e3o 10.000 threads. No geral, ser\u00e1 muito ruim.<\/p>\n
<\/p>\n
Outra raz\u00e3o \u00e9 que a distribui\u00e7\u00e3o do trabalho entre essas inst\u00e2ncias ser\u00e1 desigual. Alguma terminar\u00e1 antes, alguma terminar\u00e1 depois. Se tudo isso ocorresse em uma \u00fanica inst\u00e2ncia, o ClickHouse resolveria automaticamente como distribuir corretamente os dados entre os threads. <\/p>\n
<\/p>\n
E mais uma raz\u00e3o \u00e9 que voc\u00ea ter\u00e1 comunica\u00e7\u00e3o interprocessos via TCP. Os dados precisar\u00e3o ser serializados, desserializados e isso cria uma quantidade enorme de microshards. Ser\u00e1 simplesmente ineficiente.<\/p>\n
<\/p>\n
<\/p>\n
Outro antipadr\u00e3o, embora seja dif\u00edcil cham\u00e1-lo assim. \u00c9 a grande quantidade de pr\u00e9-agrega\u00e7\u00e3o.<\/p>\n
<\/p>\n
Na verdade, a pr\u00e9-agrega\u00e7\u00e3o \u00e9 boa. Tinha um bilh\u00e3o de linhas, voc\u00ea agregou e ficou com 1.000 linhas, e agora a consulta \u00e9 executada instantaneamente. Tudo \u00f3timo. Isso \u00e9 poss\u00edvel. E para isso, at\u00e9 mesmo no ClickHouse h\u00e1 um tipo especial de tabela, o AggregatingMergeTree, que faz a agrega\u00e7\u00e3o incremental \u00e0 medida que os dados s\u00e3o inseridos. <\/p>\n
<\/p>\n
Mas h\u00e1 casos em que voc\u00ea pensa que vamos agregar os dados dessa forma e ainda agregar os dados assim. E em algum departamento vizinho, que n\u00e3o quero mencionar, eles usam tabelas SummingMergeTree para somar por chave prim\u00e1ria, usando cerca de 20 colunas como chave prim\u00e1ria. Eu mudei os nomes de algumas colunas por precau\u00e7\u00e3o, mas \u00e9 mais ou menos assim que funciona.<\/p>\n
<\/p>\n
<\/p>\n
E surgem esses problemas. Primeiro, o volume de dados n\u00e3o diminui muito. Por exemplo, diminui em tr\u00eas vezes. Tr\u00eas vezes seria um bom pre\u00e7o para permitir-se oportunidades ilimitadas de an\u00e1lise, que surgem quando os dados n\u00e3o est\u00e3o agregados. Se os dados est\u00e3o agregados, voc\u00ea acaba recebendo apenas estat\u00edsticas med\u00edocres em vez de an\u00e1lises. <\/p>\n
<\/p>\n
E o que \u00e9 especialmente irritante? \u00c9 que essas pessoas do departamento vizinho v\u00eam e pedem para adicionar mais uma coluna \u00e0 chave prim\u00e1ria. Ou seja, agregamos os dados assim, mas agora queremos um pouco mais. Mas no ClickHouse n\u00e3o h\u00e1 como alterar a chave prim\u00e1ria. Portanto, \u00e9 preciso escrever alguns scripts em C++. E eu n\u00e3o gosto de scripts, mesmo que sejam em C++.<\/p>\n
<\/p>\n
E se voc\u00ea olhar para o motivo pelo qual o ClickHouse foi criado, dados n\u00e3o agregados s\u00e3o exatamente o cen\u00e1rio para o qual ele foi concebido. Se voc\u00ea est\u00e1 usando o ClickHouse para dados n\u00e3o agregados, voc\u00ea est\u00e1 fazendo tudo certo. Se voc\u00ea est\u00e1 agregando, isso \u00e0s vezes pode ser perdo\u00e1vel. <\/p>\n
<\/p>\n
<\/p>\n
Outro caso interessante s\u00e3o as consultas em um loop infinito. \u00c0s vezes, eu vou a algum servidor de produ\u00e7\u00e3o e olho l\u00e1 o show processlist. E a cada vez descubro que algo terr\u00edvel est\u00e1 acontecendo. <\/p>\n
<\/p>\n
Por exemplo, isso. Aqui j\u00e1 fica claro que poderia ser tudo executado em uma \u00fanica consulta. Basta escrever url in e a lista.<\/p>\n
<\/p>\n
<\/p>\n
Por que muitas dessas consultas em um loop infinito s\u00e3o ruins? Se o \u00edndice n\u00e3o for utilizado, voc\u00ea ter\u00e1 muitas passagens pelos mesmos dados. Mas se o \u00edndice for utilizado, por exemplo, se voc\u00ea tem uma chave prim\u00e1ria em ru e escreve url = algo assim. E voc\u00ea pensa que vai ler um \u00fanico url da tabela, tudo ficar\u00e1 normal. Mas, na verdade, n\u00e3o. Porque o ClickHouse faz tudo em pacotes. <\/p>\n
<\/p>\n
Quando \u00e9 necess\u00e1rio ler um intervalo de dados, l\u00ea-se um pouco mais, porque o \u00edndice no ClickHouse \u00e9 esparso. Esse \u00edndice n\u00e3o permite encontrar uma \u00fanica linha na tabela, apenas um intervalo. E os dados s\u00e3o comprimidos em blocos. Para ler uma linha, \u00e9 necess\u00e1rio pegar um bloco inteiro e descompact\u00e1-lo. E se voc\u00ea executar um monte de consultas, ter\u00e1 muitas interse\u00e7\u00f5es, e muitos trabalhos ser\u00e3o executados repetidamente.<\/p>\n
<\/p>\n
<\/p>\n
Como um b\u00f4nus, vale destacar que no ClickHouse n\u00e3o se deve ter medo de passar at\u00e9 megabytes e at\u00e9 centenas de megabytes na se\u00e7\u00e3o IN. Lembro da nossa pr\u00e1tica, que se no MySQL passarmos um monte de valores na se\u00e7\u00e3o IN, por exemplo, 100 megabytes de alguns n\u00fameros, o MySQL consome 10 gigabytes de mem\u00f3ria e mais nada acontece, tudo funciona mal. <\/p>\n
<\/p>\n
E a segunda coisa \u00e9 que no ClickHouse, se suas consultas usam \u00edndices, isso nunca \u00e9 mais lento do que um full scan, ou seja, se quase toda a tabela precisa ser lida, ele ir\u00e1 percorrer sequencialmente e ler toda a tabela. Em geral, ele mesmo se encarrega disso.<\/p>\n
<\/p>\n
No entanto, existem algumas dificuldades. Por exemplo, o IN com subconsulta n\u00e3o utiliza o \u00edndice. Mas esse \u00e9 o nosso problema e precisamos corrigi-lo. N\u00e3o h\u00e1 nada fundamental aqui. Vamos consertar isso. <\/p>\n
<\/p>\n
E mais uma coisa interessante \u00e9 que se voc\u00ea tiver uma consulta muito longa e a execu\u00e7\u00e3o distribu\u00edda de consultas, essa consulta muito longa ser\u00e1 enviada para cada servidor sem compress\u00e3o. Por exemplo, 100 megabytes e 500 servidores. E, assim, voc\u00ea transmitir\u00e1 50 gigabytes pela rede. Ser\u00e1 transmitido e depois tudo ser\u00e1 executado com sucesso.<\/p>\n
<\/p>\n
* j\u00e1 \u00e9 utilizado; tudo consertado, como prometido.<\/p>\n
<\/p>\n
<\/p>\n
E \u00e9 bastante comum que as consultas venham de uma API. Por exemplo, voc\u00ea criou um servi\u00e7o. E se seu servi\u00e7o for necess\u00e1rio para algu\u00e9m, voc\u00ea abriu uma API e, literalmente dois dias depois, v\u00ea que algo estranho est\u00e1 acontecendo. Tudo est\u00e1 sobrecarregado e algumas consultas horr\u00edveis est\u00e3o chegando, que nunca deveriam ter ocorrido. <\/p>\n
<\/p>\n
E a solu\u00e7\u00e3o \u00e9 uma s\u00f3. Se voc\u00ea abriu uma API, ter\u00e1 que limit\u00e1-la. Por exemplo, introduzir algumas quotas. N\u00e3o h\u00e1 op\u00e7\u00f5es normais. Caso contr\u00e1rio, logo escrever\u00e3o um script e voc\u00ea ter\u00e1 problemas. <\/p>\n
<\/p>\n
E no ClickHouse existe uma funcionalidade especial \u2013 o monitoramento de cotas. Voc\u00ea pode, por exemplo, passar sua chave de cota. Isso pode ser, por exemplo, um identificador interno do usu\u00e1rio. E as cotas ser\u00e3o contabilizadas independentemente para cada um deles. <\/p>\n
<\/p>\n
<\/p>\n
Agora, outra coisa interessante. \u00c9 a replica\u00e7\u00e3o manual. <\/p>\n
<\/p>\n
Eu conhe\u00e7o muitos casos em que, apesar de o ClickHouse ter suporte interno \u00e0 replica\u00e7\u00e3o, as pessoas replicam o ClickHouse manualmente.<\/p>\n
<\/p>\n
Qual \u00e9 o princ\u00edpio? Voc\u00ea tem um pipeline de processamento de dados. E ele opera independentemente, por exemplo, em diferentes data centers. Voc\u00ea grava os mesmos dados da mesma forma no ClickHouse. No entanto, a pr\u00e1tica mostra que os dados acabar\u00e3o divergindo devido a algumas peculiaridades no seu c\u00f3digo. Espero que isso n\u00e3o aconte\u00e7a com o seu. <\/p>\n
<\/p>\n
E periodicamente voc\u00ea ainda precisar\u00e1 fazer a sincroniza\u00e7\u00e3o manualmente. Por exemplo, uma vez por m\u00eas, os administradores fazem rsync.<\/p>\n
<\/p>\n
Na verdade, \u00e9 muito mais simples usar a replica\u00e7\u00e3o embutida no ClickHouse. Mas aqui podem haver algumas contraindica\u00e7\u00f5es, pois para isso \u00e9 necess\u00e1rio usar o ZooKeeper. N\u00e3o direi nada de ruim sobre o ZooKeeper, no geral, o sistema funciona, mas \u00e0s vezes as pessoas n\u00e3o o utilizam devido \u00e0 fobia de Java, porque o ClickHouse \u00e9 um sistema muito bom, escrito em C++, que pode ser utilizado e funcionar\u00e1 tudo bem. E o ZooKeeper \u00e9 em Java. E de alguma forma, n\u00e3o d\u00e1 vontade de olhar para isso, mas ent\u00e3o voc\u00ea pode usar a replica\u00e7\u00e3o manual. <\/p>\n
<\/p>\n
<\/p>\n
O ClickHouse \u00e9 um sistema pr\u00e1tico. Ele leva em considera\u00e7\u00e3o suas necessidades. Se voc\u00ea tiver replica\u00e7\u00e3o manual, poder\u00e1 criar uma tabela Distribu\u00edda que observa suas r\u00e9plicas manuais e realiza failover entre elas. E h\u00e1 at\u00e9 uma op\u00e7\u00e3o especial que permite evitar flaps, mesmo que suas r\u00e9plicas divergiam sistematicamente.<\/p>\n
<\/p>\n
<\/p>\n
Al\u00e9m disso, podem haver problemas se voc\u00ea estiver usando motores de tabela primitivos. O ClickHouse \u00e9 como um construtor, onde existem muitos tipos diferentes de motores de tabela. Para todos os casos s\u00e9rios, como est\u00e1 escrito na documenta\u00e7\u00e3o, use tabelas da fam\u00edlia MergeTree. Os outros s\u00e3o apenas para casos espec\u00edficos ou para testes.<\/p>\n
<\/p>\n
Na tabela MergeTree, n\u00e3o \u00e9 necess\u00e1rio que voc\u00ea tenha uma data e hora. Voc\u00ea ainda pode utiliz\u00e1-la. Se n\u00e3o houver data e hora, coloque um valor padr\u00e3o de 2000. Isso vai funcionar e n\u00e3o exigir\u00e1 recursos. <\/p>\n
<\/p>\n
E na nova vers\u00e3o do servidor, voc\u00ea pode at\u00e9 especificar para ter particionamento customizado sem uma chave de parti\u00e7\u00e3o. Isso ser\u00e1 o mesmo. <\/p>\n
<\/p>\n
<\/p>\n
Por outro lado, voc\u00ea pode usar mecanismos de tabela primitivos. Por exemplo, encher os dados uma vez e ver, manipular e excluir. Voc\u00ea pode usar o Log.<\/p>\n
<\/p>\n
Ou o armazenamento de pequenos volumes para processamento intermedi\u00e1rio \u2013 isso \u00e9 StripeLog ou TinyLog.<\/p>\n
<\/p>\n
Memory pode ser usado se o volume de dados for pequeno e voc\u00ea precisar apenas manipular algo na RAM. <\/p>\n
<\/p>\n
<\/p>\n
ClickHouse n\u00e3o gosta muito de dados hiper-normalizados. <\/p>\n
<\/p>\n
Aqui est\u00e1 um exemplo t\u00edpico. \u00c9 uma enorme quantidade de URLs. Voc\u00ea os colocou em uma tabela vizinha. E ent\u00e3o decidiu fazer um JOIN com eles, mas isso normalmente n\u00e3o funcionar\u00e1, porque ClickHouse suporta apenas Hash JOIN. Se n\u00e3o houver RAM suficiente para o grande volume de dados que precisam ser unidos, ent\u00e3o o JOIN n\u00e3o poder\u00e1 ser realizado*. <\/p>\n
<\/p>\n
Se os dados tiverem alta cardinalidade, n\u00e3o se preocupe, armazene-os de forma denormalizada, URLs diretamente inplace na tabela principal. <\/p>\n
<\/p>\n
* agora o ClickHouse tamb\u00e9m tem merge join, e ele funciona quando os dados intermedi\u00e1rios n\u00e3o cabem na RAM. Mas isso n\u00e3o \u00e9 eficiente e a recomenda\u00e7\u00e3o permanece v\u00e1lida.<\/p>\n
<\/p>\n
<\/p>\n
Mais alguns exemplos, mas j\u00e1 estou na d\u00favida se eles s\u00e3o antipadr\u00f5es ou n\u00e3o. <\/p>\n
<\/p>\n
O ClickHouse tem uma desvantagem conhecida. Ele n\u00e3o suporta updates*. Em certo sentido, isso \u00e9 at\u00e9 bom. Se voc\u00ea tiver dados importantes, como contabilidade, ningu\u00e9m poder\u00e1 alter\u00e1-los, porque n\u00e3o h\u00e1 suporte para updates.<\/p>\n
<\/p>\n
* j\u00e1 foi adicionada h\u00e1 tempos a compatibilidade com update e delete em modo batch.<\/p>\n
<\/p>\n
Mas existem algumas maneiras especiais que permitem updates, de certa forma em segundo plano. Por exemplo, tabelas do tipo ReplaceMergeTree. Elas fazem updates durante as mesclagens em segundo plano. Voc\u00ea pode for\u00e7ar isso usando optimize table. Mas n\u00e3o fa\u00e7a isso com muita frequ\u00eancia, pois resultar\u00e1 em reescrita completa da parti\u00e7\u00e3o. <\/p>\n
<\/p>\n
JOINs distribu\u00eddos no ClickHouse tamb\u00e9m s\u00e3o mal tratados pelo planejador de consultas. <\/p>\n
<\/p>\n
Ruim, mas \u00e0s vezes \u00e9 aceit\u00e1vel.<\/p>\n
<\/p>\n
Usar ClickHouse apenas para ler dados de volta com select*.<\/p>\n
<\/p>\n
Eu n\u00e3o recomendaria usar ClickHouse para c\u00e1lculos pesados. Mas n\u00e3o \u00e9 bem assim, porque j\u00e1 estamos nos afastando dessa recomenda\u00e7\u00e3o. E recentemente adicionamos a possibilidade de aplicar modelos de aprendizado de m\u00e1quina no ClickHouse \u2013 Catboost. E isso me preocupa, porque eu penso: \"Que horror. Quantos ciclos por byte isso resulta!\". Fico muito triste em gastar ciclos em bytes. <\/p>\n
<\/p>\n
<\/p>\n
Mas n\u00e3o se preocupe, instale o ClickHouse, tudo vai ficar bem. Se precisar, temos uma comunidade. Ali\u00e1s, a comunidade \u00e9 voc\u00ea. E se voc\u00ea tiver algum problema, pode ao menos entrar no nosso chat e, espero, que algu\u00e9m te ajude. <\/p>\n
<\/p>\n
Perguntas<\/p>\n
<\/p>\n
Obrigado pela apresenta\u00e7\u00e3o! Onde posso reclamar sobre a queda do ClickHouse?<\/em><\/p>\n<\/p>\n
Voc\u00ea pode reclamar comigo pessoalmente agora mesmo. <\/p>\n
<\/p>\n
Recentemente comecei a usar o ClickHouse. Logo derrubei a interface cli.<\/em><\/p>\n<\/p>\n
Voc\u00ea teve sorte. <\/p>\n
<\/p>\n
Mais tarde derrubei o servidor com um pequeno select.<\/em><\/p>\n<\/p>\n
Voc\u00ea tem talento. <\/p>\n
<\/p>\n
Eu abri um bug no GitHub, mas ignoraram.<\/em> <\/p>\n<\/p>\n
Vamos ver. <\/p>\n
<\/p>\n
O Alexey me enganou para me levar \u00e0 apresenta\u00e7\u00e3o, prometendo falar sobre como voc\u00ea compacta os dados por dentro.<\/em><\/p>\n<\/p>\n
\u00c9 muito simples. <\/p>\n
<\/p>\n
Eu percebi isso ontem. Mais detalhes.<\/em> <\/p>\n<\/p>\n
N\u00e3o h\u00e1 nada de terrivelmente complicado. \u00c9 apenas compress\u00e3o por blocos. Por padr\u00e3o, usa-se LZ4, mas pode-se ativar ZSTD*. Blocos variam de 64 kilobytes a 1 megabyte.<\/p>\n
<\/p>\n
* tamb\u00e9m h\u00e1 suporte para codecs de compress\u00e3o especializados que podem ser usados em combina\u00e7\u00e3o com outros algoritmos.<\/p>\n
<\/p>\n
Os blocos cont\u00eam apenas dados crus?<\/em><\/p>\n<\/p>\n
N\u00e3o exatamente crus. S\u00e3o arrays. Se voc\u00ea tem uma coluna num\u00e9rica, os n\u00fameros est\u00e3o organizados em um array sequencial. <\/p>\n
<\/p>\n
Entendi.<\/em> <\/p>\n<\/p>\n
Alexey, o exemplo que foi com uniqExact sobre endere\u00e7os IP, ou seja, o que o uniqExact leva mais tempo para calcular em strings do que em n\u00fameros e assim por diante. E se aplicarmos um truque e fizermos o casting no momento da leitura? Ou seja, voc\u00ea, aparentemente, disse que no disco isso n\u00e3o varia muito. Se lermos strings do disco e fizermos o casting, ent\u00e3o nossos agregados ser\u00e3o mais r\u00e1pidos ou n\u00e3o? Ou acabamos ganhando algo insignificante aqui? Eu acho que voc\u00ea testou isso, mas n\u00e3o mencionou no benchmark.<\/em> <\/p>\n<\/p>\n
Acho que ser\u00e1 mais lento do que sem o cast. Nesse caso, o endere\u00e7o IP precisa ser extra\u00eddo da string. Claro que em ClickHouse a extra\u00e7\u00e3o de endere\u00e7os IP tamb\u00e9m \u00e9 otimizada. N\u00f3s nos esfor\u00e7amos bastante, mas os n\u00fameros est\u00e3o registrados em forma de dez mil. Muito inconveniente. Por outro lado, a fun\u00e7\u00e3o uniqExact funcionar\u00e1 com strings mais lentamente, n\u00e3o apenas porque s\u00e3o strings, mas tamb\u00e9m porque \u00e9 escolhida uma especializa\u00e7\u00e3o diferente do algoritmo. Strings s\u00e3o processadas de forma diferente.<\/p>\n
<\/p>\n
E se pegarmos um tipo de dado mais primitivo? Por exemplo, registramos o user id, que temos in, registramos como uma string e depois fazemos o cast, ser\u00e1 mais divertido ou n\u00e3o?<\/em><\/p>\n<\/p>\n
Eu duvido. Acho que ser\u00e1 at\u00e9 mais triste, porque, afinal, analisar n\u00fameros \u00e9 um problema s\u00e9rio. Tenho a impress\u00e3o de que esse colega fez at\u00e9 uma apresenta\u00e7\u00e3o sobre como \u00e9 dif\u00edcil analisar n\u00fameros na forma de dez mil, ou talvez n\u00e3o. <\/p>\n
<\/p>\n
Alexey, muito obrigado pela apresenta\u00e7\u00e3o! E tamb\u00e9m muito obrigado pelo ClickHouse! Eu tenho uma pergunta sobre os planos. Existe a possibilidade de uma funcionalidade para atualizar dicion\u00e1rios parcialmente?<\/em><\/p>\n<\/p>\n
Ou seja, uma recarga parcial?<\/p>\n
<\/p>\n
Sim, sim. Algo como a possibilidade de especificar um campo MySQL, ou seja, atualizar ap\u00f3s para carregar apenas esses dados, se o dicion\u00e1rio for muito grande.<\/em><\/p>\n<\/p>\n
Uma funcionalidade muito interessante. E acho que algu\u00e9m a sugeriu no nosso chat. Pode ser que tenha sido voc\u00ea. <\/p>\n
<\/p>\n
N\u00e3o acho que fui eu.<\/em><\/p>\n<\/p>\n
\u00d3timo, ent\u00e3o agora temos dois pedidos. E podemos come\u00e7ar devagar. Mas quero avis\u00e1-lo imediatamente que essa funcionalidade \u00e9 bastante simples de implementar. Ou seja, teoricamente, precisamos apenas escrever o n\u00famero da vers\u00e3o na tabela e, em seguida, escrever: a vers\u00e3o \u00e9 menor que tal. E isso significa que, provavelmente, iremos sugerir que entusiastas fa\u00e7am isso. Voc\u00ea \u00e9 um entusiasta? <\/p>\n
<\/p>\n
Sim, mas, infelizmente, n\u00e3o em C++.<\/em><\/p>\n<\/p>\n
Seus colegas conseguem programar em C++? <\/p>\n
<\/p>\n
Vou encontrar algu\u00e9m.<\/em><\/p>\n<\/p>\n
Perfeito.<\/p>\n
<\/p>\n
* a funcionalidade foi adicionada dois meses ap\u00f3s a apresenta\u00e7\u00e3o \u2013 foi desenvolvida pelo autor da pergunta e enviada. pull request<\/a><\/noindex>.<\/p>\n<\/p>\n
Obrigado!<\/em><\/p>\n<\/p>\n
Ol\u00e1! Obrigado pela apresenta\u00e7\u00e3o! Voc\u00ea mencionou que o ClickHouse utiliza muito bem todos os recursos dispon\u00edveis. E o palestrante ao lado da Luxoft falou sobre sua solu\u00e7\u00e3o para os Correios da R\u00fassia. Ele disse que gostaram muito do ClickHouse, mas n\u00e3o o usaram em vez de seu principal concorrente devido ao fato de que ele consumia toda a CPU. E n\u00e3o conseguiram integr\u00e1-lo \u00e0 sua arquitetura, ao seu ZooKeeper com Docker. Existe uma maneira de limitar o ClickHouse para que ele n\u00e3o consuma tudo o que est\u00e1 dispon\u00edvel?<\/em><\/p>\n<\/p>\n
Sim, \u00e9 poss\u00edvel e muito f\u00e1cil. Se voc\u00ea quiser que consuma menos n\u00facleos, basta escrever set max_threads = 1<\/code>. E assim, ele executar\u00e1 a consulta em um \u00fanico n\u00facleo. Al\u00e9m disso, \u00e9 poss\u00edvel definir configura\u00e7\u00f5es diferentes para diferentes usu\u00e1rios. Portanto, n\u00e3o h\u00e1 problemas. E informe aos colegas da Luxoft que n\u00e3o \u00e9 bom que n\u00e3o tenham encontrado essa configura\u00e7\u00e3o na documenta\u00e7\u00e3o. <\/p>\n<\/p>\n
Alexei, ol\u00e1! Gostaria de perguntar sobre uma quest\u00e3o. N\u00e3o \u00e9 a primeira vez que ou\u00e7o que muitos come\u00e7am a usar o ClickHouse como armazenamento de logs. Na apresenta\u00e7\u00e3o voc\u00ea disse para n\u00e3o fazer isso, ou seja, n\u00e3o \u00e9 necess\u00e1rio armazenar strings longas. O que voc\u00ea pensa sobre isso?<\/em><\/p>\n<\/p>\n
Em primeiro lugar, logs geralmente n\u00e3o s\u00e3o strings longas. Pode haver, \u00e9 claro, exce\u00e7\u00f5es. Por exemplo, algum servi\u00e7o escrito em Java gera uma exce\u00e7\u00e3o, que \u00e9 registrada. E assim em um ciclo infinito, e o espa\u00e7o no disco r\u00edgido acaba. A solu\u00e7\u00e3o \u00e9 muito simples. Se as strings forem muito longas, corte-as. E o que significa longo? Dezenas de quilobytes \u00e9 ruim*.<\/p>\n
<\/p>\n
* nas vers\u00f5es mais recentes do ClickHouse, foi inclu\u00edda a \"granularidade adaptativa do \u00edndice\", o que resolve em grande parte o problema de armazenamento de strings longas.<\/p>\n
<\/p>\n
E um quilobyte \u00e9 normal?<\/em><\/p>\n<\/p>\n
Normal. <\/p>\n
<\/p>\n
Ol\u00e1! Obrigado pela apresenta\u00e7\u00e3o! J\u00e1 perguntei isso no chat, mas n\u00e3o lembro se recebi resposta. Est\u00e1 previsto expandir a se\u00e7\u00e3o WITH de maneira semelhante ao CTE?<\/em><\/p>\n<\/p>\n
Por enquanto n\u00e3o. A se\u00e7\u00e3o WITH \u00e9 um pouco s\u00e9ria. \u00c9 uma pequena funcionalidade que temos.<\/p>\n
<\/p>\n
Entendi. Obrigado!<\/em><\/p>\n<\/p>\n
Obrigado pela apresenta\u00e7\u00e3o! Muito interessante! Uma pergunta global. Est\u00e1 previsto fazer, talvez, alguma modifica\u00e7\u00e3o na exclus\u00e3o de dados?<\/em><\/p>\n<\/p>\n
Com certeza. Essa \u00e9 nossa primeira tarefa na fila. Estamos pensando ativamente em como fazer tudo corretamente. E \u00e9 hora de come\u00e7ar a digitar*.<\/p>\n
<\/p>\n
* pressionamos bot\u00f5es no teclado e tudo foi feito.<\/p>\n
<\/p>\n
Isso afetar\u00e1 de alguma forma o desempenho do sistema ou n\u00e3o? A inser\u00e7\u00e3o ser\u00e1 t\u00e3o r\u00e1pida quanto agora?<\/em><\/p>\n<\/p>\n
Talvez os pr\u00f3prios deletes, os pr\u00f3prios updates sejam muito pesados, mas isso n\u00e3o afetar\u00e1 o desempenho dos selects e o desempenho dos inserts.<\/p>\n
<\/p>\n
E mais uma pequena pergunta. Na apresenta\u00e7\u00e3o, voc\u00ea falou sobre a chave prim\u00e1ria. Portanto, temos o particionamento, que por padr\u00e3o \u00e9 mensal, correto? E quando definimos um intervalo de datas que se encaixa em um m\u00eas, lemos apenas essa parti\u00e7\u00e3o, certo?<\/em><\/p>\n<\/p>\n
Sim.<\/p>\n
<\/p>\n
Tenho uma pergunta. Se n\u00e3o conseguimos destacar alguma chave prim\u00e1ria, \u00e9 correto faz\u00ea-la pelo campo \"Data\" para que, em segundo plano, haja uma menor reorganiza\u00e7\u00e3o desses dados, permitindo que eles fiquem mais organizados? Se voc\u00ea n\u00e3o tem consultas em intervalos e n\u00e3o consegue escolher nenhuma chave prim\u00e1ria, vale a pena incluir a data na chave prim\u00e1ria?<\/em><\/p>\n<\/p>\n
Sim.<\/p>\n
<\/p>\n
Talvez fa\u00e7a sentido incluir no chave prim\u00e1ria um campo pelo qual os dados possam ser melhor compactados, se eles forem ordenados por esse campo. Por exemplo, o identificador do usu\u00e1rio. O usu\u00e1rio, por exemplo, acessa o mesmo site. Nesse caso, voc\u00ea coloca o id do usu\u00e1rio e o tempo. Assim, seus dados ser\u00e3o melhor compactados. Quanto \u00e0 data, se voc\u00ea realmente n\u00e3o tem e nunca ter\u00e1 consultas em intervalos de datas, ent\u00e3o pode n\u00e3o incluir a data na chave prim\u00e1ria. <\/p>\n
<\/p>\n
Certo, muito obrigado!<\/em><\/p>\nFonte: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0422\u0430\u043a \u043a\u0430\u043a ClickHouse \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u043e\u0439, \u043f\u0440\u0438 \u0435\u0433\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0438 \u0432\u0430\u0436\u043d\u043e \u0443\u0447\u0438\u0442\u044b\u0432\u0430\u0442\u044c \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e\u0441\u0442\u0438 \u0435\u0433\u043e \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b. \u0412 \u044d\u0442\u043e\u043c \u0434\u043e\u043a\u043b\u0430\u0434\u0435 \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0435\u0442 \u043e \u043f\u0440\u0438\u043c\u0435\u0440\u0430\u0445 \u0442\u0438\u043f\u0438\u0447\u043d\u044b\u0445 \u043e\u0448\u0438\u0431\u043e\u043a \u043f\u0440\u0438 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0438 ClickHouse, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043c\u043e\u0433\u0443\u0442 \u043f\u0440\u0438\u0432\u0435\u0441\u0442\u0438 \u043a \u043d\u0435\u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e\u0439 \u0440\u0430\u0431\u043e\u0442\u0435. \u041d\u0430 \u043f\u0440\u0438\u043c\u0435\u0440\u0430\u0445 \u0438\u0437 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0438 \u0431\u0443\u0434\u0435\u0442 \u043f\u043e\u043a\u0430\u0437\u0430\u043d\u043e, \u043a\u0430\u043a \u0432\u044b\u0431\u043e\u0440 \u0442\u043e\u0439 \u0438\u043b\u0438 \u0438\u043d\u043e\u0439 \u0441\u0445\u0435\u043c\u044b \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u043c\u043e\u0436\u0435\u0442 \u0438\u0437\u043c\u0435\u043d\u0438\u0442\u044c \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u043d\u0430 \u043f\u043e\u0440\u044f\u0434\u043a\u0438. \u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91439,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91438","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Uso](\"\/wp-content\/uploads\/2020\/08\/8e42c1fffffcc964eacef240ea90bbc5.jpg\")
<\/p>\n