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

13

Я обслуживаю векторные плитки с помощью 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 плиток в день)

Хасан Мустафа
источник

Ответы:

5

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

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

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

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

Шахзад Бача
источник
Это звучит как лучшее, что можно сделать на данный момент, я проверю, попробую это и посмотрю, что произойдет.
Хасан Мустафа
Это лучшее решение, которое я нашел до сих пор, хотя оно не идеальное (мне бы хотелось настроить файл tilestache-seed.py), оно работает достаточно хорошо.
Хасан Мустафа
2

По умолчанию 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);,

bugmenot123
источник
Я использовал плагин «PostGIS Shapefile и загрузчик DBF» в Postgres, он создал индекс: CREATE INDEX scale_geom_idx ON scale USING gist (geom). автоматически, когда я импортировал свои шейп-файлы. Стоит ли искать дополнительные индексы?
Хасан Мустафа,
У тебя много строк? Зависит ли ваше поколение векторных плиток от других атрибутов (например, отбор данных)?
bugmenot123
Да, и то и другое, у меня есть несколько строк в некоторых таблицах, моя таблица POI имеет около 975 тыс. Строк, и мой шейп-файл дорог был 8,5 ГБ до импорта в Postgres. Я использую запросы для фильтрации данных на основе уровней масштабирования: «10»: «ВЫБЕРИТЕ wkb_geometry AS геометрия , приоритет, имя, route_num ОТ дорог ГДЕ ПРИЛОЖЕНИЕ IN (5,4,3)» это запрос, который я использую для возврата дорог на уровне увеличения 10.
Хасан Мустафа,
Затем создайте индекс для каждого столбца, который вы используете в предложении WHERE. Вы также можете создавать многостолбцовые индексы, если это необходимо.
bugmenot123
Как мне поступить так, на каком основании я должен составить индексы?
Хасан Мустафа,
1

Еще одна вещь, которую можно попробовать, если вы используете стандартный запрос, - это создание материализованного представления из запроса и построение ваших плиток из этого: http://www.postgresql.org/docs/9.3/static/sql-creatematerializedview.html.

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

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

Алекс Лейт
источник
У меня есть 11 различных таблиц, которые я запрашиваю для создания своих плиток, значит ли это, что мне нужно будет создать 11 материализованных представлений? И мои запросы меняются в зависимости от уровней масштабирования.
Хасан Мустафа
Хорошо, если это не достаточно быстро, возможно, просмотр самых медленных операторов select сможет улучшить его. Обратите внимание, что вы можете сделать MV любого оператора выбора, в том числе из нескольких таблиц, если вам нужно.
Алекс Лейт
Так что, если я сделаю один MV на основе всех моих запросов, будет ли это работать?
Хасан Мустафа
Вы не можете сделать это. Сделайте один для самого медленного запроса, может быть, для одного уровня масштабирования, и посмотрите, сделает ли он меня быстрее.
Алекс Лейт
1
Ну, если это так, то оптимизация базы данных не поможет. Посмотри глубже
Алекс Лейт