168 votos

¿Almacenamiento de datos de series de tiempo, relacional o no?

Estoy creando un sistema en el que las encuestas de dispositivos de datos en diferentes medidas tales como la utilización de la CPU, el disco de utilización, temperatura, etc. en (probablemente) intervalos de 5 minutos usando SNMP. El objetivo final es proporcionar la visualización para un usuario de un sistema en la forma de series de tiempo de los gráficos.

He mirado en el uso de RRDTool en el pasado, pero lo rechazaron como el almacenamiento de los datos capturados de forma indefinida es importante para mi proyecto, y quiero más alto nivel y un acceso más flexible a los datos capturados. Así que mi pregunta es realmente:

¿Qué es mejor, una base de datos relacional (MySQL o PostgreSQL) o un no-relacional de base de datos NoSQL (como MongoDB o Redis) con respecto al rendimiento cuando se consultan datos para gráficos.

Relacional

Dada una base de datos relacional, me gustaría utilizar un data_instances tabla, en la que serán almacenados en cada instancia de captura de datos para cada métrica 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 de una métrica en particular en un dispositivo en particular, debo consulta de este singular de la tabla de filtrado de los otros dispositivos, y otras métricas de ser analizados 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 la acumulación número de métricas estar registrado para todos los dispositivos, f es la frecuencia con la que los datos se sondea y t es la cantidad total de tiempo que el sistema ha sido recogida de datos.

Para un usuario de grabación de 10 métricas para 3 dispositivos cada 5 minutos durante un año, tendríamos justo debajo de 5 millones de registros.

Los índices de

Sin índices en fk_to_device y fk_to_metric de escaneo de forma continua expansión de la mesa tomará mucho tiempo. Por lo que la indexación de los campos antes mencionados y también timestamp (para la creación de gráficos localizados períodos) es un requisito.

No Relacionales (NoSQL)

MongoDB tiene el concepto de una colección, a diferencia de estas tablas se puede crear mediante programación sin instalación. Con estos podría partición de almacenamiento de datos para cada dispositivo, o incluso cada registra para cada dispositivo.

Yo no tengo experiencia con NoSQL y no sé si se proporcionan a cualquier consulta para mejorar el rendimiento de características tales como la indexación, sin embargo el párrafo anterior se propone hacer la mayoría de las tradicionales consultas relacionales de trabajo en la estructura por la que se almacenan los datos en virtud de NoSQL.

Los indecisos

Sería una solución relacional con el posicionamiento correcto de reducir a un rastreo en el año? ¿O la colección basada en la estructura de NoSQL enfoques (que coincide con mi modelo mental de los datos almacenados) proporcionan un notable beneficio?

144voto

PerformanceDBA Puntos 9613

Definitivamente Relacional. Ilimitada flexibilidad y la expansión.

Dos correcciones, tanto en su concepción y aplicación, seguida de una elevación.

  1. No es "la filtración de la onu-de los datos necesarios"; es seleccionar sólo los datos necesarios. Sí, por supuesto, si usted tiene un Índice de apoyo a las columnas identificadas en la cláusula where, es muy rápido, y la consulta no dependen del tamaño de la tabla (el acaparamiento de 1.000 filas de 16 mil millones de fila de la tabla es instantáneo).

  2. La tabla tiene un serio obstáculo. Dada su descripción, el real PK es (Dispositivo, Métrica, DateTime). (Por favor no lo llame TimeStamp, que significa otra cosa, sino que es una cuestión menor.) La Id columna es total y completamente redundante. La singularidad de la fila es identificada por (Dispositivo, Métrica, DateTime). La Id columna no hace nada. El Índice adicionales para apoyar la Id columna, obviamente, lento a la tabla de abajo, deshacerse de él.

  3. Ahora que han quitado el impedimento, puede que no lo reconoció, pero la tabla está en la Sexta Forma Normal. Muy alta velocidad, con sólo un Índice en el PK. Para la comprensión, leer ▶esta respuesta◀ de la ¿Qué es el Sexto Forma Normal ? título en adelante.

    • (I tienen un índice único, no tres; en la No-Sql, usted puede necesitar tres índices).

Tengo la misma tabla (sin la Id clave, por supuesto). Tengo una columna adicional con el Servidor. Yo apoyo a múltiples clientes de forma remota. La tabla también realiza Giros. Yo use la tabla para erigir una variedad ilimitada de gráficos y diagramas para los clientes volver a su rendimiento del servidor.

  • ▶Monitor De Estadísticas De Modelo De Datos◀. (Demasiado grande para inline; algunos de los navegadores no puede cargar en línea, haga clic en el enlace)

  • Me permite generar ▶Gráficos Como Este◀, seis pulsaciones después de recibir una prima de monitoreo de estadísticas de archivos desde el cliente, utilizando un solo comando SELECT. Aviso de la mix-and-match; OS y el servidor en el mismo gráfico, una variedad de giros. (Usado con permiso).

  • Los lectores que no están familiarizados con el Estándar para el Modelado de Bases de datos Relacionales puede encontrar la ▶IDEF1X Notación◀ útil.

Último, el SQL es un IEC/ISO/ANSI Estándar. El freeware es realmente No-SQL; es fraudulento, para usar el término de SQL si no proporcionan la Norma. Ellos pueden proporcionar "extras", pero están ausentes los conceptos básicos.

19voto

Paolo Bozzola Puntos 447

Encontrado muy interesantes las respuestas anteriores. Tratando de agregar un par de consideraciones aquí.

1) los Datos de envejecimiento

Series de tiempo de los directivos suelen necesidad de crear políticas de envejecimiento. Un escenario típico (por ejemplo, el servidor de supervisión de la CPU) requiere para almacenar:

  • 1-sec muestras primas por un período corto (por ejemplo, 24 horas)

  • 5-min detalle agregado de muestras por medio periodo (por ejemplo, 1 semana)

  • 1 hora detalles más que (por ejemplo, de hasta 1 año)

Aunque los modelos relacionales hacer lo posible para asegurarse de (mi compañía implementó masiva centralizado de bases de datos para algunos de los grandes clientes con decenas de miles de series de datos) para gestionar de forma adecuada, la nueva raza de almacenes de datos añade interesantes funcionalidades para ser explorado como:

  • automatizado de datos de purga (ver Redis " CADUCA comando)

  • multidimensional agregaciones (por ejemplo, reducir el mapa para que los trabajos de-la-Splunk)

2) la recogida en tiempo Real

Más importante aún es que algunos datos no relacionales de las tiendas son inherentemente distribuidos y permitir de una forma mucho más eficiente en tiempo real (o casi en tiempo real) de recolección de datos que podría ser un problema con el RDBMS porque de la creación de puntos de acceso (gestión de indexación, mientras que la inserción en una sola tabla). Este problema en el RDBMS espacio es normalmente resuelto volver a importar lotes de procedimientos (lo hemos conseguido de esta manera en el pasado), mientras que los no-sql tecnologías han conseguido en la masiva recogida en tiempo real y de agregación (ver Splunk por ejemplo, se mencionó en anteriores respuestas).

7voto

Ravindra Puntos 148

Que tabla tiene los datos en una sola tabla. De modo relacional vs no relacional, no es la cuestión. Básicamente, usted necesita leer una gran cantidad de datos secuenciales. Ahora, si usted tiene suficiente memoria RAM para almacenar un años la pena de datos, a continuación, nada como usar Redis/MongoDB, etc.

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

NoSQL hace lo mismo que crear el índice de la id de dispositivo y la métrica de identificación, pero en su propia manera. Con la base de datos incluso si usted hace esto, el índice y los datos pueden estar en diferentes lugares, y habrá un montón de e / s de disco.

Herramientas como Splunk está utilizando motores NoSQL para almacenar datos de series de tiempo y, a continuación, utilizando reducir el mapa para crear agregados (que podría ser lo que usted quiere posterior). Así que en mi opinión utilizar NoSQL es una opción como personas ya lo han probado para uso similar de los casos. Pero un millón de filas llevar la base de datos para el rastreo (tal vez no , con decente de hardware y configuraciones apropiadas).

3voto

sunil Puntos 485

Si usted está buscando paquetes GPL, RRDTool es una buena para mirar. Es una buena herramienta para el almacenamiento, extracción y graficando datos de series de tiempos. El caso de uso es exactamente igual series cronológicas de datos.

1voto

monch1962 Puntos 1128

I requisitos similares se enfrentan regularmente y recientemente han empezado a utilizar Zabbix para recopilar y almacenar este tipo de datos. Zabbix tiene su propia capacidad de gráficos, pero es bastante fácil de extraer los datos de base de datos de Zabbix y procesarla sin embargo te gusta. Si usted ya no reportan Zabbix hacia fuera, te parecerá digno de su tiempo para hacerlo.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X