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

Откуда:
Сообщений: 357
Пусть у меня есть таблицы Check где лежат номера чеков с датой , Members таблица c пользователя и CheckLines где лежат линии с чека товар и цена и т.п. К примеру если я делаю выборку с таблиц за 2 месяца по каким то товарам у меня этот запрос делаеться 4 -5 часов, можно ли было б это както исправить секционированием таблицы или нет?
21 дек 15, 11:20    [18587452]     Ответить | Цитировать Сообщить модератору
 Re: Насчет секционирования таблиц  [new]
Glory
Member

Откуда:
Сообщений: 104760
Dimmf28
у меня этот запрос делаеться 4 -5 часов

И вы установили причину такого времени выполнения ?
И причина эта устранима через секционирование ?
21 дек 15, 11:22    [18587463]     Ответить | Цитировать Сообщить модератору
 Re: Насчет секционирования таблиц  [new]
Dimmf28
Member

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

секционирование на этой таблице, нету меня интересует если я сделаю секционировнаие по товару, ускорит ли это выборку?
21 дек 15, 11:28    [18587497]     Ответить | Цитировать Сообщить модератору
 Re: Насчет секционирования таблиц  [new]
SQL2008
Member

Откуда: Москва
Сообщений: 4262
Dimmf28
Glory,

секционирование на этой таблице, нету меня интересует если я сделаю секционировнаие по товару, ускорит ли это выборку?

Предлагаете устроить угадайку?
21 дек 15, 11:30    [18587510]     Ответить | Цитировать Сообщить модератору
 Re: Насчет секционирования таблиц  [new]
Glory
Member

Откуда:
Сообщений: 104760
Dimmf28
секционирование на этой таблице, нету меня интересует если я сделаю секционировнаие по товару, ускорит ли это выборку?

Еще раз
Для того, чтобы что-то ускорить, нужно сначала узнать, почему тормозит.
секционирование - это не волшебная надстройка, которая ускоряет все "выборки".
21 дек 15, 11:31    [18587519]     Ответить | Цитировать Сообщить модератору
 Re: Насчет секционирования таблиц  [new]
SQL2008
Member

Откуда: Москва
Сообщений: 4262
Посмотрите как устроен ваш запрос.
Какие сипользуются индесы.
Секционирование, по моему, сугубо субъективному мнению, оправдано при кол-ве записей от полумиллиарда и выше. И то, когда есть поле, по которому можно однозначно записи дифференцировать.
21 дек 15, 11:33    [18587528]     Ответить | Цитировать Сообщить модератору
 Re: Насчет секционирования таблиц  [new]
Dimmf28
Member

Откуда:
Сообщений: 357
SQL2008,
смотрите с таблице с которой мне надо делать выборки примерно в каждом месяце 200 000 млн записей, инфу. мне надо доставать
к примеру за пару месяцем, вопрос такой стоит ли секционировать по годам и месяцам?
21 дек 15, 12:07    [18587719]     Ответить | Цитировать Сообщить модератору
 Re: Насчет секционирования таблиц  [new]
AndyMandy
Member

Откуда: СПб
Сообщений: 196
Dimmf28
...вопрос такой стоит ли секционировать по годам и месяцам?

Что бы ответить на этот вопрос вам надо:
1. Посмотреть планы выполнения запросов которые у вас тормозят.
2. Оптимизировать эти самые запросы меняя текст запросов.
3. Если оптимизация текста запросов не помогает, необходимо попробовать наложить индексы на используемы таблицы.
Так, что секционирование наверно пока не стоит рассматривать.
21 дек 15, 12:46    [18587985]     Ответить | Цитировать Сообщить модератору
 Re: Насчет секционирования таблиц  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34621
Dimmf28
Пусть у меня есть таблицы Check где лежат номера чеков с датой , Members таблица c пользователя и CheckLines где лежат линии с чека товар и цена и т.п. К примеру если я делаю выборку с таблиц за 2 месяца по каким то товарам у меня этот запрос делаеться 4 -5 часов, можно ли было б это както исправить секционированием таблицы или нет?



сложно говорить без ddl таблиц и без запроса, но скорее всего сканирование тут не поможет.
21 дек 15, 19:56    [18590763]     Ответить | Цитировать Сообщить модератору
 Re: Насчет секционирования таблиц  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34621
Dimmf28
SQL2008,
выборки примерно в каждом месяце 200 000 млн записей,


сколько записей в КАЖДОМ МЕСЯЦЕ?
21 дек 15, 19:59    [18590771]     Ответить | Цитировать Сообщить модератору
 Re: Насчет секционирования таблиц  [new]
Glory
Member

Откуда:
Сообщений: 104760
Dimmf28
смотрите с таблице с которой мне надо делать выборки примерно в каждом месяце 200 000 млн записей

И ваш запрос реально читает все 200 000 000 (умножить на число месяцев) записей или даже больше ?

Dimmf28
вопрос такой стоит ли секционировать по годам и месяцам?

а после секционирования ваш запрос начнет меньше читать записей что ли ?
21 дек 15, 20:48    [18590913]     Ответить | Цитировать Сообщить модератору
 Re: Насчет секционирования таблиц  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31438
Dimmf28
К примеру если я делаю выборку с таблиц за 2 месяца по каким то товарам у меня этот запрос делаеться 4 -5 часов, можно ли было б это както исправить секционированием таблицы или нет?
Нет.
22 дек 15, 00:29    [18591720]     Ответить | Цитировать Сообщить модератору
 Re: Насчет секционирования таблиц  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7868
Если с таблице 10 миллиардов записей за 10 лет, скажем, а в секции будет находиться только один месяц, то, при условии выборки с фильтром по диапазону дат секционирование поможет. Тип данных фильтра запроса должен соответствовать типу данных функции секционирования. Если есть возможность, то для секционирования модно использовать smallint столбец с датой вида ГГММ, например, 1512.
22 дек 15, 13:15    [18593788]     Ответить | Цитировать Сообщить модератору
 Re: Насчет секционирования таблиц  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31438
Владислав Колосов
Если с таблице 10 миллиардов записей за 10 лет, скажем, а в секции будет находиться только один месяц, то, при условии выборки с фильтром по диапазону дат секционирование поможет.
Чем поможет? В обоих случаях нужно будет считать одинаковое количество строк, страниц данных, секторов диска. Естественно, если расположить данные по дате, т.е. сделать по ней кластерный индекс.
22 дек 15, 17:56    [18595754]     Ответить | Цитировать Сообщить модератору
 Re: Насчет секционирования таблиц  [new]
Владислав Колосов
Member

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

Но даже в этом случае сервер не будет просматривать все оглавление с начала, а сразу отправится в нужную секцию. Особенно, если запрос будет с уточнением. Вы, вообще, работали с секциями, измеряли производительность до и после?
23 дек 15, 11:04    [18598078]     Ответить | Цитировать Сообщить модератору
 Re: Насчет секционирования таблиц  [new]
Jovanny
Member

Откуда:
Сообщений: 1195
Владислав Колосов
Если с таблице 10 миллиардов записей за 10 лет

Я так понимаю, у ТС
Dimmf28
примерно в каждом месяце 200 000 млн записей
, т.е. 200 миллиардов записей каждый месяц.
Это довольно много при любом раскладе и есть вероятность, что индексы дефрагментированы.
В любом случае секционировать стоит для оптимизации обслуживания.
23 дек 15, 11:21    [18598189]     Ответить | Цитировать Сообщить модератору
 Re: Насчет секционирования таблиц  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31438
Владислав Колосов
Но даже в этом случае сервер не будет просматривать все оглавление с начала, а сразу отправится в нужную секцию.
Можно конкретнее, насчёт "просматривать все оглавление с начала"?
В обоих случаях, что с секциями, что без, сервер выполнит одинаковое количество чтений страниц. Разве нет?

Вы как то говорите качественными категориями. Можно как то более определённо, какие лишние страницы прочтёт сервер, и сколько их будет, что есть это "оглавление", которое нужно "с начала"? Если вы про лишний уровень индекса, то он будет максимум один, при этих условиях.

Допустим, есть таблица, занимает терабайт за 10 лет. Нам нужно прочитать за 2 месяца по какому то товару. Кластерный индекс по дате и товару.

У нас 2 варианта - поиск по индексу, и сканирование диапазона. В случае секции это может быть сканирование секции, что очевидно хуже. Если в сканирование секции не свалится, то будет то же самое.
Владислав Колосов
Вы, вообще, работали с секциями, измеряли производительность до и после?
Да, работал, как раз в текущей системе есть такое.

Jovanny
есть вероятность, что индексы дефрагментированы.
В любом случае секционировать стоит для оптимизации обслуживания.
Ну, это совсем другое дело - для этого секционирование и используют. А не как галочку "работать быстрее". Хотя работать будет быстрее - именно из за оптимизации обслуживания, и, в частности, из за уменьшения фрагментации.

Впрочем, думаю, Т.С. описался, записей в месяц 200 тысяч, а не 200 тысяч миллионов :-)
23 дек 15, 18:04    [18600628]     Ответить | Цитировать Сообщить модератору
 Re: Насчет секционирования таблиц  [new]
SQL2008
Member

Откуда: Москва
Сообщений: 4262
alexeyvg

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

Нет. Если в запросе указываете секцию, то читается только эта секция. Помнится, что и без указания секции просматривает только нужную, в соответствии с функцией секционирования. Но в этом я не уверен.
23 дек 15, 18:08    [18600645]     Ответить | Цитировать Сообщить модератору
 Re: Насчет секционирования таблиц  [new]
Владислав Колосов
Member

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

именно так, читаются только те секции данных и индексов, которые попадают в фильтрованный диапазон. В результате количество чтений сокращается. Могут сказать, что секционирование позволяет хранит данные звонков за последние 10 лет так, что производительность при месячной выборке остается при выборке приблизительно такой же, как если бы данные хранились в таблице за месяц. Предыдущий вариант хранения с использованием кластерного индекса не мог обеспечить требуемое время запроса.
При этом можно, в принципе, обойтись без дополнительных индексов. При использовании секционированных индексов, опять же, будет просмотрено не все дерево, а только секция. Я сравнивал количество чтений проводил различные эксперименты, на секционированных таблицах при условии правильно составленного запроса их значительно меньше, чем по полной таблице.
23 дек 15, 18:45    [18600796]     Ответить | Цитировать Сообщить модератору
 Re: Насчет секционирования таблиц  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31438
SQL2008
alexeyvg

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

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

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

Откуда это убеждение о волшебном секционировании? Причём без описания механизма, просто "вера"?

Вот я хочу считать значение для даты = вчера, товар = 1.
В индексе сервер находит, что это страницы №№ 5,6,7
Обращается к диску, читает сектора в которых лежат страницы 5,6,7.

Объясните мне разницу, сделана таблица без секционирования, либо эти сектора принадлежат секции №10? Или даже если секция расположена в отдельной файлгруппе, в ней один файл, и эти сектора лежат в файле с именем абвгд?

PS Да, без указания конкретной секции тоже обращение идёт только к нужной, если в запросе указывается поле секционирования.
23 дек 15, 18:47    [18600805]     Ответить | Цитировать Сообщить модератору
 Re: Насчет секционирования таблиц  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31438
Владислав Колосов
именно так, читаются только те секции данных и индексов, которые попадают в фильтрованный диапазон. В результате количество чтений сокращается

В данном случае секции по дате, индекс по дате.

В обоих случаях читаются только данные, которые принадлежат диапазону дат.

Объясните, почему при чтении секции "за сутки" прочитается меньше данных, чем при чтении диапазона индекса за сутки.
И на сколько меньше, напишите формулу, без оценки типа "просматривать все оглавление с начала".
23 дек 15, 18:51    [18600845]     Ответить | Цитировать Сообщить модератору
 Re: Насчет секционирования таблиц  [new]
Владислав Колосов
Member

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

я не механик, не разбираюсь во внутренностях сервера без необходимости. Я, скорее, практик. Я делал и кластерный по дате без секционирования и кластерный с секционированием. Второй вариант работал в десятки раз быстрее и это меня устроило. Каких-то математических объяснений у меня нет.
23 дек 15, 18:58    [18600891]     Ответить | Цитировать Сообщить модератору
 Re: Насчет секционирования таблиц  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31438
Владислав Колосов
я не механик, не разбираюсь во внутренностях сервера без необходимости. Я, скорее, практик.
Так что же вы рассказываете про теории, про области чтения и т.д., раз вы "практик"? :-)
Так и нужно было написать "я сделал секционирование, работало в десятки раз быстрее и это меня устроило. Советую сделать так же"
Владислав Колосов
Каких-то математических объяснений у меня нет.
Эээ, разницу в доступе к неизвестной структуре и неизвестными запросами можно объяснить очень многим :-)

Я вот разгребал проблему, когда веб программисты, воспользовавшись увольнением предыдущего ДБА, включили секционирование, "что бы было быстрее", и сервер встал, производительность упала в сотни раз. И вернуть обратно было тоже очень большой проблемой, поскольку таблица, которую разбили на секции, занимала почти всю СХД.

Потому что нужно не пробовать включать те или иные галочки на сервере, и смотреть, а как то представлять, как это работает, что делает сервер, выполняя запросы.
23 дек 15, 19:08    [18600936]     Ответить | Цитировать Сообщить модератору
 Re: Насчет секционирования таблиц  [new]
invm
Member

Откуда: Москва
Сообщений: 9405
Владислав Колосов
я не механик, не разбираюсь во внутренностях сервера без необходимости. Я, скорее, практик.
Невозможно эффективно пользоваться технологией, не зная как она устроена и работает.
Вы могли получить ускорение выборки за счет секционирования. Например, в таком сценарии:
+
use tempdb;
go

create partition function pfDate(datetime)
as range right for values (
 '20000101', '20010101', '20020101', '20030101', '20040101', '20050101',
 '20060101', '20070101', '20080101', '20090101', '20100101', '20110101',
 '20120101', '20130101', '20150101', '20160101', '20170101', '20180101'
);
go

create partition scheme psDate
as partition pfDate
all to ([primary]);
go

create table dbo.t1 (id int identity, dt datetime not null, v int, primary key (id, dt));
create table dbo.t2 (id int identity, dt datetime not null, v int, primary key (id, dt) on psDate(dt));
go

declare @dt datetime = '20100101';

while @dt < '20140101'
 begin
  insert into dbo.t1
  select top (2000000)
   dateadd(second, row_number() over (order by (select 1)), @dt), 1
  from
   master.dbo.spt_values a cross join
   master.dbo.spt_values b;

  insert into dbo.t2
  select top (2000000)
   dateadd(second, row_number() over (order by (select 1)), @dt), 1
  from
   master.dbo.spt_values a cross join
   master.dbo.spt_values b;

  select @dt = dateadd(year, 1, @dt);
 end;
go

set statistics xml, io, time on;

select
 month(dt), sum(v)
from
 dbo.t1
where
 dt between '20100101' and '20100501'
group by
 month(dt)
option
 (maxdop 1);

select
 month(dt), sum(v)
from
 dbo.t2
where
 dt between '20100101' and '20100501'
group by
 month(dt)
option
 (maxdop 1);

set statistics xml, io, time off;
go

drop table dbo.t2, dbo.t1;
go

drop partition scheme psDate;
drop partition function pfDate;
go
Но из этого не следует, что секционирование ускоряет любые выборки.
Измените в приведенном примере порядок столбцов в ПК таблиц на (dt, id) и сравните результаты.
23 дек 15, 21:23    [18601440]     Ответить | Цитировать Сообщить модератору
 Re: Насчет секционирования таблиц  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31438
invm
Вы могли получить ускорение выборки за счет секционирования. Например, в таком сценарии:
Общий принцип возможного ускорения понятен - запрос (и прочие условия) таковы, что сервер делает план со сканом таблицы (или инедкса).

Разумеется, если таблица поделена на небольшие секции (допустим, сутки за 10 лет), то при наличии в условиях критерия секционирования сервер будет сканировать одну секцию, что действительно даст ускорение в сотни-тысячи раз.

Но это явная проблема с моделью данных и/или с программированием (либо ну уж очень особый лучай),; а в этом топике, у автора, вообще овсем другая ситуация (тут нет и намёка на то, что условия выборки не могут использовать индексы)

Вот так обычно и бывает, когда восклицают (ооо, секционирование всегда помогает!). Но в реальности не всегда, вот так напрямую.
23 дек 15, 23:50    [18602029]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить