mnoskov
17 lines
2.3 KiB
Plaintext
17 lines
2.3 KiB
Plaintext
Задание 1:
|
||
- Будут собираться все 10млн строк с разных сегментов, а тольок потом сработает LIMIT. Это очень дорого стоит, и медленно тк очень много данных в пустую соединятся в мастер.
|
||
- Я думаю можно к текущему запросу добавить DENSE_RANK по total и написать условие where -тут имя dense_rank- <= 10.
|
||
!!! В теории не сказано про работу order by - пришлось загуглить !!!
|
||
|
||
Задание 2:
|
||
- PARTITION BY по. region_id, а должен быть по order_id, чтобы работало без задержек, а при текущем варианте запроса будет происходить data motion как я понял, а это лишние вычисления.
|
||
- Тогда надо распределять таблицу по region_id полагаю.
|
||
|
||
Задание 3:
|
||
- Ответ до подсказки: думаю все будет нормально, данные просто сгруппируются и вставятся, никаких зарежек быть не должно.
|
||
- Ответ после подсказки: greenplum будет пересылать(data motion) user_id между сегментами, чтобы собрать их в группы, а только потом собирать в мастер и инсертить, инсерт уже поидее будет происходить хорошо, тк данные после data motion будут лежать нормально.
|
||
- Orders надо дестрибьютить по user_id, тогда все четко и быстро будет - и group by, и join.
|
||
|
||
Задание 4:
|
||
- Я хочу увидеть Motion, Broadcast, Gather
|
||
- Что означает Broadcast Motion, Redistribute Motion, Gather Motion? - в душе ни чаю, там вопрос с ответом сразу, взял оттуда: Broadcast Motion - разослать копии каждой строки на все сегменты; Redistribute Motion - перераспределить по новому ключу; Gather Motion - собрать на мастер. |