Узлы и таблицы в Azure Cosmos DB для PostgreSQL

Область применения: Azure Cosmos DB для PostgreSQL (на базе расширения Citus для базы данных PostgreSQL)

Azure Cosmos DB для PostgreSQL позволяет серверам PostgreSQL (называемым узлам) координироваться друг с другом в архитектуре "общего ничего". Узлы в кластере совместно хранят больше данных и используют больше ядер ЦП, чем возможно на одном сервере. Архитектура также позволяет базе данных масштабироваться путем добавления дополнительных узлов в кластер.

Каждый кластер имеет узел координатора и несколько рабочих ролей. Приложения отправляют свои запросы на узел-координатор, который передает их соответствующим рабочим узлам и собирает результаты.

Azure Cosmos DB для PostgreSQL позволяет администратору базы данных распространять таблицы и схемы, сохраняя разные строки на разных рабочих узлах. Распределенные таблицы и(или) схемы являются ключом к производительности Azure Cosmos DB для PostgreSQL. Нераспределённые таблицы и (или) схемы остаются целиком на узле координатора и не могут воспользоваться параллелизмом между машинами.

Каждый запрос в распределенных таблицах координатор либо направляет в один рабочий узел, либо параллелизует по нескольким рабочим узлам в зависимости от того, находятся ли необходимые данные на одном узле или нескольких. С сегментированием на основе схемы координатор направляет запросы непосредственно на узел, на котором размещена схема. В шардинге на основе схем и шардинге на основе строк координатор решает, что делать, обращаясь к таблицам метаданных. Эти таблицы следят за DNS-именами и работоспособностью рабочих узлов, а также распределением данных между узлами.

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

Первый и наиболее распространенный тип — это распределенные таблицы. Для инструкций SQL они выглядят как обычные таблицы, но они горизонтально разделены между рабочими узлами. Это означает, что строки таблицы хранятся на разных узлах в таблицах фрагментов, называемых сегментами.

Azure Cosmos DB для PostgreSQL выполняет не только инструкции SQL, но и DDL в кластере. Изменение схемы распределенной таблицы каскадно обновляет все сегменты таблицы на рабочих узлах.

Azure Cosmos DB для PostgreSQL использует алгоритмическое сегментирование для назначения строк сегментам. Присваивание выполняется детерминировано на основе значения столбца таблицы, называемого столбцом распределения. Администратор кластера должен назначить этот столбец при распределении таблицы. Правильный выбор важен для производительности и функциональности.

Ссылочная таблица — это тип распределенной таблицы, все содержимое которой сконцентрировано в одном сегменте. Этот сегмент реплицируется на каждый рабочий узел. Запросы к любому рабочему узлу могут обращаться к ссылочным сведениям локально, без дополнительных накладных расходов сети на запрос строк из другого узла. В ссылочных таблицах столбец распределения отсутствует, поскольку различать отдельные сегменты для строк не нужно.

Ссылочные таблицы обычно невелики и используются для хранения данных, относящихся к запросам, выполняемым на любом рабочем узле. Примером являются перечисляемые значения, такие как состояние заказов или категории продуктов.

При использовании Azure Cosmos DB для PostgreSQL узел координатора, к которому вы подключаетесь, является обычной базой данных PostgreSQL. Можно создать обычные таблицы в координаторе и отказаться от их сегментирования.

Хорошим кандидатом для локальных таблиц являются небольшие административные таблицы, не участвующие в запросах присоединения. Примером является users таблица для входа и проверки подлинности приложения.

Azure Cosmos DB для PostgreSQL может автоматически добавлять локальные таблицы в метаданные, если ссылка на внешний ключ существует между локальной таблицей и эталонной таблицей. Кроме того, локально управляемые таблицы можно создать вручную, выполнив функцию create_reference_table citus_add_local_table_to_metadata в обычных локальных таблицах. Таблицы, присутствующих в метаданных, считаются управляемыми таблицами и могут запрашиваться с любого узла, Citus знает, как направляться координатору для получения данных из локальной управляемой таблицы. Такие таблицы отображаются как локальные в представлении citus_tables.

При использовании сегментирования на основе схемы, введенного в Citus 12.0, распределенные схемы автоматически связываются с отдельными группами совместного размещения. Таблицы, созданные в этих схемах, автоматически преобразуются в совместно размещенные распределенные таблицы без ключа сегмента. Такие таблицы считаются таблицами схемы и отображаются в представлении citus_tables.

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

Таблица метаданных pg_dist_shard на узле-координаторе содержит по одной строке для каждого сегмента каждой распределенной таблицы в системе. Строка соответствует идентификатору сегмента с диапазоном целых чисел в пространстве хэша (shardminvalue, shardmaxvalue).

SELECT * from pg_dist_shard;
 logicalrelid  | shardid | shardstorage | shardminvalue | shardmaxvalue
---------------+---------+--------------+---------------+---------------
 github_events |  102026 | t            | 268435456     | 402653183
 github_events |  102027 | t            | 402653184     | 536870911
 github_events |  102028 | t            | 536870912     | 671088639
 github_events |  102029 | t            | 671088640     | 805306367
 (4 rows)

Если узел-координатор хочет определить, какой сегмент содержит строку github_events, он хэширует значение столбца распределения в строке. Затем узел проверяет, какой диапазон сегмента содержит хэшированное значение. Диапазоны определены так, чтобы образ хэш-функции был их непересекающимся объединением.

Предположим, что сегмент 102027 связан с интересующей строкой. Строка читается или записывается в таблицу github_events_102027 одним из работников. Какой рабочий? Это полностью определяется таблицами метаданных. Сопоставление шарда с рабочим называется размещением шарда.

Узел-координатор перезаписывает запросы во фрагменты, ссылающиеся на конкретные таблицы, например github_events_102027, и выполняет эти фрагменты на соответствующих рабочих ролях. Ниже приведен пример запроса, выполняемого в фоновом режиме для поиска узла, содержащего сегмент с идентификатором 102027.

SELECT
    shardid,
    node.nodename,
    node.nodeport
FROM pg_dist_placement placement
JOIN pg_dist_node node
  ON placement.groupid = node.groupid
 AND node.noderole = 'primary'::noderole
WHERE shardid = 102027;

┌─────────┬───────────┬──────────┐
│ shardid │ nodename  │ nodeport │
├─────────┼───────────┼──────────┤
│  102027 │ localhost │     5433 │
└─────────┴───────────┴──────────┘

• Определение типа приложения для подготовки к моделированию данных
• Проверьте сегменты и размещения с помощью полезных диагностических запросов.