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

Откуда: Санкт-Петербург
Сообщений: 348
Товарищи, имеем Microsoft SQL Server Standard Edition (64-bit). База толстая около 700 ГБ. при этом имеется таблица, которая составляет примерно 30 процентов от всей базы. Возникла затея секционировать ее по месяцам. Возник спор с админами. Утвержают, что современные контролеры файловых хранилищ настолько круты, что секционирование вовсе не имеет смысла с точки зрения ускорения доступа. Насколько я успел изучить этот вопрос, оно до сих пор актуально и еще как. Подскажите у кого был опыт работы с подобными крупными базами. Что мы выиграем и где проиграем сделав такую "колбасу".
2 окт 13, 10:18    [14910572]     Ответить | Цитировать Сообщить модератору
 Re: Секционирование  [new]
aleks2
Guest
MedBrat
секционирование вовсе не имеет смысла с точки зрения ускорения доступа


Даже майкрософт этого не обещала.
2 окт 13, 10:23    [14910616]     Ответить | Цитировать Сообщить модератору
 Re: Секционирование  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31949
MedBrat
Товарищи, имеем Microsoft SQL Server Standard Edition (64-bit).
Версия то какая?
MedBrat
Утвержают, что современные контролеры файловых хранилищ настолько круты, что секционирование вовсе не имеет смысла с точки зрения ускорения доступа.
Про крутость контроллеров фраза совершенон не имеет смысла, в данном контексте это чисто количественный показатель быстродействия. Это всё равно что сказать - "современные контролеры файловых хранилищ настолько круты, что индексы вовсе не имеют смысла с точки зрения ускорения доступа"

Ускорения доступа при использовании секционирования само по себе не произойдёт независимо от крутости контроллера. Поиск по индексу или сканирование всей таблицы с секциями и без секций потребует одинаковых ресурсов.

Секции полезны для ряда задач, которые решаются именно посекционно. Например:

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

    Вот примерно такое направление. В общем, не рассматриваете секционирование как просто опцию таблицы БД для повышения быстродействия, смотрите на конкретное использование секций.
  • 2 окт 13, 10:34    [14910673]     Ответить | Цитировать Сообщить модератору
     Re: Секционирование  [new]
    Гость333
    Member

    Откуда:
    Сообщений: 3683
    MedBrat
    Microsoft SQL Server Standard Edition
    секционировать по месяцам

    Секционированные таблицы поддерживаются только в Enterprise Edition. Вы хотите апгрейдить сервер, или сделать вместо таблицы секционированное представление?
    2 окт 13, 10:40    [14910716]     Ответить | Цитировать Сообщить модератору
     Re: Секционирование  [new]
    Гость333
    Member

    Откуда:
    Сообщений: 3683
    alexeyvg
    Поиск по индексу ... с секциями и без секций потребует одинаковых ресурсов.

    Это если в запросе указано условие, позволяющее вычислить номер секции (в данном случае условие по дате/диапазону дат). Если же такое условие отсутствует, то вместо одного index seek будет выполнено N index seek'ов, где N — количество секций в индексе. То есть некоторые запросы по секционированной таблице вполне могут выполняться медленнее, чем по несекционированной.
    2 окт 13, 10:44    [14910742]     Ответить | Цитировать Сообщить модератору
     Re: Секционирование  [new]
    SQL2008
    Member

    Откуда: Москва
    Сообщений: 4478
    MedBrat
    Товарищи, имеем Microsoft SQL Server Standard Edition (64-bit). База толстая около 700 ГБ. при этом имеется таблица, которая составляет примерно 30 процентов от всей базы. Возникла затея секционировать ее по месяцам. Возник спор с админами. Утвержают, что современные контролеры файловых хранилищ настолько круты, что секционирование вовсе не имеет смысла с точки зрения ускорения доступа. Насколько я успел изучить этот вопрос, оно до сих пор актуально и еще как. Подскажите у кого был опыт работы с подобными крупными базами. Что мы выиграем и где проиграем сделав такую "колбасу".

    200 гб не такая уже и большая таблица. Вы можете не увидеть значительного выигрыша производительности.
    В своей практике сталкивался с схемой, когда в отсоединенную секцию заливались данные, а затем она присоединялась к основной таблице. Выигрыш по производительности вставки был приличным.
    2 окт 13, 10:47    [14910755]     Ответить | Цитировать Сообщить модератору
     Re: Секционирование  [new]
    MedBrat
    Member

    Откуда: Санкт-Петербург
    Сообщений: 348
    -С точки зрения ускорения досутпа я нашел вот такую картиунку. На мой взгляд вполне логично, что если физически данные размазаны по нескольким носителям, то скорость доступа к ним будет выше. https://www.sql.ru/subscribe/2005/269_02.gif

    -За замечание по версии спасибо 2008 R2. Укажите какой сервер лучше использовать для моей задачи.

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

    Логика простая. Если запись осуществляется быстро -> блокировка быстро снимается или если пользователь работает в одной секции (насколько я понял такое возможно) -> в другой секции могут орудовать другие пользователи и проблемы не будет.

    Верно мыслю?
    2 окт 13, 10:50    [14910778]     Ответить | Цитировать Сообщить модератору
     Re: Секционирование  [new]
    partition
    Guest
    MedBrat
    -С точки зрения ускорения досутпа я нашел вот такую картиунку. На мой взгляд вполне логично, что если физически данные размазаны по нескольким носителям, то скорость доступа к ним будет выше. https://www.sql.ru/subscribe/2005/269_02.gif

    -За замечание по версии спасибо 2008 R2. Укажите какой сервер лучше использовать для моей задачи.

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

    Логика простая. Если запись осуществляется быстро -> блокировка быстро снимается или если пользователь работает в одной секции (насколько я понял такое возможно) -> в другой секции могут орудовать другие пользователи и проблемы не будет.

    Верно мыслю?


    у вас каша в голове

    во-первых, для размазывания данных по разным дискам секционирование не нужно, существуют файловые группы
    во-вторых, блокировки далеко не всегда (и это еще мягко сказано) эскалируются до уровня таблицы, при одиночных вставках, несовместимые блокировки обычно "вешаются" на уровень ключей
    2 окт 13, 10:57    [14910825]     Ответить | Цитировать Сообщить модератору
     Re: Секционирование  [new]
    верно мыслите
    Guest
    MedBrat,

    конкурирующие транзакции можно разводить партишинингом. но следует помнить, что при использовании увеличивающихся на 1 ключей, в индексы, записи будут добавляться в крайний правый листовой блок - конкуренция и эскалация блокировок до уровня страницы обеспечена. можно пользовать partitioning_key+guid, тогда будет размазывать по партициям и в пределах партиции. но выставить нормальный fill_factor и pad_index, чтобы поменьше page split'ов было.
    2 окт 13, 11:01    [14910859]     Ответить | Цитировать Сообщить модератору
     Re: Секционирование  [new]
    MedBrat
    Member

    Откуда: Санкт-Петербург
    Сообщений: 348
    partition,

    - спасибо за замечание. не указал, что данную картинку вырвал из контекста секционирования + создание файловых групп. Амины утверждают, что подобная схема невозможна. Такое с их слов возможно при наличии нескольких файловых хранилищ. Дескать контроллер сам решает где хранить данные.

    - по блокировкам буду признателен, если дадите ссылку на материал где можно более детально изучить их природу.
    2 окт 13, 11:02    [14910862]     Ответить | Цитировать Сообщить модератору
     Re: Секционирование  [new]
    не верно мыслите
    Guest
    partition
    у вас каша в голове

    во-первых, для размазывания данных по разным дискам секционирование не нужно, существуют файловые группы


    топег стартер имел ввиду контролируемое размазывание, когда он знает, что самая горячая партиция валяется на самой шустрой дисковой группе, а все холодные партиции за 15 век до н. э. валяются на самых унылых дисковых группах или вообще где-то на ленте
    2 окт 13, 11:05    [14910892]     Ответить | Цитировать Сообщить модератору
     Re: Секционирование  [new]
    MedBrat
    Member

    Откуда: Санкт-Петербург
    Сообщений: 348
    не верно мыслите, Т.е. такую тему как изображена на схеме реализовывать не имеет смысла?
    2 окт 13, 11:22    [14911030]     Ответить | Цитировать Сообщить модератору
     Re: Секционирование  [new]
    MedBrat
    Member

    Откуда: Санкт-Петербург
    Сообщений: 348
    Гость333,

    а какой вариант посоветуете для решения подобной задач:
    -ускорение доступа к данным
    -уменьшения "вреда" блокировок на доступ к данным.
    2 окт 13, 11:25    [14911047]     Ответить | Цитировать Сообщить модератору
     Re: Секционирование  [new]
    tpg
    Member

    Откуда: Novosibirsk
    Сообщений: 23902
    MedBrat
    -уменьшения "вреда" блокировок на доступ к данным.
    Это какой же именно "вред" от блокировок?
    2 окт 13, 11:44    [14911202]     Ответить | Цитировать Сообщить модератору
     Re: Секционирование  [new]
    Гость333
    Member

    Откуда:
    Сообщений: 3683
    MedBrat
    - Выигрыш по "избежанию" блокировок будет?

    От блокировок какого вида и на каких ресурсах страдает ваша система?
    2 окт 13, 11:47    [14911228]     Ответить | Цитировать Сообщить модератору
     Re: Секционирование  [new]
    Критик
    Member

    Откуда: Москва / Калуга
    Сообщений: 35376
    Блог
    MedBrat,

    1) методы оптимизации зависят от вида нагрузки (чтение/запись)
    2) почитайте про snapshot isolation
    2 окт 13, 11:47    [14911230]     Ответить | Цитировать Сообщить модератору
     Re: Секционирование  [new]
    Гость333
    Member

    Откуда:
    Сообщений: 3683
    верно мыслите
    эскалация блокировок до уровня страницы обеспечена

    Хм, который раз уже вижу подобное утверждение.
    Эскалаций до уровня страницы никогда не бывает. Бывает только до уровня таблицы или секции, читайте BOL.
    2 окт 13, 11:50    [14911253]     Ответить | Цитировать Сообщить модератору
     Re: Секционирование  [new]
    MedBrat
    Member

    Откуда: Санкт-Петербург
    Сообщений: 348
    tpg,

    пример... идет учет накладных в больших кол-х через MS NAV. Остальные курят. Никак не вклиниться даже с самой мелкой операцией записи, что и правильно по сути. По жизни хотелось бы каким-то образом сделать так, чтоб система как-то дифференцировала объемы записываемых данных и давала тем у кого децл строчек записаться вперед. Как я понял, секционирование решит частично нашу проблему.
    2 окт 13, 11:55    [14911282]     Ответить | Цитировать Сообщить модератору
     Re: Секционирование  [new]
    Glory
    Member

    Откуда:
    Сообщений: 104751
    MedBrat
    Как я понял, секционирование решит частично нашу проблему.

    Вот откуда вы это поняли ?
    Если даже не знаете, почему именно "Остальные курят" ?
    2 окт 13, 12:06    [14911379]     Ответить | Цитировать Сообщить модератору
     Re: Секционирование  [new]
    MedBrat
    Member

    Откуда: Санкт-Петербург
    Сообщений: 348
    Glory,

    почему не знаю. в MS NAV приблудили отображение USER1 блокирует USER2. USER1 при этом ведет учет документов и ведется запись в несколько таблиц. Научите, как узнать почему курят, если я не прав.
    2 окт 13, 12:08    [14911403]     Ответить | Цитировать Сообщить модератору
     Re: Секционирование  [new]
    Glory
    Member

    Откуда:
    Сообщений: 104751
    MedBrat
    в MS NAV приблудили отображение USER1 блокирует USER2

    И какая разница из скольки секций будет состять таблица, если USER1 блокирует всю таблицу ?
    Начните с выяснения, что блокирует USER1. И почему так долго.
    2 окт 13, 12:11    [14911429]     Ответить | Цитировать Сообщить модератору
     Re: Секционирование  [new]
    Гость333
    Member

    Откуда:
    Сообщений: 3683
    MedBrat
    Научите, как узнать почему курят

    См. системные представления sys.dm_tran_locks, sys.dm_os_waiting_tasks.
    2 окт 13, 12:12    [14911443]     Ответить | Цитировать Сообщить модератору
     Re: Секционирование  [new]
    MedBrat
    Member

    Откуда: Санкт-Петербург
    Сообщений: 348
    Гость333
    MedBrat
    Научите, как узнать почему курят

    См. системные представления sys.dm_tran_locks, sys.dm_os_waiting_tasks.


    Спасибо! это уже аргумент. тут можно делать выводы.
    2 окт 13, 12:52    [14911757]     Ответить | Цитировать Сообщить модератору
     Re: Секционирование  [new]
    MedBrat
    Member

    Откуда: Санкт-Петербург
    Сообщений: 348
    верно мыслите
    MedBrat,

    конкурирующие транзакции можно разводить партишинингом. но следует помнить, что при использовании увеличивающихся на 1 ключей, в индексы, записи будут добавляться в крайний правый листовой блок - конкуренция и эскалация блокировок до уровня страницы обеспечена. можно пользовать partitioning_key+guid, тогда будет размазывать по партициям и в пределах партиции. но выставить нормальный fill_factor и pad_index, чтобы поменьше page split'ов было.


    Для особо одаренных можно какую-то ссылочку на материал. Никогда такого не делал, нужно прокачаться...
    2 окт 13, 12:54    [14911769]     Ответить | Цитировать Сообщить модератору
     Re: Секционирование  [new]
    partition
    Guest
    Гость333
    верно мыслите
    эскалация блокировок до уровня страницы обеспечена

    Хм, который раз уже вижу подобное утверждение.
    Эскалаций до уровня страницы никогда не бывает. Бывает только до уровня таблицы или секции, читайте BOL.


    Я думаю, подобное заблуждение вызвано неправильным пониманием значения термина "Эскалация", часто под эскалацией понимают не только укрупнение (n*key/rid -> tab) но и изначально выбираемые сервером блокировки с гранулярностью выше key/rid.
    2 окт 13, 13:34    [14912054]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
    Все форумы / Microsoft SQL Server Ответить