Поделиться через

Эластичные кластеры в База данных Azure для PostgreSQL — гибкий сервер

  • Статья

ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных Azure для PostgreSQL — гибкий сервер

Эластичные кластеры на гибком сервере База данных Azure для PostgreSQL — это управляемое предложение расширения Citus с открытым исходным кодом для PostgreSQL, которое обеспечивает горизонтальное сегментирование PostgreSQL.

Хотя Citus является просто расширением, он подключает несколько экземпляров PostgreSQL. При развертывании гибкого сервера База данных Azure для PostgreSQL с помощью Citus он обрабатывает управление и настройку нескольких экземпляров PostgreSQL в качестве одного ресурса. Он также автоматически настраивает узлы и делает их известными для расширения Citus.

Эластичные кластеры на гибком сервере предлагают две модели сегментирования: сегментирование на основе строк и сегментирование на основе схем. Дополнительные сведения см. в документации по сегментированию моделей с открытым кодом.

Архитектура

Эластичные кластеры состоят из одного или нескольких узлов База данных Azure для PostgreSQL гибкого сервера. Эти экземпляры автоматически становятся известны друг другу и подключены к кластеру Citus. Узлы должны быть одинаковыми уровнями вычислений и хранилища, а также могут быть равномерно масштабироваться вверх или вниз до более высоких или более низких уровней.

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

Подключение к кластеру с помощью порта 5432 приземляется на назначенном узле координатора. Эластичные кластеры также позволяют распределять нагрузку между кластерами с помощью метода хэширования с пятью кортежами, если вы подключаетесь с помощью порта 7432. Используя 7432, вы можете по-прежнему приземлиться на узле, назначенном в настоящее время в качестве координатора. Для некоторых операций на уровне кластера, таких как распространение таблиц, может потребоваться подключиться через порт 5432. Настоятельно рекомендуется всегда подключаться к порту 5432 при планировании обновления схемы приложения и аналогичных изменений.

В отличие от Cosmos DB для PostgreSQL, адреса узлов не предоставляются внешним образом. При просмотре таблиц метаданных Citus, например pg_dist_node, можно заметить, что все узлы имеют один и тот же IP-адрес, что и в примере 10.7.0.254 , но разные номера портов.

select nodeid, nodename, nodeport from pg_dist_node;

 nodeid |  nodename  | nodeport
--------+------------+----------
      1 | 10.7.0.254 |     7000
      2 | 10.7.0.254 |     7001
 
(2 rows)

В инфраструктуре Azure эти узлы живут на разных виртуальных машинах, даже если они могут быть разными портами на одном компьютере.

Дополнительные сведения о Citus см. в официальной документации по проекту с открытым исходным кодом.

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

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

После распространения данных с помощью одной из моделей сегментирования можно подключиться к любому из узлов для выполнения операций DML (язык изменения данных) (SELECT, UPDATE, INSERT, DELETE). Все узлы содержат метаданные, необходимые для поиска данных, необходимых для запроса, и могут получить его для ответа на запрос.

Операции DDL (язык определения данных) и широкие операции кластера в настоящее время ограничены узлом, где находится роль координатора. Убедитесь, что вы выполняете операции DDL и кластера, подключаясь к порту 5432, а не с помощью порта 7432.

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

Сегменты

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

Таблица pg_dist_shard метаданных содержит строку для каждого сегмента каждой распределенной таблицы в системе. Строка соответствует идентификатору сегмента (shardid) с диапазоном целых чисел в хэш-пространстве (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 │
└─────────┴───────────┴──────────┘

Связанный контент