Какие могут быть доводы против back-end для мобильного приложения на php?

Question

[abalyasnikov]

Планируем писать бекэнд для системы, которая состоит из трёх частей:

1) Мобильное приложение
Расчёт на 500к активных пользователей. Каждый из них делает 10-15 хитов к серверу в сутки. Постоянное соединение между приложением и сервером не держится.

2) Интерфейс для отслеживания статистики
Здесь меньше хитов (1000 в сутки всего), акцент на выгрузку из БД и обработку большого количества данных.

3) Обращение к серверу ВК (API): приблизительно 20к хитов в сутки.

БД исчисляется миллионами строк, пока сложно рассчитать точное количество.

ВОПРОС:
Интересуют рекомендации по языку программирования в контексте нагрузки и потенциальной масштабируемости?

Вообще приветствуются любые рекомендации (на что обратить внимание). Если описание недостаточно подробное, пишите - дополним.

Answer 1

[Eugene Mosyukov]

Если это коммерческая разработка, тогда используйте тот ЯП, который лучше знаете.

Answer 2

[Денис Инешин]

Никаких :)

Answer 3

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

Использую php для реализации restfull api для мобильных приложений. Полет нормальный. По нагрузкам особо разницы нету, боюсь у вас основной проблемой будет оптимизация базы и кеширование.

Comments

[abalyasnikov]

@Fesor какие СУБД посоветуете?

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

Вообще посоветовал бы PostgreSQL посмотреть, самый пожалуй выгодный вариант в плане стабильности и быстродействия. Но опять же советую выбрать ту СУБД с которой у вас есть опыт работы.

Answer 4

[Алексей Сундуков]

Учитывая тег PHP предположу, что этот язык известен больше всего. На нем и пишите. 500кю*10-15 ~ 10М/сутки нагрузка вполне подъемная для PHP даже с одного сервера.

Крайне рекомендую сразу проработать API с мобильщиками и продумайте архитектуру (хотя бы на уровне структуры URL). Иначе можно напороться на грабли с обновлением клиента и версиями API.

Comments

[abalyasnikov]

спасибо за дельный ответ.

Answer 5

[Crash]

Может NodeJS пойдет?

Comments

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

можно даже более логично: комбинировать и то и то. Раз уж речь идет об играх, то скорее всего нужен будет какой-то демон уведомляющий пользователей через web sockets, и тут выгоднее взять node.js + socket.io, ибо избавляет от кучи гемороя с реализацией собственного сервера с асинхронным io. А уже все остальное писать на php так как это быстрее в силу известности автору языка.

Answer 6

[Vit]

Единственным доводом против PHP может быть в вашей ситуации только то, что вы его знаете хуже чем другой язык. Но если знаете лучше всего PHP - делайте на PHP.
Масштабировать легко - баллансировщик на nginx или HAProxy, за которым нужное количество серверов с PHP. В случае масштабирования на несколько серверов только надо иметь в виду, что если используете сессии, то хранить их надо не локально в файлах.
Скорость выполнения PHP-скриптов можно поднять за счет акселератора (например, APC).
Что касается выполнения долгих задач в фоне - можно по крону скрипты запускать, можно менеджер очередей использовать (RabbitMQ, Gearman,...).

Answer 7

[Артур Смирнов]

PHP Вам не очень подойдет, если планируете делать SOA или очереди с воркерами. На PHP сложно реализовывать сервисы (в смысле, незавершаемые процессы), и они получаются достаточно ресурсоемкими. Так же, PHP не очень подойдет, если планируете активно взаимодействовать с внешней средой - exec() прилично нагружает процессор.

Comments

[Алексей Сундуков]

"Постоянное соединение между приложением и сервером не держится." @abalyasnikov

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

@artursmirnov, это все спокойно решается введением менеджера очередей (rabbitmq, zeromq и т.д.). Я бы даже настоятельно рекомендовал такой подход, так как при нем демон можно будет писать не на php (тут и в правду есть свои нюансы) а на node.js

[smok]

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

Answer 8

[webus]

Я бы взял Python + Flask + MongoDb

Comments

[abalyasnikov]

Расскажите, пожалуйста, почему?

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

mongodb то почему? Вы же даже не знаете о каких именно данных идет речь. Раз речь идет о чем-то связанном с играми, то не думаю что монга тут лучше подойдет чем MySQL и уж точно не лучше postgre

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

и еще, почему flask? Он же не сильно подходит для реализации подобного (в смысле меньше чем другие варианты) Я так понимаю что вы просто свой стандартный стэк технологий описали...

[webus]

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

[webus]

@Fesor flask отлично подходит для реализации REST API.