powered by simpleCommunicator - 2.0.48     © 2025 Programmizd 02
Форумы / NoSQL, Big Data [игнор отключен] [закрыт для гостей] / запрос в Vetica
4 сообщений из 4, страница 1 из 1
запрос в Vetica
    #38909603
pasha1018
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Всем привет. Подскажите, есть запрос типа
Код: sql
1.
2.
3.
4.
5.
6.
select 'поля...'
from T 
left join T1 on T.COL1=T1.COL1
left join T2 on T.COL2=T2.COL2
left join T3 on T.COL3=T3.COL3
.....и так далее


Вертика берет только одну проекцию для таблицы "T", а соединение идет по разным полям.
Если кто-то сталкивался с подобной проблемой, подскажите каким образом можно оптимизировать запрос, не разбивая его на части?
...
Рейтинг: 0 / 0
запрос в Vetica
    #38910311
Фотография Станислав Клевцов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pasha1018Всем привет. Подскажите, есть запрос типа
Код: sql
1.
2.
3.
4.
5.
6.
select 'поля...'
from T 
left join T1 on T.COL1=T1.COL1
left join T2 on T.COL2=T2.COL2
left join T3 on T.COL3=T3.COL3
.....и так далее


Вертика берет только одну проекцию для таблицы "T", а соединение идет по разным полям.
Если кто-то сталкивался с подобной проблемой, подскажите каким образом можно оптимизировать запрос, не разбивая его на части?

тоже интересно почему так ведет себя Vertica ?
...
Рейтинг: 0 / 0
запрос в Vetica
    #38910991
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pasha1018Всем привет. Подскажите, есть запрос типа
Код: sql
1.
2.
3.
4.
5.
6.
select 'поля...'
from T 
left join T1 on T.COL1=T1.COL1
left join T2 on T.COL2=T2.COL2
left join T3 on T.COL3=T3.COL3
.....и так далее


Вертика берет только одну проекцию для таблицы "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, проекции иметь разную сегментацию и требовать при сливании еще и операции сетевого перемещения, это может оказаться на больших данных на порядок дольше, чем просто все сделать на одной проекции ;)
...
Рейтинг: 0 / 0
запрос в Vetica
    #38911267
pasha1018
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ASCRUS,
Спасибо, очень доступно объяснили.
...
Рейтинг: 0 / 0
4 сообщений из 4, страница 1 из 1
Форумы / NoSQL, Big Data [игнор отключен] [закрыт для гостей] / запрос в Vetica
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]