key-value       → ключ-значение
document        → документы JSON/BSON
wide-column     → широкие колонки / column families
graph           → графы: вершины и связи
time-series     → временные ряды
search/vector   → поиск, векторные данные

users
-----
id | username | email

orders
------
id | user_id | total_price

order_items
-----------
id | order_id | product_id | count

primary key
foreign key
JOIN
constraints
transactions

SELECT users.username, orders.total_price
FROM users
JOIN orders ON orders.user_id = users.id;

{
  "id": 1,
  "username": "alex",
  "email": "alex@example.com",
  "orders": [
    {
      "id": 100,
      "total_price": 2500,
      "items": [
        {"product_id": 10, "count": 2},
        {"product_id": 15, "count": 1}
      ]
    }
  ]
}

таблица users
колонка username VARCHAR
колонка email VARCHAR
колонка created_at TIMESTAMP

{
  "username": "alex",
  "email": "alex@example.com"
}

{
  "username": "john",
  "email": "john@example.com",
  "avatar_url": "https://example.com/avatar.png",
  "settings": {
    "theme": "dark"
  }
}

node 1 → часть данных
node 2 → часть данных
node 3 → часть данных
node 4 → часть данных

логи
события
метрики
социальные сети
чат-системы
IoT
аналитика
high-load backend

ключ → значение

"user:100:session" → "{token: ..., expires_at: ...}"
"product:50:stock" → "142"

кэша
сессий
rate limiting
очередей
временных токенов
быстрых счётчиков
real-time данных

JSON-документы
логи
события
пользовательские настройки
каталоги товаров с разными характеристиками
контентные страницы
анкеты с динамическими полями

product_id | property_name | property_value

Пользователь → подписан на → Пользователь
Пользователь → лайкнул → Пост
Пользователь → купил → Товар
Товар → похож на → Товар

социальных графов
рекомендательных систем
антифрод-систем
графов зависимостей
маршрутов
сетевых связей

session:abc123 → user_id=10

кэш
сессии
токены
rate limiting
быстрые настройки

Redis
DynamoDB в key-value сценариях

{
  "id": 1,
  "title": "Phone",
  "price": 900,
  "attributes": {
    "color": "black",
    "memory": "256GB"
  }
}

каталоги товаров
профили пользователей
CMS
настройки
анкеты
контент

MongoDB
CouchDB
Amazon DocumentDB

большие логи
события
метрики
аналитика
данные с высокой записью

Apache Cassandra
ScyllaDB
HBase

вершины → объекты
рёбра   → связи между объектами

социальные сети
рекомендации
антифрод
поиск связей
графы зависимостей

Neo4j
Amazon Neptune
ArangoDB

таблицы
строки
колонки
связи
JOIN
строгая схема

документы
ключ-значение
графы
wide-column
гибкая схема
часто денормализация

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email VARCHAR(255) NOT NULL UNIQUE
);

{
  "email": "test@example.com"
}

{
  "email": "test@example.com",
  "phone": "+994...",
  "settings": {
    "theme": "dark"
  }
}

users отдельно
orders отдельно
products отдельно
order_items отдельно

меньше дублирования
строгие связи
удобные JOIN

{
  "user_id": 1,
  "username": "alex",
  "orders": [
    {
      "id": 100,
      "items": [
        {"name": "Keyboard", "price": 100}
      ]
    }
  ]
}

быстро читать объект целиком
меньше JOIN
удобно масштабировать чтение

дублирование данных
сложнее обновлять связанные данные
больше ответственности на уровне приложения

SELECT *
FROM users
JOIN orders ON users.id = orders.user_id
JOIN order_items ON orders.id = order_items.order_id;

как приложение будет читать данные?
какие запросы самые частые?
какие данные выгоднее хранить вместе?

Atomicity    → всё или ничего
Consistency → данные остаются валидными
Isolation   → параллельные транзакции не ломают друг друга
Durability  → данные сохраняются после commit

больше масштабируемость
больше доступность
выше скорость записи
но иногда слабее строгая консистентность

данные на разных узлах могут стать одинаковыми не мгновенно,
а через некоторое время

больше CPU
больше RAM
быстрее диск
сильнее сервер

добавили node 4
добавили node 5
данные распределились по кластеру

Критерий              SQL / RDBMS                 NoSQL
---------------------------------------------------------------------
Модель данных          таблицы                     документы, ключи, графы, колонки
Схема                  строгая                     часто гибкая
Связи                  JOIN, FK                    часто денормализация
Транзакции             сильная сторона             зависит от конкретной БД
Масштабирование        чаще вертикальное           часто горизонтальное
Подходит для           строгих структур            гибких/больших/распределённых данных
Запросы                SQL                         API/язык конкретной БД
Консистентность        обычно строгая              может быть eventual consistency

данные хорошо структурированы
важны транзакции
важны связи между сущностями
нужны JOIN
нужна строгая целостность данных
есть финансовые операции
есть сложная отчётность

банковские операции
заказы и платежи
складской учёт
CRM
ERP
админ-панели
типичный backend с users/orders/payments

данные плохо укладываются в таблицы
схема часто меняется
нужно хранить большие объёмы событий
нужно быстро читать/писать по ключу
нужно горизонтальное масштабирование
нужно хранить JSON-подобные документы
нужно работать с графовыми связями

кэш и сессии → Redis
каталог товаров → MongoDB / DocumentDB
логи и события → Cassandra / ClickHouse-like подходы
социальные связи → Graph DB
метрики и временные ряды → Time-series DB

SQL    → когда важны структура, связи, транзакции, целостность
NoSQL  → когда важны гибкость, масштабирование, быстрый доступ под конкретный сценарий

PostgreSQL → основные бизнес-данные
Redis      → кэш, сессии, rate limiting
MongoDB    → гибкие документы
Elasticsearch/OpenSearch → поиск
Cassandra  → большие потоки событий

гибкой структуры данных
горизонтального масштабирования
быстрого доступа по ключу
хранения больших объёмов событий
работы со слабоструктурированными данными
оптимизации под конкретные запросы приложения

реляционная БД проектируется вокруг таблиц, связей и строгой схемы;
NoSQL-БД проектируется вокруг конкретной модели доступа к данным и масштабирования.

строгой схемой
нормализацией
JOIN
foreign key
сильными ACID-транзакциями
строгой консистентностью
универсальностью SQL-запросов

горизонтального масштабирования
высокой доступности
быстрой записи/чтения
гибкой структуры данных
удобной работы с большими объёмами данных
лучшей работы в распределённых системах

меньше строгих гарантий и универсальности
→ больше масштабируемости, гибкости и скорости под конкретный сценарий

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email VARCHAR(255) NOT NULL UNIQUE,
    age INTEGER
);

какие поля есть
какие типы у полей
какие поля обязательны
какие ограничения действуют

{
  "username": "alex",
  "email": "alex@example.com"
}

{
  "username": "john",
  "email": "john@example.com",
  "settings": {
    "theme": "dark",
    "language": "ru"
  }
}

легче менять структуру данных
удобнее хранить JSON-подобные объекты
меньше миграций схемы
удобнее работать с динамическими полями

валидация часто переезжает из БД в приложение
легче получить грязные или несовместимые данные
сложнее поддерживать единый формат данных

users
orders
order_items
products

{
  "user_id": 1,
  "username": "alex",
  "orders": [
    {
      "id": 100,
      "items": [
        {
          "product_id": 10,
          "name": "Keyboard",
          "price": 100
        }
      ]
    }
  ]
}

быстрое чтение без JOIN
меньше запросов к БД
данные сразу лежат в форме, удобной приложению
легче масштабировать чтение

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

SELECT users.email, orders.total_price
FROM users
JOIN orders ON orders.user_id = users.id
JOIN order_items ON order_items.order_id = orders.id;

как будем читать данные?
какой объект нужен приложению целиком?
какие данные выгодно хранить рядом?

быстрее чтение по заранее известному паттерну
проще распределять данные по узлам
меньше дорогих межтабличных операций

сложнее делать ad-hoc аналитику
сложнее менять паттерны запросов
часть логики связывания данных переходит в приложение

user_id INTEGER REFERENCES users(id)

проще распределять данные
быстрее запись
меньше координации между узлами
меньше глобальных блокировок и проверок

можно получить ссылку на несуществующий объект
сложнее гарантировать целостность данных
нужны дополнительные проверки в коде

Atomicity    → всё или ничего
Consistency → данные остаются валидными
Isolation   → транзакции не мешают друг другу
Durability  → commit сохраняется

выше скорость записи
меньше задержки
лучше масштабирование
лучше доступность при распределённой архитектуре

сложнее делать операции "всё или ничего"
сложнее поддерживать строгую бизнес-целостность
часть компенсационной логики приходится писать вручную

запись уже принята одним узлом
но другие реплики могут увидеть её не мгновенно
через некоторое время данные синхронизируются

высокая доступность
работа при сетевых сбоях
низкая задержка
масштабирование на много узлов
геораспределённость

можно временно прочитать устаревшие данные
разные пользователи могут увидеть разные версии
нужно учитывать eventual consistency в бизнес-логике

JOIN
GROUP BY
HAVING
подзапросы
агрегации
оконные функции
сложные фильтры

Redis       → доступ по ключу и структурам данных
MongoDB     → запросы по документам
Cassandra   → запросы вокруг partition key
Neo4j       → графовые запросы

лучше оптимизация под конкретный паттерн доступа
проще горизонтальное масштабирование
быстрее типовые операции

сложнее делать произвольные запросы
нужно заранее проектировать модель под чтение
миграция между NoSQL-БД сложнее

READ COMMITTED
REPEATABLE READ
SERIALIZABLE

меньше блокировок
выше throughput
быстрее параллельные записи
лучше работа в кластере

сложнее рассуждать о гонках данных
нужны idempotency, versioning, compare-and-set, optimistic locking

Consistency  → все узлы видят одинаковые актуальные данные
Availability → система отвечает на запросы
Partition tolerance → система переживает сетевые разделения

Cassandra-like подход:
больше доступность и масштабирование
консистентность может быть eventual/tunable

MongoDB-like подход:
больше документная модель и удобство разработки
часть транзакционных гарантий доступна, но с ценой

Redis-like подход:
очень быстрый доступ по ключу
но это не замена полноценной реляционной модели

Чем жертвуют                 Ради чего
---------------------------------------------------------------------
Строгая схема                Гибкость структуры данных
Нормализация                 Быстрое чтение готовых объектов
JOIN                          Масштабируемость и предсказуемое чтение
Foreign key                  Быстрая запись и слабая связанность данных
Сильные ACID-транзакции      Производительность и распределённость
Строгая консистентность      Доступность и низкая задержка
Универсальный SQL            Оптимизация под конкретный тип нагрузки
Глобальная целостность       Горизонтальное масштабирование

списать деньги со счёта A
зачислить деньги на счёт B
записать транзакцию
всё должно быть атомарно

ACID
строгая консистентность
изоляция транзакций
целостность данных

миллионы событий
быстрая запись
горизонтальное масштабирование
допустима небольшая задержка синхронизации

throughput
availability
scalability
низкая задержка записи

строгой схемой
нормализацией
JOIN
ссылочной целостностью
сильными транзакциями
строгой консистентностью
универсальностью SQL-запросов

гибкая модель данных
высокая скорость
горизонтальное масштабирование
работа на большом объёме данных
высокая доступность
удобство хранения документов, событий, кэша, графов

SQL-БД чаще выбирают, когда важны связи, транзакции и строгая целостность.

NoSQL чаще выбирают, когда важны масштабирование, гибкость модели данных и скорость под конкретный сценарий доступа.

request → приложение → проверка Redis → разрешить/запретить запрос к БД

rate limit
temporary block
distributed lock
circuit breaker
cache

права пользователя БД
сетевые ACL/firewall
закрытый порт БД
минимальные privileges
connection pool limit

db:block:user:123 → 1
TTL: 300 секунд

import redis

redis_client = redis.Redis(
    host="localhost",
    port=6379,
    decode_responses=True,
)


def block_user_db_access(user_id: int, ttl_seconds: int = 300) -> None:
    redis_client.set(
        name=f"db:block:user:{user_id}",
        value="1",
        ex=ttl_seconds,
    )


def is_user_blocked(user_id: int) -> bool:
    return redis_client.exists(f"db:block:user:{user_id}") == 1


def get_user_data(user_id: int):
    if is_user_blocked(user_id):
        raise PermissionError("DB access temporarily blocked")

    # Здесь уже обращение к реальной БД
    return user_repository.get_by_id(user_id)

1. Проверяем Redis
2. Если ключ блокировки есть → не идём в БД
3. Если ключа нет → выполняем запрос к БД

не больше 100 запросов к БД в минуту на пользователя

db:rate:user:123:2026-06-26T14:30 → 42
TTL: 60 секунд

import time


def allow_db_request(user_id: int, limit: int = 100, window: int = 60) -> bool:
    current_window = int(time.time()) // window
    key = f"db:rate:user:{user_id}:{current_window}"

    pipe = redis_client.pipeline()
    pipe.incr(key)
    pipe.expire(key, window)
    current_count, _ = pipe.execute()

    return current_count <= limit


def get_user_notifications(user_id: int):
    if not allow_db_request(user_id, limit=100, window=60):
        raise PermissionError("Too many DB requests")

    return notification_repository.list_by_user(user_id)

1-й запрос  → counter = 1  → разрешить
...
100-й запрос → counter = 100 → разрешить
101-й запрос → counter = 101 → заблокировать

не запускать два пересчёта баланса одновременно
не обрабатывать один заказ двумя воркерами
не делать параллельную миграцию/синхронизацию
не создавать один и тот же ресурс дважды

lock:order:1001 → random_token
TTL: 30 секунд

import uuid


def acquire_lock(lock_key: str, ttl_seconds: int = 30) -> str | None:
    token = str(uuid.uuid4())

    acquired = redis_client.set(
        name=lock_key,
        value=token,
        nx=True,
        ex=ttl_seconds,
    )

    if acquired:
        return token

    return None

def recalculate_order(order_id: int):
    lock_key = f"lock:order:{order_id}"
    token = acquire_lock(lock_key, ttl_seconds=30)

    if token is None:
        raise RuntimeError("Operation is already running")

    try:
        return order_service.recalculate(order_id)
    finally:
        release_lock(lock_key, token)

RELEASE_LOCK_SCRIPT = """
if redis.call("get", KEYS[1]) == ARGV[1] then
    return redis.call("del", KEYS[1])
else
    return 0
end
"""


def release_lock(lock_key: str, token: str) -> None:
    redis_client.eval(RELEASE_LOCK_SCRIPT, 1, lock_key, token)

5 неудачных попыток → заблокировать доступ на 15 минут

def register_failed_attempt(user_id: int) -> None:
    key = f"db:fail:user:{user_id}"
    attempts = redis_client.incr(key)

    if attempts == 1:
        redis_client.expire(key, 900)

    if attempts >= 5:
        redis_client.set(
            name=f"db:block:user:{user_id}",
            value="1",
            ex=900,
        )


def check_db_access(user_id: int) -> None:
    if redis_client.exists(f"db:block:user:{user_id}"):
        ttl = redis_client.ttl(f"db:block:user:{user_id}")
        raise PermissionError(f"Blocked for {ttl} seconds")

db:circuit:heavy_queries → open
TTL: 60 секунд

def check_heavy_queries_allowed() -> None:
    if redis_client.exists("db:circuit:heavy_queries"):
        raise RuntimeError("Heavy DB queries are temporarily disabled")


def run_heavy_report():
    check_heavy_queries_allowed()

    return report_repository.build_heavy_report()

тяжёлые отчёты
массовые выгрузки
дорогие фильтры
частые пересчёты

import json


def get_user_profile(user_id: int):
    cache_key = f"user:profile:{user_id}"

    cached = redis_client.get(cache_key)
    if cached is not None:
        return json.loads(cached)

    user = user_repository.get_by_id(user_id)

    redis_client.set(
        cache_key,
        json.dumps(user),
        ex=300,
    )

    return user

1. Проверяем Redis cache
2. Если данные есть → БД не трогаем
3. Если данных нет → идём в БД
4. Результат кладём в Redis

профилей
настроек пользователя
справочников
часто читаемых данных
результатов тяжёлых запросов

API endpoint / middleware / dependency
service layer
use-case layer

repository сам решает, можно ли ходить в БД

service проверяет Redis
service решает, можно ли выполнять операцию
repository только работает с БД

class UserService:
    def __init__(self, user_repo, redis_client):
        self.user_repo = user_repo
        self.redis = redis_client

    def get_user(self, user_id: int):
        if self.redis.exists(f"db:block:user:{user_id}"):
            raise PermissionError("DB access blocked")

        return self.user_repo.get_by_id(user_id)

Redis-политика доступа → service
SQL-запросы            → repository

redis_client.set("db:block:user:123", "1")

redis_client.set("db:block:user:123", "1", ex=300)

закрытый доступ к БД из интернета
отдельный DB-user для приложения
минимальные права
сетевые ограничения
connection pool limits
аудит запросов

Redis недоступен → запрещать запросы к БД?
Redis недоступен → разрешать запросы к БД?
Redis недоступен → разрешать только критичные операции?

Redis не отвечает → доступ запрещён

Redis не отвечает → идём напрямую в БД

temporary block → ключ db:block:user:{id} с TTL
rate limit      → INCR + EXPIRE
distributed lock → SET key value NX EX
circuit breaker → флаг db:circuit:* с TTL
cache           → уменьшить число обращений к БД

перед запросом в БД проверяем Redis
если Redis говорит "нельзя" → запрос к БД не выполняем
если Redis говорит "можно"  → выполняем запрос к БД