Vocabulary for Discussing Database Performance in English
Англійський словник для роботи з базами даних: індекси, плани запитів, проблеми N+1, блокування і фрази, які інженери використовують для діагностики і виправлення повільних запитів.
Коли база даних сповільнюється, сповільнюється і вся програма — отже, проблеми з продуктивністю виникають постійно. Вони повні спеціалізованого словника: індекси, плани запитів, проблеми N+1, тупики. У цьому підручнику наведено основні терміни, поширені фрази і приклади речень для обговорення швидкодії бази даних англійською мовою.
Основні концепції діяльності
| Term | Meaning |
|---|---|
| Index | A data structure that speeds up lookups. |
| Query plan | The steps the database takes to run a query. |
| Full table scan | Reading every row (usually slow). |
| Cardinality | The number of distinct values in a column. |
| Latency | How long a query takes to return. |
| Throughput | How many queries per second. |
- “Цей запит виконує повну перевірку таблиці — нам потрібен індекс у стовпчику
user_id.” *
Мова повільних запитів
- Запит може бути повільним, дорогоцінним або важким.
- Це може ** заблокувати ** базу даних (надіслати занадто багато запитів).
- Цей параметр може ** блокувати ** рядки, на які чекають інші.
- Якщо програма працюватиме занадто довго, може виникнути ** тайм- аут **.
- “Цей запит на звіт є дуже дорогим — він об’ єднує п’ ять таблиць і агрегує мільйони рядків.” *
Слово “дорогоцінний” відноситься до вартості ресурсу, а не грошей — ключовий біт англійської бази даних.
Задача n + 1
Це так часто трапляється, що заслуговує власного розділу.
“У нас тут є проблема N+1 — ми завантажуємо список, а потім запускаємо окремий запит для кожного елемента. Це сто запитів замість одного.»
Зазвичай, виправлення полягає у:
- « Давайте об’ єднаємо ці дані в один запит за допомогою об’ єднання або скористаємося швидким завантаженням. » *
Знаючи “N+1”, “batch”, і “eager loading” миттєво сигналізує про плавність роботи з базою даних.
Індексація лексики
- щоб ** додати ** / ** створити ** індекс
- ** складений ** індекс (на декількох стовпчиках)
- ** вкрай короткий ** індекс (містить всі дані, необхідні для запиту)
- індекс ** роздутий ** (індекс, який з часом став неефективним)
- ** відсутній ** індекс (який повинен бути, але його немає)
“Складений індекс на
(status, created_at)дозволить цей фільтр і сортування за один раз.”
Але індекси мають свою ціну:
- “Індекси прискорюють читання, але уповільнюють запис, тому не варто додавати їх для кожного запиту.” *
Читання плану запиту
| Phrase | Meaning |
|---|---|
| ”It’s using the index.” | Good — fast lookup. |
| ”It’s doing a sequential scan.” | Reading everything; often slow. |
| ”The estimate is way off.” | The planner’s row estimate is wrong. |
| ”It’s spilling to disk.” | The operation exceeded memory. |
“Дозвольте мені запустити EXPLAIN — так, він виконує послідовне сканування, оскільки індекс не використовується.”
Дієслово “to EXPLAIN a query” (запустити аналізатор плану) є звичайним інженерним скороченням.
Блокування і одночасність
- a ** lock ** — блокування рядка або таблиці.
- ** заблоковано ** — дві транзакції, кожна з яких чекає на іншу.
- ** dispution ** — багато запитів, які конкурують за один і той же ресурс.
- ** довготривала транзакція ** — така, яка занадто довго утримує блокування.
- “Ми бачимо суперечку за блокування на столі замовлень в години пік.” *
- “Ця затримка сталася через те, що дві транзакції оновили ті ж рядки у різних порядках.” *
Використовує словосполучення
- для оптимізації запиту
- для ** профілю ** бази даних
- для ** налаштування ** налаштувань
- ** денормалізувати ** для швидкості читання
- для ** shard ** / ** partition ** великих таблиць
- для ** кешування ** часто використовуваних результатів
- “Ми могли б денормалізувати це, щоб уникнути з’ єднання, але це додасть складності записам.” *
Фрази для діагностики проблем
- « Де знаходиться вузька смуга — запит, диск або пул з’ єднань? » *
- “Журнал повільних запитів вказує на цю одну агрегацію.” * “З’ єднання перевантажені; ми ставимо запити в чергу.” “Це стало повільніше, коли таблиця зростала — вона не масштабується.”
Люди плутають слова
| Confused | Clarification |
|---|---|
| Index vs key | A key enforces uniqueness; an index speeds lookups (often both). |
| Normalise vs denormalise | Normalise removes duplication; denormalise adds it for speed. |
| Latency vs throughput | Latency is per-query speed; throughput is volume. |
| Lock vs deadlock | A lock is normal; a deadlock is a stuck cycle. |
Вирок на практиці
“Ця кінцева точка повільна через проблему N+1 — ми виконуємо один запит на рядок. Я б з’єднав їх з’єднанням і додав складний індекс на
(status, created_at). Це повинно перетворити сотню запитів в один і дозволити йому масштабуватися».
Якщо ви можете вільно говорити цю фразу, ви можете вести обговорення щодо швидкодії бази даних.
За допомогою цього словника ви зможете діагностувати і обговорити майже будь- яку проблему у базі даних англійською мовою — від виявлення повного сканування таблиці до виправлення N+1, а також пояснити, чому індекс прискорює читання, але уповільнює запис. Використовуйте прикладні речення як шаблони, утримуйте ваші пари нормалізувати/ денормувати і затримка/ пропускна здатність у правильному положенні, і ви будете звучати як інженер, який знає, де знаходиться вузька місцина.
На практиці: навігація, зворотний зв’язок і співпраця
Багато з термінів, які ми обговорювали - затримка, пропускна здатність, вузької місцини, оптимізації запиту - може здатися абстрактним, коли ви намагаєтеся ефективно спілкуватися з колегами, особливо якщо англійська не є вашою першою мовою. Легко впасти в надто технічні описи, які залишають інших збентеженими або відчувають себе виключеними з розмови. Ключова відмінність між хорошим і поганим спілкуванням з базою даних полягає в тому, щоб обґрунтувати проблему в практичному контексті, демонструючи * вплив *, а не просто повторюючи жаргон.
Розглянемо сценарій: ви переглядали запит на витягування, який вводить нову функцію, яка витягує дані з таблиці users. Розробник написав запит, який здається простим. Проте, під час перегляду ви зауважили потенційну проблему — за допомогою програми виконується велика кількість окремих запитів замість одного оптимізованого запиту. Ви не зможете відразу сказати: « Це проблема N+1! » Замість цього ви можете почати з чогось більш доступного, наприклад: « Я бачу, що цей запит виконується декілька разів для кожного запису користувача. Це може призвести до значного зниження продуктивності, оскільки кількість користувачів зростає — що може вплинути на час завантаження сторінки і загальну швидкість відповіді програми. ” Продовжуйте, пропонуючи рішення: “ Можливо, ми могли б ввести індекс на стовпчику user_id, або реструктурувати запит для виконання одного з’ єднання проти пов’ язаної таблиці orders. Чи ви готові дослідити ці варіанти?» Цей підхід зосереджено на * ефекті * проблеми — повільнішому завантаженні сторінок — і надає конкретні пропозиції щодо поліпшення.
Інша ситуація може виникнути в Slack під час розслідування інциденту. Молодший розробник повідомляє, що певний звіт виконується дуже повільно. Замість того, щоб відразу ж перейти до пояснення концепцій, таких як «план виконання типу сканування», вони могли б сказати: «Звіт займає багато часу для створення. Я бачу високе використання процесора на сервері бази даних, і план запиту показує, що він виконує повне сканування таблиці. Це означає, що він читає кожен рядок в таблиці products, яка досить велика. Нам слід розглянути можливість додавання індексу, щоб прискорити цей процес. » Ключовим у цьому випадку є перетворення технічних відомостей у зрозумілі терміни для всіх членів команди, незалежно від їх досвіду роботи з базами даних.
Нарешті, під час написання опису PR, який пояснює зміни, внесені для поліпшення швидкодії запиту, уникайте надто складних пояснень. Ясне і коротке твердження на кшталт: “Оптимізовано запит get_user_orders додаванням індексу на user_id. Це зменшує сканування повної таблиці і значно покращує час відповіді для отримання даних замовлення користувача.” є набагато ефективнішим, ніж довге пояснення того, як працює індекс або чому він корисний.
Ось приклад використання EXPLAIN ANALYZE для дослідження запиту:
EXPLAIN ANALYZE SELECT * FROM users WHERE id = 123;За допомогою цієї команди можна отримати докладні відомості щодо того, як PostgreSQL виконує запит, зокрема, кількість сканованих рядків, час виконання кожного кроку, а також чи використовувався індекс. Поширення цього виводу — підсвічування « повного сканування таблиці » — це потужний спосіб повідомити про проблему безпосередньо вашій команді.