Задумался на тему мультисайтинга для одного своего проекта. Для начала — решил выбрать, какие таблицы стоит сделать общими. Для чего? Экономия места, меньше бэкапы, а также удобство администрирования — при объединении таблиц с локализацией достаточно один раз поменять перевод, а не обновлять его на каждом сайте.
Ниже расписано чуток про каждую таблицу, а также примечания, стоит ли её делать общей для всей связки сайтов, или нет.
Таблицы
access — доступ пользователей к сайту. Блокировка по IP, имени пользователя, e-mail. Предпочитаю совместить, т.к. чаще всего не использую блокировки вообще. Для крупных сайтов можно разделить.
authmap — таблица для внешних аутентификаций (LDAP, OpenID). В ней указывается соответствие локального имени юзера (uid в таблице users), внешнего (vasya_pupkin@drupal.org), и модуля, который выполняет аутентификацию. Т.к. не использую внешнюю аутентификацию — совмещаю, т.е просто пустая таблица. Но если используется — [2].
blocks — таблица блоков у сайта. Название блока, где отображается, вес, и т.п.
blocks_roles — доступ ролей к блокам.
boxes — текст (код) самого блока.
cache и cache_* — кэши.
comments — комменты. [1]
files и file_revisions — файлы. [1]
filters и filter_formats — форматы ввода. За редким исключением (на каком—то сайте нужна вики—разметка, а на других — нет) — можно совместить.
flood — таблица, в которой хранится инфа, когда юзер посылал сообщение администрации сайта через модуль Contact. Используется крайне редко, чаще замещается модулем feedback.
history — используется для форумов, последние непрочитанные сообщения. Если на сайтах не будет форумов — можно объединить. Иначе — только c учётом [1].
locales_* — переводы. Совмещать однозначно.
menu — меню сайта.
node и node_* — ноды. [1]
permission — права ролей на хуки, предоставляемые модулями. Совмещается.
role — роли на сайте (анонимный, зарегистрированный, модер, админ). Совмещается.
sequences — информация о количестве нод, комментов, юзеров на сайте. В Drupal 6 отсутствует, т.к. в таблицах введен автоинкремент для id. Совместима только с учетом [1] и [2]. Я разделил.
sessions — сессии юзеров. Объединяю, только с учётом того, что в settings.php следует указать ini_set('session.name', 'mysite_PHPSESSID'), чтобы пользователи могли залогиниться на нескольких сайтах одновременно. [2]
system — инфа о установленных модулях и темах. Объединяю, предварительно закинув нужные файлы в /sites/all/modules и /sites/all/themes.
term_* — Термины. [1]
url_alias и url_alias_extra — алиасы, ЧПУ, чистые ссылки. Совместить можно, но только с учетом [1] и [2]. Поэтому для себя выбрал вариант — не совмещать.
users — юзеры этого сайта. [2]
users_roles — роли юзеров этого сайта. [2]
variable — переменные сайта. Из-за присутствия специфичных переменных, вроде site_name (имя сайта), site_slogan, theme_default, pathauto_* совместить не получится.
view_* — виды. [1]
vocabulary и vocabulary_node_types — Словари. [1]
watchdog — журнал ошибок сайта. Совместить можно, но крайне нежелательно, ибо при большом количестве сайтов в админке сложно смотреть такие журналы — всё валится в одну кучу. В БД (PhpMyAdmin, например) можно будет задать фильтр по столбцу location, но нафиг такое.
Примечания
[1] Возникает проблема дублированного контента. Когда одна новость / статья появляется на всех сайтах. Вряд ли понравится пользователям (возникает мысль — уже где—то такое видел), и тем более — не нравится поисковикам.
Как вариант — можно объединить таблицы node, comments, files, forum, term, vocabulary, view и сопутствующие им, создать типы материалов, вроде hunt_story — для статьи на охотничьем сайте, fish_story для рыбалки, moto_story для сайта о мотоциклах. Создать несколько "стандартных" (последние статьи, 5 самых популярных, и т.д.) views, и на каждом сайте использовать их. Далее — работа с аргументами — определяем URL сайта, и в зависимости от него уже добавляем нужный фильтр во views.
Блоки и меню предпочитаю всё ж для каждого сайта использовать свои, или просто - создать сайт-шаблон, с необходимым набором блоков, а дальше ctrl-c, ctrl-v
[2] Общая база пользователей — то, ради чего часто и делается мультисайтинг. Совмещать или нет — выбор по задачам проекта. Если сайты — это региональные подразделения какой-то фирмы, то однозначно стоит. Если сайты посвященны различным тематикам (ромашки, мотоциклы, программирование) — вряд ли пользователям нужна такая фишка.
[3] Не рассматривал другие модули, как-то: blog, forum, cck, poll, которые по сути - можно отнести к примечанию [1].
Что объединить?
В зависимости от целей. Выставил по приоритету — вначале наименее проблемные, и по нарастающей.
- locales_*, filters, filter_formats, roles, permission, flood
- access, authmap, system, sessions
- node*, comments*, file*, term*, vocabulary*, view*
Как объединить?
- Всё в одной БД, с использованием префиксов таблиц — не катит, несколько доп. модулей для связки — и каждая новая инсталяция добавляет в БД сотню таблиц.
- Общие таблиц — в одной БД, собственные — в собственной БД. Наиболее оптимальный вариант.
У меня примерно вот такой конфиг:$db_prefix = array(
'default' => 'common.',
'locales_meta' => 'site1.',
'locales_source' => 'site1.',
'locales_target' => 'site1.',
'role' => 'site1.',
.......
);Обращаю внимание на точку: common — имя одной базы, site1 — имя другой базы, а вовсе не префикс таблиц. Подробнее читайте в статье andyceo.
Еще одна мысль — таблицу session выделить в отдельную базу, и сменить тип MyISAM на более быстрый InnoDB. Выигрыш в производительности, и если даже база сломается — то затронет только таблицу session, а другие общие таблицы не заденет (InnoDB хранит всю БД на диске в виде одного файла, MyISAM — одна таблица = один файл).
Ссылки по теме
- Мультисайтинг — это просто — хорошая статья Разгонки, где всё подробно разжёванно.
- Мультисайтинг на Друпале — это круто! — тож неплохая статья andyceo, частично с моей статьей перекликается.
- Схема БД Drupal 5.
Предупреждение
Мультисайтинг — очень "веселая" тема. Будет дофига проблем с куками на разных доменах, с доступом к файлам (интеграция TinyMCE, галерей картинок). Я предупредил
Комментарии
систематизировано, спасибо!
flood — таблица, в которой хранится инфа, когда юзер посылал сообщение администрации сайта через модуль Contact. Используется крайне редко, чаще замещается модулем feedback.
эта таблица используется для ограничения количества запуска определеных участков кода
в основном для предотврацения спама - N запусков в час
используется многими модулями для этих целей, а не только Contact
Хотелось бы узнать названия этих модулей. Я могу назвать только модуль coder.
практически все что делают рассылку
email
feedback
mass_contact
forward
Решение было сохранено на сайте DrupalCookBook.ru:
Выбор таблиц для объединения при мультисайтинге.
Авторы, предложившие решения, также указаны в сохранённой статье.
KCEOH, получается, что каждый новый модуль будет создавать свои таблицы в базе common, которая объявлена базой по умолчанию.
Или у вас common - это база конкретного сайта, а site1 - общая база?
По логике вещей таблицы locales_* лучше в общую базу... Да и вы так писали.
Это путаница в названиях или я чего-то не понимаю в этом деле?