Сжатие данных в целях экономии места и ускорения работы Oracle

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

При решении проблем с дисковым пространством, появившаяся в Oracle 9i Release 2 возможность сжатия таблицы может существенно сократить объем дискового пространства, используемого таблицами базы данных и, в некоторых случаях, повысить производительность запросов.

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

Как это реализовано

Возможность сжатия таблиц в Oracle9i Release 2 реализуется путем удаления дублирующихся значений данных из таблиц базы. Сжатие выполняется на уровне блоков базы данных. Когда таблица определена как сжатая, сервер резервирует место в каждом блоке базы данных для хранения одной копии данных, встречающихся в этом блоке в нескольких местах. Это зарезервированное место называют таблицей символов (symbol table). Помеченные для сжатия данные хранятся только в таблице символов, а не в строках данных. При появлении в строке данных, помеченных для сжатия, в строке, вместо самих данных, запоминается указатель на соответствующие данные в таблице символов. Экономия места достигается за счет удаления избыточных копий значений данных в таблице.

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

Как создать сжатую таблицу

Для создания сжатой таблицы используется ключевое слово COMPRESS в операторе CREATE TABLE. Ключевое слово COMPRESS требует от сервера Oracle, по возможности, хранить строки таблицы в сжатом виде. Ниже представлен пример оператора CREATE TABLE COMPRESS:

CREATE TABLE SALES_HISTORY_COMP (
PART_ID VARCHAR2(50) NOT NULL,
STORE_ID VARCHAR2(50) NOT NULL,
SALE_DATE DATE NOT NULL,
QUANTITY NUMBER(10,2) NOT NULL
)
COMPRESS;

Можно также использовать оператор ALTER TABLE для изменения атрибута сжатия существующей таблицы, как в следующем примере:

ALTER TABLE SALES_HISTORY_COMP COMPRESS;

Чтобы узнать, использовалось ли ключевое слово COMPRESS в определении таблицы, выполните запрос к представлению USER_TABLES словаря данных и проверьте значение столбца COMPRESSION, как в следующем примере:

SELECT TABLE_NAME, COMPRESSION FROM USER_TABLES;

TABLE_NAME COMPRESSION
------------------ -----------
SALES_HISTORY DISABLED
SALES_HISTORY_COMP ENABLED

Атрибут COMPRESS также может быть задан на уровне табличного пространства, как в момент его создания (с помощью оператора CREATE TABLESPACE), так и в дальнейшем (с помощью оператора ALTER TABLESPACE). Атрибут COMPRESS наследуется аналогично параметрам хранения. При создании таблицы в табличном пространстве наследуется атрибут COMPRESS этого табличного пространства. Чтобы определить, задан ли для табличного пространства атрибут COMPRESS, выполните запрос к представлению DBA_TABLESPACES словаря данных и проверьте значение столбца DEF_TAB_COMPRESSION, как в следующем примере:

SELECT TABLESPACE_NAME, 
DEF_TAB_COMPRESSION 
FROM DBA_TABLESPACES;

TABLESPACE_NAME DEF_TAB_COMPRESSION
--------------- -------------------
DATA_TS_01 DISABLED
INDEX_TS_01 DISABLED

Как и следовало ожидать, вы можете сжимать или не сжимать таблицу в табличном пространстве, независимо от значения COMPRESS, заданного на уровне табличного пространства.

Загрузка данных в сжатую таблицу

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

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

• Непосредственная загрузка SQL*Loader
• Последовательные вставки INSERT с подсказкой APPEND
• Параллельный INSERT
• CREATE TABLE ... AS SELECT

Метод непосредственной загрузки SQL*Loader - наиболее удобный способ загрузки данных в таблицу, если данные доступны в текстовом файле. Пример представлен ниже:

$sqlldr sanjay/sanjay@proddb control=sales_history.ctl direct=true 

Если данные доступны в промежуточной (staging) таблице, можно использовать последовательные операторы INSERT с подсказкой APPEND или параллельный INSERT.

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

INSERT /*+ APPEND */ 
INTO SALES_HISTORY_COMP
SELECT * FROM SALES_HISTORY;

Для переноса данных из промежуточной таблицы в сжатую можно также использовать параллельный INSERT, как показано ниже:

ALTER SESSION ENABLE PARALLEL DML;
INSERT /*+PARALLEL(SALES_HISTORY_COMP,4)*/ 
INTO SALES_HISTORY_COMP
SELECT * FROM SALES_HISTORY;

Учтите, что при использовании параллельного INSERT надо сначала включить распараллеливание операторов DML в сеансе с помощью команды ALTER SESSION ENABLE PARALLEL DML.

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

Можно также использовать оператор CREATE TABLE ... AS SELECT для создания сжатой таблицы и вставки в нее данных за один шаг. Вот пример:

CREATE TABLE SALES_HISTORY_COMP
COMPRESS
AS SELECT * FROM SALES_HISTORY;

Если не использовать соответствующий метод загрузки или вставки данных, данные в таблице окажутся не сжатыми, хотя для таблицы и определен атрибут COMPRESS. Например, если использовать обычную загрузку (conventional path) с помощью SQL*Loader или обычные операторы INSERT, данные не будут сжиматься.

Когда использовать сжатие таблиц

Применяемый сервером Oracle алгоритм принятия решения о том, сжимать данные таблицы или не сжимать, приводит к определенным выводам об особенностях приложений, больше всего подходящих для сжатия таблиц. Как было описано выше, данные в таблице с атрибутом COMPRESS сжимаются только при непосредственной загрузке или при вставке с использованием подсказки append и распараллеливанием. Данные, вставленные обычными операторами INSERT, останутся не сжатыми.

В системах оперативной обработки транзакций (online transaction processing - OLTP) данные обычно вставляются обычными операторами INSERT. В результате, от использования сжатия для соответствующих таблиц большого преимущества не будет. Сжатие таблиц больше всего подходит для таблиц только для чтения, данные в которые загружаются один раз, а читаются - многократно. Таблицы, используемые при организации хранилищ данных, например, прекрасно подходят для сжатия.

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

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

Сжатие существующей не сжатой таблицы

Уже существующую не сжатую таблицу можно сжать с помощью оператора ALTER TABLE ... MOVE. Например, не сжатую таблицу SALES_HISTORY_TEMP можно сжать с помощью следующего оператора:

ALTER TABLE SALES_HISTORY_TEMP 
MOVE COMPRESS;

Оператор ALTER TABLE ... MOVE можно использовать и для отмены сжатия таблицы, как в следующем примере:

ALTER TABLE SALES_HISTORY_TEMP 
MOVE NOCOMPRESS;

Учтите, что оператор ALTER TABLE ... MOVE устанавливает МОНОПОЛЬНУЮ блокировку таблицы, что предотвращает выполнение любых операторов DML с таблицей на время выполнения этого оператора. Этой потенциальной проблемы можно избежать за счет использования оперативного переопределения таблицы (online table redefinition), появившегося в Oracle9i.

Сжатие материализованного представления

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

CREATE MATERIALIZED VIEW MV_SALES_COMP COMPRESS AS SELECT P.PART_NAME, H.STORE_ID,
H.SALE_DATE, H.QUANTITY FROM SALES_HISTORY H, PARTS P WHERE P.PART_ID = H.PART_ID; 

Материализованные представления на основе соединений нескольких таблиц обычно хорошо поддаются сжатию, поскольку в них часто встречаются повторяющиеся компоненты данных. Атрибут сжатия для материализованного представления можно изменить с помощью оператора ALTER MATERIALIZED VIEW. Следующий оператор показывает, как сжать существующее не сжатое материализованное представление:

ALTER MATERIALIZED VIEW MV_SALES COMPRESS;

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

Сжатие секционированной таблицы1

Вариантов использовании сжатия для секционированных таблиц много. Сжатие можно применять либо на уровне таблицы, либо на уровне секции. Например, оператор CREATE TABLE в Листинге 1 создает таблицу из четырех секций. Поскольку COMPRESS задается на уровне таблицы, все четыре секции будут сжиматься.

Поскольку сжатие может быть задано на уровне секции, можно некоторые секции сжать, а другие оставить не сжатыми. Пример в Листинге 2 демонстрирует, как задать сжатие на уровне секции.

В Листинге 2 две секции таблицы (SALES_Q1_03 и SALES_Q2_03) сжаты, а остальные две остаются не сжатыми. Учтите, что атрибуты сжатия, заданные на уровне секции, переопределяют атрибуты, заданные для этой же секции на уровне таблицы. Если атрибут сжатия для секции не задан, эта секция наследует значение из определения на уровне таблицы. В Листинге 2, поскольку атрибуты сжатия для секций SALES_Q3_03 и SALES_Q4_03 не указаны, эти две секции наследуют значение из определения таблицы (которое, в данном случае, стандартно - NOCOMPRESS).

Секционированные таблицы обеспечивают совместно со сжатием одно уникальное преимущество. Один из полезных способов секционировать таблицы - поместить подлежащие изменению (вставке, обновлению и удалению) данные в отдельные секции, а данные только для чтения вынести в другие. Например, в определении таблицы в Листинге 2 данные о продажах секционированы по значению столбца SALE_DATE, так что хронологическая информация о продажах в каждом квартале хранится в отдельной секции. В этом примере данные о продажах за первый (Q1) и второй (Q2) кварталы 2003 года не могут быть изменены, поэтому они помещены в сжатые секции SALES_Q1_03 и SALES_Q2_03. Данные о продажах за третий (Q3) и четвертый (Q4) кварталы все еще могут меняться, поэтому соответствующие секции, SALES_Q3_03 и SALES_Q4_03, оставлены не сжатыми.

Если в конце третьего квартала 2003 года данные в секции SALES_Q3_03 становятся доступными только для чтения, можно сжать эту секцию с помощью оператора ALTER TABLE ... MOVE PARTITION, как показано ниже:

ALTER TABLE SALES_PART_COMP 
MOVE PARTITION SALES_Q3_03 COMPRESS;

Чтобы узнать, какие секции таблицы сжаты, можно выполнить запрос к представлению USER_TAB_PARTITIONS словаря данных, как в следующем примере:

SELECT TABLE_NAME, PARTITION_NAME, 
COMPRESSION
FROM USER_TAB_PARTITIONS;

TABLE_NAME PARTITION_NAME COMPRESSION
---------------------------- -----------
SALES_PART_COMP SALES_Q4_03 DISABLED
SALES_PART_COMP SALES_Q1_03 ENABLED
SALES_PART_COMP SALES_Q2_03 ENABLED
SALES_PART_COMP SALES_Q3_03 ENABLED

Оценка преимуществ

Основной причиной использования сжатия таблицы является экономия дискового пространства. Таблица в сжатом виде обычно занимает меньше места. Чтобы проиллюстрировать это утверждение, рассмотрим следующий с двумя таблицами: одна не сжатая (SALES_HISTORY), а другая - сжатая (SALES_HISTORY_COMP). В обе эти таблицы данные были загружены с помощью непосредственной загрузки утилитой SQL*Loader из текстового файла, содержащего два миллиона строк. После выполнения обеих загрузок оказалось, что сжатая таблица занимает на диске почти вдвое меньше места, чем не сжатая. Анализ представлен в Листинге 3.

Тот факт, что для хранения сжатой таблицы надо меньше блоков, приводит к экономии дискового пространства, но уменьшение количества блоков может приводить и к повышению производительности. Запросы к сжатой таблице в среде с ограниченной производительностью ввода-вывода часто будут выполняться быстрее, поскольку требуют прочтения меньшего количества блоков. Чтобы проиллюстрировать это утверждение, я выполнил запрос к сжатой и не сжатой таблице и проанализировал результаты SQLTRACE/TKPROF. Эти результаты представлены в Листинге 4.

Отчет SQLTRACE/TKPROF показывает, что мой запрос к сжатой таблице потребовал меньше операций физического и логического ввода-вывода, чем аналогичный запрос к не сжатой таблице, и, как следствие, выполняется быстрее.

Снижение производительности при загрузке

Поскольку сжатие таблицы выполняется при массовой загрузке, операции загрузки требуют дополнительной обработки - надо выполнять дополнительные действия. Чтобы измерить влияние сжатия на производительность, я выполнил тест, в котором загружал один миллион строк (с помощью непосредственной загрузки утилитой SQL*Loader) в две идентичных таблицы: со сжатием и без сжатия. В Таблице 1 представлены результаты, взятые из журнальных файлов SQL*Loader и показывающие, сколько времени потребовалось для загрузки данных в каждую из таблиц.

Таблица 1: Сравнение времени загрузки данных для сжатой и не сжатой таблиц

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

Заключение

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