Будет ли приложение на платформе PHP Yii с базой данных MySQL обрабатывать ERP-решение для 20K сотрудников?

Question

У нас есть проект по созданию системы ERP для одной из крупнейших швейных отраслей Бангладеш.

У них около 20 000 сотрудников, и около 10% из них уходят / в месяц.Мы небольшая компания с 5 разработчиками PHP и не имеем большого опыта в таком большом проекте.Ранее мы разработали различные малые / средние проекты с использованием Codeigniter / Zend Framework и базы данных MySQL.

Для этого проекта мы решили использовать фреймворк Yii и MySQL или PostgreSQL.Там будет около 1 миллиона запросов к базе данных каждый день.Теперь мой вопрос: может ли MySQL / PostgreSQL справиться с этой нагрузкой или есть лучшая альтернатива?Это нормально делать с фреймворком Yii или есть лучшая фреймворк PHP для такого рода приложений?У нас есть всего 5 месяцев на создание модулей расчета заработной платы и управления сотрудниками.

Answer 1

С одной стороны, рассмотрите возможность использования PostgreSQL, а не MySQL. Вы будете иметь дело с критически важными данными, и, в целом, вы оцените это:

• У вас будет доступ к оконным функциям (полезно для отчетов), с операторами и гораздо более надежным планировщиком запросов.
• У вас будут дополнительные типы данных, а именно типы геометрии, которые можно использовать для оптимизации запросов, связанных с перекрытием диапазонов дат.
• У вас будет доступ к функциям полнотекстового поиска без необходимости использования механизма (MyISAM), который подвержен повреждению данных.
• У вас будет больше возможностей для реализации репликации БД (некоторые из которых встроены).

Что касается масштабируемости, будьте осторожны, что масштабируемость! = Производительность. Последнее о том, чтобы делать индивидуальные запросы быстрее; первый способ справиться с огромным количеством одновременных запросов, и часто приходит с небольшим ударом по последнему.

Для фреймворка PHP я никогда не использовал Yii лично, поэтому я не знаю, насколько хорошо он масштабируется. Но я совершенно уверен, что Symfony2 (или Symfony, если вы не пользуетесь бета-версией программного обеспечения) будет хорошо масштабироваться: его ключевые разработчики работают в веб-агентстве, основными клиентами которого являются средние и крупные организации малого размера.

Answer 2

Я думаю, что вы, возможно, задаете не тот вопрос.

У вас есть пять месяцев, чтобы построить систему ERP. Основные проблемы должны быть:

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

Я бы спросил, является ли производительность абсолютным приоритетом - она ​​не должна быть медленной, но многие системы ERP немного вяло. Оптимизация производительности часто означает обмен с другими приоритетами - например, система ORM повышает производительность труда разработчиков, но может быть медленнее, чем ручной SQL.

Что касается масштабируемости - до тех пор, пока у вас есть разумно разработанная схема, я не думаю, что 20 000 сотрудников являются серьезной проблемой для любой современной СУБД на достойном оборудовании.

Итак, на вашем месте я бы, вероятно, выбрал PostgreSQL по причинам, которые упоминает Денис. Никогда не использовал Yii, но это кажется вполне разумным. Я бы использовал ORM, пока вы не найдете ситуацию, когда производительность действительно неприемлема.

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

Answer 3

Я думаю, Yii будет хорошо работать с (относительно) большим количеством данных. Я использую Yii для управления 1,3 миллиона записей, несколько обновлений в день и несколько тысяч запросов в день на небольшом виртуальном хосте с потрясающей производительностью.

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

Ваш выбор базы данных будет важным моментом. Так Денис сказал, что некоторые важные мысли. Используя MySQL, вы, вероятно, должны изучить / определить правильный механизм хранения для ваших нужд.

Но есть некоторые моменты, которые я осознал, создав растущий проект с Yii. Вы должны подумать о таких вещах:

-Yii - это молодой фреймворк: поддерживаются новые технологии (например, ajax), но в некоторых особых случаях он немного незрелый: очень просто создать базовое приложение за несколько часов. Проблема может возникнуть из-за особой ситуации и требований. Пример: у них есть хороший механизм проверки для пользовательских вводов (HTML Forms). Но до Yii 1.1.6 это не работает с флажками HTML, начиная с Yii 1.1.7, флажки поддерживаются по умолчанию, но нет групп флажков. Другая проблема: Yii всегда использует псевдоним таблицы, который всегда равен «t». Это может быть проблемой! Иногда вы можете определить этот псевдоним, иногда нет (что противоречиво). Если вам нравится блокировать несколько таблиц в MySql, вы столкнулись с проблемой, потому что Yii вызывает каждую таблицу с одинаковым псевдонимом «t». Таким образом, вы не можете заблокировать таблицы в MySql по имени таблицы, а также невозможно заблокировать пару таблиц, которые вызываются одним и тем же псевдонимом. -> это конкретные проблемы, вы можете решить их, написав чистый PHP (не используя функциональность Yii). Что я пытаюсь сказать: фреймворк не будет полезным в самом случае, но в большинстве случаев.

-Yii легко расширяется. Легко добавить собственные расширения или функциональность. Поэтому многие из этих «небольших проблем» можно решить, написав собственные расширения, виджеты или переопределив методы.

-Yii поддерживает PHP 5.2. Yii совместим с 5.3, но (Yii работает на 5.3 - я все еще использую его со вчерашнего дня, он работает), но не поддерживает новые функции из 5.3 (может быть, вам нужен?) PHP5.3 будет (возможно) поддерживаться с Yii 2.0 - в будущем (2012)

-Yii имеет небольшое (но очень хорошее) сообщество.

- профессиональной поддержки нет (вы можете сообщать об ошибках в надежде, кто-нибудь исправит это - или вы исправите это самостоятельно)

-Yii - ОО PHP. Подумайте об этом, работая с объектами данных. Можно загружать большой объем данных в объекты Data. Но имейте в виду, что на вашем сервере приложений достаточно оперативной памяти (но это не относится к Yii)

В общем: мне нравится Yii, и если ваше приложение не слишком сложное, в конце вы получите массу удовольствия от красивого и мощного приложения.

Answer 4

Yii - очень гибкий, легкий и простой в изучении фреймворк PHP

Answer 5

Просто добавьте, что Yii очень хорошо масштабируется в обоих направлениях (т.е. добавление функциональности с использованием новых модулей и т. Д. И является одной из самых быстрых сред php, когда дело доходит до производительности).Единственный недостаток, который я вижу в Yii, заключается в том, что он имеет меньшую пользовательскую базу, поэтому немного меньшую поддержку, чем некоторые другие фреймворки, но это быстро меняется.Лучшая часть Yii - это генерация кода на основе gii, которая поможет вам быстро приступить к работе после того, как вы к ней привыкнете.