С какими NoSQL-базами работал

Мой опыт работы с NoSQL-базами

Я работал с разными типами NoSQL баз в production. Расскажу про каждый, его плюсы/минусы и когда его использовать.

1. MongoDB (Document Database)

Опыт: 4 года в production, 100GB+ объёмы

Когда использовал:

• Хранение user profiles (гибкая схема)
• Events storage (JSON структуры разных типов)
• Cache layer для быстрого доступа

Плюсы:

# Гибкость схемы
db.users.insertOne({
    "_id": 1,
    "name": "John",
    "email": "john@example.com",
    "preferences": {  # Nested documents
        "language": "en",
        "theme": "dark"
    },
    "tags": ["vip", "premium"]  # Arrays
})

# vs SQL: нужна была бы отдельная таблица для preferences

# Быстрый поиск по вложенным полям
db.users.find({"preferences.language": "en"})

Минусы:

# Отсутствие ACID транзакций (было до версии 4.0)
# Problematic: перевод денег (должна быть атомарность)

# Дубликация данных при joins
db.orders.find()  # Содержит поля user_name, user_email
# При обновлении информации о пользователе надо обновлять везде!

# Нет JOIN операций (нужен Application Join)
orders = db.orders.find({"status": "pending"})
for order in orders:
    user = db.users.find_one({"_id": order["user_id"]})
    # Application-level join (медленнее чем БД JOIN)

Когда использовал:

• ✅ Session storage (временные данные)
• ✅ User preferences (гибкая структура)
• ✅ Logs aggregation (JSON events)
• ❌ Financial transactions (нужны ACID)
• ❌ Highly normalized data (лучше SQL)

2. Redis (Key-Value Store + Cache)

Опыт: 6+ лет, от small до 100GB кластер

Когда использовал:

• Session кэширование
• Rate limiting
• Real-time counters (DAU, online users)
• Task queue (background jobs)
• Distributed cache

Плюсы:

# Невероятная скорость (in-memory)
redis = Redis()
redis.set("user:123:name", "John")  # microseconds
name = redis.get("user:123:name")  # microseconds

# Атомарные операции
redis.incr("daily_active_users")  # Increment counter atomically
redis.lpush("job_queue", job_id)  # Push to queue atomically

# Expiration (TTL) встроена
redis.setex("session:abc123", 3600, session_data)  # Expires in 1 hour

# Pub/Sub для real-time
pub = redis.publish("notifications", {"user_id": 123, "msg": "New message"})
# Clients подписанные на "notifications" получат сообщение мгновенно

Минусы:

# Volatility (volatile by default)
# Если Redis падает, данные теряются
# Решение: RDB snapshots, AOF logs (но это медленнее)

# Limited query capabilities
# Нельзя: SELECT * WHERE age > 18
# Только простой lookup по key

# Масштабирование требует Clustering
# Не как SQL, где можно просто реплицировать

# Все данные в памяти (дорого)
# 1GB RAM = стоит в облаке $30-100 в месяц

Когда использовал:

• ✅ Session storage
• ✅ Real-time counters
• ✅ Caching DB results
• ✅ Rate limiting
• ✅ Leaderboards (sorted sets)
• ❌ Primary storage (слишком дорого)
• ❌ Complex queries

3. Cassandra (Wide-column store)

Опыт: 2 года, 500GB+ time-series данные

Когда использовал:

• Time-series events (billions per day)
• Immutable event logs
• High write throughput
• No updates (only inserts)

Плюсы:

# Невероятный write throughput
# Может писать миллионы событий в секунду
# vs PostgreSQL: 10-100k ops/sec
# vs Cassandra: 1M+ ops/sec

# Distributed by design
# Data реплицируется автоматически
# No single point of failure

# Perfect для time-series
CREATE TABLE events (
    year INT,
    month INT,
    day INT,
    user_id INT,
    timestamp TIMESTAMP,
    event_type TEXT,
    PRIMARY KEY ((year, month, day), user_id, timestamp)
);

# Partition key: (year, month, day) — для efficient time-range queries

Минусы:

# Сложный операционный опыт (DevOps nightmare)
# Нужно понимать:
# - Replication factor
# - Consistency levels
# - GC паузы
# - Compaction strategy

# Нет JOIN операций
# Нет транзакций
# Нет простых UPDATE'ов (нужны tombstones)

# Требует тщательного моделирования
# Нельзя просто запустить, нужно знать access patterns

Когда использовал:

• ✅ Event logs (immutable, time-series)
• ✅ High write throughput
• ✅ Distributed storage
• ❌ Transactional data
• ❌ Complex queries
• ❌ Frequent updates

4. DynamoDB (AWS Managed key-value)

Опыт: 3 года, serverless приложения

Когда использовал:

• Lambda функции storage
• Serverless applications
• API backing store
• User data (not too complex)

Плюсы:

# Managed service (AWS handle infrastructure)
import boto3
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('users')

table.put_item(Item={
    'user_id': '123',
    'email': 'john@example.com',
    'preferences': {
        'notifications': True,
        'language': 'en'
    }
})

# Auto-scaling
# AWS автоматически добавляет capacity при спайках
# Не нужно manually управлять сервером

# On-demand pricing
# Платишь только за то, что использовал

Минусы:

# Очень дорого при большом объёме
# 1 million reads = ~$0.25
# vs Cassandra (self-hosted): ~$0.001

# Limited query capabilities
# Нельзя сложные фильтры
response = table.query(
    KeyConditionExpression='user_id = :uid',
    ExpressionAttributeValues={':uid': '123'}
)

# Нельзя: WHERE age > 18 AND country = 'US'
# Можно только: WHERE partition_key = X AND sort_key = Y

# Cold start для Lambda (~1-2 segundos)

Когда использовал:

• ✅ Serverless applications
• ✅ API backing store
• ✅ Quick prototypes
• ❌ Large-scale analytical queries
• ❌ Cost-sensitive applications

5. Elasticsearch (Search + Analytics)

Опыт: 5 лет, logs + search

Когда использовал:

• Full-text search (UI поиск по продуктам)
• Logs aggregation (ELK stack)
• Analytics (temporal patterns)
• Real-time metrics

Плюсы:

# Мощный full-text search
response = es.search(
    index="products",
    body={
        "query": {
            "multi_match": {
                "query": "wireless headphones",
                "fields": ["name", "description"]
            }
        }
    }
)
# Найдёт: "The best wireless audio headphones"
# vs SQL LIKE: очень медленно при большом объёме

# Агрегация данных (предшественник modern OLAP)
aggs = {
    "products_by_category": {
        "terms": {
            "field": "category.keyword",
            "size": 10
        }
    }
}

Минусы:

# Требует постоянной оптимизации (tuning nightmare)
# - Index refresh rate
# - Shard count
# - Replication factor

# Дорогой в памяти (как Redis)
# Нужно много RAM для индексов

# Сложное обновление индексов
# При схемы изменении часто нужен reindex

# Inconsistency issues
# Es — NOT consistent like SQL

Когда использовал:

• ✅ Full-text search
• ✅ Log aggregation
• ✅ Real-time analytics
• ❌ Primary source of truth
• ❌ Transactional data

6. BigTable / HBase (Google's big data engine)

Опыт: 2 года в Google Cloud

Когда использовал:

• Real-time analytics
• Time-series at scale
• Low-latency random access

Плюсы:

# Petabyte-scale
# Может хранить петабайты данных

# Consistent reads
# Не как Cassandra (eventual consistency)
# BigTable гарантирует strong consistency

# Low latency reads
# ~10ms для random access

Минусы:

# Очень сложная в использовании
# Steep learning curve

# Дорого (Google Cloud pricing)

Сравнительная таблица

┌─────────────────┬──────────┬──────────┬──────────┬──────────────┐
│ База            │ Write    │ Read     │ Query    │ Consistency  │
├─────────────────┼──────────┼──────────┼──────────┼──────────────┤
│ MongoDB         │ Medium   │ Good     │ Flexible │ Strong       │
│ Redis           │ V. Good  │ V. Good  │ Limited  │ Strong       │
│ Cassandra       │ V. Good  │ Medium   │ Limited  │ Eventual     │
│ DynamoDB        │ Good     │ Good     │ Limited  │ Strong       │
│ Elasticsearch   │ Medium   │ V. Good  │ Search   │ Eventual     │
│ BigTable        │ Good     │ V. Good  │ Limited  │ Strong       │
└─────────────────┴──────────┴──────────┴──────────┴──────────────┘

Когда SQL лучше, чем NoSQL

# Когда структура данных стабильна
CREATE TABLE users (
    user_id INT PRIMARY KEY,
    email VARCHAR(255),
    created_at TIMESTAMP
);

# Когда нужны транзакции
BEGIN TRANSACTION;
    UPDATE users SET balance = balance - 100 WHERE id = 1;
    UPDATE users SET balance = balance + 100 WHERE id = 2;
COMMIT;

# Когда нужны JOIN'ы
SELECT u.name, COUNT(o.id) as order_count
FROM users u
JOIN orders o ON u.id = o.user_id
GROUP BY u.id;

# Когда нужна ACID гарантия

Итог: выбор БД для Data Engineer

Для аналитики:

• ✅ Snowflake / BigQuery / Redshift (SQL DW)
• ❌ MongoDB (плохо для JOIN'ов)

Для транзакционных данных:

• ✅ PostgreSQL / MySQL (ACID, strong consistency)
• ❌ Cassandra (eventual consistency)

Для real-time events:

• ✅ Cassandra / Kafka + ClickHouse
• ❌ MongoDB (медленнее при millions/sec)

Для caching:

• ✅ Redis
• ❌ PostgreSQL (намного медленнее)

Для logs:

• ✅ Elasticsearch / ClickHouse
• ❌ Cassandra (нет полнотекстового поиска)

Мой подход

Я не поклонник "NoSQL is better" или "SQL is better". Я использую:

Полиглот подход = RIGHT TOOL FOR RIGHT JOB

┌─────────────────────────┐
│ Data Layer              │
├─────────────────────────┤
│ PostgreSQL (primary)    │  ← ACID, consistency
│ Redis (cache)           │  ← speed
│ Elasticsearch (search)  │  ← full-text
│ Kafka (streaming)       │  ← events
│ BigQuery (analytics)    │  ← SQL DW
└─────────────────────────┘

Каждый инструмент делает своё хорошо. Мой опыт с NoSQL помог мне понимать, когда их использовать и когда говорить "нет, здесь нужна SQL БД".