Сегментированная таблица состоит из нескольких секций. Некоторые из них являются обычными таблицами, а другие — сторонними. По умолчанию количество секций определяется параметром shardman.num_parts, но может быть перезаписано в параметре num_parts команды CREATE TABLE. Большинство операций DDL ограничены секциями сегментированной таблицы. Чтобы обойти это ограничение, следует изменять родительскую таблицу.

Количество секций в сегментированной таблице задаётся при её создании и не может быть изменено впоследствии. При добавлении новых узлов в кластер некоторые секции перемещаются с существующих узлов на новые, чтобы сбалансировать нагрузку. Таким образом, чтобы обеспечить масштабирование кластеров, начальных секций должно быть достаточно много, но не слишком много, поскольку слишком большое количество секций значительно замедляет планирование запросов. Например, если вы ожидаете, что количество узлов в вашем кластере вырастет максимум в 4 раза, создайте сегментированные таблицы с количеством секций, равным 4 * N, где N — это количество узлов. Предел масштабируемости кластера достигается, когда число узлов кластера достигает числа секций в сегментированной таблице с их минимальным количеством.

Реплицированные таблицы доступны для всех узлов кластера. Сейчас реплицированная таблица — это набор обычных таблиц, синхронизированных по триггерам. Основной вариант использования реплицированной таблицы — хранение относительно редко обновляемого набора данных, который используется всеми узлами кластера. Когда сегментированная таблица присоединяется к реплицированной таблице, соединения между сегментированными секциями таблицы и реплицированной таблицей могут выполняться на узлах, где находятся отдельные секции. Реализация репликации на основе триггеров требует, чтобы неоткладываемый первичный ключ был определён в реплицированной таблице. В настоящее время при изменении реплицированной таблицы срабатывает триггер оператора after, который распространяет изменения на другие узлы кластера через сторонние таблицы. Когда в кластер добавляются новые узлы, данные реплицированных таблиц передаются на новые узлы посредством логической репликации. Когда какие-либо узлы удаляются из кластера, реплицированные таблицы ненадолго блокируются для записи. Используйте параметр global в команде CREATE TABLE для создания реплицированной таблицы. Реплицированные таблицы регистрируются в словаре shardman.global_tables. Секционированные реплицированные таблицы не поддерживаются.

РасширениеPostgres Pro Shardman позволяет создавать несколько видов управляемых объектов. Это сегментированные и реплицированные таблицы, управляемые роли, последовательности и табличные пространства. Список операций, разрешённых для управляемых объектов, ограничен, в частности, для защиты согласованности управляемой схемы, типа или функции. Обратите внимание, что роли и табличные пространства управляются на более высоком уровне. По той же причине большинство операций над управляемыми объектами выполняются на уровне кластера. Список операций на уровне кластера включает:

Эти параметры конфигурации управляют выполнением команд распределённого DDL: shardman.broadcast_ddl и shardman.sync_schema. Первый можно использовать для трансляции всех обычных операций DDL (например, создания схем или функций) на весь кластер. Второй управляет трансляцией операторов, связанных с управляемыми объектами, и никогда не должен отключаться без консультации со службой поддержки Postgres Pro Shardman.

У распределённых таблиц есть ряд особенностей. Такие таблицы доступны на всех узлах кластера. Как у секционированных таблиц, у них есть несколько секций, число которых постоянно и не подлежит изменению без перезапуска. В каждом сегменте обычно хранится несколько секций данного сегмента, в то время как другие секции хранятся в другом месте. Обратите внимание, что эти секции взаимосвязаны.

Совмещённая таблица Postgres Pro Shardman — это секционированная таблица, состоящая из нескольких секций, которые размещены совместно с секциями распределённой таблицы в целях быстрого доступа. В таком случае секционирование обычно происходит по секциям, через сегментирование или по внешнему ключу для повышения эффективности. Такой сценарий рекомендован для больших JOIN.