Какая CMS подходит для высоконагруженных порталов?

Question

[Mikhail Tchervonnko]

Доброе время суток хаброобществу.


Последнее время пытаюсь разобраться какие CMS наиболее подходят для высоконагруженных порталов

с возможностью ухода в облака, масштабированием и использованием nosql баз.


Спасибо.

Comments

[Silaev]

А что вы понимаете под словом «портал»?

[Mikhail Tchervonnko]

Извините не сразу заметил ваш вопрос.
Ответ: Например сайт по поиску и бронированию отелей/вилл/яхт итп с более чем 1 миллионом посетителей в день.

Answer 1

[shagguboy]

ни одна не подходит. надо самому писать.

Comments

[Михаил Конюхов]

прямые руки + php + куча доки + админ (прямые руки в комплекте) + архитектор (голова в комплекте)
сделают Вам портал или еще что то для высокой нагрузки.
CMS не предназначены под неё и практически не масштабируемы.

Answer 2

[Skull]

сами же потом и пожалеете о выборе CMS, я б фреймворк взял. И для nosql можно поискать модули… или самому написать.

Comments

[Mikhail Tchervonnko]

а если выбирать framework то при ориентации например на mongo что посоветуете посмотреть?

[Mikhail Tchervonnko]

скажем если выбирать из этих.

[Владимир Соколовский]

Сейчас очень много nosql решений для Django. И по скорости работы при правильном кешировании фреймворк будет хорошо работать при высоких нагрузках. Хотя, как писали выше, «высокие нагрузки» понятие очень растяжимое.

[Skull]

Я б Kohana посоветовал

[Сергей Протько]

А я б Symfony, на вкус и цвет. Тут нужно готовые решения смотреть, качество кода, покрытие тестами и прочее.

Answer 3

[Angerslave]

А какая задача-то? Социалка, новостной сайт или сервис какой-то обработки данных? По идее, хорошая CMS позволит до роста нагрузки продержаться насколько необходимо долго различными оптимизациями по ходу. В этом плане форк Drupal'а Pressflow выглядит неплохо. Если брать фреймворк, то это изначально нужно понимать какой для чего, иметь девелоперов и закладываться на хайлоад (которого ещё нет?).
По поводу облаков — у вас такой плавающий хайлоад, что облака будут эффективнее, чем несколько арендуемых серверов?

Вообще, выглядит больше как набор маркетинговых штампов — хайлоад, облака, NoSQL. Что там ещё в тренде сейчас? Должно на мобильных девайсах хорошо отображаться… Хотя это пользователю хоть какая-то польза, от метода хранения информации в БД юзеру ни холодно, ни жарко.

Возможно, для Ваших целей всё это подходит, но тогда это Вы должны нам рассказывать, почему MapReduce Вам нужнее Join'ов, как при нагрузке вы будете запускать новые инстансы в облаках, какие стратегии кэширования у Вас на сайте могут быть применены и т.д.

Comments

[Сергей Протько]

>>то это изначально нужно понимать какой для чего
А можно взять Symfony/Zend и писать. Это комбайны, и они очень гибки.

[Сергей Протько]

косательно бблаков. Если у вас есть кластер серверов то скорее всего у вас есть и сисадмин, которому тоже нужно платить деньги. В этом плане сервисы аля амазоновских сильно профитнее своих серверов.

По поводу MapReduce vs Join — при наличии Join-ов можно забыть о горизонтальном масштабировании. Ну или как минимум это будет сильно напряжно.

[Angerslave]

Смотря что под Symfony подразумевается. Если первая ветка — то сомневаюсь, на данный момент устаревший фреймворк. Вторая ветка — да, получше, собственно как и Zend, который даже в большей степени является библиотекой, чем SF2. Второй Symfony можно также как набор инструментов воспринимать и использовать лишь некоторые из них. Возможно, это самый оптимальный вариант, если взять часть компонентов Symfony2, часть от Zend Framework и т.д., но нужно чётко понимать что для чего предназначено, какие компоненты как развиваются и т.д. Также как и с примешиванием других технологий — Django, Rails и т.п., что в конечном счёте ведёт к серьёзному росту стоимости разработки и владения проектом.
Поэтому, нужно искать грамотного технаря (или самому разбираться в тонкостях хайлоада, ибо «хайлоад CMS» в общем-то нет, хайлоад под разные нагрузки строится разными путями, разными технологиями. Поэтому тут и советуют многие фреймворки — в них зачастую проще реализовать масштабируемость, но сами методы масштабирования всё равно лежат вне плоскости фреймворков, ведь нужно ещё и код грамотно писать, чтобы при распределении приложения на несколько серверов производительность росла если не линейно, то хотя бы с небольшим оверхедом.

[Angerslave]

Не хотелось бы разводить холивор «облака vs сервера», но облака также нужно поддерживать, собственно сисадмин не за серверами следит, а за системой. В любом случае, я не говорю, что сервера лучше облаков, но я также хочу акцентировать внимание и на обратном — не всегда облака лучше серверов.

То же самое можно сказать про NoSQL — важно, чтобы человек, принимающий решение по использованию технологии, понимал зачем это, что NoSQL — не серебряная пуля и что проблемы масштабирования не решаются выбором «NoSQL или RDB», любое решение так или иначе подкинет пучок проблем.

[Борис Сёмов]

При высоких нагрузках сервера обходятся куда дешевле облаков…

[Mikhail Tchervonnko]

Проблема в том что это уже не написание нового а переписывание того что не справляется с нагрузками. Причем в сезон отпусков нагрузки могут в сотни раз вырастать. С серверами просто нереально следовать за нагрузками. Сейчас сделали с запасом но 80 % времени столько ненужно. Опять же изначально многие вещи были не предусмотрены (масштабирование и проч) и сейчас работают решения сделанные на коленке, некрасивые и отчасти нестабильные.
Про CMS спросил потому что думал что мог что то упустить и теперь изобретаю велосипед, но походу все печальнее чем представлялось.

[Angerslave]

Проблема с CMS и отчасти с фреймворками в том, что гибкость делается за счёт производительности. То есть Вы берёте default CMS, за 10 минут настраиваете её и радуетесь. А когда приходит трафик, огорчаетесь. Поэтому и нет такой default CMS, которая держит трафик (разве что всякие примочки типа Boost (HTML cache) для Drupal с кучей условий для работы), опять же, повторюсь, высокие нагрузки у всех разные, решения разные, бизнес-процессы разные, окружение разное и т.п., есть только множество практик, которые имеет смысл применять при разработке высоконагруженного проекта на чём бы то ни было — CMS, фреймворк или минимальный набор методов из ЯП.

Answer 4

[volos]

Да в принципе главное это правильно настроить сервер, но…
Я предпочитаю Друпал, и именно для порталов

Comments

[volos]

про nosql не дочитал, простите

[Mikhail Tchervonnko]

у друпала есть интеграция с монго напр.

[Mikhail Tchervonnko]

тут подробнее

[volos]

Я просто таких вещей не делал, поэтому и так написал, но спасибо, протестирую

Answer 5

[ArtEx]

Поддерживаю мнение про отказ от готовых CMS.
Готовая CMS — это, по сути своей, универсальный инструмент, направленный на массовое применение. Потому туда заложено «всё», что только может потребоваться. А Вам, в конкретной задаче, из этого «всё», как правило, даже 2\3 не понадобится. Зато ресурсов это самое «всё» будет пожирать сверх нормы.
Соот-но, как было сказано выше: правильнее взять фреймворк(на мой взгляд — yii, если речь о php), в кач-ве бд, на мой взгляд, вполне подойдет mysql\pgsql + шардинг(раз уж планируется highload).
И не факт, что это будет проще, чем допиливать\перекраивать готовую CMS, а итогом будет полноценный продукт в соответствии с Вашими требованиями.

Answer 6

[Сергей Протько]

Искать готовую CMS что бы потом потратить на допиливание столько же времени, сколько на разработку своей узко направленной… Сомневаюсь что есть в этом хоть какой-то профит. Использовать CMS имеет смысл на небольших сайтах-визитках, в остальных же случаях можно сэкономить массу нервов и писать все на фреймворках (можно запастись готовыми наработками что бы делать не с нуля).

А их фреймворков стоит обратиться к Symfony2 либо Zend2. По количеству готовых качественных решений альтернатив особо нету. В плане NoSQL и интеграции в облака с ними тоже все хорошо.

Comments

[shagguboy]

я за Симфони 2. Доктрина точно Монго поддерживает. Пропел может быть.

Answer 7

[Александр]

Я сейчас работаю как раз над проектом с похожей тематикой. Там никакого даже фреймворка нет (исторически сложилось). Перевести всё это на CMS просто нереально, не говоря уж о производительности. Только фреймворк использовать. Кстати, не понятно совсем зачем понадобилась MongoDB, можно и без этого спокойно обойтись. SQL-решения чаще всего быстрее.

Comments

[Mikhail Tchervonnko]

Перевести всегда реально, вопрос только времени, денег и желания. Причем чем раньше поймёшь что надо переводить и начнешь это делать тем дешевле в итоге это обойдётся. Важно только не повторять ошибки допущенные в первой версии и умерить своё эго. Если чувствуешь что сам не справляешься скажи это тем кто принимает решение, никто за это не съест а ситуацию возможно ещё можно поправить.

[Александр]

Не я строил то говнище. Вопрос подымался не раз. И не решался. Никого из вышестоящих ситуация не парила. Так что в декабре я покинул ту компанию.

Answer 8

[Тимур Туз]

Пишите хоть на друпале, хоть на джумле. Любой проект изменяется бешенными темпами вначале. Да и подозреваю что в это время вы не получите миллион посетителей. В общем это будет ваш «тормозной но легко изменяемый прототип». После того как требования и продукт стабилизируется, вы поймете требования к ресурсам и технологиям. Там можно и нужно переходить на самопись.

Answer 9

[zizop]

Я бы остановился либо на NodeJS (но тут ещё мноегое сыровато) либо на проверенных решениях типа Zend Framework (есть Zend/Cloud компоненты для облаков), а в качестве хранилища — MongoDB. В качестве модельного слоя можно использовать Doctrine 2 ODM. Мы используем именно так.

Answer 10

[develop3r]

Попробуйте бесплатную open source ImageCMS Corporate.
Она узкозаточенная под корпоративные порталы.