Greenplum для дата-инженера: 15 советов по индексам и сжатию

В продолжение вчерашней статьи по нашему новому курсу «Greenplum для инженеров данных», сегодня рассмотрим особенности индексации и сжатия данных в этой MPP-СУБД. Читайте далее, почему в Greenplum можно обойтись без индексов, когда выбирать RLE-сжатие вместо zlib, зачем сжимать рабочие файлы при выполнении SQL-запросов и что такое селективность индекса.

ТОП-10 советов по индексам в Greenplum

Индексы в базах данных нужны для ускорения поиска по таблице за счет структуры из значений одного или нескольких ее столбцов и указателей на соответствующие строки. SQL-запросы с индексами применяются для поиска по относительно небольшому количеству строк [1]. MPP-СУБД Greenplum предназначена для хранения и аналитической обработки очень больших данных, поэтому индексация в этой базе обычно не требуется. Для эффективного чтения данных Greenplum использует распараллеленное последовательное сканирование по сегментам, каждый из которых содержит равную часть данных. Тем не менее, иногда индексация может повысить скорость выполнения SQL-запросов, например, при высокой избирательности. В этом случае полезно создать индекс для одного столбца колоночной таблицы, чтобы уточнить столбцы с высокой мощностью. Однако, пользоваться индексами в Greenplum нужно осторожно, учитывая следующие рекомендации и лучшие практики [2]:

не стоит индексировать часто обновляемые столбцы, т.к. создание индекса увеличивает количество операций записи при обновлении;
индексы для выражений следует использовать только если оно часто используется в запросах;
индекс с предикатом создает частичный индекс, который пригодится для выбора небольшого количества строк из больших таблиц;
следует избегать перекрытия, когда несколько индексы имеют один и тот же ведущий столбец, и являются избыточными;
индексы могут повысить производительность сжатых оптимизированных для добавления (AO, append-optimized) таблиц для запросов, которые возвращают целевой набор строк. Для сжатых данных метод доступа к индексу означает, что только необходимые страницы не сжимаются.
Поскольку индексы являются структурой, оптимизированной под поиск и часто реализуются в виде B-дерева, создание селективных индексов в этом виде считается хорошей практикой. Селективность индекса – это отношение количества различных значений в столбце к количеству строк в таблице. Например, если в таблице 1000 строк, а в столбце 800 различных значений, то селективность индекса равна 800/1000=0.8, что весьма неплохо.
Чтобы ускорить процесс загрузки данных в таблицу, отбрасывайте индексы, а потом, при необходимости, создайте их снова.
Индексы Bitmap подходят для запросов, а не для обновления. Напомним, Bitmap – это метод битовых индексов, когда для каждого возможного значения столбца создается битовая карта — последовательность из 0 и 1. Каждому биту соответствует строка с индексируемым значением: 1 означает, что запись, соответствующая позиции бита, содержит индексируемое значение для данного столбца, а 0 — наоборот. На больших множествах с низкой мощностью и хорошей кластеризацией по их значениям Bitmap-индекс будет меньше чем B*-tree [3]. В Greenplum битовые индексы работают лучше всего на столбцах от 100 до 100 000 различных значений. Не стоит использовать Bitmap-индексы для уникальных столбцов, данных с очень высокой или очень низкой мощностью, а также транзакционных рабочих нагрузок.
если индексы необходимы для многораздельных таблиц, то столбцы индекса должны отличаться от столбцов раздела. Преимущество индексирования партиционированных таблиц в том, что поскольку производительность B-дерева экспоненциально ухудшается по мере его роста. Индексация партиционированных таблиц создает меньшие B-деревья, которые работают быстрее, чем с несекционированными таблицами.
Наконец, если добавление индекса не приводит к увеличению производительности, его лучше убрать. Важно, чтобы каждый созданный индекс эффективно использовался оптимизатором.

Сжатие данных

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

Сжатие с кодированием длин серий (RLE, Run-length encoding) считается наиболее эффективным с точки зрения компактного хранения данных на диске. Высокие уровни компактности реализуются за счет дополнительного времени и циклов ЦП на сжатие данных при записи и распаковку при чтении. Поэтому предварительная сортировка данных в сочетании с различными вариантами сжатия позволяет достичь оптимального результата. RLE отлично подходит для файлов с повторяющимися данными.

Помните, что данные, которые хранятся в уже сжатой файловой системе, не стоит подвергать дополнительным compression-операциям: это не даст никакого положительного эффекта. На практике придется поэкспериментировать с разными типами сжатия и методов упорядочивания, чтобы определить наилучшее сжатие для конкретных данных. Например, популярная библиотека общего назначения zlib предоставляет функции компрессии и декомпрессии в памяти, включая проверку целостности несжатых данных, а также подходит для работы с потоковыми данными [4]. В Greenplum можно запустить сжатие zlib на уровне 4 или 5, настроив его для достижения необходимых результатов [2]. Но для использования zlib СУБД Greenplum требует наличия соответствующих пакетов, установленных в хост-системе. По умолчанию в базе данных имеются утилиты gpbackup, gprestore, gpcopy, gpload и gplogfilter, которые поддерживают сжатие.

При этом по умолчанию для сжимаемого столбца устанавливается тип сжатия (compression_type) ZLIB, также можно задать ZSTD, RLE_TYPE или QUICKLZ1, доступный только в коммерческой версии Pivotal Greenplum Database. Для уровней сжатия (compression_level) в Zstd возможны целочисленные значения от 1 (самое быстрое сжатие) до 19 (максимальная степень сжатия). Для сжатия zlib допустимый диапазон составляет от 1 до 9. Уровень сжатия QuickLZ может быть установлен только на 1. Для RLE_TYPE уровень сжатия может быть от 1 (самое быстрое сжатие) до 4 (максимальная степень сжатия). По умолчанию уровень сжатия установлен в – 1. При сжатии данных в GP можно выделить следующие лучшие практики [5]:

пользовательские типы данных могут быть определены для сжатия, что следует указать при их создании в параметрах compression_type и compression_level;
протоколы внешних таблиц gpfdist (gpfdists), s3 и pxf поддерживают сжатие при доступе к внешним данным;
рабочие файлы – временные файлы утечки, которые создаются при выполнении запроса, который требует больше памяти, чем выделено, также можно сжимать, определив параметр сервера gp_workfile_compression.

Далее мы продолжим разбираться с Greenplum и рассмотрим особенности партиционирования таблиц и распределения данных в кластере. Другие подробности практической работы с популярной MPP-СУБД Greenplum для эффективного хранения и быстрой аналитики больших данных вы узнаете на новом авторском курсе «Greenplum для инженеров данных» в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве.

Смотреть расписание

Записаться на курс

Источники

ТОП-10 советов по индексам в Greenplum

Сжатие данных

Публикации по теме