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

Estos datos están estructurados. En una base de datos relacional, se almacenaría como: | user | timestamp | latitude | longitude |

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:

1. Ordenar los datos recibidos wrt marcas de tiempo.
2. Iteando en esta lista en orden, determine si la ubicación ha cambiado significativamente (verificando cuánto cambiaron la latitud y la longitud)
3. 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).
4. 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.
5. Itere todo el proceso tanto como sea necesario.
6. 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?

Algunas alternativas para almacenar estos datos:

1. 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.

2. 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.

3. 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.

4. 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 .

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.

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.