Нетривиальное кеширование запросов геолокации

Question

Сначала я должен сказать, что я действительно новичок в кешировании, поэтому, пожалуйста, уточните любое объяснение и постарайтесь ответить на мой вопрос, если мой вопрос глуп.

У меня есть сервер с довольно ограниченными ресурсами, поэтому я действительно заинтересован в том, чтобы максимально эффективно кэшировать db-запросы. Моя проблема заключается в следующем:

У меня есть MYSQL DB с таблицей для геолокации, есть столбцы (lat и lng) - я только проиндексировал lat, так как запрос всегда будет иметь оба значения lat и lng, и только 1 индекс может быть эффективно использован для моего понимания ( ?).

Запросы очень чередуются в координатах, таких как

select lat, lng 
where lat BETWEEN 123123123 AND 312412312 AND lng BETWEEN 235124231 AND 34123124

, где длинные числа, которые являются границами запроса BETWEEN, постоянно меняются, поэтому есть способ кешировать это разумным способом, так что кэш не должен быть полным совпадением запроса, но Значения предыдущих между запросами могут быть сохранены против нового, чтобы сэкономить некоторые ресурсы БД?

Надеюсь, вы получите мой вопрос - если нет, пожалуйста, спросите.

Большое спасибо

Обновление 24.01.2011

Теперь, когда я получил какой-то ответ, я хочу знать, каким будет самый эффективный способ запроса.

1. Будет ли запрос Between со значениями int выполняться быстрее или
2. будет ли вычисление радиуса с точечными значениями выполняться быстрее

если 1. то как будет выглядеть оптимальный индекс?

Answer 1

Я думаю, что для значительного улучшения вам нужно лучше охарактеризовать ваши данные. Если у вас есть данные, которые равномерно распределены по долготе и широте, без корреляции, и если ваши запросы распределены одинаково и независимы - вы застряли. Но если ваши данные или ваши запросы кластеризуются интересными способами, вы можете обнаружить, что можете вводить новые столбцы, которые ускоряют хотя бы некоторые запросы. Если большинство запросов происходит в некотором жестком диапазоне, возможно, вы можете отложить эти данные в сторону - добавить флаг, связать его с какой-либо другой таблицей, даже поместить часто запрашиваемые данные в свою собственную таблицу. Можете ли вы рассказать нам больше о данных?

Answer 2

Если ваша таблица MyISAM, вы можете использовать Point тип данных (см. этот ответ для более подробной информации)

Если вы не желаете или не можете использовать пространственные индексы, вам нужно два отдельных индекса:

CREATE INDEX ix_mytable_lat_lon ON mytable (lat, lon)
CREATE INDEX ix_mytable_lon_lat ON mytable (lon, lat)

В этом случае MySQL может использовать index_intersect над этими индексами, что иногда быстрее, чем простая фильтрация с одним индексом.

Даже если это не так, он может выбрать более селективный индекс, если есть два из них.

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

Это избавит MySQL от необходимости чтения данных с диска.

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