JavaRush /Курси /Модуль 4: FastAPI /Управління даними в реляційних та нереляційних базах

Управління даними в реляційних та нереляційних базах

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

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

Коли ми говоримо про реляційні бази даних, такі як PostgreSQL, основа-основ — це таблиці та їхня структура. У цьому розділі зрозуміємо, як ефективно керувати таблицями, створювати індекси для пришвидшення запитів, забезпечувати безпеку і перевіряти продуктивність.

Найпростіший спосіб описати структуру даних в SQL — це створити таблицю. Наприклад, ось як створити таблицю users для нашого додатку:


CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    username VARCHAR(50) NOT NULL,
    email VARCHAR(100) UNIQUE NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
  • SERIAL автоматично збільшує ідентифікатор для кожного нового запису.
  • VARCHAR дозволяє задати строковий тип з обмеженням довжини.
  • UNIQUE забороняє дублювання значень у вказаному полі.
  • DEFAULT CURRENT_TIMESTAMP автоматично проставляє поточну дату і час.

Ми пропустили важливе поле — дату останнього оновлення. Що робити? Звісно, додати його за допомогою команди ALTER TABLE:


ALTER TABLE users ADD COLUMN updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP;

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

Індексація для пришвидшення запитів

Уявіть, що ви шукаєте книгу в бібліотеці з мільйоном томів, але у вас немає каталогу. Пошук займе вічність! Індекси — це каталоги для нашої бази даних. Створимо індекс для поля email в таблиці users:


CREATE INDEX idx_users_email ON users(email);

Тепер запити на пошук користувача за email виконуються значно швидше.

💡 Порада:

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

Контроль доступу та безпека

Безпека особливо важлива для SQL-баз, бо вони часто містять чутливі дані. Наприклад, ми можемо обмежити доступ до таблиці на рівні ролі:


GRANT SELECT, INSERT ON users TO read_only_user;
REVOKE UPDATE, DELETE ON users FROM read_only_user;

Так ми даємо користувачу read_only_user право тільки на читання і додавання записів, забороняючи зміну та видалення.


Основи управління даними в NoSQL

У світі NoSQL все влаштовано не так, як в SQL. Тут немає таблиць з фіксованими полями, зате є гнучкість: колекції і документи. Розглянемо MongoDB як приклад.

Колекції — це щось на кшталт таблиць, тільки без заздалегідь визначеної схеми. А документи всередині колекцій — це записи в форматі JSON. Ось приклад додавання документа в колекцію products через MongoDB:


product = {
    "name": "Super Widget",
    "price": 49.99,
    "stock": 120,
    "tags": ["gadget", "widget", "electronics"],
    "created_at": datetime.now()
}
db.products.insert_one(product)

Тепер у нас є запис, і все це без попереднього визначення структури.

Припустимо, наш товар подорожчав, і ми хочемо оновити його ціну:


db.products.update_one(
    {"name": "Super Widget"},  # Умова пошуку
    {"$set": {"price": 59.99}} # Нове значення
)

Гнучкість JSON дозволяє додавати нові поля на льоту. Наприклад, можна додати поле category, якщо його раніше не було:


db.products.update_one(
    {"name": "Super Widget"},
    {"$set": {"category": "tools"}}
)

Індексація і продуктивність

Як і в SQL-базах, індекси в MongoDB підвищують швидкість пошуку. Створимо індекс для поля price:


db.products.create_index("price")

Тепер запити, які шукають товари в певному ціновому діапазоні, виконуються швидше.

⚠️ Зверніть увагу:

що індекси займають пам'ять. Чим більше індексів, тим вище споживання ресурсів.


Приклади успішного управління даними в гібридних архітектурах

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

Наприклад, уявіть інтернет-магазин, де SQL використовується для транзакцій, а NoSQL — для аналітики. У SQL-базі ми зберігаємо дані про замовлення:


CREATE TABLE orders (
    id SERIAL PRIMARY KEY,
    user_id INT NOT NULL,
    total_amount NUMERIC(10, 2) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

В NoSQL (MongoDB) ми записуємо аналітику поведінки користувача:


analytics_doc = {
    "user_id": 42,
    "page_views": [
        {"page": "/home", "timestamp": datetime(2023, 11, 1, 10, 15)},
        {"page": "/product/12", "timestamp": datetime(2023, 11, 1, 10, 18)}
    ],
    "session_id": "abc123"
}
db.analytics.insert_one(analytics_doc)

Потік даних між двома системами

Іноді дані з NoSQL бази потрібно аналізувати в SQL. Наприклад, можемо витягнути найвідвідуваніші сторінки з MongoDB і перенести ці дані в PostgreSQL для побудови звітів.

Python-код для синхронізації:


# Витягуємо з MongoDB
top_pages = db.analytics.aggregate([
    {"$unwind": "$page_views"},
    {"$group": {"_id": "$page_views.page", "views": {"$sum": 1}}},
    {"$sort": {"views": -1}}
])

# Зберігаємо в PostgreSQL
for page in top_pages:
    cursor.execute("""
        INSERT INTO page_views (page, views)
        VALUES (%s, %s)
        ON CONFLICT (page) DO UPDATE SET views = excluded.views;
    """, (page["_id"], page["views"]))
    conn.commit()

Це дає змогу реалізувати потужну аналітику.


Підсумкові поради та кращі практики

Робота з SQL і NoSQL вимагає знання їхніх сильних сторін і вміння використовувати їх одночасно. Ось кілька порад:

  • Оптимізуй запити: використовуй індекси і профілювання запитів.
  • Захисти дані: в SQL — контроль доступу, в NoSQL — управління кластером.
  • Автоматизуй синхронізацію даних: використовуй інструменти ETL (Extract, Transform, Load) для переміщення даних між базами.

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

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