ReSQL.ru
     
powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / оптимизировать время выполнения запроса.
38 сообщений из 38, показаны все 2 страниц
  все  
оптимизировать время выполнения запроса.
    #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:29
| Ответить | Цитировать | Написать  
оптимизировать время выполнения запроса.
    #39957836
Фотография a_voronin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_voronin
Участник
kvitnitskiy,

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

Увы, я новичек в этом.
...
Рейтинг: 0 / 0
15.05.2020, 08:32
| Ответить | Цитировать | Написать  
оптимизировать время выполнения запроса.
    #39957851
kvitnitskiy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kvitnitskiy
Гость
нету прав на создание
...
Рейтинг: 0 / 0
15.05.2020, 09:08
| Ответить | Цитировать | Написать  
оптимизировать время выполнения запроса.
    #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:40
| Ответить | Цитировать | Написать  
оптимизировать время выполнения запроса.
    #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:47
| Ответить | Цитировать | Написать  
оптимизировать время выполнения запроса.
    #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, 09:59
| Ответить | Цитировать | Написать  
оптимизировать время выполнения запроса.
    #39957872
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
kvitnitskiy
нету прав на создание
Кстати, индексы можно создавать и в самом SAP
авторС помощью транзакции SE11 заходим в режим редактирования таблицы и нажимаем кнопку изменить. Затем Goto-->IndexesТам же можно посмотреть, какие индексы есть у этой таблицы.
...
Рейтинг: 0 / 0
15.05.2020, 10:07
| Ответить | Цитировать | Написать  
оптимизировать время выполнения запроса.
    #39957887
Фотография a_voronin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_voronin
Участник
alexeyvg
a_voronin
пропущено...

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

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


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

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


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

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

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


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

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


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


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


+1,

a_voronin,

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


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


+1,

a_voronin,

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


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

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

Альтернатива трансформируйте в схему Звезда, заменяя строковые ID на суррогатные INT.
...
Рейтинг: 0 / 0
15.05.2020, 17:09
| Ответить | Цитировать | Написать  
оптимизировать время выполнения запроса.
    #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:20
| Ответить | Цитировать | Написать  
оптимизировать время выполнения запроса.
    #39958125
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владислав Колосов
Участник
колумнстор в принципе для статичных, редко пополняемых и еще реже изменяемых данных.
Автору нужен простой индекс.
...
Рейтинг: 0 / 0
15.05.2020, 17:41
| Ответить | Цитировать | Написать  
оптимизировать время выполнения запроса.
    #39958139
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
msLex
Участник
Владислав Колосов
колумнстор в принципе для статичных, редко пополняемых и еще реже изменяемых данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

Основные проблемы колумнстора -- нетипичные для него выборки (к примеру, точечные) и модификации. В остальном все классно. Экономия места на сдачу.
...
Рейтинг: 0 / 0
15.05.2020, 23:06
| Ответить | Цитировать | Написать  
оптимизировать время выполнения запроса.
    #39958317
kvitnitskiy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kvitnitskiy
Гость
alexeyvg
kvitnitskiy
alexeyvg,


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

Просто если действительно ничего нельзя, то вопрос теряет смысл. Чёрный ящик опечатан, как работает, так и работает, пишите письма в САП.


ПОлучается что да, запрещено.
...
Рейтинг: 0 / 0
16.05.2020, 12:47
| Ответить | Цитировать | Написать  
оптимизировать время выполнения запроса.
    #39958760
Фотография a_voronin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_voronin
Участник
[quot alexeyvg#22133928]
a_voronin


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

a_voronin
Альтернатива трансформируйте в схему Звезда, заменяя строковые ID на суррогатные INT.
Что трансформировать, базу SAP? :-)


Что касается первого вопроса, мы тут мерились скоростями, частично это отвечает на ваш вопрос.
https://www.sql.ru/forum/1324174/olap-ssas-dwh-clickhouse

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

Что касается трансформирования, то тут можно углубиться в целую тему про схемы звезда и суррогатные ключи и медленно меняющие измерения SCD. этому посвящена целая книга.

https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/books/microsoft-data-warehouse-dw-toolkit/
...
Рейтинг: 0 / 0
18.05.2020, 08:01
| Ответить | Цитировать | Написать  
оптимизировать время выполнения запроса.
    #39958787
Фотография a_voronin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_voronin
Участник
msLex

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

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



Почему нельзя исключить полный скан? Можно. Партиционированный колумнстор.
...
Рейтинг: 0 / 0
18.05.2020, 09:47
| Ответить | Цитировать | Написать  
оптимизировать время выполнения запроса.
    #39958789
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
msLex
Участник
a_voronin
msLex

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

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



Почему нельзя исключить полный скан? Можно. Партиционированный колумнстор.


Партиционированный по какому полю? Напомню, что даты в фильтре запроса нет.
...
Рейтинг: 0 / 0
18.05.2020, 09:49
| Ответить | Цитировать | Написать  
оптимизировать время выполнения запроса.
    #39958831
Фотография a_voronin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_voronin
Участник
msLex
a_voronin
пропущено...


Почему нельзя исключить полный скан? Можно. Партиционированный колумнстор.


Партиционированный по какому полю? Напомню, что даты в фильтре запроса нет.


А что дата -- это единственный способ партиционирования? Там есть код документа.
...
Рейтинг: 0 / 0
18.05.2020, 11:35
| Ответить | Цитировать | Написать  
оптимизировать время выполнения запроса.
    #39958839
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
msLex
Участник
a_voronin
msLex
пропущено...


Партиционированный по какому полю? Напомню, что даты в фильтре запроса нет.


А что дата -- это единственный способ партиционирования? Там есть код документа.

ну так, ваши предложения? какое поле, какие диапазоны для секций?

вы, кстати, проигнорировали про update-ы, наличие которых, с ваших слов, жирный плюс для CS.
...
Рейтинг: 0 / 0
18.05.2020, 11:44
| Ответить | Цитировать | Написать  
оптимизировать время выполнения запроса.
    #39958889
Фотография a_voronin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_voronin
Участник
msLex
a_voronin
пропущено...


А что дата -- это единственный способ партиционирования? Там есть код документа.

ну так, ваши предложения? какое поле, какие диапазоны для секций?

вы, кстати, проигнорировали про update-ы, наличие которых, с ваших слов, жирный плюс для CS.


Жирный плюс для колумнстрора -- это меньше места на диске. "update-ы, наличие которых, с ваших слов, жирный плюс для CS." такого я не говорил. Я говорил, что update жирный минус на таблице с кучей индексов. Но на партиционированном колумнсторе, если попадать update-ом внутрь 1-3 партиций, и затрагивать не все поля, могут быть быстрее. depends ...
...
Рейтинг: 0 / 0
18.05.2020, 13:25
| Ответить | Цитировать | Написать  
оптимизировать время выполнения запроса.
    #39958892
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
msLex
Участник
a_voronin
Жирный плюс для колумнстрора -- это меньше места на диске.

Да, только ТС спрашивал про ускорить запрос, а не сократить место занимаемое на диске.


a_voronin
"update-ы, наличие которых, с ваших слов, жирный плюс для CS." такого я не говорил.


вы хоть следите, за тем, что пишите
a_voronin
Медленный insert и update. А Columnstor тут прописан.
...
Рейтинг: 0 / 0
18.05.2020, 13:31
| Ответить | Цитировать | Написать  
оптимизировать время выполнения запроса.
    #39958916
Фотография a_voronin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_voronin
Участник
msLex

вы хоть следите, за тем, что пишите
a_voronin
Медленный insert и update. А Columnstor тут прописан.


Да слежу, это вы вырывает фразы из контекста. предыдущее предложение перед этим ещё есть.

msLex

Да, только ТС спрашивал про ускорить запрос, а не сократить место занимаемое на диске.


А вы не видите связь между занимаемым на диске местом и скоростью запросов.
...
Рейтинг: 0 / 0
18.05.2020, 13:56
| Ответить | Цитировать | Написать  
оптимизировать время выполнения запроса.
    #39958938
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
a_voronin
То, что вы говоря о колумсторе, говорите о "записях", указывает мне на то, что тему колумнстора надо бы вам немного покопать. Ибо колумстор это не записи. И выбор целой строки из колумнстора не оптимален.
Вопрос автора - не считать агрегаты, не делать выгрузки, и т.д., а выбрать несколько строк из 4 полей по условию:
Код: sql
1.
2.
3.
4.
where 
lips.matnr = '000000000080248026'
AND lips.charg = '9173786000'
and lips.lgort <>'';

По моему, это ваш вывод, что для оптимизации конкретно этой выборки десятка строк (из миллиарда) по такому условию нужно сделать колумнстор индекс, показывает, что тему колумнстора надо бы вам немного покопать :-)
...
Рейтинг: 0 / 0
18.05.2020, 14:21
| Ответить | Цитировать | Написать  
оптимизировать время выполнения запроса.
    #39958942
Фотография a_voronin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_voronin
Участник
alexeyvg
a_voronin
То, что вы говоря о колумсторе, говорите о "записях", указывает мне на то, что тему колумнстора надо бы вам немного покопать. Ибо колумстор это не записи. И выбор целой строки из колумнстора не оптимален.
Вопрос автора - не считать агрегаты, не делать выгрузки, и т.д., а выбрать несколько строк из 4 полей по условию:
Код: sql
1.
2.
3.
4.
where 
lips.matnr = '000000000080248026'
AND lips.charg = '9173786000'
and lips.lgort <>'';

По моему, это ваш вывод, что для оптимизации конкретно этой выборки десятка строк (из миллиарда) по такому условию нужно сделать колумнстор индекс, показывает, что тему колумнстора надо бы вам немного покопать :-)


А вы считаете, что колумстор оптимизирует только аггрегаты? И выбираются тут не вся строка, а лишь несколько полей. Я то колумсторы копаю уже давно.
...
Рейтинг: 0 / 0
18.05.2020, 14:28
| Ответить | Цитировать | Написать  
оптимизировать время выполнения запроса.
    #39958945
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
msLex
Участник
a_voronin
Да слежу, это вы вырывает фразы из контекста. предыдущее предложение перед этим ещё есть.

Я привел практически полную вашу цитату, приведите полную и осмыслите ее.

a_voronin
А вы не видите связь между занимаемым на диске местом и скоростью запросов.


Скорость запроса (если мы говорим про IO составляющую) определятся количеством операций ввода вывода и скоростью этих операций.

То, что обычный индекс будет весить в 5 (пусть даже в 10 ) раз больше чем CS совсем не значит, что весь его нужно будет считать с диска. Обычные (BTree) индексы как раз и нужны, что бы получать нужные данные считав его малую часть.
...
Рейтинг: 0 / 0
18.05.2020, 14:31
| Ответить | Цитировать | Написать  
оптимизировать время выполнения запроса.
    #39958965
Фотография a_voronin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_voronin
Участник
msLex
a_voronin
Да слежу, это вы вырывает фразы из контекста. предыдущее предложение перед этим ещё есть.

Я привел практически полную вашу цитату, приведите полную и осмыслите ее.

a_voronin
А вы не видите связь между занимаемым на диске местом и скоростью запросов.


Скорость запроса (если мы говорим про IO составляющую) определятся количеством операций ввода вывода и скоростью этих операций.

То, что обычный индекс будет весить в 5 (пусть даже в 10 ) раз больше чем CS совсем не значит, что весь его нужно будет считать с диска. Обычные (BTree) индексы как раз и нужны, что бы получать нужные данные считав его малую часть.


Цитата была такой.
"потому что потом таблица будет обвешана десятком индексов под каждый запрос и будет много места жрать. Медленный insert и update."

заявление про insert и update касалось обычной таблицы ("таблица будет обвешана десятком индексов"), а не колумстора .

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


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