MongoDB e utilizzo di DBRef con dati spaziali

Question

Ho una raccolta con 100 milioni di documenti di geometria.

Ho una seconda raccolta con dati temporali associati a ciascuna delle altre geometrie. Questo sarà 365 * 96 * 100 milioni o 3.5 trilioni di documenti.

Anziché archiviare i 100 milioni di voci (365 * 96) volte più del necessario, voglio tenerle in raccolte separate e fare un tipo di JOIN/DBRef/Qualunque cosa io possa in MongoDB.

Prima di tutto, voglio ottenere un elenco di GUID dalla raccolta di geometrie utilizzando un geoIntersection. Questo lo filtrerà da 100 a 5000. Quindi, usando quei 5000 guai delle geometrie, voglio filtrare i 3.500 miliardi di documenti basati sui 5000 goemetries e ulteriori criteri di data che specificano e aggregano i dati e trovano la media. Ti rimangono 5000 geometrie e 5000 medie per i criteri di data specificati.

Questo è fondamentalmente un JOIN come lo conosco in SQL, è possibile in MongoDB e può essere fatto in modo ottimale in meno di 10 secondi.

Chiarire: come ho capito, questo è ciò che viene utilizzato DBrefs, ma ho letto che non è affatto efficiente, e con la gestione di molti dati che non sarebbe una buona misura.

Answer 1

Se si ha a che fare con una geometria e insieme dei dati relativi alle serie temporali, è opportuno memorizzarli nello stesso documento. Un valore di anni in dati con incrementi di 15 minuti non è un assassino - e sicuramente non vuoi un documento per ogni voce di serie temporali! Dal momento che è possibile recuperare tutto ciò su cui si vuole operare come un singolo documento geometrico, è una grande vittoria. Nota che anche questo ti fa sparpagliare per i dati mancanti. È possibile codificare i dati in modo diverso se è sparse anziché indicizzare in un array di slot 35040.

A $ geoIntersects su una grande pila di dati geometrici sarà comunque un problema di prestazioni. Assicurati di avere qualche indicizzazione (come 2dsphere) per accelerare le cose.

Se esiste un modo per creare qualificatori aggiuntivi nella query che potrebbe eliminare economicamente i membri dalla ricerca più costosa, è possibile rendere le cose più trasparenti. Ad esempio, supponiamo che la ricerca colpirà stati negli Stati Uniti. È possibile prima intersecare la ricerca con i confini dello stato per trovare gli stati contenenti i dati geografici e utilizzare qualcosa come un codice postale per qualificare i documenti. Sarebbe una pre-ricerca molto veloce contro 50 documenti. Se prima veniva determinato un limite di ricerca per colpire 2 stati e i record di dati geografici includevano un campo di stato, si limitavano a spulciare 96 milioni di record (a parità di condizioni) prima della più costosa parte geo della query. Se si intersecano con coordinate di griglia ridotte, si può essere in grado di approfondirlo prima che vengano considerati i dati geografici.

Ovviamente, andare troppo oltre aggiunge spese generali. Se riesci a sintonizzare correttamente il sistema sulla densità delle 100 milioni di geometrie, potresti essere in grado di ridurre i tempi. Ma senza effettivamente lavorare con le specifiche del problema, è difficile sapere. Probabilmente molti dati richiedono una sperimentazione specifica piuttosto che basarsi su una soluzione generale.