Comments 19
Для этих целей есть же известное давнее решение: ProxySQL – это прокси-сервер MySQL с открытым исходным кодом, держит коннекты, пул из нескольких серверов и десятки параметров... Использую это на многих проектах
Согласен с вами, ProxySQL - это хороший, проверенный временем индустриальный стандарт для балансировки и менеджмента пулов на уровне крупной инфраструктуры. На больших проектах с репликацией и десятками нод без него никуда.
Разница здесь исключительно в слоях абстракции. ProxySQL требует развёртывания как отдельного демона, настройки конфигурационных слоёв и администрирования.
Описанный же в статье кастомный пул - это скорее локальный учебный MVP и легковесный инструмент "на коленке" для простых асинхронных ботов или микросервисов, когда поднимать и администрировать полноценный прокси-сервер просто избыточно в рамках задачи.
Не надо десятков нод, чтобы ProxySQL был оправдан.
Вообще же нахожу некоторое противоречие - решаем хайлоад-проблему для телеграм-бота на бюджетной виртуалке. Тут вопрос ещё, из-за чего машина ляжет - из-за радутого пула коннектов, или из-за того, что обещанные CPU на виртуалке внезапно совсем не гарантированы.
У меня другая задача. Пул решает конкретную проблему. Когда условно на бюджетной виртуалке с 512 МБ RAM прилетает 300 параллельных запросов, MySQL падает от Too many connections. Это не CPU, это именно лимит соединений. Пул даёт переиспользовать 5 соединений вместо 300 - и БД перестаёт захлёбываться. По CPU - если запросы тяжёлые, он убирает оверх на открытие и закрытие сокетов, а если CPU всё-таки упирается - это следующий уровень оптимизации: индексы, кэш, рефакторинг запросов. Проект делал под Python-ботов
так стоп - на прелоадере картинка с гошными маскотами, а под капотом питон. Репа тоже с питоном
А по теме задачи - изначальнонужно строить что бы как можно меньше было горячих мест. Потому и существует отдельная дисциплина - высоконагруженные системы.
Каждый бэкенд-разработчик рано или поздно сталкивается с ситуацией, когда база данных MySQL внезапно ложится при резком пиковом наплыве пользователей
Не каждый, а только тот, кто зачем-то пользуется MySQL
А зачем если есть HicariCP. Проверен годами, в продакшене давно.
Звучит так что в этом кейсе вы просто уперлись в дефолтные настройки mysql, вполне возможно, что достаточно было увеличить thread_cache_size и max_connections в настройках сервера (и вообще не использовать дефолты). Коннекты в mysql не такие дорогие как например в postgres.
Ну и mysql.connector.pooling если мы про python приложение.
Еще не понятно что значит в статье «Мы разработали кастомный, легковесный асинхронный пул подключений на Python и драйвере aiomysql». Какая связь между вами и разработкой aiomysql? Если я правильно понял, в вашем тесте на гитхабе вы используете именно эту библиотеку, но контрибьюшена с этого аккаунта в репозиторий aiomysql не видно.
Когда прилетает запрос, он берет готовое соединение из коробки, выполняет команду
Угу, прощайте, кастомные настройки, пользовательские переменные, вре́менные таблицы, и всё прочее со scope=connection.
Неплохое решение для небольших проектов. Часто именно из-за неправильной работы с подключениями люди упираются в лимиты, хотя проблема не в самой MySQL.
Перегружать проект тяжёлыми инструментами, чтобы бот не падал при 100 запросах - ну такое, а тут даже без перегруза
А еще можно сделать пул динамическим (нижний/верхний уровень числа сессий). Плюс можно прикинуть, что некоторые запросы дешевле поставить в очередь, чем открывать к ним дополнительные соединения. А еще можно посчитать временнОй бюджет на исполнение запроса от пользователя и при нагрузочном тестировании разложить его на исполнение/ожидание внешних сервисов. Получится почти эталонная задача с собеседования в любой бигтех 10 лет назад.
MySQL под Хабраэффектом: кастомный асинхронный Connection Pool на Py, который экономит 80% RAM сервера