Оптимізація продуктивності оновлень в PostgreSQL

Використання PG 9.1 на Ubuntu 12.04.

Наразі для запуску великого набору операцій UPDATE на базі даних, які мають форму:

UPDATE table
SET field1 = constant1, field2 = constant2, ...
WHERE id = constid

(Ми просто перезаписуємо поля об’єктів, ідентифікованих за ідентифікатором.) Значення надходять із зовнішнього джерела даних (ще не в БД у таблиці).

У таблицях є декілька індексів, кожен та відсутність зовнішніх ключових обмежень. COMMIT не робиться до кінця.

Щоб імпортувати pg_dumpцілу БД, потрібно 2 години . Це здається базовим рівнем, на який ми мусимо розумно орієнтуватися.

Окрім створення спеціальної програми, яка якимось чином реконструює набір даних для PostgreSQL для повторного імпорту, чи є щось, що ми можемо зробити, щоб наблизити основну продуктивність UPDATE до рівня імпорту? (Ми вважаємо, що це область, з якою ми вважаємо, що дерева злиття з структурованими журналами добре справляються, але нам цікаво, чи є щось, що ми можемо зробити в PostgreSQL.

Деякі ідеї:

• скасування всіх індексів без ідентифікації та відновлення після цього?
• збільшуючи контрольні_сегменти, але чи насправді це допомагає підтримувати довгострокову пропускну спроможність?
• використовуючи згадані тут методи ? (Завантажте нові дані у вигляді таблиці, а потім "зробіть" старі дані, де ідентифікатор не знайдеться в нових даних)

В основному є маса речей, які слід спробувати, і ми не впевнені, що є найбільш ефективним або якщо ми не помічаємо інших речей. Ми проведемо наступні кілька днів на експерименти, але ми подумали, що запитаємо і тут.

У мене є одночасне навантаження на стіл, але це лише для читання.

Припущення

Оскільки в Q немає інформації, я припускаю:

• Ваші дані надходять з файлу на сервері баз даних.
• Дані відформатовані так само COPY вихідні дані, з унікальним для id кожного рядка відповідним цільовій таблиці.
  Якщо ні, то відформатуйте спочатку належним чином або скористайтеся COPYопціями, щоб мати справу з форматом.
• Ви оновлюєте кожен рядок у цільовій таблиці або більшість із них.
• Ви можете дозволити собі скинути та відтворити цільову таблицю.
  Це означає відсутність паралельного доступу. Ще розглянути цю відповідь:
  • Найкращий спосіб заповнити новий стовпчик у великій таблиці?
• Залежні об'єкти взагалі відсутні, крім індексів.

Рішення

Я пропоную вам піти з аналогічним підходом, як описано в посиланням з вашої третьої кулі . З великими оптимізаціями.

Для створення тимчасової таблиці існує більш простий і швидкий спосіб:

CREATE TEMP TABLE tmp_tbl AS SELECT * FROM tbl LIMIT 0;

Єдиний великий UPDATEз тимчасового столу всередині бази даних буде швидше, ніж окремі оновлення за межами бази даних на кілька порядків.

У моделі MVCC PostgreSQL - UPDATEзасіб створити нову версію рядка та позначити стару як видалену. Це приблизно так само дорого, як INSERTіDELETE поєднанні. Плюс це залишає у вас багато мертвих кортежів. Оскільки ви все одно оновлюєте всю таблицю, було б загалом швидше просто створити нову таблицю і скинути стару.

Якщо у вас є достатня кількість оперативної пам’яті, встановітьtemp_buffers (лише для цього сеансу!) Досить високу, щоб утримувати таблицю темп в оперативній пам’яті - перш ніж робити щось інше.

Щоб отримати оцінку, скільки потрібно оперативної пам’яті, проведіть тест з невеликим зразком і використовуйте функції розміру об’єкта db :

SELECT pg_size_pretty(pg_relation_size('tmp_tbl'));  -- complete size of table
SELECT pg_column_size(t) FROM tmp_tbl t LIMIT 10;  -- size of sample rows

Повний сценарій

SET temp_buffers = '1GB';        -- example value

CREATE TEMP TABLE tmp_tbl AS SELECT * FROM tbl LIMIT 0;

COPY tmp_tbl FROM '/absolute/path/to/file';

CREATE TABLE tbl_new AS
SELECT t.col1, t.col2, u.field1, u.field2
FROM   tbl     t
JOIN   tmp_tbl u USING (id);

-- Create indexes like in original table
ALTER TABLE tbl_new ADD PRIMARY KEY ...;
CREATE INDEX ... ON tbl_new (...);
CREATE INDEX ... ON tbl_new (...);

-- exclusive lock on tbl for a very brief time window!
DROP TABLE tbl;
ALTER TABLE tbl_new RENAME TO tbl;

DROP TABLE tmp_tbl; -- will also be dropped at end of session automatically

Одночасне навантаження

Одночасні операції над таблицею (які я виключав у припущеннях на початку) зачекають, як тільки таблиця буде заблокована наприкінці, і завершиться невдачею, як тільки транзакція буде здійснена, тому що назва таблиці негайно вирішиться до її OID, але нова таблиця має інший OID. Таблиця залишається послідовною, але паралельні операції можуть отримати виняток і їх потрібно повторити. Деталі у цій відповіді:

• Найкращий спосіб заповнити новий стовпчик у великій таблиці?

ОНОВЛЕННЯ маршруту

Якщо ви (повинні) пройти UPDATEмаршрут, опустіть будь-який індекс, який не потрібен під час оновлення, і відтворіть його після цього. Набагато дешевше створити індекс в одній частині, ніж оновлювати його для кожного окремого рядка. Це також може призвести до гарячих оновлень .

Я окреслив аналогічну процедуру, використовуючи UPDATEв цій тісно пов'язаній з цим відповідь на ПЗ .

Якщо дані можуть бути доступними у структурованому файлі, ви можете прочитати їх із зовнішньою обгорткою даних та здійснити злиття на цільовій таблиці.