¿Qué DB NoSQL usar para datos de la serie de tiempo dispersos?

Question

Estoy planeando un proyecto paralelo donde trataré con los datos de la serie de tiempo y me gustaría probar uno de esos nuevos DB NoSQL brillantes y estoy buscando una recomendación.

Para un conjunto (creciente) de symbols tendré una lista de (time, value) tuplas (aumentando con el tiempo). No se actualizará todo symbols; algunos symbols se pueden actualizar, mientras que otros no, y se pueden agregar symbols completamente nuevos.

La base de datos debe permitir que, por lo tanto:

• agregar símbolos con la lista inicial de un elemento (tupla). P.ej. A: [(2012-04-14 10:23, 50)]
• Actualizar símbolos con una nueva tupla. (Añade esa tupla a la lista de ese símbolo).
• Lea los datos para un símbolo dado. (Lo ideal es que incluso me permita especificar el marco de tiempo para el que se deben devolver los datos)

Las operaciones de creación y actualización deberían ser atómicas. Si es posible leer múltiples símbolos a la vez, eso sería interesante.

El rendimiento no es crítico. Actualizaciones/Creaciones ocurrirá aproximadamente una vez cada pocas horas.

Answer 1

Creo que, literalmente, todas las principales bases de datos NoSQL soportarán ese requisito, especialmente si no tiene realmente un gran volumen de datos (lo que plantea la pregunta, ¿por qué NoSQL?).

Dicho esto, he tenido que diseñar y trabajar recientemente con una base de datos NoSQL para datos de series de tiempo, por lo que puedo aportar algo de información sobre ese diseño, que luego se puede extrapolar para todos los demás.

Nuestra base de datos elegida fue Cassandra, y nuestro diseño fue de la siguiente manera:

• Un único espacio de claves para
• Cada símbolo de todos los símbolos 'era una fila nueva
• Cada entrada de tiempo fue una nueva columna para esa fila relevante
• Cada valor (puede ser más de un único valor) fue la parte del valor de la entrada de tiempo

Esto le permite lograr todo lo que solicitó, sobre todo para leer los datos de un solo símbolo y, si es necesario, usar un rango (llamadas de alcance de columna). Aunque dijiste que el rendimiento no era crítico, fue para nosotros y esto también fue bastante bueno: todos los datos para cualquier símbolo individual están ordenados por definición (clasificación del nombre de la columna) y siempre almacenados en el mismo nodo (no hay comunicación cruzada para consultas simples)) Finalmente, este diseño se traduce bien a otras bases de datos NoSQL que tienen columnas dinámicas.

Además de esto, aquí está una cierta información sobre el uso de MongoDB (y colecciones tapados si es necesario) para una tienda de series de tiempo: MongoDB as a Time Series Database

Por último, he aquí una discusión de SQL vs NoSQL para series de tiempo: https://dba.stackexchange.com/questions/7634/timeseries-sql-or-nosql

puedo añadir a esa discusión lo siguiente:

• curva de aprendizaje para NoSQL será mayor, no obtiene la mayor flexibilidad y funcionalidad de forma gratuita, en términos de costes 'suaves'. ¿Quién apoyará esta base de datos operacionalmente?
• Si espera que esta funcionalidad crezca en el futuro (ya sea como más campos para agregar a cada entrada de tiempo, o una capacidad mucho mayor en términos de número de símbolos o tamaño de serie de símbolos), definitivamente vaya con NoSQL. El beneficio de flexibilidad es enorme, y la escalabilidad que obtiene (con el diseño anterior) tanto en el 'por símbolo' como en el 'número de símbolos' es casi ilimitado (digo casi ilimitado: las columnas máximas por fila son miles de millones, máximo filas por espacio clave es ilimitado, creo).

Answer 2

Eche un vistazo a opentsdb.org una base de datos de series de tiempo opensource que utiliza hbase. Han sido inteligentes sobre cómo almacenan el TS. Está bien documentado aquí: http://opentsdb.net/misc/opentsdb-hbasecon.pdf