Решения для архивирования баз данных

В продолжение вопроса, опубликованного мной на: Является ли хорошей идеей переместить таблицы с большим объемом и с большим доступом в отдельную базу данных? Я ищу различные методы / решения, доступные для архивирования баз данных в PostgreSQL.

Несколько решений, о которых я могу подумать:

1. Разделение таблицы
2. Отдельное табличное пространство и / или схема
3. Перемещение архивных записей / таблиц на другой жесткий диск

Любые другие предложения / указатели / решения действительно приветствуются и приветствуются.

ПРИМЕЧАНИЕ. Мы запускаем PostgreSQL v9.1.3 на CentOS5.2.

Мое предложение об архивации:

1. Создать archive_tablespace(если вы хотите, вы можете отделить оборудование в архиве)

2. Создавайте таблицы. Например, мы хотим заархивировать сообщения таблицы.

   create table  posts_all ( LIKE public.posts)  ;
   create table  posts_archive () inherits  ( public.posts_all)  ;
   alter table  public.posts  inherits ( public.posts_all ) ;

   После этого у нас будет две новые таблицы: public.posts_all (с такими же столбцами, как в сообщениях) для запроса всех сообщений (архив и производство) и public.posts_archive для запроса всех сообщений архива. Public.posts будет наследовать от posts_all.
   Вставки должны идти по-старому (в таблицу public.posts), если вы не напишите триггеры на posts_all для перенаправления вставок в таблицу posts. Если у вас есть разделение, это будет сложнее. С работающим приложением и до переноса старых данных вам не нужно ничего менять в коде приложения, чтобы работать с этим подходом.

3. Создать архив схемы для логического разделения. Я предлагаю разделить архивные данные на некоторый период времени (год или месяц), если это возможно (archive_2005).

4. Создать архивные таблицы в схеме archive_year

   create table archive_2005.posts (
     check(record_date >= '2005-01-01 00:00:00'::timestamp 
       and record_date <  '2006-01-01 00:00:00'::timestamp)
   ) inherits (posts_archive) tablespace archive_tablesapce;

   После этого у вас появятся новые записи таблицы в схеме archive_2005, и планировщик postgresql будет знать, что данные существуют только в заданный период времени. Если вы запросите другой период времени, postgresql не будет искать в этой таблице.

5. Создайте функции / процедуры / триггеры для перемещения данных в архивные таблицы.

6. Выполняйте архивирование один раз за период времени (год здесь) и очищайте старую таблицу или делайте это автоматически с помощью триггеров (тяжелее при автовакууме) Есть много преимуществ и недостатков в обоих методах.

Если реализовано:

1. Может запрашивать архив (выбрать * из posts_archive), все (выбрать * из posts_all) и производственные (выбрать * из public.posts) данные отдельно
2. Можно сделать дамп архивных схем отдельно и легко сбросить каскад на них. pg_dump -s archive_2005 datase_name отбрасывание схемы архив_2005 каскад; - будьте осторожны, потому что он удаляет все связанные таблицы
3. Старые данные разделены физически табличным пространством и логически схемой.
4. Довольно сложная структура для управления процессом архивирования
5. Может создавать разные индексы для производственных и архивных таблиц для оптимизации запросов к обоим (меньшие и специализированные индексы = более быстрые запросы и меньше места требуется)
6. Если у вас есть многораздельные таблицы (по годам или месяцам), процесс архивирования будет состоять в том, чтобы просто переместить всю таблицу archive_tablespaceили просто изменить ее для наследования от posts_archive (я не проверял это)
7. Если вы не хотите получать доступ к старым (заархивированным) данным, вам не нужно ничего менять в приложении.

Это общая техника, и вы должны адаптировать ее к вашим потребностям. Любые предложения по улучшению этого?

Дальнейшее чтение: наследование PostgreSQL , разбиение