added file with theory BD 'shard'

2026-07-10 00:26:24 +05:00
parent f1e9502716
commit 9c84f7b794
1 changed files with 42 additions and 0 deletions
@@ -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`, и она начала тормозить. Команда обсуждает два варианта: сделать партиционирование в рамках одной базы или шардирование по нескольким базам/серверям.
+    
+    Нужно:
+    
+    - описать, чем принципиально отличается партиционирование от шардирования (где данные находятся и кто ими управляет);
+            ШАРДЫ НАХОДЯИСЯ НА РАЗНЫХ СЕРВЕРАХ, А ПАРТИЦИИ НА ОДНОМ, СООТВЕТСТВЕННО СКОРОСТЬ БУДЕТ БЫСТРЕЕ ПРИ ШАРДЕ. ПРИ ШАРДИРОВАНИИ ВОЗНИКАЕТ ПРОБЛЕМА СОЕДИНЕНИЯ ТАБЛИЦ, ПРИ ПАРТИЦИОНИРОВАНИИ ТАКОГО НЕТ.
+    
+    - придумать пример, когда **достаточно** партиционирования и шардирование не нужно;
+            НЕБОЛЬШАЯ ТАБЛИЦА В СОТНИ ТЫСЯЧ СТРОК НЕ ТРЕБУЕТ ШАРДИРОВАНИЯ.
+
+    - придумать пример, когда без шардирования уже не обойтись, даже если партиции есть.
+            КОЛИЧЕСТВО СТРОК СЛИШКОМ БОЛЬШОЕ, СКОРОСТЬ УПАЛА, ПОЭТОМУ ЛУЧШЕ РАСКИДАТЬ НА РАЗНЫЕ СЕРВЕРА ДАННЫЕ.