Очистка БД модуля принятия скоринговых решений
На каждом этапе сбора данных сохраняются полные логи запросов и ответов в БД Postgres. Тип хранения lob, даже после удаления данных, не позволяет вернуть место в систему и засоряет системные записи, которые не очищаются с помощью vacuum full, что приводит к исчерпанию лимита по дисковому пространству в дата-центре.
К нам обратилась компания СМСФинанс с проблемой: стремительно растущий объем данных в БД скоринга подходит к лимитам, которые может обеспечить дата-центр.
Итоги:
Уменьшение объема данных 35Тб -> 6.5Тб, уменьшение прироста 2.5Тб/мес ->300Гб/мес
Задача:
- Проанализировать
- Удалить
- Автоматизировать
Период работы:
- Первоначальный анализ показал, что каждый из микросервисов сохраняет полное состояние системы, до начала сбора своей части данных, и после завершения. Такое количество логов удобно во время отладки сервиса и для поиска проблем, но в долгосрочной перспективе абсолютно избыточно.
- Принято решение, что данные старше месяца необходимо прореживать, сохраняя только стартовый запрос с данными клиента и полную финальную модель данных после принятия скорингового решения. Реализован набор SQL скриптов для удаления старых данных. Скрипты выполнены в ненагруженное для системы время в течение недели.
- Неожиданная проблема: Данные хранились в БД в колонке типа large object, которая после удаления данных не очищала некоторые системные записи и не очищалась при помощи штатных средств без долгосрочной остановки БД. Это не позволяло вернуть свободное место в операционную систему и переиспользовать его для новых записей.
- Решено сохранять данные в колонку с новым типом, старые данные отдельной утилитой небольшими порциями мигрировать в новую колонку, старую колонку удалить.
- Работы проводили в ненагруженное для системы время в течение недели. Место стало доступно в системе, исчерпание лимитов перестало грозить сервису скоринга.
- Автоматизировали прореживание данных задачей по расписанию, добавили регулярный запуск vacuum в БД.
Команда:
Анализом и разработкой занималось 2 человека: DevOps и Java-разработчик, к выполнению части ночных работ привлекали системных администраторов заказчика, если требовалось взаимодействие с дата-центром.
Технологии:
- Java 8 и 11;
- PostgreSQL;
- Spring, Spring Boot.
“
Задача была интересна тем, что, проблему роста БД надо было решить оперативно, потому что расширить диск больше нельзя, а система буквально через пару недель упрется в лимит и прекратит работу. Особенно добавило проблем то, что full vacuum в PostgreSQL не чистит системные таблицы large object.
Java
PostgreSQL
Large objects cleanup
Обсудить проект_
Если у вас есть ИТ-проблема, оставьте ваши контакты, и мы поможем составить план ее решения. Обещаем не слать спам.
Нажимая, я говорю «Да»
политике конфиденциальности
политике конфиденциальности
Контакты_
