Модуль 2

In-memory бази даних та сценарії використання Redis

Ось готовий урок, створений спеціально за твоїм майстер-промптом. Вмикай уяву, ми починаємо!

🚀 In-memory бази даних: Чому Redis — це швидкість світла для твого коду

Привіт, друзі! Радий бачити вас.

Сьогодні ми поговоримо про швидкість. Не просто про "швидко", а про блискавично. Ми заглянемо під капот сучасних веб-додатків і знайдемо там магічний інструмент, який дозволяє Instagram завантажувати стрічку за мілісекунди, а Uber — миттєво знаходити водія поруч.

Ім'я цьому інструменту — Redis. Але перш ніж ми пірнемо в код, давайте зрозуміємо, навіщо він взагалі здався.

1. 🔥 Вступ: проблема та мотивація

Уявіть, що ви працюєте бібліотекарем у величезній стародавній бібліотеці (це наша класична база даних, наприклад, PostgreSQL або MySQL).

До вас підходить читач і просить книгу "Гаррі Поттер". Ви йдете в сховище, спускаєтесь у підвал, шукаєте полицю, здуваєте пил, берете книгу, піднімаєтесь і віддаєте її. Це займає 2 хвилини. Читач повертає книгу, а через хвилину підходить інший і просить ту саму книгу.

Питання до вас: Ви знову підете в підвал? Знову будете шукати ту саму полицю?

Звісно, ні! Це було б божевіллям. Ви, як розумний бібліотекар, залишите цю популярну книгу прямо у себе на столі. І коли третій читач запитає її, ви просто простягнете руку і віддасте її за 1 секунду.

Ось у чому різниця: * Підвал — це ваш жорсткий диск (SSD/HDD). Там багато місця, дані зберігаються надійно, але доступ до них повільний. * Стіл бібліотекаря — це Оперативна пам'ять (RAM). Доступ миттєвий, але місця мало.

Проблема: Класичні бази даних (SQL) працюють з диском. Кожен запит — це похід у підвал. Коли у вас 100 користувачів — це ок. Коли їх 100 000 — ваш "бібліотекар" помре від біганини по сходах, а сайт "ляже".

Рішення: Нам потрібна база даних, яка живе виключно на "столі" (в оперативній пам'яті). Це і є In-memory Database, найпопулярнішою з яких є Redis. Без неї сучасний Twitter просто не завантажився б.

2. 🧠 Теоретична база (без нудних лекцій)

Що ж таке Redis? Розшифровується як Remote Dictionary Server.

Як це працює "під капотом"?

Уявіть велетенський Python-словник (dict) або JSON-об'єкт, який висить у оперативній пам'яті сервера. Це Key-Value сховище.

  • Key (Ключ): Унікальна назва (як номерок у гардеробі).
  • Value (Значення): Те, що ми зберігаємо (рядок, число, список).

🔑 Що треба запам’ятати залізно:

  1. Швидкість: Redis шалено швидкий. Він обробляє сотні тисяч запитів за секунду, тому що не витрачає час на обертання дисків.
  2. Тимчасовість (Volatile): Оскільки дані в RAM, якщо вимкнути сервер з розетки — пуф! — дані зникнуть (якщо не налаштувати спеціальне збереження, але про це пізніше).
  3. Структури даних: Redis розумний. Він вміє зберігати не просто текст, а й списки, множини та хеш-таблиці.

💡 Інтуїтивне розуміння:

Не намагайтеся будувати в Redis складні зв'язки, як у SQL (ніяких JOIN). Думайте про Redis як про надшвидкий записник-стікер. Ви пишете на ньому коротку інформацію, щоб не забути, і клеїте на монітор.

3. 🧪 Приклади (від простого до реального)

Приклад 1: Hello World

Найпростіша операція — зберегти і дістати.

# Команда Redis
SET user:name "David"
GET user:name

Що ви очікуєте побачити? Правильно, система поверне "David". Це база.

Приклад 2: Кешування (Реальний кейс)

Уявіть, що у вас є сторінка "Топ-10 товарів тижня". Щоб її зібрати, SQL-база має перелопатити мільйон замовлень. Це займає 3 секунди.

Як роблять профі:

Псевдокод:

def get_top_products():
    # 1. Питаємо у Redis: "У тебе вже є готовий список?"
    cached_data = redis.get("top_10_products")

    if cached_data:
        # Якщо є — супер! Повертаємо миттєво.
        print("Взяли з кешу (швидко!)")
        return cached_data

    # 2. Якщо немає — йдемо в повільну SQL базу (у підвал)
    print("Рахуємо з нуля (довго...)")
    data = heavy_sql_query_calculation()

    # 3. ЗАПИСУЄМО результат у Redis, щоб наступного разу не рахувати
    # І ставимо таймер життя (TTL) на 1 годину (3600 сек)
    redis.set("top_10_products", data, ex=3600)

    return data

Чому це круто? Перший користувач почекає 3 секунди. Наступні 10 000 користувачів отримають відповідь за 0.001 секунди. Ви розвантажили основну базу на 99%!

Приклад 3: Тимчасові дані (SMS-коди)

Вам приходить SMS: "Ваш код 1234, дійсний 5 хвилин".

Зберігати такий код у вічній базі даних (MySQL) — це сміття. Він потрібен лише на 5 хвилин.

# Зберегти код 1234 для користувача user_99, який знищиться через 300 сек
SETEX sms:code:user_99 300 "1234"

Питання до студента: Що станеться, якщо ми зробимо GET sms:code:user_99 через 301 секунду? Відповідь: Redis поверне nil (пустоту). Дані самознищилися. Жодного сміття в пам'яті. Геніально, правда?

4. 🛠 Практична частина

Час забруднити руки кодом! (Можна використовувати консоль redis-cli або онлайн-емулятори).

Завдання 1: Розігрів Запиши своє ім'я під ключем myname, а потім дістань його.

Завдання 2: Місія нездійсненна Створи ключ secret_msg зі значенням "Цей текст зникне", який автоматично видалиться через 10 секунд. Перевір його наявність одразу, а потім — через 11 секунд.

Завдання 3: Лічильник лайків Уяви, що ти робиш YouTube. Тобі треба дуже швидко рахувати перегляди. Використай команду INCR video:123:views. Виконай її 3 рази. Яке значення отримаєш? (Підказка: Redis атомарний, він не збивається при одночасному натисканні).

Завдання 4: Черга задач Ти — бариста. Замовлення надходять у список. Використай LPUSH orders "Latte" і LPUSH orders "Espresso". А тепер забери замовлення "в роботу" командою RPOP orders. Яке замовлення вийде першим? (Принцип FIFO — First In, First Out).

Завдання 5: Міні-кейс У тебе є інтернет-магазин. Користувач додає товари в кошик, але ще не зареєструвався. Де краще зберігати вміст цього тимчасового кошика: у PostgreSQL чи в Redis? Чому?

Завдання 6: "А що, якщо..." Ти використовуєш Redis для зберігання сесій користувачів (щоб їм не треба було логінитися щоразу). Раптом у дата-центрі зникає світло, і сервер перезавантажується. Redis був налаштований без збереження на диск. Що станеться з усіма користувачами на сайті? Як цього уникнути?

5. 💡 Мислення як у розробника

Як відрізнити новачка від профі, коли мова йде про Redis?

❌ Типова помилка новачка: Намагатися запхати в Redis усі дані. "О, він швидкий, буду тримати там всю базу користувачів!". Результат: Оперативна пам'ять (RAM) дуже дорога і обмежена. У вас закінчиться пам'ять, і сервер впаде. Redis — для гарячих даних, а не для архіву.

❌ Ще одна помилка: Забувати про ключі. Називати ключі просто users або count. Як думає профі: Використовує простори імен (namespaces). Наприклад: app:users:id:10:profile або stats:visits:2023-10-27. Це дозволяє тримати структуру в порядку.

🧠 Порада від Девіда: Завжди пам'ятайте про інвалідaцію кешу. Це найскладніша проблема в CS. Якщо ви змінили ціну товару в основній базі, а в Redis залишилася стара ціна — ви втратите гроші. Завжди думайте: "Коли ці дані стануть неактуальними?".

6. 🧩 Підсумок

Отже, що ми маємо в сухому залишку?

  1. Disk is slow, RAM is fast. Ми використовуємо Redis, щоб компенсувати повільність дисків.
  2. Redis — це кеш. Він ідеальний для даних, до яких часто звертаються (профілі, топи, сесії).
  3. Тимчасовість. Механізм TTL (Time To Live) дозволяє даним самоочищатися (коди, тимчасові токени).

Тепер ви вмієте: Прискорювати свої додатки, працювати з тимчасовими даними та розуміти, як великі системи витримують навантаження.

🔜 У наступній серії: Ми навчилися зберігати дані швидко. Але як змусити різні сервіси спілкуватися між собою миттєво? Готуйтеся, наступна тема — Message Brokers (RabbitMQ та Kafka). Це буде гучно!

А поки що — щасти тобі з кодом!

← До списку уроків Наступний урок →