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

Итоги:

Уменьшение объема данных 35Тб -> 6.5Тб, уменьшение прироста 2.5Тб/мес ->300Гб/мес

Задача:

  1. Проанализировать
  2. Удалить
  3. Автоматизировать

Период работы:

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

Команда:

Анализом и разработкой занималось 2 человека: DevOps и Java-разработчик, к выполнению части ночных работ привлекали системных администраторов заказчика, если требовалось взаимодействие с дата-центром.

Технологии:

  • Java 8 и 11;
  • PostgreSQL;
  • Spring, Spring Boot.
Задача была интересна тем, что, проблему роста БД надо было решить оперативно, потому что расширить диск больше нельзя, а система буквально через пару недель упрется в лимит и прекратит работу. Особенно добавило проблем то, что full vacuum в PostgreSQL не чистит системные таблицы large object.
Семён Бондарев, Java-разработчик Software Cats
Java
PostgreSQL
Large objects cleanup
Обсудить проект_
Если у вас есть ИТ-проблема, оставьте ваши контакты, и мы поможем составить план ее решения. Обещаем не слать спам.
Нажимая, я говорю «Да»
политике конфиденциальности
hello@softwarecats.dev
Новосибирск, ул. Демакова
23/5, оф.308
Контакты_