diff --git a/dmedvedev/4.2.greenplum_distr_by.sql b/dmedvedev/4.2.greenplum_distr_by.sql new file mode 100644 index 0000000..24909f2 --- /dev/null +++ b/dmedvedev/4.2.greenplum_distr_by.sql @@ -0,0 +1,95 @@ +## Задача 1. + +CREATE TABLE users ( + user_id INT, + name TEXT +) DISTRIBUTED BY (user_id); + +CREATE TABLE orders ( + order_id INT, + user_id INT, + amount NUMERIC +) DISTRIBUTED BY (order_id); + +**Запрос:** + +SELECT u.name, o.amount +FROM users u +JOIN orders o ON u.user_id = o.user_id; + +📌 Вопрос: будет ли `JOIN` локальным? + +📌 Что делает Greenplum? + +- Подсказка в виде визуализации: + + ``` + Segment 1: Segment 2: Segment 3: + users(user_id=1) users(user_id=2) users(user_id=3) + orders(order_id=100, user_id=2) + orders(order_id=200, user_id=1) + + JOIN требует: + users.user_id = orders.user_id + НО orders распределена по order_id + + ❌ → Redistribute Motion: перегон строк между сегментами + ``` + + +**Задание:** + +Перераспредели `orders` по `user_id`, чтобы JOIN стал локальным. + ALTER TABLE orders SET DISTRIBUTED BY (user_id); + +## Задача 2. + +CREATE TABLE logs ( + id SERIAL, + user_agent TEXT, + ts TIMESTAMP +) DISTRIBUTED RANDOMLY; + +📌 Логи не участвуют в `JOIN` — можно распределять случайно. + +- Визуализация: + + ``` + Segment 1: 1/3 строк + Segment 2: 1/3 строк + Segment 3: 1/3 строк + + ✅ Отлично сбалансировано, нет связи с другими таблицами + ``` + + +**Задание:** + +Почему `DISTRIBUTED BY` не подходит для этой таблицы? + ПОТОМУ ЧТО ЛОГИ НЕ УЧАСТВУЮТ В ПОСЛЕДУЮЩИХ ДЖОЙНАХ, СООТВЕТСТВЕННО motion МЕЖДУ СЕГМЕНТАМИ НЕ БУДЕТ. + +## Задача 3. + +CREATE TABLE events ( + event_type TEXT, + ts TIMESTAMP +) DISTRIBUTED BY (event_type); + +📌 Но `event_type = 'click'` — 95% строк + +- Подсказка в виде визуализации: + + ``` + Segment 1 (click) → 95% данных + Segment 2 (view) → 3% + Segment 3 (hover) → 2% + + ❌ Segment 1 перегружен, тормозит всё + ``` + + +**Задание:** + +Как это исправить? Приведи пример хорошего ключа. + В ДАННОМ СЛУЧАЕ БУДЕТ ПЕРЕГРУЗ ПЕРВОГО СЕГМЕНТА, ОСТАЛЬНЫЕ СЕРВЕРА БУДУТ ПРОСТАИВАТЬ В ОЖИДАНИИ - ПРОБЛЕМА ОПТИМИЗАЦИИ. + РЕШЕНИЕМ БУДЕТ ЯВЛЯТЬСЯ ЛИБО РАНДОМИЗИРОВАНИЕ ПО СЕГМЕНТАМ - КАК МНЕ КАЖЕТСЯ ЭТО РЕШЕНИЕ, НО НЕ САМОЕ ЛУЧШЕЕ (ALTER TABLE events SET DISTRIBUTED RANDOMLY), А ТАКЖЕ ДВОЙНОЙ СОСТАВНОЙ КЛЮЧ ПО ИВЕНТАМ И ВРЕМЕНИ (ALTER TABLE events SET DISTRIBUTED BY (event_type, ts)). \ No newline at end of file