23 июля 2013 в 1:01
Потянет ли друпал 2 млн node c большим кол-вом полей?
С учетом того, что: много полей, много таксономии. А сама БД node+cck+taxonomy весит около 10 Гб.
Или сразу отказываться от архитектуры друпала?
Я конечно понимаю, что можно настроить взять мега сервак с неограниченным кол-вом оперативки, но это уже слишком...
Комментарии
А почему нет?
Оптимизировать, естественно, будет необходимо. Настроить кэширование и всё такое...
лучше не связывайтесь.
Всё зависит от задач и подхода
главное сзади не подходить,как это обычно делается
а сайт уже есть с таким кол-вом нод или это только планы?
Чота в последнее время тут то и дело земляки-зеленоградцы появляются. Хорошо!
Зачем целый сегмент netall-горнет-акадо на zelhome по IP забанили?
Я бы наверное не стал друпал использовать. Хотя опять же, смотреть надо.
База конечно сама по себе не маленькая, но тут вопрос еще в другом: какова архитектура данных, и как часто предусматривается их изменение.
Если например это интернет-магазин, или что то аналогичное, то это предусматривает регулярное изменение цены/наличия, что для 2 млн. товаров уже не просто, плюс время жизни кэша будет в таком случае не больше времени актуальности цены/наличия.
Если контент будет изменятся редко - то уже проще, для клиента можно и вовсе в таком случае отдавать кэшированную статику с помощью Varnish.
Кстати, исходя из стартовой темы, предусматривается использовать шестую ветку ядра? Если да, то я думаю это не самый правильный выбор для большого нового сайта с перспективой развития.
Если делать - то уже на 7рке drupal.
Да, это интернет-магазин с часто меняемыми полями. И с частым экспортом данных в xml-формате всей продукции.
Кэширование - это хорошая, штука. Но для простоты выборки по параметрам - использовать AJAX
Есть БД для drupal-а , т.е. те самые поля, которые будут 1 в 1 весить .
Вообще есть резон наверное уйти в облака ( на амазон например )
Мы думали, что забанили не целый сегмент netall-горнет-акадо , а лишь часть))
Разве это панацея? Дергать БД всё равно придётся.
Зато придется дергать не все, а лишь данные
Месье переоценивает облака
Чтобы из кэшу взять, надо туда положить.
Всё равно закончится банальным node_load()
Естественно.
Как вариант, предположение, найти самые большие проекты на Drupke и посмотреть как они построены.
Наверняка, у какого-нить из них есть описание архитектуры, как ПО так и железной части. Я особо не заморачивался на эту тему, поэтому ничего больше предложить не смогу.
Большая вероятность, что они будут использовать какие-либо кластерные технологии.
Облака не панацея...
я знаю о какой подсети идет речь, мы сняли ограничения.
зато нету потолка))
Потолок - 1 сервер, внутри которого выполняется запрос. Т.к. любое облако не более чем кластер серверов.
На таком объеме данных лучше писать под себя изначально.
Не рекомендую здесь применять Дру - работать будет, но медленно, и костылей придется применять очень много. Пожалеете потом.
Исходя из своего небольшого опыта, могу сказать, что уже при количестве номенклатур в 50К и поддержанием актуальности в 15 минут все становится не очень хорошо.
В первую очередь проблема сохранения - node_save() довольно таки затратная для вычислительных ресурсов функция. Кроме того частые сохранения = частый сброс кэша, что опять таки замедляет общее быстродействие.
Если не использовать node_save(), а писать прямо в базу, можно уткнутся в другую проблему - если используется отдельная поисковая машина для каталога с фасетами и поиском (например Apache SOLR или Sphinx), то есть высокая вероятность рассинхронизации поискового индекса и реальных данных.
Кроме того XML не самый оптимальный формат для обмена данными в таком случае. Парсинг XML это более медленная операция, чем например получение данных их CSV или из MySQL, или из того же MongoDB.
На мой взгляд, для проекта с таким количеством товаров, и требованием частого обновления данных нужно кастомное решение, и то, не факт что все может обойтись стандартным MySQL. Я бы смотрел в сторону хранения данных в MongoDB.
У меня тоже есть серьёзные проекты с большим кол-вом node , вот из-за этого я и сомневаюсь в применении drupal-а для данной задачи. В итоге с таким объемом данных в БД - она и будет узким местом, и все будет жестко медленно лагать.
дедик с 16 гигами оперативы потянет нормально. Но лучше конечно 32 гига брать, с запасом
В самом начале поста «Я конечно понимаю, что можно настроить взять мега сервак с неограниченным кол-вом оперативки, но это уже слишком...»
Да да да, главное не на семёрке, а то сервер повесит
если посетители только анонимы на 100% ,то потянет
Вы когда молодой человек успокоитесь? Или Вы в детском саду еще? А может вообще еще сиську сосете?
для 10 гигов базы, нужна оперативка, чтоб ее туда загнать или Вы насиловать веник будете? Ни один шаред Вам не даст столько оперативы.
У нас было несколько шаред-серверов, пара облачны сервисов, механизм кеширования и большая россыпь API. Не то, чтобы необходимый запас для разработки, но уж если начал сторить сайт, то остановиться трудно. Единственное, что у нас вызывало опасение это node_load(). Нет ничего более тормозного и безответсвенного, чем загрузка ноды.
А ты, я смотрю, парень отчаянный, да?
А отчаянность здесь каким боком?
Все довольно тривиально: при загрузке ноды в основном используются селекты. При сохранении ноды - инсерты и апдейты, что явно более затратно в плане производительности.
Кроме того, раз вызвав node_load() мы можем положить результаты в варниш, и дальше определенное время отдавать статику, не поднимая ядро для сбора полей и рендеринга. Профит от этого очевиден.
При сохранении ноды напротив, производится сброс кэша, и как минимум ближайшего пользователя ждет node_load() со всеми истекающими из него тормозами в загрузке. А если этот самый node_save() происходит перманентно (при частом изменении контента), эффект будет ну ооочень не хороший 
есть одна работа с ~3млн нод с десятком полей у каждой, ~400 тыс терминов в 2х словарях, как раз на таком и живет, при этом прекрасно себя чувствует и на виртуалке(дев).
Там есть несколько простых истин(все, что ниже, относится как раз к случаю с миллионами нод):
кривой запрос приведет не к легким тормозам как на визитке, а к тому, что словите таймаут.(одна ошибка и таймаут)
7рка работает быстрее 6рки.
в 7рке список нод в виде тизеров выводится быстрее.
даже небольшой наплыв юзеров на не кешированный сайт приведет к падению БД(гарантирую)
стандартный кеш(включенный везде где только можно) держится очень даже неплохо
варниш будет кушать место на диске
мемкешед рулит
сайт будет охрененно чувствителен к настройкам сервера, особенно БД
остальное вроде ничем не отличается от визиток, хотя может чего забыл упомянуть.
node_load работает с одной и той же скоростью в независимости от числа нод(если, конечно, у Вас там не используется какие-либо странные выборки в хуках с загрузкой нод), в то время как "сложные" запросы того же вьювс работают медленнее как раз с увеличением числа строк в БД, отсюда и следует - либо отказываемся от вьювс, либо простейшая выборка во вьювс и грузим тизеры, и то и то будет работать быстрее прямых выборок кучи полей по сложным фильтрам через вьювс.
А откуда берётся кэш тогда?
не понял вопроса
Я имел ввиду, что даже если скорость загрузки страниц без какого либо кеша может показаться очень даже приемлимой, то базе данных от этого не легче, это ситуация где работает только кеш для анонимов и ни одна вьюха, ни один блок и т.д. не кешируются, в случае с мелкими сайтами будет спасать кеш самой СУБД, однако, при таких объемах данных и большом числе юзеров, его хватает только на повторяющиеся запросы в пределах одной загрузки.
И еще момент, изначально сайт был на ZF, имел меньше возможностей и тормозил по круче стоп крана, так что, то, как будет работать сайт, зависит в первую очередь не от движка, а от того, кто его делает.
З.Ы. мой выбор в конкретном случае пал в сторону друпала только из-за масштабируемости, если бы мне не приходилось раз в месяц в корне менять логику, я бы выбрал тот же Zend.
Изначально сайт был на D6+UC2 находился на полудолхлом дедике, стоимостью не многим больше VPS, причина переезда на более мощное железо была в размере жесткого диска(там контент специфический), ну и разница в производительности скорее как небольшой бонус.
Если интересно, хостер - агава.