database - timescaledb - ¿Almacena datos de series temporales, relacionales o no?

time series database (10)

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

He analizado el uso de RRDTool en el pasado, pero lo he rechazado, ya que el almacenamiento indefinido de los datos capturados es importante para mi proyecto, y quiero un acceso de mayor nivel y más flexible a los datos capturados. Entonces 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 cuando se consultan datos para graficar.

Relacional

Dada una base de datos relacional, usaría una tabla data_instances , en la cual se almacenaría cada instancia de datos capturados para cada métrica que se mide para todos los dispositivos, con los siguientes 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 que filtra 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 la cantidad de dispositivos , m_d es la cantidad acumulativa de métricas que se registran para todos los dispositivos, f es la frecuencia a la que se sondean los datos t es 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 menos de 5 millones de registros.

Índices

Sin índices en fk_to_device y fk_to_metric escaneando esta tabla en continua expansión tomaría demasiado tiempo. Por lo tanto, es un requisito indexar los campos antes mencionados y también la timestamp (para crear gráficos con períodos localizados).

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 puedo dividir el almacenamiento de datos para cada dispositivo, o incluso cada métrica registrada para cada dispositivo.

No tengo experiencia con NoSQL y no sé si proporcionan funciones de mejora del rendimiento de las consultas, como la indexación, sin embargo, el párrafo anterior propone hacer la mayor parte del trabajo tradicional de consultas relacionales en la estructura mediante la cual los datos se almacenan en NoSQL.

Indeciso

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

5 Millones de filas no son nada para los datos torrenciales de hoy. Espere que los datos estén en TB o PB en solo unos meses. En este punto, RDBMS no se adapta a la tarea y necesitamos la escalabilidad lineal de las bases de datos NoSql. Se lograría un rendimiento 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 Open TSDB realizado sobre HBASE o MapR_DB, etc.

Cree un archivo, asígnele el nombre 1_2.data. idea de weired? lo que obtienes:

Ahorre hasta 50% de espacio porque no necesita repetir el valor de fk_to_device y fk_to_metric para cada punto de datos.
Ahorras aún más espacio porque no necesitas ningún índice.
Guarde los pares de (marca de tiempo, valor_métrico) en el archivo agregando los datos para que pueda obtener un pedido por marca de tiempo de forma gratuita. (suponiendo que sus fuentes no envían datos desordenados 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 para leer.

si te gusta aún más optimizado, comienza a pensar en dividir tus archivos de esa manera;

1_2_january2014.data
1_2_february2014.data
1_2_march2014.data

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

Aparece una solución orientada a la columna basada en la nube, por lo que es posible que desee echarle un vistazo a: http://timeseries.guru

Creo que la respuesta para este tipo de preguntas debería girar principalmente sobre la forma en que su base de datos utiliza el almacenamiento. Algunos servidores de base de datos utilizan RAM y disco, algunos usan RAM solamente (opcionalmente Disk for persistency), etc. Las soluciones de base de datos SQL más comunes usan memoria + disco de almacenamiento y escriben los datos en un diseño basado en Row (cada raw insertado está escrito en el mismo localizacion fisica). Para las tiendas de series temporales, en la mayoría de los casos, la carga de trabajo es similar a: Intervalo relativamente bajo de inserciones masivas, 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 represente una métrica)

He encontrado Bases de Datos Columnar (google it, encontrarás MonetDB, InfoBright, parAccel, etc.) están haciendo un excelente trabajo para las series de tiempo.

En cuanto a su pregunta, que personalmente creo que es algo inválida (como todas las discusiones usando el término de falla NoSQL - IMO): Puede usar un servidor de base de datos que puede hablar SQL por un lado, haciendo su vida muy fácil ya que todos saben SQL para muchos años y este lenguaje ha sido perfeccionado una y otra vez para consultas de datos; pero aún así utiliza la memoria RAM, la memoria caché de la CPU y el disco de forma orientada a columnas, lo que hace que tu solución sea la mejor serie de tiempo

Deberías mirar en la base de datos de series temporales . Fue creado para este propósito.

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

Ejemplo popular de base de datos de series de tiempo InfluxDB

Definitivamente relacional. Flexibilidad y expansión ilimitadas.

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

No es "filtrar los datos innecesarios"; está seleccionando solo los datos necesarios . Sí, por supuesto, si tiene un índice para sustentar las columnas identificadas en la cláusula WHERE, es muy rápido, y la consulta no depende del tamaño de la tabla (capturar 1,000 filas de una tabla de 16,000 millones de filas es instantáneo) .
Tu mesa tiene un impedimento serio. Dada su descripción, la PK real es (Dispositivo, Métrica, Fecha y hora). (Por favor, no lo llame TimeStamp, eso significa algo más, pero ese es un problema menor.) La columna Id es total y completamente innecesaria. La singularidad de la fila se identifica por:
`(Device, Metric, DateTime)`
La columna Id no hace nada, es superfluo. El índice adicional para admitir la columna Id obviamente impide la velocidad de INSERT y agrega espacio en el disco utilizado. Por lo tanto, puede deshacerse de la columna Id .
Ahora que ha eliminado el impedimento, es posible que no lo haya reconocido, pero su mesa está en la Sexta Forma Normal. Muy alta velocidad, con solo un índice en PK. Para su comprensión, lea esta respuesta del ¿Qué es la Sexta Forma Normal? yendo hacia adelante
- (Tengo un solo índice, no tres, en los no SQL puede necesitar tres índices).
Tengo exactamente la misma tabla (sin la clave Id , por supuesto). Tengo un Server columna adicional. Apoyo a múltiples clientes de forma remota.
`(Server, Device, Metric, DateTime)`
La tabla se puede usar para pivotar los datos (es decir, Devices en la parte superior y Metrics en el lateral, o pivotar) usando exactamente el mismo código SQL (sí, cambie las celdas). Utilizo la tabla para crear una variedad ilimitada de gráficos y gráficos para que los clientes puedan conocer el rendimiento de su servidor.
- Monitorear el modelo de datos estadísticos .
  (Demasiado grande para en línea, algunos navegadores no pueden cargarse en línea, haga clic en el enlace. También esa es la versión demo obsoleta, por razones obvias, no puedo mostrarle el 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, usando un único comando SELECCIONAR . Observe el mix-and-match; Sistema operativo y servidor en el mismo gráfico; una variedad de Pivots. Por supuesto, no hay límite en la cantidad de matrices de estadísticas, y por lo tanto, en los gráficos. (Se usa con el amable permiso del cliente).
- Los lectores que no están familiarizados con el Estándar para Modelar Bases de Datos Relacionales pueden encontrar útil la Notación IDEF1X .

Por último, pero no menos importante, SQL es un estándar IEC / ISO / ANSI. El freeware es en realidad no 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.

Encontré muy interesantes las respuestas anteriores. Tratando de agregar un par de consideraciones más aquí.

1) envejecimiento de los datos

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

Muestras crudas de 1 segundo durante un período corto (p. Ej., Durante 24 horas)
Muestras agregadas de detalles de 5 minutos durante un período medio (p. Ej., 1 semana)
Detalle de 1 hora sobre eso (por ejemplo, hasta 1 año)

Aunque los modelos relacionales permiten, con toda 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 clase de tiendas de datos agrega funcionalidades interesantes para explorar como:

purga automatizada de datos (ver el comando EXPIRE de Redis)
agregaciones multidimensionales (por ejemplo, trabajos de map-reducir a-la-Splunk)

2) colección en tiempo real

Aún más importante, algunos almacenes de datos no relacionales se distribuyen intrínsecamente y permiten una recopilación de datos mucho más eficiente en tiempo real (o casi en tiempo real) que podría ser un problema con RDBMS debido a la creación de puntos de acceso (administración de índices mientras se inserta una sola mesa). Este problema en el espacio RDBMS normalmente se resuelve volviendo a los procedimientos de importación por lotes (lo logramos de esta manera en el pasado) mientras que las tecnologías sin sql han tenido éxito en la recopilación y agregación masiva en tiempo real (vea Splunk por ejemplo, mencionado en respuestas anteriores) .

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

También utilicé RRDTool para otro proyecto que fue excelente.

Me enfrento a requisitos similares regularmente, y recientemente comencé 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 prefiera. Si aún no ha revisado Zabbix, puede encontrar que vale la pena su tiempo para hacerlo.

Si está buscando paquetes GPL, RRDTool es una buena RRDTool para mirar. Es una buena herramienta para almacenar, extraer y graficar datos de series de tiempo. Su caso de uso se ve exactamente como los datos de series de tiempo.

Tu tabla tiene datos en una sola tabla. Entonces relacional vs no relacional no es la pregunta. Básicamente, necesitas leer muchos datos secuenciales. Ahora, si tienes suficiente memoria RAM para almacenar datos que valen años, entonces no hay nada como usar Redis / MongoDB, etc.

En su mayoría, las bases de datos de NoSQL almacenarán sus datos en la misma ubicación en el disco y en forma comprimida para evitar el acceso a múltiples discos.

NoSQL hace lo mismo que crear el índice en la identificación del dispositivo y la métrica, pero a su manera. Con la base de datos incluso si hace esto, el índice y los datos pueden estar en diferentes lugares y habría una gran cantidad de IO de disco.

Herramientas como Splunk están usando backends NoSQL para almacenar datos de series de tiempo y luego usar map reduce para crear agregados (que podría ser lo que quieras más adelante). Entonces, en mi opinión, usar NoSQL es una opción, ya que las personas ya lo han probado para casos de uso similares. Pero un millón de filas llevarán la base de datos al rastreo (tal vez no, con hardware decente y configuraciones adecuadas).