¿Cómo almacenar grandes cantidades de datos estructurados?

La aplicación recopilará continuamente (aproximadamente cada segundo) la ubicación de los usuarios y los almacenará.

Sin embargo, hay demasiados datos. Habrá 60 × 60 × 24 = 86,400 registros por usuario, diariamente. Incluso con 1000 usuarios, esto significa 86,400,000 registros diarios.

Y no son solo 86,400,000 registros diarios. Porque estos registros se procesarán y las versiones procesadas de ellos también se almacenarán. Entonces, multiplique ese número con aproximadamente 2.

Cómo planeo usar los datos

Esencialmente, planeo hacer versiones más gruesas de los datos de ubicación para un consumo más fácil. Es decir:

Ordenar los datos recibidos wrt marcas de tiempo.
Iteando en esta lista en orden, determine si la ubicación ha cambiado significativamente (verificando cuánto cambiaron la latitud y la longitud)
Representa los cambios de ubicación no significativos como una sola entrada en la salida (por lo tanto, la salida es una versión más gruesa de los datos de ubicación).
Itere este proceso en la salida, requiriendo un cambio de latitud y longitud aún mayor para un cambio significativo. Por lo tanto, la salida que se producirá a partir de la salida anterior será aún más gruesa.
Itere todo el proceso tanto como sea necesario.
Agregue una variedad de resoluciones y envíelas a los usuarios. Además, almacene todas las resoluciones de los datos para su posterior consumo.

¿Qué debo usar para almacenar estos datos? ¿Debo usar una base de datos relacional o una solución NoSQL? ¿Qué otras cosas debo considerar al diseñar esta aplicación?

database big-data

— Utku
fuente

2000 registros por segundo como ese probablemente no molestarán a un motor SQL actualizado. Una prueba de capacidad simple sería hacer que un programa de consola escriba algo aleatorio en los archivos que se cargan en masa.

— Caleth

@Caleth ¿Pero es escalable? ¿Qué pasa cuando la base de usuarios crece 100 veces?

— Utku

Mida lo que su hardware puede manejar actualmente. Es probable que el cuello de botella sea la CPU que "procesa" los valores o la velocidad del disco sin procesar. ¿Qué piensa hacer con todos estos datos? Eso debería dar forma a la tecnología que elijas para el almacenamiento

— Caleth

Caleth tiene toda la razón. Millones de registros no perturban un sistema de base de datos moderno. Las tiendas NoSQL son muy buenas para escribir grandes cantidades de datos muy rápido, pero finalmente quieres hacer algo que implique leer cosas nuevamente. La cantidad de lectura que necesitará a menudo determina qué tipo de tienda debe usar.

— Kilian Foth

Para dar una buena respuesta, necesitamos saber cómo planea usar estos datos. Una base de datos podría ser una buena opción si desea consultas ad-hoc, mientras que una solución basada en archivos probablemente sería mejor para el análisis de conjuntos de datos completos. Votación para cerrar.

— kdgregory

Respuestas:

Algunas alternativas para almacenar estos datos:

Cola de mensajes (posiblemente distribuida), como Apache Kafka

Esto se optimizará para escribir y leer un flujo de datos. Es ideal para recopilar flujos de datos en un formato fácil de procesar, pero generalmente no se puede consultar, excepto leyendo el flujo en su totalidad. Por lo tanto, esto sería para fines de archivo o un paso intermedio en el camino hacia una capa de procesamiento.

Bases de datos relacionales)

Simplemente puede escribirlo en la base de datos, y cuando el volumen excede la capacidad de la base de datos para manejar, puede fragmentar la base de datos (= tener múltiples subconjuntos de datos ubicados en diferentes servidores de bases de datos). Beneficio: puede usar una base de datos relacional y no tiene que aprender nada nuevo. Desventaja: todo el código que se ocupe de la base de datos debe ser consciente de qué fragmento de datos vive, las consultas agregadas deben realizarse en el software de la aplicación.

Base de datos distribuida NoSQL, como Cassandra.

Usted escribe sus datos en una base de datos NoSQL distribuida, y automáticamente los fragmentará por usted. Cassandra le permite hacer consultas en todo el clúster, lo que requiere menos código de aplicación para volver a los datos. Beneficio: más adecuado de forma natural para grandes cantidades de datos, inconveniente: requerirá experiencia específica y una comprensión profunda de la mecánica de cómo funcionan estos sistemas para lograr un buen rendimiento y hacer que los datos sean consultables de acuerdo con sus necesidades. NoSQL no es una solución mágica de rendimiento, es un conjunto de compensaciones que deben entenderse para navegar.

Hadoop / archivo

Los datos se agregan a los archivos que la plataforma Hadoop distribuye automáticamente a través de los servidores, se procesan en esos servidores utilizando herramientas como M / R o Apache Spark y finalmente se consultan (como archivo) utilizando un motor Hadoop SQL como Hive o Impala.

¿Cuál elegir?

Las compensaciones entre estas alternativas son complejas y dependen mucho de sus patrones de escritura y lectura, por lo que la única persona que puede decidir sobre estas compensaciones es usted. Si no tiene el tiempo para desarrollar una comprensión profunda de estas alternativas, simplemente use una base de datos relacional y descubra una solución de fragmentación a medida que avanza. Con toda probabilidad, YAGNI .

— Joeri Sebrechts
fuente

He proporcionado más detalles sobre cómo planeo usar los datos. ¿Desea agregar algo dado esta información?

— Utku

Todavía no me queda claro qué quiere decir con "resolución". ¿Desea agregar a nivel geográfico (ciudad, estado, ...) o en algún sistema de coordenadas como un geohash? ¿O le interesa la cantidad de delta porque desea crear notificaciones basadas en umbrales de movimiento? En resumen: ¿para qué sirve todo esto?

— Joeri Sebrechts

Es para rastrear usuarios. Los usuarios se rastrean entre sí, y grafica dónde han estado los usuarios a quienes rastrean en las últimas 5 horas en los dispositivos. Esencialmente, cuanto más fino es el grano, mejor. Sin embargo, los dispositivos móviles tienen una cantidad limitada de memoria, por lo tanto, no puede enviar los datos sin reducir su resolución. Es decir, digamos que el usuario A está rastreando a los usuarios B, C y D. Si simplemente reenvío los datos de ubicación que recibo de B, C y D a A sin realizar ningún procesamiento en el lado del servidor, la memoria del dispositivo del usuario A se llenará muy rápidamente . Por lo tanto, necesito hacer un procesamiento.

— Utku

Si tuviera que construir lo que está describiendo, lo construiría como una serie de registros de kafka conectados a través de la transmisión de chispas, donde las posiciones se integran a través de las ventanas en la corriente de chispas, y el registro de kafka de salida final se proporciona como extracción y extracción. empujar la API web a los clientes. Sin embargo ... esa es una tecnología muy particular, y dependiendo de sus antecedentes y el tiempo disponible, esas opciones pueden ser incorrectas para usted.

— Joeri Sebrechts

Gracias. Lo tendré en cuenta, pero siguiendo el principio de YAGNI, estoy planeando usar una base de datos relacional por ahora. Cuando surja la necesidad, cambiaré a algo que se adapte mejor a la aplicación. Si lo desea, edite cualquier información en su respuesta.

— Utku

Examina tus requisitos un poco más profundo. Hay una manera de crear la ilusión de rastrear la posición cada segundo.

Si tiene una aplicación que conoce su ubicación GPS actual y la escribe en una base de datos, ¿por qué seguiría escribiendo la ubicación si no cambia? Incluso si necesita los datos, si el usuario ha estado dormido durante 7 horas, puede rellenar mediante programación los espacios de tiempo faltantes con una ubicación duplicada para hacer sus cálculos o mapeos o cualquier otra cosa que necesite hacer.

Si realiza un seguimiento de la ubicación cada segundo, ¿tiene que almacenar estos datos para siempre? Puede archivar los registros en otra base de datos para evitar que la tabla actual sea demasiado grande. O incluso podría mantener los registros donde haya un cambio de posición. Esto es común en los almacenes de datos.

— JeffO
fuente

Sus datos son un conjunto de series de tiempo. Ha proporcionado conjuntos de números (dos por usuario) que evolucionan con el tiempo. Por lo general, NO está buscando ningún tipo de almacenamiento relacional, sino un almacenamiento RRD. Este almacenamiento se centra principalmente en reducir el trabajo de E / S de numerosas escrituras pequeñas al almacenarlo en búfer.

El almacenamiento relacional es una herejía para este volumen de series de tiempo. Sin embargo, tenga en cuenta que el desarrollo de RRD no está tan bien soportado en términos de explotaciones programables como el SQL. Probablemente esté buscando un trabajo de integración serio, pero es difícil de evitar dados sus requisitos.

— Arthur Havlicek
fuente