2016-11-07 1 views
0

я использовал, чтобы иметь 9.2 базы данных PostgreSQL с 3 таблицами:Перенос данных между базами данных не увеличивая производительность

A - contains 12 millions records 
B - contains 24 millions records 
C - contains 20 millions records 

Таблицы связаны как:

A (one to many) B 
B (one to zero/one) C 

Я decieded в архив/мигрировать старше данные для второй базы данных для ускорения моей основной базы данных (меньше данных = более высокая производительность).

После того, как я перенес около 20% данных из каждой таблицы, я сделал VACUUM ANALYZE на моих основных таблицах базы данных, чтобы немного почистить.

Я думал, что следующие 20% будут намного быстрее мигрировать .... Я был неправ. Каждый следующий процент данных для архивирования процесса медленнее и медленнее ...

Я подумал, что, возможно, VAACUM FULL нужен здесь, но я прочитал его не рекомендуется. Более того, это очень медленный запрос и требует почти вдвое больше дискового пространства (он создает новую таблицу, а затем удаляет старый).

Что может быть причиной более медленной обработки, несмотря на то, что осталось меньше данных? Я пропустил какой-то шаг, который может увеличить скорость моей базы данных после миграции? Какой-то очистить другие тогда VACUUM ANALYZE

Необходимо указать, что у меня есть время обработки 3 шага: выбор данных для копирования из основной базы данных, вставка в 2-ю базу данных, удаление из основной базы данных.

Выбор данных является проблемой.

О процессе архивирования:

  1. я выбираю А строки таблицы старше х дней. Скопируйте его и удалите.
  2. Затем я выбираю строки B, связанные с ранее выбранными строками. Скопируйте его и удалите.
  3. Последнее, что я выбрал, строки C, связанные со строками B, выбранными ранее. Скопируйте его и удалите.

Конф:

8GB ОЗУ.

max_connections = 100 
shared_buffers = 2GB 
effective_cache_size = 6GB 
work_mem = 32MB 
maintenance_work_mem = 512MB 
checkpoint_segments = 32 
checkpoint_completion_target = 0.9 
wal_buffers = 16MB 
default_statistics_target = 100 
random_page_cost = 2.0 
+1

Опубликовать код миграции SQL и определения этих таблиц. –

+0

Как я понимаю, эти 3 шага независимы друг от друга. Они? И что вы нашли шаг номер 1 виновником? –

+0

@ClodoaldoNeto. Шаги 1 и 2 связаны - 'вставлять в A из select ....'. Однако я попробовал запустить 'select' independent и выяснить, что он длится около 2 минут, где' insert' + 'select' длится 2,5 мин. – ilovkatie

ответ

0

Постарайтесь выяснить, где потрачено время. Это SELECT, чтобы найти строки в B и C? Это DELETE?

После того, как вы нашли проблематичное утверждение, посмотрите на вывод EXPLAIN (ANALYZE); он скажет, что вы потратили время.

Удаление строк из таблицы не делает их меньшими и не обязательно ускоряет запросы в таблице. Что такое может help is VACUUM (FULL), особенно если есть последовательные сканирования. Вам не нужно запускать его на все таблицы в базе данных; если пространство является проблемой, вы можете настроить его на один стол за другим.
Но сначала посмотрите планы выполнения, чтобы убедиться, что это вообще поможет.

+0

Я проверил планировщик запросов - он использует только индексный просмотр. Возможно ли, что в этом случае требуется REINDEX? – ilovkatie

+0

Возможно, особенно если сканирование индекса сканирует большие части индекса. Трудно сказать без планов исполнения. –

Смежные вопросы