Секционированные таблицы и индексы SQL Server 2005 - <font>Для чего нужно секционирование?</font>

Для чего нужно секционирование?

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

Так что же представляет собой большая таблица? VLDB (Very Large Database) принято называть базы данных, совокупный размер которых измеряется сотнями гигабайт, или даже терабайтами; однако данный термин никак не определяет индивидуальные размеры таблиц. Большая таблица - это такая таблица, показатели производительности или временные затраты на обслуживание которой выходят за допустимые рамки. Кроме того, таблицу можно считать большой, если действия, производимые одним пользователем, оказывают значительное влияние на другого пользователя, или если операции обслуживания базы данных влияют на возможности остальных пользователей. Это приводит к ограничению доступности базы данных. Ведь даже притом, что сервер продолжает оставаться доступным, как можно считать Вашу базу данных доступной, когда рабочие характеристики таблицы продаж значительно ухудшились, либо таблица вовсе недоступна в течение всего периода текущего обслуживания базы данных по 2 часа в день, в неделю, или пусть даже в месяц? В некоторых случаях регулярный простой все же допустим, но чаще всего простоя можно избежать или минимизировать за счет улучшения проектирования.

Таблицу, модель доступа к которой изменяется, можно также считать большой, когда подмножества (или диапазоны) строк этой таблицы имеют разные модели использования. И хотя модели использования не обязательно должны изменяться (и это вовсе не является требованием секционирования), когда модели использования все же меняются, тогда могут быть получены дополнительные преимущества от секционирования. С точки зрения продаж, данные текущего месяца обычно используются для чтения/записи (read-write), в то время как данные предыдущих месяцев (и часто большая часть таблицы) - только для чтения (read-only). Если в больших таблицах использование данных изменяется, либо накладные расходы на обслуживание огромны, то это может ограничить способность таблицы отвечать на различные пользовательские запросы, в свою очередь, ограничивая и доступность и масштабируемость. Кроме того, особенно когда большие массивы данных используются по-разному, операции обслуживания могут отказаться от планового обслуживания статичных данных. Обслуживание данных, которые в этом вовсе не нуждаются - слишком дорогое удовольствие. Излишние затраты могут отразиться на производительности, блокировках, резервном копировании (дисковом пространстве, времени и эксплуатационных характеристиках), а так же отрицательно воздействовать на общую масштабируемость сервера.
Кроме того, в многопроцессорных системах разделение больших таблиц приведет к улучшению производительности за счет параллелизма. Крупномасштабные операции над чрезвычайно большими наборами данных (в миллионы строк) могут извлечь выгоду из параллельной обработки независимых подмножеств данных. В качестве простого примера улучшения производительности при использовании секционирования может выступать агрегирование (группировка) в предыдущих версиях сервера. Например, вместо того, чтобы группировать данные в одной большой таблице, SQL Server может группировать их в нескольких секциях независимо друг от друга, и затем объединить агрегаты. В SQL Server 2005, объединения могут извлекать данные непосредственно из секций; SQL Server 2000, поддерживающий параллельные объединения наборов данных, все же должен был создавать эти наборы данных на лету. В SQL Server 2005, связанные таблицы (к примеру, Order и OrderDetails), которые разделены по одному и тому же ключу секционирования и одной и той же функции секционирования, называются выровненными. Если оптимизатор SQL Server 2005 обнаруживает, что объединяются две секционированные и выровненные таблицы, он может предпочесть объединить сначала данные, располагающиеся в одних и тех же секциях, а затем объединить результаты. Это позволяет SQL Server 2005 более эффективно использовать многопроцессорные системы.

Итак, чем же может помочь секционирование? Там, где таблицы и индексы становятся слишком большими, секционирование может помочь, расщепляя большие массивы данных на меньшие, более управляемые "куски" (т.е. секции). Тип секционирования, описанного в этой статье, называют горизонтальным секционированием. При горизонтальном секционировании большие "куски" строк сохраняются в нескольких отдельных секциях. Архитектура секционированных данных выбирается, настраивается и управляется согласно вашим потребностям. Секционирование в SQL Server 2005 позволяет вам разделять ваши таблицы, основанные на индивидуальных моделях использования данных, задавая ограниченные диапазоны. И наконец, SQL Server 2005 предоставляет большое число настроек (опций) для управления секционированными таблицами и индексами, добавляя дополнительные функции, спроектированные специально для новой концепции.