Проект с высокой посещаемостью — архитектура. Фреймворк или самопис?

Question

[maxxxixxxx]

Здравствуйте.

Никак не могу определиться, на чем писать крупный проект.

Проект из себя представляет нечто вроде социальной сети.
Реализовываться будет на php, mysql
Основные нагрузки будут на базу в момент общения пользователей.
Все примерно как вконтакте, друзья и собственно переписка, и личные сообщения.

Я начал писать свой mvc фреймворк, получилось что-то похожее на kohana-yii.
В нем мне предельно все ясно, я продумал, что маршрутизация будет храниться в мэмкэше, некоторые постоянные данные также для максимальной производительности.

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

И вот я задумался - а может не париться с разработкой фреймворка и взять yii или другой готовый фреймворк.

Подходит ли YII для такого проекта?
Какие узкие места в нем которые будут сказываться на производительности?
Есть ли какая то альтернатива?

Большое количество чатов для общения между пользователями - где хранить данные, в mysql или...?
Выдержит ли mysql?
Подходит ли для этого php?

Answer 1

[Александр Макаров]

Yii подходит для такого проекта.

Как уже было отмечено, если выводить по 100 записей на страницу и для каждой по 10—20 связанных записей, будет кушать память. Ну и ещё момент, не стоит увлекаться event-ами и сильно слоить view через renderPartial.

Чат между пользователями можно реализовать поверх XMPP. Нагрузку такое решение держит отменно.

MySQL может, при грамотной настройке, выдержать очень много. У нас, например, есть в проекте боевом JOIN по таблице с 200 млн. записей. Нормально бегает.

PHP вполне себе справится.

Comments

[Евгений Безымянников]

Верьте ему, он знает. :)

[Сергей]

Yii подходит, а Laravel нет? Есть огромное фреймворков, которые по скорости ничуть не уступают Yii. Честно говоря надоело, что в рунете Yii так доминирует, с его отвратительной архитектурой в первой версии, и вечной беты второй. Заметил такую закономерность: чем выше классом программист - тем больше он поносит Yii. Не с проста.

[addfs]

@liaren
>в рунете Yii так доминирует
Вот это тоже неспроста, потому что огромное русскоязычное сообщество. Вряд ли Taylor Otwell ответит в тостере.

[Сергей]

У Laravel намного более вменяемая документация, чем у Yii, и с учётом полноценного ООП, особых вопросам там не возникает. Мне просто не нравится, что разработчики Yii продолжают пиарить его не взирая на то, что первая версия морально жутко усторела(я уже молчу про поколение быдлкодеров выращенных на ней), и не смотря на то что вторую версию уже который год не могут выпустить(тут дело либо в лени, либо в неппрофессионализме, либо во внутренних противоречиях в сообществе/команде).

Короче, я считаю то что сейчас представляет из себя Yii как продукт в сравнении с прочими фреймворками - не достойно пиара. Разработчикам лучше заняться выпуском релиза второй версии, а не бегать по всяким тостерам и рекомендовать всем подряд своего шизоидального пенсионера Yii первой версии.

[Александр Макаров]

Вопрос был «подходит ли YII для такого проекта?». Разве тут можно объективно ответить «нет»?

С версией 2.0 дело в объёме. Если вы посмотрите на https://github.com/yiisoft/yii2/pulse, поймёте что никакой лени или проблем с сообществом нет. Просто планку взяли высокую. И мы это сделаем, поверьте. Уже есть бета и на ней крутится с десяток проектов в продакшне (мы это не рекомендуем, но факт).

Answer 2

[Vit]

Если все в базу упирается, то все равно какой фреймворк. Yii весьма хорош по производительности. Единственный его минус в этом плане, который я заметил - высокое потребление памяти и долгое время работы, если вы выбираете из БД много-много записей и маппите их в ActiveRecord. Легко лечится заменой AR на DAO в узких местах.
Можете попробовать Yii2, он еще шустрее и удобней (и вышеозвученная проблема с AR и большими выборками там решается еще проще - в AR добавили метод выборки asArray, а так же пакетные выборки)

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

Самый простой способ - master/slave репликация, но она не всегда профит по производительности приносит. Есть более сложные варианты, гуглите по слову шардинг.

А вообще если у вас будет realtime-чаты, то в любом случае на php это не стоит делать. Для этого лучше взять что-нибудь более пригодное для comet-серверов: nodejs, erlang, python+tornado/twisted. Хотя сейчас на слуху асинхронный сервер PHP - ReactPHP, но я лично его не пробовал и не знаю, хорош ли он в бою.

Большое количество чатов для общения между пользователями - где хранить данные, в mysql или...?

MySQL при грамотной настройке может многое. Для начала он вам точно должен подойти.

Answer 3

[keltanas]

Может, перед тем, как писать "хайлоад", подумаете, как решать проблемы целостности и согласованности данных. И как будете обрабатывать конкуретные запросы, чтобы они не мешали друг другу? Здесь yii-шная адстракция над БД не поможет. Придется их костыли своими котылями подпирать и все равно ждать, когда все развалится. Как и в случае большинства всяких универсальных ORM и AR.
Вопрос хранения и обработки данных здесь первостепенный. А дальше хоть гавнопростыней пейджконтроллеры лепите, разница только в стоимости дальнейшей поддержки.
Вопрос выбора фреймворка к хайлоаду никак не относится.

Answer 4

[Дэн]

Выбор фреймворка важен, но определяющими характеристиками будет выбор архитектуры и стратегии роста.

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

Советую почитать об архитектуре систем с большой нагрузкой.

Comments

[Developer Yii]

чем проще движок, тем меньше скрытых нюансов, тем лучше
5++

Answer 5

[Оптимус Пьян]

Преждевременная оптимизация - одна из ошибок программиста.

Вы сначала сделайте проект ))) У нас тоже клиент был, мы подумали за него над нагрузкой при проектировании, а он выдал 5 человек в день и сдулся...

Comments

[maxxxixxxx]

нет, я помню делал как то проект который потом было сложно оптимизировать, а если бы все было продумано в самом начале и проблем бы не было

[Оптимус Пьян]

@maxxxixxxx как насчёт mongoDB ?

[maxxxixxxx]

@marrk2 не работал с ним и не вижу в чем он лучше mysql по скорости

[kolesnevg]

Так же считаю что преждевременная оптимизация - только потеря времени. Лучше просто заложить в архитектуру проекта возможности для его оптимизации в будущем - минимальная зависимость частей архитектуры, возможность замены одного решения на другое. Вы в любом случае не узнаете что у вас начнет тормозить пока не столкнетесь с этим вживую. И кстати чат также очень просто построить на php, можно использовать nginx-push-stream-module, а можно не городить свой огород а воспользоваться (хотя бы на первом этапе) готовым решением pusher.com

[keltanas]

Вопрос не в преждевременной оптимизации, а в архитектуре хранения данных. Она либо будет уметь масштабироваться, либо нет.

Answer 6

[Developer Yii]

не рекомендовал бы frame для крупного проекта. вопрос производительности возникнет - ковырятся придется долго. а так сами сможете сделать все под свои нужды чтобы быстро и гибко, потому что сами писали - проверено неоднократно!

Comments

[keltanas]

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

[Developer Yii]

keltanas: простой пример: в свое время нужно было сделать фильтры по большой базе MySQL - несколько сотен тысяч записей с множественными индексными значениями. в итоге после тестов оказалось, что применение конструкции запроса типа "LIKE {МЕТКА}XXX{МЕТКА}" позволило повысить скорость запросов на порядок. но при этом менялась и структура хранения данных внутри базы, а она не стандартная!!! пробовал все это реализовать на UMI-CMS, затем на Yii. в итоге потратил несколько дней и понял, что на самописке мне все это быстрее поднять, а сроки поджимали. так она на самописке и работает. заказчик доволен!!! плюс ко всему оборудование не совсем свежее, а оно летает. пришлось бы настраивать фрейм или цмс. результат здесь: japancarts.ru. в итоге мой совет такой - для высоконагруженных нужно использовать то, в чем ты уверен не на 100%, а на двести. это значит что ты знаешь там все! по сути самопис это и есть фрейм, только укороченный вариант (соглашусь, что не смогу написать лучше тех, кто занимается разработкой фреймворков многие годы), но ни какой из фреймов не может априроти быть заточен под универсальное решение сложных задач - таких фреймов по логике быть не может. за коммент спасибо!

[keltanas]

Developer Yii Вообще говоря фреймворк или CMS не тоже самое, что слой работы с базой данных. Как и не все фреймворки имеют собственную реализацию этого слоя. Да и у меня возникают сомнения, как человек, который не смог освоить даже yii решил в своей поделке вопросы безопасности. Можно было бы использовать его для диспетчеризации запросов, а с базой работать напрямую через PDO или что-то еще (безусловно, использование orm иногда даже вредно).
Сравнение umi и yii вообще абсурдно по своей природе.
А если бы ваш проект вырос до размеров, когда над ним пришлось бы работать более, чем одному человеку, то остальным ни в чем не повинным членам команды пришлось бы разбираться в бесполезном для себя коде сомнительного качества, и им снились бы ужасные сны о смерти Мартиновских котов.
И да. Если уж база такая большая, а фильтры нужны такие быстрые, взяли бы sphinx ;)

[Developer Yii]

keltanas: честно говоря и так все работает. у меня 40 процентов времени ушло на оптимизацию кода - ускорение сайта, 40 процентов на переоформление кода (чтобы потом можно было быстро разбираться в нем) и 20 процентов на доработку функционала. юми и еии я привел в пример с качестве альтернатив, которые конечно же сравнивать нет смысла. в итоге все работает и все "чисто" - я считаю это главные критерии. а фреймворк это или цмс или еще что-то - главное чтобы руки из того места росли и разработчик понимал что делает, а это уже знание php!!! ИМХО конечно же для больших проектов без фрейма разработка будет сложной, но отдельные задачи есть смысл пробовать решать разными методами - с точки зрения оптимизации и безопасности у всех подходы разные и не факт, что вам подйдет то что есть там или там.

[Оптимус Пьян]

Developer Yii очень верно написал. Излишние абстракции зачастую ни к чему. Сам недавно встречался с разработчиком у которого фрейм сложную аналитическую выборку по базе делал 7 минут, он переписал на прямой запрос всё и стало делаться 15 секунд ))

Answer 7

[verysimplenick]

marrk2 прав,это правда не преждевременная оптимизация, а стремление программиста к идеально-гибкой архитектуре, легко масштабируемой и пр., все это мало того что преждевременно, так еще и мешает реально кодить, сделайте прототип yii2, а чат с оглядкой на xmpp(чтобы легко внедрить можно было при росте нагрузки), это даст хороший зазор по гибкости архитектуры и приемлемо по времени будет.

Comments

[Евгений Безымянников]

Добавлю от себя "мелочь": горизонтальное масштабирование стоит заложить в архитектуру и это порой стоит дешевле, чем оптимизация чего либо вообще.

Answer 8

[Alex Pts]

После 2 лет работы на Yii все же съехали с него. Взяв с собой симфони компоненты и написав view и controller части самостоятельно.