Что использовать при кешировании запросов MySQL в PHP

Question

[Павел Зайцев]

Есть необходимость сделать в PHP кеширование выполняемых запросов к MySQL. Но встроенное кеширование в MySQL не подходит по ряду причин. Одна из главных — сброс кеша при любом изменении таблицы — это критично, так как разрабатываемая система многопользовательская. Я уже задумывался, чтобы хранить результаты тяжелых запросов в файлах на сервере и при очередном выполнении запроса (с привязкой к пользователю системы) проверять, если уже такой запрос был, то брать из файла. Но в этом случае придется решать проблему именно отслеживания изменений в таблице.
Можете посоветовать какое-то оптимальное кеширование SQL запросов со стороны PHP? Или может есть ещё какое-то интересное решение?

Заранее благодарен за ответы!

Answer 1

[skvot]

Еще почитайте про redis. Сам его использую для кеширования. Может лучше подойдет вашему проекту, чем мемкеш.

Comments

[Павел Зайцев]

Спасибо!) Тоже взял на заметку для изучения — как раз впереди пара выходных.

Answer 2

[Vampiro]

У вас ложная информация по поводу главной причины, которая не дает Вам использовать нормальный вариант, но не это главное. Делайте таблицы-агрегаты. Посмотрите запросы и постройте индексы. Заполняйте их данными после перевода договоров в стабильные статусы. Если у вас есть лишняя оперативка — лучше отдать ее правильно спроектированной БД, чем скармливать бесполезному в этом случае мемкешу, например.
Договора заканчиваются, периоды закрываются, эти данные становятся статикой и хорошо берутся из агрегатов. Вариант с кешем хорош при частых обращениях к одинаковым данным. Ваши пользователи чаще загружают один и тот же договор, или смотрят последовательно разные? Наверняка последнее, а вы забьете оперативку договорами, которые уже не нужны пользователю. Повторюсь — лучше забить эту оперативку индексами.

Но для общего развития изучить все, об чем выше уже рассказали — мегаполезно.

Comments

[Павел Зайцев]

Спасибо за ответ! Да, я и хочу попробовать именно агрегирование финальных данных, которые уже с большой вероятностью не будут меняться, но пока изучаю тему, поэтому все впереди))

[DragoN DragoN]

А что делать, если сайт является новостным и каждый блок на главной странице делает по несколько запросов? Как лучше в данном случае оптимизировать вывод? Таким образом я пришел к memcache и локальному хранению данных в файлах. Нагрузка упала, но при тестирование через apache инструмент ab, показывает не очень хорошие результаты...

Answer 3

[edogs]

Одна из главных — сброс кеша при любом изменении таблицы — это критично, так как разрабатываемая система многопользовательская. Я уже задумывался, чтобы хранить результаты тяжелых запросов в файлах на сервере и при очередном выполнении запроса (с привязкой к пользователю системы) проверять, если уже такой запрос был, то брать из файла. Но в этом случае придется решать проблему именно отслеживания изменений в таблице.
— Получается немного нелогично. С одной стороны Вас беспокоит сброс кэша при любом изменении таблицы, с другой стороны Вы говорите что на кэш изменения в таблице влияют и их надо отслеживать.

Один из относительно легких вариантов для кэша, это memory таблица в mysql, куда складируются либо все данные которые часто выбираются либо ИД для их выбора из основных таблиц. Плюс по сравнению с 3rd-party решением тут то, что закэшить можно не прогоняя лишние данные через php и сеть, просто insert into select from — в большинстве случаев. Это во-первых. А во-вторых, триггерами при изменениях основной таблицы можно настроить апдейт кэширующей, более гибко чем просто тупой кэш запросов.
Ну и наконец если база относительно небольшая, то innodb + большой размер пула/кэша — тогда вообще все в памяти будет постоянно считай.

Comments

[Павел Зайцев]

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

Про Memory таблицу спасибо, почитаю, но, если я правильно понял, то в такой таблице фиксированный размер полей, и соответственно, для кеширования результатов, возвращающий разный набор полей необходимы свои таблицы?

[edogs]

Не фиксированный полей, а только поля с фиксированной длиной. Char/int — можно, varchar/longtext — нельзя и т.д…
В остальном — если речь о том, что Вам нужно вытаскивать определённые данные о пользователе, то вопрос в том — какие Вам данные о пользователе нужны? Может проще ввести в таблице пользователей поле типа text и аггрегированные данные (баланс там, очки, карма) хранить там? Вместо огорода с отдельными кэшами? Выборка из таблицы пользователей по ID будет не сильно медленнее чем кэши.

[Павел Зайцев]

Нет, данные довольно сложные. Разрабатывается система документооборота. И запрос, который выбирает элементарно договора организации, получается сложный. Так как необходимо так же выбрать счета к договору, подсчитать сумму оплат по счетам, и прочие цифры. Договоров может быть весьма много, порядка 100 и больше. И чтобы выполнить такой запрос, БД требуется немаленькое время. Да и данные по объему выходят за рамки стандартных Char и Int. Поэтому хочется сохранять именно результат выборки для конкретного пользователя, чтобы потом просто по запросу его вытаскивать без обращения к БД лишний раз.

Answer 4

[Вячеслав Плиско]

Для кеширования в php, если система нераспределённая, то оптимальнее использовать акселераторы типа apc (apc_fetch,....) или шаренную память shmop.
Редисы и мемкешы нужны если доступ к кешу должны иметь несколько серверов, а так это не самый лучший вариант, так как это фактически отдельные сервера, пускай и очень быстрые, но с соотвественными летенси при обращении.

Comments

[Павел Зайцев]

О, спасибо, про APC слышал, на сервере к тому же уже установлен, нужно будет попробовать. Спасибо большое!

[Вячеслав Плиско]

Лучше польваться обёртками коих масса. Они как правила позволяют менять и енжин (фалы, фзсб memcache), дают удобный интерфейс и главное — поддерживают теги, что очень удобно при инвалидации кеша.

Answer 5

[FanatPHP]

Вам не нужно никакое кэширование.
Вам нужно оптимизировать свои запросы.
«100 договоров и больше» — смешная цифра. По такому количеству любые выборки должны считаться предельно быстро, в сотые доли секунд.
Даже если тупо выбирать все сто договоров в скрипт и считать руками.

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

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

Answer 6

[Ents]

Я советую использовать memcache
Нужно только четко понимать каким образом делать инвалидацию кеша

Comments

[lumega]

Не понятна структура кеша. Но в целом 2 простых решения:
1. Чтобы вписаться в условия обычных виртуальных хостингов — таблица MYSQL типом MEMORY (чтобы промежуточные данные хранить в памяти)
2. если свой сервер, то MEMCACHE

Answer 7

[enchikiben]

Memcache чем плох?

Comments

[Павел Зайцев]

Да собственно ничем, просто не работал с ним) Теперь буду читать про него, спасибо за совет!

Answer 8

[Wott]

Надо думать о корректной схеме кеширования.
У вас не меняются данные, но вы хотите заново строить ответ сервера со старым данными? может лучше кешировать сам запрос?

Далее надо думать сколько живет кеш и как его инвалидировать. Есть простые схемы типа короткого внешнего кеша ( например nginx ), которые разгружают движек и базу. Есть более сложные — движек сам создает файловый кеш и удалает/пересоздает его по изменению контента ( самый простой — скидывать результаты запросов в файлы, которые лежат в соответвии с запрошенным урлом и сделать правила для apache, которые будут отдавать файлы вместо запуска движка, если они есть. )

Использовать еще базу типа memcached для кеширования запросов в безу или даже в движек — это явный фейл архитектуры :) Только с целью кеширования лучше отдать память в кеш io. Разумное использование начинается с хранения отдельных данных, типа сессий пользователя, которые подмешиваются в закешированную страницу включениями — типа разделение долгоживущих данных и короткоживущие сессии.

Comments

[Павел Зайцев]

Ну да, согласен, тут нужно хорошо продумать систему кеширования. Теперь понял, что memcache не панацея) Углублюсь в эту тему и попробую найти оптимальный вариант. Может не сразу, но постепенно тоже хорошо.

Answer 9

[gro]

насколько критично? как влияет на это то, что система многопользовательская?
кэшировать именно по запросам? может конкретные данные кэшировать?

>Но в этом случае придется решать проблему именно отслеживания изменений в таблице.
так mysql именно это и решает, а вам это критично.

Comments

[Павел Зайцев]

Видимо немного не правильно выразился. Придется отслеживать изменения, связанные с конкретным пользователем, а не во всей таблице полностью.
Система многопользовательская и данные выводятся из одной таблицы, но только привязанные именно к этому пользователю. Поэтому если один пользователь изменил что-то у себя в данных, кеш другого пользователя не должен сбрасываться. А уж тем более кеш всех пользователей (при сбросе кеша встроенной системеы кеширования MySQL).

Answer 10

[MealstroM]

Если у вас кеш сбрасывается при любом обновлении таблицы — вы используете MyISAM а не InnoDB, верно?
Кеш в Мускуле работает примерно так: при получении запроса БД делает хеш этого запроса (сам запрос + данные по строках какие будут задействованы) если были изменения — если хеш совпадает — то через кеш, иначе — делать в чистую. InnoDB позволяет делать проверку на уровне строк по состоянию на начало транакции. Возможно єто поможет. Так же стоит учесть длинну кеша и накладные расходы на его поддержание.

Comments

[Павел Зайцев]

Да, таблицы MyISAM. Про кеш в мускуле прочитал, он 100% не подходит под мою задачу. А вот про InnoDB не знал, спасибо большое за совет, почитаю!)