Правильно или нет? Распределение нагрузки между базами и ограничения по количеству нод.

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

Аватар пользователя gasloff@drupal.org gasloff@drupal.org 29 ноября 2006 в 2:55

Мы сейчас делаем несколько сайтов.
1. www.allbeers.org - сайт про пивоварни и сорта пива со всего мира.
2. www.allpubs.org - сайт про пабы, пивные и пивные бары.
На первом сайте будет около 10000 пивоварен (на каждую отдельная нода) и минимум по три сорта пива каждой пивоварни (еще 30000 нод). Кроме того, к каждому сорту у юзеров есть возможность оставить свой рейтинг (по нескольким шкалам) - по ноде на каждый отзыв. Допустим 3 отзыва на каждый сорт - 90000 нод. Получается огромное количество нод Sad
На втором сайте будет каталог и рейтинги пабов и пивных. Там объемы могут быть такими же.
Авторизация выполняется по единой базе юзеров (пока мы линкуем таблицы с юзерами и ролями из одной из баз).
Кроме того, мы туда намереваемся перенести существующий форум (www.allpubs.org/forum). А это еще расход нод Sad
Посему вопросы:
Сколько нод может нормально "тянуть" Друпал в 4.7 версии и в 5.0 версии?
Что стоит делать для повышения быстродействия в такой ситуации?
Стоит ли форум выносить на отдельный поддомен с отдельной базой?

Заранее благодарю за ответы Smile

Комментарии

Аватар пользователя rapitosov@drupal.org rapitosov@drupal.org 29 ноября 2006 в 8:41

Почитайте вот эту статью http://drupal.org/node/79237 Думаю, лучший ответ на Ваш вопрос - экспериментальные данные.
---
http://drupal5.ru - информация для друпателей
качественные ответы только на качественные вопросы

Аватар пользователя ultraboy@drupal.org ultraboy@drupal.org 29 ноября 2006 в 11:57

На друпалорг 100 000 нод. И ничего, работает Wink
С таким размахом, скорее всего сможете позволить себе выделенный сервер? Тогда точно все будет работать нормально. (Если не будет кривых самописных модулей LOL, потому что с таким количеством данных нужно работать аккуратно уже. но возможно, вполне!)

Единственно что - не нужно создавать тысячи элементов категорий (terms - как это по-русски?). Потому что на это стандартные модули не рассчитаны. А то бывают такие шутники ^_^

Аватар пользователя axel axel 29 ноября 2006 в 21:05

По железу ничего не порекомендую, имхо сколько денег есть, такой и сервер Smile Вот по софту рекомендую вот эту статью глянуть: http://buytaert.net/drupal-webserver-configurations-compared

На lighttpd сам не пробовал ещё, но даже если не как основной сервер, то для отдачи картинок и статики его удобно использовать, оставляя работу с php на apache. А на входе обратный прокси разруливает запросы. На drupal.ru именно так сделано.

--
Axel,
администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!

Аватар пользователя axel axel 29 ноября 2006 в 20:29

Есть ограничения конечно. Например nid представлен целым числом в 10 байт т.е. больше чем 3e+304 нодов без дополнительных ухищрений в базу запихнуть не получится Wink В реальности, нужно смотреть скорее на посещаемость, потому как это больше влияет на скорость работы сайта, нежели количество документов на нём. На виртуальном хостинге сайт будет тормозить и с сотней нодов, если на него натравить несколько тысяч посетителей в день. Выше дали правильный совет - потестировать залив контент с помощью утилит к модулю devel.

Отдельно отмечу, что в 5.0 схема кеширования ещё улучшена (хотя в 4.7 уже тоже неплохо).

--
Axel,
администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!

Аватар пользователя axel axel 29 ноября 2006 в 20:41

А очень кстати жаль, что taxonomy использует традиционный, но не самый эффективный способ хранения деревьев, с рекурсивной выборкой по элементам - см. реализацию taxonomy_get_tree(). Понятно, что выбрано из-за гибкости - можно получить множественных родителей, но они редко когда нужны и чаще хотелось бы видеть бОльшую скорость, вместо гибкости. Правда для этого придётся полностью сменить схему хранения terms и известные мне нерекурсивные алгоритмы позволят хранить только деревья и плоские списки.

--
Axel,
администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!

Аватар пользователя axel axel 29 ноября 2006 в 21:08

Тут патчем не обойтись. Поскольку схема хранения абсолютно несовместимая с тем, что есть сейчас и алгоритмы работы другие. Только альтернативный модуль таксономии писать. Собственно есть ведь folksonomy, но он afaik работу только с плоскими списками предлагает.

--
Axel,
администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!