Какую применил бы стратегию размещения по Shard?

Стратегии шардирования: выбор оптимального подхода

Шардирование - это критическая стратегия горизонтального масштабирования баз данных. Выбор стратегии зависит от характера данных и требований приложения.

Ключевые стратегии шардирования

1. Range-Based Sharding (по диапазонам)

Описание: Данные распределяются по диапазонам значений (например, по ID или дате).

public class RangeShardResolver {
    private static final int SHARD_COUNT = 4;
    
    public int getShardId(long userId) {
        // Пример: userId 1-1000000 → shard 0
        // userId 1000001-2000000 → shard 1
        return (int) ((userId / 1000000) % SHARD_COUNT);
    }
}

Преимущества:

• Простая реализация
• Легко добавлять новые шарды
• Естественен для временных рядов

Недостатки:

• Неравномерное распределение нагрузки (hotspots)
• Усложняется переба­лансировка

2. Hash-Based Sharding (по хешированию)

Описание: Применяется хеш-функция к ключу шардирования.

public class HashShardResolver {
    private static final int SHARD_COUNT = 4;
    
    public int getShardId(String userId) {
        // Последовательное распределение по хешу
        return Math.abs(userId.hashCode()) % SHARD_COUNT;
    }
    
    // Для более равномерного распределения
    public int getShardIdConsistent(String userId) {
        // Consistent hashing для минимизации переноса данных
        // при изменении количества шардов
        return consistentHashRing.getNode(userId);
    }
}

Преимущества:

• Равномерное распределение нагрузки
• Хорошо работает с добавлением новых шардов (consistent hashing)

Недостатки:

• Сложнее query'ировать без ключа шардирования
• Требует дополнительной инфраструктуры

3. Directory-Based Sharding (по справочнику)

Описание: Отдельная таблица/сервис хранит маппинг ключей на шарды.

public class DirectoryShardResolver {
    private ShardMappingRepository mappingRepo;
    
    public int getShardId(String userId) {
        ShardMapping mapping = mappingRepo.findByUserId(userId);
        return mapping.getShardId();
    }
    
    // Гибкость: легко переносить данные без изменения логики
    public void reassignShard(String userId, int newShardId) {
        mappingRepo.updateShardAssignment(userId, newShardId);
    }
}

Преимущества:

• Максимальная гибкость
• Легко переносить данные между шардами
• Поддерживает сложные стратегии

Недостатки:

• Требует дополнительной БД для справочника
• Потенциальная точка отказа

Мой выбор в зависимости от сценария

Для e-commerce платформы:

public class ECommerceShardStrategy {
    // Ключ шардирования: userId (пользователь стабилен)
    // Стратегия: Hash-Based
    
    public int resolveUserShard(String userId) {
        return Math.abs(userId.hashCode()) % SHARD_COUNT;
    }
    
    // Все заказы пользователя на одном шарде
    public List<Order> getOrdersByUser(String userId) {
        int shardId = resolveUserShard(userId);
        Database db = shardCluster.getDatabase(shardId);
        return db.query("SELECT * FROM orders WHERE user_id = ?", userId);
    }
}

Почему так:

• Пользователь - стабильный идентификатор
• Все его данные вместе - быстрые запросы
• Hash распределяет равномерно

Для аналитической системы:

public class AnalyticsShardStrategy {
    // Ключ шардирования: дата события
    // Стратегия: Range-Based
    
    public int resolveEventShard(LocalDate eventDate) {
        // Каждый месяц - новый шард
        YearMonth ym = YearMonth.from(eventDate);
        return ((ym.getYear() - 2020) * 12 + ym.getMonthValue()) % SHARD_COUNT;
    }
    
    // Архивирование старых данных просто
    public void archiveOldShard(int shardId) {
        shardCluster.moveToArchival(shardId);
    }
}

Почему так:

• Естественное разделение по времени
• Легко добавлять новые периоды
• Простое архивирование

Для системы с переменным трафиком:

public class DynamicShardStrategy {
    // Стратегия: Directory-Based
    private DirectoryService directoryService;
    
    public int resolveEntityShard(String entityId) {
        return directoryService.lookupShard(entityId);
    }
    
    // Переба­лансировка без простоев
    public void rebalanceLoad() {
        Map<Integer, Integer> shardLoad = calculateLoad();
        int overloadedShard = findMostLoaded(shardLoad);
        int underloadedShard = findLeastLoaded(shardLoad);
        
        List<String> entitiesToMove = selectEntitiesForMigration(
            overloadedShard, underloadedShard);
        
        for (String entityId : entitiesToMove) {
            directoryService.reassignShard(entityId, underloadedShard);
        }
    }
}

Практические рекомендации

Выбирай Range-Based когда:

• Есть естественный порядок (даты, ID последовательные)
• Нужна простота

Выбирай Hash-Based когда:

• Нужно равномерное распределение
• Нет явного порядка в данных
• Не планируешь частую переба­лансировку

Выбирай Directory-Based когда:

• Нужна максимальная гибкость
• Требуется частая переба­лансировка
• Готов к усложнению инфраструктуры

Антипаттерны

• ❌ Шардирование без ясного ключа - запросы будут хитить все шарды
• ❌ Игнорирование hotspots - некоторые шарды будут перегружены
• ❌ Отсутствие стратегии миграции - переба­лансировка станет ночным кошмаром