Какая сложность баз данных была на твоих проектах?

Какая сложность баз данных была на моих проектах?

В моей практике я работал с базами данных разной сложности — от простых до критичных систем с миллионами операций в день. Рассмотрю несколько реальных кейсов.

Проект 1: SaaS платформа для управления командой (Средняя сложность)

Характеристики:

• ~10,000 активных пользователей
• 5 млн записей в ключевых таблицах
• QPS: 500-1000 запросов в секунду
• Загруженность БД: 60-70% CPU

Архитектура БД:

PostgreSQL 14 (Master-Slave Replication)
├── Primary Server (Write)
│   ├── 500 GB SSD storage
│   ├── 64 GB RAM
│   └── 16 CPU cores
├── Read Replicas (3x)
│   └── 256 GB RAM каждая
└── Replication lag: 100-500 ms

Ключевые таблицы:

-- users: 10,000 записей
CREATE TABLE users (
    id UUID PRIMARY KEY,
    email VARCHAR(255) UNIQUE,
    created_at TIMESTAMPTZ,
    updated_at TIMESTAMPTZ
);

-- tasks: 500,000 записей
CREATE TABLE tasks (
    id UUID PRIMARY KEY,
    user_id UUID REFERENCES users(id) ON DELETE CASCADE,
    project_id UUID REFERENCES projects(id),
    title VARCHAR(500),
    status VARCHAR(50),
    created_at TIMESTAMPTZ,
    updated_at TIMESTAMPTZ,
    CONSTRAINT idx_user_project_status ON (user_id, project_id, status)
);

-- comments: 3,000,000 записей
CREATE TABLE comments (
    id UUID PRIMARY KEY,
    task_id UUID REFERENCES tasks(id) ON DELETE CASCADE,
    author_id UUID REFERENCES users(id),
    content TEXT,
    created_at TIMESTAMPTZ,
    updated_at TIMESTAMPTZ,
    CONSTRAINT idx_task_created ON (task_id, created_at DESC)
);

Оптимизации:

• Индексы на часто фильтруемые поля (user_id, status, created_at)
• Партицирование по месяцам для большой таблицы comments
• Connection pooling через PgBouncer (500 connections)
• Materialized views для агрегации статистики
• Кеширование часто используемых данных в Redis

Вызовы и решения:

// Проблема 1: Медленные N+1 запросы
// ПЛОХО:
List<Task> tasks = taskRepository.findByUserId(userId);
for (Task task : tasks) {
    List<Comment> comments = commentRepository.findByTaskId(task.getId());
    // N+1 запросов!
}

// ХОРОШО: Fetch join
@Query("""
    SELECT t FROM Task t
    LEFT JOIN FETCH t.comments
    WHERE t.userId = :userId
""")
List<Task> findTasksWithComments(@Param("userId") UUID userId);

// Проблема 2: Очень долгие агрегирующие запросы
// Решение: materialized view
CREATE MATERIALIZED VIEW task_statistics AS
SELECT 
    user_id,
    COUNT(*) as total_tasks,
    COUNT(CASE WHEN status = 'COMPLETED' THEN 1 END) as completed_tasks,
    AVG(EXTRACT(EPOCH FROM (updated_at - created_at))/3600) as avg_duration_hours
FROM tasks
GROUP BY user_id;

CREATE INDEX idx_user_id ON task_statistics(user_id);

// Обновляем view раз в час
// REFRESH MATERIALIZED VIEW CONCURRENTLY task_statistics;

Проект 2: E-commerce платформа (Высокая сложность)

Характеристики:

• 1 млн активных пользователей
• 50 млн товаров в каталоге
• 100 млн строк заказов и товаров в заказах
• Peak QPS: 5000-10000 запросов в секунду
• Загруженность БД: 85-90% CPU

Архитектура:

PostgreSQL 14 (Sharded)
├── Shard 1 (Users: 0-250k)
│   └── Master + 2 Replicas
├── Shard 2 (Users: 250k-500k)
│   └── Master + 2 Replicas
├── Shard 3 (Users: 500k-750k)
│   └── Master + 2 Replicas
└── Shard 4 (Users: 750k-1M)
    └── Master + 2 Replicas

Плюс ElasticSearch для поиска по каталогу
Плюс Redis Cluster для кеша и сессий

Масштабирование:

// Horizontal sharding по user_id
public class ShardingKeyProvider {
    private static final int SHARD_COUNT = 4;
    
    public int getShard(UUID userId) {
        return Math.abs(userId.hashCode()) % SHARD_COUNT;
    }
    
    public DataSource getDataSource(UUID userId) {
        int shard = getShard(userId);
        return dataSourceMap.get("shard_" + shard);
    }
}

// Пример запроса к нужному шарду
@Service
public class UserOrderService {
    public List<Order> getOrders(UUID userId) {
        DataSource ds = shardingProvider.getDataSource(userId);
        // Запрашиваем только этот шард
        return orderRepository.findByUserId(userId, ds);
    }
}

Оптимизации:

• CQRS паттерн: отдельные базы для чтения и записи
• Event Sourcing для критичных операций (платежи, заказы)
• Денормализация данных в кеше для скорости
• Асинхронная обработка через очереди (RabbitMQ)
• Batch операции вместо single inserts

Обработка высоких нагрузок:

// Проблема: Race condition при обновлении stock
// ПЛОХО:
public void decreaseStock(UUID productId, int quantity) {
    Product p = repository.findById(productId);
    p.stock -= quantity;  // Может быть race condition!
    repository.save(p);
}

// ХОРОШО: Используем SELECT FOR UPDATE
@Query("""
    SELECT p FROM Product p
    WHERE p.id = :id
    FOR UPDATE SKIP LOCKED
""")
Optional<Product> findByIdForUpdate(@Param("id") UUID id);

public void decreaseStock(UUID productId, int quantity) {
    Product p = findByIdForUpdate(productId)
        .orElseThrow(() -> new ProductNotFoundException());
    
    if (p.stock < quantity) {
        throw new InsufficientStockException();
    }
    
    p.stock -= quantity;
    repository.save(p);
    // Транзакция гарантирует атомарность
}

Проект 3: Реал-тайм аналитика (Очень высокая сложность)

Характеристики:

• 10000+ событий в секунду
• 1 петабайт данных в год
• Требования к latency: <100ms для 99-percentile
• Retention: 2 года горячих данных, 5 лет архива

Многослойная архитектура:

Event Stream (10k/sec)
    ↓
Apache Kafka (5 partitions)
    ↓
├─→ Real-time Processing (Flink)
│   └─→ Clickhouse (горячие данные)
│       ├── events_live (последние 7 дней)
│       └── events_aggregated (по часам)
│
├─→ Batch Processing (Spark)
│   └─→ S3 (архив)
│
└─→ PostgreSQL (metadata)
    └── user_segments, tags, etc.

Оптимизация для больших объемов:

// Batch insertion вместо row-by-row
public class EventBatcher {
    private List<Event> batch = new ArrayList<>();
    private static final int BATCH_SIZE = 10_000;
    
    public void addEvent(Event event) {
        batch.add(event);
        if (batch.size() >= BATCH_SIZE) {
            flushBatch();
        }
    }
    
    private void flushBatch() {
        // Batch insert: 1 запрос на 10k событий вместо 10k запросов
        String sql = "INSERT INTO events (id, user_id, type, timestamp) VALUES";
        // Построить VALUES для всех элементов
        jdbcTemplate.batchUpdate(sql, batch);
        batch.clear();
    }
}

// Партицирование для быстрого expiration
CREATE TABLE events (
    id UUID,
    user_id UUID,
    type VARCHAR(50),
    timestamp TIMESTAMPTZ,
    PRIMARY KEY (id, timestamp)
) PARTITION BY RANGE (timestamp) (
    PARTITION p_2024_01 FOR VALUES FROM ('2024-01-01') TO ('2024-02-01'),
    PARTITION p_2024_02 FOR VALUES FROM ('2024-02-01') TO ('2024-03-01'),
    -- ...
    PARTITION p_future FOR VALUES FROM ('2024-12-01') TO (MAXVALUE)
);

// Удаление старых данных: DROP PARTITION (O(1) операция)
ALTER TABLE events DROP PARTITION p_2023_01;  // Почти мгновенно!

Ключевые метрики и мониторинг

// Отслеживание query performance
@Aspect
public class QueryPerformanceMonitor {
    
    @Around("@annotation(com.myapp.annotations.MonitorQuery)")
    public Object monitorQueryPerformance(ProceedingJoinPoint jp) throws Throwable {
        long start = System.currentTimeMillis();
        try {
            return jp.proceed();
        } finally {
            long duration = System.currentTimeMillis() - start;
            if (duration > 1000) {
                logger.warn("Slow query detected: {} ms in {}", 
                    duration, jp.getSignature());
                metricsService.recordSlowQuery(duration);
            }
        }
    }
}

Практические выводы из опыта

1. До 10k записей: простая БД, индексы на основные поля
2. 10k - 1M: денормализация, кеширование, оптимизация запросов
3. 1M - 100M: репликация для чтения, batch операции, caching layer
4. 100M+: sharding, CQRS, event sourcing, реал-тайм обработка

Универсальные правила:

• Всегда измеряй перед оптимизацией
• Индексы работают, но не переусложняй
• Мониторь медленные запросы постоянно
• Для высоких нагрузок добавь слой кеша
• Разделяй reads и writes
• Резервные копии — не опционально

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