Scansione di un miliardo di righe in un database ultraveloce

La cosa più importante è sapere con certezza dove si trova il collo di bottiglia per un determinato numero di richieste rappresentative, poiché non è possibile cambiare database.

Se esegui scansioni complete della tabella, hai bisogno di indici appropriati.

Se aspetti I / O hai bisogno di più memoria per il caching (Jeff Atwood ha recentemente affermato che i sistemi a 24 Gb erano raggiungibili sui sistemi desktop).

Se aspetti sulla CPU, devi verificare se i tuoi calcoli possono essere ottimizzati.

Ciò richiede un cappello DBA a punta e un cappello del sistema operativo, ma vale la pena di assicurarti di abbaiare nell'albero giusto.

Che ne dici di partizionare la tabella in più pezzi situati su diversi host in base al timbro data? Questo è scalabile orizzontalmente e, se hai un numero sufficiente di caselle, puoi scrivere un piccolo motore di aggregazione in cima a queste impostazioni.

Se vedi che il timbro della data sta cambiando troppo, puoi partizionare in base alle posizioni, di nuovo scalabile orizzontalmente. (Si spera che non aggiungano molte altre latitudini / longitudini!)

Lo scenario peggiore è che l'intervallo di date copre tutte le date nel tuo database.

Stai cercando di leggere 1,3 miliardi di record e di fare una sorta di analisi su ogni record rispetto ai valori inseriti, su una macchina fisica, in meno di 5 secondi. Il risultato può essere in tutte le località o nessuno - non si sa nulla in anticipo.

Dati questi parametri direi probabilmente impossibile.

Guarda il tuo disco fisso: la velocità massima sostenuta è inferiore a 150 MB / s. La lettura di 1,3 miliardi di record richiederà più di 5 secondi. Dal punto di vista della CPU, non sarai in grado di eseguire alcun tipo di analisi statistica su 1,3 miliardi di record in 5 secondi.

La tua unica speranza (tm :-)) è trovare una sorta di funzione di ricerca in base ai valori immessi dall'utente che restringeranno la ricerca verso il basso (di pochi ordini di grandezza). È possibile calcolare questa funzione di ricerca offline. Senza saperne di più sui criteri di corrispondenza esatti, non penso che nessuno possa dirti come farlo, ma un esempio potrebbe essere quello di suddividere l'intervallo di valori in un intervallo discreto e creare una ricerca che fornisca tutti i record in quell'intervallo. Finché l'intervallo è abbastanza piccolo, puoi fare un vero lavoro al suo interno, ad es. eliminazione di voci che non corrispondono al valore inserito dall'utente. Fondamentalmente scambia spazio per tempo.

Potrebbe essere possibile conservare tutti i record (o almeno la parte importante) in memoria. Probabilmente non in 8 GB. Ciò eliminerà almeno la porzione di I / O del disco anche se anche la larghezza di banda della memoria potrebbe essere insufficiente per eseguire la scansione di tutto in 5 secondi. In ogni caso, questa è un'altra tecnica per accelerare questo tipo di applicazioni (combinarle con il mio precedente suggerimento).

Hai menzionato l'utilizzo di un servizio cloud. Sì, se paghi abbastanza CPU e I / O muscoli e dividi il tuo database su molti server puoi forzarlo / dividerlo e conquistarlo.

Ho in secondo luogo il commento di rwong alla domanda: PostgreSQL offre tipi di indici e strumenti appropriati (indici GIST, indici GIN, Postgis, tipi geometrici) in modo tale che i dati relativi a datetime e datetime debbano essere ricercabili secondo questi criteri senza molti problemi .

Se le tue query su questi criteri richiedono pochi secondi, probabilmente significa che non vengono utilizzati tali indici. Puoi confermare di aver esaminato questi dati come appropriato?

Dato che usi PostgreSQL e dati di latitudine / longitudine, dovresti assolutamente usare PostGIS, in questo modo puoi aggiungere un indice spaziale GiST al tuo database per velocizzare le cose.

Ho una tabella simile (con 350k righe) con una configurazione molto più piccola della tua (2 core e appena 2 GB di RAM), ma le ricerche richiedono meno di un secondo.

Forse potresti rompere un modello relazionale come ha fatto Essbase con la loro architettura OLAP: Essbase Wikipedia

Quello che intendo è creare una tabella per città, finendo così con 1000+ tabelle. Non un tavolo come te suggerito, ma molti. Indicizza ogni tabella per data e luogo. Molte tabelle, molti indici - > più veloce.

Per quanto riguarda la tua idea di trovare un servizio cloud per ospitare il database, hai già trovato SimpleGeo ? Hanno appena tagliato la barra multifunzione su un servizio di archiviazione apparentemente "ottimizzato specificamente per archiviare e interrogare i dati sulla posizione in modo veramente rapido", anche se il costo per archiviare e interrogare più di un miliardo di righe potrebbe rendere questo approccio irrealizzabile.

ti aspetti una bicicletta per correre in autostrada. attualmente stai cercando una soluzione per affrontare solo questo problema, non prevedi il problema e se avessi 2 miliardi di record? la scalabilità deve essere affrontata. la risposta è un database di oggetti di uso semplice. ad esempio cache di Intersystems

e credimi, non sono di intersistemi; -)