Как часто делаешь запись в базу данных

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

Это важный вопрос о design trade-offs в системах. Частота записи в БД влияет на производительность, нагрузку и консистентность данных. Правильный выбор зависит от бизнес-требований.

Принцип: Пишите в БД только необходимые данные

Когда писать каждый раз

Для critical data (критические данные) пишите в каждом запросе:

@Service
public class PaymentService {
    private final PaymentRepository paymentRepository;
    
    @Transactional
    public Payment processPayment(PaymentRequest request) {
        // КРИТИЧНО: любой платёж должен быть записан немедленно
        Payment payment = new Payment();
        payment.setAmount(request.getAmount());
        payment.setUserId(request.getUserId());
        payment.setStatus(PaymentStatus.PENDING);
        
        // Пишем в БД сразу
        return paymentRepository.save(payment);
    }
}

Примеры critical data:

• Платежи
• Заказы
• Изменения баланса счета
• Важные аудит логи

Когда можно писать реже (батчинг)

Для non-critical data (неважные данные) можно писать батчами:

@Service
public class AnalyticsService {
    private final AnalyticsRepository analyticsRepository;
    private final BlockingQueue<AnalyticsEvent> eventQueue;
    private static final int BATCH_SIZE = 100;
    
    @PostConstruct
    public void startBatchProcessor() {
        Thread processorThread = new Thread(() -> {
            List<AnalyticsEvent> batch = new ArrayList<>();
            
            while (true) {
                AnalyticsEvent event = null;
                try {
                    // Ждем максимум 5 секунд
                    event = eventQueue.poll(5, TimeUnit.SECONDS);
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
                
                if (event != null) {
                    batch.add(event);
                }
                
                // Пишем, если набрали BATCH_SIZE или прошло 5 секунд
                if (batch.size() >= BATCH_SIZE || (!batch.isEmpty() && event == null)) {
                    analyticsRepository.saveAll(batch);
                    batch.clear();
                }
            }
        });
        processorThread.setDaemon(true);
        processorThread.start();
    }
    
    public void trackEvent(AnalyticsEvent event) {
        eventQueue.offer(event); // Асинхронно
    }
}

Примеры non-critical data:

• Аналитика (page views, clicks)
• Логи (debug logs, info logs)
• Статистика

Реальные стратегии

1. Синхронная запись (Safe Default)

@Service
public class UserService {
    private final UserRepository userRepository;
    
    @Transactional
    public User createUser(CreateUserRequest request) {
        User user = new User();
        user.setEmail(request.getEmail());
        user.setName(request.getName());
        
        // Пишем в БД синхронно
        return userRepository.save(user); // Блокирует до завершения
    }
}

Плюсы: Консистентность гарантирована Минусы: Медленнее, если БД недоступна — весь запрос падает

2. Асинхронная запись (async with queue)

@Service
public class NotificationService {
    private final NotificationRepository notificationRepository;
    private final KafkaTemplate<String, NotificationEvent> kafkaTemplate;
    
    public void sendNotification(NotificationEvent event) {
        // Отправляем в Kafka асинхронно
        kafkaTemplate.send("notifications-topic", event);
        // Не ждём завершения!
    }
}

@Service
public class NotificationConsumer {
    private final NotificationRepository notificationRepository;
    
    @KafkaListener(topics = "notifications-topic")
    public void processNotification(NotificationEvent event) {
        // Пишем в БД в отдельном потоке
        notificationRepository.save(new Notification(event));
    }
}

Плюсы: Быстро, не блокирует пользователя Минусы: Временная задержка, риск потери при сбое

3. Кэширование + периодическая запись

@Service
public class ViewCounterService {
    private final ViewCountRepository viewCountRepository;
    private final RedisTemplate<String, Long> redisTemplate;
    private static final String VIEWS_PREFIX = "views:";
    
    public void recordView(String pageId) {
        // Увеличиваем счетчик в Redis (очень быстро)
        redisTemplate.opsForValue().increment(VIEWS_PREFIX + pageId);
    }
    
    @Scheduled(fixedDelay = 60000) // Каждую минуту
    public void flushViewsToDB() {
        // Пишем скопленные данные из Redis в БД
        Set<String> keys = redisTemplate.keys(VIEWS_PREFIX + "*");
        
        for (String key : keys) {
            String pageId = key.substring(VIEWS_PREFIX.length());
            Long count = (Long) redisTemplate.opsForValue().get(key);
            
            if (count != null && count > 0) {
                viewCountRepository.incrementViewCount(pageId, count);
                redisTemplate.delete(key); // Очищаем Redis
            }
        }
    }
}

Плюсы: Очень быстро, минимум нагрузки на БД Минусы: Задержка в данных, риск потери при сбое Redis

4. Write-Ahead Logging (WAL)

Запишите в лог ДО основной операции:

@Service
public class TransactionService {
    private final TransactionRepository transactionRepository;
    private final AuditLogRepository auditLogRepository;
    
    @Transactional
    public void executeTransaction(TransactionRequest request) {
        // 1. Пишем в audit log (быстро, simple insert)
        AuditLog auditLog = new AuditLog();
        auditLog.setAction("TRANSACTION_START");
        auditLog.setData(request.toString());
        auditLogRepository.save(auditLog);
        
        // 2. Выполняем бизнес-логику
        // 3. Пишем результат
        Transaction transaction = new Transaction();
        transaction.setStatus(TransactionStatus.COMPLETED);
        transactionRepository.save(transaction);
    }
}

Применяется для:

• Аудита
• Восстановления после сбоев
• Финансовых транзакций

Реальные примеры

Пример 1: E-commerce платформа

@Service
public class OrderService {
    private final OrderRepository orderRepository; // CRITICAL
    private final OrderAnalyticsQueue analyticsQueue; // NON-CRITICAL
    
    @Transactional
    public Order createOrder(CreateOrderRequest request) {
        // ВАЖНО: пишем заказ в БД сразу
        Order order = new Order();
        order.setUserId(request.getUserId());
        order.setStatus(OrderStatus.NEW);
        Order savedOrder = orderRepository.save(order);
        
        // НЕВАЖНО: отправляем событие для аналитики асинхронно
        analyticsQueue.enqueue(new OrderCreatedEvent(savedOrder.getId(), savedOrder.getUserId()));
        
        return savedOrder;
    }
}

Пример 2: Соцсеть с лайками

@Service
public class LikeService {
    private final LikeRepository likeRepository;
    private final RedisTemplate<String, Long> redisTemplate;
    
    public void likePost(UUID userId, UUID postId) {
        // Увеличиваем счетчик в Redis (мгновенно)
        String key = "likes:post:" + postId;
        redisTemplate.opsForValue().increment(key);
        
        // Сохраняем лайк в БД для истории (может быть асинхронно)
        likeRepository.save(new Like(userId, postId));
    }
    
    public long getLikeCount(UUID postId) {
        // Читаем из Redis (быстро)
        String key = "likes:post:" + postId;
        Long count = (Long) redisTemplate.opsForValue().get(key);
        return count != null ? count : 0;
    }
}

Пример 3: Система мониторинга

@Service
public class MetricsService {
    private final MetricsRepository metricsRepository;
    private final BlockingQueue<Metric> metricsQueue = new LinkedBlockingQueue<>();
    
    @PostConstruct
    public void startBatchWriter() {
        Executors.newSingleThreadExecutor().execute(() -> {
            List<Metric> batch = new ArrayList<>();
            
            while (true) {
                try {
                    // Ждём 5 секунд или набираем 1000 метрик
                    Metric metric = metricsQueue.poll(5, TimeUnit.SECONDS);
                    if (metric != null) {
                        batch.add(metric);
                    }
                    
                    if (batch.size() >= 1000 || (!batch.isEmpty() && metric == null)) {
                        metricsRepository.saveAll(batch);
                        batch.clear();
                    }
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
            }
        });
    }
    
    public void recordMetric(String name, double value) {
        metricsQueue.offer(new Metric(name, value));
    }
}

Best Practices

1. Определите, critical ли данные

// Для critical data: синхронная запись
@Transactional
public Payment processPayment(...) {
    return paymentRepository.save(payment);
}

// Для non-critical: асинхронная
public void trackUserActivity(...) {
    asyncQueue.enqueue(event);
}

2. Используйте batch inserts где возможно

// Вместо
for (User user : users) {
    userRepository.save(user); // N запросов
}

// Используйте
userRepository.saveAll(users); // 1 батч запрос

3. Мониторьте нагрузку на БД

// Логируйте время выполнения
@Service
public class UserService {
    private static final Logger logger = LoggerFactory.getLogger(UserService.class);
    
    public User createUser(CreateUserRequest request) {
        long start = System.currentTimeMillis();
        User user = userRepository.save(new User(request));
        long elapsed = System.currentTimeMillis() - start;
        
        if (elapsed > 1000) {
            logger.warn("Slow insert: {}ms", elapsed);
        }
        
        return user;
    }
}

4. Используйте транзакции правильно

// ПЛОХО: большие транзакции
@Transactional
public void processMillionRecords() {
    for (Record record : millionRecords) {
        save(record);
    }
}

// ХОРОШО: батчи в цикле
for (List<Record> batch : partition(millionRecords, 1000)) {
    processBatch(batch);
}

@Transactional
private void processBatch(List<Record> batch) {
    recordRepository.saveAll(batch);
}

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

Заключение

Фреквентность записи в БД зависит от:

1. Критичности данных — платежи пишутся всегда
2. Требования к консистентности — некритичные данные можно батчить
3. Нагрузка на БД — батчи и кэширование снижают нагрузку
4. Требования к скорости — асинхронная запись быстрее

Оптимальное решение обычно комбинирует все подходы: синхронно для critical, асинхронно для non-critical, с батчингом и кэшированием где возможно.