Всё на самом деле зависит от того, что лично Вы подразумеваете под определением "сильно нагруженный портал" и от многих других факторов, в том числе, от используемого железа, версии MySQL (и/или его форка) и конечных параметров и настроек, и так далее. А так же, от "качества" администратора, которому вверят эту БД.
Субъективно, оценивая Ваш вопрос, я бы порекомендовал примерно следующее:
В "интернете", активно практикуется подход кэширования данных, не зависимо от того, какие это данные именно. Кэшируют всё, от отдельных блоков на сайте, до целых страниц вместе с cookie's, картинками и скриптами.
В пользу кэша говорят многие факторы. Против же кэширования обычно приводятся два основных аргумента:
а) Лишний расход оперативной памяти и/или жесткого диска
б) Кэш не стоит применять в тех случаях, когда ресурсозатраты (машинные) на кэширование выше, чем полученный эффект экономии от получения данных из кэша (обычно это те случаи, когда количество циклов записи меньше, или незачительно больше чем количество циклов чтения данных)
В вашем же случае, кэширование возможно в двух вариантах:
1. MySQL (в отличии от некоторых других БД) сам кэширует результаты запросов, причем делает он это по умолчанию, но параметры кэширования можно (и чаще всего нужно) настраивать дополнительно
2. Использование кэша с помощью специально разработанных для этих целей программ, например Redis или Memcached. PHP (и Laravel в т.ч., если мне не изменяет память) отлично дружат с ними.
Продолжая мысль, в Вашем случае, можно использовать один двух вариантов: либо ограничиться тем, что MySQL сам закэширует результаты многих запросов и сам будет брать их из кэша (причем это касается не только запросов относительно координат, но и почти всех остальных запросов),
либо, Вы можете использовать для хранения подобных данных (например, соотношения координат с результатами поиска) либо в таблицы в памяти (в MySQL есть тип таблиц "MEMORY"), либо хранить эти данные в Redis/Memcached/etc, глобально суть не изменится, скорость работы обоих вариантов (Таблицы в памяти vs Redis/Memcached) будет примерно сопоставимой.
Обновлять данные в хранилище можно на основе событий, реализация которых в достаточной мере присутствуют в Laravel. То есть, вкратце выглядит это так:
1. Обновляется (добавляется, изменяется) какой-то блок данных, связанный с фирмой, это в свою очередь порождает какое-то событие (одно из событий)
2. Слушатель событий получает данные и делает соответствующие изменения в кэше данных, таким образом, данные в кэше всегда актуальны (либо рассинхронизация данных довольно мизерная, в пределах примерно секунды) и никакие CRON'ы, которые бестолку будут мучить базу или кэш-хранилище - не нужны.
