Set di dati geospaziali di grandi dimensioni (> 22 trilioni di articoli) con prestazioni di query di lettura rapida (<1s)

Sto progettando un nuovo sistema per un set di dati geospaziale di grandi dimensioni che richiederà prestazioni di query di lettura rapida. Pertanto, voglio vedere se qualcuno pensa che sia possibile o abbia esperienza / consulenza su DBMS, struttura dati o metodi alternativi adeguati per ottenere le prestazioni richieste nella seguente situazione:

I dati saranno continuamente prodotti da dati radar satellitari elaborati, che avranno una copertura globale. Sulla base della risoluzione satellitare e della copertura del pianeta, stima il set completo di dati per produrre valori in 75 miliardi di località discrete nel globo. Nel corso della vita di un singolo satellite, l'output produrrà fino a 300 valori in ciascuna di queste posizioni (quindi un set di dati totale di> 22 trilioni di valori). Questo è per un satellite, e ce n'è già un secondo in orbita, con altri due previsti nei nuovi anni. Quindi ci saranno molti dati! Un singolo elemento di dati è molto semplice e consisterà solo di (longitudine, latitudine, valore), ma a causa del numero di elementi che stima un singolo satellite per produrre fino a 100 TB.

I dati scritti non dovrebbero mai essere aggiornati, poiché cresceranno solo con l'elaborazione di nuove acquisizioni satellitari. La performance di scrittura non è importante, ma la performance di lettura è cruciale. L'obiettivo di questo progetto è di essere in grado di visualizzare i dati attraverso una semplice interfaccia come un livello su google maps, in cui ogni punto ha un valore colorato basato sulla sua media, gradiente o alcune funzioni nel tempo. (demo alla fine del post).

Da questi requisiti, il database deve essere scalabile e probabilmente cercheremo soluzioni cloud. Il sistema deve essere in grado di gestire query geospaziali come "punti near (lat, lon)" e "points Within (box)" e avere prestazioni di lettura di <1s per localizzare un singolo punto e poligoni che contengono fino a 50.000 punti (sebbene siano preferibili fino a 200.000 punti).

Finora ho un set di dati di test di circa 750 milioni di voci di dati in 111 milioni di località. Ho provato un'istanza postgres / postGIS, che ha funzionato bene, ma senza la possibilità di sharding non lo faccio, questo sarà in grado di far fronte alla crescita dei dati. Ho anche provato un'istanza di mongoDB, che di nuovo sembra OK, quindi lontano e con lo sharding potrebbe essere sufficiente scalare con il volume di dati. Recentemente ho imparato qualcosa su elasticsearch, quindi qualsiasi commento su questo sarebbe utile in quanto è nuovo per me.

Ecco una rapida animazione di ciò che vogliamo ottenere con il set completo di dati:

Questa gif (dalla mia prova postgres) sta servendo (6x3) riquadri raster pre-calcolati, ciascuno contenente ~ 200.000 punti e impiegando ~ 17 secondi per generarli. Facendo clic su un punto, il grafico viene creato estraendo tutti i valori storici nella posizione più vicina in <1 s.

Ci scusiamo per il lungo post, tutti i commenti / consigli sono i benvenuti.

Puoi frammentare per posizione. Partiziona il globo in una griglia e disponi ogni quadrato in quella griglia su un server. Da quando hai citato il cloud, sarebbe adatto al cloud. Ovviamente dovrai unire manualmente i risultati da più server.

In questo modo puoi utilizzare qualsiasi soluzione di database che ti piace. Non deve essere scalabile da solo.

I singoli quadrati avranno diverse quantità di dati. Puoi usare macchine di dimensioni diverse per loro (dato che si tratta di cloud), oppure metti più piccoli frammenti sulla stessa macchina.

Questo schema di sharding è ottimo per il tipo di query che esegui perché ogni query dovrà solo toccare pochissimi frammenti. La frammentazione nel tempo è peggiore perché per ogni query è necessario toccare tutti i frammenti di tempo. Lo sharding casuale ha lo stesso problema.

Tutto sommato, questo è un caso di sharding facile perché il modello di query si adatta così bene allo schema di sharding.

In realtà, mi chiedo se hai bisogno di un database per questo. Forse puoi dividere il globo in riquadri 1000x1000 o più piccoli e avere un file flat nell'archivio BLOB per ogni riquadro. L'archiviazione BLOB non dispiace affatto per i BLOB 1M.

L'esecuzione di una query è concettualmente molto semplice con questo schema di archiviazione. È possibile archiviare i dati in modo ridondante anche in più risoluzioni della griglia.

Quanto devono essere aggiornate le tue query di lettura?

È possibile partizionare il database per tempo se la mappa deve solo mostrare la misurazione più recente. Ciò ridurrebbe il carico di query per la mappa.

Per la cronologia di un determinato punto, puoi tenere un secondo negozio per xey mostrando la cronologia. Questo potrebbe essere fatto con un aggiornamento / aggiornamento notturno poiché i dati storici non cambieranno.

Quindi è possibile pre-calcolare le medie a risoluzioni più grossolane per l'integrazione con le mappe a diversi livelli di zoom. Ciò ridurrebbe il numero di punti da recuperare per le aree della mappa di grandi dimensioni (zoom indietro). Risoluzioni più precise verrebbero utilizzate per mappe più ingrandite che richiedevano aree più piccole. Se hai davvero bisogno di accelerarlo, puoi calcolare i riquadri come BLOB e interpretarli nella tua applicazione.

Poiché ciò implicherebbe un nuovo calcolo delle informazioni aggregate, vi sarebbe una certa latenza nei risultati delle query. A seconda della latenza accettabile, è possibile utilizzare questo tipo di approccio per ottimizzare le letture.

OK, quindi i tuoi punti devono essere calcolati medie nel tempo. Con questo calcolo immagino che le tue query effettive scendano abbastanza da 22 trilioni di articoli poiché i valori raster possono essere pre-calcolati per l'interrogazione.

Sembra che ci siano due classi di query: una per capire quali posizioni si trovano nella finestra della vista corrente e una seconda per fornire la statistica desiderata per quei punti. Il mio suggerimento è di utilizzare strumenti separati e specializzati per ciascuno.

Suppongo che tutte le misurazioni si riferiscano allo stesso insieme di punti da 75 miliardi. Questi lat / long, una volta stabiliti, sono quindi statici. Possono essere raggruppati, aggregati e indicizzati a un costo unico. Pertanto suggerirei la suddivisione per regione e livello di zoom. La dimensione di ciascun frammento sarà determinata dalle prestazioni che possono essere ottenute da ciascuna istanza GIS.

Il GIS restituirà una serie di punti passati a un database di serie temporali. Questo contiene i valori misurati ed esegue aggregati. KDB è uno di cui sono a conoscenza. Si rivolge al trading di titoli, che avrà meno chiavi ma più punti dati per chiave rispetto al tuo scenario.

Ci sarà un costo per il trasferimento dei valori chiave dal server GIS al DB della serie temporale. La mia ipotesi è che questo costo sarà rimborsato dall'elaborazione più rapida nel DB di serie temporali specifico dell'attività. Dalla formulazione della domanda sembra che una singola istanza non sarà in grado di contenere tutti i dati, quindi un po 'di traffico tra server sembra inevitabile. Data la velocità relativa dei componenti sembra probabile che l'invio di un keyset a un server remoto che abbia i dati memorizzati nella cache sia più veloce della lettura dei dati dal disco locale.

Se le parti di ricerca del punto e di calcolo del valore possono essere locali l'una con l'altra, ovviamente mi aspetto che la risposta sia più veloce. La mia (limitata) comprensione è che trovare gli N vicini più vicini a un determinato punto è un compito non banale. Questo è il motivo per cui ho suggerito di utilizzare un software specifico per eseguirlo. Se il rilevamento del punto può essere ridotto a

where latitude between x1 and x2
and logitude between y1 and y2

quindi quella parte potrebbe essere gestita dal software di memorizzazione del valore e il GIS eliminato dall'architettura.

Non ho implementato un tale sistema. Sto davvero solo pensando ad alta voce qui. A livello di petabyte non ci sono soluzioni standard. Esistono tuttavia numerosi fornitori di dati satellitari, quindi il tuo problema è trattabile. In bocca al lupo.