Назад | Перейти на главную страницу

Как я могу масштабировать базу данных mysql с высоким уровнем ввода-вывода, используемым для заданий очереди с 300 рабочими?

В настоящее время я использую angular в интерфейсе для панели инструментов, которая отображает прогресс работников очереди. На бэкэнде я использую 50 экземпляров AWS EC2, каждый из которых имеет около 6 рабочих, и ими управляет супервизор. Эти рабочие берут на себя следующую работу, доступную в бессерверной БД Aurora Mysql. Эти рабочие много пишут в БД, а также много читают из нее, и я заметил, что операции чтения во внешнем интерфейсе замедляются. Например, при выполнении запроса axios get для получения информации о ходе работы иногда требуется 50 секунд для получения информации, а все последующие вызовы ajax откладываются.

Я попытался масштабировать БД до лучшего экземпляра, но мне кажется, что это неправильный подход, потому что все еще много задержек. Я думаю, это, вероятно, потому, что mysql не подходит для работы, а redis лучше подходит? Одно из решений, о котором я также подумал, - это иметь реплику для чтения, чтобы интерфейсная панель считывала с нее и получала информацию за миллисекунды. Недостатком этого подхода является то, что я использую api на бэкэнде, поэтому мне пришлось бы реплицировать api на другом экземпляре, и было бы два похожих api, включая тот, который доступен только для чтения.

Как вы думаете, какой подход будет лучшим?

Вы проверяли, какие запросы действительно вызывают наибольшую нагрузку на БД? Это те, кто проверяет, как продвигается работа? Если это так, вы можете запускать их только каждые несколько секунд и кэшировать результаты в Redis или кэш памяти (например. AWS ElastiCache). Обновления на панели управления обычно не должны быть на 100% точными и на 100% немедленными.

Аврора также поддерживает узлы только для чтения - возможно, вы сможете читать свои обновления с этих узлов R / O и не перегружать главный узел R / W материалами только для чтения.

Также убедитесь, что у вас есть правильные индексы в таблицах базы данных. Ты можешь использовать EXPLAIN SELECT ... с вашими наиболее частыми или самыми долгими запросами, чтобы убедиться, что они не просматривают таблицы. Индексы могут сделать огромный разница!

И, как сказал Тим, управлять очередью заданий гораздо лучше с помощью AWS SQS - рабочие выбирают задания из очереди одно за другим и не должны сканировать БД в поисках следующего.

Надеюсь, это поможет :)