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

  • Статья

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

Узлы

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

Координатор и рабочие роли

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

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

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

Типы таблиц

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

Тип 1. Распределенные таблицы

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

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

Столбец распределения

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

Тип 2. Ссылочные таблицы

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

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

Тип 3. Локальные таблицы

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

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

Тип 4. Локальные управляемые таблицы

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

Тип 5. Таблицы схем

При использовании сегментирования на основе схемы, введенного в 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 │
└─────────┴───────────┴──────────┘

Следующие шаги