Almacenar grandes cantidades de datos de una matriz de sensores

Se me ha encomendado la tarea de implementar una solución (aplicación y base de datos) para almacenar las muestras de datos de una gran matriz de sensores. Actualmente, la matriz consta de unos 20,000 sensores, pero pronto crecerá, hasta 100,000 sensores. Cada sensor envía una muestra de datos cada 10 segundos y cada muestra tiene un tamaño de 28 bytes.

Hacer las sumas conduce a:

• 8640 muestras por sensor por día
• 242kB de datos por sensor por día
• 864 millones de muestras por día

Ahora me he estado preguntando cuál sería la mejor manera de almacenar / recuperar los datos. Me "uní" a este proyecto después de que el software ya se haya especificado, por lo que debe implementarse en una plataforma Windows con SQL Server.

La solución actual en mi cabeza es crear una base de datos con dos tablas para almacenar las muestras de datos. El primero sirve como una especie de índice en el segundo que almacena las muestras clasificadas en un campo binario por día por sensor:

Table 1:

  RecordID - BigInt - Identity
  SensorID - BigInt - Primary Key
  Date - DateTime - Primary Key (yyyy-mm-dd)

Table 2:

  RecordID - BigInt - Primary Key (from an insert into Table 1)
  Data - Binary 

Básicamente escribiré las muestras de todos los sensores en archivos temporales (1 por sensor). Al final de cada día, crearé una entrada en la Tabla 1, usaré el RecordID generado y volcaré el archivo en el campo Datos en la Tabla 2.

De esta manera termino con solo 100,000 entradas en la tabla por día, en lugar de 864 millones de entradas. Los datos deben estar disponibles en la LAN o WAN de alta velocidad, por lo que sería aceptable la recuperación de los datos del sensor durante todo el día.

Aunque todos los datos deben almacenarse, la mayoría de ellos probablemente nunca se leerán. Por lo tanto, la cantidad de lecturas en la (s) tabla (s) no será mucho mayor que la de las escrituras.

Sé que podría implementar algo usando el sistema de archivos simplemente almacenando la ruta a los archivos de datos, pero leí que SQL Server supera a NTFS mientras que sus campos binarios son menos gracias a 256kB. (Existe un área gris entre 256kB y 1MB, mientras que NTFS supera ampliamente a SQL Server para tamaños binarios> 1 MB).

También soy un poco cauteloso de almacenar datos de 100,000 sensores en sus propios archivos sin causar problemas en el sistema de archivos al tener grandes cantidades de archivos en una carpeta o al tener una estructura de árbol compleja con unos pocos archivos en cada carpeta, mientras que no incluso teniendo en cuenta la fragmentación de archivos.

1. ¿Alguien puede ofrecerme algunos consejos prácticos / comentarios sobre lo anterior?

2. ¿Hay obstáculos obvios en los que voy a caer?

3. Los datos de muestra se comprimen bastante bien. Un archivo de 242 kB se comprime a aproximadamente 85kB. Sin embargo, ¿puedo implementar algún tipo de compresión a nivel de base de datos para que los datos de muestra (columna) se compriman automáticamente?

4. ¿Es SQL Server una elección obviamente incorrecta para este proyecto?

5. ¿Es sabio mi diseño de las dos tablas, o podría combinarlo en una sola tabla que seguirá siendo tan "eficaz" como las dos tablas?

Sí, hay una trampa bastante grande con la que se encontrará bastante rápido, y es con el tamaño y el mantenimiento de las tablas. De alguna manera, estás en el camino correcto al decir que quieres poner tus datos en una tabla temporal a diario y luego moverlos a tu tabla permanente, pero pronto tendrás problemas con este esquema.

Por ejemplo, supongamos que desea "eliminar" los datos del mes más antiguo después de dos años. En su diseño, tendría que emitir una declaración DELETE contra su tabla grande, grande. Es probable que esto sea algo lento, dependiendo de la cantidad de índices que tenga. Además, provocará la fragmentación del índice, y la única forma de solucionarlo sería reconstruir o reorganizar los índices en esta tabla muy grande que también causaría problemas de rendimiento. Hay una gran cantidad de otros problemas con un gran diseño de tipo de tabla única también. Por ejemplo, con una tabla grande y única, no puede hacer copias de seguridad basadas en FILEGROUP , lo que significa que si desea tener una copia de seguridad completa de su base de datos, será GRANDE, y tomará MUCHO tiempo completarla.

¿Cual es la solución? Particionamiento de tabla. Lea sobre esto en profundidad, en tantos lugares como pueda. Básicamente, la partición le permite dividir sus datos en "tablas dentro de tablas": cada partición comparte el mismo esquema y se accede a través del objeto de tabla, pero se puede indexar y mantener de manera diferente. Las particiones son básicamente tablas, cortadas por alguna clave útil. En su caso, probablemente será la fecha. Se pueden eliminar como tablas (y tan rápido como), lo que significa que si divide sus tablas de datos grandes por fecha, simplemente puede eliminar las particiones antiguas al instante, sin ningún efecto adverso en los índices en ninguna de las otras particiones. Puede colocar particiones en diferentes grupos de archivos, lo que significa que las particiones más antiguas pueden eliminarse o almacenarse en un almacenamiento de productos más barato si no se usa comúnmente. Por último, pero no menos importante, en SQL 2012 usted 'en sus particiones antiguas de solo lectura , mientras que tiene un esquema de indexación diferente y más orientado a la inserción en la partición activa donde está insertando todos los datos de su sensor.

Espero que esto ayude. Tienes una buena cantidad de investigación que hacer con respecto a la partición y los esquemas de partición, pero espero que ahora sepas la dirección que debes seguir.

PD: Ah, y olvidé tu lista de preguntas con viñetas ... Respuesta 1, 2 y 5. Ver arriba. Respuesta 3: en SQL Server, puede comprimir partición por partición, por lo tanto, comprima sus particiones antiguas de forma agresiva utilizando la compresión PAGE. Pero creo que sus tipos de datos grandes fuera de fila no se comprimirán si hace esto; nuevamente, es posible que desee aliviar este problema normalizando los valores de su sensor. Respuesta 4: Absolutamente no, pero si todo lo que quiere hacer es almacenar datos estáticos por día y nunca buscarlos de otra manera, los archivos planos comprimidos pueden ser una forma mucho más fácil de hacerlo.

PPS: Ah, y otra cosa. No necesita su solución de dos tablas para que todo funcione. Los datos de sensores binarios grandes deben ser del tipo VARBINARIO (MAX) porque sus valores pueden almacenarse " fuera de fila " pero aún así ser una columna en una sola tabla (consulte la documentación de sp_tableoption ). Sin embargo, es posible que desee considerar la normalización de algunos de los datos de su sensor a partir de los datos binarios que tiene en la tabla, porque su base de datos no será buena para mucho más allá de recuperar fragmentos de datos del sensor por tiempo si no lo hace.

Considere una solución Hadoop. 2 Tb / día se suman rápidamente. También considere registrar solo registros delta, es decir, un valor inicial, y luego solo cuando ocurra un cambio.