Очистка БД модуля принятия скоринговых решений

Сервис моментальных онлайн-займов Smsfinance 

Стремительно растущий объем данных в БД скоринга подходит к лимитам, которые может обеспечить дата-центр. На каждом этапе сбора данных сохраняются полные логи запросов и ответов в БД Postgres. Тип хранения lob, даже после удаления данных, не позволяет вернуть место в систему и засоряет системные записи, которые не очищаются с помощью vacuum full, что приводит к исчерпанию лимита по дисковому пространству в дата-центре.

Феврвль 2019 — Март 2019

3 человека: DevOps, Java-разработчик, системный администратор

Java 8 и 11, PostgreSQL, Spring, Spring Boot.

1. Первоначальный анализ показал, что каждый из микросервисов сохраняет полное состояние системы, до начала сбора своей части данных, и после завершения. Такое количество логов удобно во время отладки сервиса и для поиска проблем, но в долгосрочной перспективе абсолютно избыточно. 
2. Принято решение, что данные старше месяца необходимо прореживать, сохраняя только стартовый запрос с данными клиента и полную финальную модель данных после принятия скорингового решения. Реализован набор SQL скриптов для удаления старых данных. Скрипты выполнены в ненагруженное для системы время в течение недели.
3. Неожиданная проблема: Данные хранились в БД в колонке типа large object, которая после удаления данных не очищала некоторые системные записи и не очищалась при помощи штатных средств без долгосрочной остановки БД. Это не позволяло вернуть свободное место в операционную систему и переиспользовать его для новых записей.
4. Решено сохранять данные в колонку с новым типом, старые данные отдельной утилитой небольшими порциями мигрировать в новую колонку, старую колонку удалить.
5. Работы проводили в ненагруженное для системы время в течение недели. Место стало доступно в системе, исчерпание лимитов перестало грозить сервису скоринга.
6. Автоматизировали прореживание данных задачей по расписанию, добавили регулярный запуск vacuum в БД.