Всетаки - кэширование с использованием БД - это очень не удобно!

dmartynenko · 02.07.2013, 13:11

Вы лучше напишите "почему". Обещали

От себя приведу такой пример. На одном сайте в таблице RealURL encode cache больше миллиона записей, в decode cache раза в два меньше. По статистике запросы на выборку из этой таблицы по Primary Key регулярно пишуться в лог относительно медленных запросов (наряду с выборками из tt_news), для этого в t3lib_db добавлен небольшой код.

Любая операция со страницей в BE (иногда приходится делать на рабочем сайте) ведет к операции DELETE FROM ... WHERE pid = xx

Если делать таблицу MyISAM, то под нагрузкой такая операция практически вешает сервер на 3-7 минут. Если делать InnoDB (как того рекомендует автор Дмитрий Дулепов) то якобы операция удаления не должна блокировать таблицу и все должно продолжать работать. На практике серверу еще хуже. Так как пока очень долго идет операция удаления (десятки минут), то все другие операции с таблицей очень сильно замедляются и LA сервера растет и растет. Даже если вручную снять этот висящий запрос на удаление, то еще пару десятков минут продолжает висеть в списке процессов MySQL некая операция "freeing items" и тоже все тормозит.

Так что пока вы кешируете в таблицы что-то небольшое и немного - это удобно. Но в реальной жизни на крупных сайтах все не так радужно.

Мне нравиться Redis - с одной стороны использует память как и memcached, с другой данные уже не влезающие в память пишутся на диск, а не просто удаляются.

Конечно в Redis и в memcached единственная проблема которая не так красиво решается как в СУБД - это тэгирование записей кэша. Ну я тут не стал выдумывать очередной велосипед и храню пары ключ-тэг в MySQL.MEMORY таблице. Когда-то видел сравнение скорости работы memcached vs MEMORY таблиц, получилось примерно одинаково.

Опции темы
Версия для печати Отправить по электронной почте
Опции просмотра
Линейный вид Комбинированный вид Древовидный вид

Похожие темы
Тема	Автор	Раздел	Ответов	Последнее сообщение
Cлишком сложно показалось?	carlos	Вопросы выбора CMS	5	04.07.2007 16:37

02.07.2013, 13:11	#14
dmartynenko Senior Member Регистрация: 20.07.2007 Адрес: Беларусь, Минск Сообщений: 957	Вы лучше напишите "почему". Обещали От себя приведу такой пример. На одном сайте в таблице RealURL encode cache больше миллиона записей, в decode cache раза в два меньше. По статистике запросы на выборку из этой таблицы по Primary Key регулярно пишуться в лог относительно медленных запросов (наряду с выборками из tt_news), для этого в t3lib_db добавлен небольшой код. Любая операция со страницей в BE (иногда приходится делать на рабочем сайте) ведет к операции DELETE FROM ... WHERE pid = xx Если делать таблицу MyISAM, то под нагрузкой такая операция практически вешает сервер на 3-7 минут. Если делать InnoDB (как того рекомендует автор Дмитрий Дулепов) то якобы операция удаления не должна блокировать таблицу и все должно продолжать работать. На практике серверу еще хуже. Так как пока очень долго идет операция удаления (десятки минут), то все другие операции с таблицей очень сильно замедляются и LA сервера растет и растет. Даже если вручную снять этот висящий запрос на удаление, то еще пару десятков минут продолжает висеть в списке процессов MySQL некая операция "freeing items" и тоже все тормозит. Так что пока вы кешируете в таблицы что-то небольшое и немного - это удобно. Но в реальной жизни на крупных сайтах все не так радужно. Мне нравиться Redis - с одной стороны использует память как и memcached, с другой данные уже не влезающие в память пишутся на диск, а не просто удаляются. Конечно в Redis и в memcached единственная проблема которая не так красиво решается как в СУБД - это тэгирование записей кэша. Ну я тут не стал выдумывать очередной велосипед и храню пары ключ-тэг в MySQL.MEMORY таблице. Когда-то видел сравнение скорости работы memcached vs MEMORY таблиц, получилось примерно одинаково.