Forbidden
@Forbidden
CEO, CTO @ a-parser.com

PostgreSQL — как архивировать старые записи в большой таблице?

Есть таблица:
  • 100 млн записей
  • каждый день прирост 1-2 млн записей
  • горячие данные - за последний месяц


На данный момент база крутится на SSD дисках, ищем вариант оптимального архивирования старых записей, пока вырисовывается такое решение:
  • поднимаем второй сервер на больших HDD дисках
  • по крону складываем старые записи
  • меняем код приложения - добавляем запросы к 2ум базам на основе необходимой даты


Больше всего смущает последний пункт, существует ли прозрачное решение отправки 2ух запросов к разным базам и автоматическое слияния результата?
Может есть более правильный подход к данной проблеме?
Что делать когда данных станет больше и понадобиться уже несколько серверов для архивации?
  • Вопрос задан
  • 2257 просмотров
Решения вопроса 1
Melkij
@Melkij
PostgreSQL DBA
Как разделить таблицу, горячие данные оставить на SSD, холодные - на HDD. Для этого во-первых партицирование для разделения таблицы на две. https://habrahabr.ru/post/273933/ (как обычно, внимание на комменты и pg_partman)
Затем, до миграции данных (или сразу при создании партиций), перенос архивных в другой tablespace www.postgresql.org/docs/current/static/sql-createt... stackoverflow.com/a/11228536 на HDD.
Затем миграция данных на партиции.
Вообще-то, это уже может быть вполне достаточно. 1-2млн строк * 365 дней это не запредельно много. Хотя не указан характер данных.

Прозрачный для приложения перенос таблиц на другую железку - FDW, foreign data wrapper. Чем актуальнее postgresql - тем лучше. Пилится штука весьма активно по части оптимального распределения запроса. Дружит ли уже с партицированием - честно, не в курсе.

Прозрачно отправить запрос на две базы и склеить - элементарно view с union all из локальной таблицы и FDW. Только это неинтересный вариант, зачем для запроса на горячие данные дёргать холодную часть базы?

Вдобавок, можете посмотреть в сторону postgresql-xl, greenplum. Первый года полтора назад был не вполне production-ready, сейчас не знаю, второй используется даже в банковской сфере, но как мне помнится катастрофически не годится для OLTP, только OLAP нагрузка.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы