Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Запрос к партицированной таблице и к обычной таблице  [new]
aleks222
Member

Откуда:
Сообщений: 747
Владислав Колосов
его назначение MS как раз и определяет как "средство, позволяющее ускорить выполнения запросов при больших размерах таблиц"

Поздравляю вас, соврамши.
Нигде, никогда MS такого не обещала.
4 окт 19, 15:59    [21986880]     Ответить | Цитировать Сообщить модератору
 Re: Запрос к партицированной таблице и к обычной таблице  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36450
aleks222
Владислав Колосов
его назначение MS как раз и определяет как "средство, позволяющее ускорить выполнения запросов при больших размерах таблиц"

Поздравляю вас, соврамши.
Нигде, никогда MS такого не обещала.
На некоторых сценариях, связанных со сканами, выигрыш все-таки есть. И этот выигрыш особенно ощутим, если можно при этом сэкономить на индексе.
4 окт 19, 16:06    [21986885]     Ответить | Цитировать Сообщить модератору
 Re: Запрос к партицированной таблице и к обычной таблице  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6612
автор
ускорить выполнения запросов при больших размерах таблиц

удалять хорошо, обслуживать индексы, иногда вставкоу разруливают.. В общем как и сказали это чисто административная штука, не для селектов :)
4 окт 19, 16:07    [21986886]     Ответить | Цитировать Сообщить модератору
 Re: Запрос к партицированной таблице и к обычной таблице  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 6788
aleks222,

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

Замечу, что в другом случае, выигрыш производительности получаем при HASH JOIN соединении, т.к. запрос может просмотреть не весь объём данных, а только одну секцию при подборе строк для сравнения.

В случае выбора SEEK стратегии разделение на секции не дает преимуществ.
4 окт 19, 17:45    [21986991]     Ответить | Цитировать Сообщить модератору
 Re: Запрос к партицированной таблице и к обычной таблице  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 29246
Владислав Колосов
aleks222,

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

Замечу, что в другом случае, выигрыш производительности получаем при HASH JOIN соединении, т.к. запрос может просмотреть не весь объём данных, а только одну секцию при подборе строк для сравнения.

В случае выбора SEEK стратегии разделение на секции не дает преимуществ.
По моему, диапазон кластерного индекса даст то же самое.
4 окт 19, 22:13    [21987160]     Ответить | Цитировать Сообщить модератору
 Re: Запрос к партицированной таблице и к обычной таблице  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36450
alexeyvg
По моему, диапазон кластерного индекса даст то же самое.
Тут рассказывают про то, что в некоторых случаях можно секционированием избежать создания дополнительного индекса. Есть ситуации, когда сканить пару необольших секций терпимо, а делать индекс ради ускорения этого дофига накладно.
4 окт 19, 22:38    [21987175]     Ответить | Цитировать Сообщить модератору
 Re: Запрос к партицированной таблице и к обычной таблице  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 29246
Гавриленко Сергей Алексеевич
alexeyvg
По моему, диапазон кластерного индекса даст то же самое.
Тут рассказывают про то, что в некоторых случаях можно секционированием избежать создания дополнительного индекса. Есть ситуации, когда сканить пару необольших секций терпимо, а делать индекс ради ускорения этого дофига накладно.
Так секционирование концептуально то же самое, что и кластерный индекс по тому же полю, что и поле секционирования. Индекс не дополнительный, а один, заменяющий секционирование.
Для постоянной вставки в секции ещё можно увидеть преимущества секционирования, но для стабильных данных я их не вижу, будет такой же "скан пары небольших секций".

Конечно, есть какие то совсем особые случаи, как описал Владислав Колосов, но это всё таки совсем редкость, на практике...
5 окт 19, 00:48    [21987204]     Ответить | Цитировать Сообщить модератору
 Re: Запрос к партицированной таблице и к обычной таблице  [new]
Roust_m
Member

Откуда: Сидней
Сообщений: 1049
invm
Roust_m
Вот зашифрованный план по партицированной таблице
Покажите план для
select * from mypartitionedtable with (index = IX_mypartitionedtable_sid)
where sid = ... and pkey = ...
option (maxdop 1)


ЗЫ: Анонимайзер планов есть в SentryOne Plan Explorer


Спасибо за подсказку, я предыдущий руками анонимизровал, прилагаю план.

К сообщению приложен файл (plan_with_index_hint_Anonymized.sqlplan - 13Kb) cкачать
8 окт 19, 04:17    [21988994]     Ответить | Цитировать Сообщить модератору
 Re: Запрос к партицированной таблице и к обычной таблице  [new]
Roust_m
Member

Откуда: Сидней
Сообщений: 1049
А вот такой же план по не партицированной таблице. Стоимость дерева похожа, а время выполнения все равно быстрее в не партицированной таблице.

К сообщению приложен файл (not_partitioned_table_plan2_Anonymized.sqlplan - 11Kb) cкачать
8 окт 19, 04:25    [21988995]     Ответить | Цитировать Сообщить модератору
 Re: Запрос к партицированной таблице и к обычной таблице  [new]
aleks222
Member

Откуда:
Сообщений: 747
Не знаю, как там у антиподов, в австралии.
А в посконной завсегда поиск по ДВУМ полям ключа дольше, чем по одномую
8 окт 19, 06:27    [21989003]     Ответить | Цитировать Сообщить модератору
 Re: Запрос к партицированной таблице и к обычной таблице  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 29246
Roust_m
Стоимость дерева похожа, а время выполнения все равно быстрее в не партицированной таблице.
Стоимость - это большая условность, вычисляется исходя из, например, определённой скорости HDD.

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

Далее, если вы ищете по sid:
Roust_m
invm
Покажите план для
select * from mypartitionedtable with (index = IX_mypartitionedtable_sid)
where sid = ... and pkey = ...
option (maxdop 1)

ЗЫ: Анонимайзер планов есть в SentryOne Plan Explorer

Спасибо за подсказку, я предыдущий руками анонимизровал, прилагаю план.
В плане написано INDEX(Column1) ... WHERE Column2=... AND Column3=...
Это ошибка анонимайзера, или ваша? Вроде индекс должен быть по той же колонке, по которой вы ищите (то есть по sid)?



И третье, вам уже писали, повторю ещё раз - если у вас есть индекс по полю, сервер идёт по этому дереву, достаёт записи, какое преимущество будет, если ему указать партицию?

Он всё равно считает те страницы данных, которые нашёл.

Если бы сервер понял, что выгоднее скан, поскольку селективность индекса низкая, то понятно, можно отсканить одну партицию, но если делается поиск, то почему вы ожидаете ускорение?
8 окт 19, 08:15    [21989040]     Ответить | Цитировать Сообщить модератору
 Re: Запрос к партицированной таблице и к обычной таблице  [new]
Roust_m
Member

Откуда: Сидней
Сообщений: 1049
alexeyvg
Roust_m
Стоимость дерева похожа, а время выполнения все равно быстрее в не партицированной таблице.
Стоимость - это большая условность, вычисляется исходя из, например, определённой скорости HDD.

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

Далее, если вы ищете по sid:
Roust_m
пропущено...

Спасибо за подсказку, я предыдущий руками анонимизровал, прилагаю план.
В плане написано INDEX(Column1) ... WHERE Column2=... AND Column3=...
Это ошибка анонимайзера, или ваша? Вроде индекс должен быть по той же колонке, по которой вы ищите (то есть по sid)?



И третье, вам уже писали, повторю ещё раз - если у вас есть индекс по полю, сервер идёт по этому дереву, достаёт записи, какое преимущество будет, если ему указать партицию?

Он всё равно считает те страницы данных, которые нашёл.

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


Это ошибка анонимайзера, на самом деле там и индекс и один из столбцов по sid.

Я пытаюсь понять как можно сервер заставить сканировать одну партицию, или другим способом заставить запрос работать быстрее.
8 окт 19, 08:36    [21989057]     Ответить | Цитировать Сообщить модератору
 Re: Запрос к партицированной таблице и к обычной таблице  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 29246
Roust_m
Я пытаюсь понять как можно сервер заставить сканировать одну партицию, или другим способом заставить запрос работать быстрее.
Что бы заставить сервер сканировать одну партицию, нужно убрать те индексы, которые позволяют серверу быстро получить данные. тогда сервер свалится в скан.

Попробую объяснить ещё раз.

Вот у вас есть индекс, там указано, что ваши данные находятся на диске в секторе № 123321
Сервер читает сектор 123321, готово!

Далее, вы задаёте вопрос: "как можно сервер заставить сканировать одну партицию"

Вы понимаете, что такой вопрос абсурден, в контексте задачи "прочитать сектор 123321"?
8 окт 19, 08:57    [21989077]     Ответить | Цитировать Сообщить модератору
 Re: Запрос к партицированной таблице и к обычной таблице  [new]
invm
Member

Откуда: Москва
Сообщений: 8797
Roust_m,

План со сканом секции банально дешевле плана с поиском в секции индекса.
Стоимость плана с несекционированным индексом аналогична плану с секционированным.

Можете ради интереса попробовать
select * from mypartitionedtable 
where sid = ... and pkey = ...
option (maxdop 1, use hint('FORCE_LEGACY_CARDINALITY_ESTIMATION'))


Учитывая, что у вас бета 2019-го сервера, не вижу смысла в дальнейших разбирательствах.
8 окт 19, 09:23    [21989100]     Ответить | Цитировать Сообщить модератору
 Re: Запрос к партицированной таблице и к обычной таблице  [new]
Roust_m
Member

Откуда: Сидней
Сообщений: 1049
alexeyvg
Roust_m
Я пытаюсь понять как можно сервер заставить сканировать одну партицию, или другим способом заставить запрос работать быстрее.
Что бы заставить сервер сканировать одну партицию, нужно убрать те индексы, которые позволяют серверу быстро получить данные. тогда сервер свалится в скан.

Попробую объяснить ещё раз.

Вот у вас есть индекс, там указано, что ваши данные находятся на диске в секторе № 123321
Сервер читает сектор 123321, готово!

Далее, вы задаёте вопрос: "как можно сервер заставить сканировать одну партицию"

Вы понимаете, что такой вопрос абсурден, в контексте задачи "прочитать сектор 123321"?


Ну контекст задачи немного шире. Еще одной целью партицирования было собрать все записи по одному и тому же студенту в одной партиции, вместо того, чтобы им быть разбросанными по всей таблице. У одного студента может быть несколько sid. Но pkey есть функция от id студента (st_id). В приложении этот запрос не единственный, поэтому задача заставить это запрос работать на секционированной таблице как можно быстрее. Это на не секционрованной таблице по этому запросу есть индекс где указано, что данные находятся в секторе № 123321. А на секционированной так не получется. Но поскольку секционирование в нашем случае нужно (IMHO), то приодится искать компромисы.
8 окт 19, 10:14    [21989138]     Ответить | Цитировать Сообщить модератору
 Re: Запрос к партицированной таблице и к обычной таблице  [new]
Yasha123
Member

Откуда:
Сообщений: 1553
[quot Roust_m]
alexeyvg
Еще одной целью партицирования было собрать все записи по одному и тому же студенту в одной партиции, вместо того, чтобы им быть разбросанными по всей таблице. У одного студента может быть несколько sid. Но pkey есть функция от id студента (st_id). В приложении этот запрос не единственный, поэтому задача заставить это запрос работать на секционированной таблице как можно быстрее.

ну так соберите их в индексе по pkey,
если запросам это надо.

одно ваше " Всего партиций 15000" заставляется задуматься о неоправданном оверхеде.
вы же своей таблице добавили метаданных больше некуда,
вместо 3 строк allocation units на таблицу типа inrow,row overflow, lob
у вас их 45000.
это не считая индексов, каждый из них еще столько же добавляет.
все это добро надо каждый раз просматривать и оно отгрызет место в buffer pool.
какое уж тут ускорение процесса...
---
ну и у вас что, на каждого студента своя партиция?
8 окт 19, 10:53    [21989186]     Ответить | Цитировать Сообщить модератору
 Re: Запрос к партицированной таблице и к обычной таблице  [new]
Roust_m
Member

Откуда: Сидней
Сообщений: 1049
[quot Yasha123]
Roust_m
пропущено...

ну так соберите их в индексе по pkey,
если запросам это надо.

одно ваше " Всего партиций 15000" заставляется задуматься о неоправданном оверхеде.
вы же своей таблице добавили метаданных больше некуда,
вместо 3 строк allocation units на таблицу типа inrow,row overflow, lob
у вас их 45000.
это не считая индексов, каждый из них еще столько же добавляет.
все это добро надо каждый раз просматривать и оно отгрызет место в buffer pool.
какое уж тут ускорение процесса...
---
ну и у вас что, на каждого студента своя партиция?


Нет, студентов всего около миллиона.
8 окт 19, 14:09    [21989423]     Ответить | Цитировать Сообщить модератору
 Re: Запрос к партицированной таблице и к обычной таблице  [new]
Yasha123
Member

Откуда:
Сообщений: 1553
а какой у вас объем таблицы в гигабайтах?
8 окт 19, 14:50    [21989484]     Ответить | Цитировать Сообщить модератору
 Re: Запрос к партицированной таблице и к обычной таблице  [new]
aleks222
Member

Откуда:
Сообщений: 747
Roust_m
Но поскольку секционирование в нашем случае нужно (IMHO), то приодится искать компромисы.

Бред.
Сам себе не может объяснить: нахера ему секционирование.
А туда же.
Создает трудности и героически их преодолевает.
8 окт 19, 18:08    [21989748]     Ответить | Цитировать Сообщить модератору
 Re: Запрос к партицированной таблице и к обычной таблице  [new]
Roust_m
Member

Откуда: Сидней
Сообщений: 1049
Yasha123
а какой у вас объем таблицы в гигабайтах?


На данный момент, пока все еще в зачатаочном состоянии 10ГБ, но в среднесрочтной перспективе 1.5ТБ
9 окт 19, 01:55    [21989965]     Ответить | Цитировать Сообщить модератору
 Re: Запрос к партицированной таблице и к обычной таблице  [new]
Roust_m
Member

Откуда: Сидней
Сообщений: 1049
invm
Roust_m,

План со сканом секции банально дешевле плана с поиском в секции индекса.
Стоимость плана с несекционированным индексом аналогична плану с секционированным.

Можете ради интереса попробовать
select * from mypartitionedtable 
where sid = ... and pkey = ...
option (maxdop 1, use hint('FORCE_LEGACY_CARDINALITY_ESTIMATION'))


Учитывая, что у вас бета 2019-го сервера, не вижу смысла в дальнейших разбирательствах.


Это Azure, я так понимаю, что Майкрософт тестирует на своих клиентах новые версии сиквела. У мне контроля над версией нет.
9 окт 19, 01:57    [21989967]     Ответить | Цитировать Сообщить модератору
 Re: Запрос к партицированной таблице и к обычной таблице  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36450
Roust_m,

"Все татары кроме я." (с)

Вы можете понятнее выражаться?
Особенно на тему у кого там Azure случился?
И очень интересно, когда вы сообщаете, что у вас контроля над версией нет. Вы уже готовитесь к тому, что вам MS SQL 4.2 раскатают? Или 7.0?
9 окт 19, 02:13    [21989968]     Ответить | Цитировать Сообщить модератору
 Re: Запрос к партицированной таблице и к обычной таблице  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36450
aleks222
Не знаю, как там у антиподов, в австралии.
А в посконной завсегда поиск по ДВУМ полям ключа дольше, чем по одномую
Aleks, я вот даже не знаю. Поиск по двум полям ключа индекса тупо быстрее, потому что поиск по одному, первому, полю ключа того того же индекса в лучшем случае будет плюс-минус так же, а в худшем приведет к Range-скану. А уж если мы говорим про разные индексы, то по тормознутости будет весьма сложно уделать поиск по индексу с одним ключом в 900 байт.
9 окт 19, 02:26    [21989969]     Ответить | Цитировать Сообщить модератору
 Re: Запрос к партицированной таблице и к обычной таблице  [new]
Roust_m
Member

Откуда: Сидней
Сообщений: 1049
aleks222
Roust_m
Но поскольку секционирование в нашем случае нужно (IMHO), то приодится искать компромисы.

Бред.
Сам себе не может объяснить: нахера ему секционирование.
А туда же.
Создает трудности и героически их преодолевает.


Ну хорошо, как тогда в терабайтной таблице данные искать?
9 окт 19, 02:34    [21989970]     Ответить | Цитировать Сообщить модератору
 Re: Запрос к партицированной таблице и к обычной таблице  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36450
Roust_m
Ну хорошо, как тогда в терабайтной таблице данные искать?
Физическим оператором Index Seek. Для одного поиска вы запаритесь делать таблицу, для которой понадобится больше 7-8 чтений. Упомянутые мною выше индексы с 900-байтовыми ключами оставим за скобками.
9 окт 19, 02:36    [21989972]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить