{"id":36737,"date":"2019-10-31T22:13:29","date_gmt":"2019-10-31T19:13:29","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-my-testirovali-neskolko-baz-dannyh-vremennyh-ryadov\/"},"modified":"2019-10-31T22:13:29","modified_gmt":"2019-10-31T19:13:29","slug":"kak-my-testirovali-neskolko-baz-dannyh-vremennyh-ryadov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kak-my-testirovali-neskolko-baz-dannyh-vremennyh-ryadov","title":{"rendered":"C\u00f3mo probamos varias bases de datos de series temporales","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"C\u00f3mo probamos varias bases de datos de series temporales\" src=\"\/wp-content\/uploads\/2019\/08\/14e07eac02df8d1276c46c33276d8a26.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEn los \u00faltimos a\u00f1os, las bases de datos de series temporales (Time-series databases) han pasado de ser una curiosidad (aplicadas de manera muy especializada, ya sea en sistemas de monitoreo abiertos, ligados a soluciones espec\u00edficas, o en proyectos de Big Data) a un \"producto de consumo masivo\". En Rusia, debemos dar las gracias a Yandex y ClickHouse por esto. Hasta ese momento, si necesitabas almacenar una gran cantidad de datos de series temporales, ten\u00edas que resignarte a levantar un monstruoso stack de Hadoop y mantenerlo, o interactuar con protocolos espec\u00edficos de cada sistema. <\/p>\n<p>Puede parecer que en 2019 el art\u00edculo sobre qu\u00e9 TSDB usar se reducir\u00eda a una sola frase: \"simplemente utiliza ClickHouse\". Pero... hay matices. <\/p>\n<p>De hecho, ClickHouse est\u00e1 en pleno desarrollo, su base de usuarios crece y el soporte se lleva a cabo de manera muy activa, pero \u00bfnos hemos convertido en rehenes del \u00e9xito p\u00fablico de ClickHouse, que ha eclipsado otras soluciones que podr\u00edan ser m\u00e1s eficientes\/fiables? <\/p>\n<p>A principios del a\u00f1o pasado, comenzamos a redise\u00f1ar nuestro propio sistema de monitoreo, durante el cual surgi\u00f3 la cuesti\u00f3n de elegir la base adecuada para el almacenamiento de datos. Quiero contarles la historia de esta elecci\u00f3n aqu\u00ed.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h4>Planteamiento del problema<\/h4>\n<p>\nPrimero que nada, una introducci\u00f3n necesaria. \u00bfPor qu\u00e9 necesitamos un sistema de monitoreo propio y c\u00f3mo estaba estructurado?<\/p>\n<p>Comenzamos a ofrecer servicios de soporte en 2008, y para 2010 se hizo evidente que agregar datos sobre los procesos en la infraestructura del cliente con las soluciones que exist\u00edan en ese momento hab\u00eda comenzado a ser complicado (estamos hablando de, Dios nos libre, Cacti, Zabbix y el emergente Graphite).<\/p>\n<p>Nuestros principales requisitos eran:<\/p>\n<ul>\n<li>soporte (en ese momento, decenas, y a futuro, cientos) de clientes dentro de un mismo sistema y, adem\u00e1s, un sistema centralizado para la gesti\u00f3n de alertas;<\/li>\n<li>flexibilidad en la gesti\u00f3n del sistema de alertas (escalamiento de alertas entre los de guardia, consideraci\u00f3n de horarios, base de conocimientos);<\/li>\n<li>opci\u00f3n de una detallada visualizaci\u00f3n de gr\u00e1ficos (Zabbix en ese momento representaba los gr\u00e1ficos como im\u00e1genes);<\/li>\n<li>almacenamiento a largo plazo de una gran cantidad de datos (un a\u00f1o o m\u00e1s) y la posibilidad de una r\u00e1pida recuperaci\u00f3n de los mismos.<\/li>\n<\/ul>\n<p>\nEn este art\u00edculo, nos interesa el \u00faltimo punto.<\/p>\n<p>Hablando de almacenamiento, los requisitos fueron los siguientes:<\/p>\n<ul>\n<li>el sistema debe funcionar r\u00e1pidamente;<\/li>\n<li>es deseable que el sistema tenga una interfaz SQL;<\/li>\n<li>el sistema debe ser estable y tener una base de usuarios activa y soporte (en alg\u00fan momento nos enfrentamos a la necesidad de mantener sistemas como MemcacheDB, que dejaron de desarrollarse, o el almacenamiento distribuido MooseFS, cuyo seguimiento de errores se llevaba a cabo en chino: no quer\u00edamos repetir esta historia para nuestro proyecto);<\/li>\n<li>conformidad con el teorema CAP: Consistencia (necesaria) \u2014 los datos deben estar actualizados, no queremos que el sistema de gesti\u00f3n de alertas no reciba nuevos datos y emita alertas sobre la falta de datos en todos los proyectos; Tolerancia a particiones (necesaria) \u2014 no queremos tener un sistema de cerebro dividido; Disponibilidad (no cr\u00edtica, en caso de existir una r\u00e9plica activa) \u2014 podemos cambiar nosotros mismos a un sistema de respaldo en caso de emergencia, mediante c\u00f3digo.<\/li>\n<\/ul>\n<p>\nCuriosamente, en ese momento la soluci\u00f3n ideal para nosotros result\u00f3 ser MySQL. Nuestra estructura de datos era sumamente simple: id del servidor, id del contador, timestamp y valor; la r\u00e1pida consulta de datos actuales se aseguraba con un gran tama\u00f1o de buffer pool, y la consulta de datos hist\u00f3ricos \u2014 con SSD.<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo probamos varias bases de datos de series temporales\" src=\"\/wp-content\/uploads\/2019\/08\/555bff26c74badf85131c4d9198871af.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAs\u00ed, logramos obtener datos frescos de dos semanas, con una precisi\u00f3n de hasta un segundo, en 200 ms antes de completar la visualizaci\u00f3n de los datos, y vivimos en este sistema bastante tiempo.<\/p>\n<p>Mientras tanto, el tiempo pas\u00f3 y la cantidad de datos creci\u00f3. Para 2016, los vol\u00famenes de datos alcanzaban decenas de terabytes, lo que representaba un gasto significativo en almacenamiento SSD alquilado.<\/p>\n<p>Para ese momento, las bases de datos en columna hab\u00edan ganado gran popularidad, y comenzamos a pensar activamente en ellas: en las BD en columna, los datos se almacenan, como se puede entender, en columnas, y si miramos nuestros datos, es f\u00e1cil ver una gran cantidad de duplicados, que podr\u00edan comprimirse si hubi\u00e9ramos utilizado una BD en columna.<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo probamos varias bases de datos de series temporales\" src=\"\/wp-content\/uploads\/2019\/08\/2e1a6010fcb09de8cd28ec826752d160.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSin embargo, el sistema clave para el funcionamiento de la empresa continu\u00f3 funcionando de manera estable, y no quer\u00edamos experimentar con la transici\u00f3n a algo diferente.<\/p>\n<p>En 2017, en la conferencia Percona Live en San Jos\u00e9, los desarrolladores de Clickhouse probablemente se dieron a conocer por primera vez. A simple vista, el sistema estaba listo para producci\u00f3n (bueno, Yandex.Metrica es un entorno de producci\u00f3n serio), el soporte era r\u00e1pido y sencillo, y lo m\u00e1s importante, la operaci\u00f3n era f\u00e1cil. Desde 2018 iniciamos el proceso de transici\u00f3n. Pero para entonces, hab\u00eda muchas m\u00e1s soluciones TSDB 'maduras' y probadas, por lo que decidimos dedicar un tiempo considerable a comparar alternativas para asegurarnos de que no hab\u00eda soluciones alternativas a Clickhouse que cumplieran con nuestros requisitos.<\/p>\n<p>Adem\u00e1s de los requisitos ya mencionados para el almacenamiento, surgieron nuevos:<\/p>\n<ul>\n<li>el nuevo sistema debe proporcionar, como m\u00ednimo, el mismo rendimiento que MySQL, con el mismo hardware;<\/li>\n<li>el almacenamiento del nuevo sistema debe ocupar significativamente menos espacio;<\/li>\n<li>la base de datos a\u00fan debe ser f\u00e1cil de administrar;<\/li>\n<li>se deseaba cambiar lo menos posible la aplicaci\u00f3n al cambiar de base de datos.<\/li>\n<\/ul>\n<p><\/p>\n<h4>Qu\u00e9 sistemas comenzamos a considerar<\/h4>\n<p>\n<b><u>Apache Hive\/Apache Impala<\/u><\/b><br \/>\nUna pila de Hadoop probada en batalla. Esencialmente, es una interfaz SQL construida sobre el almacenamiento de datos en formatos propios en HDFS. <\/p>\n<p>Ventajas.<\/p>\n<ul>\n<li>Con un funcionamiento estable, es muy f\u00e1cil escalar los datos.<\/li>\n<li>Existen soluciones de almacenamiento columnar (menos espacio).<\/li>\n<li>Ejecuciones muy r\u00e1pidas de tareas paralelizadas con los recursos disponibles.<\/li>\n<\/ul>\n<p>\nDesventajas.<\/p>\n<ul>\n<li>Es Hadoop, y es complicado de operar. Si no estamos dispuestos a adoptar una soluci\u00f3n lista en la nube (y no lo estamos por el costo), toda la pila tendr\u00e1 que ser ensamblada y mantenida por los administradores, lo cual no es algo que deseemos.<\/li>\n<li>Los datos se agregan <noindex><a rel=\"nofollow\" href=\"https:\/\/www.percona.com\/blog\/2014\/04\/21\/using-apache-hadoop-and-impala-together-with-mysql-for-data-analysis\/\">realmente r\u00e1pido<\/a><\/noindex>.<\/li>\n<\/ul>\n<p>\nSin embargo:<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo probamos varias bases de datos de series temporales\" src=\"\/wp-content\/uploads\/2019\/08\/6baa1b6024def8c1c7518ef386cfc8d3.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa velocidad se logra escalando el n\u00famero de servidores de c\u00e1lculo. En otras palabras, si somos una gran empresa, estamos involucrados en an\u00e1lisis, y es crucial para el negocio agregar informaci\u00f3n de la manera m\u00e1s r\u00e1pida posible (incluso a costa de utilizar una gran cantidad de recursos computacionales), esto puede ser nuestra elecci\u00f3n. Pero no est\u00e1bamos dispuestos a aumentar dr\u00e1sticamente nuestro equipo de hardware para acelerar la ejecuci\u00f3n de tareas.<\/p>\n<p><b><u>Druid\/Pinot<\/u><\/b><\/p>\n<p>Ya se trata mucho m\u00e1s de TSDB en concreto, pero una vez m\u00e1s, una pila de Hadoop.<\/p>\n<p>Hay <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/@leventov\/comparison-of-the-open-source-olap-systems-for-big-data-clickhouse-druid-and-pinot-8e042a5ed1c7\">Un gran art\u00edculo que compara las ventajas y desventajas de Druid y Pinot en comparaci\u00f3n con ClickHouse. <\/a><\/noindex>. <\/p>\n<p>Si se puede resumir en pocas palabras: Druid\/Pinot parecen m\u00e1s atractivos que ClickHouse en los siguientes casos:<\/p>\n<ul>\n<li>Usted tiene un car\u00e1cter de datos heterog\u00e9neo (en nuestro caso, solo registramos series temporales de m\u00e9tricas del servidor, y, de hecho, esto es una sola tabla. Pero pueden existir otros casos: series temporales de equipos, series temporales econ\u00f3micas, etc., cada uno con su propia estructura, que deben ser agregadas y procesadas).<\/li>\n<li>Sin embargo, hay una gran cantidad de estos datos.<\/li>\n<li>Las tablas y los datos con series temporales aparecen y desaparecen (es decir, un conjunto de datos lleg\u00f3, fue analizado y eliminado).<\/li>\n<li>No hay un criterio claro por el cual los datos puedan ser particionados.<\/li>\n<\/ul>\n<p>\nEn casos opuestos, ClickHouse se desempe\u00f1a mejor, que es nuestro caso.<\/p>\n<p><b><u>ClickHouse<\/u><\/b><\/p>\n<ul>\n<li>Similar a SQL.<\/li>\n<li>F\u00e1cil de administrar.<\/li>\n<li>La gente dice que funciona.<\/li>\n<\/ul>\n<p>\nLlega a la lista corta de pruebas.<\/p>\n<p><b><u>InfluxDB<\/u><\/b><\/p>\n<p>Alternativa extranjera a ClickHouse. Entre sus desventajas: la alta disponibilidad solo est\u00e1 presente en la versi\u00f3n comercial, pero deber\u00eda hacerse una comparaci\u00f3n.<\/p>\n<p>Llega a la lista corta de pruebas.<\/p>\n<p><b><u>Cassandra<\/u><\/b> <\/p>\n<p>Por un lado, sabemos que se utiliza para almacenar series temporales m\u00e9tricas en sistemas de monitoreo como, por ejemplo, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.signalfx.com\/blog\/making-cassandra-perform-as-a-tsdb\/\">SignalFX<\/a><\/noindex> o OkMeter. Sin embargo, hay especificidades.<\/p>\n<p>Cassandra no es una base de datos columna en el sentido tradicional. Se asemeja m\u00e1s a una base de datos de filas, pero en cada fila puede haber una cantidad variable de columnas, lo que facilita la organizaci\u00f3n de una presentaci\u00f3n en columnas. En este sentido, est\u00e1 claro que con un l\u00edmite de 2 mil millones de columnas, se pueden almacenar algunos datos precisamente en columnas (como las mismas series temporales). Por ejemplo, en MySQL hay un l\u00edmite de 4096 columnas y es f\u00e1cil encontrarse con un error de c\u00f3digo 1117 si se intenta hacer lo mismo.<\/p>\n<p>El motor de Cassandra est\u00e1 dise\u00f1ado para almacenar grandes vol\u00famenes de datos en un sistema distribuido sin maestro, y en el mencionado teorema CAP, Cassandra se centra m\u00e1s en AP, es decir, en la disponibilidad de datos y la resiliencia a la partici\u00f3n. Por lo tanto, esta herramienta puede ser ideal si se necesita escribir en la base de datos y leer de ella con poca frecuencia. Aqu\u00ed ser\u00eda l\u00f3gico utilizar Cassandra como un almacenamiento 'fr\u00edo', es decir, como un lugar de almacenamiento confiable a largo plazo para grandes vol\u00famenes de datos hist\u00f3ricos que rara vez se requieren, pero que se pueden recuperar si es necesario. Sin embargo, para ser completos, tambi\u00e9n la probaremos. Pero como mencion\u00e9 anteriormente, no tengo ganas de reescribir activamente el c\u00f3digo para la soluci\u00f3n de base de datos elegida, as\u00ed que la probaremos de manera algo limitada, sin adaptar la estructura de la base a las especificidades de Cassandra.<\/p>\n<p><b><u>Prometheus<\/u><\/b><\/p>\n<p>Y por pura curiosidad decidimos probar el rendimiento del almacenamiento de Prometheus, simplemente para entender si somos m\u00e1s r\u00e1pidos o m\u00e1s lentos que las soluciones actuales y en qu\u00e9 medida.<\/p>\n<h4>Metodolog\u00eda y resultados de las pruebas<\/h4>\n<p>\nAs\u00ed que probamos 5 bases de datos en las siguientes 6 configuraciones: ClickHouse (1 nodo), ClickHouse (tabla distribuida en 3 nodos), InfluxDB, Mysql 8, Cassandra (3 nodos) y Prometheus. El plan de prueba es el siguiente:<\/p>\n<ol>\n<li>cargamos datos hist\u00f3ricos de una semana (840 millones de valores por d\u00eda; 208 mil m\u00e9tricas);<\/li>\n<li>generamos carga de escritura (consideramos 6 modos de carga, ver m\u00e1s abajo);<\/li>\n<li>simult\u00e1neamente con la escritura, hacemos muestreos peri\u00f3dicos, emulando consultas de un usuario que trabaja con gr\u00e1ficos. Para no complicarlo demasiado, seleccionamos datos de 10 m\u00e9tricas (justo las que est\u00e1n en el gr\u00e1fico de CPU) durante una semana.<\/li>\n<\/ol>\n<p>\nCargamos, emulando el comportamiento del agente de monitorizaci\u00f3n que env\u00eda valores a cada m\u00e9trica cada 15 segundos. Al hacerlo, nos interesa variar:<\/p>\n<ul>\n<li>el n\u00famero total de m\u00e9tricas a las que se env\u00edan datos;<\/li>\n<li>el intervalo de env\u00edo de valores a una m\u00e9trica;<\/li>\n<li>el tama\u00f1o del lote.<\/li>\n<\/ul>\n<p>\nSobre el tama\u00f1o del lote. Dado que casi todas nuestras bases de datos probadas no se recomiendan para cargas de inserciones individuales, necesitaremos un relay que recoja las m\u00e9tricas entrantes y las agrupe en lotes y las escriba en la base mediante inserciones por lotes.<\/p>\n<p>Adem\u00e1s, para entender mejor c\u00f3mo interpretar los datos obtenidos, supongamos que no solo estamos enviando un mont\u00f3n de m\u00e9tricas, sino que las m\u00e9tricas est\u00e1n organizadas en servidores, con 125 m\u00e9tricas por servidor. Aqu\u00ed, el servidor es simplemente una entidad virtual, solo para entender que, por ejemplo, 10,000 m\u00e9tricas corresponden aproximadamente a 80 servidores.<\/p>\n<p>Y as\u00ed, teniendo esto en cuenta, nuestros 6 modos de carga de la base en escritura:<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo probamos varias bases de datos de series temporales\" src=\"\/wp-content\/uploads\/2019\/08\/3ba70050dc7e711cb8f3d14ac1a6707b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHay dos aspectos a considerar. Primero, para Cassandra, estos tama\u00f1os de lotes resultaron ser demasiado grandes; all\u00ed utilizamos valores de 50 o 100. Y en segundo lugar, dado que Prometheus funciona estrictamente en modo pull, es decir, busca y recoge datos de las fuentes de m\u00e9tricas (y aunque el pushgateway, a pesar de su nombre, no cambia la situaci\u00f3n en esencia), las cargas correspondientes se implementaron mediante una combinaci\u00f3n de configuraciones est\u00e1ticas.<\/p>\n<p>Los resultados de las pruebas son los siguientes:<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo probamos varias bases de datos de series temporales\" src=\"\/wp-content\/uploads\/2019\/08\/9df12bee66ad8c5df720ba08472efead.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"C\u00f3mo probamos varias bases de datos de series temporales\" src=\"\/wp-content\/uploads\/2019\/08\/891090bf0461c7e3c48e38eb36f9e217.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"C\u00f3mo probamos varias bases de datos de series temporales\" src=\"\/wp-content\/uploads\/2019\/08\/137f944b3578ab5bad4ebc5fa6f96b79.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Lo que vale la pena se\u00f1alar<\/b>: consultas incre\u00edblemente r\u00e1pidas desde Prometheus, consultas terriblemente lentas desde Cassandra, consultas inaceptablemente lentas desde InfluxDB; en t\u00e9rminos de velocidad de escritura, ClickHouse gan\u00f3 en todos los aspectos, y Prometheus no participa en la competici\u00f3n porque realiza las inserciones dentro de s\u00ed mismo y no medimos nada.<\/p>\n<p><u><b>En resumen<\/b><\/u>: ClickHouse e InfluxDB fueron los que mejor se desempe\u00f1aron, pero se puede construir un cl\u00faster de Influx solo en la versi\u00f3n Enterprise, que tiene un costo, mientras que ClickHouse es gratuito y fue desarrollado en Rusia. Es l\u00f3gico que en EE.UU. se incline la elecci\u00f3n hacia InfluxDB, mientras que aqu\u00ed se favorezca a ClickHouse.<br \/>\n<br \/>Fuente: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/462111\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0417\u0430 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0435 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043b\u0435\u0442 \u0431\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445 \u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u0445 \u0440\u044f\u0434\u043e\u0432 (Time-series databases) \u043f\u0440\u0435\u0432\u0440\u0430\u0442\u0438\u043b\u0438\u0441\u044c \u0438\u0437 \u0434\u0438\u043a\u043e\u0432\u0438\u043d\u043d\u043e\u0439 \u0448\u0442\u0443\u043a\u0438 (\u0443\u0437\u043a\u043e\u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e \u043f\u0440\u0438\u043c\u0435\u043d\u044f\u044e\u0449\u0435\u0439\u0441\u044f \u043b\u0438\u0431\u043e \u0432 \u043e\u0442\u043a\u0440\u044b\u0442\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c\u0430\u0445 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 (\u0438 \u043f\u0440\u0438\u0432\u044f\u0437\u0430\u043d\u043d\u043e\u0439 \u043a \u043a\u043e\u043d\u043a\u0440\u0435\u0442\u043d\u044b\u043c \u0440\u0435\u0448\u0435\u043d\u0438\u044f\u043c), \u043b\u0438\u0431\u043e \u0432 Big Data \u043f\u0440\u043e\u0435\u043a\u0442\u0430\u0445) \u0432 \u00ab\u0442\u043e\u0432\u0430\u0440 \u043d\u0430\u0440\u043e\u0434\u043d\u043e\u0433\u043e \u043f\u043e\u0442\u0440\u0435\u0431\u043b\u0435\u043d\u0438\u044f\u00bb. \u041d\u0430 \u0442\u0435\u0440\u0440\u0438\u0442\u043e\u0440\u0438\u0438 \u0420\u0424 \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u043e\u0435 \u0441\u043f\u0430\u0441\u0438\u0431\u043e \u0437\u0430 \u044d\u0442\u043e \u043d\u0430\u0434\u043e \u0441\u043a\u0430\u0437\u0430\u0442\u044c \u042f\u043d\u0434\u0435\u043a\u0441\u0443 \u0438 ClickHouse\u2019\u0443. \u0414\u043e \u044d\u0442\u043e\u0433\u043e \u043c\u043e\u043c\u0435\u043d\u0442\u0430, \u0435\u0441\u043b\u0438 \u0432\u0430\u043c \u0431\u044b\u043b\u043e \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u043e \u0441\u043e\u0445\u0440\u0430\u043d\u0438\u0442\u044c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27518,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-36737","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=\"\u0417\u0430 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0435 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043b\u0435\u0442 \u0431\u0430\u0437\u044b.\" \/>\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\/kak-my-testirovali-neskolko-baz-dannyh-vremennyh-ryadov\" \/>\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\udd47\u041a\u0430\u043a \u043c\u044b \u0442\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u043b\u0438 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445 \u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u0445 \u0440\u044f\u0434\u043e\u0432 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0417\u0430 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0435 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043b\u0435\u0442 \u0431\u0430\u0437\u044b.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kak-my-testirovali-neskolko-baz-dannyh-vremennyh-ryadov\" \/>\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=\"2019-10-31T19:13:29+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:13:29+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\udd47 C\u00f3mo probamos varias bases de datos de series temporales | ProHoster","description":"En los \u00faltimos a\u00f1os, las bases de datos.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kak-my-testirovali-neskolko-baz-dannyh-vremennyh-ryadov","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\udd47\u041a\u0430\u043a \u043c\u044b \u0442\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u043b\u0438 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445 \u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u0445 \u0440\u044f\u0434\u043e\u0432 | ProHoster","og:description":"\u0417\u0430 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0435 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043b\u0435\u0442 \u0431\u0430\u0437\u044b.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kak-my-testirovali-neskolko-baz-dannyh-vremennyh-ryadov","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":"2019-10-31T19:13:29+00:00","article:modified_time":"2019-10-31T19:13:29+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"36737","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":"2026-01-22 04:38:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:39:24","updated":"2026-01-22 04:38:20","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\/36737","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=36737"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/36737\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/27518"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=36737"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=36737"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=36737"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}