|
запрос в Vetica
|
|||
---|---|---|---|
#18+
Всем привет. Подскажите, есть запрос типа Код: sql 1. 2. 3. 4. 5. 6.
Вертика берет только одну проекцию для таблицы "T", а соединение идет по разным полям. Если кто-то сталкивался с подобной проблемой, подскажите каким образом можно оптимизировать запрос, не разбивая его на части? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2015, 11:54 |
|
запрос в Vetica
|
|||
---|---|---|---|
#18+
pasha1018Всем привет. Подскажите, есть запрос типа Код: sql 1. 2. 3. 4. 5. 6.
Вертика берет только одну проекцию для таблицы "T", а соединение идет по разным полям. Если кто-то сталкивался с подобной проблемой, подскажите каким образом можно оптимизировать запрос, не разбивая его на части? тоже интересно почему так ведет себя Vertica ? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2015, 17:46 |
|
запрос в Vetica
|
|||
---|---|---|---|
#18+
pasha1018Всем привет. Подскажите, есть запрос типа Код: sql 1. 2. 3. 4. 5. 6.
Вертика берет только одну проекцию для таблицы "T", а соединение идет по разным полям. Если кто-то сталкивался с подобной проблемой, подскажите каким образом можно оптимизировать запрос, не разбивая его на части? Вертика аналитическая СУБД. Подразумевается, что в основном идут групповые запросы к звезде, где T это факт, а T1..3 это измерения. В таком случае, на T вообще не нужна сортировка по полю COL, проекцию с сортировкой нужно сделать на поля фильтрации (WHERE), группировки (GROUP BY) и можно сортировки (ORDER BY), если вписывается. Так как Вертика колоночная СУБД, то по фильтру с учетом сортировки будут быстро найдены нужные для обработки записи. Ну а для ускорения джойнов вы на сами измерения делаете проекции с сортировкой по их ключу соединения, хотя если записей не так много, то это и не обязательно. Если же ситуация, когда у вас эти таблицы являются основным фильтром и эффективного WHERE нет, то значит нужно выбрать измерение с наиболее ограничивающим таблицу фактов набором данных и сделать на нее и факты проекции с сортировкой по полям соединения, чтобы избавиться от HASH JOIN и выйти на не затратный MERGE JOIN. Ну и стоит помнить, что оптимизация запроса это не только сортировка и сегментация, но и ENCODING. Грамотно расставленный энкодинг на поля проекции позволяет на больших наборах данных существенно уменьшить размер хранимых данных и ускорить их обработку. В общем то как раз сортировка в проекциях и предназначена не для того, чтобы ускорить выборку, а чтобы правильно отсортировать для хранения данные и позволить наиболее эффективно использовать ENDODING. Если например у вас 100 миллиардов записей на 10 нодах (на ноде по 10 миллиардов), а числовая колонка имеет 1 значение на 1 миллион записей, то сортировка по этой колонке и RLE кодировка приведет к тому, что на одной ноде по этой колонке будет в среднем хранится 10 тыс записей (10 миллиардов разделить на 1 миллион). Уже по такой колонке поиск и группировка пройдут просто моментально. Если же на колонке оставить ENCODING по умолчанию (DELTAVAL), то хранится будет 10 миллиардов смещений, фактически все равно записей, а значит поиск по такой колонке даже с сортировкой будет уже ресурсоемкой операцией. Разница как говорится на лицо. Станислав Клевцовтоже интересно почему так ведет себя Vertica ? Как архитектурно заложено, так себя и ведет :) Параллелить использование в одном запросе несколько проекций на одну таблицу это значит потом нужно будет записи этих проекций соединять вместе, с учетом того, что в них может идти запись, часть данных еще висеть в WOS, проекции иметь разную сегментацию и требовать при сливании еще и операции сетевого перемещения, это может оказаться на больших данных на порядок дольше, чем просто все сделать на одной проекции ;) ... |
|||
:
Нравится:
Не нравится:
|
|||
20.03.2015, 12:34 |
|
|
start [/forum/topic.php?fid=48&msg=38911267&tid=1856847]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
29ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
54ms |
get tp. blocked users: |
2ms |
others: | 238ms |
total: | 368ms |
0 / 0 |