powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / оптимизировать время выполнения запроса.
13 сообщений из 38, страница 2 из 2
оптимизировать время выполнения запроса.
    #39958317
kvitnitskiy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
alexeyvg
kvitnitskiy
alexeyvg,


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

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


ПОлучается что да, запрещено.
...
Рейтинг: 0 / 0
оптимизировать время выполнения запроса.
    #39958760
Фотография 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
оптимизировать время выполнения запроса.
    #39958787
Фотография a_voronin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
msLex

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

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



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

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

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



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


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


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


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


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


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


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

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

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


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

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

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


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

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


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


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

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


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

msLex

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


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

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

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


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

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

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


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

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

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

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


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

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


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

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

Впрочем давайте заканчивать это дискуссию.
...
Рейтинг: 0 / 0
13 сообщений из 38, страница 2 из 2
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / оптимизировать время выполнения запроса.
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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