Увеличение скорости кэширования тайлов (TileStache)

Я обслуживаю векторные плитки с помощью TileStache , у меня все настроено так, как я хочу. Мои данные хранятся в Postgres, и я использую провайдер VecTiles для обслуживания плиток GeoJSON .

Я хочу кэшировать все свои тайлы, чтобы они быстрее работали. Я использую tilestache-seed.py для заполнения моего кэша. Я использую кафель на нескольких машинах. Tilestache-seed работал очень хорошо до 13-го уровня масштабирования, но после этого кеширование занимает слишком много времени. Только для Zoom Level 16 у меня есть 5023772 тайлов для кэширования, и я получаю только 100k-200k тайлов в день на каждой машине.

Как я могу ускорить кеширование тайлов ? Есть ли способ точной настройки tilestache-seed.py и сделать его быстрее?

Обновление: я попытался создать пространственные индексы для своих таблиц (для столбца геометрии и столбцов, используемых для фильтрации данных с помощью предложения where), и до сих пор не наблюдал значительного увеличения скорости листов. При такой скорости только Zoom 17 займет у меня месяц, и это время будет увеличиваться только в геометрической прогрессии, когда я перейду к Zoom 21

Обновление 2: я также попытался создать материализованные представления, и никаких заметных изменений в производительности не произошло, поэтому оптимизация базы данных не работает. Я думаю, что мне нужно будет оптимизировать сам файл tilestache-seed.py или разработать новый способ кэширования плиток.

Информация об оборудовании Я запускаю процессы кэширования на 8 разных компьютерах, один из которых - i7 с оперативной памятью 32 ГБ, а другой - i3 с оперативной памятью 4 ГБ, но они оба дают мне почти одинаковую скорость кэширования (примерно 100 000 плиток в день)

Я бы сказал, что при увеличении, превышающем 15, если вы разделите интересующую вас область на более мелкие области (ограничивающий прямоугольник), вы сможете кэшировать их за гораздо меньшее время, запустив несколько процессов на одной машине.

Например, вы используете масштабирование 16 (имеющее 50 000,00 плиток) на машине, и в соответствии со средней скоростью кэширования плитки этот процесс будет завершен примерно через 40-50 дней. Допустим, вы разбили эти листы на две и одновременно запустили их на компьютере, после чего вы сможете кешировать их через 20-25 дней, потому что для процесса кэширования одной плитки в процессе заполнения тайлов используется только около 30 процентов вашего процессора, и я знаю, это потому, что у меня одна и та же проблема, и до какой-то степени это решило мою проблему.

Это не повлияет на скорость кэширования плитки, если вы запускаете один процесс на компьютере или несколько процессов, но использование ЦП будет увеличено.

Я надеюсь, что это поможет вам.

По умолчанию shp2pgsql НЕ создает индексы. Вам нужно пройти, -Iчтобы он генерировал пространственный индекс. http://postgis.net/docs/manual-1.3/ch04.html#id435762

Проверьте, имеет ли ваша таблица индекс, запустив \d tablenameв psql. В списке индексов должна быть строка с «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, и тогда вы будете как можно быстрее.

Может случиться так, что у вас есть пространственный индекс, но затем вы выбираете только некоторые данные, что означает, что вы больше не используете пространственный индекс ...