Alcune alternative per la memorizzazione di questi dati:

1. Coda messaggi (eventualmente distribuiti), come Apache Kafka

Questo sarà ottimizzato per scrivere e leggere un flusso di dati. È ideale per la raccolta di flussi di dati in un formato facile da elaborare, ma in genere non può essere interrogato tranne che leggendo il flusso nella sua interezza. Quindi, questo dovrebbe essere per scopi di archiviazione o un passaggio intermedio sulla strada per un livello di elaborazione.

2. Database (i) relazionale

Puoi semplicemente scriverlo nel database e quando il volume supera la capacità del DB da gestire, puoi dividere il database (= avere più sottoinsiemi di dati seduti su server di database diversi). Vantaggio: puoi utilizzare un DB relazionale e non devi imparare nulla di nuovo. Lato negativo: tutto il codice che riguarda il DB deve essere consapevole su quale frammento di dati esiste, le query aggregate devono essere eseguite nel software applicativo.

3. Database NoSQL distribuito, come Cassandra.

Scrivi i tuoi dati su un database NoSQL distribuito, e ti taglierà automaticamente i dati. Cassandra consente di eseguire query nel cluster, richiedendo un numero inferiore di codice dell'applicazione per tornare ai dati. Vantaggio: più naturalmente adatto a grandi quantità di dati, al ribasso: richiederà competenze specifiche e una profonda conoscenza dei meccanismi di funzionamento di questi sistemi per ottenere buone prestazioni e rendere i dati interrogabili in base alle proprie esigenze. NoSQL non è una correzione di prestazioni magiche, è un insieme di compromessi che devono essere compresi per essere esplorati.

4. Hadoop / file

I dati vengono aggiunti ai file che vengono distribuiti automaticamente tra i server dalla piattaforma Hadoop, elaborati su quei server utilizzando strumenti come M / R o Apache Spark e infine interrogati (come file) utilizzando un motore Hadoop SQL come Hive o Impala .

Quale scegliere?

I compromessi tra queste alternative sono complessi e dipendono molto sia dalla tua scrittura che dai tuoi schemi di lettura, quindi l'unica persona che può decidere su questi trade-off sei tu. Se ti manca il tempo per sviluppare una profonda comprensione di queste alternative, usa semplicemente un DB relazionale e scopri una soluzione di condivisione man mano che procedi. Con ogni probabilità, YAGNI .

Guarda le tue esigenze un po 'più a fondo. C'è un modo per creare l'illusione di tracciare la posizione ogni secondo.

Se hai un'app che conosce la tua posizione GPS corrente e la scrive in un database, perché dovresti continuare a scrivere la posizione se non cambia? Anche se richiedi i dati, se l'utente ha dormito per 7 ore, puoi inserire a livello di codice gli intervalli di tempo mancanti con una posizione duplicata per eseguire i tuoi calcoli o la mappatura o qualsiasi altra cosa tu debba fare.

Se tieni traccia della posizione ogni secondo, devi memorizzare questi dati per sempre? È possibile archiviare i record in un altro database per impedire che la tabella corrente diventi troppo grande. O potresti anche solo mantenere i record dove c'è un cambio di posizione. Questo è comune nei data warehouse.

I tuoi dati sono un insieme di serie temporali. Hai dato serie di numeri (due per utente) che si evolvono nel tempo. In genere, NON si sta cercando alcun tipo di archiviazione relazionale, ma piuttosto una memoria RRD. Questi storage si focalizzano strongmente sulla riduzione del lavoro I / O di numerose piccole scritture mediante il buffering.

Lo storage relazionale è un'eresia per questo volume di serie temporali. Tuttavia, si tenga presente che lo sviluppo di RRD non è supportato in termini di sfruttamento programmabile rispetto a SQL. Probabilmente stai considerando un serio lavoro di integrazione, ma è difficilmente evitabile date le tue esigenze.