HighLoad++ Moscova 2018, Palacio de Congresos. 9 de novembro, 15:00 h
Resumos e presentación:
Yuri Nasretdinov (VKontakte): o informe falará sobre a experiencia de implementar ClickHouse na nosa empresa: por que o necesitamos, cantos datos almacenamos, como os escribimos, etc.
Materiais adicionais:
Yuri Nasretdinov: - Ola a todos! Chámome Yuri Nasretdinov, xa que xa me presentaron. Traballo en VKontakte. Falarei de como inserimos datos en ClickHouse desde a nosa flota de servidores (decenas de miles).
Que son os rexistros e por que recollelos?
O que vos contaremos: o que fixemos, por que necesitabamos "ClickHouse", respectivamente, por que o escollemos, que tipo de rendemento pode obter aproximadamente sen configurar nada especialmente. Falarei máis sobre as táboas de memoria intermedia, sobre os problemas que tivemos con elas e sobre as nosas solucións que desenvolvemos desde código aberto: KittenHouse e Lighthouse.
Por que tivemos que facer algo (todo sempre é bo en VKontakte, non?). Queriamos recoller rexistros de depuración (e alí había centos de terabytes de datos), quizais dalgún xeito sería máis conveniente calcular estatísticas; e temos unha flota de decenas de miles de servidores desde os que hai que facer todo isto.
Por que decidimos? Probablemente tivemos solucións para almacenar rexistros. Aquí hai un "Backend VK" tan público. Recomendo encarecidamente subscribirse a el.
Que son os rexistros? Este é un motor que devolve matrices baleiras. Os motores en VK son o que outros chaman microservizos. E aquí tes un adhesivo sorrinte (moitos gústame). E logo? Ben, escoita máis!
Que se pode usar para almacenar rexistros? É imposible non mencionar a Hadup. Despois, por exemplo, Rsyslog (almacenando estes rexistros en ficheiros). LSD. Quen sabe o que é o LSD? Non, non este LSD. Tamén almacena ficheiros, respectivamente. Ben, ClickHouse é unha opción estraña.
Clickhouse e competidores: requisitos e oportunidades
Que queremos? Queremos asegurarnos de que non nos teñamos que preocupar demasiado polo funcionamento, para que funcione fóra da caixa, preferiblemente cunha configuración mínima. Queremos escribir moito, e escribir rapidamente. E queremos mantelo durante todo tipo de meses, anos, é dicir, durante moito tempo. Quizais queiramos entender algún problema co que nos chegaron e dixeron: "Algo non funciona aquí", e iso foi hai 3 meses), e queremos poder ver o que pasou hai 3 meses". A compresión de datos, está claro por que sería unha vantaxe, porque reduce a cantidade de espazo que ocupa.
E temos un requisito tan interesante: ás veces escribimos a saída dalgúns comandos (por exemplo, rexistros), pode ser máis de 4 kilobytes con bastante facilidade. E se isto funciona a través de UDP, entón non necesita gastar... non terá ningún "sobrecarga" para a conexión, e para un gran número de servidores isto será unha vantaxe.
Vexamos o que nos ofrece o código aberto. En primeiro lugar, temos o motor de rexistros: este é o noso motor; En principio, pode facer de todo, incluso pode escribir liñas longas. Ben, non comprime os datos de forma transparente: podemos comprimir columnas grandes nós mesmos se queremos... nós, por suposto, non queremos (se é posible). O único problema é que sabe dar só o que cabe na súa memoria; Para ler o resto, cómpre obter o binlog deste motor e, en consecuencia, leva bastante tempo.
Que outras opcións hai? Por exemplo, "Hadup". Facilidade de funcionamento... Quen pensa que Hadup é fácil de configurar? Por suposto, non hai problemas coa gravación. Ao ler, ás veces xorden preguntas. En principio, diría que probablemente non, especialmente para os rexistros. Almacenamento a longo prazo - por suposto, si, compresión de datos - si, cadeas longas - está claro que pode gravar. Pero gravando desde un gran número de servidores... Aínda tes que facer algo ti mesmo!
Rsyslog. De feito, utilizámolo como unha opción de copia de seguridade para poder lelo sen botar o binlog, pero non pode escribir liñas longas; en principio, non pode escribir máis de 4 kilobytes. Tes que facer a compresión de datos do mesmo xeito ti mesmo. A lectura procederá dos ficheiros.
Despois está o desenvolvemento "badushka" do LSD. Esencialmente o mesmo que "Rsyslog": admite cadeas longas, pero non pode funcionar con UDP e, de feito, por iso, por desgraza, hai moitas cousas que hai que reescribir. O LSD debe ser redeseñado para poder gravar desde decenas de miles de servidores.
E aquí! Unha opción divertida é ElasticSearch. Como dicir? Vai ben coa lectura, é dicir, le rápido, pero non moi ben coa escritura. En primeiro lugar, se comprime datos, é moi débil. Probablemente, unha busca completa require estruturas de datos máis grandes que o volume orixinal. É difícil de operar e moitas veces xorden problemas con el. E, de novo, gravar en Elastic: temos que facelo todo nós.
Aquí ClickHouse é unha opción ideal, por suposto. O único é que gravar desde decenas de miles de servidores é un problema. Pero polo menos hai un problema, podemos tentar solucionalo dalgún xeito. E o resto do informe trata sobre este problema. Que tipo de rendemento podes esperar de ClickHouse?
Como o imos inserir? MergeTree
Quen de vós non escoitou ou coñeceu "ClickHouse"? Teño que dicircho, non? Moi rápido. A inserción alí - 1-2 gigabits por segundo, ráfagas de ata 10 gigabits por segundo realmente pode soportar esta configuración - hai dous Xeon de 6 núcleos (é dicir, nin sequera o máis potente), 256 gigabytes de RAM, 20 terabytes. en RAID (ninguén configurado, configuración predeterminada). Alexey Milovidov, desenvolvedor de ClickHouse, probablemente estea sentado chorando porque non configuramos nada (todo funcionou así para nós). En consecuencia, pódese obter unha velocidade de exploración de, por exemplo, uns 6 millóns de liñas por segundo se os datos están ben comprimidos. Se che gusta % nunha cadea de texto - 100 millóns de liñas por segundo, é dicir, parece bastante rápido.
Como o imos inserir? Ben, xa sabes que VK usa PHP. Inseriremos desde cada traballador PHP vía HTTP en "ClickHouse", na táboa MergeTree para cada rexistro. Quen ve un problema con este esquema? Por algún motivo, non todos levantaron a man. Déixame dicirche.
En primeiro lugar, hai moitos servidores; en consecuencia, haberá moitas conexións (malas). Entón, é mellor inserir datos en MergeTree non máis dunha vez por segundo. E quen sabe por que? Vale, vale. Vouche contar un pouco máis sobre isto. Outra pregunta interesante é que non estamos facendo análises, non necesitamos enriquecer os datos, non necesitamos servidores intermedios, queremos inserir directamente en "ClickHouse" (preferentemente - canto máis directamente, mellor).
En consecuencia, como se fai a inserción en MergeTree? Por que é mellor inserilo non máis dunha vez por segundo ou menos? O feito é que "ClickHouse" é unha base de datos en columnas e ordena os datos en orde ascendente da clave principal, e cando fai unha inserción, créanse un número de ficheiros polo menos igual ao número de columnas nas que se ordenan os datos. en orde ascendente da clave primaria (créase un directorio separado, un conxunto de ficheiros no disco para cada inserción). Despois chega a seguinte inserción e, en segundo plano, combínanse en "particións" máis grandes. Dado que os datos están ordenados, é posible "fusionar" dous ficheiros ordenados sen consumir moita memoria.
Pero, como podes adiviñar, se escribes 10 ficheiros para cada inserción, ClickHouse (ou o teu servidor) rematará rapidamente, polo que recoméndase inserilos en grandes lotes. En consecuencia, nunca puxemos en produción o primeiro esquema. Inmediatamente lanzamos un, que aquí o número 2 ten:
Aquí imaxínate que hai uns mil servidores nos que lanzamos, só hai PHP. E en cada servidor está o noso axente local, que chamamos "Kittenhouse", que mantén unha conexión con "ClickHouse" e insire datos cada poucos segundos. Insire os datos non en MergeTree, senón nunha táboa de memoria intermedia, que serve precisamente para evitar inserilos directamente en MergeTree.
Traballar con táboas de memoria intermedia
Que é? As táboas de memoria intermedia son unha peza de memoria que se fragmenta (é dicir, pódese inserir nela con frecuencia). Constan de varias pezas, e cada unha das pezas funciona como un búfer independente, e son lavados de forma independente (se tes moitas pezas no búfer, haberá moitas insercións por segundo). É posible ler desde estas táboas; entón le a unión do contido do búfer e a táboa principal, pero neste momento a escritura está bloqueada, polo que é mellor non ler desde alí. E as táboas de búfer mostran moi bos QPS, é dicir, ata 3 mil QPS non terás ningún problema ao inserir. Está claro que se o servidor perde enerxía, entón os datos pódense perder, porque só se almacenaron na memoria.
Ao mesmo tempo, o esquema cun búfer complica ALTER, xa que primeiro cómpre soltar a táboa antiga de búfer co esquema antigo (os datos non desaparecerán por ningún lado, porque serán lavados antes de que se elimine a táboa). A continuación, "alteras" a táboa que necesitas e creas de novo a táboa de memoria intermedia. En consecuencia, aínda que non exista unha táboa de memoria intermedia, os teus datos non fluirán a ningún lado, pero podes telos no disco polo menos localmente.
Que é Kittenhouse e como funciona?
Que é KittenHouse? Este é un proxy. Adiviña que idioma? Recollei os temas máis exagerados no meu informe: "Clickhouse", Vaia, quizais lembre outra cousa. Si, isto está escrito en Go, porque realmente non sei escribir en C, non quero.
En consecuencia, mantén unha conexión con cada servidor e pode escribir na memoria. Por exemplo, se escribimos rexistros de erros en Clickhouse, se Clickhouse non ten tempo para inserir datos (despois de todo, se se escribe demasiado), non aumentamos a memoria, simplemente botamos o resto. Porque se escribimos varios gigabits por segundo de erros, probablemente poidamos tirar algúns. Kittenhouse pode facelo. Ademais, pode realizar unha entrega fiable, é dicir, escribir no disco na máquina local e unha vez cada vez (alí, unha vez cada par de segundos) tenta entregar datos deste ficheiro. E ao principio usamos o formato de Valores normal, non un formato binario, un formato de texto (como no SQL normal).
Pero entón pasou isto. Empregamos entrega fiable, escribimos rexistros, despois decidimos (era un clúster de proba condicional)... Puxémolo varias horas e volvemos a abrir, e comezou unha inserción desde mil servidores; resultou que Clickhouse aínda tiña un "Thread on connection": en consecuencia, en mil conexións, unha inserción activa leva a unha carga media no servidor de aproximadamente mil e medio. Sorprendentemente, o servidor aceptou solicitudes, pero os datos aínda se inseriron despois dun tempo; pero foi moi difícil ao servidor servilo...
Engadir nginx
Tal solución para o modelo Thread por conexión é nginx. Instalamos nginx diante de Clickhouse, ao mesmo tempo configuramos o equilibrio para dúas réplicas (a nosa velocidade de inserción aumentou 2 veces, aínda que non é un feito que deba ser así) e limitamos o número de conexións a Clickhouse, ao río arriba e, en consecuencia, máis , que en 50 conexións, parece que non ten sentido inserir.
Entón decatámonos de que este esquema xeralmente ten desvantaxes, porque aquí só temos un nginx. En consecuencia, se este nginx falla, a pesar da presenza de réplicas, perdemos datos ou, polo menos, non escribimos en ningures. É por iso que fixemos o noso propio equilibrio de carga. Tamén nos demos conta de que "Clickhouse" aínda é axeitado para rexistros, e o "demo" tamén comezou a escribir os seus rexistros en "Clickhouse", moi cómodo, para ser honesto. Aínda o usamos para outros "demos".
Entón descubrimos este interesante problema: se usa un método non estándar de inserción en modo SQL, forza un analizador SQL completo baseado en AST, que é bastante lento. En consecuencia, engadimos configuracións para garantir que isto nunca ocorre. Fixemos balance de carga, comprobacións de saúde, para que se morre un, aínda deixamos os datos. Agora temos moitas táboas que necesitamos para ter diferentes clústeres de Clickhouse. E tamén comezamos a pensar noutros usos; por exemplo, queriamos escribir rexistros desde módulos nginx, pero non saben como comunicarse usando o noso RPC. Ben, gustaríame ensinarlles como enviar polo menos dalgún xeito, por exemplo, para recibir eventos en localhost a través de UDP e despois reenvialos a Clickhouse.
A un paso da solución
O esquema final comezou a verse así (a cuarta versión deste esquema): en cada servidor diante de Clickhouse hai nginx (no mesmo servidor) e simplemente envía solicitudes proxy a localhost cun límite no número de conexións de 50 pezas. E este esquema xa funcionaba bastante, todo estaba bastante ben con el.
Vivimos así durante aproximadamente un mes. Todo o mundo estaba contento, engadiron táboas, engadiron, engadiron... En xeral, resultou que a forma en que engadimos táboas de buffer non era moi óptima (poñémolo así). Fixemos 16 pezas en cada táboa e un intervalo de flash dun par de segundos; tiñamos 20 táboas e cada táboa recibiu 8 insercións por segundo, e neste momento comezou "Clickhouse"... os rexistros comezaron a ralentizarse. Non só non pasaron... Por defecto, nginx tiña unha cousa tan interesante que, se as conexións remataban na parte superior, simplemente devolveu "502" a todas as novas solicitudes.
E aquí temos (acabo de mirar os rexistros no propio Clickhouse) preto da metade por cento das solicitudes fallaron. En consecuencia, a utilización do disco foi alta, houbo moitas fusións. Ben, que fixen? Por suposto, non me molestei en descubrir por que terminaron exactamente a conexión e a auga arriba.
Substituíndo nginx por un proxy inverso
Decidín que necesitamos xestionar isto nós mesmos, non necesitamos deixalo a nginx: nginx non sabe que táboas hai en Clickhouse, e substituín a nginx por un proxy inverso, que tamén escribín eu.
Que está facendo? Funciona baseado na biblioteca fasthttp "goshnoy", é dicir, rápido, case tan rápido como nginx. Sentímolo, Igor, se estás presente aquí (nota: Igor Sysoev é un programador ruso que creou o servidor web nginx). Pode entender que tipo de consultas son estas - INSERT ou SELECT - en consecuencia, ten diferentes grupos de conexión para diferentes tipos de consultas.
En consecuencia, aínda que non teñamos tempo para completar as solicitudes de inserción, as "seleccións" pasarán, e viceversa. E agrupa os datos en táboas de memoria intermedia -cunha pequena memoria intermedia: se houbese erros, erros de sintaxe, etc.- para que non afectasen moito ao resto dos datos, porque cando simplemente introducimos en táboas de memoria intermedia, tiña un pequeno "bachi", e todos os erros de sintaxe só afectaban a esta pequena peza; e aquí xa afectarán a un gran buffer. Pequeno é 1 megabyte, é dicir, non tan pequeno.
Inserir unha sincronización e substituír esencialmente nginx fai esencialmente o mesmo que facía antes nginx: non necesitas cambiar o "Kittenhouse" local para iso. E xa que usa fasthttp, é moi rápido: podes facer máis de 100 mil solicitudes por segundo para insercións únicas a través dun proxy inverso. Teoricamente, podes inserir unha liña á vez no proxy inverso de kittenhouse, pero por suposto non o facemos.
O esquema comezou a verse así: "Kittenhouse", o proxy inverso agrupa moitas solicitudes en táboas e, á súa vez, as táboas de memoria intermedia insíronas nas principais.
Killer é unha solución temporal, Kitten é unha solución permanente
Este é un problema interesante... Algún de vós utilizou fasthttp? Quen utilizou fasthttp coas solicitudes POST? Probablemente, isto realmente non debería facerse, porque almacena o corpo da solicitude por defecto e o noso tamaño de memoria intermedia estaba configurado en 16 megabytes. A inserción deixou de manterse nalgún momento e comezaron a chegar anacos de 16 megabytes das decenas de miles de servidores, e todos foron almacenados na memoria antes de ser enviados a Clickhouse. En consecuencia, a memoria esgotouse, o asasino fóra da memoria chegou e matou o proxy inverso (ou "Clickhouse", que teoricamente podería "comer" máis que o proxy inverso). O ciclo repetiuse. Non é un problema moi agradable. Aínda que nos topamos con isto só despois de varios meses de funcionamento.
Que fixen? De novo, non me gusta moito entender o que pasou exactamente. Creo que é bastante obvio que non debes almacenar na memoria. Non puiden parchear http, aínda que o intentei. Pero atopei un xeito de facelo para que non houbese necesidade de parchear nada, e inventei o meu propio método en HTTP: chameino GATIÑO. Ben, é lóxico: "VK", "Gatiño"... Que máis?...
Se unha solicitude chega ao servidor co método Kitten, entón o servidor debería responder "miau" - loxicamente. Se responde a isto, considérase que entende este protocolo e entón intercepto a conexión (fasthttp ten tal método) e a conexión pasa ao modo "en bruto". Por que o necesito? Quero controlar como ocorre a lectura das conexións TCP. TCP ten unha propiedade marabillosa: se ninguén está lendo dende o outro lado, entón a escritura comeza a esperar e a memoria non se gasta especialmente nisto.
E por iso lin duns 50 clientes á vez (de cincuenta porque con cincuenta deberían ser suficientes, aínda que a tarifa proceda doutro DC)... O consumo diminuíu con este enfoque polo menos 20 veces, pero eu, para ser sincero , non puiden medir exactamente a que hora, porque xa non ten sentido (xa chegou ao nivel de erro). O protocolo é binario, é dicir, contén o nome da táboa e os datos; non hai cabeceiras http, polo que non usei un socket web (non necesito comunicarme cos navegadores: fixen un protocolo que se adapta ás nosas necesidades). E todo quedou ben con el.
A mesa de tampón está triste
Recentemente atopamos outra característica interesante das táboas de memoria intermedia. E este problema xa é moito máis doloroso que os demais. Imaxinemos esta situación: xa estás usando Clickhouse activamente, tes ducias de servidores Clickhouse e tes algunhas solicitudes que tardan moito en ler (digamos, máis de 60 segundos); e chegas e fas Modificar neste momento... Mentres tanto, as "seleccionas" que comezaron antes de "Alter" non se incluirán nesta táboa, "Alter" non comezará, probablemente algunhas características de como funciona "Clickhouse" en este lugar. Quizais isto se poida solucionar? Ou é imposible?
En xeral, está claro que en realidade este non é un problema tan grande, pero coas táboas de tampón faise máis doloroso. Porque, se, digamos, o teu tempo de espera "Alter" (e pode que se agote noutro host, non no teu, senón nunha réplica, por exemplo), entón... Eliminaches a táboa de memoria intermedia, o teu "Alter" ( ou algún outro host) esgotouse o tempo de espera, entón produciuse un erro "Alter") - aínda debe asegurarse de que os datos se seguen escribindo: volve crear as táboas de memoria intermedia (segundo o mesmo esquema que a táboa principal), entón "Alter" pasa, remata despois de todo e o búfer da táboa comeza a diferir no esquema do pai. Dependendo de cal fose o "Alter", é posible que a inserción xa non vaia a esta táboa de memoria intermedia, é moi triste.
Tamén hai un sinal deste tipo (quizais alguén o notou): chámase query_thread_log nas novas versións de Clickhouse. Por defecto, nalgunha versión había un. Aquí acumulamos 840 millóns de rexistros nun par de meses (100 gigabytes). Isto débese a que alí se escribiron "insercións" (quizais agora, por certo, non estean escritas). Como vos dixen, as nosas "insercións" son pequenas: tiñamos moitas "insercións" nas táboas de memoria intermedia. Está claro que está desactivado; só vos digo o que vin no noso servidor. Por que? Este é outro argumento contra o uso de táboas de memoria intermedia. Spotty está moi triste.
Quen sabía que ese tipo se chamaba Spotty? Os empregados de VK levantaron a man. OK.
Sobre os plans de "KitttenHouse"
Os plans normalmente non se comparten, non? De súpeto non as cumprirás e non quedarás moi ben aos ollos dos demais. Pero vou correr o risco! Queremos facer o seguinte: as táboas de tampón, a min paréceme, seguen sendo unha muleta e necesitamos tamponar nós mesmos a inserción. Pero aínda non queremos almacenalo no disco, polo que almacenaremos a inserción na memoria.
En consecuencia, cando se faga unha "inserción", xa non será sincrónica: xa funcionará como unha táboa de memoria intermedia, inserirase na táboa principal (ben, algún día despois) e informará a través dunha canle separada cales insercións pasaron e cales. non ten.
Por que non podo deixar a inserción sincrónica? É moito máis cómodo. O feito é que se inseris desde 10 mil hosts, todo está ben: obterás un pouco de cada host, inseris alí unha vez por segundo, todo está ben. Pero gustaríame que este esquema funcione, por exemplo, desde dúas máquinas, para que poidas descargar a alta velocidade, quizais non saques o máximo de Clickhouse, pero escriba polo menos 100 megabytes por segundo desde unha máquina a través dun proxy inverso. isto o esquema debe escalar tanto a grandes como a pequenas cantidades, polo que non podemos esperar un segundo por cada inserción, polo que debe ser asíncrona. E do mesmo xeito, as confirmacións asíncronas deberían chegar despois de que se complete a inserción. Saberemos se pasou ou non.
O máis importante é que neste esquema sabemos con certeza se a inserción se produciu ou non. Imaxina esta situación: tes unha táboa de búfer, escribiches algo nela e despois, digamos, a táboa pasou ao modo de só lectura e intentou limpar o búfer. Onde irán os datos? Permanecerán no buffer. Pero non podemos estar seguros diso: que pasa se hai outro erro, debido ao cal os datos non permanecerán no búfer... (Enderezos Alexey Milovidov, Yandex, desenvolvedor ClickHouse) Ou permanecerá? Sempre? Alexey convéncenos de que todo estará ben. Non temos motivos para non crer nel. Pero igual: se non usamos táboas de memoria intermedia, non haberá ningún problema con elas. Crear o dobre de táboas tamén é un inconveniente, aínda que en principio non hai grandes problemas. Este é o plan.
Falemos da lectura
Agora imos falar da lectura. Tamén escribimos aquí a nosa propia ferramenta. Parece, ben, por que escribir o teu propio instrumento aquí?.. E quen usou Tabix? Dalgunha maneira poucas persoas levantaron a man... E quen está satisfeito coa actuación de Tabix? Ben, non estamos satisfeitos con el, e non é moi cómodo para ver datos. Está ben para analíticas, pero só para visualizalo claramente non está optimizado. Entón escribín a miña propia, a miña propia interface.
É moi sinxelo: só pode ler datos. Non sabe mostrar gráficos, non sabe facer nada. Pero pode mostrar o que necesitamos: por exemplo, cantas filas hai na táboa, canto espazo ocupa (sen dividilo en columnas), é dicir, unha interface moi básica é o que necesitamos.
E parece moi similar a Sequel Pro, pero só feito no Bootstrap de Twitter e a segunda versión. Preguntas: "Yuri, por que na segunda versión?" Que ano? 2018? En xeral, fixen isto hai moito tempo para "Muscle" (MySQL) e acabo de cambiar un par de liñas nas consultas alí, e comezou a funcionar para "Clickhouse", polo que un agradecemento especial! Porque o analizador é moi semellante ao "músculo" e as consultas son moi similares, moi conveniente, especialmente ao principio.
Ben, pode filtrar táboas, pode mostrar a estrutura e o contido da táboa, permítelle ordenar, filtrar por columnas, mostra a consulta que resultou no resultado, as filas afectadas (cantas como resultado), é dicir, o elementos básicos para ver datos. Moi rápido.
Tamén hai un editor. Sinceramente tentei roubar todo o editor de Tabix, pero non puiden. Pero dalgún xeito funciona. En principio, iso é todo.
"Clickhouse" é axeitado para madrigueras
Quero dicirvos que Clickhouse, a pesar de todos os problemas descritos, é moi axeitado para rexistros. O máis importante é que resolve o noso problema: é moi rápido e permíteche filtrar os rexistros por columnas. En principio, as táboas de memoria intermedia non funcionaron ben, pero normalmente ninguén sabe por que... Quizais agora saibas mellor onde terás problemas.
TCP? En xeral, en VK é habitual usar UDP. E cando usei TCP... Por suposto, ninguén me dixo: “Yuri, de que falas! Non podes, necesitas UDP". Resultou que TCP non é tan asustado. O único é que se tes decenas de miles de compostos activos que escribes, cómpre preparalo un pouco máis coidadosamente; pero é posible, e bastante doado.
Prometín publicar "Kittenhouse" e "Lighthouse" en HighLoad Siberia se todos se subscribían ao noso "backend VK" público... E xa sabes, non todos se subscribiron... Por suposto, non che esixirei que te subscribas ao noso público. Aínda sodes demasiados, incluso pode que alguén se ofenda, pero aínda así, subscríbanse (e aquí teño que facer ollos coma os de gato). Iso é . Moitas grazas! Github é noso . Con Clickhouse o teu cabelo será suave e sedoso.
Líder: - Amigos, agora para preguntas. Xusto despois presentamos o certificado de recoñecemento e o teu informe en VHS.
Yuri Nasretdinov (en diante YN): – Como puideches gravar o meu informe en VHS se acababa de rematar?
Líder: - Ti tamén non podes determinar completamente como funcionará ou non "Clickhouse". Amigos, 5 minutos para preguntas!
preguntas
Pregunta da audiencia (en diante, Q): - Boas tardes. Moitas grazas pola reportaxe. Teño dúas preguntas. Empezarei por algo frívolo: o número de letras t do nome "Kittenhouse" nos diagramas (3, 4, 7...) afecta á satisfacción dos gatos?
YN: - Cantidade de que?
Z: - Letra t. Hai tres t, nalgún lugar ao redor de tres t.
YN: - Non o arranxei? Ben, claro que si! Estes son produtos diferentes, só te enganei todo este tempo. Vale, estou de broma, non importa. Ah, aquí mesmo! Non, é o mesmo, cometín un erro.
Z: - Grazas. A segunda pregunta é seria. Polo que entendo, en Clickhouse, as táboas de búfer viven exclusivamente na memoria, non se almacenan no disco e, en consecuencia, non son persistentes.
YN: - Si.
Z: – E ao mesmo tempo, o seu cliente almacena no disco, o que implica certa garantía de entrega destes mesmos rexistros. Pero isto non está garantido en Clickhouse. Explica como se leva a cabo a garantía, por que?.. Aquí tes este mecanismo con máis detalle
YN: – Si, teoricamente non hai contradicións aquí, porque cando Clickhouse cae, en realidade podes detectalo dun millón de formas diferentes. Se Clickhouse falla (se remata incorrectamente), podes, grosso modo, rebobinar un pouco do teu rexistro que anotaches e comezar desde o momento en que todo estaba exactamente ben. Digamos que rebobinas un minuto, é dicir, considérase que tes lavado todo nun minuto.
Z: – É dicir, “Kittenhouse” aguanta máis tempo a fiestra e, en caso de caída, pode recoñecela e rebobinala?
YN: – Pero isto é en teoría. Na práctica, non facemos isto, e a entrega fiable é de cero a infinitas veces. Pero de media un. Estamos satisfeitos de que se Clickhouse falla por algún motivo ou se "reinician" os servidores, perdemos un pouco. En todos os demais casos non pasará nada.
Z: - Ola. Desde o primeiro momento pareceume que estarías usando UDP desde o inicio do informe. Tes http, todo iso... E a maioría dos problemas que describiches, segundo entendo, foron causados por esta solución en particular...
YN: - Que usamos TCP?
Z: -Esencialmente si.
YN: - Non
Z: – Foi con fasthttp que tiveches problemas, coa conexión tiveches problemas. Se acabases de usar UDP, aforraríaste tempo. Ben, habería problemas con mensaxes longas ou outra cousa...
YN: - Con que?
Z: – Con mensaxes longas, xa que pode non caber no MTU, outra cousa... Pois pode haber problemas propios. A pregunta é: por que non UDP?
YN: – Creo que os autores que desenvolveron TCP/IP son moito máis intelixentes ca min e saben mellor ca min como serializar paquetes (para que vaian), ao mesmo tempo axustar a ventá de envío, non sobrecargar a rede, dar comentarios sobre o que non se le, sen contar co outro lado... Todos estes problemas, na miña opinión, existirían en UDP, só que eu tería que escribir aínda máis código do que xa escribín para poder implementar eu o mesmo e moi probablemente mal. Nin sequera me gusta escribir en C, e menos aínda...
Z: - Simplemente cómodo! Enviouse ben e non esperes nada: é completamente asíncrono. Volveu unha notificación de que todo estaba ben, isto significa que chegou; Se non chega, significa que está mal.
YN: – Necesito os dous – Necesito poder enviar os dous con garantía de entrega e sen garantía de entrega. Son dous escenarios diferentes. Necesito non perder algúns rexistros ou non perdelos dentro do razoable.
Z: -Non vou perder o tempo. Isto hai que discutilo máis. Grazas.
Líder: – Quen ten preguntas – mans ao ceo!
Z: - Ola, son Sasha. Nalgún lugar no medio do informe, apareceu a sensación de que, ademais de TCP, era posible utilizar unha solución preparada: algún tipo de Kafka.
YN: – Pois... díxenche que non quero usar servidores intermedios, porque... en Kafka, resulta que temos dez mil hosts; de feito, temos máis: decenas de miles de anfitrións. Tamén pode ser doloroso facer con Kafka sen ningún proxy. Ademais, o máis importante, aínda dá "latencia", dá hosts adicionais que debes ter. Pero non quero telos, quero...
Z: "Pero ao final resultou así".
YN: – Non, non hai anfitrións! Todo isto funciona nos hosts de Clickhouse.
Z: - Ben, e "Kittenhouse", que é ao revés - onde vive?
YN: – No servidor Clickhouse, non escribe nada no disco.
Z: - Supoñamos.
Líder: – Estás satisfeito? Podemos darche un soldo?
Z: - Si que podes. De feito, hai moitas muletas para conseguir o mesmo, e agora - a resposta anterior sobre o tema do TCP contradí, na miña opinión, esta situación. Parece que todo se puido facer de xeonllos en moito menos tempo.
YN: – E tamén por que non quería usar Kafka, porque había bastantes queixas no chat de Clickhouse Telegram de que, por exemplo, se perderon mensaxes de Kafka. Non de Kafka en si, senón na integración de Kafka e Clickhaus; ou algo non conectou alí. En grandes liñas, sería necesario escribir un cliente para Kafka entón. Non creo que poida haber unha solución máis sinxela ou fiable.
Z: – Dime, por que non probaches ningunha cola nin algún tipo de autobús común? Xa que dis que coa asincronía poderías enviar os propios rexistros a través da cola e recibir a resposta de forma asíncrona a través da cola?
YN: – Por favor, suxire que filas se poden usar?
Z: – Calquera, aínda que non teña garantía de que están en regra. Algún tipo de Redis, RMQ...
YN: – Teño a sensación de que Redis probablemente non poderá tirar tal volume de inserción nin sequera nun servidor (no sentido de varios servidores) que saca Clickhouse. Non podo apoiar isto con ningunha proba (non o fixen de referencia), pero paréceme que Redis non é a mellor solución aquí. En principio, este sistema pode considerarse como unha cola de mensaxes improvisada, pero que só se adapta a "Clickhouse"
Líder: - Yuri, moitas grazas. Propoño rematar aquí as preguntas e as respostas e dicir a quen dos que fixeron a pregunta lle daremos o libro.
YN: – Gustaríame regalarlle un libro á primeira persoa que fixo unha pregunta.
Líder: - Marabilloso! Genial! Fabuloso! Moitas grazas!
Algúns anuncios 🙂
Grazas por estar connosco. Gústanche os nosos artigos? Queres ver máis contido interesante? Apóyanos facendo un pedido ou recomendando a amigos, , un análogo único de servidores de nivel de entrada, que inventamos nós para ti: (dispoñible con RAID1 e RAID10, ata 24 núcleos e ata 40 GB DDR4).
Dell R730xd 2 veces máis barato no centro de datos Equinix Tier IV en Amsterdam? Só aquí nos Países Baixos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - desde $ 99! Ler sobre
Fonte: www.habr.com