26 декабря 2023 в 19:10
Всем привет!
На одном из хостингов столкнулся с проблемой ограничения размера БД.
Проблему решили покупкой услуги в другом месте. Но меня не оставляет вопрос, можно ли разнести таблицы по разным базам?
Прошерстил в инете, кроме мультисайтинга ничего толкового не нашел. Может есть какие настройки для settings.php ?
В конкретном случае очень "тяжелая" одна из таблиц search_api, но я бы и таблицы кэша перенес в отдельную БД.
Комментарии
В старых версиях Drupal (< 8.2) в settings.php можно было указывать разные префиксы для разных таблиц, выглядело это так:
'default' =>
array (
'default' =>
array (
'database' => ... ,
'username' => ... ,
'password' => ... ,
'host' => ... ,
'port' => ... ,
'driver' => ... ,
'prefix' => array(
'default' => 'префикс для всех таблиц по умолчанию',
'tablename' => 'someprefix',
),
),
),
);
Если в префиксе использовать точку, то все что слева от неё, будет считаться именем БД, и чтобы вынести отдельную таблицу в другую БД, надо было указать в settings.php так:
'tablename' => 'anotherdbname.',
),
и это работало.
Но начиная с 8.2+ эту лавочку прикрыли, и оно больше не работает.
Лучшим решением тут будет использовать другой бекэнд для Search API, вместо Search API DB - Solr например.
А так же вынести кэш в память - Redis или Memcache
Это потребует установки и настройки серверного ПО (solr, redis, memcache), так что хостинг скорее всего в любом случае придется сменить.
Спасибо за ответ! Если "лавочку прикрыли", можно этот вопрос отложить. Возможно что-то в будущем изменится.
Другой поисковый бэкэнд можно было бы, да хостинг не позволяет (аренда сервера пока в планы не входит). Memcache и Opcache - это уже как база для Drupal 10+ и они на хостинге есть и включены (перенос таблиц кэша привел для примера).
Просто подумалось, в тарифе простаивает 27 возможных баз со своими выделенными процессами, ограничениями и т.п. Хорошо бы раскидать... Ну нет, так нет. Что поделать.
Есть отдельные solr-хостинги. Я как-то пробовал пользоваться солром на удаленном сервере по сети - в общем-то, задержки там минимальны и не критичны.
Плюс солра не столько в разгрузке БД, сколько в полнотекстовом поиске с учетом морфологии и синонимов, если солр правильно сконфигурирован, разумеется.
Как вариант, думал прописать в settings.php вторую БД, вручную перенести таблицы в нее и в хуках переключать БД. Не пробовал, но по логике должно работать. И опять же, это конкретно под созданные таблицы - небольшое изменение и все полетит.
Если таблица Search API сильно большая, лучше поставить Apache Solr
В общем решил пока немного "заморочиться", пока нет разделения по базам.
Поиск осуществляется по терминам с кучей полей.
1 Создал субдомен (мультисайтинг), естественно со своей таблицей. Перенес словарь и его структуру (те поля, которые участвуют в поиске.)
2. С помощью views_data_export выгрузил с основного термины с полями. С помощью feeds залил на субдомен.
3. Настроил поиск на субдомене.
4. На основном по роуту перехватываю все url.query_args тяну данные file_get_contents с субдомена и собственно вывожу.
5. На основном в hook_taxonomy_term_presave, hook_taxonomy_term_insert прописал создание/обновление файла csv с полями для обновления. На субдомене фидом раз в 6 часов подтягиваю этот файл. + прописал на хостинге задачу крон, чтобы открывал раз в три часа основную страницу субдомена, чтобы крон запускался.
Можно использовать hook_taxonomy_term_update. Использовал _presave, поскольку уже есть, но тут с проверкой
<?php if(!$entity->isNew()){moduleName_create_share_csv($entity);
}?>