Zwiększ szybkość buforowania płytek (TileStache)

Podaję kafelki wektorowe za pomocą TileStache , mam wszystko ustawione tak, jak chcę. Moje dane są przechowywane w Postgres i używam dostawcy VecTiles do obsługi kafelków GeoJSON .

Chcę buforować wszystkie moje kafelki, aby kafelki działały szybciej. Korzystam z tilestache-seed.py do zapasu mojej pamięci podręcznej. Używam seed-tilestache na kilku maszynach. Ziarno Tilestache działało naprawdę dobrze aż do poziomu powiększenia 13, ale po tym czasie buforowanie płytek trwa zbyt długo. Tylko dla Zoom Level 16 mam 5023772 kafelków do buforowania, i dostaję tylko 100 k-200 kafli dziennie na każdą maszynę.

Jak mogę szybciej buforować kafelki ? Czy istnieje sposób na dostrojenie pliku tilestache-seed.py i przyspieszenie jego tworzenia?

Aktualizacja: Próbowałem budować indeksy przestrzenne na moich tabelach (w kolumnie geometrii i kolumnach używanych do filtrowania danych przez klauzulę where) i nadal nie widziałem znacznego wzrostu szybkości kafelkowania. Przy tym tempie tylko Zoom 17 zajmie mi miesiąc, a tym razem będzie się wykładniczo zwiększać, gdy zbliżam się do Zoomu 21

Aktualizacja 2: Próbowałem również tworzyć zmaterializowane widoki i nie ma zauważalnej zmiany w wydajności, więc optymalizacja bazy danych nie działa. Myślę, że będę musiał zoptymalizować sam plik tilestache-seed.py lub opracować nowy sposób buforowania kafelków.

Informacje o sprzęcie Korzystam z procesów buforowania na 8 różnych komputerach, z których jeden to i7 z RAM 32 GB, a drugi to i3 z RAM 4 GB, ale oba dają mi prawie taką samą prędkość buforowania (około 100 000 płytek dziennie)

Powiedziałbym, że dla powiększenia większego niż 15, jeśli podzielisz swój obszar zainteresowania na mniejsze obszary (pole Ograniczenie), będziesz w stanie buforować je w znacznie krótszym czasie, uruchamiając wiele procesów na jednym komputerze.

Na przykład używasz powiększenia 16 (posiadającego 50 000,00 kafelków) na maszynie i zgodnie ze średnią szybkością buforowania kafelków proces ten zakończy się za około 40-50 dni. Powiedzmy, że podzieliłeś te kafelki na dwa i uruchomiłeś je jednocześnie na komputerze, wtedy będziesz w stanie buforować je w ciągu 20-25 dni, ponieważ proces inicjowania tilestache zużywa tylko około 30 procent procesora do pojedynczego buforowania kafelków i wiem o tym to dlatego, że mam ten sam problem raz i do pewnego stopnia to rozwiązało mój problem.

Nie wpłynie to na szybkość buforowania kafelków, jeśli uruchamiasz pojedynczy proces na komputerze lub wiele procesów, ale użycie procesora zostanie zwiększone.

Mam nadzieję, że to Ci pomoże.

Domyślnie shp2pgsql NIE tworzy indeksów. Musisz przejść, -Iaby wygenerować indeks przestrzenny. http://postgis.net/docs/manual-1.3/ch04.html#id435762

Sprawdź, czy tabela ma indeks, uruchamiając \d tablenamew psql. Na liście indeksów powinna znajdować się linia z „gist” (chyba że wybrałeś inny indeks) i nazwą kolumny geometrii.

Możesz dodać jeden po fakcie, patrz http://postgis.net/docs/manual-1.3/ch03.html#id434676 (nie pozwól, aby przestraszyła Cię notatka o stracie):

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

Ponieważ prawdopodobnie w zapytaniach używasz również nieprzestrzennych kolumn, zwykle chcesz utworzyć indeksy dla każdej kolumny używanej do wyszukiwania. Jeśli na przykład masz zapytanie podobne do SELECT * FROM roads WHERE priority = 3;tego, prioritya dodanie do niego indeksu znacznie przyspieszy:

CREATE INDEX idx_roads_priority ON roads(priority);.

Inną rzeczą do wypróbowania, jeśli używasz standardowego zapytania, jest utworzenie zmaterializowanego widoku z zapytania i zbudowanie z niego kafelków: http://www.postgresql.org/docs/9.3/static/sql-creatematerializedview.html

W ten sposób utworzysz tabelę, w której przechowywane jest zapytanie (abyś mógł potencjalnie zaktualizować je w przyszłości). Upewnij się, że masz wskaźniki przestrzenne na dziecięcych MV, a wtedy będziesz tak szybki, jak to możliwe.

Może się zdarzyć, że masz indeks przestrzenny, ale wtedy wybierasz tylko niektóre dane, co oznacza, że ​​nie używasz już indeksu przestrzennego ...