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

Масштабирование базы данных: горизонтальное (шардирование)

Для распределения записей БД используется горизонтальное масштабирование (Horizontal Scaling), также известное как шардирование (Sharding). Это основной метод распределения больших объёмов данных по нескольким серверам БД.

Два типа масштабирования БД

1. Vertical Scaling (Вертикальное масштабирование)

Принцип: увеличение мощности одного сервера (больше CPU, RAM, диск)

Без масштабирования:      С вертикальным масштабированием:
┌──────────────┐         ┌──────────────────────────┐
│ PostgreSQL   │    →    │ PostgreSQL (мощный)      │
│ 8GB RAM      │         │ 256GB RAM                │
│ 4 CPU cores  │         │ 64 CPU cores             │
└──────────────┘         └──────────────────────────┘
   10k req/s                    100k req/s

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

• Просто реализовать
• Нет изменения кода приложения
• Одна база данных

Недостатки:

• Дорого (экспоненциальный рост стоимости)
• Есть физический потолок производительности
• Single point of failure
• Невозможно масштабировать бесконечно

2. Horizontal Scaling (Горизонтальное масштабирование = Шардирование)

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

        ┌─────────────────────────────────┐
        │    Application Layer            │
        │  (Java REST API)                │
        └─────────────────────────────────┘
                    ↓
        ┌─────────────────────────────────┐
        │     Sharding Router/Logic       │
        │  (Определяет какой шард)        │
        └─────────────────────────────────┘
          ↙          ↓          ↘
      ┌────────┐ ┌────────┐ ┌────────┐
      │ Shard1 │ │ Shard2 │ │ Shard3 │
      │ DB-1   │ │ DB-2   │ │ DB-3   │
      │Users   │ │Users   │ │Users   │
      │A-G     │ │H-O     │ │P-Z     │
      └────────┘ └────────┘ └────────┘

Стратегии шардирования

1. Range-based Sharding (Диапазон значений)

Данные делятся по диапазону значения ключа:

public class RangeBasedSharding {
    
    public int getShardId(String userName) {
        char firstChar = userName.charAt(0);
        
        if (firstChar >= 'A' && firstChar < 'H') {
            return 0;  // Shard 1
        } else if (firstChar >= 'H' && firstChar < 'P') {
            return 1;  // Shard 2
        } else {
            return 2;  // Shard 3
        }
    }
    
    // Использование
    public void saveUser(User user) {
        int shardId = getShardId(user.getName());
        Database shard = getDatabaseShard(shardId);
        shard.save(user);
    }
}

Проблема: несбалансированное распределение данных (если много пользователей с первой буквой 'A')

2. Hash-based Sharding (Хеширование)

Используется хеш-функция для определения шарда:

public class HashBasedSharding {
    
    private static final int SHARD_COUNT = 3;
    
    public int getShardId(UUID userId) {
        // Хеш от ID определяет шард
        return Math.abs(userId.hashCode()) % SHARD_COUNT;
    }
    
    public void saveUser(User user) {
        int shardId = getShardId(user.getId());
        Database shard = getDatabaseShard(shardId);
        shard.save(user);
    }
    
    public User getUser(UUID userId) {
        int shardId = getShardId(userId);
        Database shard = getDatabaseShard(shardId);
        return shard.findById(userId);
    }
}

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

• Равномерное распределение данных
• Проста реализация

Недостатки:

• Сложно добавлять новые шарды (rehashing)
• Нужно перемещать данные при изменении количества шардов

3. Directory-based Sharding (Таблица маршрутизации)

Отдельная таблица определяет на каком шарде находятся данные:

public class DirectoryBasedSharding {
    
    // Таблица: userId → shardId
    private Map<UUID, Integer> shardDirectory;
    
    public int getShardId(UUID userId) {
        Integer shardId = shardDirectory.get(userId);
        if (shardId == null) {
            // Не найден, нужно создать новую запись
            shardId = allocateNewShard();
            shardDirectory.put(userId, shardId);
        }
        return shardId;
    }
    
    public void saveUser(User user) {
        int shardId = getShardId(user.getId());
        Database shard = getDatabaseShard(shardId);
        shard.save(user);
    }
}

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

• Гибкое добавление шардов
• Легко переместить данные

Недостатки:

• Дополнительный запрос в directory таблицу
• Bottleneck в directory сервисе

4. Geographic Sharding (Географическое распределение)

Данные шардируются по регионам:

public class GeographicSharding {
    
    public int getShardId(User user) {
        String country = user.getCountry();
        
        switch (country) {
            case "US":
            case "CA":
            case "MX":
                return 0;  // Americas shard
            case "GB":
            case "FR":
            case "DE":
                return 1;  // Europe shard
            case "JP":
            case "CN":
            case "IN":
                return 2;  // Asia shard
            default:
                return 3;  // Default shard
        }
    }
}

Консистентное хеширование (Consistent Hashing)

Для упрощения добавления новых шардов используется консистентное хеширование:

import java.util.*;

public class ConsistentHashing {
    
    private final SortedMap<Long, String> ring = new TreeMap<>();
    private final int replicaCount;
    
    public ConsistentHashing(List<String> shards, int replicaCount) {
        this.replicaCount = replicaCount;
        for (String shard : shards) {
            addShard(shard);
        }
    }
    
    private void addShard(String shard) {
        for (int i = 0; i < replicaCount; i++) {
            long hash = hash(shard + ":" + i);
            ring.put(hash, shard);
        }
    }
    
    public String getShard(String userId) {
        if (ring.isEmpty()) {
            return null;
        }
        
        long hash = hash(userId);
        SortedMap<Long, String> tailMap = ring.tailMap(hash);
        long key = tailMap.isEmpty() ? ring.firstKey() : tailMap.firstKey();
        return ring.get(key);
    }
    
    private long hash(String key) {
        return Math.abs(key.hashCode());
    }
}

Практический пример: Spring Boot с шардированием

@Configuration
public class ShardingConfiguration {
    
    private static final int SHARD_COUNT = 3;
    
    @Bean
    public ShardingService shardingService() {
        return new ShardingService(SHARD_COUNT);
    }
}

@Service
public class ShardingService {
    
    private final int shardCount;
    private final List<UserRepository> shardedRepositories;
    
    public ShardingService(int shardCount) {
        this.shardCount = shardCount;
        this.shardedRepositories = new ArrayList<>();
        // Инициализация репозиториев для каждого шарда
        for (int i = 0; i < shardCount; i++) {
            // Каждый репозиторий подключается к своему шарду
            shardedRepositories.add(createRepositoryForShard(i));
        }
    }
    
    public int getShardId(UUID userId) {
        return Math.abs(userId.hashCode()) % shardCount;
    }
    
    public void saveUser(User user) {
        int shardId = getShardId(user.getId());
        shardedRepositories.get(shardId).save(user);
    }
    
    public Optional<User> findUser(UUID userId) {
        int shardId = getShardId(userId);
        return shardedRepositories.get(shardId).findById(userId);
    }
}

@RestController
public class UserController {
    
    @Autowired
    private ShardingService shardingService;
    
    @PostMapping("/users")
    public ResponseEntity<User> createUser(@RequestBody User user) {
        shardingService.saveUser(user);
        return ResponseEntity.ok(user);
    }
    
    @GetMapping("/users/{id}")
    public ResponseEntity<User> getUser(@PathVariable UUID id) {
        Optional<User> user = shardingService.findUser(id);
        return user.map(ResponseEntity::ok)
                   .orElse(ResponseEntity.notFound().build());
    }
}

Challenges и решения при шардировании

Challenge 1: Распределённые запросы

Проблема: запрос, затрагивающий несколько шардов

// ❌ Проблема: нужно запросить ВСЕ шарды
public List<User> getAllUsersByCountry(String country) {
    List<User> result = new ArrayList<>();
    
    // Запрашиваем каждый шард
    for (int i = 0; i < shardCount; i++) {
        List<User> shardResults = shardedRepositories.get(i)
            .findByCountry(country);
        result.addAll(shardResults);
    }
    
    return result;
}

Challenge 2: Горячие данные

Проблема: один шард получает больше трафика

// Решение: дополнительные replica shards
public class ReplicatedSharding {
    private final Map<Integer, List<Database>> shardReplicas;
    
    public User getUser(UUID userId) {
        int shardId = getShardId(userId);
        // Выбираем replica с минимальной нагрузкой
        Database replica = selectLeastLoadedReplica(shardId);
        return replica.findById(userId);
    }
}

Challenge 3: Изменение количества шардов

Проблема: добавление нового шарда требует rehashing

// Решение: Consistent Hashing (минимизирует перемещение данных)
// При добавлении нового шарда, только часть данных переместится
public void addNewShard(String newShardId) {
    consistentHashing.addShard(newShardId);
    // Rebalance только необходимые данные
    rebalanceData(newShardId);
}

Инструменты для шардирования

Apache ShardingSphere — популярный инструмент для Java

<dependency>
    <groupId>org.apache.shardingsphere</groupId>
    <artifactId>shardingsphere-jdbc-core</artifactId>
    <version>5.3.0</version>
</dependency>

ProxySQL — MySQL proxy с встроенным шардированием

Citus — PostgreSQL extension для шардирования

Сравнение: Vertical vs Horizontal Scaling

Заключение

Для распределения записей БД используется Horizontal Scaling / Шардирование:

✅ Range-based — простая, но может быть несбалансированной

✅ Hash-based — равномерное распределение, но сложно добавлять шарды

✅ Directory-based — гибкая, но требует доп. таблицы

✅ Consistent Hashing — оптимальное решение для масштабирования

⚠️ Challenges: распределённые запросы, горячие данные, rebalancing

⚠️ Trade-offs: complexity vs unlimited scalability

Выбор стратегии зависит от требований приложения и паттернов доступа к данным.