{"id":80775,"date":"2020-05-08T13:42:47","date_gmt":"2020-05-08T11:42:47","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah"},"modified":"2020-05-08T13:42:47","modified_gmt":"2020-05-08T11:42:47","slug":"clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah","title":{"rendered":"ClickHouse para usuarios avanzados en preguntas y respuestas","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>En abril, los ingenieros de Avito se reunieron en un encuentro en l\u00ednea con el principal desarrollador de ClickHouse, Alexey Milovidov, y Kirill Shvakov, un desarrollador de Golang de la empresa Integros. Se discutieron c\u00f3mo usamos el sistema de gesti\u00f3n de bases de datos y las dificultades que enfrentamos. <\/p>\n<p><\/p>\n<p>A partir de la reuni\u00f3n, hemos recopilado un art\u00edculo con las respuestas de los expertos a nuestras preguntas y las de los espectadores sobre copias de seguridad, re-sharding de datos, diccionarios externos, el controlador de Golang y la actualizaci\u00f3n de versiones de ClickHouse. Puede ser \u00fatil para los desarrolladores que ya est\u00e1n trabajando activamente con la base de datos de 'Yandex' y que est\u00e1n interesados en su presente y futuro. Por defecto, las respuestas son de Alexey Milovidov, a menos que se indique lo contrario. <\/p>\n<p><\/p>\n<p>Cuidado, hay mucho texto bajo el corte. Esperamos que el contenido con las preguntas te ayude a orientarte.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"ClickHouse para usuarios avanzados en preguntas y respuestas\" src=\"\/wp-content\/uploads\/2020\/05\/242b1d8d002fe115614435c242297fd2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2 id=\"soderzhanie\">Contenido<\/h2>\n<p><\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"#old-data\">ClickHouse se actualiza constantemente, pero nuestros datos no. \u00bfQu\u00e9 se puede hacer al respecto?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#backup-best-practicies\">\u00bfCu\u00e1les son las mejores pr\u00e1cticas en este momento para hacer copias de seguridad de datos desde ClickHouse?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#replication\">\u00bfSe podr\u00e1 organizar un retraso controlado de las r\u00e9plicas en los flujos?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#soooo-changeable\">\u00bfQu\u00e9 hacer si la estructura de la tabla ha cambiado?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#resharding-best-practices\">\u00bfCu\u00e1les son las mejores pr\u00e1cticas actuales en el re-sharding de datos?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#clickhouse-copier\">ClickHouse tiene una utilidad llamada clickhouse-copier. \u00bfPuedes hablarnos de ella?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#resharding-tool\">Ten\u00edas una prueba piloto que se llamaba re-sharding. \u00bfQu\u00e9 pas\u00f3 con eso?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#move-to-slow-disk\">\u00bfSe pueden unir todas las partes de los datos antes de moverlas a discos lentos?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#up-to-date\">\u00bfC\u00f3mo migrar a nuevas versiones de ClickHouse si no hay posibilidad de comprobar la compatibilidad con anticipaci\u00f3n?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#kill-query\">El kill query deber\u00eda matar consultas, pero no lo hace. \u00bfPor qu\u00e9?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#reading-time\">\u00bfC\u00f3mo calcular el tiempo de respuesta bajo carga de lectura?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#pimp-my-clickhouse\">\u00bfQu\u00e9 se puede ajustar en ClickHouse para que m\u00e1s datos est\u00e9n en la cach\u00e9?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#storage-configuration\">\u00bfC\u00f3mo se puede configurar storage_configuration para almacenamiento en memoria?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#low-cardinality\">\u00bfHasta cu\u00e1ntos valores \u00fanicos es eficaz Low Cardinality?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#fulltext-search\">\u00bfCu\u00e1les son las mejores pr\u00e1cticas para la b\u00fasqueda de texto completo en una tabla con cinco mil millones de filas?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#hello-and-welcome\">\u00bfC\u00f3mo organizar mejor el acceso a ClickHouse para un gran n\u00famero de usuarios?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#smorgasbord\">\u00bfSe pueden enviar los resultados de una consulta a diez clientes?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#asynchronous\">\u00bfQu\u00e9 hacer con las operaciones as\u00edncronas y las vistas materializadas?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#dashboard\">ClickHouse genera muchos logs. \u00bfC\u00f3mo puedo ver todo lo que ocurre con el servidor en tiempo real?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#zen\">\u00bfC\u00f3mo influir en los merges para que el servidor no se bloquee por agotamiento de memoria?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#go\">\u00bfC\u00f3mo se desarrollar\u00e1 el controlador de Golang para ClickHouse?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#lazy-load\">El diccionario externo no se carga despu\u00e9s de reiniciar con la opci\u00f3n lazy_load habilitada. \u00bfQu\u00e9 hacer?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#reload-dictionaries\">\u00bfC\u00f3mo manejar el hecho de que system reload dictionaries no carga ninguno de los m\u00faltiples diccionarios si al menos uno de ellos falla con un error?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#connection\">\u00bfHay alguna forma de configurar las credenciales en&nbsp;la configuraci\u00f3n de ClickHouse sin que se expongan en caso de errores?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#zoom-backgrounds\">Bonus: fondos para Zoom de&nbsp;reuniones<\/a><\/noindex><\/li>\n<\/ul>\n<p><\/p>\n<blockquote><p>Si no quieres leer el texto, puedes ver la grabaci\u00f3n de las reuniones. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=n1tm4j4W8ZQ&amp;t=8147s\">en&nbsp;nuestro canal de YouTube<\/a><\/noindex>. Los tiempos est\u00e1n en&nbsp;el primer comentario debajo del v\u00eddeo.<\/p><\/blockquote>\n<p><\/p>\n<h2 id=\"anchorold-dataanchorclickhouse-postoyanno-obnovlyaetsya-a-nashi-dannyenbsp-net-chto-snbspetim-delat\"><noindex><a rel=\"nofollow\" name=\"old-data\"><\/a><\/noindex>ClickHouse se actualiza constantemente, pero nuestros datos&nbsp;no. \u00bfQu\u00e9 se puede hacer al respecto?<\/h2>\n<p><\/p>\n<blockquote><p>ClickHouse se actualiza constantemente, pero nuestros datos, que fueron procesados por optimize final, no se actualizan y permanecen en&nbsp;una copia de seguridad. <\/p>\n<p>Supongamos que tuvimos alg\u00fan tipo de problema y se perdieron datos. Decidimos recuperar y nos dimos cuenta de que las particiones antiguas, que est\u00e1n almacenadas en&nbsp;los servidores de copias de seguridad, difieren mucho de la versi\u00f3n de ClickHouse que estamos utilizando en este momento. \u00bfQu\u00e9 hacer en esta situaci\u00f3n, es posible?<\/p><\/blockquote>\n<p>La situaci\u00f3n en la que restauraste datos de una copia de seguridad en&nbsp;un formato antiguo y la nueva versi\u00f3n no los reconoce no es posible. Nos aseguramos de que el formato de los datos en&nbsp;ClickHouse siempre sea compatible hacia atr\u00e1s. Esto es mucho m\u00e1s importante que la compatibilidad funcional, en caso de que el comportamiento de alguna funci\u00f3n poco utilizada cambie. La nueva versi\u00f3n de ClickHouse siempre debe poder leer los datos almacenados en&nbsp;disco. Esa es la regla. <\/p>\n<p><\/p>\n<h2 id=\"anchorbackup-best-practiciesanchorkakie-luchshie-praktiki-est-nanbspdannyy-moment-ponbsprezervnomu-kopirovaniyu-dannyh-iznbspclickhouse\"><noindex><a rel=\"nofollow\" name=\"backup-best-practicies\"><\/a><\/noindex>\u00bfCu\u00e1les son las mejores pr\u00e1cticas en este momento para hacer copias de seguridad de datos desde ClickHouse?<\/h2>\n<p><\/p>\n<blockquote><p>\u00bfC\u00f3mo hacer copias de seguridad teniendo en cuenta que tenemos operaciones optimize final, una enorme base de datos de varios terabytes y datos que se actualizan, supongamos, en los \u00faltimos tres d\u00edas, y no se realizan m\u00e1s procedimientos? <\/p>\n<p>Podemos crear nuestra propia soluci\u00f3n y escribir en&nbsp;la terminal: recopila as\u00ed y as\u00ed estas copias de seguridad. Puede que no sea necesario improvisar nada, \u00bfy el ciclo ya ha sido inventado? <\/p><\/blockquote>\n<p>Para empezar, en relaci\u00f3n con las mejores pr\u00e1cticas. Mis colegas siempre recomiendan, en respuesta a preguntas sobre copias de seguridad, recordar el servicio 'Yandex. Nube', donde esta tarea ya est\u00e1 resuelta. As\u00ed que usen ese servicio si tienen la oportunidad. <\/p>\n<p><\/p>\n<p>No hay una soluci\u00f3n completa, cien por ciento integrada en&nbsp;ClickHouse, para copias de seguridad. Hay algunos esquemas que se pueden utilizar. Para obtener una soluci\u00f3n completa, ser\u00e1 necesario trabajar un poco manualmente o hacer envolturas en forma de scripts.<\/p>\n<p><\/p>\n<p>Comenzar\u00e9 con las soluciones m\u00e1s simples y terminar\u00e9 con las m\u00e1s complejas dependiendo del volumen de datos y el tama\u00f1o del cl\u00faster. Cuanto m\u00e1s grande es el cl\u00faster, m\u00e1s complicado se vuelve la soluci\u00f3n.<\/p>\n<p><\/p>\n<p>Si la tabla de datos ocupa solo unos pocos gigabytes, se puede hacer una copia de seguridad as\u00ed: <\/p>\n<p><\/p>\n<ol>\n<li>Guardar la definici\u00f3n de las tablas, es decir, los metadatos \u2014 <strong>show create table<\/strong>.<\/li>\n<li>Hacer un volcado utilizando el cliente de ClickHouse \u2014 <strong>select<\/strong> * <strong>from table<\/strong> en un archivo. Por defecto, obtendr\u00e1s un archivo en formato TabSeparated. Si deseas algo m\u00e1s eficiente, puedes optar por el formato Native. <\/li>\n<\/ol>\n<p><\/p>\n<p>Si el volumen de datos es mayor, la copia de seguridad tomar\u00e1 m\u00e1s tiempo y ocupar\u00e1 m\u00e1s espacio. Esto se llama copia de seguridad l\u00f3gica, que no est\u00e1 vinculada al formato de datos de ClickHouse. Si la tienes, en el peor de los casos, podr\u00e1s tomar la copia de seguridad y cargarla en MySQL para su restauraci\u00f3n. <\/p>\n<p><\/p>\n<p>Para casos m\u00e1s avanzados, ClickHouse tiene la capacidad incorporada de crear un snapshot de las particiones en el sistema de archivos local. Esta funcionalidad est\u00e1 disponible en forma de consulta. <strong>alter table freeze partition<\/strong>. O simplemente <strong>alter table freeze<\/strong> \u2014 esto es una instant\u00e1nea de toda la tabla. <\/p>\n<p><\/p>\n<p>El snapshot se crear\u00e1 de manera consistente para una tabla en un shard, es decir, no es posible crear un snapshot consistente para todo el cl\u00faster de esta manera. Pero para la mayor\u00eda de las tareas, no hay tal necesidad, y es suficiente ejecutar la consulta en cada shard y obtener un snapshot consistente. Se crea en forma de hard links y, por lo tanto, no ocupa espacio adicional. Luego, copias este snapshot en el servidor de respaldo o en el almacenamiento que uses para las copias de seguridad.<\/p>\n<p><\/p>\n<p>Restaurar tal copia de seguridad es bastante f\u00e1cil. Primero, creas las tablas seg\u00fan las definiciones de tablas disponibles. Luego, copias los snapshots de particiones guardados en Directory-Detached para las tablas de datos y ejecutas la consulta. <strong>attach partition<\/strong>. Esta soluci\u00f3n es adecuada para los vol\u00famenes de datos m\u00e1s serios. <\/p>\n<p><\/p>\n<p>A veces se requiere algo a\u00fan m\u00e1s impresionante \u2014 en aquellos casos en que tienes decenas o incluso cientos de terabytes en cada servidor y cientos de servidores. Aqu\u00ed hay una soluci\u00f3n que observ\u00e9 de mis colegas en \u2018Yandex.Metrics\u2019. No lo recomendar\u00eda a todos \u2014 lee y decide si es adecuado o no. <\/p>\n<p><\/p>\n<p>Primero, es necesario crear varios servidores con grandes estantes de disco. A continuaci\u00f3n, en estos servidores, se deben levantar varios servidores de ClickHouse y configurarlos para que operen como otra r\u00e9plica para los mismos shards. Luego, se puede utilizar en estos servidores un sistema de archivos o alguna herramienta que permita crear instant\u00e1neas. Hay dos opciones aqu\u00ed. La primera opci\u00f3n son las instant\u00e1neas de LVM, la segunda opci\u00f3n es ZFS en Linux. <\/p>\n<p><\/p>\n<p>Despu\u00e9s de esto, es necesario crear una instant\u00e1nea cada d\u00eda, la cual ocupar\u00e1 cierto espacio. Por supuesto, si los datos cambian, con el tiempo el volumen de espacio aumentar\u00e1. Esta instant\u00e1nea se puede recuperar en cualquier momento y restaurar los datos, es una soluci\u00f3n algo extra\u00f1a. Adem\u00e1s, hay que limitar estas r\u00e9plicas en la configuraci\u00f3n para que no intenten convertirse en l\u00edderes.<\/p>\n<p><\/p>\n<h2 id=\"anchorreplicationanchormozhno-li-budet-organizovat-kontroliruemoe-otstavanie-replik-vnbspvalah\"><noindex><a rel=\"nofollow\" name=\"replication\"><\/a><\/noindex>\u00bfSe podr\u00e1 organizar un retraso controlado de las r\u00e9plicas en los flujos?<\/h2>\n<p><\/p>\n<blockquote><p>Este a\u00f1o planean hacer anillos en ClickHouse. \u00bfSe podr\u00e1 organizar un retraso controlado de las r\u00e9plicas en ellos? Nos gustar\u00eda usarlo para protegernos de escenarios negativos con alteraciones y otros cambios. <\/p>\n<p>\u00bfSe pueden hacer algunos rollbacks para los alteradores? Por ejemplo, en el anillo existente, se puede decir que hasta este momento apliquen los cambios, y a partir de este momento dejen de aplicar cambios.<\/p>\n<p>Si en nuestro cl\u00faster lleg\u00f3 un comando y lo rompi\u00f3, entonces tenemos una r\u00e9plica condicional con un retraso de una hora, donde podemos decir que vamos a usarla en este momento, pero no aplicaremos los \u00faltimos diez minutos de cambios en ella? <\/p><\/blockquote>\n<p>Primero, sobre el retraso controlado de las r\u00e9plicas. Hubo tal solicitud por parte de los usuarios, y creamos un issue en GitHub con la petici\u00f3n: 'Si a alguien le interesa, denle un like, un coraz\u00f3n'. Nadie lo hizo, y el issue se cerr\u00f3. Sin embargo, ya ahora es posible obtener esta funci\u00f3n, configurando ClickHouse. Aunque, solo a partir de la versi\u00f3n 20.3.<\/p>\n<p><\/p>\n<p>ClickHouse constantemente realiza la fusi\u00f3n de datos en segundo plano. Cuando se completa la fusi\u00f3n, un conjunto de fragmentos de datos se reemplaza por un fragmento m\u00e1s grande. Sin embargo, los fragmentos de datos que exist\u00edan anteriormente contin\u00faan permaneciendo en el disco durante un tiempo determinado.<\/p>\n<p><\/p>\n<p>En primer lugar, contin\u00faan almacen\u00e1ndose hasta que hay consultas select que las utilizan, para asegurar un funcionamiento no bloqueante. Las consultas select pueden leer sin problemas de segmentos antiguos.<\/p>\n<p><\/p>\n<p>En segundo lugar, hay un umbral de tiempo: los segmentos antiguos de datos permanecen en el disco durante ocho minutos. Estos ocho minutos se pueden ajustar y convertir incluso en un d\u00eda. Esto ocupar\u00e1 espacio en el disco: dependiendo del flujo de datos, puede resultar que los datos del \u00faltimo d\u00eda no solo se doblen, sino que pueden aumentar hasta cinco veces m\u00e1s. Pero podr\u00e1s detener el servidor de ClickHouse ante un problema serio y resolverlo.<\/p>\n<p><\/p>\n<p>Ahora surge la pregunta de c\u00f3mo esto protege contra los alters. Aqu\u00ed es necesario profundizar, porque en las versiones antiguas de ClickHouse, el alter funcionaba cambiando directamente los segmentos. Hay un segmento de datos con ciertos archivos, y hacemos, por ejemplo, <strong>alter drop column<\/strong>. Entonces, esa columna se elimina f\u00edsicamente de todos los segmentos.<\/p>\n<p><\/p>\n<p>Pero a partir de la versi\u00f3n 20.3, el mecanismo de los alters se ha cambiado completamente, y ahora los segmentos de datos son siempre inmutables. No cambian en absoluto; los alters ahora funcionan de manera similar a los merges. En lugar de cambiar un segmento en su lugar, creamos uno nuevo. En el nuevo segmento, los archivos que no han cambiado se convierten en hardlinks, y si hemos eliminado alguna columna, simplemente no estar\u00e1 presente en el nuevo segmento. El antiguo segmento se eliminar\u00e1 por defecto despu\u00e9s de ocho minutos, y aqu\u00ed se pueden ajustar las configuraciones mencionadas anteriormente. <\/p>\n<p><\/p>\n<p>Lo mismo ocurre con los alters de tipo mutaciones. Cuando haces <strong>alter delete<\/strong> o <strong>alter update<\/strong>, no modifica la parte, sino que crea una nueva. Y luego elimina la antigua.<\/p>\n<p><\/p>\n<h2 id=\"anchorsoooo-changeableanchorkak-byt-esli-struktura-tablicy-pomenyalas\"><noindex><a rel=\"nofollow\" name=\"soooo-changeable\"><\/a><\/noindex>\u00bfQu\u00e9 hacer si la estructura de la tabla ha cambiado?<\/h2>\n<p><\/p>\n<blockquote><p>\u00bfC\u00f3mo levantar un backup que se realiz\u00f3 con un esquema antiguo? Y la segunda pregunta sobre el caso de los snapshots y los medios del sistema de archivos. \u00bfSirve Btrfs en lugar de ZFS en Linux LVM en este caso?<\/p><\/blockquote>\n<p>Si haces <strong>attach partition<\/strong> particiones con otra estructura, entonces ClickHouse te dir\u00e1 que no se puede. La soluci\u00f3n es la siguiente. Primero, crear una tabla temporal de tipo MergeTree con la estructura antigua, adjuntar los datos con attach, hacer la consulta alter. Luego, se puede copiar o mover esos datos y hacer attach nuevamente, o utilizar la consulta <strong>alter table move partition<\/strong>.<\/p>\n<p><\/p>\n<p>Ahora la segunda pregunta&nbsp;\u2014 \u00bfse puede usar Btrfs? Para empezar, si tiene LVM, entonces basta con los snapshots de LVM, y el sistema de archivos puede ser ext4, no importa. Con Btrfs, todo depende de su experiencia en su uso. Es un sistema de archivos maduro, pero siempre hay ciertas dudas sobre c\u00f3mo funcionar\u00e1 en la pr\u00e1ctica en un escenario espec\u00edfico. No lo recomendar\u00eda si no tiene Btrfs en producci\u00f3n.<\/p>\n<p><\/p>\n<h2 id=\"anchorresharding-best-practicesanchorkakie-seychas-luchshie-praktiki-vnbspreshardinge-dannyh\"><noindex><a rel=\"nofollow\" name=\"resharding-best-practices\"><\/a><\/noindex>\u00bfCu\u00e1les son las mejores pr\u00e1cticas actuales en el re-sharding de datos?<\/h2>\n<p><\/p>\n<p>La pregunta sobre el re-sharding es compleja y multifac\u00e9tica. Aqu\u00ed se puede responder de varias maneras. Se puede abordar desde un lado y decir que en ClickHouse no hay una funcionalidad integrada para re-shardar. Pero temo que esta respuesta no satisfar\u00e1 a nadie. Por lo tanto, se puede abordar desde el otro lado y decir que en ClickHouse hay muchas maneras de re-shardar datos. <\/p>\n<p><\/p>\n<p>Si se acaba el espacio en el cl\u00faster o no puede manejar la carga, usted agrega nuevos servidores. Pero estos servidores est\u00e1n vac\u00edos por defecto, no tienen datos y no reciben ninguna carga. Necesita redistribuir los datos para que est\u00e9n uniformemente repartidos en el nuevo cl\u00faster m\u00e1s grande.<\/p>\n<p><\/p>\n<p>La primera manera de hacerlo es copiar parte de las particiones en los nuevos servidores mediante una consulta. <strong>alter table fetch partition<\/strong>. Por ejemplo, si ten\u00eda particiones por meses, toma el primer mes de 2017 y lo copia en el nuevo servidor, luego copia el tercer mes en otro nuevo servidor. Y as\u00ed lo hace hasta que est\u00e9 m\u00e1s o menos equilibrado.<\/p>\n<p><\/p>\n<p>La transferencia solo se puede realizar para aquellas particiones que no cambian al escribir. Para las particiones recientes, deber\u00e1 desactivar la escritura, porque su transferencia no es at\u00f3mica. De lo contrario, obtendr\u00e1 duplicados o faltantes en los datos. Sin embargo, este m\u00e9todo es pr\u00e1ctico y funciona de manera bastante efectiva. Se env\u00edan por la red particiones comprimidas ya listas, es decir, los datos no se vuelven a comprimir ni a re-codificar.<\/p>\n<p><\/p>\n<p>Este m\u00e9todo tiene una desventaja, y depende del esquema de particionado; se refiere a c\u00f3mo se dise\u00f1\u00f3 este esquema y cu\u00e1l fue la clave de particionado. En su ejemplo, para el caso de m\u00e9tricas, la clave de particionado es el hash de la ruta. Cuando ejecuta un select en la tabla distribuida, se dirige a todos los shards del cl\u00faster y recupera los datos de all\u00ed. <\/p>\n<p><\/p>\n<p>Esto significa que, en realidad, no importa qu\u00e9 datos se encuentren en qu\u00e9 shard. Lo importante es que los datos de una misma ruta est\u00e9n en el mismo shard, aunque no sea relevante cu\u00e1l en espec\u00edfico. En este caso, el traslado de las particiones existentes es muy apropiado, ya que al realizar las consultas select, ya sea antes o despu\u00e9s del re-particionado, la estructura de valores no importa \u2013 recibir\u00e1 datos completos.<\/p>\n<p><\/p>\n<p>Sin embargo, hay casos m\u00e1s complejos. Si, a nivel de la l\u00f3gica de la aplicaci\u00f3n, tiene un esquema de particionado espec\u00edfico que determina que este cliente est\u00e1 en un shard particular, puede enviar la consulta directamente all\u00ed, en lugar de usar la tabla distribuida. O puede usar una versi\u00f3n relativamente nueva de ClickHouse y haber activado la configuraci\u00f3n. <strong>optimize skip unused shards<\/strong>En este caso, durante la consulta select, la expresi\u00f3n en la secci\u00f3n where ser\u00e1 analizada, y se calcular\u00e1 a qu\u00e9 shards es necesario ir de acuerdo con el esquema de particionado. Esto funciona a condici\u00f3n de que los datos est\u00e9n realmente organizados de acuerdo con ese esquema de particionado. Si los ha reorganizado manualmente, la correspondencia puede cambiar.<\/p>\n<p><\/p>\n<p>As\u00ed que este es el m\u00e9todo n\u00famero uno. Espero tu respuesta, si este m\u00e9todo es adecuado o si seguimos adelante.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobaev, administrador de sistemas l\u00edder en Avito<\/strong>: Alexey, el m\u00e9todo que mencionaste no se adapta bien cuando se necesita distribuir la carga tambi\u00e9n en lectura. Podemos tomar una partici\u00f3n mensual y mover el mes anterior a otro nodo, pero cuando llegue una consulta por esos datos, solo estaremos sobrecargando ese nodo. Y nos gustar\u00eda distribuir la carga en todo el cl\u00faster, porque, de lo contrario, durante un tiempo toda la carga en lectura ser\u00e1 manejada por solo dos shards.<\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> La respuesta aqu\u00ed es extra\u00f1a: s\u00ed, es malo, pero puede funcionar. Te explico c\u00f3mo. Se debe observar el escenario de carga que llega a sus datos. Si son datos de monitoreo, casi con certeza se puede decir que la gran mayor\u00eda de las consultas son por datos recientes. <\/p>\n<p><\/p>\n<p>Has configurado nuevos servidores, trasladado particiones antiguas, pero tambi\u00e9n has cambiado la forma en que se registran los datos nuevos. Y los datos nuevos se dispersar\u00e1n por todo el cl\u00faster. As\u00ed, despu\u00e9s de cinco minutos, las consultas de los \u00faltimos cinco minutos cargar\u00e1n uniformemente el cl\u00faster, despu\u00e9s de un d\u00eda, las consultas del d\u00eda cargar\u00e1n uniformemente el cl\u00faster. Y, lamentablemente, las consultas del mes anterior solo afectar\u00e1n a una parte de los servidores del cl\u00faster.<\/p>\n<p><\/p>\n<p>Pero a menudo no tendr\u00e1s consultas espec\u00edficamente de febrero de 2019. Es m\u00e1s probable que, si las consultas son del a\u00f1o 2019, sean de todo el a\u00f1o 2019, es decir, de un intervalo grande, y no de un rango peque\u00f1o. Y esas consultas tambi\u00e9n podr\u00e1n cargar uniformemente el cl\u00faster. Pero en general, tu observaci\u00f3n es completamente v\u00e1lida, ya que es una soluci\u00f3n ad hoc que no distribuye los datos de manera completamente uniforme.<\/p>\n<p><\/p>\n<p>Tengo algunos puntos m\u00e1s para responder a la pregunta. Uno de ellos es c\u00f3mo hacer inicialmente el esquema de particionado de tal manera que haya menos dolor al re-particionar. Esto no siempre es posible.<\/p>\n<p><\/p>\n<p>Por ejemplo, tienes datos de monitoreo. Los datos de monitoreo crecen por tres razones. La primera es la acumulaci\u00f3n de datos hist\u00f3ricos. La segunda es el aumento del tr\u00e1fico. Y la tercera es el incremento en la cantidad de elementos que caen bajo monitoreo. Aparecen nuevos microservicios y m\u00e9tricas que necesitan ser almacenadas. <\/p>\n<p><\/p>\n<p>Es posible que el mayor crecimiento est\u00e9 relacionado precisamente con la tercera raz\u00f3n: el aumento en el uso del monitoreo. En este caso, vale la pena observar la naturaleza de la carga, cu\u00e1les son las principales consultas de selecci\u00f3n. Las principales consultas de selecci\u00f3n probablemente se dirigir\u00e1n a un subconjunto de m\u00e9tricas.<\/p>\n<p><\/p>\n<p>Por ejemplo, el uso de CPU en ciertos servidores por parte de alg\u00fan servicio. As\u00ed que hay un subconjunto de claves del que obtienes esos datos. Y la propia consulta para esos datos, probablemente, es bastante simple y se ejecuta en d\u00e9cimas de milisegundo. Se utiliza para servicios de monitoreo, para dashboards. Espero estar entendiendo esto correctamente.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobaev:<\/strong> La cuesti\u00f3n es que a menudo apelamos a datos hist\u00f3ricos, ya que estamos comparando en tiempo real la situaci\u00f3n actual con la hist\u00f3rica. Y para nosotros es importante tener un acceso r\u00e1pido a un gran volumen de datos, y ClickHouse lo hace excelentemente.<\/p>\n<p><\/p>\n<p>Tienes absolutamente raz\u00f3n, la mayor\u00eda de las solicitudes de lectura que experimentamos son del \u00faltimo d\u00eda, al igual que cualquier sistema de monitoreo. Sin embargo, la carga sobre los datos hist\u00f3ricos tambi\u00e9n es bastante grande. Principalmente proviene del sistema de alertas, que cada treinta segundos consulta a ClickHouse: 'Dame los datos de las \u00faltimas seis semanas. Y ahora construyamos una media m\u00f3vil a partir de ellos y comparemos el valor actual con el hist\u00f3rico.' <\/p>\n<p><\/p>\n<p>Me gustar\u00eda mencionar que tenemos una peque\u00f1a tabla para estas solicitudes muy recientes, donde almacenamos solo dos d\u00edas de datos, y las solicitudes principales se env\u00edan all\u00ed. Solo enviamos grandes solicitudes hist\u00f3ricas a una tabla distribuida m\u00e1s grande.<\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> Desafortunadamente, para su escenario resulta poco aplicable, pero describir\u00e9 dos esquemas de partici\u00f3n complejos y malos que no se deben utilizar, pero que se utilizan en el servicio de mis amigos. <\/p>\n<p><\/p>\n<p>Hay un cl\u00faster principal con eventos de 'Yandex.Metrica'. Los eventos son vistas de p\u00e1ginas, clics y transiciones. La mayor\u00eda de las solicitudes se dirigen a un sitio web espec\u00edfico. Abres el servicio 'Yandex.Metrica', tienes un sitio \u2014 avito.ru, accedes al informe y se realiza una solicitud para tu sitio.<\/p>\n<p><\/p>\n<p>Pero tambi\u00e9n hay otras solicitudes: anal\u00edticas y globales, que realizan los analistas internos. Como nota, los analistas internos solo realizan solicitudes para los servicios de 'Yandex'. Sin embargo, incluso los servicios de 'Yandex' representan una parte considerable de todos los datos. Estas son solicitudes no para contadores espec\u00edficos, sino para filtraciones m\u00e1s amplias.<\/p>\n<p><\/p>\n<p>\u00bfC\u00f3mo organizar los datos de tal manera que funcione de manera eficiente tanto para un contador como para solicitudes globales? La complejidad radica tambi\u00e9n en que la cantidad de solicitudes en ClickHouse para el cl\u00faster de 'Metrica' es de varios miles por segundo. Sin embargo, solicitudes no triviales, por ejemplo, varios miles por segundo, un solo servidor de ClickHouse no puede manejar.<\/p>\n<p><\/p>\n<p>El tama\u00f1o del cl\u00faster es un poco m\u00e1s de seiscientos servidores. Si simplemente estiramos una tabla distribuida sobre este cl\u00faster y enviamos all\u00ed varios miles de solicitudes, ser\u00e1 a\u00fan peor que enviarlas a un solo servidor. Por otro lado, la opci\u00f3n de que los datos est\u00e9n repartidos uniformemente y que vayamos a solicitarlos de todos los servidores, la descartamos de inmediato.<\/p>\n<p><\/p>\n<p>Hay una opci\u00f3n diametralmente opuesta. Imagina que vamos a fragmentar los datos por sitios, y que la solicitud para un sitio en particular va a un solo fragmento. Ahora el cl\u00faster podr\u00e1 gestionar sin problemas diez mil solicitudes por segundo, pero en un \u00fanico fragmento, una determinada solicitud funcionar\u00e1 demasiado lento. Ya no se escalar\u00e1 en t\u00e9rminos de capacidad. Especialmente si se trata del sitio avito.ru. No revelar\u00e9 ning\u00fan secreto al decir que Avito es uno de los sitios m\u00e1s visitados en la red rusa. Y procesarlo en un solo fragmento ser\u00eda una locura.<\/p>\n<p><\/p>\n<p>Por lo tanto, el esquema de fragmentaci\u00f3n est\u00e1 dise\u00f1ado de forma m\u00e1s ingeniosa. Todo el cl\u00faster se divide en una serie de cl\u00fasteres m\u00e1s peque\u00f1os, que llamamos capas. Dentro de cada cl\u00faster de estos hay desde decenas hasta varios grupos de fragmentos. Y en total hay treinta y nueve de estos cl\u00fasteres. <\/p>\n<p><\/p>\n<p>\u00bfC\u00f3mo se escala todo esto? La cantidad de cl\u00fasteres no cambia: hace varios a\u00f1os eran treinta y nueve y sigue siendo la misma. Pero dentro de cada uno de ellos, aumentamos gradualmente el n\u00famero de fragmentos a medida que acumulamos datos. Y el esquema de fragmentaci\u00f3n en general es el siguiente: la divisi\u00f3n en estos cl\u00fasteres se realiza por sitios web, y para entender qu\u00e9 sitio est\u00e1 en qu\u00e9 cl\u00faster, se utiliza una base de metadatos separada en MySQL. Un sitio est\u00e1 en un solo cl\u00faster. Y dentro de \u00e9l, la fragmentaci\u00f3n se realiza seg\u00fan los identificadores de los visitantes.<\/p>\n<p><\/p>\n<p>Al registrar, los dividimos seg\u00fan el residuo de la divisi\u00f3n del identificador del visitante. Pero al agregar un nuevo shard, el esquema de sharding cambia. Continuamos dividiendo, pero seg\u00fan el residuo de la divisi\u00f3n por otro n\u00famero. Esto significa que un visitante realmente puede estar en varios servidores, y no se puede contar con ello. Esto se hizo exclusivamente para que los datos se comprimieran mejor. Y al realizar las consultas, vamos a la tabla Distributed, que mira al cluster y se conecta a decenas de servidores. As\u00ed es como funciona este complicado esquema.<\/p>\n<p><\/p>\n<p>Pero mi relato no estar\u00eda completo si no mencionara que hemos abandonado este esquema. En el nuevo esquema, cambiamos todo y copiamos todos los datos utilizando clickhouse-copier.<\/p>\n<p><\/p>\n<p>En el nuevo esquema, todos los sitios se dividen en dos categor\u00edas: grandes y peque\u00f1os. No s\u00e9 c\u00f3mo se eligi\u00f3 el umbral, pero el resultado es que los sitios grandes se almacenan en un solo cluster, donde hay 120 shards con tres r\u00e9plicas en cada uno, es decir, 360 servidores. Y el esquema de sharding es tal que cualquier consulta se env\u00eda a todos los shards simult\u00e1neamente. Si ahora abres en 'Yandex.Metrica' cualquier p\u00e1gina de informe para avito.ru, la consulta se dirigir\u00e1 a 120 servidores. Hay pocos sitios grandes en la red rusa. Por lo tanto, el n\u00famero de consultas no llega a mil por segundo, sino que es incluso menos de cien. Todo esto es manejado sin problemas por la tabla Distributed, que es gestionada por 120 servidores.<\/p>\n<p><\/p>\n<p>El segundo cluster es para los sitios peque\u00f1os. Aqu\u00ed, el esquema de sharding se basa en el identificador del sitio, y cada consulta se dirige exactamente a un shard.<\/p>\n<p><\/p>\n<h2 id=\"anchorclickhouse-copieranchorv-clickhouse-est-utilita-clickhouse-copier-mozhete-pronbspneyo-rasskazat\"><noindex><a rel=\"nofollow\" name=\"clickhouse-copier\"><\/a><\/noindex>ClickHouse tiene una utilidad llamada clickhouse-copier. \u00bfPuedes hablarnos de ella?<\/h2>\n<p><\/p>\n<p>Debo decir que esta soluci\u00f3n es m\u00e1s pesada y algo menos eficiente. La ventaja es que distribuye los datos completamente de acuerdo con el esquema que indiques. Pero el inconveniente de la herramienta es que no realiza re-sharding. Copia los datos de un esquema de cluster a otro.<\/p>\n<p><\/p>\n<p>Esto significa que para su funcionamiento necesitas tener dos clusters. Pueden estar ubicados en los mismos servidores, pero, aun as\u00ed, los datos no se mover\u00e1n de forma incremental, sino que ser\u00e1n copiados. <\/p>\n<p><\/p>\n<p>Por ejemplo, hab\u00eda cuatro servidores, ahora hay ocho. Creas una nueva tabla Distributed en todos los servidores, nuevas tablas locales y ejecutas clickhouse-copier, especificando en \u00e9l el esquema de trabajo, que debe leer de all\u00ed, tomar el nuevo esquema de particionado y trasladar los datos all\u00ed. Y necesitar\u00e1s en los servidores antiguos un espacio una vez y media m\u00e1s de lo que hay ahora, porque los datos antiguos deben permanecer en ellos, y adem\u00e1s, recibir\u00e1s la mitad de esos mismos datos antiguos. Si pensaste de antemano que los datos necesitaban ser re-particionados y hay espacio, este m\u00e9todo funcionar\u00e1.<\/p>\n<p><\/p>\n<p>\u00bfC\u00f3mo est\u00e1 estructurado clickhouse-copier internamente? Divide todo el trabajo en un conjunto de tareas para procesar una partici\u00f3n de una tabla en una shard. Todas estas tareas pueden ejecutarse en paralelo, y clickhouse-copier puede ejecutarse en diferentes m\u00e1quinas en varias instancias, pero lo que hace para una partici\u00f3n es simplemente un insert select. Los datos se leen, descomprimen, re-particionan, luego se comprimen de nuevo, se escriben en alg\u00fan lugar, se reordenan. Esta es una soluci\u00f3n m\u00e1s pesada.<\/p>\n<p><\/p>\n<h2 id=\"anchorresharding-toolanchoru-vas-byla-pilotnaya-shtuka-kotoraya-nazyvalas-resharding-chto-snbspney\"><noindex><a rel=\"nofollow\" name=\"resharding-tool\"><\/a><\/noindex>Ten\u00edas una prueba piloto que se llamaba re-sharding. \u00bfQu\u00e9 pas\u00f3 con eso?<\/h2>\n<p><\/p>\n<blockquote><p>Tuviste una cosa piloto en 2017 que se llamaba resharding. Tambi\u00e9n hay una opci\u00f3n en ClickHouse. Entiendo que esto no despeg\u00f3. \u00bfPuedes contar por qu\u00e9 pas\u00f3 as\u00ed? Parece bastante relevante.<\/p><\/blockquote>\n<p>El problema es que cuando es necesario re-particionar los datos en el lugar, se requiere una sincronizaci\u00f3n bastante compleja para hacerlo de manera at\u00f3mica. Cuando comenzamos a mirar c\u00f3mo estaba organizada esta sincronizaci\u00f3n, qued\u00f3 claro que hab\u00eda problemas fundamentales. Y esos problemas fundamentales no solo son te\u00f3ricos, sino que comenzaron a manifestarse en la pr\u00e1ctica de una manera que se puede explicar muy f\u00e1cilmente: nada funciona.<\/p>\n<p><\/p>\n<h2 id=\"anchormove-to-slow-diskanchormozhno-li-slivat-vse-chasti-dannyh-voedino-perednbspperemescheniem-nanbspmedlennye-diski\"><noindex><a rel=\"nofollow\" name=\"move-to-slow-disk\"><\/a><\/noindex>\u00bfSe pueden unir todas las partes de los datos antes de moverlas a discos lentos?<\/h2>\n<p><\/p>\n<blockquote><p>Una pregunta sobre TTL con la opci\u00f3n de mover a disco lento en el contexto de un merge. \u00bfHay alguna manera, aparte de a trav\u00e9s de cron, de fusionar todas las partes en una antes de moverlas a discos lentos?<\/p><\/blockquote>\n<p>La respuesta a la pregunta de si se puede autom\u00e1ticamente combinar todas las piezas en una antes de su traslado es: no. No creo que sea necesario. Se puede simplemente contar con que se trasladar\u00e1n a discos lentos autom\u00e1ticamente. <\/p>\n<p><\/p>\n<p>Tenemos dos criterios para la migraci\u00f3n. El primero es en funci\u00f3n del nivel de ocupaci\u00f3n. Si el almacenamiento actual tiene menos de un cierto porcentaje de espacio libre, seleccionamos un segmento y lo trasladamos a un almacenamiento m\u00e1s lento. M\u00e1s precisamente, no necesariamente m\u00e1s lento, sino el siguiente, dependiendo de c\u00f3mo lo configures.<\/p>\n<p><\/p>\n<p>El segundo criterio es por tama\u00f1o. Este se refiere a la migraci\u00f3n de grandes segmentos. Puedes ajustar el umbral de espacio libre en el disco r\u00e1pido, y los datos se someter\u00e1n a la migraci\u00f3n autom\u00e1ticamente.<\/p>\n<p><\/p>\n<h2 id=\"anchorup-to-dateanchorkak-pereezzhat-nanbspnovye-versii-clickhouse-esli-net-vozmozhnosti-zaranee-proverit-sovmestimost\"><noindex><a rel=\"nofollow\" name=\"up-to-date\"><\/a><\/noindex>\u00bfC\u00f3mo migrar a nuevas versiones de ClickHouse si no hay posibilidad de comprobar la compatibilidad con anticipaci\u00f3n?<\/h2>\n<p><\/p>\n<blockquote><p>Este tema se discute regularmente <noindex><a rel=\"nofollow\" href=\"https:\/\/teleg.run\/clickhouse_ru\">en el chat de Telegram de ClickHouse<\/a><\/noindex> teniendo en cuenta las diferentes versiones. A\u00fan as\u00ed, \u00bfqu\u00e9 tan seguro es actualizar de la versi\u00f3n 19.11 a la 19.16 y, por ejemplo, de la 19.16 a la 20.3? \u00bfCu\u00e1l es la mejor manera de migrar a nuevas versiones sin tener la posibilidad de verificar la compatibilidad en un entorno de pruebas?<\/p><\/blockquote>\n<p>Aqu\u00ed hay algunas 'reglas doradas'. La primera es <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ClickHouse\/ClickHouse\/blob\/master\/CHANGELOG.md\">lee el changelog<\/a><\/noindex>. Es extensa, pero hay secciones espec\u00edficas sobre cambios incompatibles. No debes considerar estos puntos como se\u00f1ales de advertencia. Por lo general, se trata de incompatibilidades menores relacionadas con alguna funcionalidad marginal que probablemente no est\u00e9s utilizando.<\/p>\n<p><\/p>\n<p>La segunda regla es que si no tienes la posibilidad de verificar la compatibilidad en un entorno de pruebas y deseas actualizar directamente en producci\u00f3n, la recomendaci\u00f3n es no hacerlo. Primero, crea un entorno de pruebas y verifica. Si no tienes un entorno de pruebas, probablemente tu empresa no sea muy grande, as\u00ed que puedes copiar parte de los datos a tu port\u00e1til y asegurarte de que todo funcione correctamente. Incluso puedes levantar varias r\u00e9plicas localmente en tu m\u00e1quina. Adem\u00e1s, puedes levantar una nueva versi\u00f3n en alg\u00fan lugar cercano y cargar parte de los datos, es decir, crear un entorno de prueba improvisado. <\/p>\n<p><\/p>\n<p>Otra regla es no actualizar durante la semana posterior al lanzamiento de una versi\u00f3n debido a la detecci\u00f3n de errores en producci\u00f3n y las correcciones r\u00e1pidas subsiguientes. Vamos a revisar la numeraci\u00f3n de versiones de ClickHouse para no perdernos. <\/p>\n<p><\/p>\n<p>Hay una versi\u00f3n 20.3.4. El n\u00famero 20 indica el a\u00f1o de lanzamiento, 2020. Desde el punto de vista de lo que hay dentro, esto no tiene importancia, as\u00ed que no vamos a prestarle atenci\u00f3n. Seguimos con 20.3. El segundo n\u00famero, en este caso 3, lo incrementamos cada vez que lanzamos una nueva versi\u00f3n con alguna funcionalidad nueva. Si queremos agregar alguna capacidad a ClickHouse, estamos obligados a aumentar este n\u00famero. Es decir, en la versi\u00f3n 20.4, ClickHouse funcionar\u00e1 a\u00fan mejor. El tercer n\u00famero, 20.3.4. Aqu\u00ed, 4 es la cantidad de parches lanzados, en los cuales no hemos a\u00f1adido nuevas capacidades, pero hemos corregido algunos errores. Y 4 significa que hemos hecho esto cuatro veces.<\/p>\n<p><\/p>\n<p>No hay que pensar que esto sea algo terrible. Normalmente, un usuario puede instalar la versi\u00f3n m\u00e1s reciente, y funcionar\u00e1 sin problemas y con un tiempo de actividad de un a\u00f1o. Pero imagina que en alguna funci\u00f3n para el manejo de mapas de bits, que fue a\u00f1adida por nuestros colegas chinos, al pasar argumentos incorrectos, el servidor se cae. Estamos obligados a corregirlo. Lanzaremos una nueva versi\u00f3n de parche y ClickHouse ser\u00e1 m\u00e1s estable.<\/p>\n<p><\/p>\n<p>Si tienes ClickHouse funcionando en producci\u00f3n y sale una nueva versi\u00f3n de ClickHouse con funciones adicionales, por ejemplo, 20.4.1, no te apresures a instalarla en producci\u00f3n el primer d\u00eda. \u00bfPara qu\u00e9 sirve? Si a\u00fan no est\u00e1s utilizando ClickHouse, puedes instalarla y, lo m\u00e1s probable, todo ir\u00e1 bien. Pero si ClickHouse ya funciona de manera estable, entonces presta atenci\u00f3n a los parches y actualizaciones, \u00bfqu\u00e9 problemas estamos corrigiendo?<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> Quiero a\u00f1adir un poco sobre los entornos de prueba. Todos tienen mucho miedo a los entornos de prueba y, por alguna raz\u00f3n, creen que si tienes un cl\u00faster grande de ClickHouse, entonces el entorno de prueba debe ser igual de grande o al menos diez veces m\u00e1s peque\u00f1o. No es as\u00ed.<\/p>\n<p><\/p>\n<p>Puedo hablar por experiencia propia. Tengo un proyecto en el que est\u00e1 ClickHouse. Nuestro entorno de prueba para \u00e9l es una peque\u00f1a m\u00e1quina virtual en Hetzner por veinte euros, donde todo est\u00e1 desplegado. Para hacer esto, tenemos una automatizaci\u00f3n completa en Ansible, as\u00ed que, en principio, no hay diferencia en qu\u00e9 usar: servidores f\u00edsicos o simplemente desplegar en m\u00e1quinas virtuales.<\/p>\n<p><\/p>\n<p>\u00bfQu\u00e9 se puede hacer? Ser\u00eda \u00fatil incluir en la documentaci\u00f3n de ClickHouse un ejemplo de c\u00f3mo desplegar un peque\u00f1o cl\u00faster en Docker, en LXC, o quiz\u00e1s crear un playbook de Ansible, dado que diferentes personas tienen distintos despliegues. Esto facilitar\u00eda mucho las cosas. Cuando puedes desplegar un cl\u00faster en cinco minutos, es mucho m\u00e1s sencillo intentar entender algo. Es m\u00e1s conveniente, porque llevar a producci\u00f3n una versi\u00f3n que no has probado es un camino sin salida. A veces funciona, y a veces no. Por eso, depender del \u00e9xito es un error.<\/p>\n<p><\/p>\n<p><strong>Maxim Kotiakov, ingeniero backend senior en Avito:<\/strong> Voy a a\u00f1adir algo sobre los entornos de prueba en relaci\u00f3n a los problemas de grandes empresas. Tenemos un cl\u00faster de aceptaci\u00f3n completo de ClickHouse, que es una copia exacta de lo que hay en producci\u00f3n en t\u00e9rminos de esquemas de datos y configuraciones. Este cl\u00faster se despliega en contenedores bastante limitados con recursos m\u00ednimos. Escribimos all\u00ed un cierto porcentaje de los datos de producci\u00f3n, ya que tenemos la posibilidad de replicar el flujo en Kafka. Todo est\u00e1 sincronizado y escalado, tanto en potencia como en flujo, y, en teor\u00eda, deber\u00eda comportarse como producci\u00f3n bajo condiciones iguales. Todo lo potencialmente peligroso primero se despliega en este entorno y se deja reposar durante varios d\u00edas hasta que est\u00e9 listo. Pero, por supuesto, esta soluci\u00f3n es costosa, pesada y tiene gastos de mantenimiento. <\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> Voy a contarles c\u00f3mo es el entorno de prueba de nuestros amigos de \u2018Yandex.Metrica\u2019. Un cl\u00faster ten\u00eda m\u00e1s de 600 servidores, otro 360, y hay otro cl\u00faster m\u00e1s y varios adicionales. El entorno de prueba para uno de ellos consiste en dos shards con dos r\u00e9plicas en cada uno. \u00bfPor qu\u00e9 dos shards? Para que no haya solo uno. Y tambi\u00e9n para que haya r\u00e9plicas. Simplemente, una cantidad m\u00ednima que se puede permitir.<\/p>\n<p><\/p>\n<p>Este entorno de prueba permite verificar la operatividad de las consultas y si algo grande se ha roto. Pero a menudo los problemas surgen de una naturaleza completamente diferente, cuando todo funciona, pero hay algunos peque\u00f1os cambios en la carga.<\/p>\n<p><\/p>\n<p>Voy a dar un ejemplo. Decidimos instalar una nueva versi\u00f3n de ClickHouse. Esta se ha desplegado en el entorno de prueba, se han realizado pruebas automatizadas en la misma 'Yandex.Metrica', que comparan los datos en la versi\u00f3n antigua y en la nueva, ejecutando todo el pipeline. Y, por supuesto, las pruebas pasadas de nuestro CI. De lo contrario, ni siquiera hubi\u00e9ramos propuesto esta versi\u00f3n.<\/p>\n<p><\/p>\n<p>Todo es perfecto. Comenzamos a implementar en producci\u00f3n. Recibo un mensaje de que la carga en los gr\u00e1ficos ha aumentado varias veces. Revertimos la versi\u00f3n. Miro el gr\u00e1fico y veo: la carga realmente aument\u00f3 varias veces durante el despliegue y volvi\u00f3 a reducirse cuando se implement\u00f3. Luego comenzamos a revertir la versi\u00f3n. Y la carga aument\u00f3 de la misma manera y tambi\u00e9n cay\u00f3 de nuevo. As\u00ed que la conclusi\u00f3n es que la carga aument\u00f3 debido al despliegue, nada sorprendente.<\/p>\n<p><\/p>\n<p>Luego fue dif\u00edcil convencer a los colegas de que implementaran la nueva versi\u00f3n. Les digo: 'Todo est\u00e1 bien, implementen. Mantengan los dedos cruzados, todo funcionar\u00e1. Ahora la carga ha aumentado en los gr\u00e1ficos, pero todo est\u00e1 bien. Mant\u00e9nganse firmes'. En resumen, hicimos eso, y todos: la versi\u00f3n se ha implementado en producci\u00f3n. Pero casi en cada despliegue surgen problemas similares.<\/p>\n<p><\/p>\n<h2 id=\"anchorkill-queryanchorkill-query-dolzhen-ubivat-zaprosy-no-on-etogo-ne-delaet-pochemu\"><noindex><a rel=\"nofollow\" name=\"kill-query\"><\/a><\/noindex>El kill query deber\u00eda matar consultas, pero no lo hace. \u00bfPor qu\u00e9?<\/h2>\n<p><\/p>\n<blockquote><p>Me lleg\u00f3 un usuario, un analista, y cre\u00f3 una consulta que colaps\u00f3 mi cl\u00faster de ClickHouse. Alguna nodo o el cl\u00faster completo, dependiendo de qu\u00e9 r\u00e9plica o shard recibi\u00f3 la consulta. Veo que todos los recursos en CPU en este servidor est\u00e1n en rojo. Sin embargo, ClickHouse responde a las consultas. Y escribo: 'Mu\u00e9strame, por favor, la lista de procesos, \u00bfqu\u00e9 consulta caus\u00f3 esta locura?'<\/p>\n<p>Encuentro esta consulta y le escribo kill. Y veo que no pasa nada. Mi servidor est\u00e1 en rojo, ClickHouse sigue d\u00e1ndome algunos comandos, muestra que el servidor est\u00e1 vivo y todo va bien. Pero tengo degradaci\u00f3n en todas las consultas de usuario, comienza la degradaci\u00f3n en la escritura en ClickHouse, y mi kill query no se ejecuta. \u00bfPor qu\u00e9? Pens\u00e9 que kill query deber\u00eda matar consultas, pero eso no ocurre.<\/p><\/blockquote>\n<p>Ahora tendr\u00e1 una respuesta bastante extra\u00f1a. La cuesti\u00f3n es que kill query no mata las consultas. <\/p>\n<p><\/p>\n<p>Kill query establece una peque\u00f1a bandera llamada \"quiero que esta consulta sea eliminada\". Y la consulta, al procesar cada bloque, revisa esa bandera. Si est\u00e1 establecida, la consulta deja de funcionar. Por lo tanto, nadie elimina la consulta, ella misma debe verificar todo y detenerse. Y esto deber\u00eda funcionar en todos los casos en que la consulta se encuentra en estado de procesamiento de bloques de datos. Procesar\u00e1 el siguiente bloque de datos, revisar\u00e1 la bandera y se detendr\u00e1.<\/p>\n<p><\/p>\n<p>Esto no funciona en los casos en que la consulta est\u00e1 bloqueada en alguna operaci\u00f3n. Sin embargo, es probable que este no sea su caso, porque, seg\u00fan sus palabras, est\u00e1 utilizando un mont\u00f3n de recursos del servidor. Es posible que esto no funcione en el caso de ordenamiento externo y en algunos otros detalles. Pero en general no deber\u00eda suceder, es un error. Y lo \u00fanico que puedo recomendar es actualizar ClickHouse.<\/p>\n<p><\/p>\n<h2 id=\"anchorreading-timeanchorkak-rasschitat-vremya-otveta-pri-chitayuschey-nagruzke\"><noindex><a rel=\"nofollow\" name=\"reading-time\"><\/a><\/noindex>\u00bfC\u00f3mo calcular el tiempo de respuesta bajo carga de lectura?<\/h2>\n<p><\/p>\n<blockquote><p>Hay una tabla donde se almacenan los agregados por item \u2014 varios contadores. La cantidad de filas es de aproximadamente cien millones. \u00bfSe puede contar con un tiempo de respuesta predecible si se env\u00edan 1K RPS de 1K items? <\/p><\/blockquote>\n<p>A juzgar por el contexto, se trata de la carga de lectura, porque no hay problemas con la escritura \u2014 se pueden insertar mil, cien mil, y a veces incluso varios millones de filas. <\/p>\n<p><\/p>\n<p>Las consultas de lectura son muy variadas. En select 1, ClickHouse puede ejecutar decenas de miles de consultas por segundo, por lo que incluso las consultas por una sola clave ya requerir\u00e1n ciertos recursos. Y tales consultas puntuales ser\u00e1n m\u00e1s complejas que en las bases de datos tipo key-value, porque para cada lectura es necesario leer un bloque de datos por \u00edndice. El \u00edndice no dirige a cada registro, sino a cada rango. Es decir, tendr\u00e1 que leer todo el rango \u2014 son 8192 filas por defecto. Y ser\u00e1 necesario descomprimir un bloque de datos comprimido de 64 Kb a 1 Mb. Normalmente, tales consultas puntuales toman desde varios milisegundos. Pero esta es la opci\u00f3n m\u00e1s simple.<\/p>\n<p><\/p>\n<p>Intentemos realizar una simple aritm\u00e9tica. Si multiplicamos unos pocos milisegundos por mil, obtenemos unos pocos segundos. Como si no se pudiera manejar mil solicitudes por segundo, pero en realidad se puede, porque tenemos varios n\u00facleos de procesador. Por lo tanto, en principio, ClickHouse puede manejar 1000 RPS a veces, pero en consultas cortas, puntuales.<\/p>\n<p><\/p>\n<p>Si necesitas escalar un cl\u00faster de ClickHouse en cuanto a la cantidad de solicitudes simples, recomiendo la opci\u00f3n m\u00e1s sencilla: aumentar la cantidad de r\u00e9plicas y enviar las solicitudes a una r\u00e9plica aleatoria. Si una r\u00e9plica puede manejar quinientas solicitudes por segundo, lo cual es completamente realista, entonces tres r\u00e9plicas manejar\u00e1n mil quinientas.<\/p>\n<p><\/p>\n<p>A veces, por supuesto, tambi\u00e9n se puede configurar ClickHouse para el n\u00famero m\u00e1ximo de lecturas puntuales. \u00bfQu\u00e9 se necesita para esto? Primero, reducir la granularidad del \u00edndice. Y esta reducci\u00f3n no debe hacerse hasta la unidad, sino calculando que la cantidad de registros en el \u00edndice ser\u00e1 de varios millones o decenas de millones por servidor. Si en la tabla hay cien millones de filas, entonces como granularidad se puede establecer 64.<\/p>\n<p><\/p>\n<p>Se puede reducir el tama\u00f1o del bloque comprimido. Para esto hay configuraciones. <strong>min compress block size<\/strong>, <strong>max compress block size<\/strong>. Se pueden reducir, volver a cargar los datos, y entonces las solicitudes puntuales ser\u00e1n m\u00e1s r\u00e1pidas. Pero a\u00fan as\u00ed, ClickHouse no es una base de datos clave-valor. Una gran cantidad de peque\u00f1as solicitudes es un antipatr\u00f3n de carga.<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> Te dar\u00e9 un consejo por si acaso tienes contadores habituales. Esta es una situaci\u00f3n bastante est\u00e1ndar, cuando en ClickHouse se almacena alg\u00fan contador. Tengo un usuario, \u00e9l es de cierto pa\u00eds, y con un tercer campo, y hay que incrementar algo. Tomas MySQL, haces una clave \u00fanica: en MySQL es clave duplicada, y en PostgreSQL es conflicto, y luego agregas con un signo m\u00e1s. Esto funcionar\u00e1 mucho mejor. <\/p>\n<p><\/p>\n<p>Cuando tienes pocos datos, no tiene mucho sentido usar ClickHouse. Hay bases de datos normales, y manejan esto bien. <\/p>\n<p><\/p>\n<h2 id=\"anchorpimp-my-clickhouseanchorchto-podtyunit-v-clickhouse-chtoby-bolshe-dannyh-bylo-vnbspkeshe\"><noindex><a rel=\"nofollow\" name=\"pimp-my-clickhouse\"><\/a><\/noindex>\u00bfQu\u00e9 ajustar en ClickHouse para que haya m\u00e1s datos en la cach\u00e9?<\/h2>\n<p><\/p>\n<blockquote><p>Imaginemos la situaci\u00f3n: en los servidores hay 256 GB de RAM, en la rutina diaria ClickHouse toma alrededor de 60\u201480 GB, en pico \u2014 hasta 130. \u00bfQu\u00e9 se puede activar y ajustar para que haya m\u00e1s datos en la cach\u00e9 y, consecuentemente, menos accesos al disco?<\/p><\/blockquote>\n<p>Por lo general, la cach\u00e9 de p\u00e1gina del sistema operativo se encarga bien de esta tarea. Si solo abres el top y miras all\u00ed cached o free, tambi\u00e9n se indica cu\u00e1nto est\u00e1 en cach\u00e9; puedes notar que toda la memoria libre se utiliza para la cach\u00e9. Y estos datos, al ser le\u00eddos, no ser\u00e1n le\u00eddos del disco, sino de la memoria RAM. Puedo decir que la cach\u00e9 se utiliza de manera efectiva, ya que se almacenan precisamente datos comprimidos.<\/p>\n<p><\/p>\n<p>Sin embargo, si deseas acelerar a\u00fan m\u00e1s algunas consultas simples, existe la posibilidad de habilitar dentro de ClickHouse la cach\u00e9 en datos descomprimidos. Esto se llama <strong>uncompressed cache<\/strong>. En el archivo de configuraci\u00f3n config.xml, estableces el tama\u00f1o de la cach\u00e9 descomprimida en el valor que desees; recomiendo no m\u00e1s de la mitad de la RAM libre, ya que el resto se destinar\u00e1 a la cach\u00e9 de p\u00e1gina. <\/p>\n<p><\/p>\n<p>Adem\u00e1s, hay dos configuraciones a nivel de consulta. La primera configuraci\u00f3n es <strong>usar cach\u00e9 descomprimido<\/strong> \u2014 incluye su uso. Se recomienda habilitarla para todas las consultas, excepto para aquellas pesadas que pueden leer todos los datos y limpiar esta cach\u00e9. Y la segunda configuraci\u00f3n es algo as\u00ed como el n\u00famero m\u00e1ximo de filas para utilizar la cach\u00e9. Limita autom\u00e1ticamente las consultas grandes para que pasen por alto la cach\u00e9.<\/p>\n<p><\/p>\n<h2 id=\"anchorstorage-configurationanchorkak-mozhno-nastroit-storage_configuration-dlya-hraneniya-v-operativke\"><noindex><a rel=\"nofollow\" name=\"storage-configuration\"><\/a><\/noindex>\u00bfC\u00f3mo se puede configurar storage_configuration para almacenamiento en memoria?<\/h2>\n<p><\/p>\n<blockquote><p>En la nueva documentaci\u00f3n de ClickHouse, le\u00ed una secci\u00f3n relacionada <noindex><a rel=\"nofollow\" href=\"https:\/\/clickhouse.tech\/docs\/en\/single\/#table_engine-mergetree-multiple-volumes\">con almacenamiento de datos<\/a><\/noindex>. En la descripci\u00f3n hay un ejemplo con SSD r\u00e1pido. <\/p>\n<p>Es interesante c\u00f3mo se puede configurar lo mismo con memoria caliente de volumen. Y otra pregunta. \u00bfC\u00f3mo funciona el select con tal organizaci\u00f3n de datos? \u00bfLeer\u00e1 todo el conjunto o solo el que est\u00e1 en el disco, y se comprimen estos datos en la memoria? \u00bfY c\u00f3mo funciona la secci\u00f3n prewhere en tal organizaci\u00f3n de datos?<\/p><\/blockquote>\n<p>Esta configuraci\u00f3n afecta al almacenamiento de fracciones de datos, y su formato no cambia en absoluto.<br \/>\nVeamos esto con m\u00e1s detalle. <\/p>\n<p><\/p>\n<p>Se puede configurar el almacenamiento de datos en la memoria RAM. Todo lo que se configura para el disco es su ruta. Creas una partici\u00f3n tmpfs, que est\u00e1 montada en alg\u00fan lugar del sistema de archivos. Indicas esta ruta como el camino para almacenar los datos del segmento m\u00e1s caliente, y ah\u00ed comienzan a llegar y escribirse las fracciones de datos; todo est\u00e1 bien. <\/p>\n<p><\/p>\n<p>Pero no lo recomendar\u00eda debido a la baja fiabilidad, aunque, si tienes al menos tres r\u00e9plicas en diferentes centros de datos, podr\u00edas hacerlo. En caso de que algo suceda, los datos ser\u00e1n recuperados. Imaginemos que el servidor se apaga y se vuelve a encender. La secci\u00f3n se monta de nuevo, pero est\u00e1 vac\u00eda. El servidor ClickHouse, al iniciarse, nota que le faltan esos fragmentos, aunque, seg\u00fan los metadatos de ZooKeeper, deber\u00edan estar ah\u00ed. Verifica en qu\u00e9 r\u00e9plicas est\u00e1n disponibles, las solicita y las descarga. As\u00ed es como se recuperar\u00e1n los datos. <\/p>\n<p><\/p>\n<p>En este sentido, almacenar datos en memoria RAM no difiere fundamentalmente de almacenarlos en disco, porque al escribir datos en el disco tambi\u00e9n pasan primero por la cach\u00e9 de p\u00e1ginas y se escriben f\u00edsicamente de forma diferida. Esto depende de la forma en que se monte el sistema de archivos. Pero para estar seguro, dir\u00e9 que ClickHouse no realiza fsync durante el insert.<\/p>\n<p><\/p>\n<p>Los datos en memoria RAM se guardan en el mismo formato que en disco. La consulta select elige de la misma manera los fragmentos que necesita leer, selecciona los rangos de datos correspondientes y los lee. Y prewhere funciona exactamente igual, independientemente de si los datos estaban en RAM o en disco.<\/p>\n<p><\/p>\n<h2 id=\"anchorlow-cardinalityanchordo-kakogo-kolichestva-unikalnyh-znacheniy-effektiven-low-cardinality\"><noindex><a rel=\"nofollow\" name=\"low-cardinality\"><\/a><\/noindex>\u00bfHasta cu\u00e1ntos valores \u00fanicos es eficaz Low Cardinality?<\/h2>\n<p><\/p>\n<p>Low Cardinality est\u00e1 ingeniosamente dise\u00f1ado. Crea diccionarios de datos, pero son locales. Primero, los diccionarios son espec\u00edficos de cada fragmento, y segundo, incluso dentro de un mismo fragmento pueden ser diferentes para cada rango. Cuando el n\u00famero de valores \u00fanicos alcanza un umbral \u2014creo que un mill\u00f3n\u2014 el diccionario se deja de lado y se crea uno nuevo.<\/p>\n<p><\/p>\n<p>La respuesta en general: para cada rango local \u2014digamos, para cada d\u00eda\u2014 hasta aproximadamente un mill\u00f3n de valores \u00fanicos, Low Cardinality es efectivo. Despu\u00e9s habr\u00e1 un fallback, donde se utilizar\u00e1n varios diccionarios en lugar de uno solo. Funcionar\u00e1 de forma similar a una columna habitual de tipo string, quiz\u00e1s un poco menos eficaz, pero no habr\u00e1 una degradaci\u00f3n significativa en el rendimiento. <\/p>\n<p><\/p>\n<h2 id=\"anchorfulltext-searchanchorkakie-luchshie-praktiki-ponbsppolnotekstovomu-poisku-ponbsptablice-snbsppyatyu-milliardami-strok\"><noindex><a rel=\"nofollow\" name=\"fulltext-search\"><\/a><\/noindex>\u00bfCu\u00e1les son las mejores pr\u00e1cticas para la b\u00fasqueda de texto completo en una tabla con cinco mil millones de filas?<\/h2>\n<p><\/p>\n<p>Hay varias maneras de responder. La primera es decir que ClickHouse no es un sistema para b\u00fasqueda de texto completo. Para eso hay sistemas especializados como, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/enterprise-search\">Elasticsearch<\/a><\/noindex> y <noindex><a rel=\"nofollow\" href=\"http:\/\/sphinxsearch.com\/\">Sphinx<\/a><\/noindex>. Sin embargo, cada vez encuentro m\u00e1s personas que dicen que est\u00e1n migrando de Elasticsearch a ClickHouse.<\/p>\n<p><\/p>\n<p>\u00bfPor qu\u00e9 sucede esto? Ellos lo explican diciendo que Elasticsearch deja de manejar la carga a partir de ciertos vol\u00famenes, comenzando con la construcci\u00f3n de \u00edndices. Los \u00edndices se vuelven demasiado pesados y, si simplemente trasladamos los datos a ClickHouse, se almacenar\u00e1n de manera muchas veces m\u00e1s eficiente en volumen. Adem\u00e1s, las consultas de b\u00fasqueda a menudo no eran tales que necesitaban encontrar alguna frase dentro de todo el volumen de datos teniendo en cuenta la morfolog\u00eda, sino completamente diferentes. Por ejemplo, encontrar en los registros de las \u00faltimas horas alguna subcadena de bytes.<\/p>\n<p><\/p>\n<p>En este caso, en ClickHouse creas un \u00edndice, cuyo primer campo ser\u00e1 la fecha y hora. Y el mayor recorte de datos ser\u00e1 precisamente por rango de fechas. Dentro del rango de fechas elegido, generalmente se puede realizar una b\u00fasqueda de texto completo incluso mediante el m\u00e9todo de fuerza bruta utilizando like. El operador like en ClickHouse es el operador like m\u00e1s efectivo que puedes encontrar. Si encuentras uno mejor, h\u00e1zmelo saber. <\/p>\n<p><\/p>\n<p>Pero a\u00fan as\u00ed, like es un escaneo completo. Y un escaneo completo puede ser lento no solo por la CPU, sino tambi\u00e9n por el disco. Si de repente tienes un terabyte de datos al d\u00eda y buscas alguna palabra en un d\u00eda, tendr\u00e1s que escanear un terabyte. Y seguramente estar\u00e1 en discos duros normales, lo que al final har\u00e1 que est\u00e9n tan ocupados que no podr\u00e1s acceder a ese servidor por SSH.<\/p>\n<p><\/p>\n<p>En este caso, estoy dispuesto a ofrecer otro peque\u00f1o truco. Es del tipo experimental: puede que funcione, o puede que no. En ClickHouse hay \u00edndices de texto completo en forma de filtros de Bloom trigramas. Nuestros colegas de la empresa Arenadata ya han probado estos \u00edndices, y a menudo funcionan exactamente como se pretende.<\/p>\n<p><\/p>\n<p>Para utilizarlos correctamente, es importante entender bien c\u00f3mo funcionan: qu\u00e9 es un filtro de Bloom trigramo y c\u00f3mo elegir su tama\u00f1o. Puedo decir que ayudar\u00e1n para consultas sobre algunas frases raras, subcadenas que aparecen poco en los datos. En este caso, se elegir\u00e1n subrangos a trav\u00e9s de los \u00edndices, y se leer\u00e1n menos datos.<\/p>\n<p><\/p>\n<p>Recientemente, ClickHouse ha introducido funciones a\u00fan m\u00e1s avanzadas para la b\u00fasqueda de texto completo. Esto incluye, en primer lugar, la b\u00fasqueda de m\u00faltiples substrings en una sola pasada, incluyendo variaciones con distinci\u00f3n de may\u00fasculas y min\u00fasculas, sin distinci\u00f3n de may\u00fasculas, con soporte para UTF-8 o solo para ASCII. Elija la m\u00e1s efectiva que necesite. <\/p>\n<p><\/p>\n<p>Tambi\u00e9n se ha a\u00f1adido la b\u00fasqueda de m\u00faltiples expresiones regulares en una sola pasada. No necesita escribir X like una substring o X like otra substring. Escriba todo de una vez y se ejecutar\u00e1 de manera \u00f3ptima.<\/p>\n<p><\/p>\n<p>Por \u00faltimo, ahora hay b\u00fasqueda aproximada de expresiones regulares y b\u00fasqueda aproximada de substrings. Si alguien ha escrito una palabra con un error tipogr\u00e1fico, se buscar\u00e1 en base a la coincidencia m\u00e1xima.<\/p>\n<p><\/p>\n<h2 id=\"anchorhello-and-welcomeanchorkak-luchshe-organizovat-dostup-vnbspclickhouse-dlyanbspbolshogo-kolichestva-polzovateley\"><noindex><a rel=\"nofollow\" name=\"hello-and-welcome\"><\/a><\/noindex>\u00bfC\u00f3mo organizar mejor el acceso a ClickHouse para un gran n\u00famero de usuarios?<\/h2>\n<p><\/p>\n<blockquote><p>Comparta c\u00f3mo organizar mejor el acceso para una gran cantidad de consumidores y analistas. \u00bfC\u00f3mo formar una cola, priorizar solicitudes de consultas concurrentes m\u00e1ximas, y con qu\u00e9 herramientas?<\/p><\/blockquote>\n<p>Si el cl\u00faster es lo suficientemente grande, una buena soluci\u00f3n ser\u00e1 levantar otros dos servidores que act\u00faen como punto de entrada para los analistas. Es decir, no dejar que los analistas accedan a shards espec\u00edficos del cl\u00faster, sino simplemente crear dos servidores vac\u00edos, sin datos, y configurar los permisos de acceso en ellos. A su vez, las configuraciones de usuarios en consultas distribuidas se transmiten a servidores remotos. Es decir, usted configura todo en estos dos servidores y los ajustes tienen efecto en todo el cl\u00faster.<\/p>\n<p><\/p>\n<p>En principio, estos servidores est\u00e1n vac\u00edos de datos, pero la cantidad de memoria RAM en ellos es bastante importante para la ejecuci\u00f3n de consultas. El disco tambi\u00e9n puede utilizarse para datos temporales si la agregaci\u00f3n externa o la ordenaci\u00f3n externa est\u00e1n habilitadas.<\/p>\n<p><\/p>\n<p>Es importante revisar la configuraci\u00f3n relacionada con todos los l\u00edmites posibles. Si ahora accedo al cl\u00faster de \u2018Yandex.Metrica\u2019 como analista y hago una solicitud <strong>select count from hits<\/strong>, se me mostrar\u00e1 de inmediato una excepci\u00f3n diciendo que no puedo ejecutar la consulta. El n\u00famero m\u00e1ximo de filas que se me permite escanear es de cien mil millones, mientras que en el cl\u00faster hay un total de cincuenta billones en una sola tabla. Esta es la primera limitaci\u00f3n. <\/p>\n<p><\/p>\n<p>Supongamos que quito la limitaci\u00f3n en el n\u00famero de filas y vuelvo a ejecutar la consulta. Entonces ver\u00e9 la siguiente excepci\u00f3n: la configuraci\u00f3n est\u00e1 habilitada. <strong>force index by date<\/strong>. No puedo realizar la solicitud si no especifico un rango de fechas. No hay que contar con que los analistas lo indiquen manualmente. Un caso t\u00edpico ser\u00eda haber escrito un rango de fechas donde la fecha del evento est\u00e1 entre una semana. Y luego, simplemente se puso mal el par\u00e9ntesis, y en lugar de 'and' result\u00f3 'or' \u2014 o la coincidencia de URL. Si no hay restricciones, va a escanear la columna de URL y gastar\u00e1 una tonelada de recursos.<\/p>\n<p><\/p>\n<p>Adem\u00e1s, en ClickHouse hay dos configuraciones de prioridad. Desafortunadamente, son muy primitivas. Una se llama simplemente <strong>priority<\/strong>. Si la prioridad \u2260 0, y se ejecutan consultas con alguna prioridad, pero al mismo tiempo se ejecuta una consulta con prioridad que tiene un valor menor, lo que significa mayor prioridad, entonces la consulta con un valor de prioridad mayor, que indica menor prioridad, simplemente se suspende y no funcionar\u00e1 en absoluto durante ese tiempo.<\/p>\n<p><\/p>\n<p>Es una configuraci\u00f3n muy burda y no es adecuada para los casos en que hay una carga constante en el cl\u00faster. Pero si tiene consultas cortas e impulsivas que son importantes, y principalmente el cl\u00faster est\u00e1 inactivo, tal configuraci\u00f3n ser\u00e1 adecuada.<\/p>\n<p><\/p>\n<p>La siguiente configuraci\u00f3n de prioridades se llama <strong>prioridad de hilo del SO<\/strong>. Simplemente establece para todos los hilos de ejecuci\u00f3n de la consulta un valor nice para el scheduler de Linux. Funciona m\u00e1s o menos, pero a\u00fan as\u00ed funciona. Si se establece el valor m\u00ednimo nice \u2014 es el m\u00e1s alto en magnitud y, por lo tanto, menor prioridad \u2014 y para las consultas de alta prioridad se establece -19, entonces la CPU consumir\u00e1 consultas de baja prioridad aproximadamente cuatro veces menos que las de alta prioridad. <\/p>\n<p><\/p>\n<p>Tambi\u00e9n es necesario establecer un tiempo m\u00e1ximo de ejecuci\u00f3n de la consulta \u2014 digamos, cinco minutos. La velocidad m\u00ednima de ejecuci\u00f3n de la consulta \u2014 esto es lo mejor. Esta configuraci\u00f3n ha existido desde hace tiempo y es necesaria para no solo afirmar que ClickHouse no se retrasa, sino para forzar eso.<\/p>\n<p><\/p>\n<p>Imagina que est\u00e1s configurando: si alguna consulta procesa menos de un mill\u00f3n de filas por segundo \u2014 eso no debe hacerse. Eso deshonra nuestro buen nombre, nuestra buena base de datos. Vamos a prohibirlo. En realidad hay dos configuraciones. Una se llama <strong>velocidad m\u00ednima de ejecuci\u00f3n<\/strong> \u2014 en l\u00edneas por segundo, y el segundo se llama tiempo de espera antes de comprobar la velocidad m\u00ednima de ejecuci\u00f3n \u2014 por defecto quince segundos. Es decir, se pueden dar quince segundos, y luego, si es lento, simplemente lanzar una excepci\u00f3n \u2014 interrumpir la solicitud.<\/p>\n<p><\/p>\n<p>Tambi\u00e9n es necesario configurar las cuotas. En ClickHouse hay una funci\u00f3n incorporada de cuotas que cuenta el consumo de recursos. Pero, desafortunadamente, no de recursos f\u00edsicos como CPU, discos, sino l\u00f3gicos \u2014 el n\u00famero de consultas procesadas, l\u00edneas y bytes le\u00eddos. Y se puede establecer, por ejemplo, un m\u00e1ximo de cien consultas en cinco minutos y mil consultas por hora.<\/p>\n<p><\/p>\n<p>\u00bfPor qu\u00e9 es importante? Porque parte de las consultas anal\u00edticas se ejecutar\u00e1n manualmente directamente desde el cliente de ClickHouse. Y todo ir\u00e1 bien. Pero si en su empresa hay analistas avanzados, ellos escribir\u00e1n un script, y en el script puede haber un error. Y ese error har\u00e1 que la consulta se ejecute en un bucle infinito. De eso es de lo que hay que protegerse.<\/p>\n<p><\/p>\n<h2 id=\"anchorsmorgasbordanchormozhno-li-otdat-rezultaty-odnogo-zaprosa-desyati-klientam\"><noindex><a rel=\"nofollow\" name=\"smorgasbord\"><\/a><\/noindex>\u00bfSe pueden enviar los resultados de una consulta a diez clientes?<\/h2>\n<p><\/p>\n<blockquote><p>Tenemos varios usuarios que les gusta hacer consultas muy grandes al mismo tiempo. La consulta es grande, se ejecuta r\u00e1pidamente en principio, pero debido a que hay muchas consultas as\u00ed al mismo tiempo, se vuelve muy doloroso. \u00bfEs posible ejecutar la misma consulta que lleg\u00f3 diez veces seguidas solo una vez y darle el resultado a diez clientes?<\/p><\/blockquote>\n<p>El problema es que no tenemos resultados en cach\u00e9 o cach\u00e9 de datos intermedios. Hay cach\u00e9 de p\u00e1gina del sistema operativo, que permitir\u00e1 no leer los datos del disco nuevamente, pero, desafortunadamente, los datos a\u00fan se descomprimir\u00e1n, deserializar\u00e1n y procesar\u00e1n nuevamente. <\/p>\n<p><\/p>\n<p>Me gustar\u00eda evitar esto de alguna manera, ya sea cach\u00e9 de datos intermedios o estructurando consultas similares en una cola y a\u00f1adiendo cach\u00e9 de resultados. Actualmente, tenemos en desarrollo una solicitud de extracci\u00f3n que agrega cach\u00e9 de consultas, pero solo para subconsultas en la secci\u00f3n in y join \u2014 es decir, la soluci\u00f3n no es completa.<\/p>\n<p><\/p>\n<p>Sin embargo, tambi\u00e9n nos encontramos en esta situaci\u00f3n. Un ejemplo can\u00f3nico son las consultas con paginaci\u00f3n. Hay un informe, con varias p\u00e1ginas, y se realiza una consulta con limit 10. Luego lo mismo, pero con limit 10,10. Despu\u00e9s, la siguiente p\u00e1gina. Y surge la pregunta, \u00bfpor qu\u00e9 estamos calculando todo esto cada vez? Pero actualmente no hay soluci\u00f3n, y no se puede evitar.<\/p>\n<p><\/p>\n<p>Hay una soluci\u00f3n alternativa que se instala como un sidecar junto a ClickHouse \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Vertamedia\/chproxy\">ClickHouse Proxy<\/a><\/noindex>.<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> En ClickHouse Proxy hay un limitador de tasa incorporado y un cach\u00e9 de resultados integrado. Se han realizado muchas configuraciones, porque se plante\u00f3 un problema similar. Proxy permite limitar las consultas, organiz\u00e1ndolas en cola, y configurar cu\u00e1nto tiempo vive el cach\u00e9 de las consultas. Si las consultas fueron realmente iguales, el Proxy las devolver\u00e1 m\u00faltiples veces, pero ir\u00e1 a ClickHouse solo una vez.<\/p>\n<p><\/p>\n<p>Nginx tambi\u00e9n tiene cach\u00e9 en la versi\u00f3n gratuita, y eso tambi\u00e9n funcionar\u00e1. Nginx incluso tiene configuraciones que, si las consultas llegan al mismo tiempo, ralentizar\u00e1 otras hasta que una se complete. Pero en ClickHouse Proxy, la configuraci\u00f3n se realiz\u00f3 mucho mejor. Se dise\u00f1\u00f3 espec\u00edficamente para ClickHouse, para estas consultas, por lo que es m\u00e1s adecuado. Y adem\u00e1s, se instala f\u00e1cilmente. <\/p>\n<p><\/p>\n<h2 id=\"anchorasynchronousanchorkak-byt-snbspasinhronnymi-operaciyami-i-materializovannymi-predstavleniyami\"><noindex><a rel=\"nofollow\" name=\"asynchronous\"><\/a><\/noindex>\u00bfQu\u00e9 hacer con las operaciones as\u00edncronas y las vistas materializadas?<\/h2>\n<p><\/p>\n<blockquote><p>Hay un problema de que las operaciones con el motor de reemplazo son asincr\u00f3nicas: primero se escriben los datos, luego se produce su compactaci\u00f3n. Si hay una tabla materializada con algunos agregados debajo de la tabla, se registrar\u00e1n duplicados. Y si no hay alguna l\u00f3gica compleja, los datos estar\u00e1n duplicados. \u00bfQu\u00e9 se puede hacer al respecto?<\/p>\n<p>Hay una soluci\u00f3n evidente: implementar un trigger en una clase espec\u00edfica de materialized views durante la operaci\u00f3n asincr\u00f3nica de compactaci\u00f3n. \u00bfHay alguna \"bala de plata\", planes para implementar funcionalidades similares?<\/p><\/blockquote>\n<p>Vale la pena investigar c\u00f3mo funciona la deduplicaci\u00f3n. Lo que voy a contar ahora no se relaciona con la pregunta, pero vale la pena tenerlo en cuenta.<\/p>\n<p><\/p>\n<p>Al insertar en una tabla replicada, hay deduplicaci\u00f3n de bloques completos insertados. Si vuelves a insertar el mismo bloque que contiene el mismo n\u00famero de las mismas filas en el mismo orden, los datos se deduplican. Recibir\u00e1s \u201cOk\u201d como respuesta a la inserci\u00f3n, pero de hecho se registrar\u00e1 un solo lote de datos, y no se duplicar\u00e1.<\/p>\n<p><\/p>\n<p>Esto es necesario para la claridad. Si durante la inserci\u00f3n recibiste \u201cOk\u201d, significa que tus datos han sido insertados. Si recibiste un error de ClickHouse, significa que no se insertaron, y debes repetir la inserci\u00f3n. Pero si durante la inserci\u00f3n se interrumpi\u00f3 la conexi\u00f3n, no sabes si los datos han sido insertados o no. La \u00fanica opci\u00f3n es repetir la inserci\u00f3n nuevamente. Si los datos realmente fueron insertados y los insertaste nuevamente, hay deduplicaci\u00f3n de bloques. Esto es necesario para evitar duplicados. <\/p>\n<p><\/p>\n<p>Y tambi\u00e9n es importante c\u00f3mo funciona para las vistas materializadas. Si los datos fueron deduplicados al insertarse en la tabla principal, no ir\u00e1n tampoco a la vista materializada.<\/p>\n<p><\/p>\n<p>Ahora respecto a la pregunta. Tienes una situaci\u00f3n m\u00e1s complicada, porque est\u00e1s registrando duplicados de filas individuales. Es decir, no se ha duplicado un lote entero, sino espec\u00edficamente filas concretas, que se est\u00e1n colapsando de fondo. De hecho, los datos se colapsar\u00e1n en la tabla principal, pero a la vista materializada ir\u00e1n los no colapsados, y durante las uniones no ocurrir\u00e1 nada con las vistas materializadas. Porque la vista materializada es simplemente un trigger en la inserci\u00f3n. En otras operaciones, no ocurre nada adicional con ella.<\/p>\n<p><\/p>\n<p>Y aqu\u00ed no puedo alegrarte. Solo hay que buscar una soluci\u00f3n espec\u00edfica para este caso. Por ejemplo, \u00bfse puede hacer tambi\u00e9n un reemplazo en la vista materializada? Y quiz\u00e1s el m\u00e9todo de deduplicaci\u00f3n funcione de la misma manera. Pero desafortunadamente, no siempre. Si es agregadora, entonces no se podr\u00e1. <\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> En nuestra \u00e9poca, tambi\u00e9n tuvimos un problema similar con la construcci\u00f3n de soluciones temporales. Exist\u00eda el problema de que hab\u00eda impresiones de anuncios y ciertos datos que pod\u00edamos mostrar en tiempo real: eran simplemente impresiones. Rara vez se duplican, pero si eso sucede, las consolidamos m\u00e1s tarde. Hab\u00eda cosas que no se pod\u00edan duplicar: los clics y toda esa historia. Pero quer\u00edamos mostrarlas casi de inmediato.<\/p>\n<p><\/p>\n<p>\u00bfC\u00f3mo se hicieron las vistas materializadas? Hab\u00eda vistas en las que se escrib\u00eda directamente: se registraban los datos en crudo y se escrib\u00edan en las vistas. En alg\u00fan momento, esos datos no eran muy precisos, se duplicaban, etc. Y hay una segunda parte de la tabla donde se ven exactamente igual que las vistas materializadas, es decir, por estructura son absolutamente id\u00e9nticas. De vez en cuando, recalculamos los datos, sumamos los datos sin duplicados y los escribimos en esas tablas. <\/p>\n<p><\/p>\n<p>Trabajamos a trav\u00e9s de API: hacerlo manualmente en ClickHouse no funcionar\u00e1. Y la API observa: cuando tengo la fecha de la \u00faltima entrada en la tabla, donde los datos ya est\u00e1n garantizados como correctos, y realiza una consulta a una tabla y a otra. De una consulta selecciona hasta un cierto per\u00edodo de tiempo, y de la otra, recoge lo que a\u00fan no ha sido calculado. Y eso funciona, pero no con las herramientas de un solo ClickHouse.<\/p>\n<p><\/p>\n<p>Si tienes alg\u00fan API, ya sea para analistas o para usuarios, entonces, en principio, es una opci\u00f3n. Siempre puedes recalcular, siempre puedes sumar. Esto se puede hacer una vez al d\u00eda o en otro momento. T\u00fa eliges el rango que no necesitas y que no es cr\u00edtico para ti.<\/p>\n<p><\/p>\n<h2 id=\"anchordashboardanchorv-clickhouse-mnogo-logov-kak-ya-mogu-videt-vsyo-chto-proishodit-s-serverom-vnbspmomente\"><noindex><a rel=\"nofollow\" name=\"dashboard\"><\/a><\/noindex>En ClickHouse hay muchos registros. \u00bfC\u00f3mo puedo ver todo lo que est\u00e1 sucediendo con el servidor en tiempo real?<\/h2>\n<p><\/p>\n<blockquote><p>En ClickHouse hay una gran cantidad de registros diferentes, y esa cantidad sigue aumentando. En las nuevas versiones, algunos de ellos incluso est\u00e1n habilitados por defecto; en las versiones antiguas, hay que habilitarlos al actualizar. Sin embargo, hay cada vez m\u00e1s. Me gustar\u00eda poder ver al final qu\u00e9 est\u00e1 sucediendo actualmente con mi servidor, quiz\u00e1s en alg\u00fan panel de control consolidado. <\/p>\n<p>\u00bfNo tiene usted en&nbsp;su equipo ClickHouse, o en&nbsp;los equipos de sus amigos, que apoyen alguna funcionalidad de tableros listos que muestren estos registros con la apariencia de un producto ya terminado? Al final, ver registros en&nbsp;ClickHouse es genial. Pero ser\u00eda muy bueno si ya viniera preparado en&nbsp;forma de tablero. Eso me gustar\u00eda mucho. <\/p><\/blockquote>\n<p>Hay tableros, pero no est\u00e1n estandarizados. En&nbsp;nuestra empresa, alrededor de 60&nbsp;equipos utilizan ClickHouse, y lo m\u00e1s extra\u00f1o es que muchos de ellos han creado sus propios tableros, que son un poco diferentes entre s\u00ed. Algunos equipos utilizan una instalaci\u00f3n interna de 'Yandex.Cloud'. All\u00ed hay algunos informes listos, aunque no todos los necesarios. Otros tienen los suyos. <\/p>\n<p><\/p>\n<p>Mis colegas de&nbsp;'Metrica' tienen su tablero en&nbsp;Grafana, y yo tengo el m\u00edo sobre su cl\u00faster. All\u00ed miro cosas como el cach\u00e9 de aciertos para el cach\u00e9 de consultas. Y lo que es a\u00fan m\u00e1s complicado es que usamos diferentes herramientas. Mi tablero lo cre\u00e9 en&nbsp;una herramienta muy antigua llamada Graphite-web. Es completamente feo. Y sigo us\u00e1ndolo, aunque Grafana probablemente ser\u00eda m\u00e1s conveniente y bonita. <\/p>\n<p><\/p>\n<p>La base de los tableros es la misma. Son m\u00e9tricas del sistema por&nbsp;cl\u00faster: CPU, memoria, disco, red. Otras m\u00e9tricas incluyen el n\u00famero de solicitudes simult\u00e1neas, el n\u00famero de fusiones simult\u00e1neas, el n\u00famero de solicitudes por segundo, la cantidad m\u00e1xima de partes para las particiones de tablas MergeTree, el retraso de replicaci\u00f3n, el tama\u00f1o de la cola de replicaci\u00f3n, la cantidad de filas insertadas por segundo, la cantidad de bloques insertados por segundo. Todo esto proviene de m\u00e9tricas, no de registros.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobaev:<\/strong> Alexey, quisiera hacer una peque\u00f1a correcci\u00f3n. Hay Grafana. Grafana tiene una fuente de datos, que es ClickHouse. Esto significa que puedo realizar consultas directamente a ClickHouse desde Grafana. En ClickHouse hay una tabla con los registros, que es la misma para todos. Quiero referirme a esta tabla de registros en Grafana y ver las consultas que realiza mi servidor. Ser\u00eda genial tener un tablero de este tipo.<\/p>\n<p><\/p>\n<p>Lo he hecho yo mismo. Pero me surge la pregunta: si todo est\u00e1 estandarizado y Grafana es utilizada por todos, \u00bfpor qu\u00e9 en 'Yandex' no hay un tablero oficial as\u00ed?<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> En realidad, el datasource que est\u00e1 conectado a ClickHouse ahora es soportado por Altinity. Solo quiero dar una direcci\u00f3n sobre d\u00f3nde investigar y a qui\u00e9n presionar. Se les puede preguntar, ya que Yandex todav\u00eda est\u00e1 detr\u00e1s de ClickHouse, y no del entorno que lo rodea. Altinity es la empresa principal que actualmente est\u00e1 promoviendo ClickHouse. No lo abandonar\u00e1n, sino que lo respaldar\u00e1n. Porque, en principio, para cargar un dashboard en el sitio de Grafana, solo necesitas registrarte y subirlo; no hay problemas especiales. <\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> En el \u00faltimo a\u00f1o, ClickHouse ha agregado muchas funcionalidades para el perfilado de consultas. Hay m\u00e9tricas para cada consulta respecto al uso de recursos. Y muy recientemente, se ha a\u00f1adido un perfilador de consultas a\u00fan m\u00e1s de bajo nivel, para ver d\u00f3nde cada consulta gasta cada milisegundo. Pero para aprovechar esta funcionalidad, tengo que abrir el cliente de la consola y escribir la consulta que siempre olvido. La guard\u00e9 en alg\u00fan lugar y siempre olvido cu\u00e1l fue. <\/p>\n<p><\/p>\n<p>Me gustar\u00eda tener una herramienta en la que est\u00e9 escrito simplemente: aqu\u00ed est\u00e1n tus consultas pesadas, agrupadas por clases de consultas. Haces clic en alguna y me dir\u00edan que es pesada por esa raz\u00f3n. Actualmente no hay tal soluci\u00f3n. Y es bastante extra\u00f1o que, cuando la gente me pregunta: '\u00bfHay alg\u00fan dashboard listo para Grafana?', yo respondo: 'Visita el sitio de Grafana, all\u00ed est\u00e1 la comunidad \u201cDashboards\u201d, y hay un dashboard de Dima, hay un dashboard de Kostyan. Qu\u00e9 son, no lo s\u00e9, yo mismo no los he usado.'<\/p>\n<p><\/p>\n<h2 id=\"anchorzenanchorkak-vozdeystvovat-na-merdzhi-chtoby-server-ne-padal-vnbspoom\"><noindex><a rel=\"nofollow\" name=\"zen\"><\/a><\/noindex>\u00bfC\u00f3mo influir en los merges para que el servidor no se caiga en OOM?<\/h2>\n<p><\/p>\n<blockquote><p>Tengo una tabla, en la tabla hay solo una partici\u00f3n, es un ReplacingMergeTree. Durante cuatro a\u00f1os he estado escribiendo datos en ella. Necesitaba hacer un alter y eliminar algunos datos.<\/p>\n<p>Lo hice, y durante el procesamiento de esta consulta, se consumi\u00f3 toda la memoria en todos los servidores del cl\u00faster, y todos los servidores del cl\u00faster se fueron a OOM. Luego todos juntos se reiniciaron, comenzaron a ejecutar el merge de la misma operaci\u00f3n, de este bloque de datos, y nuevamente cayeron en OOM. Luego se reiniciaron de nuevo y volvieron a caer. Y esta situaci\u00f3n no se deten\u00eda.<\/p>\n<p>Luego result\u00f3 que en realidad era un error que el equipo solucion\u00f3. Es muy bueno, muchas gracias. Pero la impresi\u00f3n se qued\u00f3. Y ahora, cuando pienso que debo hacer una fusi\u00f3n en la tabla, la pregunta que me surge es: \u00bfpor qu\u00e9 no puedo de alguna manera influir en estas fusiones? Por ejemplo, limitar su cantidad en relaci\u00f3n a la memoria RAM requerida, o en general limitar el n\u00famero de fusiones que procesar\u00e1 esa tabla en concreto.<\/p>\n<p>Tengo una tabla llamada \u00abM\u00e9tricas\u00bb, por favor, proc\u00e9sala en dos hilos. No es necesario crear diez o cinco fusiones en paralelo, hazlo en dos. Creo que con dos me alcanzar\u00e1 la memoria, y puede que no tenga suficiente para procesar diez. \u00bfPor qu\u00e9 sigue el temor? Porque la tabla est\u00e1 creciendo y en alg\u00fan momento me enfrentar\u00e9 a la situaci\u00f3n de que, en principio, no ser\u00e1 por un error, sino porque los datos cambiar\u00e1n en tal cantidad que simplemente no tendr\u00e9 suficiente memoria en el servidor. Y entonces el servidor caer\u00e1 en OOM durante la fusi\u00f3n. De hecho, puedo cancelar la mutaci\u00f3n, pero las fusiones no.<\/p><\/blockquote>\n<p>Sabes, durante las fusiones el servidor no caer\u00e1 en OOM, porque en la fusi\u00f3n solo se utiliza la cantidad de memoria para un peque\u00f1o rango de datos. As\u00ed que todo estar\u00e1 bien independientemente del volumen de datos.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobaev:<\/strong> Est\u00e1 bien. Hay un punto aqu\u00ed, que despu\u00e9s de que realizaron la soluci\u00f3n del error, descargu\u00e9 una nueva versi\u00f3n y en otra tabla, m\u00e1s peque\u00f1a, donde hay muchas particiones, realic\u00e9 una operaci\u00f3n similar. Y durante la fusi\u00f3n, en el servidor se consumieron alrededor de 100 GB de memoria RAM. Ten\u00eda 150 ocupados, 100 consumidos, y qued\u00f3 un margen de 50 GB, as\u00ed que no ca\u00ed en OOM.<\/p>\n<p><\/p>\n<p>\u00bfQu\u00e9 me protege en este momento de caer en OOM si realmente consume unos 100 GB de memoria RAM? \u00bfC\u00f3mo manejar la situaci\u00f3n si la memoria RAM se acaba durante las fusiones?<\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> Hay un problema, que el consumo de memoria RAM durante el merge no se limita. Y el segundo problema es que, si se ha programado un merge, es necesario ejecutarlo porque est\u00e1 registrado en el registro de replicaci\u00f3n. El registro de replicaci\u00f3n son las acciones necesarias para llevar la r\u00e9plica a un estado consistente. Si no se hacen manipulaciones manuales que retrocedan este registro de replicaci\u00f3n, el merge debe necesariamente ejecutarse, de una forma u otra.<\/p>\n<p><\/p>\n<p>Por supuesto, no estar\u00eda de m\u00e1s tener un l\u00edmite en la RAM que proteja \u00abpor si acaso\u00bb contra OOM. Esto no ayudar\u00e1 a que el merge se complete, comenzar\u00e1 de nuevo, alcanzar\u00e1 un umbral, lanzar\u00e1 una excepci\u00f3n y luego volver\u00e1 a comenzar; no saldr\u00e1 nada bueno de esto. Pero en principio, ser\u00eda \u00fatil establecer este l\u00edmite.<\/p>\n<p><\/p>\n<h2 id=\"anchorgoanchorkak-budet-proishodit-razrabotka-golang-drayvera-dlya-clickhouse\"><noindex><a rel=\"nofollow\" name=\"go\"><\/a><\/noindex>\u00bfC\u00f3mo se desarrollar\u00e1 el controlador Golang para ClickHouse?<\/h2>\n<p><\/p>\n<blockquote><p>El controlador Golang, que fue escrito por Kirill Shvakov, ahora parece ser oficialmente soportado por el equipo de ClickHouse. \u00c9l <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ClickHouse\/clickhouse-go\">est\u00e1 en el repositorio de ClickHouse<\/a><\/noindex>, ahora es grande y real.<\/p>\n<p>Una peque\u00f1a observaci\u00f3n. Hay un almacenamiento maravilloso y querido por todos, el almacenamiento de formas normales de orden infinito \u2014 es Vertica. Tambi\u00e9n tienen su propio controlador oficial de Python, el cual es mantenido por los desarrolladores de Vertica. Y varias veces ha sucedido que las versiones del almacenamiento y del controlador se desincronizaban bastante, y en alg\u00fan momento el controlador dejaba de funcionar. Y el segundo punto. La atenci\u00f3n a este controlador oficial, me parece, se lleva a cabo en el sistema 'nipplo' \u2014 t\u00fa les env\u00edas un problema, y este queda pendiente para siempre.<\/p>\n<p>Tengo dos preguntas. Actualmente, el controlador de Golang de Kirill es casi la forma predeterminada de comunicarse desde Golang con ClickHouse. Excepto que alguien a\u00fan se comunica a trav\u00e9s de la interfaz http, porque le gusta m\u00e1s as\u00ed. \u00bfC\u00f3mo se desarrollar\u00e1 este controlador? \u00bfSe sincronizar\u00e1 con algunos cambios disruptivos en el almacenamiento mismo? \u00bfY cu\u00e1l es el procedimiento para considerar los problemas? <\/p><\/blockquote>\n<p><strong>Kirill Shvakov:<\/strong> Primero, c\u00f3mo est\u00e1 todo estructurado burocr\u00e1ticamente. Este aspecto no se discuti\u00f3, por lo que no tengo nada que responder.<\/p>\n<p><\/p>\n<p>Para responder a la pregunta sobre el issue, se necesita un peque\u00f1o historial del driver. Trabaj\u00e9 en una empresa con muchos datos. Era un sistema de publicidad que generaba una gran cantidad de eventos que deb\u00edan almacenarse en alg\u00fan lugar. Y en alg\u00fan momento, apareci\u00f3 ClickHouse. Comenzamos a enviarle datos, y al principio todo iba bien, pero luego ClickHouse se cay\u00f3. En ese momento decidimos que no lo necesit\u00e1bamos. <\/p>\n<p><\/p>\n<p>Un a\u00f1o despu\u00e9s, regresamos a la idea de usar ClickHouse, y necesit\u00e1bamos alguna forma de escribir datos all\u00ed. La entrada era la siguiente: el hardware era muy d\u00e9bil, hab\u00eda pocos recursos. Pero siempre hab\u00edamos trabajado as\u00ed, as\u00ed que miramos hacia el protocolo nativo.<\/p>\n<p><\/p>\n<p>Dado que trabaj\u00e1bamos en Go, estaba claro que necesit\u00e1bamos un driver en Go. Lo desarroll\u00e9 pr\u00e1cticamente a tiempo completo; esa era mi tarea laboral. Hasta cierto momento lo logramos, y en principio nadie supuso que alguien m\u00e1s lo usar\u00eda. Luego lleg\u00f3 CloudFlare con el mismo problema, y durante un tiempo trabajamos estrechamente con ellos, porque ten\u00edan las mismas tareas. De hecho, lo hicimos tanto en ClickHouse como en el driver. <\/p>\n<p><\/p>\n<p>En alg\u00fan momento simplemente dej\u00e9 de manejarlo, porque mi actividad en t\u00e9rminos de ClickHouse y en el trabajo cambi\u00f3 un poco. Por eso no se cierran los problemas. Peri\u00f3dicamente hay gente que hace commits en el repositorio porque necesitan algo. Entonces reviso la solicitud de extracci\u00f3n y a veces incluso corrijo algo, pero eso ocurre raramente.<\/p>\n<p><\/p>\n<p>Quiero volver al controlador. Hace algunos a\u00f1os, cuando todo esto comenz\u00f3, ClickHouse era diferente y ten\u00eda otras capacidades. Ahora ya hay una idea de c\u00f3mo rehacer el controlador para que funcione bien. Si esto sucede, la versi\u00f3n 2 ser\u00e1 incompatible debido a los parches acumulados. <\/p>\n<p><\/p>\n<p>No s\u00e9 c\u00f3mo organizar esto. Tengo poco tiempo. Si algunas personas quieren mejorar el controlador, podr\u00eda ayudarles y decirles qu\u00e9 hacer. Pero la participaci\u00f3n activa de 'Yandex' en el desarrollo del proyecto a\u00fan no se ha discutido. <\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> De hecho, no hay burocracia con respecto a estos controladores. La \u00fanica cosa es que est\u00e1n bajo una organizaci\u00f3n oficial, es decir, este controlador es reconocido como la soluci\u00f3n oficial por defecto para Go. Hay otros controladores, pero van por separado. <\/p>\n<p><\/p>\n<p>No tenemos ning\u00fan desarrollo interno para estos controladores. La cuesti\u00f3n es si podremos contratar a una persona dedicada, no espec\u00edficamente a este controlador, sino al desarrollo de todos los controladores de la comunidad, o si podremos encontrar a alguien externo. <\/p>\n<p><\/p>\n<h2 id=\"anchorlazy-loadanchorvneshniy-slovar-ne-podnimaetsya-posle-perezagruzki-snbspvklyuchennoy-nastroykoy-lazy_load-chto-delat\"><noindex><a rel=\"nofollow\" name=\"lazy-load\"><\/a><\/noindex>El diccionario externo no se carga despu\u00e9s de reiniciar con la configuraci\u00f3n de lazy_load habilitada. \u00bfQu\u00e9 hacer?<\/h2>\n<p><\/p>\n<blockquote><p>Tenemos habilitada la configuraci\u00f3n de lazy_load, y despu\u00e9s de reiniciar el servidor el diccionario no se carga autom\u00e1ticamente. Solo se carga despu\u00e9s de que un usuario accede a este diccionario. Y en el primer acceso genera un error. \u00bfEs posible cargar diccionarios autom\u00e1ticamente a trav\u00e9s de ClickHouse, o tenemos que controlar siempre su disponibilidad para que los usuarios no reciban errores?<\/p>\n<p>Quiz\u00e1s tenemos una versi\u00f3n antigua de ClickHouse, por eso el diccionario no se carg\u00f3 autom\u00e1ticamente. \u00bfPuede ser eso?<\/p><\/blockquote>\n<p>En primer lugar, se pueden cargar los diccionarios forzosamente mediante una consulta. <strong>system reload dictionaries<\/strong>. En segundo lugar, sobre el error: si el diccionario ya se ha cargado, las consultas funcionar\u00e1n con los datos que se han cargado. Si el diccionario a\u00fan no se ha cargado, se cargar\u00e1 justo en el momento de la consulta.<\/p>\n<p><\/p>\n<p>Para diccionarios pesados, esto no es muy conveniente. Por ejemplo, se necesitan recuperar un mill\u00f3n de filas de MySQL. Alguien hace un simple select, pero este select esperar\u00e1 esas millones de filas. Aqu\u00ed hay dos soluciones. La primera es desactivar lazy_load. La segunda es, cuando el servidor se inicia, antes de cargarlo, hacer <strong>system reload dictionary<\/strong> o simplemente ejecutar una consulta que use el diccionario. Entonces, el diccionario se cargar\u00e1. Se debe controlar la disponibilidad de los diccionarios con la configuraci\u00f3n lazy_load activada, porque ClickHouse no los carga autom\u00e1ticamente.<\/p>\n<p><\/p>\n<p>A la \u00faltima pregunta, la respuesta es que o la versi\u00f3n es antigua o es necesario depurar. <\/p>\n<p><\/p>\n<h2 id=\"anchorreload-dictionariesanchorkak-byt-snbsptem-chto-system-reload-dictionaries-ne-podgruzhaet-ni-odin-iznbspmnozhestva-slovarey-esli-hotya-by-odin-iznbspnih-padaet-snbsposhibkoy\"><noindex><a rel=\"nofollow\" name=\"reload-dictionaries\"><\/a><\/noindex>\u00bfC\u00f3mo manejar el hecho de que system reload dictionaries no carga ninguno de los m\u00faltiples diccionarios si al menos uno de ellos falla con un error?<\/h2>\n<p><\/p>\n<blockquote><p>Tambi\u00e9n hay una pregunta respecto a system reload dictionaries. Tenemos dos diccionarios: uno no se carga, el otro s\u00ed se carga. system reload dictionaries en este caso no carga ninguno de los diccionarios, y tenemos que cargar uno espec\u00edfico por su nombre utilizando system reload dictionary. \u00bfEsto tambi\u00e9n est\u00e1 relacionado con la versi\u00f3n de ClickHouse?<\/p><\/blockquote>\n<p>Quiero darles buenas noticias. Este comportamiento ha cambiado. Esto significa que si actualizan ClickHouse, tambi\u00e9n cambiar\u00e1. Si no est\u00e1n satisfechos con el comportamiento actual <strong>system reload dictionaries<\/strong>, actual\u00edzate, y esperemos que esto cambie para mejor.<\/p>\n<p><\/p>\n<h2 id=\"anchorconnectionanchorest-li-sposob-konfigurirovat-rekvizity-vnbspkonfige-clickhouse-no-ne-svetit-ih-prinbsposhibkah\"><noindex><a rel=\"nofollow\" name=\"connection\"><\/a><\/noindex>\u00bfHay alguna forma de configurar las credenciales en&nbsp;la configuraci\u00f3n de ClickHouse sin que se expongan en caso de errores?<\/h2>\n<p><\/p>\n<blockquote><p>La siguiente pregunta es sobre errores relacionados con el diccionario, espec\u00edficamente con los credenciales. Hemos escrito las credenciales de conexi\u00f3n en la configuraci\u00f3n de ClickHouse para el diccionario, y ante un error, recibimos estas credenciales y la contrase\u00f1a en la respuesta. <\/p>\n<p>Hemos resuelto este error moviendo las credenciales a la configuraci\u00f3n del controlador ODBC. \u00bfHay alguna forma de configurar las credenciales en la configuraci\u00f3n de ClickHouse sin exponer estas credenciales ante errores?<\/p><\/blockquote>\n<p>Aqu\u00ed la soluci\u00f3n realmente es especificar estas credentials en odbc.ini, y en ClickHouse solo indicar el ODBC Data Source Name. Para otras fuentes de diccionarios esto no ser\u00e1 as\u00ed: ni para el diccionario con MySQL, ni para otros deber\u00edas ver la contrase\u00f1a al recibir un mensaje de error. Para ODBC tambi\u00e9n investigar\u00e9: si existe, simplemente deber\u00edamos eliminarlo.<\/p>\n<p><\/p>\n<h2 id=\"anchorzoom-backgroundsanchorbonus-fony-dlya-zuma-snbspposidelok\"><noindex><a rel=\"nofollow\" name=\"zoom-backgrounds\"><\/a><\/noindex>Bonus: fondos para Zoom de&nbsp;reuniones<\/h2>\n<p><\/p>\n<p>Al hacer clic en&nbsp;la imagen, los lectores m\u00e1s perseverantes podr\u00e1n acceder a fondos de bonificaci\u00f3n de&nbsp;reuniones. Apaguemos el fuego junto a&nbsp;los personajes tecnol\u00f3gicos de Avito, discutamos con&nbsp;colegas en&nbsp;la sala del administrador del sistema o en&nbsp;un viejo club de computadoras y realicemos un daily bajo&nbsp;el puente con&nbsp;fondo de grafitis.<\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"http:\/\/amp.gs\/KvUr\"><img decoding=\"async\" alt=\"ClickHouse para usuarios avanzados en preguntas y respuestas\" src=\"\/wp-content\/uploads\/2020\/05\/38b2ea076283285d934913c395863eb1.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p>Fuente: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/avito\/blog\/500678\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412 \u0430\u043f\u0440\u0435\u043b\u0435 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u044b \u0410\u0432\u0438\u0442\u043e \u0441\u043e\u0431\u0438\u0440\u0430\u043b\u0438\u0441\u044c \u043d\u0430&nbsp;\u043e\u043d\u043b\u0430\u0439\u043d-\u043f\u043e\u0441\u0438\u0434\u0435\u043b\u043a\u0438 \u0441 \u0433\u043b\u0430\u0432\u043d\u044b\u043c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c ClickHouse \u0410\u043b\u0435\u043a\u0441\u0435\u0435\u043c \u041c\u0438\u043b\u043e\u0432\u0438\u0434\u043e\u0432\u044b\u043c \u0438 \u041a\u0438\u0440\u0438\u043b\u043b\u043e\u043c \u0428\u0432\u0430\u043a\u043e\u0432\u044b\u043c, Golang-\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c \u0438\u0437&nbsp;\u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Integros. \u041e\u0431\u0441\u0443\u0436\u0434\u0430\u043b\u0438, \u043a\u0430\u043a \u043c\u044b \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u0431\u0430\u0437\u0430\u043c\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u0438 \u043a\u0430\u043a\u0438\u0435 \u0441\u043b\u043e\u0436\u043d\u043e\u0441\u0442\u0438 \u0443&nbsp;\u043d\u0430\u0441 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u044e\u0442. \u041f\u043e&nbsp;\u043c\u043e\u0442\u0438\u0432\u0430\u043c \u0432\u0441\u0442\u0440\u0435\u0447\u0438 \u043c\u044b \u0441\u043e\u0431\u0440\u0430\u043b\u0438 \u0441\u0442\u0430\u0442\u044c\u044e \u0441&nbsp;\u043e\u0442\u0432\u0435\u0442\u0430\u043c\u0438 \u044d\u043a\u0441\u043f\u0435\u0440\u0442\u043e\u0432 \u043d\u0430&nbsp;\u043d\u0430\u0448\u0438 \u0438 \u0437\u0440\u0438\u0442\u0435\u043b\u044c\u0441\u043a\u0438\u0435 \u0432\u043e\u043f\u0440\u043e\u0441\u044b \u043f\u0440\u043e&nbsp;\u0431\u044d\u043a\u0430\u043f\u044b, \u0440\u0435\u0448\u0430\u0440\u0434\u0438\u043d\u0433 \u0434\u0430\u043d\u043d\u044b\u0445, \u0432\u043d\u0435\u0448\u043d\u0438\u0435 \u0441\u043b\u043e\u0432\u0430\u0440\u0438, Golang-\u0434\u0440\u0430\u0439\u0432\u0435\u0440 \u0438 \u043e\u0431\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u0435 \u0432\u0435\u0440\u0441\u0438\u0439 ClickHouse. \u041e\u043d\u0430 \u043c\u043e\u0436\u0435\u0442 \u0431\u044b\u0442\u044c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":80776,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-80775","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412 \u0430\u043f\u0440\u0435\u043b\u0435 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u044b \u0410\u0432\u0438\u0442\u043e \u0441\u043e\u0431\u0438\u0440\u0430\u043b\u0438\u0441\u044c \u043d\u0430 \u043e\u043d\u043b\u0430\u0439\u043d-\u043f\u043e\u0441\u0438\u0434\u0435\u043b\u043a\u0438 \u0441 \u0433\u043b\u0430\u0432\u043d\u044b\u043c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c ClickHouse \u0410\u043b\u0435\u043a\u0441\u0435\u0435\u043c \u041c\u0438\u043b\u043e\u0432\u0438\u0434\u043e\u0432\u044b\u043c \u0438 \u041a\u0438\u0440\u0438\u043b\u043b\u043e\u043c \u0428\u0432\u0430\u043a\u043e\u0432\u044b\u043c, Golang-\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Integros.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"es_ES\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47ClickHouse \u0434\u043b\u044f \u043f\u0440\u043e\u0434\u0432\u0438\u043d\u0443\u0442\u044b\u0445 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432 \u0432\u043e\u043f\u0440\u043e\u0441\u0430\u0445 \u0438 \u043e\u0442\u0432\u0435\u0442\u0430\u0445 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412 \u0430\u043f\u0440\u0435\u043b\u0435 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u044b \u0410\u0432\u0438\u0442\u043e \u0441\u043e\u0431\u0438\u0440\u0430\u043b\u0438\u0441\u044c \u043d\u0430 \u043e\u043d\u043b\u0430\u0439\u043d-\u043f\u043e\u0441\u0438\u0434\u0435\u043b\u043a\u0438 \u0441 \u0433\u043b\u0430\u0432\u043d\u044b\u043c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c ClickHouse \u0410\u043b\u0435\u043a\u0441\u0435\u0435\u043c \u041c\u0438\u043b\u043e\u0432\u0438\u0434\u043e\u0432\u044b\u043c \u0438 \u041a\u0438\u0440\u0438\u043b\u043b\u043e\u043c \u0428\u0432\u0430\u043a\u043e\u0432\u044b\u043c, Golang-\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Integros.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-05-08T11:42:47+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-05-08T11:42:47+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47ClickHouse para usuarios avanzados en preguntas y respuestas | ProHoster","description":"En abril, los ingenieros de Avito se reunieron en l\u00ednea con el desarrollador principal de ClickHouse, Alexey Milovidov, y Kirill Shvakov, un desarrollador de Golang de la empresa Integros.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47ClickHouse \u0434\u043b\u044f \u043f\u0440\u043e\u0434\u0432\u0438\u043d\u0443\u0442\u044b\u0445 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432 \u0432\u043e\u043f\u0440\u043e\u0441\u0430\u0445 \u0438 \u043e\u0442\u0432\u0435\u0442\u0430\u0445 | ProHoster","og:description":"\u0412 \u0430\u043f\u0440\u0435\u043b\u0435 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u044b \u0410\u0432\u0438\u0442\u043e \u0441\u043e\u0431\u0438\u0440\u0430\u043b\u0438\u0441\u044c \u043d\u0430 \u043e\u043d\u043b\u0430\u0439\u043d-\u043f\u043e\u0441\u0438\u0434\u0435\u043b\u043a\u0438 \u0441 \u0433\u043b\u0430\u0432\u043d\u044b\u043c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c ClickHouse \u0410\u043b\u0435\u043a\u0441\u0435\u0435\u043c \u041c\u0438\u043b\u043e\u0432\u0438\u0434\u043e\u0432\u044b\u043c \u0438 \u041a\u0438\u0440\u0438\u043b\u043b\u043e\u043c \u0428\u0432\u0430\u043a\u043e\u0432\u044b\u043c, Golang-\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Integros.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-05-08T11:42:47+00:00","article:modified_time":"2020-05-08T11:42:47+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"80775","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 16:11:22","updated":"2022-09-28 05:48:13","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/80775","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=80775"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/80775\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/80776"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=80775"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=80775"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=80775"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}