Версия сайта для слабовидящих
Продвигая наш новый курс «Greenplum для инженеров данных», сегодня мы рассмотрим особенности организации таблиц в этой MPP-СУБД, типы данных и оптимальное расположение столбцов. Читайте далее, чем heap storage отличается от append-optimized, когда выбирать колоночную, а когда – строковую модель хранения данных для таблицы, почему BIGINT с TIMESTAMP следует размещать перед TEXT и VARCHAR.
MPP-архитектура Greenplum и быстрая PostgreSQL-аналитика
Согласно рейтингу популярности СУБД-движков, на середину мая 2021 года Greenplum занимала 42 место, набрав 12,75 баллов. Для сравнения, Oracle DB, расположившаяся на 1-м месте, набрала 1269.94 баллов. А PostgreSQL, на которой и основана сама Greenplum, стоит на 4-ой строке рейтинга с 559.25 баллами [1]. Методика расчета DB-Engines Ranking касается только упоминания названия системы, от обсуждения в чатах до поиска специалистов по отдельным СУБД, не затрагивая особенности технической реализации и пользы практического применения [2]. Однако, попадание в ТОП-50 мест такого рейтинга популярности косвенно свидетельствует о востребованности этой распределенной массивно-параллельной база данных на основе PostreSQL.
Greenplum (GP) реализует массивно-параллельную архитектуру (MPP, Massive Parallel Processing) без разделения ресурсов между узлами кластера: каждый из них имеет собственную память, операционную систему и жесткие диски. Благодаря этому GP эффективно распараллеливает нагрузку и может быстро выполнять аналитические запросы к многотерабайтным хранилищам и озерам данных. Но такая архитектурная модель значительно отличается от широко распространенных сильно нормализованных транзакционных СУБД. Поэтому для эффективного использования Greenplum существует целый ряд рекомендаций, воплощающих лучшие практики работы с этой аналитической MPP-вычислений. Далее мы рассмотрим те из них, которые относятся к оптимальной организации таблиц в GP: поговорим про модели хранения, типы данных и расположение столбцов.
4 модели хранения данных в Greenplum: что и когда выбирать
Прежде чем перейти к особенностям организации таблиц в Greenplum, отметим что эта MPP-СУБД лучше всего работает с денормализованной схемой, подходящей для аналитической обработки (OLAP) — «звезда» или «снежинка», с большими централизованными таблицами фактов, подключенными к меньшим таблицам измерений. При этом рекомендуется использовать те же типы данных для столбцов, задействованных в соединениях между таблицами, о чем мы поговорим в пункте про типы данных. А о том, чем отличается звезда от снежинки в OLAP и витринах данных при проектировании КХД, мы рассказывали здесь.
Greenplum предоставляет множество вариантов хранения при создании таблиц [3]:
- хранилище кучи (heap storage), которое обычно использует PostgreSQL для всех таблиц базы данных. Этот способ подходит для таблиц и разделов, которые будут получать конкурентные запросы: итеративные UPDATE и DELETE, а также одиночные INSERT.
- хранилище, оптимизированным для добавления (AO, append-optimized storage) таблиц и разделов, которые нечасто обновляются после начальной загрузки, а последующие вставки выполняются только в пакетных операциях. Следует избегать выполнения одноэлементных операций INSERT, UPDATE или DELETE в AO-таблицах. Допустимы конкурентные пакетные операции INSERT, но не пакетные UPDATE или DELETE. Эта модель предназначена для больших таблиц, которые загружаются один раз, редко обновляются и часто запрашиваются для аналитической обработки запросов.
- хранилище, ориентированное на строки, с традиционным способом хранения кортежей базы данных. Столбцы хранятся на диске непрерывно, так что вся строка может быть прочитана с диска за один ввод-вывод.
- хранилище, ориентированное на столбцы, сохраняющее все значения каждого столбца на диске в отдельном файле. Если таблица разбита на разделы, для каждого столбца и раздела создается отдельный файл. Когда запрос обращается только к небольшому количеству столбцов из множества колонок такой таблицы, затраты на ввод-вывод данных существенно снижаются по сравнению со строковым хранилищем, т.к. ненужные столбцы не считываются с диска.
Подробнее про отличия колоночно-ориентированной модели хранения данных от строковой ориентации с примерами, читайте в нашей новой статье.
Greenplum для инженеров данных и аналитиков данных
Код курса
GPDE
Ближайшая дата курса
24 июня, 2024
Продолжительность
24 ак.часов
Стоимость обучения
72 000 руб.
Выбор оптимальной модели особенно важен для больших таблиц фактов. Для определения оптимальной модели хранения данных в Greenplum можно опираться на следующие рекомендации и лучшие практики [3]:
- сперва спроектируйте модель только для вставки, отсекая ежедневный раздел перед загрузкой;
- для разных разделов в больших таблицах фактов наиболее эффективно использовать различные варианты хранения, т.к. некоторые разделы могут быть ориентированы на строки, а другие – наоборот, на столбцы;
- параметры хранилища устанавливаются на уровне раздела;
- в колоночном хранилище, любой столбец является отдельным файлом в каждом сегменте базы данных Greenplum. Поэтому в таких таблицах рекомендуется хранить «горячие» данные, обращения к которым выполняются часто.
- строковые хранилища подходят для «холодных» данных, которые требуется считывать достаточно редко, и для рабочих нагрузок транзакционного типа с итеративными транзакциями с обновлениями и частыми вставками.
- используйте строковое хранилище для широких выборок, когда в запросе используется много столбцов одной строки, например, в списке SELECT или условии WHERE. Также строковое хранилище подходит для общих или смешанных рабочих нагрузок, поскольку оно предлагает наилучшее сочетание гибкости и производительности.
- колоночное хранилище оптимизировано для операций чтения, но не для записи: таблицы, ориентированные на столбцы, оптимальны для небольшой выборки столбцов из больших таблиц.
- в колоночных таблицах набор значений одного и того же типа данных может храниться в меньшем пространстве, занимая меньше дискового пространства, чем строковые таблицы. Также колоночные таблицы лучше сжимаются, чем строковые.
- Колоночные таблицы отлично подходят для аналитических рабочих нагрузок, когда выборка ограничена или агрегаты данных вычисляются по небольшому количеству столбцов. Также эта модель рекомендуется для таблиц с отдельными столбцами, которые регулярно обновляются без изменения других столбцов в строке.
- Для оптимальной производительности следует располагать столбцы таблицы так, чтобы добиться выравнивания типов данных на уровне байтов, что мы рассмотрим далее.
Типы данных и столбцы
Как следует из вышеописанных особенностей хранения, СУБД GP очень сильно зависит от типов хранящихся в ней данных. В частности, рекомендуется использовать одинаковые типы данных для столбцов в соединениях между таблицами. Если типы данных различаются, база данных Greenplum должна динамически преобразовать тип данных одного из столбцов, чтобы значения данных можно было правильно сравнивать. Для выполнения этой операции требуются дополнительные вычислительные ресурсы и время. Поэтому при проектировании структуры БД имеет смысл увеличить размер типа данных, чтобы облегчить соединение таблиц. Для этого можно использовать следующие лучшие практики [3]:
- выбирать типы данных, которые используют наименьшее пространство для хранения, чтобы увеличить емкость базы и ускорить выполнение запросов. Например, TEXT или VARCHAR вместо CHAR. На первый взгляд, между символьными типами данных нет различий в производительности, но TEXT или VARCHAR требуют меньше пространства для хранения. Аналогично с числовыми типами данных: использование BIGINT для данных, которые помещаются в INT или SMALLINT, тратит впустую место в хранилище.
- размещать столбцы в таблицах кучи в порядке от наибольшего к наименьшему – от столбцов с ключами распределения и разделения к фиксированным числовым и переменным типам. Например, BIGINT и TIMESTAMP перед INT и DATE, а только потом TEXT, VARCHAR или NUMERIC(x, y). Например, сперва идут 8-байтовые типы (BIGINT, TIMESTAMP), затем 4-байтовые типы (INT, DATE), далее 2-байтовые типы, после (SMALLINT), а переменный тип данных (VARCHAR) — в последнюю очередь.
К примеру, вместо определения столбцов в последовательности
Int, Bigint, Timestamp, Bigint, Timestamp, Int (distribution key), Date (partition key), Bigint, Smallint
более эффективно определить столбцы таблицы так:
Int (distribution key), Date (partition key), Bigint, Bigint, Timestamp, Bigint, Timestamp, Int, Smallint
Наконец, следует сжимать большие таблицы, чтобы повысить производительность ввода-вывода и освободить место в кластере, о чем мы поговорим завтра. О про индексирование данных в Greenplum читайте здесь.
Администрирование Greenplum / Arenadata DB
Код курса
GRAD
Ближайшая дата курса
13 мая, 2024
Продолжительность
40 ак.часов
Стоимость обучения
120 000 руб.
Узнайте все подробности администрирования и эксплуатации этой MPP-СУБД на примере Arenadata DB или в виде отдельного продукта для эффективного хранения и аналитики больших данных на наших специализированных курсах в лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
