From 9c84f7b794b229bf70a46c9f7fcfd9a5b7422bbd Mon Sep 17 00:00:00 2001 From: Dmitry Medvedev Date: Fri, 10 Jul 2026 00:26:24 +0500 Subject: [PATCH] added file with theory BD 'shard' --- dmedvedev/2.3.theory_bd_shard.sql | 42 +++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) create mode 100644 dmedvedev/2.3.theory_bd_shard.sql diff --git a/dmedvedev/2.3.theory_bd_shard.sql b/dmedvedev/2.3.theory_bd_shard.sql new file mode 100644 index 0000000..321c436 --- /dev/null +++ b/dmedvedev/2.3.theory_bd_shard.sql @@ -0,0 +1,42 @@ +- Задание 1. Выбор ключа шардирования + + У тебя есть сервис онлайн‑магазина с таблицами: + + - `users` + - `orders` + + Нужно: + + - Выбрать, по какому полю ты будешь **шардировать пользователей** и объяснить, почему именно этот ключ, а не другие + Я БЫ ХОТЕЛ ШАРДИРОВАТЬ ПОЛЬЗОВАТЕЛЕЙ ПО АЙДИШНИКАМ, ИМЕННО АЙДИШНИК ЭТО ЧИСЛО, ПОЭТОМУ МОЖНО ШАРДИРОВАТЬ ПО ХЭШУ, ПЛЮС КО ВСЕМУ АЙДИ НЕ ПОВТОРЯЕТСЯ. + + - Описать, как при выбранном ключе будут распределяться пользователи по шардам и какие типы запросов станут выполняться быстрее, а какие, наоборот, станут сложнее. + ЕСЛИ ШАРДОВ 4, ТО ПЕРВЫЙ ПОЛЬЗОВАТЕЛЕЙ В 1ЫЙ, ВТОРОЙ ВО 2ОЙ, ТРЕТИЙ В 3ИЙ, ЧЕТВЕРТЫЙ В 0, ПЯТЫЙ В 1ЫЙ, ШЕСТОЙ ВО 2ОЙ, СЕДБМОЙ В 3ИЙ, ВОСБМОЙ В 0. + + Задание 2. Добавление нового шарда + + Ты шардируешь пользователей по правилу `user_id % 4` (4 шарда). Через пару лет один шард сильно перегружен, и ты хочешь перейти на `user_id % 8` (8 шардов). + + Нужно: + + - Описать, какие проблемы возникают при смене количества шардов (что происходит с существующими пользователями и их данными); + КАК МНЕ КАЖЕТСЯ НЕОБХОДИМО БУДЕТ ЗАНОВО ВЗЯТЬ СПИСОК ВСЕХ ПОЛЬЗОВАТЕЛЕЙ (КОТОРЫЕ УЖЕ В ШАРДАХ) И РАСКИДАТЬ ПО НОВЫМ РАЗНЫМ ШАРДАМ. + + - Предложить общий план «перешардирования» (как переносить данные, как не потерять консистентность, что делать с новыми запросами в момент миграции). + ПОЛУЧИТЬ ДАННЫЕ ИЗ СТАРЫХ ШАРДОВ, НЕ УДАЛЯЯ НИ ДАННЫЕ, НИ ШАРДЫ, РАСКИДАТЬ ДАННЫЕ ПО НОВЫМ ШАРДАМ (СЕРВЕРАМ) И УДАЛИТЬ СТАРЫЕ ШАРДЫ; + ПО ИДЕЕ ЗАПРОСЫ ВО ВРЕМЯ МИГРАЦИИ ТАК И БУДУТ ОБРАЩАТЬСЯ К СТАРЫМ ШАРДАМ, ВПЛОТЬ ДО МОМЕНТА, ПОКА ОНИ НЕ БУДУТ УДАЛЕНЫ. + +- Задание 3. Шардинг против партиционирования + + Есть одна большая база PostgreSQL с таблицей `orders`, и она начала тормозить. Команда обсуждает два варианта: сделать партиционирование в рамках одной базы или шардирование по нескольким базам/серверям. + + Нужно: + + - описать, чем принципиально отличается партиционирование от шардирования (где данные находятся и кто ими управляет); + ШАРДЫ НАХОДЯИСЯ НА РАЗНЫХ СЕРВЕРАХ, А ПАРТИЦИИ НА ОДНОМ, СООТВЕТСТВЕННО СКОРОСТЬ БУДЕТ БЫСТРЕЕ ПРИ ШАРДЕ. ПРИ ШАРДИРОВАНИИ ВОЗНИКАЕТ ПРОБЛЕМА СОЕДИНЕНИЯ ТАБЛИЦ, ПРИ ПАРТИЦИОНИРОВАНИИ ТАКОГО НЕТ. + + - придумать пример, когда **достаточно** партиционирования и шардирование не нужно; + НЕБОЛЬШАЯ ТАБЛИЦА В СОТНИ ТЫСЯЧ СТРОК НЕ ТРЕБУЕТ ШАРДИРОВАНИЯ. + + - придумать пример, когда без шардирования уже не обойтись, даже если партиции есть. + КОЛИЧЕСТВО СТРОК СЛИШКОМ БОЛЬШОЕ, СКОРОСТЬ УПАЛА, ПОЭТОМУ ЛУЧШЕ РАСКИДАТЬ НА РАЗНЫЕ СЕРВЕРА ДАННЫЕ. \ No newline at end of file