Як пояснити проблему запитів N+1 англійською мовою

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

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

** N+1 запит ** — шаблон, за допомогою якого один запит отримує список N елементів, за яким слідують N додаткових запитів (по одному на кожен елемент) для отримання пов’ язаних даних, замість одного запиту, який об’ єднує або розділяє пов’ язані дані на пакети. “Ця кінцева точка виконує один запит для двадцяти замовлень, потім ще двадцять запитів, щоб отримати кожного клієнта замовлення - це підручник N+1, і саме тому завантаження сторінки займає три секунди.”

** Лихове завантаження ** — шаблон, де пов’ язані дані завантажуються на запит, перший раз, коли вони доступні, а не заздалегідь — поширена основна причина проблем N+1, коли це відбувається всередині петлі, без того, щоб хтось це помітив. “ORM ліниво завантажує взаємозв’язок з клієнтом, тому кожна ітерація цього циклу беззвучно запускає свій власний запит - ніхто не написав двадцять запитів навмисно, це відбувалося один доступ за раз.”

** Eager loading ** — явне отримання пов’ язаних даних заздалегідь, у тому ж запиту або в одному пакетному наступному запиту, уникаючи шаблону запиту на елемент, який спричиняє проблеми N+1.

• “Ми перейшли на завантаження зв’ язку з клієнтом за допомогою одного з’ єднання, отже замість двадцяти одного запиту, ця кінцева точка тепер виконує точнісінько один запит.” *

** Пакетування ** — об’ єднання декількох окремих запитів у один запит за допомогою клаузули IN або подібної, отримання всіх пов’ язаних рядків для набору елементів одночасно, замість одного рядка за раз. “Замість повного з’єднання, ми з’єднали пошуки клієнтів в один запит з WHERE id IN (...) — той же результат, що і охоче завантаження, дешевше реалізувати, враховуючи те, як код вже був структурований.”

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

• Це N+1 — один запит для списку, потім один запит на елемент для пов’язаних даних
• Чи це ліниво завантажується всередині петлі, що, ймовірно, є причиною того, що вона повільна?»
• Чи можемо ми охоче завантажити це відношення замість того, щоб завантажувати його за елементом?»
• «Скільки фактичних поїздок по базі даних робить ця кінцева точка за запитом?»
• Чи можна було б встановити цю категорію в одному абзаці, якщо б вона була вказана в абзаці?

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

Пояснення вади інженеру під час перегляду коду: “Ця петля викликає order.customer для кожного з двадцяти порядків, і оскільки це відношення завантажується ліниво, він викликає окремий запит кожен раз — це двадцять один загальний запит для того, що повинно бути одним або двома. Чи можемо ми завантажити зв’язок з клієнтом в початковому запиту замість цього?»

Пояснення впливу для нетехнічної зацікавленої сторони:

• “Сторінка повільна через те, що ми отримуємо дані за кадром — замість того, щоб запитувати базу даних один раз на всі необхідні дані, код запитує її один раз на кожен елемент на сторінці. Для списку з п’ятдесяти пунктів, це п’ятдесят окремих поїздок навколо замість одного, і кожна поїздка навколо додається»

Опис виправлення у описі PR:

• “Встановлює N+1 на кінцевій точці списку порядку. Раніше завантаження кожного замовлення клієнта з окремим ліниво завантаженим запитом; тепер охоче завантаження через з’єднання, яке взяло це з ~ 40 запитів на запит до 1.” *

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

• Скажімо N+1, а не “це робить занадто багато запитів”, коли шаблон підтверджується - це точна, універсально визнана назва для цього точного режиму невдачі і каже товаришу по команді негайно, що шукати.
• Вказує на конкретний ** lazy loading ** виклик, що викликає петлю під час перегляду коду — “це відношення ліниво завантажується всередині петлі” є дієздатним; “ORM робить щось неефективне” не є.
• Запрошуйте охоче завантаження або пакетування явно як виправлення, а не просто «зменшити кількість запитів» — назва конкретної техніки говорить автору точно, які зміни робити.
• Для нетехнічної аудиторії, перекладіть концепцію в поїздки в обидві сторони («запитуючи базу даних п’ятдесят разів замість одного»), а не використовуючи жаргон ORM — вплив є тим, що їм потрібно, а не назва механізму.

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

1. Напишіть речення, яке пояснює проблему запиту N+1 для нетехнічного користувача.
2. Поясніть різницю між лінивим завантаженням і охочим завантаженням вашими словами.
3. Опишіть, як ви б сформулювали коментар про перегляд PR, що позначає підозрюваний N + 1.

Наприклад, мова опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови опису мови

Погляньмо правді в очі – «N+1» може звучати як технічний кошмар навіть для тих, хто знайомий з концепціями баз даних. Ключ до ефективного обміну інформацією про цю проблему не просто вказувати на проблему, а робити це з точністю і зосередженістю на впливі. Поширеною помилкою є просто сказати « У нас є запит N+1 ». Хоча це технічно правильно, це не передає терміни або не пояснює * чому * це важливо. Натомість, прагни до ясності і покажи, що розумієш наслідки. Сфокусуйтеся на тому, щоб розв’ язати проблему з точки зору користувацького досвіду – повільне завантаження, погана продуктивність – а не занурюватися в технічний жаргон.

Розгляньте, як ви можете обговорити це зі старшим розробником під час перегляду коду. Замість того, щоб сказати: «Я думаю, що ми маємо N+1 тут», спробуйте щось на зразок: «Я помітив, що коли ми отримуємо початковий набір продуктів, ми потім запускаємо окремі запити бази даних, щоб отримати пов’язані дані — наприклад, відгуки. Це створює каскадний ефект, що призводить до приблизно 20 додаткових запитів на завантаження сторінки продукту. Це значно впливає на час завантаження сторінок і може призвести до поганого користувацького досвіду. Бачите зміну? Тепер мова йде про * продуктивність * і * вплив на користувача *, а не лише про технічні деталі структури запиту.

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

Нарешті, пам’ ятайте, що чіткість у описі виправлення є не менш важливою. Замість того, щоб просто сказати: « Ми виправили N+1 », поясніть * як *. « Ми реалізували охоче завантаження для отримання пов’ язаних даних безпосередньо з бази даних у початковому запиту, зменшивши кількість окремих запитів до одного на продукт ». Це демонструє глибше розуміння і показує, що ви вийшли за рамки простої ідентифікації проблеми. Використання точної мови - “охоче завантаження”, “денормалізація” або “оптимізація JOIN” - показує вашу технічну компетентність і дозволяє іншим швидко зрозуміти рішення.