🚀 Більше оптимізації SQL-запитів. В 10 разів швидше, і чому не варто сліпо довіряти ШІ 😅

💡 Історія почалася з того, що я вирішив оптимізувати деякі SQL-запити в боті @gram_piarbot, приблизно 2 місяці тому, і звернувся за порадою до GPT-4o. Модель впевнено порекомендувала використовувати CTE (Common Table Expressions) замість звичайних підзапитів.

⚡️ Спочатку все здавалося нормальним - запити працювали, швидкість начебто та сама, майже не було різниці, може навтіь трохи швидше. Але коли наша база підросла і навантаження збільшилося... От тоді почалося найцікавіше!

🤖 Ось дуже приблизно, як виглядав запит з CTE:

WITH completed_tasks_cte AS (
    SELECT UserTask.task_id, COUNT(*) AS total_completions_count
    FROM UserTask
    WHERE UserTask.completed_at IS NOT NULL
    GROUP BY UserTask.task_id
)
SELECT Task.task_id, Task.price
FROM Task
LEFT JOIN completed_tasks_cte...

📉 Коли RPS (кількість запитів в секунду) збільшилось, продуктивність почала падати. І тут мені на допомогу прийшла нова модель OpenAI O1 Preview, яка пояснила дещо важливе: CTE дійсно може бути корисним, але тільки в специфічних випадках!

💎 Виявляється, CTE працює як "матеріалізований в'ю" і найкраще підходить, коли:
• Ви використовуєте один і той самий CTE багато разів в запиті
• Вам потрібно робити рекурсивні запити
• Ви працюєте з великим набором даних, який використовується повторно

🔧 В моєму випадку нічого з цього не було потрібно! Тому я переписав запит на корельований підзапит (correlated subquery):

SELECT Task.task_id, Task.price
FROM Task
WHERE Task.status = 'CREATED'
  AND Task.limit > (
      SELECT COUNT(*)
      FROM UserTask
      WHERE UserTask.task_id = Task.task_id
        AND UserTask.completed_at IS NOT NULL
  )
ORDER BY Task.price DESC

🚀 Результат? Швидкість виконання зросла в 10 разів! А все тому, що:
• База даних тепер обробляє тільки потрібні рядки
• Не створюється зайва проміжна таблиця
• Використовується менше пам'яті
• Оптимізатор постгресу може краще планувати виконання запиту (з СТЕ він йому набагато важче)

📚 Головний урок, який я виніс:
1. Розбирайтеся, ЧОМУ щось працює краще або гірше
2. Не бійтеся експериментувати і міряти продуктивність, використовуючи EXPLAIN ANALYZE на продакшн базі.

🤔 А у вас були випадки, коли поради ШІ виявлялися не найкращими? Як ви перевіряєте такі рекомендації? Діліться досвідом в коментарях!

Ставте 👍 якщо хочете більше постів про оптимізацію SQL та роботу з ШІ!

🔍 Redis оптимізація: Прихована проблема команди KEYS

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

🎯 Передісторія проблеми
У нас є робочий бот з досить високим навантаженням, про який я розповідав вище - RPS досягав від 150 до 200, а іноді й вище. Все працювало начебто нормально, але періодично виникала дивна поведінка: в абсолютно випадкові моменти бот просто "завмирав".

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

🔬 Процес розслідування
- Спершу перевірив усі повільні запити (про які я розповідав у попередніх постах)
- Проаналізував навантаження на сервер
- Почав відстежувати конкретні моменти, коли відбуваються зупинки

Випадково ми помітили закономірність: проблема виникала при специфічному сценарії з двома ботами (в нас тут система мультиботів). У нас була логіка, де при додаванні нового бота в групу, старий мав автоматично видалятися. Для цього використовувався Redis для зберігання ID активного бота.

🎈 Момент відкриття
Саме в процесі очищення кешу (інформації про користувачів групи) після виходу бота з групи і крилася проблема. Я використовував команду KEYS для отримання всіх ключів, які потрібно було очистити.

Коли я спробував виконати команду KEYS в Redis CLI під час активної роботи бота, побачив точно таку ж картину: всі логи миттєво зупинялися!

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

⚡️ Технічні деталі проблеми:
- Команда KEYS сканує весь простір ключів Redis
- При великих базах даних це може зайняти багато часу
- Це суттєво впливає на продуктивність сервера
- Redis документація прямо не рекомендує використовувати KEYS в production

✅ Як ми це виправили:
1. Повністю прибрали використання команди KEYS
2. Замінили її на команду SCAN, яка:
- Працює інкрементально через курсор
- Сканує базу частинами, а не повністю за раз
- Рекомендована для production-середовища
3. Провели додаткове тестування під навантаженням

📊 Результати оптимізації:
- Зникли випадкові зупинки в роботі бота
- Стабільна робота навіть при пікових навантаженнях
- Покращилась загальна відгучність системи

⚠️ Важливі висновки:
- Уникайте команд, що скануют весь простір ключів Redis
- Використовуйте SCAN замість KEYS в production
- Моніторте час виконання Redis-операцій
- Перевіряйте рекомендації Redis щодо production-використання

💡 Рекомендації:
1. Проведіть аудит свого коду на наявність команди KEYS
2. Замініть її на SCAN, якщо знайдете

🤝 Поділіться в коментарях:
- Чи стикалися ви з подібними проблемами?
- Які інші "підводні камені" Redis ви знайшли?

🚀 P.S. Оптимізація - це нескінченний процес вдосконалення. Слідкуйте за каналом, попереду ще багато цікавих кейсів та порад з оптимізації!