2009-06-04 10 views
9

Estoy tratando de identificar posibles métodos para almacenar 100 canales de datos de coma flotante de 25 Hz. Esto dará como resultado 78,840,000,000 de puntos de datos por año.Cómo almacenar muchos años de series de tiempo de 100 x 25 Hz - Servidor Sql o base de datos de series de tiempo

Idealmente, todos estos datos estarían disponibles de manera eficiente para sitios web y herramientas como los servicios de informes del servidor Sql. Somos conscientes de que las bases de datos relacionales son deficientes en el manejo de series temporales de esta escala, pero aún no han identificado una base de datos específica de series de tiempo convincente.

Los problemas clave son la compresión para un almacenamiento eficiente que también ofrece consultas sencillas y eficientes, informes y extracción de datos.

  • ¿Cómo manejarías estos datos?

  • ¿Hay características o diseños de tablas en el servidor Sql que puedan manejar tal cantidad de datos de series de tiempo?

  • Si no es así, ¿hay alguna extensión de terceros para que el servidor Sql maneje eficientemente series temporales gigantescas?

  • Si no, ¿existen bases de datos de series de tiempo que se especializan en el manejo de dichos datos pero que proporcionan acceso natural a través de los servicios de informes Sql, .Net y Sql?

gracias!

+0

¿Qué tan grandes son los puntos de datos? – cgp

+0

¿Cuál es el tipo de datos de las muestras? ¿La velocidad de muestreo/alimentación es fija o variable? ¿Necesita almacenar el tiempo de muestra o puede inferirse? ¿Y qué tipo de datos se están probando? – RBarryYoung

+0

Supongamos un punto flotante de 32 bits. Podría haber alguna optimización, pero sería perfecto si no tuviéramos que manejar ese dolor de cabeza. – Duncan

Respuesta

1

Particiono la tabla por fecha, por ejemplo, para dividir los datos en pequeños bits de 216,000,000 filas cada uno.

Siempre que no necesite una estadística de todo el año, esto es fácil de usar por los índices.

Digamos, la consulta como "me da un promedio para la hora dada" será una cuestión de segundos.

+0

Gracias por la respuesta. ¿Utiliza la partición del servidor sql o solo varias tablas? Si hay varias tablas, ¿hay algún patrón de diseño para manejar fácilmente las consultas en las tablas? – Duncan

+0

@Duncan: la parición SQL Server sería la mejor, pero no sé cuántas particiones permitirá.Con varias tablas, puede ejecutar un programador para recrear las vistas como SELECT * FROM table_20090609 UNION ALL SELECT * FROM table_20090608 etc. No olvide incluir una columna de particionamiento en las tablas. – Quassnoi

1

Supongo que necesita un acceso aleatorio a la serie de datos. La idea que ya he utilizado para la tabla de datos de lluvia es subdividir todo el conjunto de datos en una parte más pequeña, para crear una entrada por cada pocos minutos o incluso un minuto. A continuación, puede mostrar esta matriz, todavía grande, desde el archivo db y acceder directamente a la parte necesaria; puede encontrar una correlación directa entre el desplazamiento temporal y el desplazamiento del byte.

+0

Gracias por la respuesta. ¿Usando un blob para la gran matriz? ¿Hay algún enfoque de diseño para hacer que un blob sea fácilmente consultable, p. ¿puntos de vista? – Duncan

1

El conjunto de características que está describiendo es para un cubo de análisis. Echa un vistazo a los servicios de análisis de Microsoft si estás en esa parte del mundo de la tecnología:

http://msdn.microsoft.com/en-us/library/ms175609(SQL.90).aspx

En cuanto al modelo de que describes, es necesario implementar un modelo Kimball (el estándar de datos modelo de almacenamiento) con una dimensión de tiempo. Me encontré con este problema al almacenar archivos de registro multimedia hace un tiempo.

Buena suerte.

+0

Gracias por la respuesta. Es difícil saber por dónde empezar con el almacenamiento de datos. He buscado y leído en Google su enlace, pero me beneficiaría de algo así como un proyecto de muestra que aborda un problema similar. ¿Conoces algo como esto? – Duncan

+0

Tiene razón en que el almacenamiento de datos es difícil de comenzar. El mejor proceso que puedo recomendar es (y tenga en cuenta que estoy hablando de Microsoft Visual Studio y Sql Server 2005/2008 aquí) para descargar el almacén de muestra de AdventureWorks db: http://www.microsoft.com/ downloads/details.aspx? FamilyId = E719ECF7-9F46-4312-AF89-6AD8702E4E6E & displaylang = en y luego echa un vistazo a algunos de los laboratorios de Sql: http://www.microsoft.com/sqlserver/2008 /en/us/virtual-labs.aspx Por último, recomiendo el libro de Kimball para empezar: http://www.ralphkimball.com/html/booksDWT2.html Buena suerte! –

0

Tienes

A. 365 x 24 x 100 = 876.000 por hora señales (todos los canales) por año

B.cada señal que comprende 3600 * 25 = 90.000 puntos de datos

¿Qué tal si almacena los datos como una fila por cada señal, con columnas de resumen/Estadísticas de consulta para los casos de uso actualmente soportadas, y una blob de la señal comprimida para los futuros?

+0

Gracias por la respuesta. Es posible que no entiendo completamente la sugerencia. ¿La sugerencia para cada fila es similar (signalId, timeperiod, float ave, float min, float max, blob raw)? ¿Hay algún ejemplo de hacer que los datos de un bloque sean fácilmente consultables, p. ¿puntos de vista? – Duncan

+0

Algo parecido, pero no estoy seguro de hacer que los datos de blob sean consultables ... Mi idea era limitar las consultas a columnas de estadísticas adicionales según sea necesario. – bubaker

1

Puede consultar Infobright Community o Enterprise Edition, creo. Es un almacenamiento orientado a columna diseñado para fines analíticos y datos grandes (instalaciones existentes de hasta 30 TB ahora como dicen) y una buena tasa de compresión.

El cargador de datos también es bastante rápido y existen conectores para herramientas ETL (Talend, hervidor, etc.).

Edición de comunidad disponible gratis bajo los términos de GNU GPL, pero permite agregar datos solo a través del cargador nativo. Enterprise Edition admite agregar/actualizar en una sola fila a través de DML.

Otra ventaja que puede usar con todas las herramientas que admiten conexiones MySQL.

La orientación de columna le permite, por ejemplo, agregar columnas para el componente de fecha en cada nivel de agregación necesario (uso fecha, números semana, meses y qtr.) Para un mejor rendimiento, pero también es bueno sin él.

Lo uso para cantidades relativamente pequeñas (aún) de datos de transacciones comerciales para fines analíticos con R como herramienta de análisis de datos a través de la interfaz mysql y scripts python (numpy) como algún tipo de ETL.

Contras: falta de soporte oficial para utf-8, agregación por valores de función (seleccione mes (fecha de ...)) aún no implementado (plan: julio de 2009, AFAIK), pero utilizo ETL para esto.

Enlace: http://www.infobright.org/Download/ICE/

+0

Gracias - Voy a echar un vistazo. – Duncan

+0

por favor no dude en compartir su experiencia después de explorar ICE :) Estoy trabajando en la arquitectura de nuestra pequeña aplicación de análisis/informes con R, Infobright y Django como visor de informes e interesado en nuevas ideas sobre almacenamiento/representación de grandes datos :) – zzr

0

Ha considerado HBASE o abre TSDB. También puede echarle un vistazo a Cassandra

0

Si solo se trata de datos de coma flotante, los TSDB le ofrecerán un mejor rendimiento. Los algoritmos de compresión de Timeseries son diferentes, por lo tanto, obtienes mejores tasas de almacenamiento y consultas.

Cuestiones relacionadas