Является ли nginx / node.js / postgres очень масштабируемой архитектурой?

Question

У меня есть приложение, работающее с:

• один экземпляр nginx в качестве интерфейса (обслуживающий статический файл)
• кластер приложения node.js для бэкэнда (с использованием модулей cluster и expressjs)
• один экземпляр Postgres как DB

Достаточно ли этой архитектуры, если приложению требуется масштабируемость (это только для запросов HTTP / REST) ​​для:

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

• 20000 пользователей, подключенных одновременно

Где могут быть узкие места?

Answer 1

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

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

Если вам не требуется реляционная модель данных, то MongoDB может быть более масштабируемым выбором.

Еще одна вещь, которую нужно иметь в виду, это ваша сетевая инфраструктура. Если вы собираетесь добавить кластеры / узлы, убедитесь, что сеть может обрабатывать распределенную нагрузку.

И последнее: как правило, невозможно определить, может ли приложение в архитектуре справиться с определенной нагрузкой, без тестирования производительности, объема и стресса, поэтому ответом может быть «возможно».

Answer 2

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

Не зная гораздо больше данных от вас, дисковый ввод-вывод, скорее всего, станет вашим узким местом.Это произойдет в вашей базе данных PostgreSQL со скоростью около 10 тыс. Операций в секунду, если вы выполняете ввод-вывод с жесткого диска на стандартном оборудовании, а также замедляет работу, если вы выполняете JOIN для команды SQL.Это также замедлит работу большего числа одновременно работающих пользователей, пытающихся получить доступ к одному диску.Время поиска вашего накопителя будет сходить с ума, поскольку вы будете постоянно получать доступ к накопителю в случайном порядке.

Вам следует изучить структуру ваших данных и, если необходима реляционная база данных (нужно ли вам присоединиться?).Решением noSQL может быть путь.Всегда старайтесь сделать дисковый ввод-вывод максимально распределенным и последовательным.