Производительность с использованием информации о местоположении и фильтров близости
Я создаю сайт, где каждый фрагмент контента геокодирован с указанием широты и долготы. Информация будет отображаться в зависимости от близости к местоположению, выбранному пользователем. Похоже, было бы быстрее, если бы информация отображалась на основе аргументов города или штата, потому что тогда представления можно кэшировать. Если для каждого просмотра страницы требуется поиск узлов по близости по координате lat/lng, которую никогда не будут использовать два пользователя, я думаю, что база данных будет сильно расширена.
Поиск по близости - это хорошо, но как мне показать другие узлы в контексте близости, будь то штат, город, город или страна?
Какой будет информационная архитектура?
1 answers
Я отвечу на первую часть вашего вопроса о кэшировании мягким предупреждением и советом...
Я пробовал кэшировать поиск по местоположению, и это быстрый способ получить ОГРОМНУЮ (медленную) таблицу cache_views_data.
Причина та же, что и необходимость кэширования; существует множество перестановок широты и долготы, поэтому каждый новый запрос будет добавляться в кэш. В зависимости от скорости, с которой у вас появляется новое содержимое или обновления, кэш будет либо:
- стать огромным поскольку запросы хранятся для множества различных комбинаций lat/long. Это произойдет при длительном времени кэширования.
- быть довольно большим, но редко попадать, потому что время кэширования достаточно короткое, чтобы страницы отображали свежие данные.
Супер-огромные таблицы кэша вполне могут быть таким же ударом по производительности, как если бы база данных просто вычисляла, что находится поблизости. Поиск может быть в порядке, но вставки и удаление старых данных, безусловно, замедлят работу вашего сервера баз данных.
Один подход Я подумал, но еще не реализовал, чтобы сделать аргументы широты/долготы менее детализированными, округлив значения до меньшего количества знаков после запятой. Таким образом, вы можете получить гораздо более высокую скорость попадания в кэш за счет небольшой точности. Например, вероятность того, что (51.1, 0.9) пострадает от нескольких пользователей, гораздо больше, чем (51.123456, 0.887744). Количество десятичных знаков и, следовательно, потеря точности полностью зависят от вас.
Вы можете либо реализовать крюк представлений, чтобы изменить просматривает аргументы или использует Просмотры PHP для добавления пользовательского кода к вашим аргументам, который позволяет округлять их в самом представлении.