Производительность запросов к хранилищу данных SQL Server 2008 - Сжатие данных
ОГЛАВЛЕНИЕ
Сжатие данных
По мере того, как бизнес-аналитика становится популярной, предприятия добавляют все больше данных для анализа в свои хранилища. Результат – экспоненциальный рост объема управляемых данных. В 1995 первое исследование размера баз данных корпорацией Winter Corporation позволило выяснить, что крупнейшая система в мире содежит терабайт данных. Спустя десять лет крупнейшая база данных была уже в 100 раз больше. Впечатляет то, что размер хранилищ данных утраивается каждые два года. Это ставит новые вопросы об управлении такими большими объемами данных и обеспечении приемлимогой скорости выполнения запросов к хранилищам данных. Эти запросы обычно сложные, включающие много соединений и агрегатов, им нужен доступ к большим объемам данных. И многие запросы в рабочей нагрузке зависят от ввода-вывода.
Эту проблему помогает решить собственное сжатие данных. В SQL Server 2005 SP2 был включен новый формат хранения переменной длины под названием vardecimal, для десятичных и числовых данных. Этот новый формат хранения может значительно уменьшить размер баз данных. Выигрыш в объеме может, в свою очередь, двумя способами улучшить производительность запросов, зависимых от ввода-вывода. Во-первых, нужно считывать меньше страниц, а во-вторых, так как данные хранятся в буферном пуле сжатыми, увеличивается ожидаемое время жизни страницы (иначе говоря, увеличивается вероятность, что нужная страница окажется в буфере). Конечно, выгода в объеме от сжатия данных приводит к нагрузке на ЦП в процессе сжатия и распаковки данных.
SQL Server 2008 использует формат хранения vardecimal, обеспечивая два вида сжатия: сжатие ROW и PAGE. Сжатие ROW расширяет формат хранения vardecimal за счет хранения всех типов данных фиксированной длины в формате хранения переменной длины.
Некоторые примеры типов данных фиксированной длины -- integer, char и свободные типы данных. Несмотря на то, что SQL Server хранит эти типы данных в формате переменной длины, их семантика не меняется (с точки зрения приложения, тип данных продолжает быть фиксированной длины). Это значит, что можно воспользоваться преимуществами сжатия данных, не изменяя свои приложения.
Сжатие PAGE уменьшает изыбточность данных в столбцах в одной или более строке на данной странице. Оно использует собственную реализацию алгоритма LZ78 (Лемпеля-Зива), сохраняя избыточные данные единожды на странице, ссылаясь затем на них из многих столбцов. Заметьте, что если вы используете сжатие PAGE, сжатие ROW тоже используется.
Сжатие ROW и PAGE можно включить для таблицы, индекса или одной и более секций секционированных таблиц и индексов. Это дает полную гибкость выбора таблиц, индексов и секций для сжатия, позволяя найти баланс между выигрышем в объеме и нагрузкой на ЦП. На рис. 7 это проиллюстрировано с помощью таблицы продаж, секционированной различными способами с выровненными индексами.
Рис 7 Секционированная таблица с различными настройками сжатия
Каждая секция представляет квартал, последний квартал – Oct-Dec. Предположим, что первые две секции используются редко, третья – средне, а последняя – наиболее активно. В этом случае можно включить сжатие PAGE для первых двух секций, чтобы получит максимальную экономию места, мнимально затронув производительность рабочей нагрузки, сжатие ROW для третьей секции и не сжимать последнюю.
Сжатие можно включить в автономном или оперативном режиме с помощью выражений Alter Table или Alter Index языка DDL. SQL Server также позволяет оценить экономию места. Получаемая экономия места будет зависеть от распределения данных и схемы сжимаемого объекта.
На основании результатов тестов баз данных многих клиентов, можно предположить, что большинство клиентов смогут уменьшить размер базы данных на 50-64 процентов и зачительно увеличить производительность запросов, зависимых от ввода-вывода. Однако, оценка производительности запросов, свзанных с ЦП, посложнее и зависит от сложности запроса. В SQL Server нагрузка от распаковки возникает только при доступе к индексу или таблицам. Если относительная нагрузка на ЦП операторов сканирования невелика по сравнению с общей нагрузкой запроса на ЦП, как обычно бывает с хранилищами данных, влияние на использование ЦП не должно превышать 20-30 процентов.