¿Cuándo NO deberías usar un índice espacial?

Pregunto esto porque estaba trabajando principalmente con Oracle, pero durante el año pasado me he duplicado 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: Verifique que la tabla de geometría referenciada en el operador espacial tenga un índice espacial.

Para mí esto tiene sentido. Ejecutas una consulta espacial = debes tener un índice espacial. Pero por lo que yo entiendo, ni PostGIS ni SQL Serve requieren esto. PostGIS incluso parece tener funciones (_ * por ejemplo, _STContains) que EXPLÍCITAMENTE no usarán el índice espacial.

Entonces la pregunta es: ¿hay algún caso en el que NO deba usar un índice espacial? No necesariamente si es 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 por lo demás, ¿por qué PostGIS proporcionaría estas funciones?

mapoholic

En términos generales, no hay una razón para hacer una consulta espacial sin un índice espacial a menos que se trate de tablas realmente pequeñas. Sin embargo, usaría el ST_ que no usa un índice pero tiene los operadores de caja de cortocircuito indexables &&. Las funciones que comienzan con _ST no deben ser utilizadas por los usuarios finales. La razón por la que existen es porque tienen que hacerlo. Los índices espaciales de PostGIS usan la alineación de SQL para forzar el uso del índice: el _ST generalmente lo realiza GEOS y el && es el índice que puede reordenarse. Entonces los _ST son realmente un artefacto de implementación.

en resumen, no es una función, por lo que la operación de índice puede reordenarse para que ocurra de una vez antes de la verificación espacial más intensa.

Si su conjunto de datos se agrega y actualiza con frecuencia, las instrucciones INSERT, DELETE y UPDATE que provocan 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 soltar 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 hacer esto automáticamente.

Esperaría 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 pantallas de mapas, puede retrasar la creación de índices en un momento oportuno en el desarrollo del sistema ...

Creo que esto está implícito, pero NO usaría un índice espacial para una consulta cuando tuviera un índice no espacial que pudiera 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 puntos para comparar con la geometría del estado de Alaska, O, simplemente podría usar el campo "state_alpha" en los datos del punto (que también está indexado) para devolver todos los puntos que tienen "state_alpha" = 'AK'.

"¿Dónde está la parte espacial de esto", preguntas? Bueno, si necesito hacer un análisis espacial adicional en Alaska_points después de recopilarlos, es más rápido reunir 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, solo lo menciono porque lo encontré en el pasado 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". Ganamos mucho rendimiento al agregar un campo indexado country_fips.

A continuación se presentan algunos resultados de EXPLAIN ANALYZE que prueban el punto. (NOTA: Traté de hacer que la consulta espacial sea lo más eficiente posible utilizando una consulta BBOX. El uso de los contornos de estado solo la habría hecho más lenta).

# 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 

Acabo de notar esta declaración

Para mí esto tiene sentido. Ejecutas una consulta espacial = debes tener un í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 te molestan con detalles de rendimiento. De hecho, tanto SQL Server como Postgis a veces ni siquiera usan el índice espacial en absoluto (volver al escaneo completo de la tabla).

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

Simplemente comparando esto con índices alfanuméricos, están allí por razones de rendimiento, su declaración SQL debería funcionar con y sin ella.

En una base de datos Oracle, suelte el índice y obtendrá un montón de errores y aplicaciones que no podrán usar consultas espaciales, por lo tanto, no funcionan.