¿Cuál es la mejor manera de almacenar datos de tendencia?

Question

Actualmente estoy creando una aplicación en la que estoy importando datos estadísticos para (actualmente) alrededor de 15,000 productos. En la actualidad, si tuviera que mantener una tabla de base de datos para cada día de estadísticas de una fuente, se incrementarían en 15,000 filas de datos (digamos 5-10 campos por fila principalmente flotantes, int) por día. Obviamente igualando a más de 5 millones de registros por año en una sola tabla.

Eso no me preocupa tanto como la idea de traer datos de otras fuentes (y así aumentar el tamaño de la base de datos en 5 millones de registros para cada fuente nueva).

Ahora los datos son estadísticos/de tendencias basados ​​en datos, y tendrán básicamente 1 escritura por día por registro, y muchas lecturas. A los efectos de informar y graficar sobre la marcha, sin embargo, necesito un acceso rápido a subconjuntos de datos basados ​​en reglas (rangos de fechas, rangos de valores, etc.).

¿Cuál es mi pregunta? ¿Es esta la mejor manera de almacenar los datos (tablas InnoDb de MySQL) o existe una forma mejor de almacenar y manejar datos estadísticos/de tendencias?

Otras opciones que he dado vueltas en este punto: 1. Múltiples bases de datos (una por producto), con tablas separadas para cada fuente de datos dentro. (es decir, base de datos: ProductA, Table (s): Source_A, Source_B, Source_C) 2. Una base de datos, varias tablas (una para cada producto/fuente de datos) (es decir, base de datos: Products, Table (s): ProductA_SourceA, ProductA_SourceB , etc.) 3. Todos factual o información específica del producto en la base de datos y todos los datos statistical en csv, xml, json, (archivos planos) en directorios separados.

Hasta el momento, ninguna de estas opciones es muy manejable, cada una tiene sus pros y sus contras. Necesito una solución razonable antes de pasar a la etapa alfa del desarrollo.

Answer 1

Podría intentar hacer uso de una base de datos basada en columnas. Este tipo de bases de datos son mucho mejores en las consultas analíticas del tipo que está describiendo. Hay varias opciones:

http://en.wikipedia.org/wiki/Column-oriented_DBMS

Hemos tenido buenas experiencias con InfiniDB:

http://infinidb.org/

y Infobright se ve bien así:

http://www.infobright.com/

Tanto InfiniDB e Infobright tienen ediciones gratuitas de comunidades de código abierto, así que Recomiendo usar estos para obtener algunos puntos de referencia sobre los tipos de beneficios de rendimiento que podría obtener.

Es posible que también desee ver particionar sus datos para mejorar el rendimiento.

Answer 2

Depende un poco de cómo se vean sus datos, y del tipo de agregaciones/tendencias que desea ejecutar. La mayoría de las bases de datos relacionales funcionan bien para este tipo de datos cronológicos. Incluso con miles de millones de registros, la indexación y la partición adecuadas pueden hacer que el trabajo rápido de encontrar los registros que necesita. DB's como Oracle, MySQL, SQL-Server caen dentro de esta categoría.

Digamos que los productos con los que trabaja son acciones, y por cada acción obtiene un nuevo precio todos los días (un caso muy realista). Los nuevos intercambios, acciones y frecuencias comerciales aumentarán estos datos exponencialmente bastante rápido.Sin embargo, podría dividir los datos por intercambio. O región

Varias herramientas de Business Intelligence también son capaces de ayudar, lo que efectivamente equivale a la preagregación de datos antes de la recuperación. Esto es básicamente una base de datos orientada a columnas como se sugirió. (Los almacenes de datos y las estructuras OLAP pueden ayudar a dar masajes y agregar conjuntos de datos con anticipación).

Similar a la idea del almacenamiento de datos, si solo se trata de que las agregaciones tarden demasiado, puede trabajar las agregaciones de la noche a la mañana en una estructura más rápida de consultar. En mi ejemplo anterior, es posible que solo necesite recuperar grandes cantidades de datos con poca frecuencia, pero con mayor frecuencia alguna agregación, como una semana de alta. Puede almacenar la gran cantidad de datos sin procesar en un formato y luego, cada noche, un trabajo solo funciona en una tabla que en lugar de miles de puntos de datos por stock, ahora tiene 3 o 4.

Si las tendencias que está rastreando realmente están por todos lados, o algoritmos complejos, una solución BI completa puede ser algo que investigar para que pueda usar algoritmos analíticos y de minería de datos preconstruidos.

Si los datos no son muy estructurados, puede tener mejor suerte con una base de datos NoSQL como Hadoop o Mongo, aunque es cierto que mi conocimiento de las bases de datos está más centrado en los formatos relacionales.