Сегодня предлагаем обсудить сжатие данных в Oracle.
 
Ситуация: один наш крупный клиент в сфере телекома стремится нарастить абонентскую базу, поощряет потребление услуг и рост трафика. Это позволяет развиваться компании в целом и каждой её системе в отдельности, включая нашу систему взаиморасчётов с партнёрами — Partner Relationships Managment.

Проблема: регулярный прирост информации в БД на 0.6 TБ в месяц превращается в 7.2 TБ в год. При этом востребованной для изменений является информация только за последние два-три месяца. Остальные данные накапливаются и хранятся для отчётности. При таком подходе база разрастается очень быстро, а каждый SSD системы хранения данных становится на вес золота. К тому же необходимо поддерживать согласованность резервной и тестовой БД. 

Есть два выхода: закидывать в базы, как «в топку», бесконечное количество дисков, либо оптимизировать хранение информации. Мы выбрали второе.

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

Интро: почему нам надо сжимать данные

Каждый месяц после расчёта клиентских начислений в мобильной, фиксированной связи и интерконнекте (системе расчетов между операторами), мы проводим свой биллинг для определения вознаграждения дилерам и агентам, которые работают с оператором. Для этого выгружаем из биллинговой системы используемую абонентами НСИ, агрегированные начисления клиентов за месяц, информацию о потреблённых услугах и подключенных пакетах, данные о регистрации абонентов в точках продаж.

За 10 лет работы системы количество данных могло бы стать неприемлемо большим, более 80 ТБ (7,2 ТБ в год на 10 лет, плюс технологические данные и результаты расчётов). По факту на март 2024 г. имеем 41 TБ. Чтобы понять, как менялся объем хранилища за весь период, рассмотрим график 1. На нем приведена наглядная статистика количества данных с марта 2019 года по март 2024 года за каждый месяц в терабайтах.

На момент начала сбора статистики в базе данных было занято 32 ТБ и за 5 лет это значение выросло до 41 ТБ Такая математика не совпадает с заявленным мною ранее приростом 7.2 ТБ в год. И на то есть причины:

1. В 2019 и 2022 годах проводились активности по удалению старых, неактуальных данных и по оптимизации занимаемого пространства. В эти периоды график снижается.

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

Так как данные моложе 12 месяцев ещё не сжимались, рассмотрим меньший поздний период за последний год — с марта 2023 по март 2024.

За 2023-2024 гг. наблюдается линейный прирост занимаемого места, и субпартиции за этот период ещё не архивировались. На  основании этих данных получаем средний ежемесячный актуальный прирост 0.57 ТБ. Это значение сопоставимо со средним значением суммы субпартиций для каждого месяца за последний год — 0.414 ТБ.

Остальные данные (из 0,57 ТБ) добавляются инкрементально в непартиционированные таблицы, поэтому в статистику в следующей таблице не попадают. Статистика размера субпартиций за март 2023 — март 2024 года:

Для сравнения рассмотрим график прироста занимаемого места за ранний период с февраля 2020 года по апрель 2022 года.

Для этого периода уже работает функционал сжатия старых данных. Благодаря чему среднее значение ежемесячного прироста данных за период со сжатием получилось 0.38 ТБ против 0.57 ТБ для периода, когда архивирование ещё не проводилось. Получаем снижение ежемесячного прироста занимаемого места в 1.5 раза, что подтверждает эффективность применяемого метода сжатия старых субпартиций. Давайте рассмотрим функционал партиционирования и архивирования Oracle, который помог нам добиться такого результата.

Что мы сделали, чтобы остановить стремительный рост БД

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

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

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

У нас реализовано LIST партиционирование по списку значений и RANGE субпартиционирование по дате события, а именно по месяцу. В этой статье буду рассказывать только про деление субпартиций по месяцам.

Теперь поговорим про сжатие

Возникает вопрос, если сжатые таблицы не отличаются по способам работы с ними от обычных — почему бы не применить компресс (сжатие) сразу ко всей таблице? Зачем возиться с партиционированием?
 Для ответа давайте разберём, как работает сжатие данных в Oracle.

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

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

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

Сжатие бывает трёх видов:

1. Basic Table Compression — высокий уровень сжатия, низкие накладные расходы CPU. Возможно сжатие только при direct-path загрузке (INSERT /*+ APPEND */ INTO ... SELECT ... или CREATE TABLE ... AS SELECT... или через SQL Loader с директивой DIRECT=TRUE). Обновление basic-сжатых строк вызывает немедленную распаковку и возврат к хранению в обычном строчном виде. Поэтому такой вариант неоптимален, если сжатые данные будут подвержены частому и массовому изменению.

2. Advanced Row Compression — высокий уровень сжатия, низкие накладные расходы CPU, поддерживает сжатие «на лету» при OLTP-операциях (например, INSERT INTO x VALUES ...).  Это реализуется путем отсрочки сжатия до тех пор, пока в блоке не будет достаточно данных, чтобы их стоило компресссировать. Такой метод может сжимать строки в блоке, которые были вставлены по отдельности в разных сеансах и в разное время. Степень сжатия немного хуже или сопоставима со сжатием basic. Но главный недостаток - опция расширенного сжатия (Advanced Compression Option) приобретается у компании Oracle за дополнительную плату.

3. Hybrid Columnar Compression (HCC) — этот вариант подразделяется на Warehouse compression и Archive compression, для которых уровень сжатия и затраты на CPU зависят от выбранного уровня LOW или HIGH.
    HCC позволяет сжать таблицу в 10-50 раз! Такой результат достигается благодаря тому, что данные в таблицах с гибридным сжатием хранятся с объединением по столбцам, а не по строкам. Это позволяет оптимизировать сжатие и минимизировать дубли:

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

Для типов Basic, Warehouse и Archive Compression сжатие данных будет применяться при первом включении для субпартиции и при последующих вставках (изменениях), но только для вставляемых пачек bulk, или массивов array.

В базах системы Nexign Partner Relationships Managment мы применяем Basic compression — это обсуловлено логикой работы с данными. В начале каждого месяца нарезаются субпартиции для хранения данных нового периода. После биллинга (мобильных абонентов и клиентов фиксированной связи) свежесозданные партиции разово наполняются данными и хранятся так год, после чего к ним применяется сжатие.

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

В каждую субпартицию данные загружаются массово и один раз в первые дни месяца, после чего редко претерпевают изменения. В таком случае при отсутствии многочисленных и постоянных DML-операций (insert, update, merge - на которые не действует онлайн-сжатие), вариант basic compression является самым подходящим. Advanced требует дополнительных денежных затрат, а Hybrid — бóльших железных мощностей и времени на выполнение.

Как работает сжатие данных в Nexign

Как я отметил ранее, мы сжимаем новые данные не сразу, как они появляются, а только спустя год использования. Я настроил автоматический запуск процессов сжатия на середину каждого месяца, когда нагрузка от ежемесячных расчётов уже прошла (а жажда приключений ещё нет). Алгоритм выглядит так:

1. По заранее подготовленному списку таблиц строится курсор, выбирающий субпартиции, хранящие данные с глубиной более 12 месяцев. 

2. В цикле по результирующему набору курсора отключаются bitmap индексы, если такие есть для таблицы.

3. Выполняется сжатие субпартиции в несколько параллелей (в 8, если это кому-то интересно).

4. Пересобирается индекс для обработанной партиции.

5. Пересобирается глобальный индекс уровня всей таблицы.

Немного обзорной статистики: в нашем случае на анализ и сжатие субпартиции, хранящей 78 млн. строк, 15 гб. данных, Oracle в 8 параллелей тратит 2 минуты. Всего ежемесячно мы обрабатываем до 1400 субпартиций разной степени наполненности и пересобираем столько же их индексов.

Благодаря тому, что процессы работают в 8 потоков по 8 параллелей, эти работы укладываются в тех. окно — 2 часа в ночное время. То есть работы проводятся незаметно для бизнес-пользователей.

Сжатие партиций и субпартиций

Сжатие данных может быть применимо как для таблиц в целом, так и к отдельным её партициям и субпартициям. Выполняется всё простой командой (в зависимости от типа партиционирования):

Для оптимального использования мощностей БД можно добавить параллельности parallel N. Также может потребоваться перенести старые данные в отдельное табличное пространство. Тогда дописываем в команду move tablespace TABLESPACE_NAME. К примеру, такое архивное ТП можно физически разместить на отдельных более дешёвых дисках СХД.

Сжатие индексов

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

Важно отметить особенность работы с bitmap-индексами. Перед сжатием их необходимо выключить, а после компресса — пересобрать.

Такой вариант допустим, если наш индекс един и неделим. В случае если индекс партиционирован — перестраивать необходимо каждую его минимальную часть.

Также Oracle позволяет сжимать отдельные столбцы в составных индексах. Но это уже совсем другая история.

Подводим итоги

В разных продуктах для разных вариантов использования баз данных можно подобрать свой тип сжатия: Basic Table Compression, Advanced Row Compression, Hybrid Columnar Compression (HCC). Архивирование особенно удобно использовать в паре с разделением таблиц на партиции и субпартиции.

Функционал архивирования в Oracle позволяет значительно оптимизировать хранимые массивы данных. В нашем случае удалось снизить ежемесячный прирост в 1.5 раза — с 0.6 ТБ до 0.38 ТБ. Считаю, что для базы в 40 ТБ (а их у нас три) — это хороший результат. Он позволит сэкономить на закупке очередных СХД.

 Надеюсь, мой опыт поможет оптимизировать хранение данных и в ваших системах!