#anniversary #databases #bug
Вчора каналу Test Engineering Notes виповнилося 3 роки! Стартуючи канал, я й не думав, що буду писати так довго 😄. А ще - я навіть не сподівався, що канал виросте аж до 3500+ підписників! 🎉
Дякую вам усім за те, що продовжуєте читати! А я буду продовжувати ділитись з вами технічними та складними штуками зі світу тестування й інженерії.
То ж, не буде гаяти час - перейдемо до справи!
💼 Справа про зламані індекси в базі
Сьогодні я хочу поділитися з вами цікавим матеріалом - "When Postgres Indexing Went Wrong”. Ця стаття розповідає, як оптимізація перфомансу може піти не так, як планувалося. (Як часто й буває).
Була в одній компанії Postgres база даних, величенька за розмірами (десь мільярди рядків). Щоб зробити запити більш швидкими, розробники створювали індекси. Але просто індекси, а в паралелі - за допомогою
CREATE INDEX CONCURRENTLY. Перфоманс запитів покращився, можна святкувати!!!Але трохи згодом, почалися проблеми зі швидкістю запитів в базу. Швидкість яка поступово росла. Перфоманс бази бідкався, розробники розводили руками.
🔍 Що ж сталося?
- паралельна індексація проходить в два етапи: спочатку створюється індекс на основі снапшоту стану бази, а потім Postgres обробляє всі зміни, які пропустив.
- паралельна індексація - асинхронна та …. може ТИХО ВПАСТИ й залишити по собі зламаний індекс!
- у випадку компанії проблема була гіршою - бо дані були розділені між багатьма розділами (partitions)
❗️Як цього уникнути?
- користуйтеся флагом
CONCURRENTLY, коли створюєте індекси в продакшені- моніторьте індекси та перевіряйте їх вручну (за допомогою
EXPLAIN ANALYZE)Памʼятаймо: чим більше ми знаємо про системи та як вони можуть впасти - тим краще ми зможемо запобігти помилкам.
