Гость
Войти | Профиль | Очистить
Действия ...
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / оптимизировать время выполнения запроса. / 25 сообщений из 38, страница 1 из 2
  1  все
15.05.2020, 08:29
    #39957835
kvitnitskiy
kvitnitskiy
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать время выполнения запроса.
Добрый день уважаемые форумчане.
есть таблица (под миллиард записей), делаю простой запрос, возвращает от 1 до 200 строк( в зависимости от параметров), время выполнени может варьироваться вплоть до несколко минут.
Подскажите пожалуйста, можно ли как то это оптимизировать?

Server 2016.

Код: sql
1.
2.
3.
4.
5.
6.
 select   lips.VBELN, lips.ERDAT, lips.WERKS, lips. LGORT
from LIB_F6P_RTP.[sap].[LIPS] lips
where 
lips.matnr = '000000000080248026'
AND lips.charg = '9173786000'
and lips.lgort <>'';
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.05.2020, 08:30
    #39957836
a_voronin
a_voronin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать время выполнения запроса.
kvitnitskiy,

перевести таблицу в columnstore
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.05.2020, 08:32
    #39957837
kvitnitskiy
kvitnitskiy
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать время выполнения запроса.
a_voronin,

Увы, я новичек в этом.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.05.2020, 09:08
    #39957851
kvitnitskiy
kvitnitskiy
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать время выполнения запроса.
нету прав на создание
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.05.2020, 09:40
    #39957859
alexeyvg
alexeyvg
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать время выполнения запроса.
kvitnitskiy
есть таблица (под миллиард записей), делаю простой запрос, возвращает от 1 до 200 строк( в зависимости от параметров), время выполнени может варьироваться вплоть до несколко минут.
Подскажите пожалуйста, можно ли как то это оптимизировать?
Очевидно, построить индекс:
Код: sql
1.
CREATE INDEX IX_LIPS_ ON LIB_F6P_RTP.[sap].[LIPS](MATRN, CHARG) INCLUDE(LGORT)


или даже лучше:
Код: sql
1.
CREATE INDEX IX_LIPS_ ON LIB_F6P_RTP.[sap].[LIPS](MATRN, CHARG) INCLUDE(LGORT, VBELN, ERDAT, WERKS)



kvitnitskiy
нету прав на создание
А если нет прав, то ничего нельзя сделать.
Это же очевидно: ничего нельзя сделать, раз запрещено что то делать.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.05.2020, 09:47
    #39957863
a_voronin
a_voronin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать время выполнения запроса.
alexeyvg
Очевидно, построить индекс:
Код: sql
1.
CREATE INDEX IX_LIPS_ ON LIB_F6P_RTP.[sap].[LIPS](MATRN, CHARG) INCLUDE(LGORT)




Вот мне не очевидно, потому что потом таблица будет обвешана десятком индексов под каждый запрос и будет много места жрать. Медленный insert и update. А Columnstor тут прописан.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.05.2020, 09:59
    #39957868
alexeyvg
alexeyvg
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать время выполнения запроса.
a_voronin
alexeyvg
Очевидно, построить индекс:
Код: sql
1.
CREATE INDEX IX_LIPS_ ON LIB_F6P_RTP.[sap].[LIPS](MATRN, CHARG) INCLUDE(LGORT)



Вот мне не очевидно, потому что потом таблица будет обвешана десятком индексов под каждый запрос и будет много места жрать. Медленный insert и update. А Columnstor тут прописан.
Ну, индексы нужно создавать с умом, конечно. Смотреть типичные запросы, собирать статистику по распределению условий в запросах.

А вот насчёт Columnstor мне совершенно неочевидно. Звучит как призыв создавать Columnstor вместо даже кластерного уникального индекса.
Зачем тут Columnstor, если нужен поиск от одной до сотни записей по условию равенства пары полей? С таким подходом становится непонятно, почему МС не упразднила обычные индексы, ведь есть же Columnstor.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.05.2020, 10:07
    #39957872
alexeyvg
alexeyvg
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать время выполнения запроса.
kvitnitskiy
нету прав на создание
Кстати, индексы можно создавать и в самом SAP
авторС помощью транзакции SE11 заходим в режим редактирования таблицы и нажимаем кнопку изменить. Затем Goto-->IndexesТам же можно посмотреть, какие индексы есть у этой таблицы.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.05.2020, 10:44
    #39957887
a_voronin
a_voronin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать время выполнения запроса.
alexeyvg
a_voronin
пропущено...

Вот мне не очевидно, потому что потом таблица будет обвешана десятком индексов под каждый запрос и будет много места жрать. Медленный insert и update. А Columnstor тут прописан.
Ну, индексы нужно создавать с умом, конечно. Смотреть типичные запросы, собирать статистику по распределению условий в запросах.

А вот насчёт Columnstor мне совершенно неочевидно. Звучит как призыв создавать Columnstor вместо даже кластерного уникального индекса.
Зачем тут Columnstor, если нужен поиск от одной до сотни записей по условию равенства пары полей? С таким подходом становится непонятно, почему МС не упразднила обычные индексы, ведь есть же Columnstor.


Я не призываю отказываться от обычных индексов, но тут выбор нескольких кодов, выбор небольшого объема из большой таблице. Ускорение будет как минимум от того, что занимать будет все меньше места.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.05.2020, 10:46
    #39957890
a_voronin
a_voronin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать время выполнения запроса.
alexeyvg

авторС помощью транзакции SE11 заходим в режим редактирования таблицы и нажимаем кнопку изменить. Затем Goto-->Indexes


И все ложится с концами. Ибо надо смотреть какой скрипт будет.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.05.2020, 11:51
    #39957921
kvitnitskiy
kvitnitskiy
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать время выполнения запроса.
alexeyvg,

Доступа как у эндюзера-нету.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.05.2020, 13:34
    #39957973
aleks222
aleks222
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать время выполнения запроса.
kvitnitskiy
alexeyvg,

Доступа как у эндюзера-нету.


Если ты ничо изменить не можешь => ничего ускорить нельзя.

ЗЫ. Хинт "БЫСТРО" еще в стадии разработки.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.05.2020, 15:15
    #39958030
Критик
Критик
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать время выполнения запроса.
a_voronin
А Columnstor тут прописан.


А обоснуй будет? Ибо мне тоже это утверждение видится весьма сомнительным.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.05.2020, 15:59
    #39958060
felix_ff
felix_ff
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать время выполнения запроса.
Критик
a_voronin
А Columnstor тут прописан.


А обоснуй будет? Ибо мне тоже это утверждение видится весьма сомнительным.


+1,

a_voronin,

там же выборка не диапазона, а можно сказать поиск по ключам.
конечно все зависит от селективности предиката, но если ТС говорит что будет возвращаться по 200 строк, то имхо колумстор тут избыточен
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.05.2020, 16:04
    #39958064
kvitnitskiy
kvitnitskiy
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать время выполнения запроса.
Ок, спасбио всем :)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.05.2020, 17:09
    #39958106
a_voronin
a_voronin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать время выполнения запроса.
felix_ff
Критик
пропущено...


А обоснуй будет? Ибо мне тоже это утверждение видится весьма сомнительным.


+1,

a_voronin,

там же выборка не диапазона, а можно сказать поиск по ключам.
конечно все зависит от селективности предиката, но если ТС говорит что будет возвращаться по 200 строк, то имхо колумстор тут избыточен


Как раз выбирание небольшого числа записей на большой таблице при достаточно гранулярном условии фильтрации хорошо работает на колумнсторе. Таблица меньше занимает места, вы быстро выходить на очень узкий диапазон записей, выбираются только нужные поля, не затрагивая остальные. Это выгрузка из SAP отфильтрованная по номеру документа.

Просто по числу страниц, которые надо прочитать это гораздо меньше.

Альтернатива трансформируйте в схему Звезда, заменяя строковые ID на суррогатные INT.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.05.2020, 17:20
    #39958116
msLex
msLex
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать время выполнения запроса.
a_voronin
felix_ff
пропущено...


+1,

a_voronin,

там же выборка не диапазона, а можно сказать поиск по ключам.
конечно все зависит от селективности предиката, но если ТС говорит что будет возвращаться по 200 строк, то имхо колумстор тут избыточен


Как раз выбирание небольшого числа записей на большой таблице при достаточно гранулярном условии фильтрации хорошо работает на колумнсторе. Таблица меньше занимает места, вы быстро выходить на очень узкий диапазон записей, выбираются только нужные поля, не затрагивая остальные. Это выгрузка из SAP отфильтрованная по номеру документа.

Просто по числу страниц, которые надо прочитать это гораздо меньше.

Альтернатива трансформируйте в схему Звезда, заменяя строковые ID на суррогатные INT.


Вы таблицу видели?
А запрос?

Данные явно добавляются по дате, и в запросе нет фильтра по дате.

Большинство сегментов CS не получится исключить по метаданным, а следовательно будет полный скан всего миллиардного CS, а это гарантированно дольше (много дольше) поиска в 1 index seek (с одним спуском по дереву и последующему range scan) 200-300 записей.


А про вот это

a_voronin
Медленный ... update. А Columnstor тут прописан.


update вообще противопоказан для и CS , т.к. ( в отличии от insert-ов) он навсегда (до ребилда) зависнет в дельтасторе.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.05.2020, 17:41
    #39958125
Владислав Колосов
Владислав Колосов
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать время выполнения запроса.
колумнстор в принципе для статичных, редко пополняемых и еще реже изменяемых данных.
Автору нужен простой индекс.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.05.2020, 18:00
    #39958139
msLex
msLex
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать время выполнения запроса.
Владислав Колосов
колумнстор в принципе для статичных, редко пополняемых и еще реже изменяемых данных.

Нет, он вполне подходит для append only таблиц (даже без секционирования). Всякие DWH, логи, потоки каких-то событий и т.п.

Асинхронный процесс автоматически собирает пачки добавленных записей из дельтасторе и генерит новые сегменты.

Вопрос в последующих выборках

Если это выборки с условием по монотонно растущему значению (обычно, дата событий, документа и т.п.), то метаднные сегментов (min max по каждому полю) позволяют быстро находить нужные сегменты.

Если это агрегаты по большой доли данных и только части полей, то сжатие позволяет читать меньше данных с диска, а колоночное хранение игнорировать данные прочих полей.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.05.2020, 18:10
    #39958142
Владислав Колосов
Владислав Колосов
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать время выполнения запроса.
msLex,

Я не экспериментировал, но у меня есть смутное подозрение, что дельта-механизм будет вызывать периодические подвисания запросов при более-менее интенсивной вставке. Также есть сомнения относительно производительности переноса на реплику высокой доступности, эксплуатационного удобства, изменения схемы данных, к примеру.

Все нововведения имеют довольно значимые недостатки, компилированные процедуры, таблицы в памяти и прочее. Область применения довольно узкая и круг задач соответственный.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.05.2020, 18:14
    #39958147
msLex
msLex
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать время выполнения запроса.
Владислав Колосов
msLex,

Я не экспериментировал, но у меня есть смутное подозрение, что дельта-механизм будет вызывать периодические подвисания запросов при более-менее интенсивной вставке. Также есть сомнения относительно производительности переноса на реплику высокой доступности, эксплуатационного удобства, изменения схемы данных, к примеру.

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

Не переживайте, все это у нас работает и проблем нет.

Размер добавляемых данных (уже в пожатом в CS виде) около 1.5 ТБ в день.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.05.2020, 19:33
    #39958190
alexeyvg
alexeyvg
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать время выполнения запроса.
a_voronin
Как раз выбирание небольшого числа записей на большой таблице при достаточно гранулярном условии фильтрации хорошо работает на колумнсторе. Таблица меньше занимает места, вы быстро выходить на очень узкий диапазон записей, выбираются только нужные поля, не затрагивая остальные. Это выгрузка из SAP отфильтрованная по номеру документа.

Просто по числу страниц, которые надо прочитать это гораздо меньше.
А можно как то расписать, сколько страниц будет читать сервер в обоих случаях?

Для указанного мной индекса это будет всегда одна страница.

А сколько будет для колумнстора? Например, для 50 записей, и для 5 записей, можете назвать число?
Я просто не понимаю, что это за такой волшебный индекс, который читает быстрее чем из дерева по ключу, и ещё и обновляется быстрее.

a_voronin
Альтернатива трансформируйте в схему Звезда, заменяя строковые ID на суррогатные INT.
Что трансформировать, базу SAP? :-)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.05.2020, 20:00
    #39958198
kvitnitskiy
kvitnitskiy
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать время выполнения запроса.
alexeyvg,


Господа, добавлю здесь, что это не конкретно база SAP, это так называемый Simplement, 1 в 1 зеркало SAP на базе MS SQL 2016, куда зеркалятся таблицы.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.05.2020, 22:36
    #39958236
alexeyvg
alexeyvg
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать время выполнения запроса.
kvitnitskiy
alexeyvg,


Господа, добавлю здесь, что это не конкретно база SAP, это так называемый Simplement, 1 в 1 зеркало SAP на базе MS SQL 2016, куда зеркалятся таблицы.
А в этом зеркале тоже запрещено создавать индексы?

Просто если действительно ничего нельзя, то вопрос теряет смысл. Чёрный ящик опечатан, как работает, так и работает, пишите письма в САП.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.05.2020, 23:06
    #39958241
Гавриленко Сергей Алексеевич
Гавриленко Сергей Алексеевич
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать время выполнения запроса.
Владислав КолосовЯ не экспериментировал, но у меня есть смутное подозрение, что дельта-механизм будет вызывать периодические подвисания запросов при более-менее интенсивной вставке. Также есть сомнения относительно производительности переноса на реплику высокой доступности, эксплуатационного удобства, изменения схемы данных, к примеру.
Сжатие дельты -- процесс асинхронный. Поэтому если хватает ресурсов на сжатие, все будет пучком.

Основные проблемы колумнстора -- нетипичные для него выборки (к примеру, точечные) и модификации. В остальном все классно. Экономия места на сдачу.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
  1  все
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / оптимизировать время выполнения запроса. / 25 сообщений из 38, страница 1 из 2
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
созд. / загр.: 156ms
Закрыть
start [/forum/topic.php?fid=46&mobile=1&tid=1686112]:
 0ms
get settings:
 11ms
get forum list:
 11ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 41ms
get topic data:
 11ms
get forum data:
 2ms
get page messages:
 59ms
get tp. blocked users:
 2ms
others: 13ms
total:  156ms
x
x
Закрыть


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