Для снижения нагрузки на базу данных монолитного приложения, разработчики применили комплексный подход, включающий анализ «медленных» запросов, вынос таблиц в отдельные базы данных и сокращение объёма хранимых данных. Сначала была проведена оптимизация запросов, на основе анализа slow query логов, что позволило снизить нагрузку на CPU и ОЗУ.
Для ускорения процесса разгрузки основной базы данных был разработан инструмент TableSwitcher. Он позволяет переключать чтение и запись отдельных таблиц на новую БД, минимизируя риски. Изначально используется одновременная запись в обе базы, затем переключение чтения и генерации ID на новую. Процесс включает в себя последовательное переключение стратегий, основанных на первичных ключах, и последующую миграцию отсутствующих данных.
При выборе таблиц для переноса, учитывались нагрузка, использование в коде, связанность с другими таблицами и актуальность переноса. Для выноса выбрали 13 таблиц, преимущественно содержащих данные логирования. Столкнулись с проблемами из-за ограничений на количество подключений к БД в облаке, а также из-за проблем переключения мастера в другом дата-центре, которые были решены с использованием HAProxy и PgBouncer.
Дополнительно были реализованы стратегии по сокращению размера БД. Это включало отсеивание забытых таблиц, удаление устаревших данных, поиск неиспользуемых таблиц и индексов, и, наконец, сокращение срока хранения информации о заказах. В результате, размер БД был уменьшен с 4 ТБ до 750 ГБ, что позволило перенести её в облако.
Изображение носит иллюстративный характер
Для ускорения процесса разгрузки основной базы данных был разработан инструмент TableSwitcher. Он позволяет переключать чтение и запись отдельных таблиц на новую БД, минимизируя риски. Изначально используется одновременная запись в обе базы, затем переключение чтения и генерации ID на новую. Процесс включает в себя последовательное переключение стратегий, основанных на первичных ключах, и последующую миграцию отсутствующих данных.
При выборе таблиц для переноса, учитывались нагрузка, использование в коде, связанность с другими таблицами и актуальность переноса. Для выноса выбрали 13 таблиц, преимущественно содержащих данные логирования. Столкнулись с проблемами из-за ограничений на количество подключений к БД в облаке, а также из-за проблем переключения мастера в другом дата-центре, которые были решены с использованием HAProxy и PgBouncer.
Дополнительно были реализованы стратегии по сокращению размера БД. Это включало отсеивание забытых таблиц, удаление устаревших данных, поиск неиспользуемых таблиц и индексов, и, наконец, сокращение срока хранения информации о заказах. В результате, размер БД был уменьшен с 4 ТБ до 750 ГБ, что позволило перенести её в облако.
