Estoy escribiendo una aplicación web de uso intensivo de datos que se entrega a través de apache. Mi pregunta es sobre cómo organizar mejor el procesamiento dado que existen múltiples opciones.
Tengo a mi disposición OpenLayers / JQuery / Javascript, PostGIS / Postgresql (con pgsql), python / psycopg2, php.
La base de datos contiene aproximadamente 3 millones de filas y el prototipo se ejecuta actualmente de la siguiente manera:
El usuario hace clic en un punto de la ventana de OpenLayers
La coordenada se envía como una solicitud AJAX a través de una función de Python en el servidor
Actualmente mi solicitud no tiene estado
El psycopg2 de Python se usa para llamar a un procedimiento almacenado pgsql y un amplio conjunto de valores WKT (y un campo de datos) se devuelven al módulo python
El campo de datos se usa para clasificar los registros WKT en Python de la siguiente manera: todos los valores WKT se clasifican en uno de los 5 grupos. Aproximadamente el 1% de los valores de WKT se modifican realmente.
Los cinco conjuntos / grupos de WKT están almacenados para crear cinco polígonos distintos. Actualmente llamo a un procedimiento almacenado en la base de datos para hacer esto. Esto a su vez solo usa ST_BUFFER. (He considerado usar Shapely, pero no estoy seguro de que haya una ventaja de rendimiento ya que la biblioteca GEOS se usa en cualquier caso ...)
Finalmente, los 5 valores de texto WKT se envuelven en una cadena JSON y se envían a OpenLayers para representarlos en cinco capas.
Estoy descubriendo que los cuellos de botella son la búsqueda espacial inicial y la etapa final de almacenamiento en búfer.
Supongo que la pregunta es:
¿Hay una mejor manera de arreglar las cosas? Por ejemplo, ¿TODO el procesamiento de datos debe realizarse en PostgreSQL (por ejemplo, con cursores) y ¿sería esto algo bueno en términos de mantenimiento y rendimiento? ¿Sería mejor usar un servidor de mosaico para evitar pasar cadenas WKT largas al cliente web? ¿Cómo lo abordarías?
fuente
Respuestas:
Cuello de botella de amortiguamiento
Al utilizar ST_Buffer, puede reducir la complejidad de la forma resultante agregando una opción num_seg_quarter_circle más baja. Esto debería reducir la cantidad de procesamiento al almacenar en búfer y en operaciones posteriores.
De la documentación de PostGIS:
En general, en PostGIS obtendrá un mejor rendimiento si ejecuta consultas en tablas existentes correctamente indexadas. Esto le brinda un fácil acceso a varias optimizaciones (como la agrupación). Considere procesar el 1% que cambia por separado y fusionar los dos al final.
fuente
Sin pensar en absoluto en la arquitectura, para todas las aplicaciones de mapeo web, desea hacer la mayor parte del procesamiento con anticipación. Esto significa que, si puede, las memorias intermedias deben calcularse previamente, todos sus datos deben estar en el SRS de salida, etc. Obviamente, algunos datos y cálculos deben ser dinámicos.
Sugiero que más allá de Python, mire MapServer y Geoserver para hacer los cálculos y producir la salida. Ambos podrían producir mosaicos de imágenes o salida GeoJSON. Ambas aplicaciones pueden usar PostGIS como back-end.
fuente