HighLoad++ Moscú 2018, Salón de Congresos. 9 de noviembre, 15:00
Resúmenes y presentación:
Yuri Nasretdinov (VKontakte): el informe hablará sobre la experiencia de implementar ClickHouse en nuestra empresa: por qué lo necesitamos, cuántos datos almacenamos, cómo los escribimos, etc.
Materiales adicionales:
Yuri Nasretdinov: - ¡Hola a todos! Mi nombre es Yuri Nasretdinov, como ya me han presentado. Trabajo en VKontakte. Hablaré sobre cómo insertamos datos en ClickHouse desde nuestra flota de servidores (decenas de miles).
¿Qué son los registros y por qué recopilarlos?
Lo que le diremos: qué hicimos, por qué necesitábamos "ClickHouse", respectivamente, por qué lo elegimos, qué tipo de rendimiento se puede obtener aproximadamente sin configurar nada especialmente. Les contaré más sobre las tablas de buffer, sobre los problemas que tuvimos con ellas y sobre nuestras soluciones que desarrollamos a partir de código abierto: KittenHouse y Lighthouse.
¿Por qué teníamos que hacer algo (en VKontakte todo siempre va bien, verdad?). Queríamos recopilar registros de depuración (y había cientos de terabytes de datos allí), tal vez de alguna manera sería más conveniente calcular estadísticas; y tenemos una flota de decenas de miles de servidores desde los cuales es necesario hacer todo esto.
¿Por qué decidimos? Probablemente teníamos soluciones para almacenar registros. Aquí hay un "Backend VK" público. Recomiendo encarecidamente suscribirse.
¿Qué son los registros? Este es un motor que devuelve matrices vacías. Los motores en VK son lo que otros llaman microservicios. Y aquí tienes una pegatina sonriente (bastantes me gusta). ¿Cómo es eso? Bueno, ¡escucha más!
¿Qué se puede utilizar para almacenar registros? Es imposible no mencionar a Hadup. Luego, por ejemplo, Rsyslog (almacenando estos registros en archivos). LSD. ¿Quién sabe qué es el LSD? No, este LSD no. Almacene archivos, respectivamente, también. Bueno, ClickHouse es una opción extraña.
Clickhouse y competidores: requisitos y oportunidades
¿Qué queremos? Queremos asegurarnos de que no tenemos que preocuparnos demasiado por el funcionamiento, para que funcione desde el primer momento, preferiblemente con una configuración mínima. Queremos escribir mucho y escribir rápido. Y queremos conservarlo durante todo tipo de meses, años, es decir, durante mucho tiempo. Es posible que queramos entender algún problema con el que vinieron a nosotros y nos dijeron: "Algo no funciona aquí", y eso fue hace 3 meses), y queremos poder ver qué sucedió hace 3 meses " La compresión de datos (está claro por qué sería una ventaja) porque reduce la cantidad de espacio que ocupa.
Y tenemos un requisito tan interesante: a veces escribimos la salida de algunos comandos (por ejemplo, registros), que puede tener más de 4 kilobytes con bastante facilidad. Y si esto funciona a través de UDP, entonces no necesita gastar... no habrá ningún "gasto general" para la conexión, y para una gran cantidad de servidores esto será una ventaja.
Veamos qué nos ofrece el código abierto. En primer lugar, tenemos Logs Engine: este es nuestro motor; En principio, puede hacer de todo, incluso puede escribir largas líneas. Bueno, no comprime datos de forma transparente: podemos comprimir columnas grandes nosotros mismos si queremos... nosotros, por supuesto, no queremos (si es posible). El único problema es que sólo puede regalar lo que cabe en su memoria; Para leer el resto, es necesario obtener el binlog de este motor y, en consecuencia, lleva bastante tiempo.
¿Qué otras opciones hay? Por ejemplo, "Hadup". Facilidad de operación... ¿Quién piensa que Hadup es fácil de configurar? Por supuesto, no hay problemas con la grabación. Al leer a veces surgen preguntas. En principio, diría que probablemente no, especialmente en el caso de los registros. Almacenamiento a largo plazo, por supuesto, sí, compresión de datos, sí, cadenas largas, está claro que se puede grabar. Pero grabar desde una gran cantidad de servidores... ¡Aún tienes que hacer algo tú mismo!
Rsyslog. De hecho, lo usamos como opción de respaldo para poder leerlo sin volcar el binlog, pero no puede escribir líneas largas; en principio, no puede escribir más de 4 kilobytes. Usted mismo debe realizar la compresión de datos de la misma manera. La lectura provendrá de archivos.
Luego está el desarrollo “badushka” del LSD. Esencialmente lo mismo que “Rsyslog”: admite cadenas largas, pero no puede funcionar a través de UDP y, de hecho, debido a esto, desafortunadamente, es necesario reescribir muchas cosas allí. Es necesario rediseñar LSD para poder grabar desde decenas de miles de servidores.
¡Y aquí! Una opción divertida es ElasticSearch. ¿Cómo decir? Le va bien en lectura, es decir, lee rápido, pero no muy bien en escritura. En primer lugar, si comprime datos, es muy débil. Lo más probable es que una búsqueda completa requiera estructuras de datos más grandes que el volumen original. Es difícil de operar y a menudo surgen problemas. Y, nuevamente, grabar en Elastic: tenemos que hacerlo todo nosotros mismos.
Aquí ClickHouse es una opción ideal, por supuesto. Lo único es que grabar desde decenas de miles de servidores es un problema. Pero al menos hay un problema, podemos intentar solucionarlo de alguna manera. Y el resto del informe trata sobre este problema. ¿Qué tipo de rendimiento puede esperar de ClickHouse?
¿Cómo lo vamos a insertar? Fusionarárbol
¿Quién de vosotros no ha oído hablar o no conoce “ClickHouse”? Necesito decírtelo, ¿no? Muy rapido. La inserción allí (1-2 gigabits por segundo, ráfagas de hasta 10 gigabits por segundo realmente pueden soportar esta configuración): hay dos Xeon de 6 núcleos (es decir, ni siquiera los más potentes), 256 gigabytes de RAM, 20 terabytes en RAID (nadie configurado, configuración predeterminada). Alexey Milovidov, desarrollador de ClickHouse, probablemente esté sentado llorando porque no configuramos nada (todo funcionó así para nosotros). En consecuencia, se puede obtener una velocidad de escaneo de, digamos, aproximadamente 6 mil millones de líneas por segundo si los datos están bien comprimidos. Si le gusta % en una cadena de texto, es decir, 100 millones de líneas por segundo, parece bastante rápido.
¿Cómo lo vamos a insertar? Bueno, sabes que VK usa PHP. Insertaremos desde cada trabajador PHP a través de HTTP en “ClickHouse”, en la tabla MergeTree para cada registro. ¿Quién ve un problema con este esquema? Por alguna razón, no todos levantaron la mano. Déjame decirte.
En primer lugar, hay muchos servidores; en consecuencia, habrá muchas conexiones (malas). Entonces es mejor insertar datos en MergeTree no más de una vez por segundo. ¿Y quién sabe por qué? Bien bien. Te contaré un poco más sobre esto. Otra pregunta interesante es que no hacemos análisis, no necesitamos enriquecer los datos, no necesitamos servidores intermedios, queremos insertarlos directamente en "ClickHouse" (preferiblemente, cuanto más directamente, mejor).
En consecuencia, ¿cómo se realiza la inserción en MergeTree? ¿Por qué es mejor insertarlo no más de una vez por segundo o menos? El hecho es que "ClickHouse" es una base de datos en columnas y ordena los datos en orden ascendente de la clave principal, y cuando realiza una inserción, se crea una cantidad de archivos al menos igual a la cantidad de columnas en las que se ordenan los datos. en orden ascendente de la clave principal (se crea un directorio separado, un conjunto de archivos en el disco para cada inserción). Luego viene la siguiente inserción y, en el fondo, se combinan en "particiones" más grandes. Dado que los datos están ordenados, es posible "fusionar" dos archivos ordenados sin consumir mucha memoria.
Pero, como puede imaginar, si escribe 10 archivos para cada inserción, ClickHouse (o su servidor) finalizará rápidamente, por lo que se recomienda insertar en lotes grandes. En consecuencia, nunca pusimos en producción el primer plan. Inmediatamente lanzamos uno, que aquí el número 2 tiene:
Imaginemos que hay alrededor de mil servidores en los que hemos iniciado, solo hay PHP. Y en cada servidor está nuestro agente local, al que llamamos “Kittenhouse”, que mantiene una conexión con “ClickHouse” e inserta datos cada pocos segundos. Inserta datos no en MergeTree, sino en una tabla de búfer, lo que sirve precisamente para evitar insertarlos directamente en MergeTree de inmediato.
Trabajar con tablas de buffer
¿Lo que es? Las tablas de búfer son una parte de la memoria que está fragmentada (es decir, se puede insertar en ella con frecuencia). Consisten en varias piezas, y cada una de ellas funciona como un buffer independiente, y se vacían de forma independiente (si tiene muchas piezas en el buffer, habrá muchas inserciones por segundo). Es posible leer desde estas tablas; luego lee la unión del contenido del búfer y la tabla principal, pero en este momento la escritura está bloqueada, por lo que es mejor no leer desde allí. Y las tablas de buffer muestran muy buenos QPS, es decir, hasta 3 mil QPS no tendrás ningún problema al insertar. Está claro que si el servidor se queda sin energía, entonces los datos se pueden perder, porque solo estaban almacenados en la memoria.
Al mismo tiempo, el esquema con un búfer complica ALTER, porque primero debe eliminar la tabla de búfer anterior con el esquema anterior (los datos no desaparecerán en ninguna parte, porque se borrarán antes de que se elimine la tabla). Luego "altera" la tabla que necesita y crea la tabla de búfer nuevamente. En consecuencia, hasta que no haya una tabla de búfer, sus datos no fluirán a ninguna parte, pero puede tenerlos en el disco al menos localmente.
¿Qué es Kittenhouse y cómo funciona?
¿Qué es KittyHouse? Este es un proxy. ¿Adivina qué idioma? Recopilé los temas más publicitados en mi informe: "Clickhouse", vaya, tal vez recuerde algo más. Sí, esto está escrito en Go, porque realmente no sé escribir en C, no quiero.
En consecuencia, mantiene una conexión con cada servidor y puede escribir en la memoria. Por ejemplo, si escribimos registros de errores en Clickhouse, entonces si Clickhouse no tiene tiempo para insertar datos (después de todo, si se escribe demasiado), entonces no hinchamos la memoria, simplemente tiramos el resto. Porque si escribimos varios gigabits por segundo de errores, probablemente podamos descartar algunos. Kittenhouse puede hacer esto. Además, puede realizar una entrega confiable, es decir, escribir en el disco de la máquina local y una vez cada vez (allí, una vez cada dos segundos) intenta entregar datos desde este archivo. Y al principio utilizamos el formato de Valores normal, no un formato binario, sino un formato de texto (como en SQL normal).
Pero entonces sucedió esto. Usamos una entrega confiable, escribimos registros y luego decidimos (era un grupo de prueba condicional)... Se apagó durante varias horas y se volvió a activar, y se inició una inserción desde mil servidores; resultó que Clickhouse todavía tenía un "Subproceso al conectarse": en consecuencia, en mil conexiones, una inserción activa conduce a una carga promedio en el servidor de aproximadamente mil quinientos. Sorprendentemente, el servidor aceptó las solicitudes, pero los datos aún se insertaron después de un tiempo; pero al servidor le costó mucho servirlo...
Agregar nginx
Una solución de este tipo para el modelo Thread por conexión es nginx. Instalamos nginx frente a Clickhouse, al mismo tiempo configuramos el equilibrio para dos réplicas (nuestra velocidad de inserción aumentó 2 veces, aunque no es un hecho que deba ser así) y limitamos el número de conexiones a Clickhouse, al aguas arriba y, en consecuencia, más de 50 conexiones, parece que no tiene sentido insertar.
Luego nos dimos cuenta de que este esquema generalmente tiene desventajas, porque aquí solo tenemos un nginx. En consecuencia, si este nginx falla, a pesar de la presencia de réplicas, perdemos datos o, al menos, no escribimos en ninguna parte. Por eso creamos nuestro propio equilibrio de carga. También nos dimos cuenta de que "Clickhouse" todavía es adecuado para registros, y el "demonio" también comenzó a escribir sus registros en "Clickhouse", muy conveniente, para ser honesto. Todavía lo usamos para otros "demonios".
Luego descubrimos este interesante problema: si utiliza un método de inserción no estándar en modo SQL, fuerza un analizador SQL completo basado en AST, que es bastante lento. En consecuencia, hemos agregado configuraciones para garantizar que esto nunca suceda. Hicimos equilibrio de carga, comprobaciones de estado, de modo que si uno muere, aún dejemos los datos. Ahora tenemos muchas tablas que necesitamos para tener diferentes grupos de Clickhouse. Y también comenzamos a pensar en otros usos; por ejemplo, queríamos escribir registros desde módulos nginx, pero no saben cómo comunicarse usando nuestro RPC. Bueno, me gustaría enseñarles cómo enviar al menos de alguna manera, por ejemplo, recibir eventos en localhost a través de UDP y luego reenviarlos a Clickhouse.
A un paso de la solución
El esquema final comenzó a verse así (la cuarta versión de este esquema): en cada servidor frente a Clickhouse hay nginx (en el mismo servidor) y simplemente envía solicitudes a localhost con un límite en el número de conexiones de 50 piezas. Y este esquema ya estaba funcionando bastante, todo iba bastante bien.
Vivimos así durante aproximadamente un mes. Todos estaban contentos, agregaron tablas, agregaron, agregaron... En general, resultó que la forma en que agregamos tablas de buffer no fue muy óptima (digámoslo así). Hicimos 16 piezas en cada mesa y un intervalo de flash de un par de segundos; Teníamos 20 tablas y cada tabla recibía 8 inserciones por segundo, y en ese momento comenzó “Clickhouse”... los registros comenzaron a disminuir. Ni siquiera pasaron... Nginx por defecto tenía algo tan interesante que si las conexiones terminaban en el flujo ascendente, simplemente devolvía "502" a todas las solicitudes nuevas.
Y aquí tenemos (acabo de mirar los registros en Clickhouse) aproximadamente el medio por ciento de las solicitudes fallaron. En consecuencia, la utilización del disco fue alta y hubo muchas fusiones. Bueno, ¿qué hice? Naturalmente, no me molesté en averiguar por qué exactamente terminó la conexión y el flujo ascendente.
Reemplazo de nginx con un proxy inverso
Decidí que teníamos que administrar esto nosotros mismos, no necesitamos dejárselo a nginx; nginx no sabe qué tablas hay en Clickhouse y reemplacé nginx con un proxy inverso, que también escribí yo mismo.
¿Qué está haciendo? Funciona basándose en la biblioteca fasthttp “goshnoy”, es decir, rápido, casi tan rápido como nginx. Lo siento, Igor, si estás presente aquí (nota: Igor Sysoev es un programador ruso que creó el servidor web nginx). Puede comprender qué tipo de consultas son (INSERTAR o SELECCIONAR) y, en consecuencia, mantiene diferentes grupos de conexiones para diferentes tipos de consultas.
En consecuencia, incluso si no tenemos tiempo para completar las solicitudes de inserción, las "selecciones" pasarán y viceversa. Y agrupa los datos en tablas de búfer - con un búfer pequeño: si hubiera algún error, errores de sintaxis, etc. - para que no afecten mucho al resto de los datos, porque cuando simplemente los insertamos en tablas de búfer, tenía "bachi" pequeño, y todos los errores de sintaxis sólo afectaban a esta pequeña pieza; y aquí ya afectarán a un gran búfer. Pequeño es 1 megabyte, es decir, no tan pequeño.
Insertar una sincronización y esencialmente reemplazar nginx hace esencialmente lo mismo que hacía nginx antes: no es necesario cambiar el "Kittenhouse" local para esto. Y como utiliza fasthttp, es muy rápido: puede realizar más de 100 mil solicitudes por segundo para inserciones individuales a través de un proxy inverso. En teoría, puedes insertar una línea a la vez en el proxy inverso de la casa del gatito, pero, por supuesto, no hacemos eso.
El esquema empezó a verse así: “Kittenhouse”, el proxy inverso agrupa muchas solicitudes en tablas y, a su vez, las tablas buffer las insertan en las principales.
Killer es una solución temporal, Kitten es permanente.
Este es un problema interesante... ¿Alguno de ustedes ha usado fasthttp? ¿Quién usó fasthttp con solicitudes POST? Probablemente, esto realmente no debería haberse hecho, porque almacena el cuerpo de la solicitud de forma predeterminada y nuestro tamaño de búfer se estableció en 16 megabytes. La inserción dejó de mantenerse en algún momento y comenzaron a llegar fragmentos de 16 megabytes de las decenas de miles de servidores, y todos se almacenaron en la memoria antes de enviarlos a Clickhouse. En consecuencia, la memoria se agotó, el asesino de la falta de memoria vino y mató al proxy inverso (o "Clickhouse", que en teoría podría "comer" más que el proxy inverso). El ciclo se repitió. No es un problema muy agradable. Aunque nos topamos con esto sólo después de varios meses de funcionamiento.
¿Qué he hecho? Una vez más, no me gusta mucho entender qué pasó exactamente. Creo que es bastante obvio que no deberías almacenarlo en la memoria. No pude parchear fasthttp, aunque lo intenté. Pero encontré una manera de hacerlo para que no fuera necesario parchear nada, y se me ocurrió mi propio método en HTTP: lo llamé KITTEN. Bueno, es lógico: "VK", "Gatito"... ¿Qué más?...
Si llega una solicitud al servidor con el método Kitten, entonces el servidor debería responder "miau", lógicamente. Si responde a esto, entonces se considera que comprende este protocolo y luego intercepto la conexión (fasthttp tiene ese método) y la conexión pasa al modo "sin procesar". ¿Por qué lo necesito? Quiero controlar cómo se realiza la lectura de las conexiones TCP. TCP tiene una propiedad maravillosa: si nadie lee desde el otro lado, entonces la escritura comienza a esperar y no se gasta mucha memoria en esto.
Y entonces leo a unos 50 clientes a la vez (de cincuenta, porque cincuenta deberían ser suficientes, incluso si la tarifa proviene de otro centro de distribución)... El consumo ha disminuido con este enfoque al menos 20 veces, pero, para ser honesto, , no pude medir exactamente en qué momento, porque ya no tiene sentido (ya alcanzó el nivel de error). El protocolo es binario, es decir, contiene el nombre de la tabla y los datos; no hay encabezados http, por lo que no utilicé un socket web (no necesito comunicarme con los navegadores; creé un protocolo que se adapta a nuestras necesidades). Y todo salió bien para él.
La mesa de amortiguamiento está triste.
Recientemente nos encontramos con otra característica interesante de las tablas de búfer. Y este problema ya es mucho más doloroso que los demás. Imaginemos esta situación: ya estás usando Clickhouse activamente, tienes docenas de servidores Clickhouse y tienes algunas solicitudes que tardan mucho en leerse (digamos, más de 60 segundos); y vienes y haces Alter en este momento... Mientras tanto, las "selecciones" que comenzaron antes de "Alter" no se incluirán en esta tabla, "Alter" no se iniciará; probablemente algunas características de cómo funciona "Clickhouse" en este lugar. ¿Quizás esto pueda solucionarse? ¿O acaso no es posible?
En general, está claro que en realidad esto no es un problema tan grande, pero con las tablas de búfer se vuelve más doloroso. Porque, si, digamos, su "Alter" agota el tiempo de espera (y puede que se agote el tiempo de espera en otro host, no en el suyo, sino en una réplica, por ejemplo), entonces... Usted eliminó la tabla de buffer, su "Alter" ( o algún otro host) expiró el tiempo de espera, luego se produjo un error de "Alteración") - aún debe asegurarse de que los datos continúen escribiéndose: vuelva a crear las tablas de búfer (de acuerdo con el mismo esquema que la tabla principal), luego "Alterar" continúa, termina después de todo, y el búfer de la tabla comienza a diferir en esquema del padre. Dependiendo de cuál fue el "Alterar", es posible que la inserción ya no vaya a esta tabla de búfer; esto es muy triste.
También existe un letrero de este tipo (tal vez alguien lo haya notado): se llama query_thread_log en las nuevas versiones de Clickhouse. Por defecto, en alguna versión había uno. Aquí hemos acumulado 840 millones de registros en un par de meses (100 gigas). Esto se debe al hecho de que allí se escribieron "insertos" (tal vez ahora, por cierto, no estén escritos). Como les dije, nuestras "inserciones" son pequeñas; teníamos muchas "inserciones" en las tablas de búfer. Está claro que esto está deshabilitado; solo les cuento lo que vi en nuestro servidor. ¿Por qué? ¡Este es otro argumento en contra del uso de tablas de búfer! Spotty está muy triste.
¿Quién sabía que el nombre de este tipo era Spotty? Los empleados de VK levantaron la mano. DE ACUERDO.
Sobre los planes para “KitttenHouse”
Los planes normalmente no se comparten, ¿verdad? De repente no los cumplirás y no quedarás muy bien ante los ojos de los demás. ¡Pero me arriesgaré! Queremos hacer lo siguiente: me parece que las tablas de búfer siguen siendo una muleta y necesitamos almacenar en búfer la inserción nosotros mismos. Pero todavía no queremos almacenarlo en el disco, por lo que almacenaremos la inserción en la memoria.
En consecuencia, cuando se realiza una "inserción", ya no será sincrónica: ya funcionará como una tabla de búfer, se insertará en la tabla principal (bueno, algún día más tarde) e informará a través de un canal separado qué inserciones han pasado y cuáles. no tengo.
¿Por qué no puedo dejar el inserto sincrónico? Es mucho más conveniente. El hecho es que si inserta desde 10 mil hosts, entonces todo está bien: obtendrá un poco de cada host, lo inserta allí una vez por segundo, todo está bien. Pero me gustaría que este esquema funcione, por ejemplo, desde dos máquinas, para que pueda descargar a alta velocidad; tal vez no aproveche Clickhouse al máximo, pero escriba al menos 100 megabytes por segundo desde una máquina a través de un proxy inverso. Para ello el esquema debe escalar tanto a cantidades grandes como pequeñas, por lo que no podemos esperar un segundo para cada inserción, por lo que debe ser asíncrono. Y de la misma manera, las confirmaciones asincrónicas deberían llegar después de que se haya completado la inserción. Sabremos si pasó o no.
Lo más importante es que en este esquema sabemos con certeza si la inserción se realizó o no. Imagine esta situación: tiene una tabla de búfer, escribió algo en ella y luego, digamos, la tabla entró en modo de solo lectura e intentó vaciar el búfer. ¿A dónde irán los datos? Permanecerán en el buffer. Pero no podemos estar seguros de esto: ¿qué pasa si hay algún otro error por el cual los datos no permanecerán en el búfer... (Se dirige a Alexey Milovidov, Yandex, desarrollador de ClickHouse) ¿O permanecerá? ¿Siempre? Alexey nos convence de que todo estará bien. No tenemos ninguna razón para no creerle. Pero de todos modos: si no utilizamos tablas de búfer, no habrá ningún problema con ellas. Crear el doble de tablas también es un inconveniente, aunque en principio no hay grandes problemas. Este es el plan.
hablemos de lectura
Ahora hablemos de lectura. También escribimos nuestra propia herramienta aquí. Parecería, bueno, ¿por qué escribir aquí tu propio instrumento?... ¿Y quién usó Tabix? De alguna manera pocas personas levantaron la mano... ¿Y quién está satisfecho con el desempeño de Tabix? Bueno, no estamos contentos con esto y no es muy conveniente para ver datos. Está bien para análisis, pero solo para visualización claramente no está optimizado. Así que escribí mi propia interfaz.
Es muy simple: sólo puede leer datos. No sabe mostrar gráficos, no sabe hacer nada. Pero puede mostrar lo que necesitamos: por ejemplo, cuántas filas hay en la tabla, cuánto espacio ocupa (sin dividirla en columnas), es decir, lo que necesitamos es una interfaz muy básica.
Y se parece mucho a Sequel Pro, pero solo se creó en Bootstrap de Twitter y la segunda versión. Preguntas: "Yuri, ¿por qué en la segunda versión?" ¿Qué año? 2018? En general, hice esto hace bastante tiempo para "Muscle" (MySQL) y simplemente cambié un par de líneas en las consultas allí, y comenzó a funcionar para "Clickhouse", ¡por lo cual muchas gracias! Porque el analizador es muy similar al "músculo" y las consultas son muy similares, muy convenientes, especialmente al principio.
Bueno, puede filtrar tablas, puede mostrar la estructura y el contenido de la tabla, le permite ordenar, filtrar por columnas, muestra la consulta que generó el resultado, las filas afectadas (cuántas como resultado), es decir, el Cosas básicas para ver datos. Muy rápido.
También hay un editor. Sinceramente, intenté robarle todo el editor a Tabix, pero no pude. Pero de alguna manera funciona. En principio, eso es todo.
"Clickhouse" es adecuado para guaridas
Quiero decirles que Clickhouse, a pesar de todos los problemas descritos, es muy adecuado para registros. Lo más importante es que resuelve nuestro problema: es muy rápido y le permite filtrar registros por columnas. En principio, las tablas de búfer no han funcionado bien, pero normalmente nadie sabe por qué... Quizás ahora sepas mejor dónde tendrás problemas.
TCP? En general, en VK se acostumbra utilizar UDP. Y cuando usé TCP... Por supuesto, nadie me dijo: “¡Yuri, de qué estás hablando! No puedes, necesitas UDP”. Resultó que TCP no da tanto miedo. Lo único es que, si tienes decenas de miles de compuestos activos que escribes, debes prepararlos con un poco más de cuidado; pero es posible y bastante fácil.
Prometí publicar “Kittenhouse” y “Lighthouse” en HighLoad Siberia si todos se suscribieran a nuestro “backend VK” público... Y ya sabes, no todos se suscribieron... Por supuesto, no exigiré que te suscribas a nuestro público. Todavía sois muchos, puede que alguno incluso se ofenda, pero aún así, suscríbete (y aquí tengo que poner ojos como los de un gato). Eso es . ¡Muchas gracias! Github es nuestro . Con Clickhouse tu cabello quedará suave y sedoso.
Moderador: - Amigos, ahora para preguntas. Inmediatamente después le presentamos el certificado de agradecimiento y su informe en VHS.
Yuri Nasretdinov (en adelante, YN): – ¿Cómo pudiste grabar mi reportaje en VHS si recién terminó?
Moderador: – ¡Tampoco puedes determinar completamente cómo funcionará o no “Clickhouse”! Amigos, ¡5 minutos para preguntas!
preguntas
Pregunta de la audiencia (en adelante, Q): - Buenas tardes. Muchas gracias por el informe. Tengo dos preguntas. Empezaré con algo frívolo: ¿el número de letras t del nombre "Kittenhouse" en los diagramas (3, 4, 7...) afecta la satisfacción de los gatos?
SN: - ¿Cantidad de qué?
З: – Letra t. Hay tres tes, alrededor de tres tes.
SN: - ¿No lo arreglé? ¡Bueno, por supuesto que lo hace! Estos son productos diferentes; te estuve engañando todo este tiempo. Está bien, estoy bromeando, no importa. ¡Ah, aquí mismo! No, es lo mismo, cometí un error tipográfico.
З: - Gracias. La segunda pregunta es seria. Según tengo entendido, en Clickhouse las tablas de búfer viven exclusivamente en la memoria, no se almacenan en el disco y, en consecuencia, no son persistentes.
SN: - Sí.
З: – Y al mismo tiempo, su cliente almacena en el disco, lo que implica cierta garantía de entrega de estos mismos registros. Pero en Clickhouse esto no está garantizado en absoluto. Explique cómo se realiza la garantía, ¿por qué?.. Aquí se detalla este mecanismo
SN: – Sí, teóricamente no hay contradicciones aquí, porque cuando Clickhouse cae, en realidad puedes detectarlo de un millón de maneras diferentes. Si Clickhouse falla (si finaliza incorrectamente), puede, en términos generales, rebobinar un poco del registro que anotó y comenzar desde el momento en que todo estaba exactamente bien. Digamos que rebobinas un minuto, es decir, se considera que has vaciado todo en un minuto.
З: – Es decir, ¿“Kittenhouse” sostiene la ventana por más tiempo y, en caso de caída, puede reconocerla y rebobinarla?
SN: – Pero esto es en teoría. En la práctica, no hacemos esto y la entrega confiable es de cero a infinitos tiempos. Pero en promedio uno. Estamos convencidos de que si Clickhouse falla por algún motivo o los servidores se "reinician", perderemos un poco. En todos los demás casos, no pasará nada.
З: - Hola. Desde el principio me pareció que efectivamente estaría utilizando UDP desde el principio del informe. Tienes http, todo eso... Y la mayoría de los problemas que describiste, según tengo entendido, fueron causados por esta solución en particular...
SN: – ¿Para qué utilizamos TCP?
З: - Básicamente sí.
SN: -No
З: – Fue con fasthttp que tuviste problemas, con la conexión tuviste problemas. Si hubiera utilizado UDP, se habría ahorrado algo de tiempo. Bueno, habría problemas con mensajes largos o algo más...
SN: - ¿Con que?
З: – Con mensajes largos, ya que puede que no quepa en la MTU, otra cosa... Bueno, puede haber problemas propios. La pregunta es: ¿por qué no UDP?
SN: – Creo que los autores que desarrollaron TCP/IP son mucho más inteligentes que yo y saben mejor que yo cómo serializar paquetes (para que vayan), al mismo tiempo ajustar la ventana de envío, no sobrecargar la red, dar retroalimentación sobre qué no se lee, sin contar en el otro lado... Todos estos problemas, en mi opinión, existirían en UDP, solo que tendría que escribir aún más código del que ya escribí para poder implementar lo mismo yo mismo y muy probablemente mal. Ni siquiera me gusta mucho escribir en C, y mucho menos allí...
З: - ¡Simplemente conveniente! Enviado correctamente y no esperes nada: es completamente asincrónico. Llegó una notificación de que todo estaba bien, eso significa que llegó; Si no llega, significa que está mal.
SN: – Necesito ambos – Necesito poder enviar ambos con garantía de entrega y sin garantía de entrega. Estos son dos escenarios diferentes. Necesito no perder algunos registros o no perderlos dentro de lo razonable.
З: – No perderé el tiempo. Esto necesita ser discutido más. Gracias.
Moderador: – Quien tenga preguntas – ¡manos al cielo!
З: - Hola, soy Sasha. En algún lugar a mitad del informe, apareció la sensación de que, además de TCP, era posible utilizar una solución ya preparada: una especie de Kafka.
SN: – Bueno… te dije que no quiero usar servidores intermedios, porque… en Kafka, resulta que tenemos diez mil hosts; de hecho, tenemos más: decenas de miles de hosts. También puede resultar doloroso trabajar con Kafka sin ningún representante. Además, lo más importante es que todavía proporciona "latencia", proporciona hosts adicionales que necesita tener. Pero no quiero tenerlos - quiero...
З: “Pero al final resultó así de todos modos”.
SN: – ¡No, no hay anfitriones! Todo esto funciona en los hosts de Clickhouse.
З: - Bueno, y “Kittenhouse”, que es al revés, ¿dónde vive?
SN: – En el host de Clickhouse, no escribe nada en el disco.
З: - Supongamos.
Moderador: - ¿Estás satisfecho? ¿Podemos darte un salario?
З: - Sí tu puedes. De hecho, hay muchas muletas para conseguir lo mismo, y ahora, la respuesta anterior sobre el tema TCP contradice, en mi opinión, esta situación. Siento que todo se podría haber hecho de rodillas en mucho menos tiempo.
SN: – Y también por qué no quería usar Kafka, porque hubo muchas quejas en el chat de Clickhouse Telegram de que, por ejemplo, se perdían mensajes de Kafka. No de Kafka en sí, sino de la integración de Kafka y Clickhaus; o algo no se conectó allí. En términos generales, entonces sería necesario escribir un cliente para Kafka. No creo que pueda haber una solución más sencilla o más fiable.
З: – Dime, ¿por qué no probaste ninguna cola o algún tipo de autobús común? ¿Ya que dice que con asincronía podría enviar los registros a través de la cola y recibir la respuesta de forma asincrónica a través de la cola?
SN: – ¿Sugiera qué colas podrían utilizarse?
З: – Cualquiera, incluso sin garantía de que estén en regla. Algún tipo de Redis, RMQ...
SN: – Tengo la sensación de que lo más probable es que Redis no pueda generar tal volumen de inserción ni siquiera en un host (en el sentido de varios servidores) que extrae Clickhouse. No puedo respaldar esto con ninguna evidencia (no lo he evaluado), pero me parece que Redis no es la mejor solución en este caso. En principio, este sistema se puede considerar como una cola de mensajes improvisada, pero diseñada únicamente para “Clickhouse”.
Moderador: – Yuri, muchas gracias. Propongo terminar aquí las preguntas y respuestas y decir a cuál de los que hicieron la pregunta le daremos el libro.
SN: – Me gustaría regalar un libro a la primera persona que hiciera una pregunta.
Moderador: - ¡Maravilloso! ¡Excelente! ¡Fabuloso! ¡Muchas gracias!
Algunos anuncios 🙂
Gracias por estar con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más contenido interesante? Apóyanos haciendo un pedido o recomendándonos a amigos, , un análogo único de servidores de nivel de entrada, que fue inventado por nosotros para usted: (disponible con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).
Dell R730xd 2 veces más barato en el centro de datos Equinix Tier IV en Amsterdam? Solo aqui ¡en los Paises Bajos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ¡desde $99! Leer acerca de
Fuente: habr.com