Dmitry Medvedev
45 lines
5.2 KiB
SQL
45 lines
5.2 KiB
SQL
- Задание 1. Выбор ключа шардирования
|
||
|
||
У тебя есть сервис онлайн‑магазина с таблицами:
|
||
|
||
- `users`
|
||
- `orders`
|
||
|
||
Нужно:
|
||
|
||
- Выбрать, по какому полю ты будешь **шардировать пользователей** и объяснить, почему именно этот ключ, а не другие
|
||
Я БЫ ХОТЕЛ ШАРДИРОВАТЬ ПОЛЬЗОВАТЕЛЕЙ ПО АЙДИШНИКАМ, ИМЕННО АЙДИШНИК ЭТО ЧИСЛО, ПОЭТОМУ МОЖНО ШАРДИРОВАТЬ ПО ХЭШУ, ПЛЮС КО ВСЕМУ АЙДИ НЕ ПОВТОРЯЕТСЯ.
|
||
|
||
- Описать, как при выбранном ключе будут распределяться пользователи по шардам и какие типы запросов станут выполняться быстрее, а какие, наоборот, станут сложнее.
|
||
ЕСЛИ ШАРДОВ 4, ТО ПЕРВЫЙ ПОЛЬЗОВАТЕЛЕЙ В 1ЫЙ, ВТОРОЙ ВО 2ОЙ, ТРЕТИЙ В 3ИЙ, ЧЕТВЕРТЫЙ В 0, ПЯТЫЙ В 1ЫЙ, ШЕСТОЙ ВО 2ОЙ, СЕДБМОЙ В 3ИЙ, ВОСБМОЙ В 0.
|
||
|
||
Задание 2. Добавление нового шарда
|
||
|
||
Ты шардируешь пользователей по правилу `user_id % 4` (4 шарда). Через пару лет один шард сильно перегружен, и ты хочешь перейти на `user_id % 8` (8 шардов).
|
||
|
||
Нужно:
|
||
|
||
- Описать, какие проблемы возникают при смене количества шардов (что происходит с существующими пользователями и их данными);
|
||
КАК МНЕ КАЖЕТСЯ НЕОБХОДИМО БУДЕТ ЗАНОВО ВЗЯТЬ СПИСОК ВСЕХ ПОЛЬЗОВАТЕЛЕЙ (КОТОРЫЕ УЖЕ В ШАРДАХ) И РАСКИДАТЬ ПО НОВЫМ РАЗНЫМ ШАРДАМ.
|
||
|
||
- Предложить общий план «перешардирования» (как переносить данные, как не потерять консистентность, что делать с новыми запросами в момент миграции).
|
||
ПОЛУЧИТЬ ДАННЫЕ ИЗ СТАРЫХ ШАРДОВ, НЕ УДАЛЯЯ НИ ДАННЫЕ, НИ ШАРДЫ, РАСКИДАТЬ ДАННЫЕ ПО НОВЫМ ШАРДАМ (СЕРВЕРАМ) И УДАЛИТЬ СТАРЫЕ ШАРДЫ;
|
||
ПО ИДЕЕ ЗАПРОСЫ ВО ВРЕМЯ МИГРАЦИИ ТАК И БУДУТ ОБРАЩАТЬСЯ К СТАРЫМ ШАРДАМ, ВПЛОТЬ ДО МОМЕНТА, ПОКА ОНИ НЕ БУДУТ УДАЛЕНЫ.
|
||
|
||
НОВЫЙ ОТВЕТ: РАЗВЕРНУТЬ НОВЫЕ ШАРДЫ ПАРАЛЛЕЛЬНО СТАРЫМ И НАСТРОИТЬ ПАРАЛЛЕЛЬНУЮ МИГРАЦИЮ ДАННЫЕ В СТАРЫЕ И НОВЫЕ ШАРДЫ. ДАЛЕЕ БЕРЕМ ДАННЫЕ ИЗ СТАРЫХ ШАРДОВ И ЗАПУСКАЕМ ПРОЦЕСС КОПИРОВАНИЯ В НОВЫЕ ШАРДЫ. ПОСЛЕ ПЕРЕНОСА НАМ НУЖНО УДОСТОВЕРИТЬСЯ ЧТО ДАННЫЕ АНАЛОГИЧНО И ТАМ И ТАМ. ЕСЛИ ЕСТЬ РАСХОЖДЕНИЯ, ТО НУЖНО ИХ ДОПЕРЕНЕСТИ.
|
||
ПОТОМ НУЖНО ВЫКЛЮЧИТЬ ЗАПИСЬ В СТАРЫЕ ШАРДЫ И ОСТАВИТЬ ЗАПИСЬ НА НОВЫХ.
|
||
|
||
- Задание 3. Шардинг против партиционирования
|
||
|
||
Есть одна большая база PostgreSQL с таблицей `orders`, и она начала тормозить. Команда обсуждает два варианта: сделать партиционирование в рамках одной базы или шардирование по нескольким базам/серверям.
|
||
|
||
Нужно:
|
||
|
||
- описать, чем принципиально отличается партиционирование от шардирования (где данные находятся и кто ими управляет);
|
||
ШАРДЫ НАХОДЯИСЯ НА РАЗНЫХ СЕРВЕРАХ, А ПАРТИЦИИ НА ОДНОМ, СООТВЕТСТВЕННО СКОРОСТЬ БУДЕТ БЫСТРЕЕ ПРИ ШАРДЕ. ПРИ ШАРДИРОВАНИИ ВОЗНИКАЕТ ПРОБЛЕМА СОЕДИНЕНИЯ ТАБЛИЦ, ПРИ ПАРТИЦИОНИРОВАНИИ ТАКОГО НЕТ.
|
||
|
||
- придумать пример, когда **достаточно** партиционирования и шардирование не нужно;
|
||
НЕБОЛЬШАЯ ТАБЛИЦА В СОТНИ ТЫСЯЧ СТРОК НЕ ТРЕБУЕТ ШАРДИРОВАНИЯ.
|
||
|
||
- придумать пример, когда без шардирования уже не обойтись, даже если партиции есть.
|
||
КОЛИЧЕСТВО СТРОК СЛИШКОМ БОЛЬШОЕ, СКОРОСТЬ УПАЛА, ПОЭТОМУ ЛУЧШЕ РАСКИДАТЬ НА РАЗНЫЕ СЕРВЕРА ДАННЫЕ. |