Мультисайтинг. Выбор таблиц

Главные вкладки

Аватар пользователя KCEOH KCEOH 7 июля 2008 в 11:48

Задумался на тему мультисайтинга для одного своего проекта. Для начала — решил выбрать, какие таблицы стоит сделать общими. Для чего? Экономия места, меньше бэкапы, а также удобство администрирования — при объединении таблиц с локализацией достаточно один раз поменять перевод, а не обновлять его на каждом сайте.
Ниже расписано чуток про каждую таблицу, а также примечания, стоит ли её делать общей для всей связки сайтов, или нет.

Таблицы

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_* — переводы. Совмещать однозначно. Smile
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, но нафиг такое. Smile

Примечания

[1] Возникает проблема дублированного контента. Когда одна новость / статья появляется на всех сайтах. Вряд ли понравится пользователям (возникает мысль — уже где—то такое видел), и тем более — не нравится поисковикам.
Как вариант — можно объединить таблицы node, comments, files, forum, term, vocabulary, view и сопутствующие им, создать типы материалов, вроде hunt_story — для статьи на охотничьем сайте, fish_story для рыбалки, moto_story для сайта о мотоциклах. Создать несколько "стандартных" (последние статьи, 5 самых популярных, и т.д.) views, и на каждом сайте использовать их. Далее — работа с аргументами — определяем URL сайта, и в зависимости от него уже добавляем нужный фильтр во views.
Блоки и меню предпочитаю всё ж для каждого сайта использовать свои, или просто - создать сайт-шаблон, с необходимым набором блоков, а дальше ctrl-c, ctrl-v Smile

[2] Общая база пользователей — то, ради чего часто и делается мультисайтинг. Совмещать или нет — выбор по задачам проекта. Если сайты — это региональные подразделения какой-то фирмы, то однозначно стоит. Если сайты посвященны различным тематикам (ромашки, мотоциклы, программирование) — вряд ли пользователям нужна такая фишка.

[3] Не рассматривал другие модули, как-то: blog, forum, cck, poll, которые по сути - можно отнести к примечанию [1].

Что объединить?

В зависимости от целей. Выставил по приоритету — вначале наименее проблемные, и по нарастающей.

  1. locales_*, filters, filter_formats, roles, permission, flood
  2. access, authmap, system, sessions
  3. 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 — одна таблица = один файл).

Ссылки по теме

  1. Мультисайтинг — это просто — хорошая статья Разгонки, где всё подробно разжёванно.
  2. Мультисайтинг на Друпале — это круто! — тож неплохая статья andyceo, частично с моей статьей перекликается.
  3. Схема БД Drupal 5.

Предупреждение

Мультисайтинг — очень "веселая" тема. Будет дофига проблем с куками на разных доменах, с доступом к файлам (интеграция TinyMCE, галерей картинок). Я предупредил Wink

Комментарии

Аватар пользователя Debugger_01 Debugger_01 8 июля 2008 в 13:18

flood — таблица, в которой хранится инфа, когда юзер посылал сообщение администрации сайта через модуль Contact. Используется крайне редко, чаще замещается модулем feedback.

эта таблица используется для ограничения количества запуска определеных участков кода
в основном для предотврацения спама - N запусков в час
используется многими модулями для этих целей, а не только Contact

Аватар пользователя VladSavitsky VladSavitsky 19 ноября 2008 в 0:18

"KCEOH" wrote:
$db_prefix = array(
'default' => 'common.',
'locales_meta' => 'site1.',
'locales_source' => 'site1.',
'locales_target' => 'site1.',
'role' => 'site1.',
.......
);

KCEOH, получается, что каждый новый модуль будет создавать свои таблицы в базе common, которая объявлена базой по умолчанию.
Или у вас common - это база конкретного сайта, а site1 - общая база?
По логике вещей таблицы locales_* лучше в общую базу... Да и вы так писали.
Это путаница в названиях или я чего-то не понимаю в этом деле?