¿Por qué mis búsquedas espaciales son más lentas en SQL Server que PostGIS?

Question

Estoy trabajando en mover algunas capacidades de búsqueda espacial de Postgres con PostGIS a SQL Server y estoy viendo un rendimiento bastante terrible, incluso con índices.

Mis datos es de alrededor de un millón de puntos, y quiero averiguar cuál de estos puntos están dentro de formas dadas, por lo que la consulta es como la siguiente:

DECLARE @Shape GEOMETRY = ... 
SELECT * FROM PointsTable WHERE Point.STWithin(@Shape) = 1 

Si selecciono una bastante pequeña forma, A veces puedo obtener segundos segundos, pero si mi forma es bastante grande (que a veces son), puedo obtener tiempos de más de 5 minutos. Si ejecuto las mismas búsquedas en Postgres, siempre están por debajo de un segundo (de hecho, casi todas tienen menos de 200 ms).

He intentado varios tamaños de cuadrícula en mis índices (todos altos, todos medianos, todos bajos), diferentes celdas por objeto (16, 64, 256) y no importa lo que haga, los tiempos permanecen bastante constantes. Me gustaría probar más combinaciones, pero ni siquiera sé qué dirección tomar. Más celdas por objeto? ¿Menos? ¿Alguna extraña combinación de tamaños de cuadrícula?

He visto mis planes de consulta y siempre están usando el índice, simplemente no está ayudando en absoluto. Incluso he intentado sin el índice, y no es mucho peor.

¿Hay algún consejo que alguien pueda dar sobre esto? Todo lo que puedo encontrar sugiere que "no podemos darle ningún consejo sobre índices, simplemente pruebe todo y tal vez uno funcione", pero demorar 10 minutos en crear un índice, hacerlo a ciegas es una gran pérdida de tiempo.

EDITAR: También publiqué esto en a Microsoft forum. He aquí alguna información que pedían allí:

El mejor índice de trabajo que pude conseguir fue la siguiente:

CREATE SPATIAL INDEX MapTesting_Location_Medium_Medium_Medium_Medium_16_NDX 
    ON MapTesting (Location) 
USING GEOMETRY_GRID 
    WITH (
    BOUNDING_BOX = (-- The extent of our data, data is clustered in cities, but this is about as small as the index can be without missing thousands of points 
     XMIN = -12135832, 
     YMIN = 4433884, 
     XMAX = -11296439, 
     YMAX = 5443645), 
    GRIDS = (
     LEVEL_1 = MEDIUM, 
     LEVEL_2 = MEDIUM, 
     LEVEL_3 = MEDIUM, 
     LEVEL_4 = MEDIUM), 
    CELLS_PER_OBJECT = 256 -- This was set to 16 but it was much slower 
) 

he tenido algunos problemas para conseguir el índice utilizado, pero esto es diferente.

Para estas pruebas realicé una búsqueda de prueba (la que figura en mi publicación original) con una cláusula WITH (INDEX (...)) para cada uno de mis índices (probando varias configuraciones para el tamaño de la cuadrícula y las celdas por objeto) y uno sin ninguna pista. También ejecuté sp_help_spatial_geometry_index usando cada índice y la misma forma de búsqueda. El índice mencionado anteriormente funcionaba más rápido y también se incluyó como el más eficaz en sp_help_spatial_geometry_index.

Cuando se ejecuta la búsqueda consigo estas estadísticas:

(1 row(s) affected) 
Table 'MapTesting'. Scan count 0, logical reads 361142, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'extended_index_592590491_384009'. Scan count 1827, logical reads 8041, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 

(1 row(s) affected) 

SQL Server Execution Times: 
    CPU time = 6735 ms, elapsed time = 13499 ms. 

También he intentado usar como puntos aleatorios de datos (ya que no puedo dar a conocer nuestros datos reales), pero resulta que esta búsqueda es realmente rápido con datos aleatorios. Esto nos lleva a creer que nuestro problema es cómo funciona el sistema de cuadrícula con nuestros datos.

Nuestros datos son direcciones en todo el estado, por lo que hay algunas regiones de muy alta densidad, pero la mayoría de los datos son escasos. Creo que el problema es que ninguna configuración para los tamaños de cuadrícula funciona bien para ambos. Con cuadrículas establecidas en HIGH, el índice devuelve demasiadas celdas en áreas de baja densidad, y con grillas establecidas en LOW, las cuadrículas son inútiles en áreas de alta densidad (en MEDIUM, no es tan malo, pero aún no es bueno en ninguno).

Puedo utilizar el índice, simplemente no está ayudando. Cada prueba se ejecutó con "mostrar plan de ejecución real" activado, y siempre muestra el índice.

Answer 1

Éstos son algunos comentarios sobre las extensiones espaciales de SQL Server y cómo asegurarse de que el índice se utiliza de manera eficiente:

• http://sqlskills.com/BLOGS/BOBB/post/How-to-ensure-your-spatial-index-is-being-used.aspx

Al parecer, el planificador tiene dificultades para construir un buen plan si no conoce la geometría real durante el tiempo de análisis. El autor sugiere insertar exec sp_executesql:

Reemplazar:

-- does not use the spatial index without a hint 
declare @latlonPoint geometry = geometry::Parse('POINT (45.518066 -122.767464)') 
select a.id, a.shape.STAsText() 
from zipcodes a 
where a.shape.STIntersects(@latlonPoint)=1 
go 

con:

-- this does use the spatial index without using a hint 
declare @latlonPoint geometry = geometry::Parse('POINT (45.518066 -122.767464)') 
exec sp_executesql 
N'select a.id, a.shape.STAsText() 
from zipcodes a 
where a.shape.STIntersects(@latlonPoint)=1', N'@latlonPoint geometry', @latlonPoint 
go 

Answer 2

Mi reacción visceral es "porque Microsoft no ha tomado la molestia de hacerlo rápido, porque no es una Empresa Característica". Tal vez estoy siendo cínico.

No estoy seguro de por qué estás migrando lejos de Postgres tampoco.

Answer 3

no estoy familiarizado con las consultas espaciales, pero podría ser un problema de consulta con parámetros

intentar escribir una consulta (sin utilizar parámetros) con un valor fijo (utilizar un valor que realiza lenta con la consulta con parámetros) y ejecutarlo. Compare los tiempos con la versión parametrizada. Si es mucho más rápido, su problema son las consultas parametrizadas.

Si lo anterior es mucho más rápido, entonces construiría dinámicamente su cadena sql con los valores de los parámetros incrustados en la cadena, de esa manera puede eliminar los parámetros que causan problemas.

Answer 4

¿Ha configurado correctamente su índice espacial? ¿Es correcto su cuadro delimitador? ¿Están todos los puntos adentro? En su caso, probablemente HHMM para GRIDS funcionaría mejor (dependiendo nuevamente de una caja de bouding).

¿Puedes tratar de usar sp_help_spatial_geometry_index, para ver qué pasa? http://msdn.microsoft.com/en-us/library/cc627426.aspx

Intente utilizar la operación de filtro y díganos qué números de perfunción obtiene? (ejecuta solo el filtro primario (use index) sin pasar por el filtro secundario (operación espacial real))

Algo está mal con su configuración. Spatial es, de hecho, una nueva característica, pero no es tan malo.

Answer 5

Creo que STIntersects está mejor optimizado para usar el índice que tendría un mejor rendimiento que STWithin, especialmente para formas más grandes.

Answer 6

Usted puede tratar de dividirlo en dos pases:

1. seleccionar a los candidatos en una tabla temporal w/.Filter().
2. candidatos de consulta w/.STWithin().

por ejemplo:

SELECT * INTO #this FROM PointsTable WHERE Point.Filter(@Shape) = 1 
SELECT * FROM #this WHERE Point.STWithin(@Shape) = 1 

(reemplazando SELECT * con sólo las columnas reales que necesita para reducir la E/S)

Este tipo de micro-optimización no debería ser necesario, pero tengo visto mejoras decentes de rendimiento antes. Además, podrá evaluar cuán selectivo es su índice por la relación de (1) a (2).

Answer 7

Acabo de pasar el día en un problema similar. En particular, estamos haciendo una consulta de tipo punto en polígono, donde había un conjunto relativamente pequeño de polígonos, pero cada polígono era grande y complejo.

solución resultó ser de la siguiente manera, para el índice espacial en la tabla polígono:

1. Uso "rejilla geometría auto" en lugar de la antigua MMLL etc. Esto da 8 niveles como máximo en lugar de la vieja 4, y la configuración es automática. 'celdas por objeto' Y ...
2. SET para 2000 o 4000. (No es una cosa fácil de adivinar, dado que el valor predeterminado es 16!)

Esto marcó una gran diferencia. Era 10 veces más rápido que un índice espacial en la configuración predeterminada, y 60 veces más rápido que ningún índice en absoluto.

Answer 8

Problemas de eficiencia de implementación a un lado El servidor SQL usa Quadtree index mientras que PostGIS usa el índice R-tree.

R-tree es en la mayoría de los casos el mejor algoritmo, especialmente para grandes conjuntos de datos con diferentes tamaños de geometría.