JavaRush /Курси /Модуль 4: FastAPI /Вступ до NoSQL баз даних: особливості та використання

Вступ до NoSQL баз даних: особливості та використання

Модуль 4: FastAPI
Рівень 8 , Лекція 0
Відкрита

У реальному світі не всі проєкти ідеально вкладаються в рамки реляційних СУБД. Сьогодні ми виходимо за межі звичного SQL-світу і починаємо вивчати NoSQL бази даних.

NoSQL — заперечення SQL? Не поспішайте з висновками. Ця абревіатура розшифровується як Not Only SQL. Це означає, що такі бази даних не обмежуються класичним підходом реляційних систем, де використовуються таблиці, рядки, колонки і сувора схема. Вони призначені для роботи з іншими моделями даних, такими як документи, графи, ключ-значення і інші підходи.

Якщо порівнювати бази даних з коробками для зберігання речей, то реляційні бази — це коробки з чітко розміченими комірками під кожен предмет. А NoSQL бази — це коробки "збери сам", де можна розкидати все як завгодно, головне — знайти потім.

Наприклад, дані можуть зберігатися у вигляді JSON-документів, масивів або навіть зв'язків між об'єктами в деревах.

NoSQL бази даних: типи, плюси і мінуси

  • Документно-орієнтовані — дані зберігаються у вигляді JSON/BSON-документів, зручно для вкладених структур.
    Приклад: MongoDB
  • Ключ-значення — проста пара ключ: значення, відмінно підходить для кешів.
    Приклад: Redis
  • Графові — дані представлені як вузли та зв'язки; ідеальні для соцмереж і рекомендацій.
    Приклад: Neo4j
  • Колонно-орієнтовані — зберігають дані по стовпцях, ефективні в аналітиці.
    Приклад: Cassandra

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

Недоліки: без суворої структури — може виникнути безлад. Із транзакціями часто трапляються проблеми. Немає єдиної мови запитів — у кожної БД свій синтаксис.


Коли використовувати NoSQL бази даних?

Реляційні бази даних зручні, коли потрібна сувора структура — наприклад, банківські додатки або ERP-системи. Однак у реальному житті бувають задачі, де реляційна модель не підходить:

  1. Великі об'єми даних з високою швидкістю запису.
    Наприклад, збір подій у реальному часі, таких як кліки користувачів на сайті. Припустимо, ваш сайт збирає 1 мільйон подій на хвилину — спробуйте встигнути зберегти це в PostgreSQL без втрати даних.
  2. Зберігання незв'язаних даних різної структури.
    Уявіть інтернет-магазин, де є товари з різними характеристиками: телефон з камерами і обсягом пам'яті або книга з кількістю сторінок. Вносити такі дані в одну таблицю складно. У NoSQL можна просто записати це як JSON-документи.
  3. Кешування даних для швидкого доступу.
    Redis — приклад бази ключ-значення, яка ідеально підходить для тимчасового збереження інформації, наприклад даних сесій користувачів.
  4. Соціальні мережі і графові структури.
    У соціальній мережі, де є користувачі та їхні зв'язки, простіше працювати з графами. У цьому випадку кожна взаємозв'язок (наприклад, "користувач A у друзях у користувача B") — це окремий об'єкт.
  5. Гнучкість при зміні структури даних.
    У стартапах або динамічно що розвиваються проєктах структура даних постійно змінюється. Наприклад, додавання нового поля до моделей даних у реляційних базах вимагатиме міграції, тоді як MongoDB дозволить просто додати це поле в новий документ.

Основні концепції NoSQL

Практично кожна NoSQL база даних представляє дані так, щоб вони легко асоціювалися з об'єктами з реального світу.

  • Документ — це автономна одиниця даних. В MongoDB документ зазвичай представлений у форматі JSON або BSON (бінарний JSON).
    Приклад документа:
    {
        "id": 1,
        "name": "Alice",
        "age": 25,
        "interests": ["Python", "FastAPI"]
    }
  • Колекція — це набір документів з подібними даними. Наприклад, колекція users може містити всі документи про користувачів додатку.

Денормалізація даних

Якщо в реляційних базах даних ми «нормалізуємо» дані (розподіляємо їх по різних таблицях з ключами і зв'язками), то в NoSQL часто використовується протилежний підхід — денормалізація. Це означає, що дані в одному документі можуть містити всю необхідну інформацію.

Приклад: замість таблиць користувачів і їхніх замовлень ми можемо зберегти все в одному документі:

{
    "user_id": 123,
    "name": "John Doe",
    "orders": [
        {"order_id": 1, "item": "Book", "price": 10.99},
        {"order_id": 2, "item": "Pen", "price": 1.5}
    ]
}

Це спрощує читання даних, але може збільшити обсяг збереженої інформації.

Горизонтальне масштабування

Одна з причин, чому обирають NoSQL бази даних — це можливість масштабування "вшир". У реляційних базах даних масштабування часто відбувається "вглиб" (додавання ресурсів на одному сервері). На практиці додавати сервери і розподіляти дані між ними простіше, ніж апгрейдити існуючий сервер.


Чому програмісти люблять NoSQL?

Якщо ви коли-небудь ловили себе на думці "Ось би мені JSON запхати в базу і не мучитися!" — вітаю, ви знайшли своє нове щастя. Документно-орієнтовані бази ідеально підходять розробникам, які хочуть мінімізувати перетворення даних між Python-об'єктами і базою. Це пришвидшує розробку і знижує складність багатьох дрібних задач.

Однак, як і будь-яка технологія, NoSQL має свої підводні камені, і вибір між SQL і NoSQL базами завжди залежить від ваших конкретних вимог. У наступних лекціях ми будемо занурюватися глибше, щоб дізнатися, як використовувати MongoDB в реальних проєктах.

Поки що постарайтеся усвідомити одну річ: в світі баз даних немає універсального підходу. NoSQL — це не заміна SQL, а скоріше зручний інструмент для специфічних задач, який варто додати в ваш арсенал.

Коментарі
ЩОБ ПОДИВИТИСЯ ВСІ КОМЕНТАРІ АБО ЗАЛИШИТИ КОМЕНТАР,
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ