¿Almacenar datos de series temporales, relacionales o no?

Question

¿Almacenar datos de series temporales, relacionales o no?

Estoy creando un sistema que sondea los dispositivos para obtener datos sobre diferentes métricas, como la utilización de la CPU, la utilización del disco, la temperatura, etc. a intervalos (probablemente) de 5 minutos usando SNMP. El objetivo final es proporcionar visualizaciones al usuario del sistema en forma de gráficos de series temporales.

He visto el uso de RRDtool en el pasado, pero lo rechacé ya que almacenar los datos capturados indefinidamente es importante para mi proyecto, y quiero un acceso de mayor nivel y más flexible al datos capturados. Así que mi pregunta es realmente:

Lo que es mejor, una base de datos relacional (como MySQL o PostgreSQL) o una base de datos no relacional o NoSQL (como MongoDB o Redis) con respecto al rendimiento al consultar datos para graficar.

Relacional

Dada una base de datos relacional, usaría una tabla data_instances, en la que se almacenaría cada instancia de datos capturados para cada métrica que se mide para todos los dispositivos, con lo siguiente campos:

Campos: id fk_to_device fk_to_metric metric_value timestamp

Cuando quiero dibujar un gráfico para una métrica en particular en un dispositivo en particular, debo consultar esta tabla singular filtrando los otros dispositivos, y las otras métricas que se analizan para este dispositivo:

SELECT metric_value, timestamp FROM data_instances
    WHERE fk_to_device=1 AND fk_to_metric=2

El número de filas en esta tabla sería:

d * m_d * f * t

Donde d es el número de dispositivos, m_d es el acumulativo número de métricas siendo grabada para todos dispositivos, fes la frecuencia a la que se encuestan los datos y tes la cantidad total de tiempo que el sistema ha estado recopilando datos.

Para un usuario que registra 10 métricas para 3 dispositivos cada 5 minutos durante un año, tendríamos un poco menos de 5 millones de registros.

Índices

Sin índices en fk_to_device y fk_to_metric escanear esta tabla en continua expansión tomaría demasiado tiempo. Así que la indexación de los campos antes mencionados y también timestamp (para crear gráficos con períodos localizados) es un requisito.

No Relacional (NoSQL)

MongoDB tiene el concepto de una colección , a diferencia de las tablas, estas se pueden crear mediante programación sin configuración. Con estos podría particionar el almacenamiento de datos para cada dispositivo, o incluso cada métrica grabada para cada dispositivo.

No tengo experiencia con NoSQL y no sé si proporcionan alguna función de mejora del rendimiento de las consultas, como la indexación, el párrafo anterior propone hacer la mayor parte del trabajo de consulta relacional tradicional en la estructura por la cual los datos se almacenan bajo NoSQL.

Indecisos

¿Una solución relacional con indexación correcta se reduciría a un rastreo dentro del año? ¿O la estructura basada en la recopilación de enfoques NoSQL (que coincide con mi modelo mental de los datos almacenados) proporciona un beneficio notable?

166

database nosql relational-database time-series non-relational-database

Author: user22a6db72d7249, 2011-01-27

Source

10 answers

Encontramos muy interesantes las respuestas anteriores. Tratando de añadir un par de consideraciones más aquí.

1) Envejecimiento de los datos

La administración de series temporales generalmente necesita crear políticas obsoletas. Un escenario típico (por ejemplo, monitoreo de CPU del servidor) requiere almacenar:

1-sec muestras crudas durante un corto período (por ejemplo, durante 24 horas)
5-mín detalle las muestras globales para un período medio (por ejemplo, 1 semana)
1-hora detalle durante ese período (por ejemplo, hasta 1 año)

Aunque los modelos relacionales permiten con seguridad (mi empresa implementó bases de datos centralizadas masivas para algunos clientes grandes con decenas de miles de series de datos) administrarlo adecuadamente, la nueva generación de almacenes de datos agrega funcionalidades interesantes para explorar como:

Purga automatizada de datos (ver el comando EXPIRE de Redis)
Agregaciones multidimensionales (por ejemplo, map-reduce jobs a-la-Splunk)

2) Colección en tiempo real

Aún más importante, algunos almacenes de datos no relacionales están distribuidos inherentemente y permiten una recopilación de datos en tiempo real (o casi en tiempo real) mucho más eficiente que podría ser un problema con RDBMS debido a la creación de hotspots (administrar la indexación mientras se inserta en una sola tabla). Este problema en el espacio RDBMS normalmente se resuelve revirtiendo a procedimientos de importación por lotes (lo manejamos de esta manera en el pasado) mientras que no-sql las tecnologías han tenido éxito en la recopilación y agregación masiva en tiempo real (véase Splunk, por ejemplo, mencionado en respuestas anteriores).

19

Author: Paolo Bozzola,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-03-20 13:18:32

Su tabla tiene datos en una sola tabla. Así que relacional vs no relacional no es la cuestión. Básicamente necesitas leer muchos datos secuenciales. Ahora, si tiene suficiente RAM para almacenar datos de un año, nada como usar Redis / MongoDB, etc.

La mayoría de las bases de datos NoSQL almacenarán sus datos en la misma ubicación en el disco y en forma comprimida para evitar el acceso a varios discos.

NoSQL hace lo mismo que crear el índice en device id y metric id, pero a su manera. Con base de datos incluso si hace esto, el índice y los datos pueden estar en diferentes lugares y habría una gran cantidad de E / s de disco.

Herramientas como Splunk usan backends NoSQL para almacenar datos de series temporales y luego usan map reduce para crear agregados (que podría ser lo que desea más adelante). Entonces, en mi opinión, usar NoSQL es una opción, ya que la gente ya lo ha probado para casos de uso similares. Pero un millón de filas hará que la base de datos se rastree (tal vez no , con un hardware decente y configuraciones adecuadas).

7

Author: Ravindra,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-02-06 13:21:20

Si está buscando paquetes GPL, RRDtool es una buena opción. Es una buena herramienta para almacenar, extraer y graficar datos de series temporales. Su caso de uso se ve exactamente como los datos de series temporales.

3

Author: sunil,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-07-06 06:05:33

Cree un archivo, llámelo 1_2.datos. weired idea? lo que obtienes:

Ahorra hasta un 50% de espacio porque no necesita repetir el valor fk_to_device y fk_to_metric para cada punto de datos.
Ahorra aún más espacio porque no necesita ningún índice.
Guarde pares de (timestamp,metric_value) en el archivo anexando los datos para obtener un pedido por marca de tiempo de forma gratuita. (suponiendo que sus fuentes no envían datos fuera de servicio para un dispositivo)

=> Las consultas por marca de tiempo se ejecutan increíblemente rápido porque puede usar la búsqueda binaria para encontrar el lugar correcto en el archivo desde el que leer.

Si te gusta aún más optimizado empezar a pensar en dividir sus archivos de esa manera;

1_2_enero2014.datos
1_2_febrero 2014.datos
1_2_march2014.datos

O utilice kdb + desde http://kx.com porque hacen todo esto por ti:) orientado a columnas es lo que puede ayudarte.

Hay una nube basada en solución orientada a columnas apareciendo, por lo que es posible que desee echar un vistazo a: http://timeseries.guru

3

Author: hellomichibye,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-09-26 12:59:40

Este es un problema que hemos tenido que resolver en ApiAxle. Nosotros escribimos una entrada de blog sobre cómo lo hicimos usando Redis. No ha estado ahí por mucho tiempo, pero está demostrando ser eficaz.

También he usado RRDtool para otro proyecto que fue excelente.

2

Author: Phil Jackson,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-04-05 11:32:05

Creo que la respuesta para este tipo de preguntas debe girar principalmente sobre la forma en que su Base de datos utiliza el almacenamiento. Algunos servidores de bases de datos usan RAM y Disco, otros solo usan RAM (opcionalmente Disco para persistencia), etc. Las soluciones de base de datos SQL más comunes utilizan memoria + almacenamiento en disco y escriben los datos en un diseño basado en filas (cada raw insertado se escribe en la misma ubicación física). Para las tiendas timeseries, en la mayoría de los casos la carga de trabajo es algo así como: Intervalo relativamente bajo de cantidad de insertos, mientras que las lecturas se basan en columnas (en la mayoría de los casos, desea leer un rango de datos de una columna específica, que representa una métrica)

He encontrado Bases de datos columnares (google, encontrarás MonetDB, InfoBright, parAccel, etc.) están haciendo un trabajo excelente para las series temporales.

En cuanto a su pregunta, que personalmente creo que es algo inválida (como todas las discusiones que usan el término de falla NoSQL-IMO): Puede utilizar un servidor de base de datos que puede hablar SQL por un lado, haciendo su vida muy fácil ya que todo el mundo conoce SQL desde hace muchos años y este lenguaje se ha perfeccionado una y otra vez para consultas de datos; pero todavía utilizar RAM, Caché de CPU y Disco de una manera orientada a columnas, haciendo que su solución mejor ajuste Series de tiempo

2

Author: Shay,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-08-16 19:46:13

5 Millones de filas no son nada para los datos torrenciales de hoy. Espere que los datos estén en la TB o PB en solo unos pocos meses. En este punto, los RDBMS no escalan a la tarea y necesitamos la escalabilidad lineal de las bases de datos NoSQL. El rendimiento se lograría para la partición columnar utilizada para almacenar los datos, agregando más columnas y menos filas tipo de concepto para aumentar el rendimiento. Aproveche el trabajo TSDB abierto realizado sobre HBASE o MapR_DB, etc.

2

Author: Juan Asenjo,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-05-31 20:56:14

Me enfrento a requisitos similares regularmente, y recientemente he comenzado a usar Zabbix para recopilar y almacenar este tipo de datos. Zabbix tiene su propia capacidad de gráficos, pero es bastante fácil extraer los datos de la base de datos de Zabbix y procesarlos como quieras. Si aún no ha comprobado Zabbix, puede que valga la pena su tiempo para hacerlo.

1

Author: monch1962,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-01-27 11:11:58

Debe buscar en la base de datos de series temporales . Fue creado para este propósito.

Una base de datos de series temporales (TSDB) es un sistema de software que está optimizado para manejar datos de series temporales, matrices de números indexados por tiempo (un datetime o un rango de datetime).

Ejemplo popular de base de datos de series temporales InfluxDB

1

Author: Adam,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-07-14 19:14:00

score 142 · Accepted Answer

Definitivamente Relacional. Flexibilidad y expansión ilimitadas.

Dos correcciones, tanto en concepto como en aplicación, seguidas de una elevación.

Corrección

No es "filtrar los datos no necesarios"; es seleccionando solo los datos necesarios. Sí, por supuesto, si tiene un índice para soportar las columnas identificadas en la cláusula WHERE, es muy rápido, y la consulta no depende del tamaño de la tabla (tomando 1,000 filas de un la tabla de 16 mil millones de filas es instantánea).
Su mesa tiene un grave impedimento. Dada su descripción, el PK real es (Dispositivo, Métrica, Fecha y hora). (Por favor, no lo llames Marca de tiempo, eso significa otra cosa, pero eso es un problema menor.) La singularidad de la fila se identifica por:
```
   (Device, Metric, DateTime)
```
- La columna Id no hace nada, es total y completamente redundante.
  - Una columna Id nunca es una Clave (filas duplicadas, que están prohibidos en una base de datos Relacional, deben ser prevenidos por otros medios).
  - La columna Id requiere un índice adicional, que obviamente impide la velocidad de INSERT/DELETE, y se suma al espacio en disco utilizado.
  - Puedes deshacerte de él. Favor.

Elevación

Ahora que ha eliminado el impedimento, puede que no lo haya reconocido, pero su tabla está en Sexta Forma Normal. Muy alta velocidad, con un solo índice en el PK. Para la comprensión, lectura esta respuesta desde el ¿Qué es la Sexta Forma Normal ? hacia adelante.
- (Solo tengo un índice, no tres; en los que no son SQL es posible que necesite tres índices).
- Tengo exactamente la misma tabla (sin la Id "clave", por supuesto). Tengo una columna adicional Server. Apoyo a varios clientes de forma remota.
  
  (Server, Device, Metric, DateTime)
La tabla puede se utilizará para pivotar los datos (es decir. Devices en la parte superior y Metrics en el lateral, o pivotado) usando exactamente el mismo código SQL (sí, cambie las celdas). Utilizo la tabla para erigir una variedad ilimitada de gráficos y tablas para los clientes con respecto al rendimiento de su servidor.
- Modelo de Datos de Estadísticas de Monitoreo.
  (Demasiado grande para inline; algunos navegadores no pueden cargar inline; haga clic en el enlace. También que es la versión demo obsoleta, por razones obvias, no puedo mostrar producto comercial DM.)
- Me permite producir Gráficos Como Este, seis pulsaciones de teclas después de recibir un archivo de estadísticas de monitoreo sin procesar del cliente, utilizando un comando de selección única . Observe la combinación; sistema operativo y servidor en el mismo gráfico; una variedad de pivotes. Por supuesto, no hay límite para el número de matrices de estadísticas, y por lo tanto los gráficos. (Utilizado con el permiso amable del cliente.)
- Lectores que no están familiarizados con el Estándar para Modelar Bases de Datos Relacionales puede encontrar la Notación IDEF1X útil.

Una Cosa Más

Por último, pero no menos importante, SQL es un estándar IEC/ISO/ANSI. El freeware en realidad no es SQL; es fraudulento usar el término SQL si no proporcionan el Estándar. Pueden proporcionar "extras", pero están ausentes de lo básico.