타일 ​​캐싱 속도 증가 (TileStache)

TileStache를 사용하여 벡터 타일을 제공 하고 있으며 원하는대로 모든 것을 설정했습니다. 내 데이터는 Postgres에 저장되어 있으며 VecTiles 공급자를 사용하여 GeoJSON 타일 을 제공 하고 있습니다.

타일을 더 빨리 제공하기 위해 모든 타일을 캐시하고 싶습니다. tilestache-seed.py 를 사용하여 캐시를 시드하고 있습니다. 여러 컴퓨터 에서 tiletache-seed 를 실행 하고 있습니다. Tilestache-seed는 확대 / 축소 레벨 13까지 실제로 잘 작동했지만 타일을 캐시하는 데 너무 오래 걸립니다. Zoom Level 16의 경우 캐시 할 5023772 타일이 있으며 각 컴퓨터에서 하루에 100k-200k 타일 만 가져옵니다.

타일 ​​캐시를 더 빠르게 만들려면 어떻게 해야합니까? tilestache-seed.py 를 미세 조정 하고 더 빨리 시드 할 수 있는 방법이 있습니까?

업데이트 : 내 테이블 (geometry 열 및 where 절을 통해 데이터를 필터링하는 데 사용되는 열)에 공간 인덱스를 작성하려고 시도했지만 타일링 속도가 크게 증가하지 않았습니다. 이 속도에서는 Zoom 17 만 한 달이 걸리며 이번에는 Zoom 21쪽으로 이동하면 기하 급수적으로 증가합니다.

업데이트 2 : 구체화 된 뷰를 만들려고 시도했지만 성능에 눈에 띄는 변화가 없으므로 데이터베이스 최적화가 작동하지 않습니다. tilestache-seed.py 자체를 최적화하거나 타일을 캐시하는 새로운 방법을 고안해야한다고 생각합니다.

하드웨어 정보 8 개의 서로 다른 PC에서 캐싱 프로세스를 실행하고 있는데, 그 중 하나는 32GB 램이 장착 된 i7이고 다른 하나는 4GB 램이 장착 된 i3이지만 캐싱 속도는 거의 같습니다 (하루에 약 100k 타일).

15보다 큰 확대 / 축소의 경우 관심 영역을 더 작은 영역 (바운딩 박스)으로 분할하면 단일 시스템에서 여러 프로세스를 실행하여 훨씬 적은 시간에이를 캐시 할 수 있습니다.

예를 들어 컴퓨터에서 확대 / 축소 16 (50,000,00 타일)을 실행하고 평균 타일 캐싱 속도에 따라이 프로세스는 약 40-50 일 후에 완료됩니다. 이 타일을 두 개로 나누고 머신에서 동시에 실행하면 20-25 일 안에 타일을 캐싱 할 수 있습니다. 타일 타겟 시딩 프로세스는 단일 타일 캐싱 프로세스에 프로세서의 약 30 % 만 사용하기 때문에 알고 있습니다 이것은 같은 문제가 한 번 있고 얼마 남았 기 때문에 내 문제를 해결했기 때문입니다.

머신이나 여러 프로세스에서 단일 프로세스를 실행하는 경우 타일 캐싱 속도에 영향을 미치지 않지만 CPU 사용량은 증가합니다.

이것이 도움이되기를 바랍니다.

기본적으로 shp2pgsql은 색인을 작성하지 않습니다. -I공간 인덱스를 생성 하려면 전달해야합니다 . http://postgis.net/docs/manual-1.3/ch04.html#id435762

\d tablenamepsql에서 실행하여 테이블에 인덱스가 있는지 확인하십시오 . 색인 목록에 "gist"(다른 색인을 선택하지 않은 경우)와 기하 열 이름이있는 행이어야합니다.

사실 다음에 하나를 추가 할 수 있습니다 ( http://postgis.net/docs/manual-1.3/ch03.html#id434676 참조 ).

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

쿼리에서 비 공간 열을 사용할 수도 있으므로 일반적으로 조회에 사용되는 각 열에 대한 인덱스를 만들려고합니다. 예를 들어 SELECT * FROM roads WHERE priority = 3;다음 과 같은 쿼리 priority가 사용되고 인덱스를 추가하면 작업 속도가 크게 향상됩니다.

CREATE INDEX idx_roads_priority ON roads(priority);.

표준 쿼리를 사용하는 경우 시도해야 할 또 다른 사항은 쿼리에서 구체화 된 뷰를 만들고 그로부터 타일을 만드는 것입니다. http://www.postgresql.org/docs/9.3/static/sql-creatematerializedview.html

이것이 할 일은 쿼리를 저장하는 테이블을 만드는 것입니다 (따라서 나중에 쿼리를 업데이트 할 수 있습니다). 하위 MV에 공간 인덱스가 있는지 확인한 다음 최대한 빨리 진행하십시오.

일어날 수있는 일은 공간 인덱스가 있지만 일부 데이터 만 선택하고 있기 때문에 더 이상 공간 인덱스를 사용하지 않는다는 것입니다 ...