В настоящее время мы изучаем, как мы могли бы масштабировать систему, в которой у нас много пользователей, каждый со своей собственной схемой postgres и своими учетными данными пользователя БД, чтобы обеспечить изоляцию. Однако это означает, что каждому пользователю фактически потребуется собственное подключение к базе данных, а поскольку количество одновременных открытых подключений к серверу postgres довольно ограничено из-за накладных расходов памяти для каждого подключения на сервере, мы ищем возможные решения. pgBouncer Было бы неплохо использовать и мультиплексировать несколько входящих подключений к фиксированному пулу подключений к фактической базе данных, однако мы не смогли подтвердить, что изоляция пользователя на основе учетных данных пользователя и схемы базы данных может быть сопоставлена с этим сценарием.
Сеансы пользователей и, следовательно, время жизни соединения имеют продолжительность пару минут, но не используются интенсивно (одна транзакция БД с соответствующим пакетом запросов каждые пару секунд), а запросы нет чувствителен к задержке, поэтому мы могли технически отключаться между транзакциями и переподключаться по требованию с помощью прокси-сервера, такого как pgBouncer сохранение состояния соединения. Говоря о состоянии, приложение не использует именованные подготовленные операторы, поэтому состояние на стороне сервера, вероятно, в любом случае невелико, но, поскольку база данных размещена в облаке, мы также не можем легко изменить max_connections конфиг на сервере.
Есть ли способ сопоставить этот сценарий с pgBouncer или аналогичный прокси?
