Партиционирование в Greenplum 7: что нового

Greenplum 7 - это важное событие для мира партицированных таблиц. Помимо ряда важных улучшений и исправлений, это первая версия Greenplum, которая совместима с партицированными талицами из мира PostgreSQL.

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

CREATE TABLE sales (id int, date date, amt decimal(10,2))
PARTITION BY RANGE (date);

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

В этой статье речь пойдет в основном о различиях между Greenplum 7 и Greenplum 6. Поэтому, если Вы - совсем новичок в Greenplum (или даже в PostgreSQL) и никогда раньше не использовали разметку в Greenplum 6, то Вам, скорее всего, будет интереснее прочитать статьи, ссылки на которые Вы найдете в конце данного поста.

Итак, приступим к делу.

1. Новый синтаксис

Прежде чем мы начнем рассматривать новинки Greenplum 7, давайте разберемся в том, что осталось по-прежнему: поскольку в PostgreSQL используется то же объявление для ключа разделения, что и в Greenplum, а именно предложение PARTITION BY, оно осталось таким же и в Greenplum 7. Более того, в PostgreSQL также есть стратегии партиционирования RANGE и LIST, которые Greenplum продолжает поддерживать в своих новых версиях.

Однако есть одно важное отличие, которое заключается в том, что Greenplum 7 теперь позволяет определять таблицу с разделами без определения дочерних разделов, например:

CREATE TABLE sales (id int, date date, amt decimal(10,2))
DISTRIBUTED BY (id)
PARTITION BY RANGE (date);

Команда CREATE TABLE ... PARTITION BY, приведенная выше, создает только родительскую таблицу с разделами без дочерних разделов. Дочерние разделы в Greenplum 7 являются таблицами первого класса и могут создаваться с помощью отдельных команд, которые будут рассмотрены позже.

1.1. Стратегия партиционирования по хэш-значению

Помимо существующих стратегий RANGE и LIST Greenplum 7 также поддерживает партиционирование по хэш-значению. Оно работает так же, как и в PostgreSQL. Пример:

-- создание таблицы, разделенной по хэш-значению 
CREATE TABLE sales_by_hour (id int, date date, hour int, amt decimal(10,2))
DISTRIBUTED BY (id)
PARTITION BY HASH (hour);

-- каждый модуль хэш-раздела должен быть в раз больше следующего модуля
CREATE TABLE sales_by_hour_1 PARTITION OF sales_by_hour FOR VALUES WITH (MODULUS 24, REMAINDER 0);
CREATE TABLE sales_by_hour_2 PARTITION OF sales_by_hour FOR VALUES WITH (MODULUS 24, REMAINDER 1);
CREATE TABLE sales_by_hour_3 PARTITION OF sales_by_hour FOR VALUES WITH (MODULUS 24, REMAINDER 2);
......

1.2. Новое партиционирование DDL

Итак, основными дополнениями в Greenplum 7 являются новое DDL партиционирование, такое же, как и в PostgreSQL. Подробнее о нем мы поговорим позже, а пока давайте посмотрим, что оно делает:

(1) CREATE TABLE PARTITION OF

Для создания новой таблицы и добавления ее в качестве нового дочернего раздела:

CREATE TABLE jan_sales PARTITION OF sales 
FOR VALUES FROM ('2023-01-01') TO ('2023-02-01');

(2) ALTER TABLE ATTACH PARTITION

Для добавления существующей таблицы в качестве нового дочернего раздела:

CREATE TABLE feb_sales (LIKE sales);
ALTER TABLE sales ATTACH PARTITION feb_sales 
FOR VALUES FROM ('2024-02-01') TO ('2024-03-01');

(3) ALTER TABLE DETACH PARTITION

Для удаления таблицы из иерархии партиционирования (без сброса самой таблицы):

ALTER TABLE sales DETACH PARTITION jan_sales;

1.3. Новый каталог и вспомогательные функции

Теперь информация касательно партиционирования хранится в каталоге pg_partitioned_table, а также в дополнительных полях в pg_class (relispartition и relpartbound). Вы также можете воспользоваться следующими вспомогательными функциями: pg_partition_ancestors(rel)), pg_partition_root(rel) and pg_partition_tree(rel).

В связи с этим исчезли старые таблицы каталогов, связанные с разделением, pg_partition и pg_partition_rule, а также функция pg_partition_def().

-- новый каталог для разделенных таблиц
select * from pg_partitioned_table where partrelid = 'sales'::regclass;
 partrelid | partstrat | partnatts | partdefid | partattrs | partclass | partcollation | partexprs
-----------+-----------+-----------+-----------+-----------+-----------+---------------+-----------
    156181 | r         |         1 |         0 | 2         | 3122      | 0             |
(1 row)
 
-- Вспомогательная процедура для проверки иерархии разделов
select pg_partition_tree('sales');
         pg_partition_tree
-----------------------------------
 (sales,,f,0)
 (jan_sales,sales,t,1)
 (sales_1_prt_feb_sales,sales,t,1)
 (sales_1_prt_mar_sales,sales,t,1)
(4 rows)

2. Новые рабочие процессы

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

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

Создайте дочерний раздел вместе с родительским

Greenplum удалось создать дочерние разделы вместе с родительской таблицей. Например:

CREATE TABLE sales (id int, date date, amt decimal(10,2))
DISTRIBUTED BY (id)
PARTITION BY RANGE (date)
(PARTITION jan_sales START ('2023-01-01') END ('2023-02-01'),
PARTITION feb_sales START ('2023-02-01') END ('2023-03-01'),
DEFAULT PARTITION other_sales);

В PostgreSQL нет аналогичной команды. Вместо этого сначала создается родительская таблица с разделами, а затем отдельно добавляются дочерние разделы:

CREATE TABLE sales (id int, date date, amt decimal(10,2))
DISTRIBUTED BY (id)
PARTITION BY RANGE (date);

-- Add partition individually
CREATE TABLE jan_sales PARTITION OF sales FOR VALUES FROM ('2023-01-01') TO ('2023-02-01');
CREATE TABLE feb_sales PARTITION OF sales FOR VALUES FROM ('2023-02-01') TO ('2023-03-01');
CREATE TABLE other_sales PARTITION OF sales DEFAULT;

Создание и добавление дочерних разделов

ALTER TABLE ... ADD PARTITION и CREATE TABLE ... PARTITION OF одновременно создают и добавляют новую дочернюю таблицу.

Однако, поскольку CREATE TABLE PARTITION OF - это команда CREATE TABLE, в отличие от ADD PARTITION, которая является подкомандой ALTER TABLE, в CREATE TABLE ... PARTITION OF можно указать больше параметров создания таблиц. ADD PARTITION в общем случае наследует только то, что есть у родительской таблицы.

CREATE TABLE также позволяет Вам указать большое количество параметров.

CREATE TABLE jan_sales PARTITION OF sales FOR VALUES FROM ('2023-01-01') TO ('2023-02-01')
USING ao_row 
WITH(compresstype=zlib);
 
-- ADD PARTITION создает разделение, но параметры нужно указывать в отдельных командах
ALTER TABLE sales ADD PARTITION jan_sales START ('2023-01-01') END ('2023-02-01');

ALTER TABLE sales_1_prt_jan_sales SET ACCESS METHOD ao_row;
ALTER TABLE sales_1_prt_jan_sales SET WITH (compresstype=zlib);

Поменяйте существующий раздел на другую таблицу

Команда EXCHANGE PARTITION в устаревшем синтаксисе меняет местами существующий дочерний раздел с обычной таблицей. В новом синтаксисе для достижения того же самого результата достаточно использовать DETACH PARTITION и ATTACH PARTITION.

-- 1. Using EXCHANGE PARTITION
ALTER TABLE sales EXCHANGE jan_sales WITH TABLE jan_sales_new; 
     
-- 2. Using ATTACH PARTITION
ALTER TABLE sales DETACH PARTITION jan_sales;
ALTER TABLE sales ATTACH PARTITION jan_sales_new;

Удаление дочернего раздела

Раньше было довольно сложно удалить дочерний раздел без сброса таблицы. В устаревшей версии Greenplum есть команда ALTER TABLE ... DROP PARTITION, которая также уничтожает таблицу. Сначала нужно было создать фиктивную таблицу, поменять раздел, который Вы хотите удалить, на фиктивную таблицу, а затем сбросить помененный раздел. Теперь эту задачу можно выполнить с помощью команды ALTER TABLE ... DETACH PARTITION:

-- Длительные операции по удалению нежелательного дочернего раздела без его сброса:
CREATE TABLE dummy (LIKE sales);
ALTER TABLE sales EXCHANGE PARTITION archived_sales WITH dummy;
ALTER TABLE sales DROP PARTITION archived_sales;
DROP TABLE dummy;
 
-- Теперь достаточно "DETACH PARTITION":
ALTER TABLE sales DETACH PARTITION archived_sales;

Как Вы уже могли заметить, ALTER TABLE ... DROP PARTITION по сути выполняет ту же задачу, что и DROP TABLE. Тогда почему ALTER TABLE ... DROP PARTITION все еще существует? Потому что эти два синтаксиса по-разному относятся к имени таблицы. См. раздел «Имя раздела vs имя таблицы».

Разделение дочернего раздела

SPLIT PARTITION - это специальная команда, выполняющая достаточно интересную задачу: партиционирование листа раздела и создание из него двух разделов. Это еще один синтаксис, не имеющий простой альтернативы в PostgreSQL. Вам придется вручную отсоединять раздел и добавлять два раздела, соответствующих разделенным диапазонам. Но есть и хорошая новость: если Вы не хотите выполнять эти действия, Вы можете просто использовать SPLIT PARTITION.

Вы также можете разделить раздел по умолчанию, что является достаточно распространенной практикой, когда данные сначала вставляются в раздел по умолчанию, а затем добавляются в объявленные разделы. Но стоит отметить, что если раздел по умолчанию не содержит никаких данных, то для добавления новых разделов лучше использовать ATTACH PARTITION, поскольку ATTACH PARTITION имеет менее ограниченный тип блокировки (см. подробнее в разделе 3.3). Если раздел по умолчанию содержит данные, то, скорее всего, ATTACH PARTITION будет выполнен с ошибкой, поскольку данные в разделе по умолчанию нарушают ограничения нового раздела.

Сравнительная таблица:

Действие	Традиционный синтаксис	Альтернатива
Создание дочернего раздела вместе с родительским	`CREATE TABLE ... (PARTITION ...)`	`CREATE TABLE ... PARTITION BY` и `CREATE TABLE ... PARTITION OF`
Создание и добавление раздела	`ALTER TABLE ... ADD PARTITION`	`CREATE TABLE ... PARTITION OF`
Смена дочерних разделов на обычные таблицы	`ALTER TABLE ... EXCHANGE PARTITION`	`ALTER TABLE ... DETACH PARTITION` и `ATTACH PARTITION`
Удаление разделов	`ALTER TABLE ... DROP PARTITION`	`DROP TABLE`
Разбиение разделов	`ALTER TABLE ... SPLIT PARTITION`	`DETACH` и `ATTACH`

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

3. Другие различия

3.1. Имя раздела vs Имя таблицы

Исторически сложилось так, что в DDL-файлах Greenplum для разделов указывается так называемое «имя раздела», которое не совпадает с именем таблицы. В основном, Greenplum добавляет к имени дочерней таблицы специальный префикс, соответствующий родительскому разделу. Например, при использовании унаследованного синтаксиса для добавления разделов:

CREATE TABLE sales (id int, date date, amt decimal(10,2))
DISTRIBUTED BY (id)
PARTITION BY RANGE (date)
(PARTITION jan_sales START ('2023-01-01') END ('2023-02-01'));

ALTER TABLE sales ADD PARTITION feb_sales START ('2023-02-01') END ('2023-03-01');

\d+ sales
                                Partitioned table "public.sales"
 Column |     Type      | Collation | Nullable | Default | Storage | Stats target | Description
--------+---------------+-----------+----------+---------+---------+--------------+-------------
 id     | integer       |           |          |         | plain   |              |
 date   | date          |           |          |         | plain   |              |
 amt    | numeric(10,2) |           |          |         | main    |              |
Partition key: RANGE (date)
Partitions: sales_1_prt_feb_sales FOR VALUES FROM ('2023-02-01') TO ('2023-03-01'),
            sales_1_prt_jan_sales FOR VALUES FROM ('2023-01-01') TO ('2023-02-01')
Distributed by: (id)
Access method: heap

Как показано выше, оба дочерних раздела имеют префикс sales_1_prt_ к именам, которые мы для них указали (jan_sales и feb_sales). В отличие от этого, новый синтаксис рассматривает указанные имена как имя таблицы:

CREATE TABLE sales (id int, date date, amt decimal(10,2))
DISTRIBUTED BY (id)
PARTITION BY RANGE (date);
 
CREATE TABLE jan_sales PARTITION OF sales
FOR VALUES FROM ('2023-01-01') TO ('2023-02-01');
 
CREATE TABLE feb_sales (LIKE sales);
ALTER TABLE sales ATTACH PARTITION feb_sales
FOR VALUES FROM ('2024-02-01') TO ('2024-03-01'); 
 
\d+ sales
                                Partitioned table "public.sales"
 Column |     Type      | Collation | Nullable | Default | Storage | Stats target | Description
--------+---------------+-----------+----------+---------+---------+--------------+-------------
 id     | integer       |           |          |         | plain   |              |
 date   | date          |           |          |         | plain   |              |
 amt    | numeric(10,2) |           |          |         | main    |              |
Partition key: RANGE (date)
Partitions: feb_sales FOR VALUES FROM ('2024-02-01') TO ('2024-03-01'),
            jan_sales FOR VALUES FROM ('2023-01-01') TO ('2023-02-01')
Distributed by: (id)
Access method: heap

Однако это различие сохраняется между старым и новым синтаксисами. Например, нам не нужно указывать префикс при использовании старого синтаксиса DROP PARTITION. Но если мы используем DETACH PARTITION для выполнения того же действия, то это необходимо:

Предположим, у нас есть разделение 'sales' с дочерними разделениями по Февралю и Январю, созданные с помощью традиционного синтаксиса.

\d+ sales
                                Partitioned table "public.sales"
 Column |     Type      | Collation | Nullable | Default | Storage | Stats target | Description
--------+---------------+-----------+----------+---------+---------+--------------+-------------
 id     | integer       |           |          |         | plain   |              |
 date   | date          |           |          |         | plain   |              |
 amt    | numeric(10,2) |           |          |         | main    |              |
Partition key: RANGE (date)
Partitions: sales_1_prt_feb_sales FOR VALUES FROM ('2023-02-01') TO ('2023-03-01'),
            sales_1_prt_jan_sales FOR VALUES FROM ('2023-01-01') TO ('2023-02-01')
Distributed by: (id)
Access method: heap
 
-- сбрасываем разделение 'jan_sales', без проблем
ALTER TABLE sales DROP PARTITION jan_sales;
 
-- сбросить не смогли, так как таблицы 'feb_sales'не существует
ALTER TABLE sales DETACH PARTITION feb_sales;
ERROR:  relation "feb_sales" does not exist
 
-- необходимо указать полное имя, используя DETACH
ALTER TABLE sales DETACH PARTITION sales_1_prt_feb_sales;

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

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

Синтаксис	Добавляем префикс или нет	Традиционный или новый
`ADD PARTITION`	да	традиционный
`DROP PARTITION`	да	традиционный
`EXCHANGE PARTITION`	да	традиционный
`SPLIT PARTITION`	да	традиционный
`CREATE TABLE (PARTITION ...)`	да	традиционный
`CREATE TABLE (EVERY ...)`	да	традиционный
`CREATE TABLE ... PARTITION OF`	нет	новый
`ATTACH PARTITION`	нет	новый
`DETACH PARTITION`	нет	новый

3.2. `START|END` vs `FROM|TO`

На примерах SQL, которые были показаны ранее, Вы, вероятно, заметили, что в новом синтаксисе также присутствуют различные ключевые слова для определения раздела диапазона: FOR VALUES FROM ... TО ..... В унаследованном синтаксисе Greenplum есть START ... END (). Оба определения будут работать только в соответствующих старых или новых DDL:

ALTER TABLE sales ADD PARTITION mar_sales 
START ('2023-03-01') END ('2023-03-31');
 
CREATE TABLE mar_sales PARTITION OF sales 
FOR VALUES FROM ('2023-03-01') TO ('2023-03-31');
 
-- Это не сработает:
ALTER TABLE sales ADD PARTITION mar_sales 
FOR VALUES FROM ('2023-03-01') TO ('2023-03-31');
 
CREATE TABLE mar_sales PARTITION OF sales 
START ('2023-03-01') END ('2023-03-31');

В устаревшем синтаксисе также есть ключевые слова EXCLUSIVE и INCLUSIVE для разделения диапазона. В PostgreSQL этого нет, начальная граница всегда инклюзивная, а конечная эксклюзивная. Greenplum 7 продолжает поддерживать EXCLUSIVE|INCLUSIVE, неявно добавляя «+1» к начальному или конечному диапазону. В результате они теперь работают только для типов данных, имеющих подходящий оператор «+», таких как integer и timestamp, но не float или text.

ALTER TABLE sales ADD PARTITION mar_sales
START ('2023-03-01') INCLUSIVE END ('2023-03-31') INCLUSIVE;

3.3. блокировка с меньшим ограничением в `ATTACH` `PARTITION`

Поведение блокировки в разделе заслуживает отдельной статьи, но одна из самых важных вещей, о которой должны знать пользователи, - это легкая блокировка с помощью ATTACH PARTITION. ATTACH PARTITION требует только Share Update Exclusive Lock на родительской таблице. Этот тип блокировки является относительно легким и не конфликтует со многими другими запросами, включая SELECT, INSERT и иногда UPDATE.

Это означает, что только в Greenplum 7 стало возможным добавлять разделы в иерархию разделов, не нарушая при этом выполнения многих запросов к разделу (и наоборот). Например:

-- Предположим, что мы имеем дело с долговременной вставкой 
INSERT INTO sales SELECT * FROM ext_sales_data;
 
-- Такое решение будет заблокировано:
ALTER TABLE sales ADD PARTITION march_sales START ('2023-03-01') END ('2023-04-01');
 
-- А это сработает:
ALTER TABLE sales ATTACH PARTITION march_sales FOR VALUES FROM ('2023-03-01') TO ('2023-04-01');

Чтобы увидеть все это на практике, просмотрите это демо-видео.

В этой таблице показаны блокировки во время различных DDL разделов.

Команда	Самый серьезный тип блокировки	Разрешенный запрос
`ADD PARTITION`	AccessExclusiveLock	нет
`DROP PARTITION`	AccessExclusiveLock	нет
`EXCHANGE PARTITION`	AccessExclusiveLock	нет
`SPLIT PARTITION`	AccessExclusiveLock	нет
`CREATE TABLE ... PARTITION OF`	AccessExclusiveLock	нет
`ATTACH PARTITION`	ShareUpdateExclusiveLock	SELECT, INSERT, UPDATE*
`DETACH PARTITION`	AccessExclusiveLock	нет

* Когда включен gp_enable_global_deadlock_detector, а таблица не оптимизирована для добавления.

3.4. Ограничения раздела и ограничения проверки

Границы разделов больше не представлены в виде ограничений CHECK. Теперь ограничения разделов - это совершенно отдельная концепция.

-- одинаковое определение разделов в Greenplum 6 и 7
 
-- Greenplum 6
\d+ sales_1_prt_jan_sales
                   Table "public.sales_1_prt_jan_sales"
 Column |     Type      | Modifiers | Storage | Stats target | Description
--------+---------------+-----------+---------+--------------+-------------
 id     | integer       |           | plain   |              |
 date   | date          |           | plain   |              |
 amt    | numeric(10,2) |           | main    |              |
Check constraints:
    "sales_1_prt_jan_sales_check" CHECK (date >= '2023-01-01'::date AND date < '2023-02-01'::date)
Inherits: sales
Distributed by: (id)
 
-- Greenplum 7
\d+ jan_sales
                                    Table "public.jan_sales"
 Column |     Type      | Collation | Nullable | Default | Storage | Stats target | Description
--------+---------------+-----------+----------+---------+---------+--------------+-------------
 id     | integer       |           |          |         | plain   |              |
 date   | date          |           |          |         | plain   |              |
 amt    | numeric(10,2) |           |          |         | main    |              |
Partition of: sales FOR VALUES FROM ('2023-01-01') TO ('2023-02-01')
Partition constraint: ((date IS NOT NULL) AND (date >= '2023-01-01'::date) AND (date < '2023-02-01'::date))
Distributed by: (id)

3.5. PARTITION BY для нескольких столбцов

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

-- Это больше не работает:
CREATE TABLE foo (a int, b int, c int) PARTITION BY list (b,c);
ERROR:  cannot use "list" partition strategy with more than one column
 
-- Альтернатива:
CREATE TYPE partkey as (b int, c int);
CREATE TABLE foo (a int, b int, c int)
PARTITION BY LIST ((row(b, c)::partkey));

Полезные ссылки

касательно использования партиционирования PostgreSQL:

Документация PostgreSQL касательно партиционирования таблиц: https://www.postgresql.org/docs/12/ddl-partitioning.html
Руководство по партиционированию PostgreSQL: https://www.youtube.com/watch?v=oJj-pltxBUM
Гид по партиционированию таблиц в PostgreSQL для новичков: https://medium.com/swlh/beginners-guide-to-table-partitioning-in-postgresql-5a014229042

← Предыдущая статья

20 команд разделения, доступные в Greenplum 7

Следующая статья →

Партиционирование в Greenplum