25 августа 2018 в 22:24
Всем привет. Вот чем больше пользуюсь друпал, тем он больше мне нравится.
Но, как бороться с огромным размером базы? На сайте предполагается большое количество статей, а сейчас, пока там всего 50 материалов база уже весит 300 мб. Через год она будет 3 гига весить.
| Вложение | Размер |
|---|---|
 screenshot_2.png | 20.39 КБ |
Комментарии
Причина - Drupal 8. Но, он все равно лучше чем Джумла.
Вы скриньте не размер БД, а какие таблицы больше жрут. Ну и сайт покажите. Если у ноды много полей - действительно БД разрастается.
Она разрастается количеством таблиц, а не размером.
А сколько из этих 300М занимает таблица watchdog?
таблица watchdog занимает 1.1 МБ
А покажите топ 10 таблиц по убыванию их размера
полей 8 шт. Установлены только парочка базовых модулей для ЧПУ и мета тегов
тут все, размер чего в мегабайтах.
os_cache_page реально самая жирная?
Итак выходы для вас:
1. Не обращать внимания.
2. Drupal 7. Воспринимать ее не как устаревшую, а как стабильную и малотребовательную систему.
3. Backdrop. Уступает D7 по кол-ву модулей и доков.
4. Хостинг https://drupal.ru/node/135166 - и пусть за 200 рублей ваша БД будет их проблемой.
Еще Асквия-хостинг есть но там сильно дорого.
Хостингом от Acquia мне приходилось пользоваться.
Ну, мягко выражаясь - не возбудил он меня.
А с учетом стоимости - можно взять гораздо больше ресурсов за эти деньги.
Большое спасибо за ответы.
Да, os_cache_page самая большая.
На счет 7-ки, я знаю, но так как только изучаю Друпал, всё что читал, все советуют сразу с 8 начинать, если не знаком Drupal вообще.
Васёк просто у нас особенный путь имеет.
Не слушайте его.
У вас вполне нормальная картина.
Друпал загнал всё в кеш, всё работает.
300 мегайбайт в админке, возможно, считается по размеру файлов базы данных, они во-первых, всегда больше, во-вторых, в зависимости от настроек сервера, они могут сохранять размер несмотря на то, что данные уже удалены.
ок. Спасибо. Буду мониторить.
Считаю, что D8 среда для разработки крупного сайта или большого количества мелких, одной командой разработчиков. Расходы на сервер в этом случае мало волнуют (только на сервериста).
Рядовой заказчик не поймет, зачем нужно морочить голову с композером (главное, без него многие модули не поставить) + Гитом, треккером задач, внутренним чатом (не главное но на крупных проектах часто так).
Это сугубо мое мнение. Вам решать самому как жить и работать.
Ты в очередной раз смотришь с точки зрения собственной лени и постишь дикие страшилки.
Лень - двигатель прогресса!
А основной посыл: не подходит D8 для мелких сайтов сайтоводов обыкновенных.
Без аргументации только бабки на лавке в это поверят.
Аргументы: размер БД, разность структуры папок с композером и без, привлечение программистов туда где лучше без них (webform_calculator).
Ну да, у меня особоенный путь.
300 мегайбайт - нормально. Кто ж говороит, что ненормально. У меня и пол гига на D8 относительно мелкие сайты.
ого, нет, мне о таком и думать то..... тут просто статейник, для души так сказать (тут чисто хобби).
возможно так, но я никогда не сталкивался с такими размерами баз, вот решил спросить, мало ли накосячил
Ну, с кешем уже разобрались, я бы вынес его в Redis/Memcache - и побыстрее будет, и базе полегче станет.
Если память позволяет, разумеется.
Еще как-то многовато записей в таблицах поиска, на 50 нод-то.
В коробке, сущности поля и связи нормализованы, вопросы больших объёмов и оптимизации стоит решать по мере возникновения.
optimizedb