El almacenamiento en caché / Precarga de datos para su uso con WMS consultas

Question

Esperando que alguien me puede ayudar con este problema. Tengo un mapa implementado en mi aplicación web con OpenLayers que hace WMS consultas a GeoServer que a su vez las consultas de Postgres (PostGIS) de la base de datos para producir WMS azulejos. También se hace uso de WMS GetFeatureInfo para obtener información acerca de las características de su ratón sobre.

Debido a la cantidad de datos que se consulta en la carga inicial de las fichas puede tomar entre 1 a 10 minutos, dependiendo de los datos que se consulta (consulta puede ser ajustado por fecha/intervalos de tiempo y un par de otras propiedades), lo cual es aceptable porque es una gran cantidad de datos. Pero tengo un par de problemas relacionados con el rendimiento que estoy tratando de conseguir alrededor.

1. Cada vez que el nivel de zoom se cambia la base de datos se tiene que volver a consultar. Hay una manera en que los datos pueden ser almacenados en caché, de modo que no tiene que volver a ser consultado para cada cambio en el nivel de zoom? Los datos no cambian dependiendo del nivel de zoom por lo que la consulta se ejecuta es la de devolver el mismo resultado cada vez.
2. Cuando un usuario coloca el ratón sobre un elemento, una petición GetFeatureInfo y un emergente que se muestra sobre el mapa que detalla la entidad. Una vez más se ha de ejecutar la consulta completa de nuevo y, a continuación, se estrecha hacia abajo a la característica que ha sido el ratón sobre.

Previamente antes del cambio de uso de WMS se genera un único archivo KML a partir de los datos que recibimos de nuestros consulta de base de datos y, a continuación, este podría ser usado para cargar el mapa en todos los niveles de zoom y obtener la función de información. Hemos tenido que cambiar a partir de este enfoque para lidiar con el más grande y más complejo de los polígonos.

Así que simplemente, está ahí de todos modos para obtener GeoServer a utilizar una memoria caché de resultados de la consulta de datos o hay alguna manera de que yo tal vez podría generar el archivo KML cómo estaba antes, pero a continuación, pasar a GeoServer para que sea como WMS azulejos?

Mucho agradecería cualquier aportación sobre el tema o alguna sugerencia para obtener alrededor de los problemas que yo he indicado.

Gracias de antemano,

Marca

Answer 1

Dado que usted está solicitando WMS azulejos, usted puede utilizar un servicio de caché como WMS-C (WMS en Caché), Mapa de Mosaico de Servicio (TMS) o Web Map Tile Service (WMTS); el último es un estándar OGC. Existen varias implementaciones de estas normas; por mencionar algunos, hay GeoWebCache, TileCache o MapProxy.

Debido a que usted está usando GeoServer, creo que la mejor solución en tu caso sería GeoWebCache, que tiene una muy buena integración con GeoServer. Entre las normas citadas antes, tal vez WMTS es el uno que se adapte a sus necesidades de la mayoría, porque WMTS puede almacenar en caché los resultados de GetFeatureInfo solicitudes. Actualmente GeoWebCache 'implementa plenamente WMTS el uso de KVP'.

Answer 2

Para la caché de consultas de postgres usted debe echar un vistazo ad pgPool II. pgPool es un middleware para postgres que, entre otras cosas útiles, dispone de una memoria caché de consultas. Por favor, tenga en cuenta que incluso si una sola de cambios de parámetros, los resultados no se obtienen de la memoria caché (por razones obvias).

Dependiendo de cómo se realizan consultas de si el BBOX cambios en la memoria caché puede ser evitada, pero tal vez, dependiendo del software de cliente (que no especificó), puede evitar que.

Como para el almacenamiento en caché GetFeatureInfo las solicitudes que usted debe primero ver si pgPool puede manejar para usted también. Si no puede frontal GeoServer con un caché de proxy inverso, como Apache mod_cache o Barniz.

Answer 3

Suponiendo que el conjunto de datos no cambia en una base regular creo que @dariapra del método es la mejor para la representación de imágenes, pero por desgracia eso no va a cambiar el rendimiento de su GetFeatureInfo las solicitudes de la base de datos aún necesita ser consultados cada vez.

Usted podría considerar el uso de GDAL del ogr2ogr (o pg2shp pero nunca la he utilizado este) para exportar el conjunto de datos en un archivo separado tienda de la noche a la mañana. Si es aceptable para los datos a ser de hasta 24 horas de la fecha de este enfoque podría mejorar significativamente la representación y el rendimiento de las consultas. He hecho esto para exportar datos de un ajetreado base de datos de Oracle a una GeoDatabase de Archivos locales y la mejora es enorme.

Dependiendo del volumen de datos .shp podría no ser adecuado debido a su límite de 4 gb, pero se puede mirar en otro formato de archivo que GeoServer apoya.

Si no es aceptable que los datos a ser de hasta 24 horas fuera de fecha, ni este enfoque o el WMS de baldosas de caché va a trabajar para usted. En este caso, la mejor opción podría ser revisar el modelo de datos para buscar en denormalisation u otros ajustes de rendimiento.

Answer 4

Así que hay un montón de opciones que usted puede hacer para mejorar la velocidad. Depende de sus habilidades.

Si usted tiene el tiempo de las preguntas que usted puede estar en necesidad de sintonizar Postgresql recursos de memoria.

Si usted tiene habilidades de javascript puede reemplazar la WMSGetFeatureInfo control de Openlayers y caché de resultados en el control para evitar una repetición de consultas.

Si usted sabe un poco acerca de los idiomas de servidor como PHP, Python, etc a continuación, puede cargar mapscript en el idioma del servidor y hacer un servicio WMS para responder a su consulta compleja evitar una ejecución para geoserver, a continuación, postgres. En mapserver ellos llaman a este Mapscript Contenedores http://mapserver.org/ogc/mapscript.html

• request -> idioma de destino -> postgres

Usted va a necesitar para descubrir dónde está el cuello de botella de la primera.