Dmitry Medvedev
95 lines
3.0 KiB
SQL
95 lines
3.0 KiB
SQL
## Задача 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)). |