Aumentar la velocidad de almacenamiento en caché de mosaicos (TileStache)

Estoy sirviendo mosaicos vectoriales usando TileStache , tengo todo configurado como quiero. Mis datos se almacenan en Postgres y estoy usando el proveedor VecTiles para servir mosaicos GeoJSON .

Quiero almacenar en caché todos mis mosaicos para que los mosaicos se sirvan más rápido. Estoy usando tilestache-seed.py para sembrar mi caché. Estoy ejecutando tiletache-seed en varias máquinas. Tilestache-seed funcionó muy bien hasta el nivel de zoom 13, pero después de eso, se tarda demasiado en almacenar en caché los mosaicos. Solo para Zoom Level 16, tengo 5023772 mosaicos para almacenar en caché, y solo obtengo 100k-200k mosaicos por día en cada máquina.

¿Cómo puedo hacer que mis teselas se almacenen más rápido ? ¿Hay alguna manera de ajustar tilestache-seed.py y hacer que se siembre más rápido?

Actualización: He intentado construir índices espaciales en mis tablas (en la columna de geometría y las columnas utilizadas para filtrar datos a través de la cláusula where) y todavía no he visto un aumento significativo en la velocidad de mosaico. A este ritmo, solo Zoom 17 me llevará un mes y esta vez solo aumentará exponencialmente a medida que avance hacia Zoom 21

Actualización 2: también intenté hacer vistas materializadas y no hay un cambio apreciable en el rendimiento, por lo que la optimización de la base de datos no funciona. Creo que tendré que optimizar el propio tiletache-seed.py o idear una nueva forma de almacenar en caché los mosaicos.

Información de hardware Estoy ejecutando los procesos de almacenamiento en caché en 8 PC diferentes, uno de los cuales es un i7 con 32 gb de ram y otro es un i3 con 4 gb de ram, pero ambos me dan casi la misma velocidad de almacenamiento en caché (aproximadamente 100k mosaicos por día)

Diría que para un zoom mayor de 15, si divide su área de interés en áreas más pequeñas (cuadro delimitador), podrá almacenarlos en caché en mucho menos tiempo ejecutando múltiples procesos en una sola máquina.

Por ejemplo, está ejecutando zoom 16 (que tiene 50,000,00 mosaicos) en una máquina y de acuerdo con su velocidad promedio de almacenamiento en caché de mosaicos, este proceso se completará en aproximadamente 40-50 días. Digamos que divide estos mosaicos en dos y los ejecuta simultáneamente en la máquina, luego podrá almacenarlos en caché en 20-25 días porque el proceso de siembra de mosaico utiliza solo alrededor del 30 por ciento de su procesador para un solo proceso de almacenamiento en caché de mosaico y sé esto porque tengo el mismo problema una vez y hasta algunos existentes esto resolvió mi problema.

No afectará la velocidad de almacenamiento en caché de baldosas si está ejecutando un solo proceso en una máquina o múltiples procesos, pero el uso de la CPU aumentará.

Espero que esto ayude.

Por defecto, shp2pgsql NO crea índices. Debe pasar -Ipara que genere un índice espacial. http://postgis.net/docs/manual-1.3/ch04.html#id435762

Compruebe si su tabla tiene un índice ejecutándose \d tablenameen psql. En la lista de índices debe aparecer una línea con "esencia" (a menos que haya elegido un índice diferente) y el nombre de su columna de geometría.

También puede agregar uno después del hecho, consulte http://postgis.net/docs/manual-1.3/ch03.html#id434676 (no deje que la nota sobre pérdida lo asuste):

CREATE INDEX [indexname] ON [tablename] USING GIST ( [geometrycolumn] );

Dado que probablemente también use columnas no espaciales en sus consultas, generalmente desea crear índices para cada columna que se usa para la búsqueda. Si, por ejemplo, tiene una consulta como SELECT * FROM roads WHERE priority = 3;entonces, priorityse usa y agregar un índice para ella acelerará significativamente las cosas:

CREATE INDEX idx_roads_priority ON roads(priority);.

Otra cosa que debe probar si está utilizando una consulta estándar es crear una vista materializada a partir de la consulta y construir sus mosaicos a partir de eso: http://www.postgresql.org/docs/9.3/static/sql-creatematerializedview.html

Lo que esto hará es crear una tabla que almacene la consulta (para que pueda actualizarla en el futuro). Asegúrese de tener índices espaciales en los MV secundarios y luego será lo más rápido posible.

Lo que podría estar sucediendo es que tiene un índice espacial, pero luego está seleccionando solo algunos de los datos, lo que significa que ya no está utilizando el índice espacial ...