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

Question

Моя компания переходит на 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 разделов.будет запрошен для дат между 05.01.2010 и 20.06.2010.

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

Запрос 2

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

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

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

Ресурс:

• Видео: Демонстрационная таблица SQL Server 2008 Распределенная таблица Параллелизм (5 минут)
• MSDN: Секционированные таблицы и индексы
• MSDN: Проектирование разделов для управления подмножествами данных
• MSDN: Улучшения обработки запросов для секционированных таблиц и индексов
• MSDN: Word Doc: Стратегии секционированных таблиц и индексов с использованием SQL Server 2008 white paper

BarDev

Answer 1

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

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

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

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

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

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

нет

Нет

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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