ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Запрос к партицированной таблице и к обычной таблице
54 сообщений из 54, показаны все 3 страниц
  все  
Запрос к партицированной таблице и к обычной таблице
    #39871028
Фотография Roust_m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Roust_m
Участник
Добрый день,

Есть такой запрос:

Код: sql
1.
2.
select * from mytable 
where id=1234567 and pkey=13707



pkey в данном случае ключ по которому таблица партицированна. Всего партиций 15000.


Если запустить подобный запрос на не партицированной таблице:
Код: sql
1.
2.
select * from mytable_no_partition 
where id=1234567


То время исполнения (из Джава приложения) в два-три раза ниже: 170ms вместо 400-500.

Но при этом у первого запроса в реальном плане исполнения Estimated subtree cost = 0.073 а у вторго 0.1366

Почему более низкая стоимость запроса не транслируется в более короткое время исполнения?

Спасибо.
...
Рейтинг: 0 / 0
03.10.2019, 11:20
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39871040
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
msLex
Участник
Roust_mПочему более низкая стоимость запроса не транслируется в более короткое время исполнения?
потому что стоимость плана это не время исполнения.
Не говоря уже, что это Estimated

Покажите планы
...
Рейтинг: 0 / 0
03.10.2019, 11:43
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39871044
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владислав Колосов
Участник
Roust_m,

вы смотрите на предполагаемый план, смотрите на фактический. Сравните, например, объем просмотренных данных в том и ином случае.

Например, для второй таблицы есть индекс по ID и вы получите seek, а в первой таблице индекса нет и получите просмотр секции.
...
Рейтинг: 0 / 0
03.10.2019, 11:44
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39871417
Фотография Roust_m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Roust_m
Участник
Вот план по партицированной таблице. Ниже добавлю второй план по непартицированной По идее вся суть партицирования это зверски улучшить скорость чтения когда ты знаешь в какой партиции ищещь. А получается наоборот, улучшение в непартицированной таблице.
...
Рейтинг: 0 / 0
04.10.2019, 02:41
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39871418
Фотография Roust_m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Roust_m
Участник
Вот непартицированная таблица
...
Рейтинг: 0 / 0
04.10.2019, 02:41
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39871419
Гавриленко Сергей Алексеевич
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гавриленко Сергей Алексеевич
Участник
Roust_mПо идее вся суть партицирования это зверски улучшить скорость чтения когда ты знаешь в какой партиции ищещьТот евангелист, который вам это в уши напел, вас злостно обманул. Index seek по индексу даже с невероятной глубиной в 8-9 уровней уделает любой скан по партиции, если нет нормального seek predicate после elimination.
...
Рейтинг: 0 / 0
04.10.2019, 02:46
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39871421
Гавриленко Сергей Алексеевич
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гавриленко Сергей Алексеевич
Участник
Модератор: Короче, уважаемый Roust_m.

Давайте так. Или вы предоставляете скрипты ваших таблиц, ваши запросы и нормальные планы (обфусцируйте уж как-нибудь), или я к вам за троллинг санкции применю. А то вот сначала эти эпатажные вбросы в двух топиках, что секционирование вам все замедлило, а потом выясняется, что всего лишь у разных ваших запросов к разным вашим таблицам разный план.
...
Рейтинг: 0 / 0
04.10.2019, 02:54
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39871422
Гавриленко Сергей Алексеевич
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гавриленко Сергей Алексеевич
Участник
Модератор: Еще раз русскими буквами: скрипты таблиц с индексами (в текстовом виде), запросы к этим таблицам (в текстовом виде), планы этих запросов (в текстовом виде или в виде sqlplan-файлов). Cкриншоты будут стираться на месте.
...
Рейтинг: 0 / 0
04.10.2019, 03:15
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39871423
Фотография Roust_m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Roust_m
Участник
Вот скрипт партицированной таблицы. Там 15000 партиций. Ключ pkey есть функция от st_id: st_id % 14999 + 1


Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
CREATE TABLE [dbo].[mypartitionedtable](
	[id] [bigint] IDENTITY(1,1) NOT NULL,
	[sid] [bigint] NOT NULL,
	[node_id] [bigint] NOT NULL,
	[st_id] [bigint] NOT NULL,
	[col5] [bigint] NULL,
	[col6] [bigint] NULL,
	[col7] [varchar](2048) NULL,
	[col8] [varchar](512) NULL,
	[col9] [datetime] NULL,
	[col10] [varchar](16) NULL,
	[coll11] [bigint] NULL,
	[coll12] [char](1) NULL,
	[col13] [varchar](512) NULL,
	[col14] [smallint] NULL,
	[col15] [varchar](80) NOT NULL,
	[col16] [datetime] NOT NULL,
	[col17] [varchar](80) NULL,
	[col18] [datetime] NULL,
	[pkey] [smallint] NOT NULL,
 CONSTRAINT [PK_mypartitionedtable] PRIMARY KEY CLUSTERED 
(
	[id] ASC,
	[pkey] ASC
)WITH (STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF) ON [ps_partition_id]([pkey])
) ON [ps_partition_id]([pkey])
GO
CREATE NONCLUSTERED INDEX [IX_mypartitionedtable_sid] ON [dbo].[mypartitionedtable]
(
	[sid] ASC
)WITH (STATISTICS_NORECOMPUTE = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [ps_partition_id]([pkey])
GO
CREATE UNIQUE NONCLUSTERED INDEX [UX_mypartitionedtable] ON [dbo].[mypartitionedtable]
(
	[st_id] ASC,
	[node_id] ASC,
	[pkey] ASC
)WITH (STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [ps_partition_id]([pkey])
GO
...
Рейтинг: 0 / 0
04.10.2019, 03:25
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39871424
Фотография Roust_m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Roust_m
Участник
Вот непартицированная таблица:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
CREATE TABLE [tmp].[my_not_partitionedtable](
	[id] [bigint] IDENTITY(1,1) NOT NULL,
	[sid] [bigint] NOT NULL,
	[node_id] [bigint] NOT NULL,
	[st_id] [bigint] NOT NULL,
	[col5] [bigint] NULL,
	[sec_id] [bigint] NULL,
	[col7] [varchar](2048) NULL,
	[col8] [varchar](512) NULL,
	[col9] [datetime] NULL,
	[col10] [varchar](16) NULL,
	[coll11] [bigint] NULL,
	[coll12] [char](1) NULL,
	[col13] [varchar](512) NULL,
	[col14] [smallint] NULL,
	[col15] [varchar](80) NOT NULL,
	[col16] [datetime] NOT NULL,
	[col17] [varchar](80) NULL,
	[col18] [datetime] NULL,
 CONSTRAINT [PK_my_not_partitionedtable] PRIMARY KEY CLUSTERED 
(
	[id] ASC
)WITH (STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [IX_my_not_partitionedtable] ON [tmp].[my_not_partitionedtable]
(
	[sid] ASC
)WITH (STATISTICS_NORECOMPUTE = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY]
GO
CREATE UNIQUE NONCLUSTERED INDEX [UX_my_not_partitionedtable] ON [tmp].[my_not_partitionedtable]
(
	[sec_id] ASC,
	[node_id] ASC
)WITH (STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY]
GO
...
Рейтинг: 0 / 0
04.10.2019, 03:33
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39871425
Гавриленко Сергей Алексеевич
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гавриленко Сергей Алексеевич
Участник
У вас вторые некластерные индексы UX_mypartitionedtable / UX_my_not_partitionedtable вообще не идентичны если убрать ключ секционирования.
...
Рейтинг: 0 / 0
04.10.2019, 03:35
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39871426
Фотография Roust_m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Roust_m
Участник
Вот запрос в партицированной таблице:

Код: sql
1.
select * from [dbo].[mypartitionedtable] where sid=140862 and pkey=13707




А это к непратицированной:

Код: sql
1.
select * from [tmp].[my_not_partitionedtable] where sid=131623
...
Рейтинг: 0 / 0
04.10.2019, 03:37
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39871427
Гавриленко Сергей Алексеевич
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гавриленко Сергей Алексеевич
Участник
Удивительно, что хоть где-то index seek...

Чтобы было быстро выбирать все поля по sid, надо сделать индекс по (sid) include (все остальные поля, кроме ключей кластерного индекса).
А секционирование уберите. В вашем случае оно разве что могло бы быть похоже на борьбу с latch contention, которого, скорее всего, у вас и в помине нет. Рано еще оно вам.
...
Рейтинг: 0 / 0
04.10.2019, 03:43
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39871428
Фотография Roust_m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Roust_m
Участник
Гавриленко Сергей АлексеевичУ вас вторые некластерные индексы UX_mypartitionedtable / UX_my_not_partitionedtable вообще не идентичны если убрать ключ секционирования.

Хоть этот индекс и не используется, исправил, теперь непратицированная таблица выглядит так. (ниже). Непратицированная таблица по прежнему гораздо быстрее по времени. Щас зашишрую немного имена объектов и выложу планы.

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
CREATE TABLE [tmp].[my_not_partitionedtable](
	[id] [bigint] IDENTITY(1,1) NOT NULL,
	[sid] [bigint] NOT NULL,
	[node_id] [bigint] NOT NULL,
	[st_id] [bigint] NOT NULL,
	[col5] [bigint] NULL,
	[sec_id] [bigint] NULL,
	[col7] [varchar](2048) NULL,
	[col8] [varchar](512) NULL,
	[col9] [datetime] NULL,
	[col10] [varchar](16) NULL,
	[coll11] [bigint] NULL,
	[coll12] [char](1) NULL,
	[col13] [varchar](512) NULL,
	[col14] [smallint] NULL,
	[col15] [varchar](80) NOT NULL,
	[col16] [datetime] NOT NULL,
	[col17] [varchar](80) NULL,
	[col18] [datetime] NULL,
 CONSTRAINT [PK_my_not_partitionedtable] PRIMARY KEY CLUSTERED 
(
	[id] ASC
)WITH (STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [IX_my_not_partitionedtable] ON [tmp].[my_not_partitionedtable]
(
	[sid] ASC
)WITH (STATISTICS_NORECOMPUTE = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY]
GO
CREATE UNIQUE NONCLUSTERED INDEX [UX_my_not_partitionedtable] ON [tmp].[my_not_partitionedtable]
(
	[st_id] ASC,
	[node_id] ASC
)WITH (STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY]
GO
...
Рейтинг: 0 / 0
04.10.2019, 03:56
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39871429
Фотография Roust_m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Roust_m
Участник
Гавриленко Сергей АлексеевичУдивительно, что хоть где-то index seek...

Чтобы было быстро выбирать все поля по sid, надо сделать индекс по (sid) include (все остальные поля, кроме ключей кластерного индекса).
А секционирование уберите. В вашем случае оно разве что могло бы быть похоже на борьбу с latch contention, которого, скорее всего, у вас и в помине нет. Рано еще оно вам.

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

Еще один момент, который учитывался при решении применить секционирование, это то, что большинство запросов используют st_id или он известен. Поскольку диапазон st_id около миллиона, то, создали pkey, который есть остаток от деления st_id на 14999 плюс 1.

То есть предполагалось, что все данные для одного и того-же студента будут в одной партиции. На данный момент в партиции с pkey=13707 всего 353 записи, из которых выбирается 31 запись.

В непартицированной таблице 5843430 записей, из которых выбирается 52. Я не понимаю, почему выбрать 31 запись из 353 занимает больше времени, чем выбрать 52 записи из почти 6-ти миллионов. Я теряю веру в технологический прогресс и вообще во все человечество.

Решение убрать секционирование не очень простое, ибо это может затронуть другие запросы.
...
Рейтинг: 0 / 0
04.10.2019, 04:16
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39871430
Фотография Roust_m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Roust_m
Участник
Гавриленко Сергей АлексеевичУдивительно, что хоть где-то index seek...

Чтобы было быстро выбирать все поля по sid, надо сделать индекс по (sid) include (все остальные поля, кроме ключей кластерного индекса).


Разные запросы будут использовать разные поля, то есть придется создать индекс по sid и включить туда почти все поля в таблице. Если следовать этому подходу и для других запросов, то размер индексов будет огромен, что замедлит вставку данных в таблицу а также изменение данных. Палка о двух конца.
...
Рейтинг: 0 / 0
04.10.2019, 04:40
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39871432
Фотография Roust_m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Roust_m
Участник
Вот зашифрованный план по партицированной таблице. Очень желательно найти способ сделать так, чтобы это работало быстро на партицированной таблице. Убирать партицирование будет означать проблемы в других местах.
...
Рейтинг: 0 / 0
04.10.2019, 04:56
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39871437
Фотография Roust_m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Roust_m
Участник
Владислав КолосовRoust_m,

вы смотрите на предполагаемый план, смотрите на фактический. Сравните, например, объем просмотренных данных в том и ином случае.

Например, для второй таблицы есть индекс по ID и вы получите seek, а в первой таблице индекса нет и получите просмотр секции.

В обеих таблицах есть индекс по ID (sid), в партицированной таблице он тоже партицирован, однако же в партицированной таблице такой индекс не используется и происходит скан по кластерному индексу.
...
Рейтинг: 0 / 0
04.10.2019, 05:18
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39871438
Idol_111
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Idol_111
Участник
Roust_m Большая часть запросов герерится Джавой (там есть какая-то автоматическая приблуда для этого). В редких случаях, когда совсем никак эти запросы выносятся в хранимую процедуру, остальное автоматом, чтобы ускорить время разработки. Повлиять я на это не могу.
как это знакомо, а вот теперь огребаем по полной.
...
Рейтинг: 0 / 0
04.10.2019, 05:53
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39871481
Фотография StarikNavy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
StarikNavy
Участник
Roust_m,

партиционирование это в основном для удобства обслуживания, а не для ускорения запросов
...
Рейтинг: 0 / 0
04.10.2019, 09:49
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39871528
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владислав Колосов
Участник
Roust_m,

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

сканирование может происходить в результате несоблюдения приоритета типов или самих типов передаваемого в запрос параметра и аргумента функции секционирования.

И да, секционирование не всегда имеет смысл создавать для сокращения времени запросов. Нельзя утверждать, что оно предназначено именно для обслуживания, его назначение MS как раз и определяет как "средство, позволяющее ускорить выполнения запросов при больших размерах таблиц" в учебных курсах, например. Однако, они не рассматривают подробно сценарии, применимые для таких практик, поэтому возникает ощущение, что так следует делать всегда на любых больших таблицах.
...
Рейтинг: 0 / 0
04.10.2019, 11:36
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39871661
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
invm
Участник
Roust_mВот зашифрованный план по партицированной таблицеПокажите план для
Код: sql
1.
2.
3.
select * from mypartitionedtable with (index = IX_mypartitionedtable_sid)
where sid = ... and pkey = ...
option (maxdop 1)



ЗЫ: Анонимайзер планов есть в SentryOne Plan Explorer
...
Рейтинг: 0 / 0
04.10.2019, 14:00
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39871735
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aleks222
Участник
Roust_mЯ не понимаю, почему выбрать 31 запись из 353 занимает больше времени, чем выбрать 52 записи из почти 6-ти миллионов. Я теряю веру в технологический прогресс и вообще во все человечество.

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

Или другими словами: бесполезно ожидать ускорения выборки от партиционирования.
...
Рейтинг: 0 / 0
04.10.2019, 15:57
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39871736
TaPaK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
TaPaK
Участник
aleks222,
авторИли другими словами: бесполезно ожидать ускорения выборки от партиционирования.

деградацию так точно стоит ожидать
...
Рейтинг: 0 / 0
04.10.2019, 15:58
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39871738
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aleks222
Участник
Владислав Колосовего назначение MS как раз и определяет как "средство, позволяющее ускорить выполнения запросов при больших размерах таблиц"
Поздравляю вас, соврамши.
Нигде, никогда MS такого не обещала.
...
Рейтинг: 0 / 0
04.10.2019, 15:59
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39871741
Гавриленко Сергей Алексеевич
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гавриленко Сергей Алексеевич
Участник
aleks222Владислав Колосовего назначение MS как раз и определяет как "средство, позволяющее ускорить выполнения запросов при больших размерах таблиц"
Поздравляю вас, соврамши.
Нигде, никогда MS такого не обещала.На некоторых сценариях, связанных со сканами, выигрыш все-таки есть. И этот выигрыш особенно ощутим, если можно при этом сэкономить на индексе.
...
Рейтинг: 0 / 0
04.10.2019, 16:06
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39871742
TaPaK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
TaPaK
Участник
автор ускорить выполнения запросов при больших размерах таблиц

удалять хорошо, обслуживать индексы, иногда вставкоу разруливают.. В общем как и сказали это чисто административная штука, не для селектов :)
...
Рейтинг: 0 / 0
04.10.2019, 16:07
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39871815
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владислав Колосов
Участник
aleks222,

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

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

В случае выбора SEEK стратегии разделение на секции не дает преимуществ.
...
Рейтинг: 0 / 0
04.10.2019, 17:45
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39871920
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
Владислав Колосовaleks222,

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

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

В случае выбора SEEK стратегии разделение на секции не дает преимуществ.По моему, диапазон кластерного индекса даст то же самое.
...
Рейтинг: 0 / 0
04.10.2019, 22:13
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39871933
Гавриленко Сергей Алексеевич
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гавриленко Сергей Алексеевич
Участник
alexeyvgПо моему, диапазон кластерного индекса даст то же самое.Тут рассказывают про то, что в некоторых случаях можно секционированием избежать создания дополнительного индекса. Есть ситуации, когда сканить пару необольших секций терпимо, а делать индекс ради ускорения этого дофига накладно.
...
Рейтинг: 0 / 0
04.10.2019, 22:38
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39871956
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
Гавриленко Сергей АлексеевичalexeyvgПо моему, диапазон кластерного индекса даст то же самое.Тут рассказывают про то, что в некоторых случаях можно секционированием избежать создания дополнительного индекса. Есть ситуации, когда сканить пару необольших секций терпимо, а делать индекс ради ускорения этого дофига накладно.Так секционирование концептуально то же самое, что и кластерный индекс по тому же полю, что и поле секционирования. Индекс не дополнительный, а один, заменяющий секционирование.
Для постоянной вставки в секции ещё можно увидеть преимущества секционирования, но для стабильных данных я их не вижу, будет такой же "скан пары небольших секций".

Конечно, есть какие то совсем особые случаи, как описал Владислав Колосов, но это всё таки совсем редкость, на практике...
...
Рейтинг: 0 / 0
05.10.2019, 00:48
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39873091
Фотография Roust_m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Roust_m
Участник
invmRoust_mВот зашифрованный план по партицированной таблицеПокажите план для
Код: sql
1.
2.
3.
select * from mypartitionedtable with (index = IX_mypartitionedtable_sid)
where sid = ... and pkey = ...
option (maxdop 1)



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

Спасибо за подсказку, я предыдущий руками анонимизровал, прилагаю план.
...
Рейтинг: 0 / 0
08.10.2019, 04:17
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39873092
Фотография Roust_m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Roust_m
Участник
А вот такой же план по не партицированной таблице. Стоимость дерева похожа, а время выполнения все равно быстрее в не партицированной таблице.
...
Рейтинг: 0 / 0
08.10.2019, 04:25
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39873098
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aleks222
Участник
Не знаю, как там у антиподов, в австралии.
А в посконной завсегда поиск по ДВУМ полям ключа дольше, чем по одномую
...
Рейтинг: 0 / 0
08.10.2019, 06:27
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39873122
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
Roust_mСтоимость дерева похожа, а время выполнения все равно быстрее в не партицированной таблице.Стоимость - это большая условность, вычисляется исходя из, например, определённой скорости HDD.

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

Далее, если вы ищете по sid:
Roust_minvmПокажите план для
Код: sql
1.
2.
3.
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)?



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

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

Если бы сервер понял, что выгоднее скан, поскольку селективность индекса низкая, то понятно, можно отсканить одну партицию, но если делается поиск, то почему вы ожидаете ускорение?
...
Рейтинг: 0 / 0
08.10.2019, 08:15
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39873131
Фотография Roust_m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Roust_m
Участник
alexeyvgRoust_mСтоимость дерева похожа, а время выполнения все равно быстрее в не партицированной таблице.Стоимость - это большая условность, вычисляется исходя из, например, определённой скорости HDD.

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

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

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



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

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

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

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

Я пытаюсь понять как можно сервер заставить сканировать одну партицию, или другим способом заставить запрос работать быстрее.
...
Рейтинг: 0 / 0
08.10.2019, 08:36
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39873146
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
Roust_mЯ пытаюсь понять как можно сервер заставить сканировать одну партицию, или другим способом заставить запрос работать быстрее.Что бы заставить сервер сканировать одну партицию, нужно убрать те индексы, которые позволяют серверу быстро получить данные. тогда сервер свалится в скан.

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

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

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

Вы понимаете, что такой вопрос абсурден, в контексте задачи "прочитать сектор 123321"?
...
Рейтинг: 0 / 0
08.10.2019, 08:57
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39873160
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
invm
Участник
Roust_m,

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

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



Учитывая, что у вас бета 2019-го сервера, не вижу смысла в дальнейших разбирательствах.
...
Рейтинг: 0 / 0
08.10.2019, 09:23
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39873178
Фотография Roust_m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Roust_m
Участник
alexeyvgRoust_mЯ пытаюсь понять как можно сервер заставить сканировать одну партицию, или другим способом заставить запрос работать быстрее.Что бы заставить сервер сканировать одну партицию, нужно убрать те индексы, которые позволяют серверу быстро получить данные. тогда сервер свалится в скан.

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

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

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

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

Ну контекст задачи немного шире. Еще одной целью партицирования было собрать все записи по одному и тому же студенту в одной партиции, вместо того, чтобы им быть разбросанными по всей таблице. У одного студента может быть несколько sid. Но pkey есть функция от id студента (st_id). В приложении этот запрос не единственный, поэтому задача заставить это запрос работать на секционированной таблице как можно быстрее. Это на не секционрованной таблице по этому запросу есть индекс где указано, что данные находятся в секторе № 123321. А на секционированной так не получется. Но поскольку секционирование в нашем случае нужно (IMHO), то приодится искать компромисы.
...
Рейтинг: 0 / 0
08.10.2019, 10:14
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39873211
Фотография Yasha123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yasha123
Участник
[quot Roust_m]alexeyvgЕще одной целью партицирования было собрать все записи по одному и тому же студенту в одной партиции, вместо того, чтобы им быть разбросанными по всей таблице. У одного студента может быть несколько sid. Но pkey есть функция от id студента (st_id). В приложении этот запрос не единственный, поэтому задача заставить это запрос работать на секционированной таблице как можно быстрее.
ну так соберите их в индексе по pkey,
если запросам это надо.

одно ваше " Всего партиций 15000" заставляется задуматься о неоправданном оверхеде.
вы же своей таблице добавили метаданных больше некуда,
вместо 3 строк allocation units на таблицу типа inrow,row overflow, lob
у вас их 45000.
это не считая индексов, каждый из них еще столько же добавляет.
все это добро надо каждый раз просматривать и оно отгрызет место в buffer pool.
какое уж тут ускорение процесса...
---
ну и у вас что, на каждого студента своя партиция?
...
Рейтинг: 0 / 0
08.10.2019, 10:53
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39873355
Фотография Roust_m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Roust_m
Участник
[quot Yasha123]Roust_mпропущено...

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

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

Нет, студентов всего около миллиона.
...
Рейтинг: 0 / 0
08.10.2019, 14:09
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39873399
Фотография Yasha123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yasha123
Участник
а какой у вас объем таблицы в гигабайтах?
...
Рейтинг: 0 / 0
08.10.2019, 14:50
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39873550
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aleks222
Участник
Roust_m Но поскольку секционирование в нашем случае нужно (IMHO), то приодится искать компромисы.
Бред.
Сам себе не может объяснить: нахера ему секционирование.
А туда же.
Создает трудности и героически их преодолевает.
...
Рейтинг: 0 / 0
08.10.2019, 18:08
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39873691
Фотография Roust_m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Roust_m
Участник
Yasha123а какой у вас объем таблицы в гигабайтах?

На данный момент, пока все еще в зачатаочном состоянии 10ГБ, но в среднесрочтной перспективе 1.5ТБ
...
Рейтинг: 0 / 0
09.10.2019, 01:55
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39873693
Фотография Roust_m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Roust_m
Участник
invmRoust_m,

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

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



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

Это Azure, я так понимаю, что Майкрософт тестирует на своих клиентах новые версии сиквела. У мне контроля над версией нет.
...
Рейтинг: 0 / 0
09.10.2019, 01:57
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39873694
Гавриленко Сергей Алексеевич
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гавриленко Сергей Алексеевич
Участник
Roust_m,

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

Вы можете понятнее выражаться?
Особенно на тему у кого там Azure случился?
И очень интересно, когда вы сообщаете, что у вас контроля над версией нет. Вы уже готовитесь к тому, что вам MS SQL 4.2 раскатают? Или 7.0?
...
Рейтинг: 0 / 0
09.10.2019, 02:13
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39873695
Гавриленко Сергей Алексеевич
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гавриленко Сергей Алексеевич
Участник
aleks222Не знаю, как там у антиподов, в австралии.
А в посконной завсегда поиск по ДВУМ полям ключа дольше, чем по одномуюAleks, я вот даже не знаю. Поиск по двум полям ключа индекса тупо быстрее, потому что поиск по одному, первому, полю ключа того того же индекса в лучшем случае будет плюс-минус так же, а в худшем приведет к Range-скану. А уж если мы говорим про разные индексы, то по тормознутости будет весьма сложно уделать поиск по индексу с одним ключом в 900 байт.
...
Рейтинг: 0 / 0
09.10.2019, 02:26
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39873696
Фотография Roust_m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Roust_m
Участник
aleks222Roust_m Но поскольку секционирование в нашем случае нужно (IMHO), то приодится искать компромисы.
Бред.
Сам себе не может объяснить: нахера ему секционирование.
А туда же.
Создает трудности и героически их преодолевает.

Ну хорошо, как тогда в терабайтной таблице данные искать?
...
Рейтинг: 0 / 0
09.10.2019, 02:34
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39873698
Гавриленко Сергей Алексеевич
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гавриленко Сергей Алексеевич
Участник
Roust_mНу хорошо, как тогда в терабайтной таблице данные искать?Физическим оператором Index Seek. Для одного поиска вы запаритесь делать таблицу, для которой понадобится больше 7-8 чтений. Упомянутые мною выше индексы с 900-байтовыми ключами оставим за скобками.
...
Рейтинг: 0 / 0
09.10.2019, 02:36
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39873703
Фотография Roust_m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Roust_m
Участник
Гавриленко Сергей АлексеевичRoust_m,

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

Вы можете понятнее выражаться?
Особенно на тему у кого там Azure случился?
И очень интересно, когда вы сообщаете, что у вас контроля над версией нет. Вы уже готовитесь к тому, что вам MS SQL 4.2 раскатают? Или 7.0?

В нашей среде, если нужна база, то отвечающий за это человек заходит на Azure портал и нажимает несколько кнопок, указывая какого размера и производительности нужна база. Выбора версии там нет. Старых версий у нас не раскатают, наоборот, в такой среде Майкрософт использует самую новую версию, даже если она не вышла еще на рынок. Вы разве про это не знаете? Да, они на клиентах как на хомячках обкатывают новую версию, зато потом, когда она готова, получается гораздо стабильнее.
Я только что сам туда зашел, кнопки выбрать версию (2016 к примеру) не увидел.
...
Рейтинг: 0 / 0
09.10.2019, 04:02
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39873711
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
Roust_mНу хорошо, как тогда в терабайтной таблице данные искать?Какая разница, сколько байт в таблице, если вам нужно считать сектор №123321?
...
Рейтинг: 0 / 0
09.10.2019, 07:31
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39873715
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
Roust_malexeyvgВот у вас есть индекс, там указано, что ваши данные находятся на диске в секторе № 123321
Сервер читает сектор 123321, готово!

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

Вы понимаете, что такой вопрос абсурден, в контексте задачи "прочитать сектор 123321"?
Ну контекст задачи немного шире. Еще одной целью партицирования было собрать все записи по одному и тому же студенту в одной партиции, вместо того, чтобы им быть разбросанными по всей таблице. У одного студента может быть несколько sid. Но pkey есть функция от id студента (st_id). В приложении этот запрос не единственный, поэтому задача заставить это запрос работать на секционированной таблице как можно быстрее. Это на не секционрованной таблице по этому запросу есть индекс где указано, что данные находятся в секторе № 123321. А на секционированной так не получется. Но поскольку секционирование в нашем случае нужно (IMHO), то приодится искать компромисы.Между тем, что все записи по одному и тому же студенту в одной партиции, или они разбросаны по всей таблице, нет никакой разницы.

У вас всего лишь 3 варианта :

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

2) Данные разбросаны по разным секторам, и для получения данных вам нужно прочитать N секторов из некоего набора (№123321, №765567, №444333, .........).
В этом случае тоже неважно, в одной партиции у вас данные, или в нескольких. Вы просто читаете с диска сектора из списка. Если данные в одной партиции, то сектора будут поближе друг к другу, ну и что?

3) У вас нет списка секторов. Для получения данных вы должны просканировать фрагмент таблицы по какому то условию, и потом их отфильтровать.
Да, в этом случае, как одно из решений, можно использовать секционирование.
Но можно использовать и другие варианты, никакого преимущества секционирования перед ними нет (за исключением неких тонкостей, но глупо, не зная их, цепляться за секционарование).
Однако, тут (вариант 3) важно понимать, что такое сканирование (пусть даже одной секции) - признак грубейшей ошибки проектирования, которая сделает невозможным практическое использование базы данных (почти всегда, хотя есть и исключения).
...
Рейтинг: 0 / 0
09.10.2019, 07:44
| Ответить | Цитировать | Написать  
Запрос к партицированной таблице и к обычной таблице
    #39874932
Фотография Mind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mind
Участник
Roust_mВот скрипт партицированной таблицы. Там 15000 партиций. Ключ pkey есть функция от st_id: st_id % 14999 +1Сорри, не стал читать весь топик, но это самое идиотское секционирование которое я когда либо видел в жизни.
...
Рейтинг: 0 / 0
10.10.2019, 22:45
| Ответить | Цитировать | Написать  
54 сообщений из 54, показаны все 3 страниц
  все  
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Запрос к партицированной таблице и к обычной таблице
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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