Пул соединений с использованием pg-promise

Я автор pg-promise.

Я использую Node js и Postgresql и стараюсь быть максимально эффективным в реализации соединений.

Существует несколько уровней оптимизации взаимодействия с базой данных. Самый важный из них — минимизировать количество запросов на HTTP-запрос, потому что IO стоит дорого, как и пул соединений.

• Если вам нужно выполнить более одного запроса на HTTP-запрос, всегда используйте задачи с помощью метода задача.
• Если для вашей задачи требуется транзакция, выполните ее как транзакцию с помощью метода tx. .
• Если вам нужно сделать несколько вставок или обновлений, всегда используйте многострочные операции. См. Многострочная вставка с pg-promise и многострочные обновления PostgreSQL в Node.js.

Я видел, что pg-promise построен поверх node-postgres, а node-postgres использует pg-pool для управления пулом.

node-postgres начал использовать pg-pool с версии 6.x, в то время как pg-promise остается в версии 5.x, которая использует реализацию внутреннего пула соединений. Вот почему.

Я тоже читал, что больше 100 клиентов за раз - это очень плохо

Моя многолетняя практика в этой области подсказывает: если вы не можете поместить свой сервис в пул из 20 подключений, вы не спасетесь, выбрав больше подключений, вместо этого вам нужно будет исправить свою реализацию. Кроме того, при превышении 20 вы начинаете создавать дополнительную нагрузку на ЦП, что приводит к дальнейшему замедлению.

каков рекомендуемый размер пула для очень большой нагрузки данных.

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

что произойдет, если poolSize = 100 и приложение одновременно получит 101 запрос

Он будет ждать следующего доступного соединения.

Смотрите также:

• Связывание запросов
• Повышение производительности

2. что произойдет, если poolSize = 100 и приложение одновременно получит 101 запрос (или даже больше)? Обрабатывает ли Postgres заказ и заставляет ли запрос 101 ждать, пока он не сможет его выполнить?

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

1. каков рекомендуемый размер пула для очень большой нагрузки данных.

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

Также я нахожу документацию node-postgres довольно запутанной и вводящей в заблуждение по этому вопросу:

Как только вы получите> 100 одновременных запросов, ваш веб-сервер попытается открыть 100 подключений к серверной части PostgreSQL, и у вас закончится память на сервере PostgreSQL, ваша база данных перестанет отвечать, ваше приложение будет зависать, и все будет ломать. Буооо!

https://github.com/brianc/node-postgres

Это не совсем так. Если вы достигнете лимита соединений на стороне Postgres, вы просто не сможете установить новое соединение, пока не будет закрыто предыдущее соединение. Ничего не сломается, если вы справитесь с этой ситуацией в своем приложении узла.