MySQL под Хабраэффектом: кастомный асинхронный Connection Pool на Py, который экономит 80% RAM сервера

[KKKSite]

Для этих целей есть же известное давнее решение: ProxySQL – это прокси-сервер MySQL с открытым исходным кодом, держит коннекты, пул из нескольких серверов и десятки параметров... Использую это на многих проектах

[laenij]

Согласен с вами, ProxySQL - это хороший, проверенный временем индустриальный стандарт для балансировки и менеджмента пулов на уровне крупной инфраструктуры. На больших проектах с репликацией и десятками нод без него никуда.

Разница здесь исключительно в слоях абстракции. ProxySQL требует развёртывания как отдельного демона, настройки конфигурационных слоёв и администрирования.

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

[FurySeer]

Не надо десятков нод, чтобы ProxySQL был оправдан.

Вообще же нахожу некоторое противоречие - решаем хайлоад-проблему для телеграм-бота на бюджетной виртуалке. Тут вопрос ещё, из-за чего машина ляжет - из-за радутого пула коннектов, или из-за того, что обещанные CPU на виртуалке внезапно совсем не гарантированы.

[laenij]

У меня другая задача. Пул решает конкретную проблему. Когда условно на бюджетной виртуалке с 512 МБ RAM прилетает 300 параллельных запросов, MySQL падает от Too many connections. Это не CPU, это именно лимит соединений. Пул даёт переиспользовать 5 соединений вместо 300 - и БД перестаёт захлёбываться. По CPU - если запросы тяжёлые, он убирает оверх на открытие и закрытие сокетов, а если CPU всё-таки упирается - это следующий уровень оптимизации: индексы, кэш, рефакторинг запросов. Проект делал под Python-ботов

[FurySeer]

Окей, если приложение дождётся выполнения 300-ого запроса - это конечно должно сработать

Не воспринимайте за нападки - я целиком и полностью поддерживаю учебные проекты, вы молодец!

[laenij]

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

[Void-Cowboy]

так стоп - на прелоадере картинка с гошными маскотами, а под капотом питон. Репа тоже с питоном

А по теме задачи - изначальнонужно строить что бы как можно меньше было горячих мест. Потому и существует отдельная дисциплина - высоконагруженные системы.

[laenij]

Спасибо за внимательность! На самом деле с прелоадером получилась пасхалка, я хотел использовать для след статьи.

[not_yours_ne]

Каждый бэкенд-разработчик рано или поздно сталкивается с ситуацией, когда база данных MySQL внезапно ложится при резком пиковом наплыве пользователей

Не каждый, а только тот, кто зачем-то пользуется MySQL

[FurySeer]

Точно, постргес из коробки держит любую нагрузку без лишних движений)

[BugM]

А зачем если есть HicariCP. Проверен годами, в продакшене давно.

[laenij]

пул создавался именно для легковесных асинхронных микросервисов на Python, где нет места тяжеловесным ORM и JVM. Это решение для тех, кто пишет на asyncio/aiogram и хочет контролировать каждый байт RAM на бюджетном VPS. HikariCP не поможет Telegram-боту на aiogram, который работает на Python.

[coh]

Звучит так что в этом кейсе вы просто уперлись в дефолтные настройки mysql, вполне возможно, что достаточно было увеличить thread_cache_size и max_connections в настройках сервера (и вообще не использовать дефолты). Коннекты в mysql не такие дорогие как например в postgres.

Ну и mysql.connector.pooling если мы про python приложение.

[coh]

Еще не понятно что значит в статье «Мы разработали кастомный, легковесный асинхронный пул подключений на Python и драйвере aiomysql». Какая связь между вами и разработкой aiomysql? Если я правильно понял, в вашем тесте на гитхабе вы используете именно эту библиотеку, но контрибьюшена с этого аккаунта в репозиторий aiomysql не видно.

[laenij]

Поверх драйвера aiomysql мы реализовали свой пул с фиксированным числом соединений и очередью на asyncio.Queue. Извиняюсь за неточную формулировку

[Akina]

Когда прилетает запрос, он берет готовое соединение из коробки, выполняет команду

Угу, прощайте, кастомные настройки, пользовательские переменные, вре́менные таблицы, и всё прочее со scope=connection.

[miharionov]

Неплохое решение для небольших проектов. Часто именно из-за неправильной работы с подключениями люди упираются в лимиты, хотя проблема не в самой MySQL.

[lapylia]

Перегружать проект тяжёлыми инструментами, чтобы бот не падал при 100 запросах - ну такое, а тут даже без перегруза

[Borikinternet]

А еще можно сделать пул динамическим (нижний/верхний уровень числа сессий). Плюс можно прикинуть, что некоторые запросы дешевле поставить в очередь, чем открывать к ним дополнительные соединения. А еще можно посчитать временнОй бюджет на исполнение запроса от пользователя и при нагрузочном тестировании разложить его на исполнение/ожидание внешних сервисов. Получится почти эталонная задача с собеседования в любой бигтех 10 лет назад.