@toddbarry

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

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

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

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

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

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

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

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

Войти через центр авторизации
Похожие вопросы
19 апр. 2024, в 05:01
999999 руб./за проект
19 апр. 2024, в 03:52
1000 руб./за проект
19 апр. 2024, в 03:01
1000 руб./за проект