Как избежать разделения операций по шардам?

Как избежать разделения операций по шардам

Понимание проблемы

Шардирование (горизонтальное разделение данных) создает сложность при выполнении операций, которые затрагивают несколько шардов одновременно. Такие операции требуют координации между несколькими партициями данных, что снижает производительность и усложняет логику.

1. Правильный выбор ключа шардирования

Это самый критичный фактор. Ключ шардирования должен группировать связанные данные в одном шарде:

// ❌ Плохо: шардирование по user_id
// Если нужна операция по order_id, она разобьется на несколько шардов

// ✅ Хорошо: шардирование по user_id
// Все заказы одного пользователя в одном шарде
long shardId = userId % numberOfShards;

Правило: выбирайте ключ, который совпадает с главным паттерном запросов.

2. Денормализация и дублирование данных

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

// Таблица Order содержит полную информацию пользователя
public class Order {
    private long orderId;
    private long userId;
    private String userName;     // Дублирование
    private String userEmail;    // Дублирование
    private LocalDateTime createdAt;
}

Это нарушает нормализацию, но часто оправдано для производительности.

3. Местные операции внутри шарда

Проектируйте операции так, чтобы они работали целиком в одном шарде:

public class UserOrderService {
    // ✅ Локальная операция - все данные в одном шарде
    public List<Order> getUserOrders(long userId) {
        long shardId = userId % numberOfShards;
        return orderRepository.getOrdersByUserAndShard(userId, shardId);
    }

    // ❌ Глобальная операция - требует обхода всех шардов
    public List<Order> getAllOrdersForDate(LocalDate date) {
        // Требует параллельного запроса к каждому шарду
        return getAllShardsInParallel(date);
    }
}

4. Использование связанных данных в одном шарде

// ✅ Good: все данные пользователя в одном шарде
public class UserShard {
    private long userId;
    private UserProfile profile;
    private List<Order> orders;
    private List<Payment> payments;
    private List<Address> addresses;
}

5. Избегайте join-операций между шардами

// ❌ Плохо: требует join между шардами
SELECT o.id, u.name 
FROM orders o 
JOIN users u ON o.user_id = u.id
WHERE o.created_date > ?;

// ✅ Хорошо: локальная операция
SELECT o.id, o.user_name  // user_name уже в orders
FROM orders o
WHERE o.user_id = ? AND o.created_date > ?;

6. MapReduce паттерн для глобальных операций

Если кросс-шардовая операция неизбежна, используйте MapReduce:

public class ShardedAggregation {
    private final List<ShardConnection> shards;

    public long getTotalOrders(LocalDate date) {
        // MAP: запросить каждый шард параллельно
        List<CompletableFuture<Long>> futures = shards.stream()
            .map(shard -> CompletableFuture.supplyAsync(() -> 
                shard.countOrdersByDate(date)
            ))
            .collect(Collectors.toList());

        // REDUCE: агрегировать результаты
        return CompletableFuture.allOf(futures.toArray(new CompletableFuture[0]))
            .thenApply(v -> futures.stream()
                .map(CompletableFuture::join)
                .mapToLong(Long::longValue)
                .sum()
            ).join();
    }
}

7. Кэширование и асинхронные обновления

public class CachedUserStats {
    private final Cache<Long, UserStats> cache;
    private final ExecutorService executor;

    // ✅ Возвращаем кэшированное значение, обновляем асинхронно
    public UserStats getStats(long userId) {
        return cache.get(userId, key -> {
            executor.submit(() -> updateStatsAcrossShards(userId));
            return getCachedOrCompute(userId);
        });
    }
}

8. Дизайн бизнес-логики с учетом шардирования

На этапе проектирования системы:

• Определите основной ключ доступа к данным (обычно user_id)
• Проектируйте все операции вокруг этого ключа
• Избегайте операций, требующих доступа к несвязанным пользователям
• Используйте event-driven архитектуру для асинхронных кросс-шардовых обновлений

9. Мониторинг и анализ

public class ShardQueryAnalyzer {
    public void logCrossShardQuery(String query, List<Long> affectedShards) {
        if (affectedShards.size() > 1) {
            logger.warn("Cross-shard query detected: {} shards affected", affectedShards.size());
            // Отправить в мониторинг для анализа
            metrics.increment("cross_shard_queries");
        }
    }
}

Резюме

Главное правило: выберите правильный ключ шардирования и организуйте данные так, чтобы все связанные данные находились в одном шарде. Это избежит большинства кросс-шардовых операций. Для неизбежных кросс-шардовых операций используйте асинхронные паттерны и MapReduce.