La estructura de mis datos es la siguiente:
date: <timestamp>
filter_a: <integer> -> range [0, 1000]
filter_b: <integer> -> range [0, 1000]
filter_c: <integer> -> range [0, 86400]
filter_d: <integer> -> range [0, 6]
group: <string>
second_group: <integer>
variable_a: <float>
variable_b: <float>
variable_c: <float>
a couple more no very important
Necesito realizar las siguientes consultas:
Primero:
- Filtrar los datos por
date,filter_a,filter_b,filter_cy otros
En segundo lugar, con los datos filtrados:
- contar todos los registros
- obtener un promedio de
variable_a,variable_byvariable_c - obtener la desviación estándar de
variable_a,variable_byvariable_c - obtener cuartiles de
variable_a,variable_byvariable_c - agrupar datos por
grouposecond_groupy agregado (Count, Avg, Std, ..)
El número de usuarios del sistema es de aproximadamente 10 o 15, pero el número de artículos es enorme, en este momento es de 70 millones, pero será de 500 millones en un par de semanas y será de 1000 millones en aproximadamente un año.
El número de consultas es pequeño, no más de 10 usuarios al mismo tiempo, mi problema es cómo manejar esas consultas con esta gran cantidad de datos.
¿Qué he probado hasta ahora?
Comencé con
mongodb, al principio fue rápido pero se hizo lento al calcular cuartiles con 10M +. Mejoró cuando agregué índices, pero no ayudó mucho cuando tuve que consultar todos los datos. Empecé a usar mongodb porque los datos eran muy dinámicos, pero afortunadamente el formato de datos "ya no va a cambiar".Como
filter_ayfilter_bpodría verse como nodos, lo intenténeo4j. Me gustó mucho neo4j, pero mi gráfico tenía MUCHOS bordes, por lo que las consultas no fueron muy rápidas.Finalmente, dado que el formato de datos no va a cambiar y es solo una colección / tabla, por lo que no necesita combinaciones en SQL, verifiqué postgresql. Mis pruebas han sido más rápidas con postgresql, pero tengo miedo de que no pueda escalar correctamente en el futuro.
¿Qué necesito?
- ¿Postgresql es una buena opción para este caso?
- ¿Hay otro tipo de base de datos que pueda usar? ¿Cuál es el mejor para este caso?
- ¿Qué más podría hacer para mejorarlo?
Editar
- Alrededor de 1 millón de elementos se insertan todos los días y "no deberían cambiar" a lo largo del tiempo.
- La velocidad de escritura no es importante.
- El requisito difícil es leer / agregar rápidamente
¡Gracias!
Respuestas:
En lugar de apoyarse en una base de datos relacional para realizar estos cálculos estadísticos en datos de series de tiempo, sugiero que traslade este trabajo matemático y de procesamiento posterior fuera de la base de datos a una aplicación cliente.
Usando un lenguaje de script como Python o Ruby, puede resolver el problema de forma incremental al consultar "fragmentos" de datos durante un período de tiempo de ancho fijo, calcular un resumen estadístico intermedio y luego combinar los resultados en varios fragmentos, a medida que realiza un bucle a lo largo de toda la historia. Algunas medidas estadísticas son difíciles de combinar entre fragmentos, pero algo como Avg () solo necesita sum () y count () por fragmento, O (1) frente a O (tamaño de fragmento), por lo que la fusión de fragmentos puede escalar bien.
fuente
chunksizepodría ayudar. +1Como sus datos no cambian y solo se adjuntan, los almacenaría donde lo desee; Amazon S3, por ejemplo, pero cualquier base de datos de lectura rápida estará bien. Sin índices La base de datos / FS que elija debe tener la opción de leer los datos en cubos: podría tener, por ejemplo, un archivo por día con sus registros de 1M.
Entonces usaría Spark para hacer el filtrado / análisis. Está basado en clúster, puede escalarlo según sus necesidades.
fuente
La respuesta depende de la forma en que va a utilizar los datos después de esto. Si para procesar mejor use Cassandra, si para análisis mejor use Hive.
fuente
real time. ¿Me equivoco?Este tipo de situación es ideal para el almacenamiento de datos, utilizando las técnicas perfeccionadas por Ralph Kimball y compañía, en plataformas como SQL Server (con la que estoy más familiarizado). Fueron diseñados específicamente con este tipo de escenario en mente: enormes cantidades de registros de datos que son relativamente estáticos, para los cuales necesita calcular agregados de este tipo. Nola técnica relacional será una combinación para el almacenamiento de datos implementado adecuadamente en aplicaciones de este tipo, aunque algunas serán mejores que otras si su organización simplemente no puede pagar las licencias de los paquetes de software (como SQL Server Analysis Services) que los implementan. También hay una curva de aprendizaje para implementar lenguajes como MDX que están hechos a medida para este tipo de acceso a datos. Sin embargo, si el almacenamiento de datos es una opción viable para su organización, no pierda el tiempo buscando una solución relacional; Este no es un problema de base de datos relacional. Puedo publicar algunas referencias básicas a Kimball, etc. y enlaces a SSAS y MDX (lo siento, no puedo ayudar con Oracle y otros competidores con los que no estoy familiarizado) si es necesario. Espero que eso ayude.
fuente