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

База даних, яка періодично падає під навантаженням, — це кошмар будь-якого розробника. Це призводить до простою сервісів, втрати даних і головного болю для DevOps. Особливо боляче, коли причина криється не в поганій оптимізації SQL-запитів чи відсутності індексів, а в фундаментальній архітектурній помилці.

Контекст і чому це важливо

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

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

Практична реалізація

Один з найпоширеніших сценаріїв – це “граф транзакцій”, коли обробка одного запиту вимагає отримання даних з багатьох пов’язаних таблиць, створюючи ланцюг операцій. Щоб вирішити цю проблему, потрібно розбити великі транзакції на менші, а також використовувати стратегію “lazy loading” для даних, які не потрібні одразу.

<?php

// Початковий код - поганий приклад
function getOrderDetails($orderId) {
    $order = $db->query("SELECT * FROM orders WHERE id = $orderId");
    $user = $db->query("SELECT * FROM users WHERE id = {$order['user_id']}");
    $address = $db->query("SELECT * FROM addresses WHERE id = {$order['address_id']}");
    $items = $db->query("SELECT * FROM order_items WHERE order_id = $orderId");

    foreach ($items as $item) {
        $product = $db->query("SELECT * FROM products WHERE id = {$item['product_id']}");
    }

    return [
        'order' => $order,
        'user' => $user,
        'address' => $address,
        'items' => $items,
    ];
}

// Оптимізований код - використання lazy loading
function getOrderDetailsLazy($orderId) {
    $order = $db->query("SELECT id, user_id, address_id FROM orders WHERE id = $orderId");
    $user = $db->query("SELECT id, name FROM users WHERE id = {$order['user_id']}");
    $address = $db->query("SELECT id, city FROM addresses WHERE id = {$order['address_id']}");
    $items = $db->query("SELECT product_id FROM order_items WHERE order_id = $orderId");

    $products = [];
    foreach ($items as $item) {
        if (!isset($products[$item['product_id']])) {
            $products[$item['product_id']] = $db->query("SELECT name FROM products WHERE id = {$item['product_id']}");
        }
    }

    return [
        'order' => $order,
        'user' => $user,
        'address' => $address,
        'items' => $items,
        'products' => $products,
    ];
}
?>

Цей код демонструє перехід від завантаження всіх даних відразу до стратегії “lazy loading”, коли дані про товари завантажуються лише за потреби. Це дозволяє зменшити початкове навантаження на базу даних і підвищити швидкість відповіді. У початковому коді, для кожного замовлення виконується велика кількість запитів. Оптимізований код мінімізує кількість запитів, завантажуючи дані лише тоді, коли вони необхідні.

Поширені помилки та підводні камені

• Занадто агресивне кешування: Кешування важливе, але надмірне кешування може призвести до застарілих даних і непередбачуваної поведінки системи. Наприклад, кешування інформації про наявність товару без оновлення при зміні кількості на складі може призвести до продажу товару, якого немає в наявності.
• Неправильний вибір стратегії lazy loading: Неправильне впровадження lazy loading може призвести до збільшення затримки при першому доступі до даних. Важливо правильно оцінити, які дані можна завантажувати пізніше, і оптимізувати порядок завантаження.
• Відсутність моніторингу: Недостатній моніторинг продуктивності бази даних ускладнює виявлення проблем та оцінку ефективності оптимізації. Встановіть моніторинг ключових метрик, таких як час відповіді на запити, кількість з’єднань та використання ресурсів.

Порівняння підходів

Старий підхід – завантаження всіх даних одразу – призводить до великого навантаження на базу даних і збільшення часу відповіді. При великій кількості запитів це може призвести до значного уповільнення роботи системи, в гіршому випадку, до її простою.

Новий підхід – lazy loading – дозволяє завантажувати дані лише за потреби, значно зменшуючи початкове навантаження на базу даних та покращуючи час відповіді на запити. Наприклад, час завантаження сторінки замовлення може скоротитися з 500ms до 200ms.

Висновки

Цей підхід найкраще використовувати в системах з великою кількістю транзакцій та складними зв’язками між сутностями. Почніть з профілювання найповільніших запитів та ідентифікації можливостей для застосування lazy loading. Не забувайте про моніторинг, щоб переконатися, що ваші зміни дійсно покращують продуктивність системи.