#postgresql #performance #backup #restore
#postgresql #Производительность #резервное копирование #восстановить
Вопрос:
Я перехожу с собственной СУБД на PG. В проприетарной СУБД разделы данных «offlining» и «onlining» — это очень легкая операция. Я хочу реализовать аналогичную функциональность с помощью PG путем резервного копирования и восстановления отдельных таблиц (разделов). Очевидно, мне нужно избежать снижения производительности. Итак, мой вопрос в том, какой самый быстрый способ:
- Резервное копирование таблицы (раздела), как данных, так и индексов
- Перевод таблицы в автономный режим (что означает, что данные теперь удалены из базы данных)
- Восстановление таблицы (раздела), как данных, так и индексов
Как только у меня будет несколько советов, я смогу разработать более целенаправленные сравнения производительности. Заранее спасибо за любые указания.
Ответ №1:
Что быстро и должно быть быстрым, так это добавление или удаление раздела ( ALTER TABLE ... ATTACH/DETACH PARTITION ).
После того, как вы отсоединили раздел, вы не очень спешите создавать резервные копии / экспортировать данные. Это можно удобно сделать с pg_dump .
Аналогично, импорт данных для таблицы, которая должна стать новым разделом, обычно не критичен по времени.
Если вам нужно, чтобы это произошло быстрее (например, вы хотите, чтобы старый раздел был виден в другой базе данных, как только он будет отсоединен в старой), вы можете использовать логическую репликацию для репликации раздела в другую базу данных PostgreSQL перед его отсоединением. Как только репликация завершится, вы отсоединяете или удаляете исходный раздел и прикрепляете копию в другой базе данных.
Комментарии:
1. На самом деле, производительность резервного копирования не критична, но восстановление имеет значение. Мне нужно при необходимости вернуть разделы данных (резервные копии разделов таблиц) в оперативный режим (в довольно больших количествах). Общая производительность приложения пострадает, если это не быстро.
2. Что ж, тогда логическая репликация — это путь (требуется PostgreSQL > = v10).
3. Я не хочу, чтобы мои данные были «онлайн» в какой-либо базе данных, пока они мне не нужны. Но если я это сделаю, я хочу, чтобы он был быстро подключен к Сети. Так что на самом деле репликация logcal мне не помогает. Есть ли у PG способ быстрого подключения таблицы (раздела) к Сети? То есть, конечно, включая индексы. Если переиндексация является частью онлайна, то она никогда не будет достаточно быстрой для моего варианта использования. Это то, что я пытаюсь оценить. Если это невозможно сделать, я буду искать альтернативу.
4. Невозможно быстро получить много данных в базу данных, если это то, что вы имеете в виду под «в Онлайн». Существует возможность определить «внешнюю таблицу» на основе файла CSV с помощью
file_fdw, что очень быстро, но, конечно, тогда нет индекса (действительно ли исторические данные должны быть такими быстрыми?). Кроме этого, вы должны хранить данные в базе данных, но они не должны быть доступны (—> разрешения), если это вас беспокоит.