buena (noSQL?) Base de datos para mediciones físicas

Question

Estamos construyendo un sistema de medición que eventualmente consistirá en miles de estaciones de medición. Cada estación ahorrará alrededor de 500 millones de mediciones que consisten en 30 valores escalares a lo largo de su vida útil. Estos serán valores flotantes. Ahora nos preguntamos cómo guardar estos datos en cada estación, teniendo en cuenta que estaremos construyendo una aplicación web en cada estación de tal manera que

• queremos visualizar los datos en varias escalas de tiempo (por ejemplo, mediciones de una semana, mes, año)
• que necesitamos para construir las medias móviles a través de los datos (por ejemplo, la media más de un mes para mostrar en un gráfico año)
• la base de datos es necesario que haya (cortes de energía resistentes a choques)
• sólo estamos haciendo escribe y lee, no hay actualizaciones o elimina en los datos

Además, nos gustaría tener un servidor más que pueda mostrar los datos de, digamos, 1000 estaciones de medición. Eso sería ~ 50 TB de datos en 500 mil millones de mediciones. Para transmitir los datos desde la estación de medición al servidor, pensé que algún tipo de replicación a nivel de base de datos sería una forma limpia y eficiente.

Ahora me pregunto si una solución noSQL podría ser mejor que mySQL para estos fines. Especialmente couchDB, Cassandra y tal vez tiendas clave-valor como Redis me parecen atractivas. ¿Cuál de estos se adecuaría mejor al modelo de datos "series de tiempo de medición" en su opinión? ¿Qué pasa con otras ventajas como la seguridad contra fallas y la replicación de la estación de medición al servidor principal?

Answer 1

Creo que CouchDB es una excelente base de datos, pero su capacidad para manejar grandes cantidades de datos es cuestionable. El enfoque principal de CouchDB está en la simplicidad del desarrollo y la replicación sin conexión, no necesariamente en el rendimiento o la escalabilidad. CouchDB en sí mismo no es compatible con la partición, por lo que estará limitado por el tamaño máximo de nodo a menos que use BigCouch o invente su propio esquema de partición.

No foolin, Redis es una base de datos en memoria. Es extremadamente rápido y eficiente para obtener datos dentro y fuera de la RAM. Tiene la capacidad de usar el disco para el almacenamiento, pero no es muy bueno en eso. Es ideal para cantidades limitadas de datos que cambian con frecuencia. Redis tiene replicación, pero no tiene ningún soporte integrado para particionar, así que de nuevo, estará solo aquí.

También mencionó a Cassandra, que creo que está más orientada a su caso de uso. Cassandra es ideal para bases de datos que crecen indefinidamente, esencialmente es su caso de uso original. El reparto y la disponibilidad están preparados para que no tenga que preocuparse mucho por ello. El modelo de datos también es un poco más flexible que el almacén de clave/valor promedio, agrega una segunda dimensión de columnas y prácticamente puede acomodar millones de columnas por fila. Esto permite que los datos de series de tiempo se "incluyan en el código" en filas que cubren intervalos de tiempo, por ejemplo. La distribución de datos a través del clúster (partición) se realiza en el nivel de fila, por lo que solo se necesita un nodo para realizar operaciones dentro de una fila.

Hadoop se conecta directamente a Cassandra, con "controladores nativos" para MapReduce, Pig y Hive, por lo que podría ser utilizado para agregar los datos recopilados y materializar los promedios de ejecución. La mejor práctica es dar forma a los datos en torno a las consultas, por lo que probablemente desee almacenar varias copias de los datos en forma "desnormalizada", una para cada tipo de consulta.

Salida este post en hacer series de tiempo en Cassandra:

http://rubyscale.com/2011/basic-time-series-with-cassandra/

Answer 2

Para los datos altamente estructurados de esta naturaleza (series de tiempo de los vectores float) que tienden a alejarse de las bases de datos todos juntos. La mayoría de las características de una base de datos no son muy interesantes; básicamente no te interesan cosas como la atomicidad o la semántica transaccional. La única característica que es deseable es la resistencia a fallar. Sin embargo, esta característica es fácil de implementar cuando no necesita deshacer una escritura (sin actualizaciones/eliminaciones), simplemente agregando a un archivo. la recuperación de fallas es simple; abra un nuevo archivo con un número de serie incrementado en el nombre del archivo.

Un formato lógico para esto es csv simple. después de tomar cada medición, llame al flush() en el file subyacente. Obtener los datos replicados en el servidor central es un trabajo resuelto eficientemente por rsync(1). Luego puede importar los datos en la herramienta de análisis que elija.

Answer 3

Persionalmente me alegraría de los archivos "csv" y "plaintext". Estos son convenientes cuando tiene poco volumen y quiere omitir las herramientas para mirar rápidamente los datos o realizar pequeñas modificaciones en los datos.

Cuando hablamos de "50 TB" de datos, eso es bastante. Si un simple truco lo reduce en un factor de dos, se amortizará en costos de almacenamiento y cargos de ancho de banda.

Si las mediciones se toman con regularidad, eso significaría que en lugar de guardar la marca de tiempo con cada medida, almacenará la hora e intervalo de inicio y simplemente almacenará las mediciones.

Iré por un formato de archivo que tenga un encabezado pequeño y luego solo un montón de medidas de coma flotante. Para evitar que los archivos sean realmente grandes, decida el tamaño máximo de archivo. Si inicializa el archivo escribiéndolo por completo antes de comenzar a usar el archivo, se asignará por completo en el disco cuando empiece a usarlo. Ahora puede mmap el archivo y alterar los datos. Si la energía se reduce cuando está cambiando los datos, simplemente lo hace en el disco o no lo hace.