|
оптимизировать время выполнения запроса.
|
|||
---|---|---|---|
#18+
alexeyvg kvitnitskiy alexeyvg, Господа, добавлю здесь, что это не конкретно база SAP, это так называемый Simplement, 1 в 1 зеркало SAP на базе MS SQL 2016, куда зеркалятся таблицы. Просто если действительно ничего нельзя, то вопрос теряет смысл. Чёрный ящик опечатан, как работает, так и работает, пишите письма в САП. ПОлучается что да, запрещено. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2020, 12:47 |
|
оптимизировать время выполнения запроса.
|
|||
---|---|---|---|
#18+
[quot alexeyvg#22133928] a_voronin А сколько будет для колумнстора? Например, для 50 записей, и для 5 записей, можете назвать число? Я просто не понимаю, что это за такой волшебный индекс, который читает быстрее чем из дерева по ключу, и ещё и обновляется быстрее. a_voronin Альтернатива трансформируйте в схему Звезда, заменяя строковые ID на суррогатные INT. Что касается первого вопроса, мы тут мерились скоростями, частично это отвечает на ваш вопрос. 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/ ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 08:01 |
|
оптимизировать время выполнения запроса.
|
|||
---|---|---|---|
#18+
msLex Данные явно добавляются по дате, и в запросе нет фильтра по дате. Большинство сегментов CS не получится исключить по метаданным, а следовательно будет полный скан всего миллиардного CS, а это гарантированно дольше (много дольше) поиска в 1 index seek (с одним спуском по дереву и последующему range scan) 200-300 записей. Почему нельзя исключить полный скан? Можно. Партиционированный колумнстор. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 09:47 |
|
оптимизировать время выполнения запроса.
|
|||
---|---|---|---|
#18+
a_voronin msLex Данные явно добавляются по дате, и в запросе нет фильтра по дате. Большинство сегментов CS не получится исключить по метаданным, а следовательно будет полный скан всего миллиардного CS, а это гарантированно дольше (много дольше) поиска в 1 index seek (с одним спуском по дереву и последующему range scan) 200-300 записей. Почему нельзя исключить полный скан? Можно. Партиционированный колумнстор. Партиционированный по какому полю? Напомню, что даты в фильтре запроса нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 09:49 |
|
оптимизировать время выполнения запроса.
|
|||
---|---|---|---|
#18+
msLex a_voronin пропущено... Почему нельзя исключить полный скан? Можно. Партиционированный колумнстор. Партиционированный по какому полю? Напомню, что даты в фильтре запроса нет. А что дата -- это единственный способ партиционирования? Там есть код документа. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 11:35 |
|
оптимизировать время выполнения запроса.
|
|||
---|---|---|---|
#18+
a_voronin msLex пропущено... Партиционированный по какому полю? Напомню, что даты в фильтре запроса нет. А что дата -- это единственный способ партиционирования? Там есть код документа. ну так, ваши предложения? какое поле, какие диапазоны для секций? вы, кстати, проигнорировали про update-ы, наличие которых, с ваших слов, жирный плюс для CS. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 11:44 |
|
оптимизировать время выполнения запроса.
|
|||
---|---|---|---|
#18+
msLex a_voronin пропущено... А что дата -- это единственный способ партиционирования? Там есть код документа. ну так, ваши предложения? какое поле, какие диапазоны для секций? вы, кстати, проигнорировали про update-ы, наличие которых, с ваших слов, жирный плюс для CS. Жирный плюс для колумнстрора -- это меньше места на диске. "update-ы, наличие которых, с ваших слов, жирный плюс для CS." такого я не говорил. Я говорил, что update жирный минус на таблице с кучей индексов. Но на партиционированном колумнсторе, если попадать update-ом внутрь 1-3 партиций, и затрагивать не все поля, могут быть быстрее. depends ... ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 13:25 |
|
оптимизировать время выполнения запроса.
|
|||
---|---|---|---|
#18+
a_voronin Жирный плюс для колумнстрора -- это меньше места на диске. Да, только ТС спрашивал про ускорить запрос, а не сократить место занимаемое на диске. a_voronin "update-ы, наличие которых, с ваших слов, жирный плюс для CS." такого я не говорил. вы хоть следите, за тем, что пишите a_voronin Медленный insert и update. А Columnstor тут прописан. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 13:31 |
|
оптимизировать время выполнения запроса.
|
|||
---|---|---|---|
#18+
msLex вы хоть следите, за тем, что пишите a_voronin Медленный insert и update. А Columnstor тут прописан. Да слежу, это вы вырывает фразы из контекста. предыдущее предложение перед этим ещё есть. msLex Да, только ТС спрашивал про ускорить запрос, а не сократить место занимаемое на диске. А вы не видите связь между занимаемым на диске местом и скоростью запросов. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 13:56 |
|
оптимизировать время выполнения запроса.
|
|||
---|---|---|---|
#18+
a_voronin То, что вы говоря о колумсторе, говорите о "записях", указывает мне на то, что тему колумнстора надо бы вам немного покопать. Ибо колумстор это не записи. И выбор целой строки из колумнстора не оптимален. Код: sql 1. 2. 3. 4.
По моему, это ваш вывод, что для оптимизации конкретно этой выборки десятка строк (из миллиарда) по такому условию нужно сделать колумнстор индекс, показывает, что тему колумнстора надо бы вам немного покопать :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 14:21 |
|
оптимизировать время выполнения запроса.
|
|||
---|---|---|---|
#18+
alexeyvg a_voronin То, что вы говоря о колумсторе, говорите о "записях", указывает мне на то, что тему колумнстора надо бы вам немного покопать. Ибо колумстор это не записи. И выбор целой строки из колумнстора не оптимален. Код: sql 1. 2. 3. 4.
По моему, это ваш вывод, что для оптимизации конкретно этой выборки десятка строк (из миллиарда) по такому условию нужно сделать колумнстор индекс, показывает, что тему колумнстора надо бы вам немного покопать :-) А вы считаете, что колумстор оптимизирует только аггрегаты? И выбираются тут не вся строка, а лишь несколько полей. Я то колумсторы копаю уже давно. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 14:28 |
|
оптимизировать время выполнения запроса.
|
|||
---|---|---|---|
#18+
a_voronin Да слежу, это вы вырывает фразы из контекста. предыдущее предложение перед этим ещё есть. Я привел практически полную вашу цитату, приведите полную и осмыслите ее. a_voronin А вы не видите связь между занимаемым на диске местом и скоростью запросов. Скорость запроса (если мы говорим про IO составляющую) определятся количеством операций ввода вывода и скоростью этих операций. То, что обычный индекс будет весить в 5 (пусть даже в 10 ) раз больше чем CS совсем не значит, что весь его нужно будет считать с диска. Обычные (BTree) индексы как раз и нужны, что бы получать нужные данные считав его малую часть. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 14:31 |
|
оптимизировать время выполнения запроса.
|
|||
---|---|---|---|
#18+
msLex a_voronin Да слежу, это вы вырывает фразы из контекста. предыдущее предложение перед этим ещё есть. Я привел практически полную вашу цитату, приведите полную и осмыслите ее. a_voronin А вы не видите связь между занимаемым на диске местом и скоростью запросов. Скорость запроса (если мы говорим про IO составляющую) определятся количеством операций ввода вывода и скоростью этих операций. То, что обычный индекс будет весить в 5 (пусть даже в 10 ) раз больше чем CS совсем не значит, что весь его нужно будет считать с диска. Обычные (BTree) индексы как раз и нужны, что бы получать нужные данные считав его малую часть. Цитата была такой. "потому что потом таблица будет обвешана десятком индексов под каждый запрос и будет много места жрать. Медленный insert и update." заявление про insert и update касалось обычной таблицы ("таблица будет обвешана десятком индексов"), а не колумстора . Впрочем давайте заканчивать это дискуссию. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 15:15 |
|
|
start [/forum/topic.php?fid=46&gotonew=1&tid=1686112]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
30ms |
get topic data: |
10ms |
get first new msg: |
8ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
others: | 276ms |
total: | 411ms |
0 / 0 |