| Входящие | Горячие | Без ответа |
31 октября 2012 в 16:17
Какая CMS подходит для высоконагруженных порталов?
CMS*
Доброе время суток хаброобществу.
Последнее время пытаюсь разобраться какие CMS наиболее подходят для высоконагруженных порталов
с возможностью ухода в облака, масштабированием и использованием nosql баз.
Спасибо.
Последнее время пытаюсь разобраться какие CMS наиболее подходят для высоконагруженных порталов
с возможностью ухода в облака, масштабированием и использованием nosql баз.
Спасибо.
сортировка
по дате
по рейтингу
ответы (10)
прямые руки + php + куча доки + админ (прямые руки в комплекте) + архитектор (голова в комплекте)
сделают Вам портал или еще что то для высокой нагрузки.
CMS не предназначены под неё и практически не масштабируемы.
сделают Вам портал или еще что то для высокой нагрузки.
CMS не предназначены под неё и практически не масштабируемы.
а если выбирать framework то при ориентации например на mongo что посоветуете посмотреть?
Сейчас очень много nosql решений для Django. И по скорости работы при правильном кешировании фреймворк будет хорошо работать при высоких нагрузках. Хотя, как писали выше, «высокие нагрузки» понятие очень растяжимое.
>>то это изначально нужно понимать какой для чего
А можно взять Symfony/Zend и писать. Это комбайны, и они очень гибки.
А можно взять Symfony/Zend и писать. Это комбайны, и они очень гибки.
косательно бблаков. Если у вас есть кластер серверов то скорее всего у вас есть и сисадмин, которому тоже нужно платить деньги. В этом плане сервисы аля амазоновских сильно профитнее своих серверов.
По поводу MapReduce vs Join — при наличии Join-ов можно забыть о горизонтальном масштабировании. Ну или как минимум это будет сильно напряжно.
По поводу MapReduce vs Join — при наличии Join-ов можно забыть о горизонтальном масштабировании. Ну или как минимум это будет сильно напряжно.
Смотря что под Symfony подразумевается. Если первая ветка — то сомневаюсь, на данный момент устаревший фреймворк. Вторая ветка — да, получше, собственно как и Zend, который даже в большей степени является библиотекой, чем SF2. Второй Symfony можно также как набор инструментов воспринимать и использовать лишь некоторые из них. Возможно, это самый оптимальный вариант, если взять часть компонентов Symfony2, часть от Zend Framework и т.д., но нужно чётко понимать что для чего предназначено, какие компоненты как развиваются и т.д. Также как и с примешиванием других технологий — Django, Rails и т.п., что в конечном счёте ведёт к серьёзному росту стоимости разработки и владения проектом.
Поэтому, нужно искать грамотного технаря (или самому разбираться в тонкостях хайлоада, ибо «хайлоад CMS» в общем-то нет, хайлоад под разные нагрузки строится разными путями, разными технологиями. Поэтому тут и советуют многие фреймворки — в них зачастую проще реализовать масштабируемость, но сами методы масштабирования всё равно лежат вне плоскости фреймворков, ведь нужно ещё и код грамотно писать, чтобы при распределении приложения на несколько серверов производительность росла если не линейно, то хотя бы с небольшим оверхедом.
Поэтому, нужно искать грамотного технаря (или самому разбираться в тонкостях хайлоада, ибо «хайлоад CMS» в общем-то нет, хайлоад под разные нагрузки строится разными путями, разными технологиями. Поэтому тут и советуют многие фреймворки — в них зачастую проще реализовать масштабируемость, но сами методы масштабирования всё равно лежат вне плоскости фреймворков, ведь нужно ещё и код грамотно писать, чтобы при распределении приложения на несколько серверов производительность росла если не линейно, то хотя бы с небольшим оверхедом.
Не хотелось бы разводить холивор «облака vs сервера», но облака также нужно поддерживать, собственно сисадмин не за серверами следит, а за системой. В любом случае, я не говорю, что сервера лучше облаков, но я также хочу акцентировать внимание и на обратном — не всегда облака лучше серверов.
То же самое можно сказать про NoSQL — важно, чтобы человек, принимающий решение по использованию технологии, понимал зачем это, что NoSQL — не серебряная пуля и что проблемы масштабирования не решаются выбором «NoSQL или RDB», любое решение так или иначе подкинет пучок проблем.
То же самое можно сказать про NoSQL — важно, чтобы человек, принимающий решение по использованию технологии, понимал зачем это, что NoSQL — не серебряная пуля и что проблемы масштабирования не решаются выбором «NoSQL или RDB», любое решение так или иначе подкинет пучок проблем.
Проблема в том что это уже не написание нового а переписывание того что не справляется с нагрузками. Причем в сезон отпусков нагрузки могут в сотни раз вырастать. С серверами просто нереально следовать за нагрузками. Сейчас сделали с запасом но 80 % времени столько ненужно. Опять же изначально многие вещи были не предусмотрены (масштабирование и проч) и сейчас работают решения сделанные на коленке, некрасивые и отчасти нестабильные.
Про CMS спросил потому что думал что мог что то упустить и теперь изобретаю велосипед, но походу все печальнее чем представлялось.
Про CMS спросил потому что думал что мог что то упустить и теперь изобретаю велосипед, но походу все печальнее чем представлялось.
Проблема с CMS и отчасти с фреймворками в том, что гибкость делается за счёт производительности. То есть Вы берёте default CMS, за 10 минут настраиваете её и радуетесь. А когда приходит трафик, огорчаетесь. Поэтому и нет такой default CMS, которая держит трафик (разве что всякие примочки типа Boost (HTML cache) для Drupal с кучей условий для работы), опять же, повторюсь, высокие нагрузки у всех разные, решения разные, бизнес-процессы разные, окружение разное и т.п., есть только множество практик, которые имеет смысл применять при разработке высоконагруженного проекта на чём бы то ни было — CMS, фреймворк или минимальный набор методов из ЯП.
Перевести всегда реально, вопрос только времени, денег и желания. Причем чем раньше поймёшь что надо переводить и начнешь это делать тем дешевле в итоге это обойдётся. Важно только не повторять ошибки допущенные в первой версии и умерить своё эго. Если чувствуешь что сам не справляешься скажи это тем кто принимает решение, никто за это не съест а ситуацию возможно ещё можно поправить.
Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Ответ: Например сайт по поиску и бронированию отелей/вилл/яхт итп с более чем 1 миллионом посетителей в день.