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

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

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

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

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

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

** Пакетування ** — об’ єднання багатьох окремих запитів у один запит за допомогою клаузули IN або подібної, таким чином пов’ язані дані для багатьох записів буде отримано одночасно. “Пакетування перетворило 50 пошуків окремих клієнтів в один запит за допомогою клаузули IN для всіх 50 ідентифікаторів клієнтів.”

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

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

• «Це N+1 запит проблема — один запит для отримання [X], потім один запит на [X] для отримання [пов’язаних даних].»
• «Кількість запитів на цій кінцевій точці пропорційна [N], що є сильним сигналом N+1 шаблону, який ховає десь у петлі»
• «Ми повинні охоче завантажувати [відношення] тут, замість того, щоб покладатися на лінь завантаження, оскільки ми вже знаємо, що ми будемо потребувати його для кожного запису»
• «Пакетування цього в один запит з клаузулою IN скоротить це з [N] запитів до одного»
• «Це виглядало швидко в тестуванні, тому що у нас була лише горстка записів — шаблон N+1 стає видимим тільки при реалістичному обсязі даних»

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

Діагностика проблеми під час перегляду коду: “Ця петля отримує доступ до post.author.name для кожного посту, що викликає окремий запит на пост через ліниве завантаження — це проблема N+1, яка погіршиться, коли кількість постів зростатиме.”

Пояснення виправлення:

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

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

Пояснення впливу для менш технічно освічених учасників: “Замість того, щоб задати базі даних одне запитання і отримати все, що нам потрібно, ця сторінка задала одне запитання, а потім п’ятдесят подальших запитань — по одному за кожним елементом на сторінці. Ми змінили його, щоб запитати все в одному або двох питаннях, тому сторінка завантажується набагато швидше тепер.”

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

• Назвіть шаблон явно як “N+1”, а не описуючи його тільки як “повільний” - це широко визнаний термін, який негайно говорить іншим інженерам, який клас проблеми ви маєте на увазі.
• Зазначте ** кількість запитів ** конкретно, коли це можливо (“103 запити замість 3”) - конкретна кількість набагато переконливіша, ніж “багато запитів”
• Розрізняйте ** ліньове завантаження ** від ** охочого завантаження **, коли обговорюватиметься виправлення, оскільки виправлення зазвичай є зміною стратегії отримання даних, а не зміною налаштування бази даних.
• Вказуйте, що N+1 проблеми часто невидимі в малому масштабі, що пояснює, чому вони прослизають через перегляд коду і тільки виходять на поверхню під виробничим навантаженням або більшими наборами даних.
• Коли пропонуєте виправлення, назвіть конкретний механізм — «охоче завантаження» або «пакування з IN-клаузулою» — замість нечіткого «давайте оптимізуємо запити»

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

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

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

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

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

Нарешті, пам’ятайте, що ефективне спілкування не просто про заяву про проблему; це про запропонування рішення - навіть якщо це просто запит на подальше дослідження. Фрази на кшталт «Дослідимо альтернативні методи отримання даних» або «Чи можемо ми дослідити використання JOIN тут?» демонструють активне залучення і допомагають направляти розмову до рішення. Це про те, щоб позиціонувати себе як того, хто розуміє не тільки * що * не так, але * чому * це має значення для більшої системи і її користувачів.