53 lines
1.6 KiB
SQL
53 lines
1.6 KiB
SQL
## Задача 1:
|
||
|
||
EXPLAIN ANALYZE
|
||
SELECT user_id, COUNT(*)
|
||
FROM orders
|
||
GROUP BY user_id;
|
||
|
||
📌 `orders` распределена по `order_id`.
|
||
|
||
Что происходит:
|
||
|
||
```
|
||
Segment:
|
||
Seq Scan on orders
|
||
▼
|
||
Redistribute Motion (по user_id)
|
||
▼
|
||
HashAggregate (GROUP BY user_id)
|
||
```
|
||
|
||
💣 **Проблема:** Motion перед агрегированием — значит данные идут по сети между сегментами.
|
||
|
||
### Задание:
|
||
|
||
1. Что будет, если `orders DISTRIBUTED BY user_id`?
|
||
В таком случае таблица orders будет распределена по user_id между сегментами, соответственно счет будет внутри сегментов и не будет motion между сегментами.
|
||
2. Как меняется `EXPLAIN ANALYZE`
|
||
Не будет Redistribute Motion (по user_id)
|
||
|
||
## Задача 2:
|
||
|
||
SELECT user_id, COUNT(*)
|
||
FROM orders
|
||
GROUP BY user_id;
|
||
|
||
📌 `orders` содержит 10 млн заказов, и 90% из них у `user_id = 1`.
|
||
|
||
Что происходит:
|
||
|
||
```
|
||
Segment 1: user_id = 1 → 9 млн строк
|
||
Segment 2: остальные user_id → 1 млн строк
|
||
Segment 3–N: почти пусто
|
||
|
||
❗ Segment 1 перегружен → весь запрос тормозит
|
||
```
|
||
|
||
### Задание:
|
||
|
||
1. Как это называется?
|
||
Это называется "перекос"
|
||
2. Как избежать?
|
||
Сделать составной ключ по двум аргументам, либо разбить сегменты рандомно. |