@toddbarry

Стоит ли использовать асинхронный драйвер для postgres?

Есть приложение, которое должно поддерживать большое количество websocket соединений. В целях увеличения производительности и изучения aiohttp вцелом был запущен асинхронный бекенд (Позднее он будет проксироваться nginx'ом). Почитав о производительности драйвера для postgres под названием asyncpg, нагуглил orm, основанную на sqlalchemy, использующую этот драйвер. ORM называется Gino.
Скачал Gino, импортировал, создал базу и таблицы, протестировал запросы. Всё работает, и работает на первый взгляд хорошо.
Однако меня интересует - стоит ли запускать базу данных с асинхронным драйвером? Выполнение кода python не много ли дольше, чем поиск информации в базе? И не эффективнее ли будет стандартная многопроцессная парадигма работы postgres, когда на каждое подключение создаётся отдельный процесс.

Прошу поделиться мнением - когда использование асинхронной базы данных целесообразно, а когда нет?
П.С. Выбор асинхронного бекенд сервера не обсуждается и переход на синхронный не планируется.
  • Вопрос задан
  • 1927 просмотров
Решения вопроса 1
sergey-gornostaev
@sergey-gornostaev Куратор тега Python
Седой и строгий
Если взять какие-либо данные одинаковой структуры и объёма, то сортировка, группировка и агрегация этих данных в Python будет на порядок медленнее, чем в СУБД. Даже если в Python эти данные будут располагаться в памяти. Но передача результата обработки данных от СУБД в Python код будет на два порядка дольше, чем обработка их в Python. Именно ввод/вывод - это самая медленная часть. Настолько медленная, что на её фоне всё остальное - несущественные издержки. Эту проблему и решает асинхронность, позволяя программе вместо простаивания выполнять какие-либо полезные действия в момент ожидания ввода/вывода. Но это работает только в том случае, если абсолютно весь код асинхронный. Если один вызов блокирующийся, асинхронность всей остальной цепочки вызовов бесполезна.

И не эффективнее ли будет стандартная многопроцессная парадигма работы postgres, когда на каждое подключение создаётся отдельный процесс.

Кроме того можно ведь обращаться к синхронной базе на psycopg2 через run_in_executor()

И то и другое подходит пока у вас не больше 50 rps. Во-первых, каждый поток потребляет ресурсы сервера. Во-вторых, запуск, остановка и синхронизация потоков приводят к дополнительным издержкам. Эти два пункта справедливы и для процессов, только сказанное можно смело умножать на тысячу.
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
@deliro
Стоит как минимум потому, что с синхронными драйвером весь твой event loop будет ждать результатов из БД и смысла от него не будет

Плюс, судя по бенчам, asyncpg сильно быстрее остальных
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы