Экономия энергии с помощью функции сжатия данных DB2 10.1 для Linux, UNIX и Windows

Сократите эксплуатационные расходы и сделайте свою базу данных "зеленой"

Функция сжатия данных IBM® DB2® для Linux®, UNIX® и Windows® позволяет хранить данные в компактной форме. У такого подхода два известных преимущества: он сокращает требуемое дисковое пространство и повышает производительность. В этой статье мы опишем пример, демонстрирующий третье преимущество: сокращение потребления электроэнергии на единицу работы. В результате сжатие данных снижает стоимость эксплуатации базы данных и делает ее "зеленой".

Андрей Миранский, инженер-программист, IBM

Фото автораД-р Андрей Миранский (Andriy Miranskyy) работает инженером-программистом в подразделении управления информацией Лаборатории программного обеспечения IBM в Торонто. Его научные и производственные интересы лежат в области понижения уровня риска, связанного с программным обеспечением, в особенности вопросов качества ПО, его совершенствования, требований к ПО, архитектуры ПО, управления рисками и "зелёных" ИТ. Защитил докторскую диссертацию по прикладной математике в университете Западного Онтарио. Имеет 15-летний опыт разработки программного обеспечения для управления информацией и фармацевтической промышленности. Также имеет многочисленные публикации и патенты в области разработки программного обеспечения.



Седеф Акинли Кожак, аспирант, Ryerson University

Фото автораСедеф Акинли Кожак (Sedef Akinli Kocak) ― аспирантка университета Райерсона по программе прикладной экологии. Ее научные интересы охватывают информационные технологии и экологическую устойчивость, устойчивое программное обеспечение, зеленые ИТ и разработку "зеленого" ПО. Окончила университет штата Мэн с ученой степенью магистра и Университет Анкары со степенью MBA. Контактный адрес: sedef.akinlikocak@ryerson.ca



Энцо Кьялини, старший технический специалист, IBM

Фото автораЭнцо Кьялини (Enzo Cialini) ― старший технический специалист отдела программного управления информацией IBM лаборатории IBM в Торонто. В настоящее время исполняет обязанности главного архитектора по обеспечению качества и отвечает за стратегию административного и технического тестирования DB2 LUW Engine (Warehouse и OLTP) и оперативного профилирования заказчиков. Работает в IBM с 1991 года и с 1992 года входит в группу разработки DB2. Имеет более чем 20-летний опыт разработки, тестирования и поддержки программного обеспечения. Активно взаимодействует с клиентами и работает на объектах в области внедрения OLTP- и Warehouse-систем, автор книги Руководство по обеспечению высокой готовности DB2, имеет многочисленные патенты и публикации в области DB2 и интеграции.



Басар Айше Бенер, профессор технических наук, Ryerson University

Фото автораД-р Айше Басар Бенер (Ayse Basar Bener) ― профессор в Факультета механики и промышленной техники Университете Райерсона. Ее научные интересы сосредоточены на построении интеллектуальных моделей для надежного принятия решений в условиях неопределенности. Опубликовала более 100 статей в журналах и трудах конференций. Получила докторскую степень по информационным системам в Лондонской школе экономики. Является членом организаций AAAI, IEEE и AIS.



24.05.2013

Введение

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

В последней версии DB2, версии 10.1, появился новый способ сжатия данных: адаптивное сжатие данных. Эта функция использует несколько методов сжатия, включая сжатие на уровне таблицы и на уровне страниц. (См. ссылку на раздел документации DB2, посвященный сжатию данных, в разделе Ресурсы.) Эти методы сжатия дают значительное сокращение занимаемого дискового пространства. Однако использование этой функции может привести к перегрузке ЦП операциями сжатия и распаковки данных.

Еще один положительный побочный эффект этой технологии ― ускорение решения задач с интенсивным вводом-выводом (несмотря на перегрузку ЦП). Чтение данных с диска в оперативную память для обработки ― одна из самых медленных операций базы данных. Хранение сжатых данных на диске приводит к меньшему количеству операций ввода-вывода, необходимых для чтения или записи одного и того же количества данных (по сравнению с несжатыми данными). Таким образом, время обработки запросов в задачах ввода-вывода (например, когда система простаивает в ожидании доступа к диску) может быть значительно сокращено. Более того, процессы DB2 записывают данные в буфер в оперативной памяти в сжатой форме, тем самым уменьшая количество потребляемой памяти по сравнению с несжатыми данными. Это ведет к немедленному увеличению объема памяти, доступной для базы данных, без необходимости увеличивать объем физической памяти, что может еще больше повысить производительность базы данных при обработке запросов и других операций.

Сжатие можно включить при создании таблицы с помощью параметра COMPRESS YES. Кроме того, администратор может включить сжатие существующей таблицы T, выполнив команду SQL ALTER TABLE T COMPRESS YES. Дополнительные сведения об использовании функции сжатия данных приведены в статье developerWorks Оптимизация хранения данных в DB2 10 с помощью глубокого сжатия (EN).

Каким же образом функция сжатия влияет на энергопотребление для данной рабочей нагрузки? Чтобы ответить на этот вопрос, мы проанализировали общее энергопотребление системы при обработке определенной нагрузки в двух разных сценариях:

  • без сжатия данных и
  • с адаптивным сжатием данных.

Мы обнаружили, что функция сжатия увеличивает среднее энергопотребление на единицу времени, но уменьшает среднее энергопотребление на оператор благодаря значительному сокращению времени выполнения. В нашем исследовании рабочей нагрузки это привело к снижению энергопотребления на единицу работы на 34%. Ниже приводится подробное описание этого исследования.

Рабочая нагрузка и установка

Мы измерили влияние сжатия данных на количество ресурсов (время и электроэнергия), необходимых для обработки определенной нагрузки, в двух режимах работы:

  • без сжатия данных и
  • с адаптивным сжатием данных.

Нашей рабочей нагрузкой был стандартный тест TPC-H. Он разработан Советом по оценке производительности обработки транзакций и используется в качестве отраслевого стандарта для измерения производительности баз данных. Рабочая нагрузка состоит из набора специальных бизнес-ориентированных запросов. База данных имеет широкий общеотраслевой профиль. См. Спецификацию TPC-H.

Используя инструменты, прилагаемые к рабочей нагрузке, мы заполнили базу данных 1 ГБ исходных данных и сгенерировали 240 уникальных запросов к этому набору данных. Запросы выполнялись последовательно циклами приблизительно по два часа на ноутбуке Lenovo ThinkPad T60 с 3 ГБ оперативной памяти. Двухчасовой интервал был выбран для уменьшения ошибок измерения, связанных с низкой точностью (0,01 кВт-час) счетчика электроэнергии (UPM EM100). Примечание. Некоторые операторы занимают значительное время. Например, запрос, запущенный в 1:59, может занять 5 минут и закончиться в 2:04.

Мы подсчитали количество операторов, выполняемых за данный интервал времени, и измерили количество энергии, потребляемой DB2 в двух конфигурациях: без сжатия и с адаптивным сжатием данных.

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


Результаты тестов

Результаты измерений приведены в Таблице 1. Во-первых, обратите внимание на среднее время выполнения одного оператора. Как и следовало ожидать, наиболее медленная конфигурация базы данных ― та, в которой функция сжатия отключена. Мы рассматривали эту конфигурацию в качестве базовой. Сжатие данных уменьшает размер таблиц на 61% и приводит к повышению производительности по сравнению с базовой конфигурацией на 97%.

Функция сжатия увеличивает общее энергопотребление на 29% (по сравнению с базовой конфигурацией). Однако энергопотребление на единицу работы уменьшилось на 34% благодаря увеличению пропускной способности.

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

Таблица 1. Характеристики рабочей нагрузки и базы данных с использованием функции адаптивного сжатия и без нее (± обозначает относительную стандартную погрешность)
Режим работы базы данныхСреднее число операторов в часСреднее значение энергопотребления (кВт-час)Потребление дискового пространства (МБ)Коэффициент сжатия (см. примечание 1)Ватт на оператор в секунду (см. примечание 2)
Без сжатия415 ± 1,8%0,035 ± 0,5%1168,2100%302
Адаптивное сжатие814 ± 4,0%0,045 ± 0,0%455,661%199

Примечание 1. Коэффициент сжатия определяется как 1 - размер сжатых данных / размер несжатых данных.

Примечание 2. Эта характеристика эквивалентна характеристике TPC "потребляемая мощность на единицу производительности" (power per performance throughput), измеряемой в ваттах на транзакцию в секунду (Вт/tps), и рассчитывается как отношение потребляемой энергии к выполненной работе. См. документ TPC Energy Specification.


Границы достоверности

Это исследование показывает, что метод может успешно применяться для конкретного набора данных. Следуя парадигме "репрезентативного" или "типичного" случая, можно предположить, что тот же подход может быть экстраполирован и на другие продукты.

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

Для производственной системы величина экономии будет варьироваться в зависимости от настройки системы и рабочей нагрузки. В большой системе экономия должна быть заметнее. Например, если без сжатия для хранения данных системе требуется 100 жестких дисков, а со сжатием ― 50, то отключив неиспользуемые жесткие диски, можно сразу же сэкономить 50% энергии, потребляемой системой хранения данных.


Заключение

Наше исследование показывает, что помимо экономии дискового пространства и улучшения производительности, функция адаптивного сжатия DB2 позволяет сократить потребление энергии на единицу выполненной работы. Это приводит к сокращению эксплуатационных расходов и делает базу данных "зеленой".

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=931262
ArticleTitle=Экономия энергии с помощью функции сжатия данных DB2 10.1 для Linux, UNIX и Windows
publish-date=05242013