Назад | Перейти на главную страницу

Кеширование результатов БД - нужно знать, с чего начать

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

Как делает кеширование работает? Я видел что-то, называемое кешированием запросов, но выполняет ли этот запрос кеширования полученные результаты? Или просто запросы? И разве представление не является формой кеширования?

Я просто ищу толчок в правильном направлении. Проект будет использовать MySQL 5.1 для магазина, поэтому любые ссылки, которые могут прояснить мою путаницу, будут большим подспорьем. Обычный поиск в Google предоставил мне только кеширование запросов, и, учитывая отсутствие у меня знаний в этой области, я не уверен, следует ли мне идти в этом направлении.

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

Чтобы использовать его, вы можете либо включи это на вашем сервере my.cnf или используйте SQL_CACHE намек перед вашими запросами. Если он включен в my.cnf, вы можете указать MySQL не кэшировать результат, используя SQL_NO_CACHE перед вашими запросами.

Любая запись (INSERT, UPDATE, DELETE и т. Д.) В таблицу сделает недействительными все записи в кэше запросов, поступившие из этой таблицы.

Одна аномалия производительности с кешем запросов: он использует неэффективный алгоритм для поиска записей в кэше, поэтому создание большего кеша может привести к снижению производительности. Вы должны поэкспериментировать с его изменением с вашими собственными данными и профилями запросов, но в последний раз, когда я проводил этот эксперимент, я обнаружил, что около 256 МБ были оптимальным вариантом. Больше или меньше, и производительность ухудшилась. В руководстве предлагается "Десятки мегабайт"

Вы также можете реализовать кеширование вне MySQL, используя что-то вроде memcached. Это непрозрачно для приложения, поэтому вам придется добавить дополнительный код в свое приложение, чтобы выполнить поиск в memcached, а затем, если вы пропустите, выполнить поиск в базе данных и сохранить результат в memcached.

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

Вы можете создать другую таблицу для хранения кешированных результатов и по расписанию запускать дорогостоящие запросы, которые могут объединить несколько таблиц с лоты записей в них и выгружать записи в эту таблицу. Делая SELECT * из одной таблицы должно быть дешевле, чем выполнение SELECT, которое объединяет 12 разных таблиц, в каждой из которых есть миллионы записей. Хотя это не совсем удаляет работу с сервера БД, это должно уменьшить вычислительную нагрузку, поскольку нужно только выполнять дорогостоящие запросы по расписанию и заставлять ваших постоянных клиентов извлекать данные из таблицы кеша.

В качестве альтернативы для кеша, который полностью отделен от вашей БД, вы можете реализовать что-то вроде Redis. Это сохранит данные в памяти и должно быть очень быстрым, но в вашем приложении потребуется дополнительная логика, чтобы использовать это в качестве источника данных вместо реальной базы данных. Он также хорошо масштабируется - сеть Stack Exchange довольно эффективно использует его на своих сайтах.