Quando NON dovresti usare un indice spaziale?

Lo sto chiedendo perché stavo lavorando principalmente con Oracle, ma per l'anno passato ho raddoppiato con PostGIS e SQLServer 2008. La maggior parte delle funzioni spaziali in Oracle non funzionerà senza un indice spaziale che restituisce l'errore ORA-13226:

13226, 00000, "interfaccia non supportata senza un indice spaziale" // * Causa: la tabella della geometria non ha un indice spaziale. // * Azione: verificare che la tabella della geometria a cui fa riferimento l'operatore spaziale abbia un indice spaziale su di essa.

Per me questo ha senso. Esegui una query spaziale = devi avere un indice spaziale. Ma per quanto ho capito, né PostGIS né SQL Serve lo richiedono. PostGIS sembra anche avere funzioni (_ * ad esempio _STContains) che ESPLICITAMENTE non useranno l'indice spaziale.

Quindi la domanda è: ci sono casi in cui NON dovresti usare un indice spaziale? Non necessariamente se si tratta di un approccio "prendilo o lascialo", cioè non farà alcuna differenza, ma dove NON usare l'indice spaziale può compromettere le prestazioni? Per me, l'ultima frase è una contraddizione in termini, ma altrimenti perché PostGIS dovrebbe fornire queste funzioni?

mapoholic,

In generale, non c'è motivo di fare una query spaziale senza un indice spaziale a meno che non si tratti di tabelle veramente piccole. Tuttavia, useresti lo ST_ che non usa un indice ma ha gli operatori && indicizzabili per i cortocircuiti. le funzioni che iniziano con _ST non sono pensate per essere utilizzate dagli utenti finali. Il motivo per cui esistono è perché devono. Gli indici spaziali PostGIS utilizzano la funzione SQL Inline per forzare l'uso dell'indice: _ST viene generalmente eseguito da GEOS e && è l'indice che può essere riordinato. Quindi i _ST sono davvero un artefatto di implementazione.

quindi, in breve, non è una funzione in modo che l'operazione sull'indice possa essere riordinata in modo che avvenga tutte in una volta prima del controllo spaziale più intenso.

Se il set di dati viene aggiunto e aggiornato spesso, le istruzioni INSERT, DELETE e UPDATE che causano la ricostruzione dell'indice possono rallentare il database.

Per inserimenti di massa, come il caricamento dell'intero set di dati OSM in un database, potrebbe essere più rapido eliminare gli indici e crearli nuovamente in seguito.

Se è più efficiente ignorare un indice (ad esempio la tabella è abbastanza piccola per essere caricata in memoria), il processore di query del database dovrebbe farlo automaticamente.

Mi aspetto che il motivo principale per consentire l'esecuzione delle query senza un indice spaziale sia quello di misurare i vantaggi in termini di prestazioni ottenuti utilizzando un indice, senza doverlo eliminare.

Infine, se si desidera mostrare un enorme incremento delle prestazioni alle query e alla visualizzazione delle mappe, è possibile ritardare la creazione di indici in un momento opportuno nello sviluppo del sistema ...

Penso che questo sia implicito, ma NON utilizzerei un indice spaziale per una query quando avessi un indice non spaziale che potrei usare invece. Ad esempio, ho 2.113.450 punti che coprono gli Stati Uniti caricati in una tabella. Se volessi estrarre tutti i punti che si trovavano nello stato dell'Alaska, potrei fare una query spaziale che utilizzava l'indice GIST sulle geometrie dei punti per confrontare con la geometria dello stato dell'Alaska, OR, potrei semplicemente usare il campo "state_alpha" nei dati dei punti (anch'essi indicizzati) per restituire tutti i punti che hanno "state_alpha" = "AK".

"Dov'è la parte spaziale di questo", chiedi? Bene, se ho bisogno di fare qualche ulteriore analisi spaziale sui punti Alaska_ dopo averli raccolti, è più veloce raccogliere quelle geometrie dei punti usando prima una query non spaziale. Significa anche che per insiemi di dati veramente grandi, beneficiate dell'aggiunta di un campo di ricerca (o tabella). Ancora una volta, so che questo è probabilmente ovvio per tutti, lo dico solo perché l'ho incontrato in passato con set di dati globali che erano solo indicizzati spazialmente e in cui una query comune era "tutte le funzionalità all'interno di un paese". Abbiamo ottenuto molte prestazioni aggiungendo un campo country_fips indicizzato.

Di seguito sono riportati alcuni risultati di EXPLAIN ANALYZE che dimostrano il punto. (NOTA: ho cercato di rendere la query spaziale il più efficiente possibile utilizzando una query BBOX. L'uso dei contorni dello stato avrebbe solo reso più lento.)

# explain analyze select count(*) from gnis_names where state_alpha = 'AK';
Aggregate  (cost=57359.45..57359.46 rows=1 width=0) (actual time=76.606.. 76.607 rows=1 loops=1)
<snip>
Total runtime: 76.676 ms

# explain analyze select count(*) from gnis_names where the_geom && GeomFromText('POLYGON((-179.14734 51.219862,-179.14734 71.3525606439998,179.77847 71.3525606439998,179.77847 51.219862,-179.14734 51.219862))',4326);
Aggregate  (cost=27699.86..27699.87 rows=1 width=0) (actual time=86.523..86.524 rows=1 loops=1)
<snip>
Total runtime: 86.584 ms 

Ho appena notato questa affermazione

Per me questo ha senso. Esegui una query spaziale = devi avere un indice spaziale

Per me questo non ha affatto senso e penso che sia SQL Server che Postgis facciano un lavoro migliore o almeno non ti disturbino con i dettagli delle prestazioni. Infatti, sia SQL Server che Postgis a volte non usano nemmeno l'indice spaziale (ripristinano la scansione della tabella completa).

Per Oracle, è necessario creare l'indice e quindi è necessario compilare user_sdo_geom_metadata.

Solo confrontando questo con gli indici alfanumerici, sono lì per motivi di prestazioni, la tua istruzione SQL dovrebbe funzionare con e senza di essa.

In un database Oracle, rilasciare l'indice e otterrai un sacco di errori e app che non saranno in grado di utilizzare le query spaziali, quindi non funzioneranno.