Збільшити швидкість кешування плитки (TileStache)

Я обслуговую векторні плитки за допомогою TileStache , у мене все налаштовано так, як я хочу. Мої дані зберігаються в Postgres, і я використовую постачальника VecTiles для обслуговування плиток GeoJSON .

Я хочу кешувати всі свої плитки, щоб плитки швидше служили. Я використовую tilestache-seed.py для нанесення кешу. Я біг tilestache насіння на кілька машин. Насіннєвий насіннєвий механізм справді добре працював, збільшуючи масштаб 13, але після цього занадто довго проходить кешування плиток. Тільки для масштабу 16 рівня у мене є 5023772 плитки для кешування, і я отримую лише 100k-200k плиток на день на кожній машині.

Як я можу зробити кеш плитки швидше ? Чи є спосіб налагодити tilestache-seed.py і зробити його швидше насіння?

Оновлення: Я спробував побудувати просторові індекси на своїх таблицях (на стовпці з геометрією та стовпцях, які використовуються для фільтрації даних через пункт де), і досі не спостерігав значного збільшення швидкості плитки. З цією швидкістю лише Zoom 17 займе у мене місяць, і цей час лише зросте експоненціально, коли я рухатимусь до Zoom 21

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

Інформація про обладнання Я запускаю процеси кешування на 8 різних ПК, один з яких - i7 з 32 ГБ оперативної пам’яті, а інший - i3 з 4 ГБ оперативної пам’яті, але вони обидва дають мені майже однакову швидкість кешування (приблизно 100 к плиток на день)

Я б сказав, що при збільшенні масштабу більше 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

З цього ви зможете зробити таблицю, в якій зберігається запит (щоб ви могли потенційно оновити його в майбутньому). Переконайтеся, що у вас є просторові показники на дитячих МВ, і тоді ви будете якомога швидше.

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