Aumentar a velocidade de armazenamento em cache de ladrilhos (TileStache)

Estou servindo blocos de vetor usando o TileStache , tenho tudo configurado como eu quero. Meus dados são armazenados no Postgres e estou usando o provedor VecTiles para servir blocos GeoJSON .

Quero armazenar em cache todos os meus blocos para que eles sejam mais rápidos. Estou usando tilestache-seed.py para propagar meu cache. Estou executando o tilestache-seed em várias máquinas. O Tilestache-seed funcionou muito bem até o nível de zoom 13, mas depois disso está demorando muito para armazenar em cache os blocos. Apenas para o nível de zoom 16, tenho 5023772 blocos para armazenar em cache e só recebo blocos de 100k a 200k por dia em cada máquina.

Como posso tornar meus blocos de cache mais rápidos ? Existe uma maneira de ajustar o tilestache-seed.py e torná-lo mais rápido?

Atualização: tentei criar índices espaciais em minhas tabelas (na coluna geometria e nas colunas usadas para filtrar dados através da cláusula where) e ainda não vi um aumento significativo na velocidade do ladrilho. Nesse ritmo, apenas o Zoom 17 levará um mês e esse tempo só aumentará exponencialmente à medida que passo em direção ao Zoom 21

Atualização 2: Tentei fazer visualizações materializadas também e não há alterações discerníveis no desempenho, portanto, otimizar o banco de dados não está funcionando. Acho que vou precisar otimizar o próprio tilestache-seed.py ou criar uma nova maneira de armazenar em cache os blocos.

Informações de hardware Estou executando os processos de armazenamento em cache em 8 PCs diferentes, um dos quais é um i7 com 32 GB de RAM e outro é um i3 com 4 GB de RAM, mas ambos me proporcionam quase a mesma velocidade de armazenamento em cache (aproximadamente 100 mil peças por dia)

Eu diria que, para o zoom maior que 15, se você dividir sua área de interesse em áreas menores (caixa delimitadora), poderá armazená-las em cache em muito menos tempo executando vários processos em uma única máquina.

Por exemplo, você está executando o zoom 16 (com 50.000,00 blocos) em uma máquina e, de acordo com a velocidade média de armazenamento em cache do bloco, esse processo será concluído em cerca de 40 a 50 dias. Digamos que você divida esses blocos em dois e execute-os simultaneamente na máquina. Você poderá armazená-los em cache em 20 a 25 dias, porque o processo de propagação de dor de marca usa apenas cerca de 30% do seu processador para um processo de cache de bloco único e eu sei isso porque eu tenho o mesmo problema uma vez e até certo ponto isso resolveu o meu problema.

Isso não afetará a velocidade de armazenamento em cache do bloco se você estiver executando um único processo em uma máquina ou vários processos, mas o uso da CPU será aumentado.

Eu espero que isso te ajude.

Por padrão, shp2pgsql NÃO cria índices. Você precisa passar -Ipara gerar um índice espacial. http://postgis.net/docs/manual-1.3/ch04.html#id435762

Verifique se sua tabela possui um índice executando \d tablenameno psql. Na lista de índices, deve haver uma linha com "gist" (a menos que você tenha escolhido um índice diferente) e o nome da coluna de geometria.

Você também pode adicionar um após o fato, consulte http://postgis.net/docs/manual-1.3/ch03.html#id434676 (não deixe que a observação sobre perdas o assuste):

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

Como você provavelmente também usa colunas não espaciais em suas consultas, geralmente deseja criar índices para cada coluna usada para pesquisa. Se por exemplo você tem uma consulta como SELECT * FROM roads WHERE priority = 3;, em seguida, priorityé usada e adicionar um índice para ele vai significativamente velocidades acima das coisas:

CREATE INDEX idx_roads_priority ON roads(priority);.

Outra coisa a tentar se você estiver usando uma consulta padrão é criar uma exibição materializada a partir da consulta e construir seus blocos a partir disso: http://www.postgresql.org/docs/9.3/static/sql-creatematerializedview.html

O que isso fará é criar uma tabela que armazena a consulta (para que você possa atualizá-la potencialmente no futuro). Verifique se você possui índices espaciais nas MVs filho e, em seguida, será o mais rápido possível.

O que pode estar acontecendo é que você possui um índice espacial, mas seleciona apenas alguns dados, o que significa que não está mais usando o índice espacial ...