{"id":55734,"date":"2020-01-27T00:00:00","date_gmt":"2020-01-26T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie"},"modified":"2020-02-18T14:03:52","modified_gmt":"2020-02-18T11:03:52","slug":"highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","title":{"rendered":"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Examinaremos el funcionamiento de Zabbix con la base de datos TimescaleDB como backend. Mostraremos c\u00f3mo ponerlo en marcha desde cero y c\u00f3mo migrar desde PostgreSQL. Tambi\u00e9n presentaremos pruebas comparativas de rendimiento de dos configuraciones.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/fb4f7ea4585b6dcdafec9d0d1e3a71e4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHighLoad++ Siberia 2019. Sala \"Tomsk\". 24 de junio, 16:00. Res\u00famenes y <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/siberia\/2019\/abstracts\/5390\">presentaci\u00f3n<\/a><\/noindex>. La pr\u00f3xima conferencia de HighLoad++ se llevar\u00e1 a cabo el 6 y 7 de abril de 2020 en San Petersburgo. Detalles y entradas <noindex><a rel=\"nofollow\" href=\"http:\/\/bit.ly\/2sSxgBx\">en el enlace<\/a><\/noindex>.<\/p>\n<p><b>Andrey Gushchin (en adelante \u2013 AG):<\/b> \u2013 Soy ingeniero de soporte t\u00e9cnico de ZABBIX (en adelante \u2013 \"Zabbix\"), capacitador. He trabajado m\u00e1s de 6 a\u00f1os en soporte t\u00e9cnico y he enfrentado directamente cuestiones de rendimiento. Hoy hablar\u00e9 sobre el rendimiento que puede ofrecer TimescaleDB en comparaci\u00f3n con el tradicional PostgreSQL 10. Tambi\u00e9n habr\u00e1 una parte introductoria sobre c\u00f3mo funciona en general.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Los principales desaf\u00edos de rendimiento: desde la recolecci\u00f3n hasta la limpieza de datos<\/h3>\n<p>\nComenzaremos por se\u00f1alar que hay ciertos desaf\u00edos de rendimiento que enfrenta cada sistema de monitoreo. El primer desaf\u00edo de rendimiento es la r\u00e1pida recolecci\u00f3n y procesamiento de datos.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/a2cb78b549a55c3b59d7fcdb8b8865b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUn buen sistema de monitoreo debe recibir todos los datos de manera r\u00e1pida y oportuna, procesarlos seg\u00fan expresiones de activaci\u00f3n, es decir, procesarlos seg\u00fan ciertos criterios (que var\u00edan en diferentes sistemas) y almacenarlos en la base de datos para que esos datos puedan ser utilizados m\u00e1s adelante.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/a3ce55c3aec3eb93948150684838a5b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEl segundo desaf\u00edo de rendimiento es el almacenamiento de la historia. Almacenar en la base de datos y tener un acceso r\u00e1pido y conveniente a estas m\u00e9tricas que se han recopilado durante un cierto per\u00edodo de tiempo. Lo m\u00e1s importante es que esos datos sean accesibles y utilizables en informes, gr\u00e1ficos, activaciones, valores umbrales, alertas, etc.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/325363d79f0270d620f956eeb8ab3402.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa tercera llamada de rendimiento es la limpieza de la historia, es decir, cuando llega un d\u00eda en que no necesitas almacenar m\u00e9tricas detalladas que se han recopilado durante 5 a\u00f1os (incluso meses o dos meses). Algunos nodos de la red han sido eliminados, o algunos hosts, las m\u00e9tricas ya no son necesarias porque se han vuelto obsoletas y han dejado de ser recopiladas. Todo esto debe ser limpiado para que tu base de datos no crezca demasiado. De hecho, la limpieza de la historia suele ser una prueba seria para el almacenamiento, ya que a menudo afecta mucho al rendimiento.<\/p>\n<h3>\u00bfC\u00f3mo resolver problemas de cach\u00e9?<\/h3>\n<p>\nAhora voy a hablar espec\u00edficamente sobre 'Zabbix'. En 'Zabbix', la primera y segunda llamadas se resuelven mediante el uso de cach\u00e9.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/d5510b31553ee8e63a0c240789d51622.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa recolecci\u00f3n y el procesamiento de datos: utilizamos la memoria RAM para almacenar todos esos datos. Ahora se hablar\u00e1 con m\u00e1s detalle sobre estos datos.<\/p>\n<p>Adem\u00e1s, del lado de la base de datos hay un cierto tipo de cach\u00e9 para las consultas principales: para gr\u00e1ficos y otras cosas.<\/p>\n<p>Cach\u00e9 en el propio servidor de Zabbix: tenemos ConfigurationCache, ValueCache, HistoryCache, TrendsCache. \u00bfQu\u00e9 son?<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/241a131145eccd280a7411c43b2cdce4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nConfigurationCache es la cach\u00e9 principal, en la que almacenamos m\u00e9tricas, hosts, elementos de datos, disparadores; todo lo que se necesita para el procesamiento previo, recolecci\u00f3n de datos, de qu\u00e9 hosts recolectar, con qu\u00e9 frecuencia. Todo esto se almacena en ConfigurationCache para no ir a la base de datos, no crear solicitudes innecesarias. Despu\u00e9s de iniciar el servidor, actualizamos esta cach\u00e9 (la creamos) y la actualizamos peri\u00f3dicamente (dependiendo de la configuraci\u00f3n).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/474ac0db2e46aa945a0da62197f72987.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Cach\u00e9 en Zabbix. Recolecci\u00f3n de datos<\/h3>\n<p>\nAqu\u00ed el esquema es bastante grande:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/a6ad9dbd5deebac5440433a47c693fcf.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLos principales en el esquema son estos recolectores:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/feb932586302e2284bd44595caf9ee1b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSon los propios procesos de recolecci\u00f3n, varios 'pollers', que se encargan de diferentes tipos de recolecci\u00f3n. Recolectan datos a trav\u00e9s de icmp, ipmi, diferentes protocolos y transmiten todo esto para el procesamiento previo.<\/p>\n<h3>PreProcessing HistoryCache<\/h3>\n<p>\nAdem\u00e1s, si tenemos elementos de datos calculados (quien est\u00e9 familiarizado con 'Zabbix' lo sabe), es decir, elementos de datos calculados y agregados, los recuperamos directamente de ValueCache. M\u00e1s adelante hablar\u00e9 sobre c\u00f3mo se llena. Todos estos recolectores utilizan ConfigurationCache para obtener sus tareas y luego las transmiten para el procesamiento previo.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/3948ee1167c52856949c25e2043be974.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEl preprocesamiento tambi\u00e9n utiliza ConfigurationCache para obtener los pasos de preprocesamiento, procesando estos datos de diversas maneras. A partir de la versi\u00f3n 4.2, se ha trasladado a un proxy. Esto es muy conveniente, ya que el preprocesamiento en s\u00ed es una operaci\u00f3n bastante pesada. Y si tienes un 'Zabbix' muy grande, con muchos elementos de datos y una alta frecuencia de recopilaci\u00f3n, esto facilita mucho el trabajo.<\/p>\n<p>Por lo tanto, despu\u00e9s de procesar estos datos de alguna manera mediante el preprocesamiento, los guardamos en HistoryCache para su posterior procesamiento. Aqu\u00ed termina la recopilaci\u00f3n de datos. Pasamos al proceso principal.<\/p>\n<h3>Trabajo de History syncer<\/h3>\n<p>\n<img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/66539e4184d041ed84f797080226ba24.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEl proceso principal en 'Zabbix' (dado que es una arquitectura monol\u00edtica) es el History syncer. Este es el proceso principal que se encarga de la procesamiento at\u00f3mico de cada elemento de datos, es decir, de cada valor:<\/p>\n<ul>\n<li>recibe un valor (lo toma de HistoryCache);<\/li>\n<li>verifica en Configuration syncer: si hay alg\u00fan disparador para calcular \u2014 los calcula;<br \/>\nsi hay \u2014 crea eventos, crea una escalaci\u00f3n para generar una notificaci\u00f3n, si es necesario seg\u00fan la configuraci\u00f3n;<\/li>\n<li>registra los disparadores para su posterior procesamiento, agregaci\u00f3n; si agregas durante la \u00faltima hora y as\u00ed sucesivamente, este valor lo guarda en ValueCache, para no tener que consultar la tabla de historia; de este modo, ValueCache se llena con los datos necesarios para calcular los disparadores, los elementos calculados, etc.;<\/li>\n<li>a continuaci\u00f3n, el History syncer graba todos los datos en la base de datos;<\/li>\n<li>la base de datos los escribe en el disco - aqu\u00ed termina el proceso de procesamiento.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Bases de datos. Cach\u00e9<\/h3>\n<p>\nDel lado de la base de datos, cuando deseas ver gr\u00e1ficos o algunos informes sobre eventos, hay varios cach\u00e9s. Pero en el marco de esta presentaci\u00f3n, no voy a hablar de ellos.<\/p>\n<p>Para MySQL hay Innodb_buffer_pool, y muchos otros cach\u00e9s que tambi\u00e9n se pueden configurar.<br \/>\nPero estos son los principales:<\/p>\n<ul>\n<li>shared_buffers;<\/li>\n<li>effective_cache_size;<\/li>\n<li>shared_pool.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/925e7abb21cfaa2516ff2b33ab161dc0.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHe mencionado para todas las bases de datos que hay cach\u00e9s espec\u00edficos que permiten mantener en memoria RAM aquellos datos que son frecuentemente necesarios para consultas. Tienen sus propias tecnolog\u00edas para esto.<\/p>\n<h3>Sobre el rendimiento de la base de datos<\/h3>\n<p>\nPor lo tanto, hay un entorno competitivo, es decir, el servidor Zabbix recopila datos y los registra. Al reiniciarse, tambi\u00e9n lee de la historia para llenar el ValueCache, entre otras cosas. Aqu\u00ed tambi\u00e9n pueden haber scripts e informes que utilizan la API de Zabbix, que se basa en una interfaz web. La API de Zabbix accede a la base de datos y obtiene los datos necesarios para generar gr\u00e1ficos, informes o alguna lista de eventos, las \u00faltimas incidencias.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/10a55cb1af660aace3172a572bea6692.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOtra soluci\u00f3n muy popular para la visualizaci\u00f3n es Grafana, que utilizan nuestros usuarios. Puede acceder directamente tanto a trav\u00e9s de la API de Zabbix como de la base de datos. Esto tambi\u00e9n genera una cierta competencia para la obtenci\u00f3n de datos: se requiere una configuraci\u00f3n m\u00e1s refinada y adecuada de la base de datos para garantizar una r\u00e1pida entrega de resultados y pruebas.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/8a008e55dbee5635d386cec2fc1c40f5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Limpieza de historial. En Zabbix hay un Housekeeper.<\/h3>\n<p>\nLa tercera llamada que se utiliza en Zabbix es la limpieza del historial mediante el Housekeeper. El 'Housekeeper' respeta todas las configuraciones, es decir, en nuestros elementos de datos se indica cu\u00e1nto almacenar (en d\u00edas), cu\u00e1nto almacenar como tendencias, y la din\u00e1mica de los cambios.<\/p>\n<p>No he mencionado el TrendCache, que calculamos en tiempo real: llegan los datos, los agregamos durante una hora (principalmente son n\u00fameros del \u00faltimo hora), el promedio \/ m\u00ednimo, y lo registramos una vez por hora en la tabla de din\u00e1mica de cambios ('Trends'). El 'Housekeeper' se ejecuta y elimina los datos de la base de datos mediante selects, lo que no siempre es eficiente.<\/p>\n<p>\u00bfC\u00f3mo saber que esto no es eficiente? En los gr\u00e1ficos de rendimiento de los procesos internos, puedes ver la siguiente situaci\u00f3n:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/f413ec989491d4186a05c779978e2f6d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTu History syncer est\u00e1 constantemente ocupado (gr\u00e1fico rojo). Y el gr\u00e1fico en 'naranja' que va por encima. Este es el 'Housekeeper', que se ejecuta y espera a que la base de datos elimine todas las filas que ha se\u00f1alado.<\/p>\n<p>Tomemos alg\u00fan Item ID: necesitas eliminar las \u00faltimas 5 mil; claro, por \u00edndices. Pero normalmente el conjunto de datos es lo suficientemente grande: la base de datos de todos modos lo lee del disco y lo sube a la cach\u00e9, y esa es una operaci\u00f3n muy costosa para la base de datos. Dependiendo de su tama\u00f1o, esto puede llevar a ciertos problemas de rendimiento.<\/p>\n<p>Desactivar 'Housekeeper' se puede hacer de manera sencilla: tenemos la interfaz web que todos conocemos. En la configuraci\u00f3n de Administration general (ajustes para 'Housekeeper'), desactivamos el housekeeping interno para el historial y las tendencias internas. Por lo tanto, 'Housekeeper' ya no gestiona esto:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/c9dc3ca86e7fd0c1229f6b9bc5d31270.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00bfQu\u00e9 se puede hacer a continuaci\u00f3n? Has desactivado, tus gr\u00e1ficos se han alineado... \u00bfCu\u00e1les podr\u00edan ser los problemas que surjan despu\u00e9s? \u00bfQu\u00e9 puede ayudar?<\/p>\n<h3>Particionamiento (seccionamiento)<\/h3>\n<p>\nGeneralmente, esto se configura en cada base de datos relacional de las que he mencionado, de diferentes maneras. MySQL tiene su propia tecnolog\u00eda. Pero, en general, son muy similares si hablamos de PostgreSQL 10 y MySQL. Por supuesto, hay muchas diferencias internas sobre c\u00f3mo se implementa todo esto y c\u00f3mo afecta al rendimiento. Sin embargo, en general, la creaci\u00f3n de una nueva partici\u00f3n a menudo tambi\u00e9n conduce a ciertos problemas.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/729114d61794314e19383f09ee9b5d61.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDependiendo de tu configuraci\u00f3n (cu\u00e1ntos datos se generan en un d\u00eda), generalmente se establece el m\u00ednimo: 1 d\u00eda\/partici\u00f3n, y para 'tendencias', din\u00e1mica de cambios: 1 mes\/nueva partici\u00f3n. Esto puede cambiar si tienes una configuraci\u00f3n muy grande.<\/p>\n<p>Primero, hablemos de los tama\u00f1os de la configuraci\u00f3n: hasta 5,000 nuevos valores por segundo (nvps, as\u00ed llamado) se considera una 'configuraci\u00f3n' peque\u00f1a. Media: de 5 a 25 mil valores por segundo. Todo lo que supere esto ya son instalaciones grandes y muy grandes, que requieren una configuraci\u00f3n muy cuidadosa de la base de datos.<\/p>\n<p>En instalaciones muy grandes, 1 d\u00eda puede no ser \u00f3ptimo. Personalmente he visto en MySQL particiones de 40 gigabytes por d\u00eda (y pueden ser m\u00e1s). Este es un volumen de datos muy grande que puede causar algunos problemas. Debe reducirse.<\/p>\n<h3>\u00bfPor qu\u00e9 se necesita el particionamiento?<\/h3>\n<p>\nLo que aporta el particionamiento, creo que todos lo sabemos: es la seccionamiento de tablas. A menudo son archivos separados en el disco y consultas de span. Selecciona de manera m\u00e1s \u00f3ptima una partici\u00f3n, si est\u00e1 dentro del particionamiento habitual.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/4920fb3415733799f0a90b1bc7af0114.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPara \u00abZabbix\u00bb, en particular, se utiliza por rango, es decir, usamos timestamp (un n\u00famero com\u00fan, tiempo desde el inicio de la \u00e9poca). Usted establece el inicio del d\u00eda \/ fin del d\u00eda, y esto constituye la partici\u00f3n. Por lo tanto, si solicita datos de hace dos d\u00edas, todo esto se selecciona de la base de datos m\u00e1s r\u00e1pido porque solo se necesita cargar un archivo en la cach\u00e9 y emitirlo (y no una tabla grande).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/f5ee4e0b471eb5ebe701615aa617d66d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMuchas bases de datos tambi\u00e9n aceleran la inserci\u00f3n (inserci\u00f3n en una tabla hijo). Estoy hablando de manera abstracta, pero tambi\u00e9n es posible. La partici\u00f3n a menudo ayuda.<\/p>\n<h3>Elasticsearch para NoSQL<\/h3>\n<p>\nRecientemente, en la versi\u00f3n 3.4, implementamos una soluci\u00f3n para NoSQL. Agregamos la capacidad de escribir en Elasticsearch. Puede escribir ciertos tipos: elige \u2013 o escribes n\u00fameros, o ciertos caracteres; tenemos texto en cadena, registros puede escribir en Elasticsearch... Por lo tanto, la interfaz web tambi\u00e9n tendr\u00e1 que dirigirse a Elasticsearch. Esto funciona excelentemente en algunos casos, pero en este momento se puede utilizar.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/24fe7d19c9e42474cd786ba59846c18c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>TimescaleDB. Hiper-tablas<\/h3>\n<p>\nPara la versi\u00f3n 4.4.2, notamos una cosa, como TimescaleDB. \u00bfQu\u00e9 es esto? Es una extensi\u00f3n para \u00abPostgres\u00bb, es decir, tiene una interfaz nativa de PostgreSQL. Adem\u00e1s, esta extensi\u00f3n permite trabajar de manera mucho m\u00e1s eficiente con datos de series temporales y tener particionamiento autom\u00e1tico. As\u00ed es como se ve:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/de921f06453476215b6240ab9da6fae1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEsta es una hypertable \u2013 hay tal concepto en Timescale. Es una hiper-tabla que creas, y en ella hay chunks (fragmentos). Los chunks son particiones, son tablas hijo, si no me equivoco. Esto es realmente eficiente.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/719eb3f5d8c9f57544dfc4010850610c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>TimescaleDB y PostgreSQL<\/h3>\n<p>\nComo aseguran los productores de TimescaleDB, utilizan un algoritmo m\u00e1s correcto de procesamiento de consultas, en particular de inserciones, que permite tener un rendimiento pr\u00e1cticamente constante al aumentar el tama\u00f1o del conjunto de datos de inserci\u00f3n. Es decir, despu\u00e9s de 200 millones de filas, PostgreSQL normal comienza a bajar mucho el rendimiento y pierde productividad casi hasta cero, mientras que \u00abTimescale\u00bb permite insertar las inserciones de la manera m\u00e1s eficiente posible con cualquier cantidad de datos.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/a613d505a9dfe6008551ce981da7b24e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>\u00bfC\u00f3mo instalar TimescaleDB? \u00a1Es muy sencillo!<\/h3>\n<p>\nEn su documentaci\u00f3n se describe \u2013 se puede instalar desde paquetes para cualquier... Depende de los paquetes oficiales de \u00abPostgres\u00bb. Se puede compilar manualmente. As\u00ed sucedi\u00f3 que tuve que compilar para la base de datos.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/6767927fa92260103d318f9aa70ef5b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEn \"Zabbix\" simplemente activamos la Extensi\u00f3n. Creo que aquellos que han usado la Extensi\u00f3n en \"Postgres\"\u2026 Solo activas la Extensi\u00f3n y la creas para la base de datos \"Zabbix\" que est\u00e1s utilizando.<\/p>\n<p>Y el \u00faltimo paso\u2026<\/p>\n<h3>TimescaleDB. Migraci\u00f3n de tablas hist\u00f3ricas<\/h3>\n<p>\nNecesitas crear un hypertable. Para esto hay una funci\u00f3n especial: Create hypertable. En ella, el primer par\u00e1metro es la tabla que necesitas en esta base de datos (para la cual necesitas crear el hypertable).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/47350f79fd9829c12685c1df8f0ff9a6.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEl campo por el que necesitas crear, y chunk_time_interval (este es el intervalo de los chunks (particiones que se deben utilizar). 86 400 es un d\u00eda. <\/p>\n<p>El par\u00e1metro migrate_data: si lo estableces en true, trasladar\u00e1 todos los datos actuales a los chunks creados previamente.<\/p>\n<p>Yo mismo utilic\u00e9 migrate_data; esto toma un tiempo considerable, dependiendo del tama\u00f1o de tu base de datos. Ten\u00eda m\u00e1s de un terabyte; la creaci\u00f3n tom\u00f3 m\u00e1s de una hora. En algunos casos, al probar, elimin\u00e9 datos hist\u00f3ricos para texto (history_text) y cadena (history_str), para no trasladarlos; en realidad no me interesaban.<\/p>\n<p>Y la \u00faltima actualizaci\u00f3n la hacemos en nuestro db_extension: instalamos timescaledb para que la base de datos y, en particular, nuestro \"Zabbix\", comprendan que hay db_extension. Lo activa y utiliza correctamente la sintaxis y las consultas a la base de datos, aprovechando ya esas \"funciones\" que son necesarias para TimescaleDB.<\/p>\n<h3>Configuraci\u00f3n del servidor<\/h3>\n<p>\nUtilic\u00e9 dos servidores. El primer servidor es una m\u00e1quina virtual bastante peque\u00f1a, con 20 procesadores y 16 gigabytes de RAM. La configur\u00e9 con \"Postgres\" 10.8:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/990805374a2380a5c645c578404489bd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEl sistema operativo era Debian, el sistema de archivos \u2013 xfs. Realic\u00e9 configuraciones m\u00ednimas para utilizar exactamente esta base de datos, sin contar lo que Zabbix utilizar\u00e1. En esta misma m\u00e1quina estaba el servidor de Zabbix, PostgreSQL y los agentes de carga.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/a6efa9ab9cd58f0061d04f13fe31018c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUtilic\u00e9 50 agentes activos que utilizan LoadableModule para generar r\u00e1pidamente diversos resultados. Ellos generaban cadenas, n\u00fameros y as\u00ed sucesivamente. Llen\u00e9 la base de datos con una gran cantidad de datos. Inicialmente, la configuraci\u00f3n conten\u00eda 5 mil elementos de datos por cada host, y aproximadamente cada elemento de datos conten\u00eda un trigger, para que fuera una configuraci\u00f3n real. A veces, incluso se requiere m\u00e1s de un trigger.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/d5a3c306402e08bf2532eb6203a4aab4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEl intervalo de actualizaci\u00f3n, la carga la regul\u00e9 no solo utilizando 50 agentes (agregu\u00e9 m\u00e1s), sino tambi\u00e9n con elementos din\u00e1micos de datos y reduje el intervalo de actualizaci\u00f3n a 4 segundos.<\/p>\n<h3>Prueba de rendimiento. PostgreSQL: 36 mil NVPs<\/h3>\n<p>\nEl primer lanzamiento, la primera configuraci\u00f3n la hice en PostgreSQL 10 limpio en este hardware (35 mil valores por segundo). En general, como se puede ver en la pantalla, la inserci\u00f3n de datos toma fracciones de segundo: todo bien y r\u00e1pido, discos SSD (200 gigabytes). Lo \u00fanico es que 20 GB se llenan bastante r\u00e1pido.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/6803a64fedd26093b9117a036d2993ae.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHabr\u00e1 muchos gr\u00e1ficos como este m\u00e1s adelante. Este es el panel de rendimiento est\u00e1ndar del servidor 'Zabbix'.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/081cc11c6bf42db3f8f16b6cc4e6ee0c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEl primer gr\u00e1fico muestra la cantidad de valores por segundo (azul, en la parte superior izquierda), 35 mil valores en este caso. Esto (en la parte superior del centro) es la carga de los procesos de recopilaci\u00f3n, y esto (en la parte superior derecha) es la carga de los procesos internos: history syncers y housekeeper, que aqu\u00ed (en la parte inferior del centro) se ejecut\u00f3 durante un tiempo considerable.<\/p>\n<p>Este gr\u00e1fico (en la parte inferior del centro) muestra el uso de ValueCache: cu\u00e1ntos hits de ValueCache para los triggers (varios miles de valores por segundo). Otro gr\u00e1fico importante es el cuarto (en la parte inferior izquierda), que muestra el uso de HistoryCache, del que habl\u00e9, que es un buffer antes de la inserci\u00f3n en la base de datos.<\/p>\n<h3>Prueba de rendimiento. PostgreSQL: 50 mil NVPs<\/h3>\n<p>\nLuego aument\u00e9 la carga a 50 mil valores por segundo en este mismo hardware. Al cargar con 'Housekeeper', ya se registraban 10 mil valores en 2-3 segundos con el c\u00e1lculo. Lo que, de hecho, se muestra en la siguiente captura de pantalla:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/80824da986dbee2f8d5ebe0ead4fbcfd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n'Housekeeper' ya empieza a interferir con el trabajo, pero en general la carga de los trappers de los history syncers a\u00fan permanece en el nivel del 60 % (tercer gr\u00e1fico, en la parte superior derecha). HistoryCache ya durante la operaci\u00f3n de 'Housekeeper' comienza a llenarse activamente (en la parte inferior izquierda). Era alrededor de medio gigabyte, y se llen\u00f3 en un 20 %.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/9e1bcd4f3b9f3e8a1c9a36b2083ec61b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Prueba de rendimiento. PostgreSQL: 80 mil NVPs<\/h3>\n<p>\nLuego aument\u00e9 a 80 mil valores por segundo:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/13ae1589d6b9d35b4dda9c6c7d989cc2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHab\u00eda aproximadamente 400 mil elementos de datos, 280 mil disparadores. La carga, como pueden ver, por la carga de los history-syncers (hab\u00eda 30 en total) ya era bastante alta. Luego aument\u00e9 varios par\u00e1metros: history-syncers, cach\u00e9\u2026 En este hardware, la carga de los history-syncers comenz\u00f3 a aumentar al m\u00e1ximo, pr\u00e1cticamente \"en su l\u00edmite\" \u2013 de acuerdo, HistoryCache estaba bajo una carga muy alta:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/0ec528256c8fa7b16e1c7c95c8119535.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDurante todo este tiempo, observ\u00e9 todos los par\u00e1metros del sistema (c\u00f3mo se utilizaba la CPU, la memoria RAM) y descubr\u00ed que la utilizaci\u00f3n de los discos era m\u00e1xima: hab\u00eda alcanzado la capacidad m\u00e1xima de ese disco en este hardware, en esta m\u00e1quina virtual. PostgreSQL comenz\u00f3, con esa intensidad, a descargar datos de manera bastante activa, y el disco ya no pod\u00eda mantenerse al ritmo de escritura, lectura\u2026<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/0809dbd7638e7ee003ea24c611984a0c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTom\u00e9 otro servidor que ya ten\u00eda 48 procesadores y 128 gigabytes de RAM:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/53410b502a4574aac5d40f1a2a6d3f42.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTambi\u00e9n lo \"optimic\u00e9\" - instal\u00e9 60 history syncers y logr\u00e9 un rendimiento aceptable. De hecho, no estamos \"en su l\u00edmite\", pero este es, probablemente, el m\u00e1ximo rendimiento donde ya es necesario tomar medidas.<\/p>\n<h3>Prueba de rendimiento. TimescaleDB: 80 mil NVPs<\/h3>\n<p>\nTen\u00eda una tarea principal: usar TimescaleDB. En cada gr\u00e1fico se puede ver una ca\u00edda:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/b0064068895a34b93b5aa6771aba05cb.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEstas ca\u00eddas son precisamente la migraci\u00f3n de datos. Despu\u00e9s de eso, en el servidor de Zabbix, el perfil de carga de los history-syncers, como pueden ver, cambi\u00f3 dr\u00e1sticamente. Permite insertar datos casi 3 veces m\u00e1s r\u00e1pido y utilizar menos HistoryCache \u2013 por lo tanto, los datos se suministrar\u00e1n a tiempo. Nuevamente, 80 mil valores por segundo \u2013 es una tasa bastante alta (por supuesto, no para Yandex). En general, es un set up bastante grande, con un solo servidor.<\/p>\n<h3>Prueba de rendimiento de PostgreSQL: 120 mil NVPs<\/h3>\n<p>\nLuego increment\u00e9 el n\u00famero de elementos de datos a medio mill\u00f3n y obtuve un valor calculado de 125 mil por segundo:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/7d0cf2ef7c6691c1bbf4b90afd34e4bb.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nY obtuve estos gr\u00e1ficos:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/9c09333a50e016921a8a5b70e00397a1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEn principio, es un set up funcional, puede operar durante un per\u00edodo bastante prolongado. Pero como solo ten\u00eda un disco de 1.5 terabytes, lo consum\u00ed en un par de d\u00edas. Lo m\u00e1s importante es que al mismo tiempo se estaban creando nuevas particiones en TimescaleDB, y eso para el rendimiento pasaba absolutamente desapercibido, lo que no se puede decir de MySQL.<\/p>\n<p>Normalmente, las particiones se crean por la noche, ya que esto bloquea cualquier inserci\u00f3n y operaci\u00f3n con tablas, lo que puede llevar a una degradaci\u00f3n del servicio. \u00a1En este caso, esto no ha ocurrido! La tarea principal era verificar las capacidades de TimescaleDB. Se obtuvo una cifra de 120 mil valores por segundo.<\/p>\n<p>Tambi\u00e9n hay ejemplos en la \u00abcomunidad\u00bb:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/66aa6b1d4c559d12082e4d91b6a1ca10.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUna persona tambi\u00e9n activ\u00f3 TimescaleDB y la carga por uso de io.weight disminuy\u00f3 en el procesador; y el uso de los elementos de los procesos internos tambi\u00e9n se redujo gracias a la activaci\u00f3n de TimescaleDB. \u00a1Y son discos duros normales, es decir, una m\u00e1quina virtual en discos normales (no SSD)!<\/p>\n<p>Para algunas configuraciones peque\u00f1as que est\u00e1n limitadas por el rendimiento del disco, TimescaleDB, en mi opini\u00f3n, es una muy buena soluci\u00f3n. Esto permitir\u00e1 continuar operando hasta que migres a hardware m\u00e1s r\u00e1pido para la base de datos.<\/p>\n<p>Los invito a todos a nuestros eventos: Conferencia \u2013 en Mosc\u00fa, Cumbre \u2013 en Riga. Utilicen nuestros canales: \u00abTelegram\u00bb, foro, IRC. Si tienen alguna pregunta, ac\u00e9rquense a nuestro stand, podemos hablar de todo.<\/p>\n<h3>Preguntas de la audiencia<\/h3>\n<p>\nPregunta de la audiencia (en adelante \u2013 A): \u2013 Si TimescaleDB es tan f\u00e1cil de configurar y proporciona un aumento tan grande en el rendimiento, \u00bfquiz\u00e1s deber\u00eda utilizarse como mejor pr\u00e1ctica para la configuraci\u00f3n de \u00abZabbix\u00bb con \u00abPostgres\u00bb? \u00bfY hay alguna trampa o desventajas en esta soluci\u00f3n, o en realidad, si decid\u00ed hacer \u00abZabbix\u00bb, puedo simplemente usar \u00abPostgres\u00bb, instalar \u00abTimescale\u00bb de inmediato, usarlo y no preocuparme por ning\u00fan problema?<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/314845a019724806283a957b15d857cc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>AG:<\/b> \u2013 S\u00ed, dir\u00eda que es una buena recomendaci\u00f3n: usar \u00abPostgres\u00bb desde el principio con la extensi\u00f3n TimescaleDB. Como ya dije, hay muchas buenas opiniones, a pesar de que esta \u00abfunci\u00f3n\u00bb es experimental. Pero en realidad, las pruebas muestran que es una excelente soluci\u00f3n (con TimescaleDB), y creo que seguir\u00e1 desarroll\u00e1ndose. Estamos siguiendo c\u00f3mo se desarrolla esta extensi\u00f3n y corregiremos lo que sea necesario.<\/p>\n<p>Incluso durante el desarrollo nos basamos en una de sus conocidas \u00abfunciones\u00bb: all\u00ed se pod\u00eda trabajar un poco diferente con los chunks. Pero luego lo eliminaron en la siguiente versi\u00f3n, y tuvimos que dejar de depender de ese c\u00f3digo. Recomendar\u00eda usar esta soluci\u00f3n en muchas configuraciones. Si usas MySQL\u2026 Para configuraciones medias, cualquier soluci\u00f3n funciona bastante bien.<\/p>\n<p><b>A:<\/b> \u2013 En los \u00faltimos gr\u00e1ficos de la comunidad, hab\u00eda un gr\u00e1fico con \"Housekeeper\":<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/d01549b6b9b97d8bdf5372efe05d9039.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSigui\u00f3 funcionando. \u00bfQu\u00e9 hace \"Housekeeper\" en el caso de TimescaleDB?<\/p>\n<p><b>AG:<\/b> \u2013 Ahora no puedo decirlo con certeza; revisar\u00e9 el c\u00f3digo y lo dir\u00e9 con m\u00e1s detalle. Utiliza consultas de TimescaleDB no para eliminar chunks, sino que de alguna manera agrega. Por ahora, no estoy listo para responder a esta pregunta t\u00e9cnica. En el stand lo aclararemos hoy o ma\u00f1ana.<\/p>\n<p><b>A:<\/b> \u2013 Tengo una pregunta similar: sobre el rendimiento de la operaci\u00f3n de eliminaci\u00f3n en \"Timescale\".<br \/>\nY (respuesta de la audiencia): \u2013 Cuando eliminas datos de una tabla, si lo haces a trav\u00e9s de delete, necesitas recorrer la tabla: eliminar, limpiar, marcar todo para el futuro vacuum. En \"Timescale\", dado que tienes chunks, puedes eliminarlos. En t\u00e9rminos simples, le est\u00e1s diciendo al archivo que est\u00e1 en big data: \"\u00a1Elimina!\"<\/p>\n<p>\"Timescale\" simplemente entiende que ese chunk ya no existe. Y como se integra en el planificador de consultas, detecta tus condiciones en el select o en otras operaciones y entiende de inmediato que ese chunk ya no existe \u2013 \"\u00a1No ir\u00e9 all\u00ed!\" (los datos est\u00e1n ausentes). \u00a1Eso es todo! Es decir, el escaneo de la tabla se reemplaza por la eliminaci\u00f3n de un archivo binario, por lo que es r\u00e1pido.<\/p>\n<p><b>A:<\/b> \u2013 Ya se toc\u00f3 el tema de no SQL. Seg\u00fan tengo entendido, \"Zabbix\" no necesita mucho modificar datos, y todo esto es algo as\u00ed como un registro. \u00bfSe pueden usar bases de datos especializadas que no pueden cambiar sus datos, pero que, sin embargo, guardan, acumulan y regresan mucho m\u00e1s r\u00e1pido \u2013 como Clickhouse, o algo tipo Kafka...? \u00a1Kafka tambi\u00e9n es un registro! \u00bfSe pueden integrar de alguna manera?<\/p>\n<p><b>AG:<\/b> \u2013 Se puede hacer una exportaci\u00f3n. Tenemos una caracter\u00edstica espec\u00edfica desde la versi\u00f3n 3.4: puedes escribir en archivos todos los archivos hist\u00f3ricos, eventos, todo lo dem\u00e1s; y despu\u00e9s, con alg\u00fan procesador, enviarlo a cualquier otra base de datos. De hecho, muchos est\u00e1n rehaciendo y escribiendo directamente en la base de datos. Los history-sinkers lo escriben en archivos sobre la marcha, rotan esos archivos, etc., y puedes transferirlo a \"Clickhouse\". No puedo hablar sobre planes, pero quiz\u00e1s el soporte futuro para soluciones NoSQL (como \"Clickhouse\") contin\u00fae.<\/p>\n<p><b>A:<\/b> \u2013 Entonces, \u00bfes posible deshacerse completamente de Postgres?<\/p>\n<p><b>AG:<\/b> \u2013 Por supuesto, la parte m\u00e1s dif\u00edcil de \u00abZabbix\u00bb son las tablas hist\u00f3ricas, que crean m\u00e1s problemas, y los eventos. En este caso, si no almacenas los eventos durante mucho tiempo y guardas la historia con tendencias en alg\u00fan otro almacenamiento r\u00e1pido, en general no deber\u00eda haber problemas, creo yo.<\/p>\n<p><b>A:<\/b> \u2013 \u00bfPuedes estimar cu\u00e1nto m\u00e1s r\u00e1pido funcionar\u00e1 todo si cambiamos a \u00abClickHouse\u00bb, por ejemplo?<\/p>\n<p><b>AG:<\/b> \u2013 No he probado. Creo que al menos se podr\u00edan alcanzar las mismas cifras bastante f\u00e1cilmente, considerando que \u00abClickHouse\u00bb tiene su propia interfaz, pero no puedo decirlo con seguridad. Lo mejor es probar. Todo depende de la configuraci\u00f3n: cu\u00e1ntos hosts tienes, etc. La inserci\u00f3n es una cosa, pero tambi\u00e9n necesitas obtener esos datos, ya sea con Grafana o alguna otra herramienta.<\/p>\n<p><b>A:<\/b> \u2013 Entonces se trata de una competencia equitativa, no de una gran ventaja de estas bases de datos r\u00e1pidas?<\/p>\n<p><b>AG:<\/b> \u2013 Creo que cuando integremos, tendremos pruebas m\u00e1s precisas.<\/p>\n<p><b>A:<\/b> \u2013 \u00bfY qu\u00e9 pas\u00f3 con el viejo y querido RRD? \u00bfQu\u00e9 te llev\u00f3 a cambiar a bases de datos SQL? Inicialmente, todas las m\u00e9tricas se recopilaban en RRD.<\/p>\n<p><b>AG:<\/b> \u2013 En \u00abZabbix\u00bb, RRD puede haber existido en una versi\u00f3n muy antigua. Siempre han existido bases de datos SQL: el enfoque cl\u00e1sico. El enfoque cl\u00e1sico es MySQL, PostgreSQL (que ya existen desde hace mucho tiempo). Tenemos una interfaz com\u00fan para bases de datos SQL y casi nunca hemos utilizado RRD.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/ac5f02494c63983601cc09c0b22e722b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<center><div class=\"youtube-placeholder\" data-id=\"umRk94j5M8o\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/umRk94j5M8o\/hqdefault.jpg\" alt=\"Reproducir video\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><\/p>\n<h3>Un poco de publicidad \ud83d\ude42<\/h3>\n<p>\nGracias por permanecer con nosotros. \u00bfTe gustan nuestros art\u00edculos? \u00bfQuieres ver m\u00e1s contenido interesante? Ap\u00f3yanos haciendo un pedido o recomendando a tus conocidos, <noindex><a rel=\"nofollow\" href=\"https:\/\/ua-hosting.company\/cloudvps\/nl\">VPS en la nube para desarrolladores desde $4.99<\/a><\/noindex>, <b>un an\u00e1logo \u00fanico de servidores entry-level que hemos dise\u00f1ado para Ti:<\/b> <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/ua-hosting\/blog\/347386\/\">Toda la verdad sobre VPS (KVM) E5-2697 v3 (6 n\u00facleos) 10GB DDR4 480GB SSD 1Gbps desde $19, o c\u00f3mo dividir correctamente un servidor?<\/a><\/noindex> (disponibles opciones con RAID1 y RAID10, hasta 24 n\u00facleos y hasta 40GB DDR4).<\/p>\n<p><b>\u00bfDell R730xd a mitad de precio en el centro de datos Equinix Tier IV en \u00c1msterdam?<\/b> Solo aqu\u00ed <b><noindex><a rel=\"nofollow\" href=\"https:\/\/ua-hosting.company\/serversnl\">2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB desde $199<\/a><\/noindex> \u00a1en los Pa\u00edses Bajos! <b>Dell R420 \u2014 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB \u2014 \u00a1desde $99!<\/b><\/b> Lee sobre c\u00f3mo <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/ua-hosting\/blog\/329618\/\">Construir infraestructura de clase empresarial usando servidores Dell R730xd E5-2650 v4 que cuestan 9000 euros a un precio asequible?<\/a><\/noindex><br \/>\n<br \/>Fuente: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/ua-hosting\/blog\/485470\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0440\u0430\u0431\u043e\u0442\u0443 Zabbix \u0441 \u0431\u0430\u0437\u043e\u0439 \u0434\u0430\u043d\u043d\u044b\u0445 TimescaleDB \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 backend. \u041f\u043e\u043a\u0430\u0436\u0435\u043c, \u043a\u0430\u043a \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0441 \u043d\u0443\u043b\u044f \u0438 \u043a\u0430\u043a \u043c\u0438\u0433\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441 PostgreSQL. \u0422\u0430\u043a\u0436\u0435 \u043f\u0440\u0438\u0432\u0435\u0434\u0435\u043c \u0441\u0440\u0430\u0432\u043d\u0438\u0442\u0435\u043b\u044c\u043d\u044b\u0435 \u0442\u0435\u0441\u0442\u044b \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0434\u0432\u0443\u0445 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u0439. HighLoad++ Siberia 2019. \u0417\u0430\u043b \u00ab\u0422\u043e\u043c\u0441\u043a\u00bb. 24 \u0438\u044e\u043d\u044f, 16:00. \u0422\u0435\u0437\u0438\u0441\u044b \u0438 \u043f\u0440\u0435\u0437\u0435\u043d\u0442\u0430\u0446\u0438\u044f. \u0421\u043b\u0435\u0434\u0443\u044e\u0449\u0430\u044f \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u044f HighLoad++ \u043f\u0440\u043e\u0439\u0434\u0435\u0442 6 \u0438 7 \u0430\u043f\u0440\u0435\u043b\u044f 2020 \u0433\u043e\u0434\u0430 \u0432 \u0421\u0430\u043d\u043a\u0442-\u041f\u0435\u0442\u0435\u0440\u0431\u0443\u0440\u0433\u0435. \u041f\u043e\u0434\u0440\u043e\u0431\u043d\u043e\u0441\u0442\u0438 \u0438 \u0431\u0438\u043b\u0435\u0442\u044b \u043f\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-55734","post","type-post","status-publish","format-standard","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=\"\u041c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0440\u0430\u0431\u043e\u0442\u0443 Zabbix \u0441 \u0431\u0430\u0437\u043e\u0439 \u0434\u0430\u043d\u043d\u044b\u0445 TimescaleDB \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 backend. \u041f\u043e\u043a\u0430\u0436\u0435\u043c, \u043a\u0430\u043a \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0441 \u043d\u0443\u043b\u044f \u0438 \u043a\u0430\u043a \u043c\u0438\u0433\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441 PostgreSQL.\" \/>\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\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie\" \/>\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\udd47HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): \u0432\u044b\u0441\u043e\u043a\u0430\u044f \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u0438 \u043d\u0430\u0442\u0438\u0432\u043d\u043e\u0435 \u043f\u0430\u0440\u0442\u0438\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0440\u0430\u0431\u043e\u0442\u0443 Zabbix \u0441 \u0431\u0430\u0437\u043e\u0439 \u0434\u0430\u043d\u043d\u044b\u0445 TimescaleDB \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 backend. \u041f\u043e\u043a\u0430\u0436\u0435\u043c, \u043a\u0430\u043a \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0441 \u043d\u0443\u043b\u044f \u0438 \u043a\u0430\u043a \u043c\u0438\u0433\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441 PostgreSQL.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie\" \/>\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-01-26T21:00:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-18T11:03:52+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\udd47HighLoad++, Andrey Gushchin (Zabbix): alto rendimiento y particionamiento nativo | ProHoster","description":"Veremos el funcionamiento de Zabbix con la base de datos TimescaleDB como backend. Mostraremos c\u00f3mo iniciar desde cero y c\u00f3mo migrar desde PostgreSQL.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","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\udd47HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): \u0432\u044b\u0441\u043e\u043a\u0430\u044f \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u0438 \u043d\u0430\u0442\u0438\u0432\u043d\u043e\u0435 \u043f\u0430\u0440\u0442\u0438\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 | ProHoster","og:description":"\u041c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0440\u0430\u0431\u043e\u0442\u0443 Zabbix \u0441 \u0431\u0430\u0437\u043e\u0439 \u0434\u0430\u043d\u043d\u044b\u0445 TimescaleDB \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 backend. \u041f\u043e\u043a\u0430\u0436\u0435\u043c, \u043a\u0430\u043a \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0441 \u043d\u0443\u043b\u044f \u0438 \u043a\u0430\u043a \u043c\u0438\u0433\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441 PostgreSQL.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","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-01-26T21:00:00+00:00","article:modified_time":"2020-02-18T11:03:52+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"55734","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 19:37:39","updated":"2022-09-28 01:51:35","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\/55734","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=55734"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/55734\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=55734"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=55734"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=55734"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}