Задать вопрос
vitalets
@vitalets

Уменьшение размера БД

Всем привет,

хочу получить ваш совет по следующей задаче:
есть mysql база, в которой для работы в основном используются недавно добавленные записи (за последние 1-2 месяца). После использования данные по сути просто лежат в бд, занимая место и замедляя работу.
Но удалить их нельзя, т.к. иногда (нечасто) приходится делать отчеты за длительный срок, например за год и больше.
Вопрос — как все это оптимизировать?

Вариант 1:
Создать копию бд, которая будет служить архивом и раз в неделю переносить данные из основной базы старше 2-х месяцев. Использовать sql-скрипт c выражениями вида:
insert archive.document select * from prod.document where create_date <= DATE_SUB(now(), interval 2 month);
delete * from prod.document where create_date <= DATE_SUB(now(), interval 2 month);

Но как в этом случае писать запросы за длительный срок?
Использовать сложные скрипты с UNION или собирать общую базу из двух частей? И то и другое видится не очень удобным…

Вариант 2:
Опять же создать копию бд, которая будет служить архивом и настроить на нее репликацию. И потом каким-то хитрым образом удалять древние строки из основной базы, но чтобы эти изменения не реплицировались. Возможно ли такое в принципе?

Может есть еще какие-то варианты?
Спасибо!
  • Вопрос задан
  • 4105 просмотров
Подписаться 3 Оценить Комментировать
Ответ пользователя Владимир К ответам на вопрос (7)
Я человек не образованный, УЗов не заканчивал — учился в основном по доступным книгам, так что сильно не пинайте :)
Есть такой термин как «денормализация данных». Я для таких случаев придумал для себя «денормализацию таблиц».
Например, у нас есть новостной ресурс, в котором нельзя физически удалять новости. Т.е. удаленные новости должны быть доступны при необходимости из панели управления, но для клиентской части они «отсутствуют». Я делал дубликат таблицы, в которую при удалении переносил запись со всеми полями. Это разгружало рабочую таблицу, но нагружало приложение в случае необходимости запроса к удаленной записи. А в виду того что таких запросов обычно в тысячи раз меньше — я остановился на таком подходе.

Т.е. я в своих решениях использовал (при необходимости) union совместно с кешированием.
Ответ написан