¿Cuándo NO debe usar un índice espacial?

28

Lo pregunto porque estaba trabajando principalmente con Oracle, pero durante el año pasado he estado duplicando con PostGIS y SQLServer 2008. La mayoría de las funciones espaciales en Oracle no funcionarán sin un índice espacial que devuelva el error ORA-13226:

  

13226, 00000, "interfaz no admitida sin un índice espacial"   // * Causa: la tabla de geometría no tiene un índice espacial. //   * Acción: Verificar que la tabla de geometría referenciada en el espacio   el operador tiene un índice espacial en él.

Para mí esto tiene sentido. Ejecuta una consulta espacial = debe tener un índice espacial. Pero por lo que yo entiendo, ni PostGIS ni el Servidor SQL lo requieren. PostGIS parece tener funciones (_ *, por ejemplo, _STContains) que EXPLICITAMENTE no utilizará el índice espacial.

Entonces, la pregunta es: ¿hay casos en los que NO deba usar un índice espacial? No necesariamente si se trata de un enfoque de 'tómalo o déjalo', es decir, no hará ninguna diferencia, pero ¿dónde NO usar el índice espacial mejorará el rendimiento? Para mí, la última oración es una contradicción en términos, pero, de lo contrario, ¿por qué PostGIS proporcionaría estas funciones?

    
pregunta mapoholic 27.07.2011 - 14:43

4 respuestas

11

mapoholic,

En términos generales, no hay ninguna razón para realizar una consulta espacial sin un índice espacial a menos que esté trabajando con tablas realmente pequeñas. Aun así, usted usaría el ST_ que no usa un índice pero tiene el & & Operadores de caja de cortocircuito indexables. Las funciones que comienzan con _ST no están destinadas a ser utilizadas por los usuarios finales. La razón por la que existen es porque tienen que hacerlo. Los índices espaciales de PostGIS utilizan la inclusión de SQL para forzar el uso del índice: el _ST generalmente lo realiza GEOS y & & Es el índice que se puede reordenar. Así que los _ST son realmente un artefacto de implementación.

en resumen, no es una función para que la operación de índice se pueda reordenar para que suceda de una sola vez antes de la verificación espacial más intensa.

    
respondido por el LR1234567 28.07.2011 - 00:16
24

Si su conjunto de datos se agrega y actualiza con frecuencia, las instrucciones INSERT, DELETE y UPDATE que causan la reconstrucción del índice pueden ralentizar la base de datos.

Para inserciones masivas, como cargar todo el conjunto de datos OSM en una base de datos, puede ser más rápido descartar los índices y crearlos nuevamente después.

Si es más eficiente ignorar un índice (por ejemplo, la tabla es lo suficientemente pequeña como para cargarla en la memoria), el procesador de consultas de la base de datos debería hacerlo automáticamente.

Espero que la razón principal para permitir que las consultas se ejecuten sin un índice espacial es medir los beneficios de rendimiento que obtiene al usar un índice, sin tener que descartarlo.

Finalmente, si desea mostrar un gran aumento en el rendimiento de las consultas y visualizaciones de mapas, es posible que desee retrasar la creación de índices para un momento oportuno en el desarrollo del sistema ...

    
respondido por el geographika 27.07.2011 - 15:16
9

Creo que esto está implícito, pero NO usaría un índice espacial para una consulta cuando tuviera un índice no espacial que podría usar en su lugar. Por ejemplo, tengo 2,113,450 puntos que abarcan los Estados Unidos cargados en una tabla. Si quisiera extraer todos los puntos que estaban dentro del estado de Alaska, podría hacer una consulta espacial que usara el índice GIST en las geometrías de los puntos para compararlos con la geometría del estado de Alaska, O, solo podría usar el campo "state_alpha" en los datos de puntos (que también se indexa) para devolver todos los puntos que tienen "state_alpha" = 'AK'.

"¿Dónde está la parte espacial de esto", preguntas? Bueno, si necesito realizar un análisis espacial adicional en los puntos Alaska_ después de recopilarlos, es más rápido recopilar esas geometrías de puntos utilizando primero una consulta no espacial. También significa que para conjuntos de datos realmente grandes, se beneficia al agregar un campo de búsqueda (o tabla). Una vez más, sé que esto probablemente sea obvio para todos los que ya están en la lista, solo lo menciono porque en el pasado lo encontré con conjuntos de datos globales que solo estaban indexados espacialmente, y donde una consulta común era "todas las características dentro de un país". Obtuvimos una gran cantidad de rendimiento al agregar un campo indexado country_fips.

A continuación se muestran algunos resultados de EXPLAIN ANALYZE que demuestran el punto. (NOTA: traté de hacer que la consulta espacial fuera lo más eficiente posible utilizando una consulta de BBOX. El uso de los esquemas de estado solo lo habría hecho más 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 
    
respondido por el lagerratrobe 28.07.2011 - 22:33
0

Acabo de notar esta declaración

  

Para mí esto tiene sentido. Ejecuta una consulta espacial = debe tener una   índice espacial

Para mí, esto no tiene ningún sentido y creo que tanto SQL Server como Postgis hacen un mejor trabajo o al menos no le molestan con los detalles de rendimiento. De hecho, tanto SQL Server como Postgis a veces ni siquiera usan el índice espacial (revertir al escaneo completo de la tabla).

Para Oracle, debe crear el índice y, por lo tanto, debe completar user_sdo_geom_metadata.

Al comparar esto con los índices alfanuméricos, están ahí por razones de rendimiento, su declaración SQL debería funcionar con y sin ella.

En una base de datos Oracle, elimine el índice y obtendrá una gran cantidad de errores y aplicaciones que no podrán utilizar consultas espaciales, por lo que no funcionarán.

    
respondido por el user2192239 28.09.2016 - 16:21

Lea otras preguntas en las etiquetas