Англійська для пояснення Postgres VACUUM і Table Bloat

Процес VACUUM Postgres є однією з тих тем, які легко пояснити, але важко пояснити точно — і тут важлива точність, тому що нечіткі пояснення призводять до нечітких виправлень, таких як « просто запустити VACUUM більше », без розгляду справжньої причини роздутості. Цей підручник містить англійську лексику для обговорення розширення таблиць і точної настройки VACUUM.

Ключовий словник

** Мертва кортеж** — версія рядка, яка більше не видима для будь- якої активної транзакції (оскільки її було оновлено або вилучено), але яка все ще фізично займає місце на диску, поки її не буде очищено.

• “Кожна операція UPDATE у Postgres створює нову версію рядка, а не змінює її на місці, що залишає стару версію як мертву кортеж, доки VACUUM не поверне її.” *

** Роздутість таблиці ** — накопичення мертвих кортежів і невикористаного місця у таблиці з плином часу, що призводить до того, що таблиця займає більше місця на диску і її сканування відбувається повільніше, ніж це потрібно для отримання реальних даних. “Ця таблиця показує значне розширення — на диску 40 ГБ, але дані у реальному часі ближче до 12 ГБ. Решта — це мертві кільця, з якими autovacuum не впорався».

** Autovacuum ** — фоновий процес Postgres, який автоматично виконує VACUUM на таблицях, коли у них накопичуються мертві кортежі, налаштований за порігами, які визначають, наскільки агресивно буде виконуватися запуск.

• “Autovacuum відстає від цієї таблиці через типові параметри порігів — з нашим обсягом запису, нам потрібен більш агресивний autovacuum_vacuum_scale_factor спеціально для цієї таблиці.” *

** Обгортання транзакції ** — більш серйозний, невідкладний стан, коли внутрішній лічильник ідентифікатора транзакції Postgres наближається до свого обмеження, що вимагає виконання VACUUM, щоб запобігти втраті даних; відрізняється від звичайного очищення роздутих даних і обробляється з набагато більшою невідкладністю. “Це не рутинне очищення роздутих даних — ми знаходимося в межах обгортання транзакцій у цій таблиці, що є набагато більш невідкладною ситуацією, оскільки Postgres зрештою відмовиться від записів, щоб запобігти пошкодженню даних, якщо це не буде зроблено.”

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

• “Ми змінили структуру цього оновлення, щоб уникнути зміни будь- якої індексованої колонки, що дозволяє Postgres використовувати HOT- оновлення — це значно зменшує як накопичення перевантаження, так і вартість обслуговування індексу для цього конкретного шляху запису.” *

Звичайні фрази

• «Ця таблиця має значне розширення — розмір на диску набагато більший, ніж дані наживо могли б припустити»
• «Autovacuum не встигає за нашим обсягом запису на цій таблиці»
• Це не рутинне роздуття, це наближення до обгортання транзакції, що є невідкладним
• «Ми налаштували поріг автовакууму спеціально для цієї таблиці, а не для глобального типового»
• «Ця модель оновлення запобігає HOT-оновленням, тому що вона торкається індексованої колонки.»

Приклади висловлювань

Діагностика роздутості з конкретними числами, а не з нечітким описом: “Я виконав оцінку розширення на таблиці orders: на даний момент на диску є 85 ГБ, але оцінюваний розмір даних у реальному часі становить близько 30 ГБ. Це приблизно 65% набряк, який збігається з високим обсягом оновлення в цій таблиці з нашого функції відстеження стану замовлення. ”

Відрізняти звичайне розширення від більш невідкладного обгортання:

• “Щоб розуміти, що таке тяжкість: це не рутинне розширення, яке ми бачимо у більшості таблиць з великими записами. Ми вже використали 1,4 мільярда транзакційних ідентифікацій з приблизно 2 мільярдів перед тим, як захист обгортки почне діяти. Це потребує VACUUM запуску цього тижня, а не як частина рутинного обслуговування. ”*

Пояснення рішення про націлене автоматичне налаштування вакууму:

• “Замість зміни загальних параметрів автоматичного очищення, які б впливали на кожну таблицю у базі даних, ми встановили перевищення для кожної таблиці на orders : зменшення autovacuum_vacuum_scale_factor з типового значення 0. 2 до 0. 02, отже автоматичне очищення буде викликано після зміни приблизно 2% рядків замість 20%, враховуючи, наскільки велика кількість записів у цій таблиці.” *

Пояснення зміни схеми або запиту, яка зменшує наповнення у джерелі, а не лише лікує симптом:

• “Замість того, щоб просто більш агресивно налаштовувати автоматичне оновлення, ми змінили сам шаблон оновлення: ця можливість раніше оновляла стовпчик JSONB, що містив індексоване поле, під час кожного запису, запобігаючи оновленню HOT. Ми розділили це індексоване поле на власну колонку, тому більшість оновлень тепер кваліфікуються для HOT оновлень і генерують набагато менше набряку в першу чергу.”*

Професійні поради

• Цитата фактичний розмір диска проти оцінюваного розміру живих даних при описі роздутості — “85 ГБ на диску, ~30 ГБ живих даних” набагато переконливіше і діагностично, ніж “ця таблиця здається роздутою.”
• Відрізняйте чітко між ** рутинним очищенням роздутості ** і ** ризиком обгортання транзакції ** — останній є справжньою надзвичайною ситуацією з жорстким лимитом, і об’ єднання двох або викликає непотрібну паніку або, гірше, недостатню терміни.
• Коли ви пропонуєте автоматичне налаштування, вкажіть, чи є це глобальним параметром або перевизначенням для кожної таблиці — глобальні зміни мають ширший радіус дії і заслуговують більшої уваги, ніж цільові зміни до однієї таблиці з великою кількістю записів.
• Поясніть, що виправлення, які стосуються корінної причини (наприклад, перебудова оновлень для уможливлення HOT- оновлень) відрізняються від виправлень, які лише лікують симптом (наприклад, налаштування autovacuum для частішого запуску) — обидва варіанти є законними, але читач повинен знати, який з них ви пропонуєте.
• Використовуйте точні терміни — ** мертвий рядок, роздутість, автовакуум, обгортання ** — замість загальних фраз на зразок « проблема з підтримкою бази даних », оскільки кожен з цих термінів вказує на інший діагностичний шлях.

Практичні вправи

1. Напишіть речення, яке діагностує переповнення таблиці за допомогою значення фактичного розміру диска у порівнянні з розміром даних.
2. Напишіть речення, яке відрізняє рутинне очищення від надмірного обсягу від обов’ язкового обгортання транзакцій.
3. Напишіть речення, у якому буде пояснено, як виправити основну причину (наприклад, увімкнути оновлення HOT) у порівнянні з виправленням на рівні симптомів (наприклад, налаштувати автоматичне відкачування).

На практиці: Навігація нюансів в технічних дискусіях

Зрозуміти технічний жаргон - це одне; ефективно пояснити його колегам - особливо тим, чия перша мова не англійська - це зовсім інший рівень. Припустимо, що ви переглядаєте запит на витягування, який вводить новий конвеєр даних у Postgres, і розробник використовує термін « VACUUM » без надання контексту. Нерідний мовець може просто зрозуміти це як «видалити старі дані», що може призвести до нерозуміння його призначення. Щоб вирішити цю проблему, вам потрібно обговорити точну термінологію і пояснити основні принципи.

Поширений сценарій включає обговорення параметрів автовідкачування. Замість того, щоб сказати «Ми повинні налаштувати параметри autovacuum», більш корисним підходом буде: «Давайте розглянемо, як часто Postgres автоматично виконує VACUUM FULL в цій таблиці. Ціль полягає у тому, щоб зменшити * роздутість таблиці * — це коли старі, вилучені рядки залишаються у таблиці, збільшуючи фізичний розмір і сповільнюючи запиту, оскільки Postgres має сканувати більшу кількість даних, ніж це необхідно. Ви можете навіть сформулювати це питання так: « Чи можете ви описати дії « VACUUM FULL » у цьому контексті, зокрема, щодо того, як це впливає на швидкість запиту? » Це спонукатиме їх до того, щоб вони сформулювали своє розуміння, яке виходить за рамки самої команди.

Іншим корисним способом пояснення концепції мертвих кортежів є такий: « По суті, — ви можете сказати під час обговорення Slack, — процес автовилучення постійно вилучає «мертві кортежі » — рядки, на які більше не посилаються активні запити або транзакції. Це запобігає заповненню Postgres застарілими даними, що покращує загальну ефективність. » Після цього ви можете додати: « Важливо зауважити, що VACUUM не завжди є відповіддю; нам слід враховувати * частоту * і * тип * очищення на основі активності таблиці. » Це демонструє розуміння складнішого процесу, ніж просто видання команди.

Нарешті, під час написання опису PR уникайте нечітких тверджень на зразок « Виконано обслуговування ». Замість цього, будьте конкретними: « Оптимізовано обслуговування таблиці Postgres за допомогою налаштування параметрів автоматичного вилучення, щоб запобігти можливому перевантаженню таблиці і забезпечити ефективне вилучення мертвих рядків, таким чином покращивши швидкодію запиту ». Використання такого виду докладної мови забезпечує ясність і демонструє професійні навички спілкування, які є ключовими для ефективної співпраці у команді розробників.