Какую связку «фреймворк-СУБД» выбрать для веб-приложения на 1000 запросов в секунду?
Здравствуйте. Мне предстоит разработать RESTfull веб-приложение на питоне, которое будет получать крайне неравномерную нагрузку от пользователей. Предполагается, что большую часть времени оно будет вяло обмениваться данными примерно с десятью пользователями. Но в пиковом случае оно должно выдерживать до 1000-1200 пользовательских действий в секунду, в большинстве случаев предполагающих простой обмен HTTP-запросами между клиентом и сервером, а также чтение/запись из/в БД. Более серьезные вычисления, обмен файлами и т.п. будут происходить редко, долготекущих заданий типа отправки почты не предусматривается. Если предположить, что я деплою его на General Purpose-дроплете DigitalOcean (2 vCPU, 8 Гб ОЗУ - немного ограничен в бюджете), какая из следующих комбинаций фреймворка и СУБД лучше подойдет для заявленной цели: Flask+РСУБД (через SQLAlchemy, возможно с Celery - если он тут вообще нужен), aiohttp+РСУБД через тот же SQLAlchemy, или aiohttp+NoSQL (например, MongoDB, при условии, что мои данные не очень охотно поддаются денормализации)? Сервер nginx + Gunicorn.
В принципе, подойдёт любое решение.
Главное - это реализация очереди обработки.
При входящих запросах их нужно делить на зависимые и независимые и распределять по приоритетам.
Нужен каскад из двух последовательных типов очередей:
1. Внешний - последовательная обработка зависимых запросов (от одного или нескольких клиентов). Т.е., постановка в асинхронную очередь.
2. Внутренний - асинхронная и пакетная (один запрос к бд сразу для нескольких внешних запросов!) обработка параллельных независимых внешних запросов.
Таким образом, значительно снизится время ответа при высоких нагрузках к API (при большом количестве параллельных запросов в единицу времени).
Чуется хлебнёт автор пытаясь реализовать написанное в этом ответе на питоньих синхронных фреймворках. С aiohttp не знаком, но мне кажется и там такое сделать непросто будет
javedimka, Если такой подход не применять - останется одно: сразу искать тучу денег, сервов, оплату содержания/аренды всего этого дела и создать и настроить балансировку.
Или, что проще всего: не обеспечить нужный уровень сервиса на момент запуска и потом всё решать количеством серверов и/или переписыванием кода с нуля (рефакторинг - невозможен в данном случае).
В любом случае, это единственный вариант по обеспечению высоких нагрузок.
Кстати, он же, применим в онлайн-играх реального времени: шуттерах и стратегиях. Разводка сетевых пакетов там осуществляется по такому же принципу как на клиенте, так и на сервере.
xmoonlight, В питоне, как минимум, есть стандарт wsgi, который не даст собрать запросы в кучу и реализовать "пакетную" обработку, чтобы это ни значило. В питоне обычно не пишут свои http сервера которые позволяют разруливать http.
Подход может и не привязан, а вот инструментов может и не быть, а чтобы понять есть ли инструменты, нужно осмыслить подход или увидеть хотя бы пример. Из ответа мне, например, не понятно, что есть внешний каскад и что понимается под асинхронной очередью - если очередь это неблокирующие сокеты и поллинг с обработкой событий, а под "внешний каскад" понимается обработка входящих запросов от клиента к серверу, то ок, понятно что имеется ввиду, но почему только зависимые и что есть "зависимые" - нет.
А что под внутренней? Запросы в бд и к сторонним API, которые должно выполнить приложение для обработки запроса клиента? Тогда непонятно почему во "внутреннюю" очередь попадают внешние запросы
javedimka, там не было внешних и внутренних каскадов. Там был один двух-уровневый каскад. Поищите в инете как реализуется любая пакетная обработка данных.
Простой
