O aplicativo coletará continuamente (aproximadamente a cada segundo) a localização dos usuários e os armazenará.

Esses dados estão estruturados. Em um banco de dados relacional, ele seria armazenado como: | user | timestamp | latitude | longitude |

No entanto, há muitos dados. Haverá 60 × 60 × 24 = 86.400 registros por usuário, diariamente. Mesmo com 1.000 usuários, isso significa 86.400.000 registros diários.

E não são apenas 86.400.000 registros diários. Como esses registros serão processados ​​e as versões processadas deles também serão armazenadas. Portanto, multiplique esse número por aproximadamente 2.

Como pretendo usar os dados

Basicamente, pretendo criar versões mais granulares dos dados de localização para facilitar o consumo. Isso é:

1. Classifique os registros de data e hora de gravação de dados recebidos.
2. Examinando esta lista em ordem, determine se o local mudou significativamente (verificando quanto a latitude e a longitude mudaram)
3. Represente as alterações de localização não significativas como uma única entrada na saída (portanto, a saída é uma versão mais granular dos dados de localização).
4. Itere esse processo na saída, exigindo uma alteração ainda maior de latitude e longitude para uma alteração significativa. Portanto, a produção a ser produzida a partir da produção anterior será ainda mais granulada.
5. Repita todo o processo conforme necessário.
6. Agregue uma variedade de resoluções e envie-as aos usuários. Além disso, armazene todas as resoluções dos dados para consumo posterior.

O que devo usar para armazenar esses dados? Devo usar um banco de dados relacional ou uma solução NoSQL? Que outras coisas devo considerar ao criar este aplicativo?

Algumas alternativas para armazenar esses dados:

1. Fila de mensagens (possivelmente distribuída), como Apache Kafka

Isso será otimizado para escrever e ler um fluxo de dados. É ideal para coletar fluxos de dados em um formato fácil de processar, mas normalmente não pode ser consultado, exceto pela leitura completa do fluxo. Portanto, isso seria para fins de arquivamento ou uma etapa intermediária no caminho para uma camada de processamento.

2. Bancos de dados relacionais

Você pode simplesmente gravá-lo no banco de dados e, quando o volume exceder a capacidade do banco de dados, você pode fragmentar o banco de dados (= ter vários subconjuntos de dados em diferentes servidores de banco de dados). Benefício: você pode usar um banco de dados relacional e não precisa aprender nada de novo. Desvantagem: todo o código que lida com o banco de dados deve estar ciente de qual fragmento está armazenado em quais dados, consultas agregadas devem ser feitas no software aplicativo.

3. Banco de dados NoSQL distribuído, como Cassandra.

Você grava seus dados em um banco de dados NoSQL distribuído e os dados serão compartilhados automaticamente. O Cassandra permite fazer consultas no cluster, exigindo menos código do aplicativo para retornar aos dados. Benefício: mais naturalmente adequado para grandes quantidades de dados, desvantagem: exigirá conhecimento específico e profundo conhecimento da mecânica de como esses sistemas funcionam para obter bom desempenho e tornar os dados consultáveis ​​de acordo com suas necessidades. O NoSQL não é uma correção mágica de desempenho, é um conjunto de trade-offs que devem ser entendidos para serem navegados.

4. Hadoop / arquivo

Os dados são anexados aos arquivos que são distribuídos automaticamente pelos servidores pela plataforma Hadoop, processados ​​nesses servidores usando ferramentas como M / R ou Apache Spark e, finalmente, consultados (como arquivo) usando um mecanismo SQL do Hadoop como o Hive ou Impala.

Qual escolher?

As compensações entre essas alternativas são complexas e dependem muito dos padrões de gravação e de leitura, portanto, a única pessoa que pode decidir sobre essas compensações é você. Se você não tiver tempo para desenvolver um entendimento profundo dessas alternativas, basta usar um banco de dados relacional e descobrir uma solução de fragmentação à medida que avança. Com toda a probabilidade, YAGNI .

Examine seus requisitos um pouco mais profundamente. Existe uma maneira de criar a ilusão de rastrear a posição a cada segundo.

Se você tem um aplicativo que conhece sua localização GPS atual e a grava em um banco de dados, por que continuaria escrevendo a localização se ela não mudar? Mesmo se você precisar dos dados, se o usuário estiver dormindo por 7 horas, poderá preencher programaticamente os horários ausentes com um local duplicado para fazer seus cálculos ou mapeamentos ou o que mais for necessário.

Se você rastrear o local a cada segundo, precisará armazenar esses dados para sempre? Você pode arquivar os registros em outro banco de dados para impedir que a tabela atual fique muito grande. Ou você pode apenas manter os registros onde há uma mudança de posição. Isso é comum em data warehouses.

Seus dados são um conjunto de séries temporais. Você forneceu conjuntos de números (dois por usuário) que evoluem com o tempo. Normalmente, você NÃO está procurando nenhum tipo de armazenamento relacional, mas um armazenamento RRD. Esse armazenamento se concentra fortemente na redução do trabalho de E / S de várias gravações pequenas, armazenando-o em buffer.

O armazenamento relacional é uma heresia para esse volume de séries temporais. No entanto, esteja avisado de que o desenvolvimento do RRD não é tão bem suportado em termos de explorações programáveis ​​quanto o SQL. Você provavelmente está procurando um trabalho sério de integração, mas dificilmente é evitável, considerando seus requisitos.