## Задача 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)).