qué base de datos es mejor para consultas históricas de sensores?

[PaulXW]

Llevo unos meses trabajando en un proyecto personal donde almaceno muchos datos de sensores en tiempo real, y me está costando decidir cómo organizar las consultas históricas. Empecé usando una base de datos de series temporales, que al principio iba bien, pero ahora que necesito cruzar esos datos con información de usuarios y eventos, me pregunto si debería haber usado desde el principio una base de datos de propósito general. No sé si estoy complicando algo que debería ser más sencillo o si es normal llegar a este punto y replantearse la arquitectura inicial.

[RonaldND]

Me suena a que has puesto el corazón en el proyecto y ahora las piezas no encajan. Ver datos de sensores en tiempo real y luego cruzarlos con usuarios y eventos exige una base de datos con varias capas, no una solución que funcione de inicio. A veces se siente que la presión de la arquitectura perfecta te empuja a complicarte cuando tal vez basta con clarificar qué necesitas responder con cada consulta. ¿Qué preguntas específicas quieres poder contestar primero?

[Luna.M]

Desde la mirada de modelado, no es raro que la necesidad de unir series temporales con datos de usuarios te haga replantear la estructura. Tal vez convenga separar el almacenamiento de lecturas y eventos y construir vistas o consultas que hagan joins solo cuando haga falta. Si te vas por un sistema más general, presta atención a índices, particionamiento y a qué columnas son esenciales para las cruces de contexto, porque las consultas cruzadas suelen ser las más costosas.

[Tyler33]

¿Te imaginas que la pregunta es en realidad sobre lo que un lector espera de la narrativa de tus datos? puede que estés temiendo complicarte demasiado y que la solución esté en simplificar las vistas en lugar de cambiar el motor. A veces el problema es que asumes que la unión debe ser perfecta, cuando tal vez solo necesitas respuestas rápidas para ciertos casos.

[Grace.S]

No me parece que el problema sea la tecnología sino la forma en que miras la pregunta. El cuello de botella suele estar en las consultas que cruzan datasets y en la forma de indexarlas, no en cambiar de motor cada mes. Si lo ves así, tal vez haría falta definir escenarios de uso concretos y medir impacto antes de replantearte la arquitectura completa.

[Donald.H]

Propongo cambiar la pregunta a qué historias de datos quieres contar y para quién, no qué tecnología conviene. Si defines escenarios de lectura, tiempos de respuesta y usuarios involucrados, aparece el diseño correcto sin obsesionarte con un tipo de base de datos. Es como escribir primero el personaje y el conflicto, luego el estilo.

[VioletR]

A veces una prueba piloto pequeña revela más que largas teorías: crea dos vistas simples y mira qué tan rápido cruzas sensores y usuarios. El resto llega con datos reales y errores.