Секционированная таблица SQL Server 2008 и параллелизм

Моя компания переходит на SQL Server 2008 R2. У нас есть таблица с тоннами архивных данных. Большинство запросов, использующих эту таблицу, используют значение DateTime в операторе where. Например:

Запрос 1

SELECT COUNT(*) 
FROM TableA 
WHERE 
     CreatedDate > '1/5/2010' 
     and CreatedDate < '6/20/2010'

Я предполагаю, что разделы создаются на CreatedDate, и каждый раздел распределен по нескольким дискам, у нас 8 процессоров, и в базе данных содержится 500 миллионов записей, которые равномерно распределены по датам с 01.01.2008 г. до 24.02.2011 (38 разделов). Эти данные также могут быть разделены на кварталы года или другие периоды времени, но давайте оставим предположения в месяцах.

В этом случае я полагаю, что будут использованы 8 процессоров, и только 6 разделов будут запрошены для дат с 5 января 2010 года по 20 июня 2010 года.

А что если я выполнил следующий запрос и мои предположения те же, что и выше?

Запрос 2

SELECT COUNT(*) 
FROM TableA 
WHERE State = 'Colorado'

Вопросы?
1. Будут ли запрошены все разделы? да
2. Будут ли все 8 процессоров использоваться для выполнения запроса? да
3. Будет ли производительность лучше, чем запросить таблицу, которая не разделена? да
4. Есть ли что-то еще, что я пропускаю?
5. Как поможет Индекс раздела?

Я отвечаю на первые 3 вопроса выше, основываясь на моих ограниченных знаниях SQL Server 2008 Partitioned Table & Parallelism. Но если мои ответы неверны, можете ли вы дать отзыв, почему я не прав?

Ресурс:

BarDev

Источник

3 ответа

Решение

Разбиение может увеличить производительность - я видел это много раз. Причиной создания разделов была и остается производительность, особенно для вставок. Вот пример из реального мира:

Насколько мы можем судить, у меня есть несколько таблиц в сети SAN с одним большим сигнальным диском. Администраторы SAN настаивают на том, что SAN знает все, поэтому не оптимизируют распределение данных. Как раздел может помочь? Факт: это сделал и делает.

Мы разбили несколько таблиц по одной схеме (FileID%200) с 200 разделами ALL на первичном. Какой смысл в этом, если единственная причина иметь схему разбиения - это "обмен"? Нет, но целью разделения является производительность. Видите ли, каждый из этих разделов имеет свою собственную схему подкачки. Я могу записать данные для всех сразу, и нет возможности тупика. Страницы не могут быть заблокированы, потому что каждый процесс записи имеет уникальный идентификатор, равный разделу. 200 разделов увеличили производительность в 2000 раз (факт), а взаимные блокировки снизились с 7500 в час до 3-4 в день. Это происходит по той простой причине, что эскалация блокировки страницы всегда происходит с большими объемами данных, а большие объемы OLTP-системы и блокировки страниц являются причиной тупиковых ситуаций. Секционирование, даже на одном и том же томе и файловой группе, размещает секционированные данные на разных страницах, и эскалация блокировки не имеет никакого эффекта, поскольку процессы не пытаются получить доступ к одним и тем же страницам.

Преимущество в выборе данных есть, но оно не так велико. Но, как правило, схема разбиения будет разработана с учетом цели БД. Держу пари, что Ремус разработал свою схему с учетом возрастающей нагрузки (например, ежедневных нагрузок), а не транзакционной обработки. Теперь, если часто выбирать строки с блокировкой (чтение зафиксировано), могут возникнуть взаимные блокировки, если процессы попытаются получить доступ к одной и той же странице одновременно.

Но Ремус прав: в вашем примере я не вижу никакой выгоды, на самом деле могут возникнуть некоторые накладные расходы при поиске строк в разных разделах.

Источник

Разбиение никогда не может улучшить производительность. Лучшее, на что вы можете надеяться, это иметь производительность на одном уровне с однораздельной таблицей. Обычно вы получаете регрессию, которая увеличивается с увеличением количества разделов. Для производительности вам нужны индексы, а не разделы. Разделы предназначены для операций управления данными: ETL, архивирование и т. Д. Некоторые утверждают, что устранение разделов является возможным приростом производительности, но для любого удаления разделение может дать размещение ключа индекса в том же столбце, что и столбец разделения, даст гораздо лучшие результаты.

Будут ли запрошены все разделы?

Этот запрос нуждается в индексе State, В противном случае выполняется сканирование таблицы, и выполняется сканирование всей таблицы. Сканирование таблицы по многораздельной таблице всегда выполняется медленнее, чем сканирование по однораздельной таблице того же размера. Сам индекс может быть выровнен по той же схеме разбиения, но ведущий ключ должен быть State,

Будут ли все 8 процессоров использоваться для выполнения запроса?

Параллелизм не имеет ничего общего с разделением, несмотря на распространенное неправильное представление об обратном. Как при сканировании с разделами, так и без разделов можно использовать параллельный оператор, это будет решение оптимизатора запросов.

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

нет

Как поможет индекс раздела?

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

Если вы смотрите на разделение, это должно быть потому, что вам нужно выполнить быстрые операции по переключению, чтобы удалить старые данные за период политики хранения или что-то подобное. Для производительности вам нужно смотреть на индексы, а не на разбиение.

Источник

Самый первый вопрос, который у меня есть, это если у вашей таблицы есть кластерный индекс. если нет, вы захотите один.

Также вам понадобится индекс покрытия для ваших запросов. Индексы покрытия

Если у вас много исторических данных, вы можете изучить процесс архивации, чтобы ускорить работу ваших приложений oltp.

Источник
Другие вопросы по тегам