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

Реляционные базы данных обычно используют строковый тип хранения. SAP HANA использует как строковый так и колоночный тип хранения информации. При этом, в процессе создания таблицы без явного указания типа, в БД будет создана таблица с типом COLUMN. В SAP HANA эти два типа таблиц имеют большие отличия с точки зрения администратора базы данных, в то время как для разработчика эти различия не всегда очевидны.

Колоночно-ориентированные базы данных больше, чем традиционные, ориентированные на строковое хранение данных, подходят для аналитических задач, в таких областях как большие хранилища данных, поддержка принятия решений, предиктивная аналитика и т. д.

Память компьютера организована в виде линейной последовательности. Классические row-store таблицы хранятся в виде последовательности записей, содержащих поля одной строки. При колоночном хранении записи, колонки хранятся в непрерывных ячейках памяти. На рисунке ниже показана разница хранения в памяти между строковой и колоночной таблицами.

Представление хранения данных в памяти (Column vs Row)

Основная разница в типах хранения заключается в операциях чтения, которые при колоночном типе хранения более эффективны чем при строковом типе.

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

Высокий коэффициент сжатия данных
Высокая производительность при операциях чтения
Исключение дополнительных индексов
Поздняя материализация
Параллелизация

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

Компрессия

Данные, хранящиеся в колонках более сжаты по отношению к строковому хранению. Объясняется это тем, что алгоритм сжатия лучше работает с данными с низкой энтропией. Высокая степень сжатия оказывает позитивное влияние на работу базы данных, так как сокращается объем данных, которые необходимо передать от оперативной памяти RAM к CPU.

В данном случае речь пойдет о самом распространённом типе сжатия в SAP HANA (он же тип сжатия по умолчанию) – Dictionary (сжатие на основе словаря). Это единственный тип сжатия, работающий как в Main, так и в Delta store. Техника сжатия, основана на кодировке словаря, где содержимое поля хранится в виде закодированных целых чисел в векторе атрибутов. В данном контексте это означает «перевод» содержимого поля в целочисленное значение.

Тип сжатия для интересующей вас таблицы (поля таблицы) можно посмотреть в представлении M_CS_COLUMNS поле COMPRESSION_TYPE.

Внимание! Тип сжатия определяется на уровне поля. Таким образом одна таблица по разным полям может иметь разные типы сжатия.

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

В таком случае словари (Dictionary) полей «Last Name» и «Location» будут выглядеть следующим образом:

Аттрибуты словаря (поля Last Name, Location)

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

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

Поддержка параллельных операций

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

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

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

Поздняя материализация

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

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

Итоги

В этой статье мы кратко рассмотрели основные преимущества колоночного хранения информации, реализованного в базе данных SAP HANA. Именно этот тип является типом хранения по умолчанию. В каком-то смысле - это попытка компании SAP объединить два мира OLAP и OLTP приложений, так как колоночные таблицы не только увеличивают производительность в операциях чтения, но и позволяют строить "тяжелые" аналитические представления в транзакционных системах.

SAP HANA. О преимуществах колоночного хранения