Come archiviare grandi quantità di dati _structured_?

L'applicazione raccoglierà continuamente (circa ogni secondo) la posizione degli utenti e li memorizzerà.

Tuttavia, ci sono troppi dati. Ogni giorno ci saranno 60 × 60 × 24 = 86.400 record per utente. Anche con 1000 utenti, ciò significa 86.400.000 record al giorno.

E non sono solo 86.400.000 di record al giorno. Perché questi record verranno elaborati e anche le versioni elaborate verranno archiviate. Quindi, moltiplica quel numero per circa 2.

Come intendo utilizzare i dati

In sostanza, ho in programma di realizzare versioni più grossolane dei dati sulla posizione per un consumo più semplice. Questo è:

Ordinare i timestamp wrt dati ricevuti.
Andando su questo elenco in ordine, determinare se la posizione è cambiata in modo significativo (verificando quanto sono cambiate la latitudine e la longitudine)
Rappresenta le modifiche di posizione non significative come una singola voce nell'output (pertanto, l'output è una versione più grossolana dei dati di posizione).
Iterate questo processo sull'output, richiedendo un cambiamento ancora maggiore di latitudine e longitudine per un cambiamento significativo. Quindi, l'output da produrre dall'output precedente sarà ancora più grossolano.
Scorrere l'intero processo quanto basta.
Aggrega una serie di risoluzioni e inviale agli utenti. Inoltre, memorizza tutte le risoluzioni dei dati per un consumo successivo.

Cosa devo usare per archiviare questi dati? Dovrei usare un database relazionale o una soluzione NoSQL? Quali altre cose dovrei considerare durante la progettazione di questa applicazione?

database big-data

— Utku
fonte

2000 record al secondo come quello probabilmente non guasteranno un motore SQL aggiornato. Un semplice test di capacità sarebbe quello di ottenere un programma console che scrive casualmente su file che vengono caricati in blocco.

— Caleth,

@Caleth Ma è scalabile? Che dire di quando la base di utenti cresce 100 volte?

— Utku,

Misura ciò che il tuo hardware può attualmente gestire. È probabile che il collo di bottiglia sia la CPU che "elabora" i valori o la velocità del disco non elaborato. Cosa intendi fare con tutti questi dati? Ciò dovrebbe dare forma alla tecnologia scelta per lo stoccaggio

— Caleth,

Caleth ha assolutamente ragione. Milioni di record non fanno impazzire un moderno sistema di database. I negozi NoSQL sono molto bravi a scrivere enormi quantità di dati molto velocemente, ma alla fine vuoi fare qualcosa che implica leggere di nuovo le cose. Quanta lettura ti servirà spesso determina il tipo di negozio che dovresti usare.

— Kilian Foth,

Per dare una buona risposta, dobbiamo sapere come prevedi di utilizzare questi dati. Un database potrebbe essere una buona scelta se desideri query ad hoc, mentre una soluzione basata su file sarebbe probabilmente migliore per l'analisi di interi set di dati. Votare per chiudere.

— kdgregory,

Risposte:

Alcune alternative per la memorizzazione di questi dati:

Coda dei messaggi (possibilmente distribuita), come Apache Kafka

Questo sarà ottimizzato per la scrittura e la lettura di 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 se non leggendo il flusso nella sua interezza. Quindi, questo sarebbe o per scopi di archiviazione o un passaggio intermedio sulla strada per un livello di elaborazione.

Database relazionale

Puoi semplicemente scriverlo nel database e quando il volume supera la capacità del DB da gestire, puoi frammentare il database (= avere più sottoinsiemi di dati su diversi server di database). Vantaggio: è possibile utilizzare un DB relazionale e non è necessario apprendere nulla di nuovo. Unico inconveniente: tutto il codice relativo al DB deve essere consapevole di quale frammento di dati risiede, le query aggregate devono essere eseguite nel software applicativo.

Database NoSQL distribuito, come Cassandra.

Scrivi i tuoi dati su un database NoSQL distribuito e li frammenterà automaticamente. Cassandra consente di eseguire query in tutto il cluster, richiedendo meno codice applicazione per recuperare i dati. Vantaggio: più naturalmente adatto per grandi quantità di dati, aspetto negativo: richiederà competenze specifiche e una profonda conoscenza della meccanica di come funzionano questi sistemi per ottenere buone prestazioni e rendere i dati interrogabili in base alle vostre esigenze. NoSQL non è una soluzione magica per le prestazioni, è un insieme di compromessi che devono essere compresi per essere navigati.

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 sottoposti a query (come file) utilizzando un motore Hadoop SQL come Hive o Impala.

Quale scegliere?

I compromessi tra queste alternative sono complessi e dipendono in gran parte sia dalla tua scrittura che dai tuoi schemi di lettura, quindi l'unica persona che può decidere su questi compromessi sei tu. Se non hai il tempo di approfondire queste alternative, usa semplicemente un DB relazionale e scopri una soluzione di sharding mentre procedi. Con ogni probabilità, YAGNI .

— Joeri Sebrechts
fonte

Ho fornito maggiori dettagli su come intendo utilizzare i dati. Vorresti aggiungere qualcosa dato queste informazioni?

— Utku,

Non mi è ancora chiaro cosa intendi per "risoluzione". Vuoi aggregare a livello geografico (città, stato, ...) o su un sistema di coordinate come un geohash? Oppure sei interessato alla quantità di delta perché vuoi creare notifiche basate sulle soglie di movimento? In breve: a cosa serve tutto questo?

— Joeri Sebrechts,

È per il monitoraggio degli utenti. Gli utenti si tracciano a vicenda e io grafico dove sono stati gli utenti che tracciano nelle ultime 5 ore sui dispositivi. In sostanza, più fine è, meglio è. Tuttavia, i dispositivi mobili hanno una quantità limitata di memoria, quindi non è possibile inviare i dati senza ridurne la risoluzione. Cioè, supponiamo che l'utente A stia monitorando l'utente B, C e D. Se inoltro semplicemente qualsiasi dato di posizione che ricevo da B, C e D ad A senza eseguire alcuna elaborazione sul lato server, la memoria del dispositivo dell'utente A si riempirà molto rapidamente . Quindi, ho bisogno di fare un po 'di elaborazione.

— Utku,

Se dovessi costruire quello che stai descrivendo, lo costruirei come una serie di registri kafka collegati tramite spark streaming, in cui le posizioni sono integrate tra le finestre nel flusso spark e il registro kafka di output finale viene fornito come pull e spingere le API dei web verso i client. Tuttavia ... questa è una tecnologia molto particolare e, a seconda del tuo background e del tempo disponibile, queste scelte potrebbero essere sbagliate per te.

— Joeri Sebrechts,

Grazie. Lo terrò a mente, ma seguendo il principio YAGNI, sto pensando di utilizzare un database relazionale per ora. Quando se ne presenta la necessità, passerò a qualcosa che si adatta meglio all'applicazione. Sentiti libero di modificare qualsiasi informazione nella tua risposta, se lo desideri.

— Utku,

Esamina 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 attuale e la scrive su un database, perché dovresti continuare a scrivere la posizione se non cambia? Anche se hai bisogno dei dati, se l'utente ha dormito per 7 ore, puoi compilare a livello di programmazione le fasce orarie mancanti con una posizione duplicata per eseguire i calcoli o la mappatura o qualsiasi altra cosa tu debba fare.

Se si tiene traccia della posizione ogni secondo, è necessario conservare questi dati per sempre? È possibile archiviare i record in un altro database per evitare che la tabella corrente diventi troppo grande. Oppure potresti anche tenere i registri in cui c'è un cambio di posizione. Questo è comune nei data warehouse.

— Jeffo
fonte

I tuoi dati sono un insieme di serie temporali. Hai fornito set di numeri (due per utente) che si evolvono nel tempo. In genere, NON stai cercando alcun tipo di memoria relazionale, ma piuttosto una memoria RRD. Questa memoria si concentra fortemente sulla riduzione del lavoro di I / O di numerose piccole scritture mediante buffering.

L'archiviazione relazionale è un'eresia per questo volume di serie storiche. Tuttavia, tieni presente che lo sviluppo di RRD non è abbastanza ben supportato in termini di sfruttamenti programmabili rispetto a SQL. Probabilmente stai esaminando un serio lavoro di integrazione, ma è difficilmente evitabile date le tue esigenze.

— Arthur Havlicek
fonte