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

[-=UncleByte=-]

Для кеширование в базе есть серьезные основания:
1. Сайт может функционировать на одном сервере, а БД быть на другом
2. На нагруженных сервера с большим объемом памяти можно вывести всю базу в оперативку и тогда отклик будет существенно быстрее, чем при работе с файлами

[Ивано++]

Сообщение от -=UncleByte=-

Для кеширование в базе есть серьезные основания:
1. Сайт может функционировать на одном сервере, а БД быть на другом

И в чем здесь подоплека?...

Сообщение от -=UncleByte=-

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

Думаю - здесь только пробовать...
На сайте typo3 - тоже про это говорится...

В общем второй вопрос - это очень сомнительный вопрос о том что лучше...
Для меня пока в любом случае лучше файлы (по крайней мере для сайтов из 10-250 страниц это уж точно!)

НИгде нет однозначного ответа о том, что лучше...
http://alexvolkov.ru/bd-bystree-fajjlov.html
http://hashcode.ru/questions/28006/p...B0%D0%B9%D0%BB ( сразу первый ответ - (
http://habrahabr.ru/qa/26867/

В общем-то проблема в том, что я делая рез.копии несколькох проетков - 1 хостинг - получаю по сущетству содержимое + мусор - и это уже достало...

//
Вот что еще пищут на хабре.
Кстати, файловая система — это тоже в некотором роде база данных.

[-=UncleByte=-]

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

Для бэкапов без мусора достаточно использовать sypex dumper - можно отметить содержимое каких таблиц не включать в дамп и все.

[dmartynenko]

Сообщение от -=UncleByte=-

Для кеширование в базе есть серьезные основания:
1. Сайт может функционировать на одном сервере, а БД быть на другом

А ведь суть кэша как раз в том, что бы максимально приблизить данные к потребителю. Канал/время отклика по сети к другому серверу чаще всего медленней чем к локальному диску (особенно если он SSD).

Сообщение от -=UncleByte=-

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

Тут есть нюанс. Таблицы типа MEMORY для кэшей сделать нельзя, так как там в ней нет типов данных BLOB и т.п., а VARCHAR(xxx) разворачиается в фиксированный CHAR(xxx) с соответствующим потреблением памяти.

Второй вариант - размещать сами базы на RAM-диске. А это весьма стремно - при перезагрузке теряются и базы и структуры и подключение их к MySQL

Так что при наличии большого объема памяти кэшировать лучше либо
в файлы на RAM-диск, либо на решения вроде memcached/redis.

[-=UncleByte=-]

Сообщение от dmartynenko

А ведь суть кэша как раз в том, что бы максимально приблизить данные к потребителю. Канал/время отклика по сети к другому серверу чаще всего медленней чем к локальному диску (особенно если он SSD).

У большинства отечественных хостеров собственно хостинг и сервер БД разнесены по разным серверам.

Сообщение от dmartynenko

Тут есть нюанс. Таблицы типа MEMORY для кэшей сделать нельзя, так как там в ней нет типов данных BLOB и т.п., а VARCHAR(xxx) разворачиается в фиксированный CHAR(xxx) с соответствующим потреблением памяти.

Второй вариант - размещать сами базы на RAM-диске. А это весьма стремно - при перезагрузке теряются и базы и структуры и подключение их к MySQL

Так что при наличии большого объема памяти кэшировать лучше либо
в файлы на RAM-диск, либо на решения вроде memcached/redis.

Я как раз и писал что при большом доступном количестве памяти проще всего вынести БД в эту самую память и таким образом и снизить время доступа к данным.

[Ивано++]

Эээээ...

Не думал, что когда нибудь такое скажу... НО мне даже очень понравилось кэширвоание на основе БД....
Как ни будь расскажу почему (единственный минус конечно когда на хостингах жмешь кнопку рез. копии, то база вся дампится)...

[Ивано++]

Даже smarty - кэш переведу на БД (с такой возможностью)...

[dmartynenko]

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

От себя приведу такой пример. На одном сайте в таблице 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 таблиц, получилось примерно одинаково.

[Ивано++]

Сообщение от dmartynenko

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

1) С точки зрения управления кэшированием на основе БД - можно сделать более сложную логику - в виде "матрешки". Где кроме того, можно еще и по определенным тэгам удалять отдельные кэши.

К примеру у нас есть новости на сайте:

Они выводятся в

новостях (список новостей с потраничной навигации)
сама новость
новость в карте сайта
блок последних новостей на главной странице
блок новости в слайдере на всех страницах...
кроме того, может быть в sitemap...

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

Хотя все таки думаю - что даже это все дело потянет хороший хостинг...

Подобную матрешку - пробовал реализовать на файлах...
Но, к сожалению, очень не гибко в сравнении с Файлами.

2) С точки зрения записи файлов на кэшах - не знаю почему - но мне показалось что это работает по скорость также как и на БД, а вот с позции манипуляций кэшем на файлах - как-то дольше - в т.ч. удаление.

А с точки зрения минусов - есть один минус, который по прежнему к сожалению вижу...
Таблицы кэширования лучше всего переводить в отдельную БД... Т.е. специально для кэшей держать отдельную БД...

А то при бэкапах хостинга обычно он бэкапит все в одну кучу...
А так было бы

1. Дамп Контента
2. Дамп Кэша (только структура)
3. FTP