added tasks greenplum distributed by

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)).