Please enable JavaScript.
Coggle requires JavaScript to display documents.
Физическая модель данных и DDL - Coggle Diagram
Физическая модель данных и DDL
Ключевые сущности Greenplum
Инстанс Greenplum - это набор процессов, выполняющихся на кластере и обеспечивающих возможность работать с базами данных (подключения, запись данных на диск, обработка данных, системные задачи). Работающий кластер всегда представлен одним инстансом.
База данных (БД) - это набор таблиц с данными, представлений, функций и других объектов. На одном инстансе Greenplum можно создать несколько БД, они могут различаться настройками. Настройки доступа пользователей для разных БД в рамках одного инстанса также могут отличаться. Кроме того, объекты БД в разных базах данных изолированы друг от друга. Обратиться из одной БД к таблице или иному объекту другой БД невозможно.
CREATE DATABASE database_name;
Схема - это пространство имён, которое содержит именованные объекты: таблицы, представления, типы данных, функции и операторы.
CREATE SCHEMA schema_name
CREATE SCHEMA IF NOT EXISTS schema_name
Роль - это сущность, которая может владеть объектами базы данных и иметь её привилегии. Роль может рассматриваться как пользователь, группа или оба в зависимости от того, как она используется. В Greenplum роли отличаются от пользователей операционной системы и являются глобальными для всего кластера (не для отдельной БД).
В Greenplum имена таблиц и схем не чувствительны к регистру. Имена, заключённые в двойные кавычки, будут чувствительны к регистру.
Системные схемы
pg_catalog. Основной источник знаний об объектах БД. Содержит таблицы, в которых хранятся метаданные таблиц, представлений, столбцов и остальных объектов БД. Эта схема также называется каталогом Greenplum. В каталоге содержится ряд полезных представлений. Схема pg_catalog всегда неявно присутствует в пути поиска (search_path), поэтому к её таблицам и представлениям можно обращаться без указания схемы.
Information_schema. Содержит набор удобных представлений над таблицами каталога с информацией об объектах БД. Структура этих представлений соответствует стандарту ANSI и может быть удобна для тех, кто переходит на Greenplum с другой СУБД.
gp_toolkit
Содержит представления и функции для мониторинга и администрирования.
mdb_toolkit. Содержит представления и функции для мониторинга и администрирования с учётом ограничений облака. Некоторые системные функции из pg_catalog или gp_toolkit требуют для запуска права суперпользователя, которых нет в управляемой Greenplum. Для этих функций есть аналог в mdb_toolkit. Эта схема присутствует только в управляемой Greenplum.
pg_aoseg
Хранит системные данные для APPEND-OPTIMIZED-таблиц. Подробнее об этих таблицах вы узнаете в следующем уроке
pg_toast
Хранит значения из других таблиц, размер которых превышает размер блока данных для таблицы (по умолчанию — 32 КБ).
pg_bitmapindex
Содержит служебную информацию о bitmap-индексах.
pg
temp
<sess_id>
Содержит временные таблицы и другие объекты, созданные с указанием слова TEMPORARY. Для каждой пользовательской сессии создается своя схема pg_temp. Подробнее о временных таблицах вы узнаете в следующем уроке.
Таблицы
Дистрибуция
Сегмент Greenplum — это инстанс модифицированной СУБД PostgreSQL, единица шардирования данных и параллелизации работы. Сегменты располагаются на сегмент-хостах, и их может быть несколько на хост.
Часть данных, находящаяся на одном из сегментных инстансов PostgreSQL, называется сегмент, или шард. В зависимости от контекста, сегмент — это и инстанс PostgreSQL в составе кластера, и часть данных таблицы, хранящаяся в этом инстансе.
Типы дистрибуции
По ключу (distributed by) - Ключ дистрибуции может состоять из одного или нескольких (рекомендуется не более 3) полей таблицы. У ключа должна быть высокая кардинальность — большое количество уникальных значений для как можно более равномерного распределения данных по сегментам. В качестве ключа дистрибуции выгодно выбирать ключ, по которому в дальнейшем будут объединяться таблицы (join).
CREATE TABLE test_schema.company ( id UUID, inn BIGINT, company_name TEXT, utc_valid_from_dttm TIMESTAMP WITHOUT TIME ZONE)DISTRIBUTED BY (id, inn);
Дистрибуция случайным образом (DISTRIBUTED RANDOMLY). Если не удаётся подобрать поля для хорошего ключа распределения, можно использовать дистрибуцию случайным образом. Строки будут распределены по сегментам равномерно.
CREATE TABLE test_schema.company(id UUID,inn BIGINT,company_name TEXT,utc_valid_from_dttm TIMESTAMP WITHOUT TIME ZONE)DISTRIBUTED RANDOMLY;
Реплицирование таблицы по всем сегментам (DISTRIBUTED REPLICATED). Словари и небольшие таблицы можно хранить как полную копию на каждом сегменте кластера. В ряде случаев это помогает ускорить запросы с использованием этих таблиц. Объём места, занятый на кластере таблицей, увеличивается кратно количеству сегментов, то есть в десятки или сотни раз. Мы не рекомендуем выбирать такой способ распределения для больших таблиц.
CREATE TABLE test_schema.company(id UUID,inn BIGINT,company_name TEXT,utc_valid_from_dttm TIMESTAMP WITHOUT TIME ZONE)DISTRIBUTED REPLICATED;
Всегда явно указывайте дистрибуцию, иначе кластер сам выбирает поле дистрибуции (как правило, это первое поле в таблице) и распределяет таблицу по сегментам по этому полю. Таблица может распределиться неравномерно, и будет перекос.
Ключ дистрибуции таблицы можно менять так ALTER TABLE test_schema.company SET DISTRIBUTED BY (inn);
Если таблица не пустая, необходимо провести физическое перераспределение данных по сегментам. Для этого нужно выполнить команду: ALTER TABLE test_schema.company SET WITH (REORGANIZE=true);
Особенности внутреннего хранения
HEAP. Простая внутренняя структура хранения, перекочевавшая из PostgreSQL. На каждом сегменте Greenplum записи таблицы складываются последовательно в один файл. HEAP-таблицы создают наименьшее количество файлов в файловой системе. HEAP-таблицы поддерживают только построчно-ориентированное хранение данных. Сжатие HEAP-таблиц недоступно. Используем для небольших или таблиц с частым изменением данных.
APPEND-OPTIMIZED-таблицы нужны для сжатия данных. У них более сложная внутренняя структура: таблицы содержат ссылки на файлы, в которых хранятся большие блоки данных. У каждой таблицы есть внутренний индекс, обеспечивающий её работу. Это индекс по системным полям, и он не используется в запросах. Каждая APPEND-OPTIMIZED-таблица создаёт несколько системных объектов в Greenplum и несколько файлов на диске. Главное достоинство AO-таблиц — возможность хранить данные в сжатом виде. Если сжатие не нужно, лучше выбрать HEAP-таблицу.
Ориентация
Построчная ориентация: в файле данных записи хранятся целиком и последовательно.
Поколоночная ориентация: каждая колонка таблицы хранится в отдельном файле. Это приводит к резкому увеличению количества файлов, в которых хранятся данные. AO-таблицы с поколоночной ориентацией значительно сокращают затраты на чтение, когда запрос обращается только к части столбцов из всего набора колонок таблицы. Такие таблицы лучше сжимаются.
Сжатие (его можно задать только при создании таблицы, типа AO). Сжатие позволяет сэкономить дисковое пространство: это происходит за счёт использования CPU. Поэтому запись в сжатую таблицу может быть медленнее, чем в HEAP, особенно на быстрых дисках. Чтение из сжатой таблицы использует CPU менее интенсивно, чем запись, и не зависит от алгоритма сжатия.
Партицирование. Большие таблицы в Greenplum можно дополнительно разбивать на части — партиции. Такие таблицы будут называться партицированными. Цель партицирования — физически разделить данные таблицы на части, чтобы оптимизировать операцию выборки.
Партицирование и дистрибуция делят данные на части, но преследуют разные цели. Дистрибуция как можно более равномерно распределяет по кластеру данные и нагрузку по их обработке. Партицирование делит данные по критерию так, чтобы при фильтрации по этому критерию не нужно было сканировать всю таблицу.
Может быть многоуровневым
Типы данных, особенности работы
Дистрибуция. Лучший тип данных для использования в ключах дистрибуции — целочисленный. При распределении данных по сегментам вычисляется хеш от ключа, на основе хеша определяется номер сегмента. Целочисленный тип даёт абсолютную точность в отличие от типов с плавающей точкой и компактный размер в отличие от строк — а значит, максимально быстрое вычисление хеша. Колонки с геопространственными типами данных и собственными типами пользователей не могут использоваться в качестве составляющих ключа.
Партицирования. В качестве ключа для партицирования по диапазону можно использовать числовые типы данных или типы данных date, timestamp. При партицировании по списку возможно использовать поле любого типа данных, поддерживающего сравнение и определение равенства значений, например varchar, int.
Индексы. Индекс — это специальный объект в БД, позволяющий находить строку в таблице по значению одного или нескольких атрибутов. Индексы Primary Key и Unique не поддерживаются на APPEND-OPTIMIZED-таблицах.
Типы индексов
B-Tree. Применяется по умолчанию, используется чаще всего. Числа, даты, строки. В корнях и ветках индекса B-tree хранятся упорядоченные значения индексируемого поля. От каждого значения есть ссылка на следующие блоки с большими и меньшими значениями. В листьях дерева лежат ссылки на блоки таблицы. B-tree может помочь в сжатой таблице прочитать с диска и разжать только те блоки, в которых есть искомые данные, сберегая IO-операции и вычислительное время CPU.
Bitmap. Применяется для полей с небольшим количеством уникальных значений (100–100000) и таблиц с большим количеством строк. Для значений индексируемого поля создаётся битовая карта, отражающая наличие конкретного значения индексируемого поля в строке таблицы. Bitmap index может хорошо сжиматься и занимать мало места по сравнению с самим полем таблицы. При выборке нужных значений СУБД сканирует битовую карту и быстро находит только те блоки таблицы, где лежат искомые данные. Bitmap index лучше всего работает в таблицах, из которых данные вычитываются группами по значению проиндексированного поля. Особенно эффективно работает WHERE c выборкой из нескольких значений.
GiST. Generalized Search Tree (Обобщённое дерево поиска) — индекс общего назначения. Индекс GiST можно, например, построить по геопространственным данным, полям типа TSVECTOR.
SP-GiST. SP-GiST: Space Partitioned (Разделяемое в пространстве обобщённое дерево поиска) применяется, когда можно разбить все значения на группы без пересечений. Например, геометрические фигуры на плоскости или географические объекты. Объекты с одного континента могут попасть в ветвь индекса этого континента, а объекты других континентов будут содержаться в других ветвях.
GIN: Generalized Inverted Search Tree (Обобщённое инвертированное дерево поиска) применяется для поиска по полям типов данных Greenplum Database Full Text Search или полям типа jsonb. Принцип действия индекса GIN похож на Bitmap index, но GIN работает с другими типами данных. GIN отвечает на вопрос, в каких строках таблицы встречаются вхождения определённого значения или несколько значений вместе.
Примечания
Все существующие в БД индексы можно найти в представлениях каталогов pg_index или pg_indexes в удобном для человека формате.
В партицированной таблице для каждой партиции создаётся свой индекс, то есть на каждый объект создаётся отдельный объект-индекс.
Ограничения целостности (constraints) в базе данных — это правила, которые гарантируют, что данные в таблице соответствуют определённым условиям.
Ограничения CHECK — проверка условия
NOT NULL — непустые значения колонки
UNIQUE — уникальность
PRIMARY KEY — первичный ключ
Если задано UNIQUE и PRIMARY KEY то дистрибуция таблицы по умолчанию берется по ключу. Ограничения целостности в партицированных таблицах применяются ко всем партициям. Все существующие ограничения целостности в базе данных можно найти в представлении каталога pg_constraint.
Последовательность (sequence) — специальный объект базы данных, который помогает автоматически создавать уникальные идентификаторы (например, значения для поля PRIMARY KEY) для записей в таблице путём получения следующего значения в числовом ряду. Движок последовательностей живёт на мастере и отдаёт в остальные сегменты уникальные значения
Представление (view) позволяет сохранять сложные или часто используемые запросы к таблицам БД как специальный объект и обращаться к такому объекту как к таблице. Представления хранятся в БД в виде текста своего запроса, дополнительного хранения данных нет. Информацию обо всех созданных представлениях можно получить из системного каталога pg_views.
Функция (function) — блок кода, способный принять параметры, вернуть результат и выполнить расчёты над данными или произвести действия над объектами базы данных. Функции в Greenplum перегружаемы. У литералов есть специальные ограничители. У функций в СУБД нет зависимостей от объектов, на основе которых они созданы.