- Задание 1. Выбор ключа шардирования
    
    У тебя есть сервис онлайн‑магазина с таблицами:
    
    - `users`
    - `orders`
    
    Нужно:
    
    - Выбрать, по какому полю ты будешь **шардировать пользователей** и объяснить, почему именно этот ключ, а не другие
            Я БЫ ХОТЕЛ ШАРДИРОВАТЬ ПОЛЬЗОВАТЕЛЕЙ ПО АЙДИШНИКАМ, ИМЕННО АЙДИШНИК ЭТО ЧИСЛО, ПОЭТОМУ МОЖНО ШАРДИРОВАТЬ ПО ХЭШУ, ПЛЮС КО ВСЕМУ АЙДИ НЕ ПОВТОРЯЕТСЯ.
 
    - Описать, как при выбранном ключе будут распределяться пользователи по шардам и какие типы запросов станут выполняться быстрее, а какие, наоборот, станут сложнее.
            ЕСЛИ ШАРДОВ 4, ТО ПЕРВЫЙ ПОЛЬЗОВАТЕЛЕЙ В 1ЫЙ, ВТОРОЙ ВО 2ОЙ, ТРЕТИЙ В 3ИЙ, ЧЕТВЕРТЫЙ В 0, ПЯТЫЙ В 1ЫЙ, ШЕСТОЙ ВО 2ОЙ, СЕДБМОЙ В 3ИЙ, ВОСБМОЙ В 0.

 Задание 2. Добавление нового шарда
    
    Ты шардируешь пользователей по правилу `user_id % 4` (4 шарда). Через пару лет один шард сильно перегружен, и ты хочешь перейти на `user_id % 8` (8 шардов).
    
    Нужно:
    
    - Описать, какие проблемы возникают при смене количества шардов (что происходит с существующими пользователями и их данными);
            КАК МНЕ КАЖЕТСЯ НЕОБХОДИМО БУДЕТ ЗАНОВО ВЗЯТЬ СПИСОК ВСЕХ ПОЛЬЗОВАТЕЛЕЙ (КОТОРЫЕ УЖЕ В ШАРДАХ) И РАСКИДАТЬ ПО НОВЫМ РАЗНЫМ ШАРДАМ.
    
    - Предложить общий план «перешардирования» (как переносить данные, как не потерять консистентность, что делать с новыми запросами в момент миграции).
            ПОЛУЧИТЬ ДАННЫЕ ИЗ СТАРЫХ ШАРДОВ, НЕ УДАЛЯЯ НИ ДАННЫЕ, НИ ШАРДЫ, РАСКИДАТЬ ДАННЫЕ ПО НОВЫМ ШАРДАМ (СЕРВЕРАМ) И УДАЛИТЬ СТАРЫЕ ШАРДЫ; 
            ПО ИДЕЕ ЗАПРОСЫ ВО ВРЕМЯ МИГРАЦИИ ТАК И БУДУТ ОБРАЩАТЬСЯ К СТАРЫМ ШАРДАМ, ВПЛОТЬ ДО МОМЕНТА, ПОКА ОНИ НЕ БУДУТ УДАЛЕНЫ.

НОВЫЙ ОТВЕТ: РАЗВЕРНУТЬ НОВЫЕ ШАРДЫ ПАРАЛЛЕЛЬНО СТАРЫМ И НАСТРОИТЬ ПАРАЛЛЕЛЬНУЮ МИГРАЦИЮ ДАННЫЕ В СТАРЫЕ И НОВЫЕ ШАРДЫ. ДАЛЕЕ БЕРЕМ ДАННЫЕ ИЗ СТАРЫХ ШАРДОВ И ЗАПУСКАЕМ ПРОЦЕСС КОПИРОВАНИЯ В НОВЫЕ ШАРДЫ. ПОСЛЕ ПЕРЕНОСА НАМ НУЖНО УДОСТОВЕРИТЬСЯ ЧТО ДАННЫЕ АНАЛОГИЧНО И ТАМ И ТАМ. ЕСЛИ ЕСТЬ РАСХОЖДЕНИЯ, ТО НУЖНО ИХ ДОПЕРЕНЕСТИ.
ПОТОМ НУЖНО ВЫКЛЮЧИТЬ ЗАПИСЬ В СТАРЫЕ ШАРДЫ И ОСТАВИТЬ ЗАПИСЬ НА НОВЫХ.

- Задание 3. Шардинг против партиционирования
    
    Есть одна большая база PostgreSQL с таблицей `orders`, и она начала тормозить. Команда обсуждает два варианта: сделать партиционирование в рамках одной базы или шардирование по нескольким базам/серверям.
    
    Нужно:
    
    - описать, чем принципиально отличается партиционирование от шардирования (где данные находятся и кто ими управляет);
            ШАРДЫ НАХОДЯИСЯ НА РАЗНЫХ СЕРВЕРАХ, А ПАРТИЦИИ НА ОДНОМ, СООТВЕТСТВЕННО СКОРОСТЬ БУДЕТ БЫСТРЕЕ ПРИ ШАРДЕ. ПРИ ШАРДИРОВАНИИ ВОЗНИКАЕТ ПРОБЛЕМА СОЕДИНЕНИЯ ТАБЛИЦ, ПРИ ПАРТИЦИОНИРОВАНИИ ТАКОГО НЕТ.
    
    - придумать пример, когда **достаточно** партиционирования и шардирование не нужно;
            НЕБОЛЬШАЯ ТАБЛИЦА В СОТНИ ТЫСЯЧ СТРОК НЕ ТРЕБУЕТ ШАРДИРОВАНИЯ.

    - придумать пример, когда без шардирования уже не обойтись, даже если партиции есть.
            КОЛИЧЕСТВО СТРОК СЛИШКОМ БОЛЬШОЕ, СКОРОСТЬ УПАЛА, ПОЭТОМУ ЛУЧШЕ РАСКИДАТЬ НА РАЗНЫЕ СЕРВЕРА ДАННЫЕ.