Приведи пример когда без NoSQL не обойтись

Когда без NoSQL не обойтись

NoSQL базы данных критичны для определённых сценариев, где реляционные БД показывают слабые стороны. Вот реальные примеры.

Пример 1: Высоконагруженная система с непредсказуемой схемой данных (Instagram/Twitter)

Социальная сеть должна быстро масштабироваться и хранить разнородные данные:

Проблема с SQL:

• У поста могут быть метаданные, теги, геолокация, хештеги
• У видео дополнительные поля (длительность, разрешение)
• У комментария могут быть @mention и media attachments
• Постоянные ALTER TABLE миграции
• Сложные JOIN запросы

Решение с MongoDB/Firestore:

# MongoDB - документ может иметь произвольную структуру
post1 = {
    "_id": ObjectId(),
    "author_id": "user123",
    "content": "Hello world",
    "created_at": datetime.now(UTC),
    "likes": 1500,
    "tags": ["#python", "#coding"]
}

post2 = {
    "_id": ObjectId(),
    "author_id": "user456",
    "content": "Video tutorial",
    "created_at": datetime.now(UTC),
    "video_url": "https://...",
    "duration_seconds": 3600,
    "resolution": "4K",
    "views": 50000,
    "subtitles": {"en": "...", "ru": "..."}
}

# Одна коллекция, разные структуры - OK!
db.posts.insert_many([post1, post2])

# Запрос работает для обоих
recent_posts = db.posts.find({
    "created_at": {"$gt": one_week_ago}
}).sort("created_at", -1).limit(10)

Почему NoSQL здесь необходима:

• Масштабирование горизонтальное (shard by user_id)
• Отсутствие сложных JOIN на миллиарды записей
• Гибкость схемы — новые поля без миграций
• Высокая скорость записи (write-optimized)

Пример 2: Real-time аналитика и временные ряды (Prometheus/InfluxDB)

Приложение собирает метрики каждую секунду от миллионов устройств:

Проблема с SQL:

• PostgreSQL не может хранить миллиарды записей метрик
• Индексирование по timestamp неэффективно
• JOIN для сложных агрегаций невозможен

Решение с InfluxDB (Time-Series NoSQL):

from influxdb_client import InfluxDBClient
from influxdb_client.client.write_api import SYNCHRONOUS

client = InfluxDBClient(url="http://localhost:8086", token="token")
write_api = client.write_api(write_protocol=SYNCHRONOUS)

# Пишем метрики миллионами
for device_id in range(1, 1000000):
    for i in range(60):  # 60 измерений в минуту
        point = {
            "measurement": "cpu_usage",
            "tags": {
                "device_id": str(device_id),
                "region": "us-east-1"
            },
            "fields": {
                "value": random.uniform(10, 90),
                "temp": random.uniform(40, 80)
            },
            "time": int(time.time() * 1e9)
        }
        write_api.write(bucket="metrics", record=point)

# Запрашиваем агрегаты (очень быстро благодаря индексам)
query = '''
    from(bucket:"metrics")
    |> range(start: -24h)
    |> filter(fn: (r) => r._measurement == "cpu_usage" and r.region == "us-east-1")
    |> aggregateWindow(every: 5m, fn: mean)
    |> mean()
'''

result = client.query_api().query(org="my-org", query=query)

Почему NoSQL критична:

• Оптимизирована для записи временных рядов
• Автоматическое удаление старых данных (TTL)
• Быстрая агрегация (min, max, mean по диапазонам)
• Горизонтальная масштабируемость

Пример 3: Кэширование сессий и быстрый доступ (Redis)

Приложение должно обслуживать 100k одновременных пользователей:

Проблема с SQL:

• Каждый запрос требует двух запросов в БД (verify token + get session)
• Timeout: SELECT с индексом идёт 5-10ms
• При 100k пользователей это 500MB-1GB в памяти на одно поле

Решение с Redis:

import redis
import json
from datetime import datetime, timedelta, UTC

redis_client = redis.Redis(host="localhost", port=6379, db=0)

class SessionManager:
    def create_session(self, user_id: str, data: dict) -> str:
        """Создаём сессию - O(1) операция"""
        session_id = str(uuid4())
        
        # Сохраняем с TTL (автоматически удалится через 24 часа)
        session_data = {
            "user_id": user_id,
            "created_at": datetime.now(UTC).isoformat(),
            "data": data
        }
        
        redis_client.setex(
            f"session:{session_id}",
            86400,  # 24 часа TTL
            json.dumps(session_data)
        )
        
        return session_id
    
    def get_session(self, session_id: str) -> dict:
        """Получаем сессию - O(1), <1ms"""
        data = redis_client.get(f"session:{session_id}")
        if not data:
            return None
        return json.loads(data)
    
    def delete_session(self, session_id: str) -> None:
        """Удаляем сессию - O(1)"""
        redis_client.delete(f"session:{session_id}")

# Использование в FastAPI
from fastapi import FastAPI, Request
from fastapi.responses import JSONResponse

app = FastAPI()
session_manager = SessionManager()

@app.middleware("http")
async def validate_session(request: Request, call_next):
    token = request.headers.get("Authorization", "").replace("Bearer ", "")
    
    if not token:
        return JSONResponse({"error": "No token"}, status_code=401)
    
    # Очень быстрый Redis lookup (<1ms)
    session = session_manager.get_session(token)
    if not session:
        return JSONResponse({"error": "Invalid token"}, status_code=401)
    
    request.state.user_id = session["user_id"]
    return await call_next(request)

Почему Redis критичен:

• Память вместо диска (тысячи раз быстрее)
• Встроенная TTL для автоочистки
• Атомарные операции (SETEX, GETEX)
• Миллионы операций в секунду на одном узле

Пример 4: Документо-ориентированное хранилище (Elasticsearch)

Приложение должно обеспечить полнотекстовый поиск по миллиардам документов:

Проблема с SQL:

• LIKE '%keyword%' сканирует все строки
• Индексирование по всем словам невозможно
• Морфология и синонимы не работают

Решение с Elasticsearch:

from elasticsearch import Elasticsearch

es = Elasticsearch(["http://localhost:9200"])

# Индексируем документы с анализом текста
for article in articles:
    es.index(index="articles", body={
        "title": article["title"],
        "content": article["content"],
        "author": article["author"],
        "published_at": article["published_at"],
        "tags": article["tags"]
    })

# Быстрый полнотекстовый поиск
result = es.search(index="articles", body={
    "query": {
        "multi_match": {
            "query": "python машинное обучение",
            "fields": ["title^2", "content"],
            "fuzziness": "AUTO"  # Морфология
        }
    },
    "aggs": {
        "tags": {
            "terms": {"field": "tags.keyword", "size": 10}
        }
    },
    "sort": [{"published_at": "desc"}]
})

for hit in result["hits"]["hits"]:
    print(f"{hit['_source']['title']} ({hit['_score']:.2f})")

Почему NoSQL критична:

• Инвертированные индексы для полнотекстового поиска
• Морфологический анализ (лемматизация)
• Синонимы и опечатки (fuzzy search)
• Агрегации по facets

Пример 5: Граф данных (Neo4j)

Приложение должно рекомендовать друзей на основе социальной сети:

Проблема с SQL:

• Запрос "друзья друзей" требует 3 JOIN
• "Друзья друзей друзей" требует 5 JOIN
• При миллионах связей производительность падает

Решение с Neo4j:

from neo4j import GraphDatabase

driver = GraphDatabase.driver("bolt://localhost:7687")

def recommend_friends(user_id: str, depth: int = 2) -> list:
    """Найти рекомендации через социальную сеть"""
    query = f"""
    MATCH (user:User {{id: $user_id}})
          -[:FRIEND*1..{depth}]-(potential_friend:User)
    WHERE potential_friend.id <> $user_id
      AND NOT (user)-[:FRIEND]-(potential_friend)  -- не уже друзья
    RETURN potential_friend, count(*) as mutual_connections
    ORDER BY mutual_connections DESC
    LIMIT 10
    """
    
    with driver.session() as session:
        result = session.run(query, {"user_id": user_id})
        return [{
            "id": record["potential_friend"]["id"],
            "name": record["potential_friend"]["name"],
            "mutual_friends": record["mutual_connections"]
        } for record in result]

# Использование
recommendations = recommend_friends("user123")
for friend in recommendations:
    print(f"{friend['name']} ({friend['mutual_friends']} общих друзей)")

Почему NoSQL критична:

• Графовые запросы O(1) вместо O(n) JOIN
• Встроенные алгоритмы (shortest path, pagerank)
• Эффективнее SQL при глубоких связях

Сравнение: SQL vs NoSQL

Вывод

NoSQL критична когда:

1. Масштабируемость выше согласованности (микросервисы, микроблоги)
2. Динамическая схема (социальные сети, IoT)
3. Скорость записи критична (лог-системы, аналитика)
4. Специальные запросы (поиск, графы, временные ряды)
5. Высокая нагрузка на чтение (кэширование, сессии)

Для большинства приложений — начните с PostgreSQL, а не с NoSQL. Переходите на NoSQL только когда SQL показывает слабые стороны на вашем сценарии.