Чому ОНОВЛЕННЯ Postgres тривало 39 годин?

У мене є таблиця Postgres з ~ 2,1 млн рядків. Я запустив оновлення нижче:

WITH stops AS (
    SELECT id,
           rank() OVER (ORDER BY offense_timestamp,
                     defendant_dl,
                     offense_street_number,
                     offense_street_name) AS stop
    FROM   consistent.master
    WHERE  citing_jurisdiction=1
)

UPDATE consistent.master
SET arrest_id=stops.stop
FROM stops
WHERE master.id = stops.id;

Цей запит зайняв 39 годин. Я працюю цим на 4 (фізичному) процесорі ноутбука i7 Q720 для ноутбука, багато оперативної пам’яті, більше нічого не працює переважна більшість часу. Немає місця на жорсткому диску. Нещодавно таблицю було вакуумовано, проаналізовано та перероблено.

Весь час роботи запиту, принаймні після початкового WITHзавершення, використання процесора зазвичай було низьким, а жорсткий диск використовувався 100%. HDD використовувався настільки важко, що будь-який інший додаток працював значно повільніше, ніж зазвичай.

Налаштування живлення ноутбука були на високому рівні (Windows 7 x64).

Ось ПОЯСНЕННЯ:

Update on master  (cost=822243.22..1021456.89 rows=2060910 width=312)
  CTE stops
    ->  WindowAgg  (cost=529826.95..581349.70 rows=2060910 width=33)
          ->  Sort  (cost=529826.95..534979.23 rows=2060910 width=33)
                Sort Key: consistent.master.offense_timestamp, consistent.master.defendant_dl, consistent.master.offense_street_number, consistent.master.offense_street_name
                ->  Seq Scan on master  (cost=0.00..144630.06 rows=2060910 width=33)
                      Filter: (citing_jurisdiction = 1)
  ->  Hash Join  (cost=240893.51..440107.19 rows=2060910 width=312)
        Hash Cond: (stops.id = consistent.master.id)
        ->  CTE Scan on stops  (cost=0.00..41218.20 rows=2060910 width=48)
        ->  Hash  (cost=139413.45..139413.45 rows=2086645 width=268)
              ->  Seq Scan on master  (cost=0.00..139413.45 rows=2086645 width=268)

citing_jurisdiction=1виключає лише кілька десятків тисяч рядків. Навіть з цим WHEREпунктом я все ще працюю на понад 2 мільйони рядків.

Жорсткий диск повністю зашифрований приводом TrueCrypt 7.1a. Те , що уповільнює трохи, але не досить , щоб викликати запит , щоб прийняти , що багато годин.

Час WITHзаймає лише близько 3 хвилин.

У arrest_idполі не було індексу для зовнішнього ключа. У цій таблиці є 8 індексів та 2 зовнішніх ключа. Усі інші поля запиту індексуються.

arrest_idПоле не було ніяких обмежень , крім NOT NULL.

У таблиці налічується 32 стовпці.

arrest_idмає різний тип характеру (20) . Я усвідомлюю, що rank()створює числове значення, але мені потрібно використовувати символи, що змінюються (20), оскільки у мене є інші рядки, де citing_jurisdiction<>1для цього поля використовуються нечислові дані.

arrest_idПоле було порожнім для всіх рядків з citing_jurisdiction=1.

Це персональний ноутбук високого класу (станом на 1 рік тому). Я єдиний користувач. Інші запити чи операції не виконувалися. Блокування здається малоймовірним.

Ні в цій таблиці, ні в іншому місці бази даних немає тригерів.

Інші операції з цією базою даних ніколи не займають ненормальну кількість часу. При правильній індексації SELECTзапити, як правило, досить швидкі.

Нещодавно у мене трапилось щось подібне зі столом у 3,5 мільйона рядків. Моє оновлення ніколи не закінчиться. Після багатьох експериментів і розчарувань я нарешті знайшов винуватця. Це виявились індекси в таблиці, що оновлюється.

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

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

Ваша найбільша проблема - це велика кількість важкої роботи на жорсткому диску ноутбука. Це ніколи не буде швидким, незалежно від того, що ви робите, особливо якщо це такий тип повільнішого накопичувача 5400 об / хв, що постачається на безлічі ноутбуків.

TrueCrypt сповільнює роботу записів більше, ніж "трохи". Читання буде досить швидким, але записи дозволяють RAID 5 виглядати швидко. Запуск БД на томі TrueCrypt буде тортурами для записів, особливо випадкових.

У цьому випадку я думаю, що ви витрачаєте свій час, намагаючись оптимізувати запит. Ви все одно переписуєте більшість рядків, і це буде повільно зі своєю жахливою ситуацією написання. Що я б рекомендував:

BEGIN;
SELECT ... INTO TEMPORARY TABLE master_tmp ;
TRUNCATE TABLE consistent.master;
-- Now DROP all constraints on consistent.master, then:
INSERT INTO consistent.master SELECT * FROM master_tmp;
-- ... and re-create any constraints.

Я підозрюю, що це буде швидше, ніж просто скинути і відтворити обмеження поодинці, тому що в UPDATE будуть досить випадкові шаблони запису, які вб'ють ваше сховище. Дві масові вставки, одна в незаблоковану таблицю і одна в таблицю з журналом WAL без обмежень, ймовірно, буде швидшою.

Якщо у вас абсолютно актуальні резервні копії, і ви не заперечуєте відновити базу даних із резервних копій, ви також можете перезапустити PostgreSQL з fsync=offпараметром і full_page_writes=off тимчасово для цієї масової операції. Будь-яка несподівана проблема, як втрата електроенергії або збої в ОС, залишить вашу базу даних невиправною fsync=off.

POSTGreSQL, еквівалентний "без реєстрації", полягає у використанні невідкритих таблиць. Ці незаблоковані таблиці обрізаються, якщо БД закривається нечисто, поки вони брудні. Використання незаблокованих таблиць принаймні вдвічі зменшить завантаження вашої записи та зменшить кількість запитів, тож вони можуть бути НАШОМО швидшими.

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

Хтось дасть кращу відповідь на Postgres, але ось декілька спостережень з точки зору Oracle, які можуть застосовуватися (а коментарі занадто довгі для поля коментарів).

Першим моїм питанням було б намагання оновити 2 мільйони рядків за одну транзакцію. В Oracle ви б писали попереднє зображення кожного оновлюваного блоку, щоб інші сеанси все-таки послідовно читали, не читаючи змінених блоків, і ви мали змогу відкатати. Це довгий відкат, який будується. Зазвичай вам краще робити дрібні шматки. Скажіть 1000 записів одночасно.

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

Oracle дозволяє "не вести журнал" натяки на заяви, щоб зупинити проїзд. Це прискорює багато тверджень, але залишає ваш db у ситуації, що не може бути відновлена. Таким чином, ви хочете зробити резервну копію раніше, а потім знову зробити резервну копію. Я не знаю, чи є у Postgres подібні варіанти.