Рішення архіву бази даних

На продовження запитання, яке я опублікував на тему: Чи корисно перемістити таблиці з великим обсягом та з великим доступом до окремої бази даних? , я шукаю різні методи / рішення, доступні для архівування баз даних у 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 ) ;

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

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;

   Після цього у вас з'являться нові записи таблиці в архіві схеми_2005, і планер postgresql буде знати, що дані існують лише у розроблений період часу. Якщо ви запитуєте інший часовий період, у цій таблиці не буде здійснюватися пошук postgresql.

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

6. Зробіть архів один раз на часовий проміжок (рік тут) і відпиліть стару таблицю або зробіть це автоматично за допомогою тригерів (важче на автовакуумі). В обох методів є багато переваг і недоліків.

Якщо реалізовано:

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

Це загальна техніка, і ви повинні адаптувати її до своїх потреб. Будь-які пропозиції щодо покращення цього?

Подальше читання: успадкування PostgreSQL , розділення