6 февраля в 12:24
Приветствую специалистов в по big data, и базам данным 
Есть сайт с 120 тыс статей. Периодически пропадает место на сервере. Хостинг не предлагает докупить место, а предлагает лишь переехать на другой сервер, что уже несколько больше по деньгам чем 2 чебурека.
Размер БД сайта 2.3 ГБ. Но вот таблицы кеширования иногда неприлично выростают.
+-------------------------------------------------+-----------+
| Table | Size (MB) |
+-------------------------------------------------+-----------+
| cache_page | 11808.78 |
| cache_render | 4111.88 |
| cache_dynamic_page_cache | 1770.48 |
| search_index | 1283.00 |
| cache_data | 1110.88 |
| node_revision__body | 896.55 |
| node__body | 894.55 |
| Table | Size (MB) |
+-------------------------------------------------+-----------+
| cache_page | 11808.78 |
| cache_render | 4111.88 |
| cache_dynamic_page_cache | 1770.48 |
| search_index | 1283.00 |
| cache_data | 1110.88 |
| node_revision__body | 896.55 |
| node__body | 894.55 |
Насколько это нормально и как бороться.
Слышал решение, что выполняется команда очистки кеша раз в сутки, это приемлимо?
Комментарии
В твоем случае нужно положить кэш в redis. Это уменьшит вес БД (а это важно для бэкапа, например).
В Drupal 8/9/10 нет очистки кэша. Есть cache rebuild, то есть перестройка заново. Соответственно размер кэша ты не уменьшишь этим действием
Есть же кнопка в admin/config/development/performance Очистка кеша. Нажимаю - таблицы уходят. Тоже самое через drush cr. Значит уменьшаю... Или как?
Зачем в редис..Оперативная память нынче дорогая. Нужно настроить файловый кеш. Пускай на диске лежит.
https://www.drupal.org/project/filecache
Не...бигдата..- это когда на планете живет 9 миллиардов а тебе говорят..Умножь это число на квадриллион и посчитай пуговицы на каждом левом ботинке..
В итоге ты узнаешь сколько пуговиц будет на левом ботинке через миллиард лет на планете если население продолжит увеличиваться такими темпами
И насколько меньше файловый кеш, чем записи в БД?
Просто это может быть удобнее. Но это не быстрее, и не компактнее.
Затем, например, что будет ограничен размер и будет лишнее вымываться. Часто нет смысла хранить огромный кеш всего, что обходят иногда боты... В общем, случаи бывают очень разные, и нет одного хорошего рецепта кеширования.
Точно? А как же кнопка Clear all caches на странице /admin/config/development/performance ?
Да ладно? То есть drush cr заново перегенерит все вьюхи со всеми возможными сочетаниями значений всех параметров? Это ж он месяц будет крутиться. Сомневаюсь я.
Ну по крайней мере я смотрел размер таблиц кэша в phpmyadmin и после сброса кэша размер таблиц не был равен 0, как ожидалось, а был примерно таким же как и до сброса кэша
А ты смотри не мегабайты в таблицах, а строки. Есть в InnoDB такой прикол, что если таблица разрослась, то сколько её не чисти, она всегда будет занимать места по максимуму, пока не пересоздашь таблицу заново.
Чаще всего кэш пухнет из-за того, что крон не запускается. Если крон запускать, то он будет удалять протухшие записи из кэша.
У меня были другие результаты - размер таблиц падал практически до нуля, и бэкап, который перестал помещаться на диске, внезапно стал помещаться.
Хорошо, в 2-х словах: что такое redis? Это что: хранилище данных вне сервера рабочего сайта?
Это хранилище вне базы данных твоего сайта. Но так же в оперативной памяти.
А ещё можно кэш как файлы положить. Там выше модуль скидывали
Ок, пробую filecache.
По информации со страницы модуля добавляю в settings.php
$settings['cache']['default'] = 'cache.backend.file_system';и получаю
The website encountered an unexpected error. Please try again later.drush ws выдает:
You have requested a non-existent service "cache.backend.file_system".
Что я не так делаю?