Compartir a través de

Clústeres elásticos en Azure Database for PostgreSQL: servidor flexible

SE APLICA A: Azure Database for PostgreSQL con servidor flexible

El clúster elástico en el servidor flexible de Azure Database for PostgreSQL es una oferta administrada de la extensión Citus de código abierto para PostgreSQL que habilita el particionamiento horizontal de PostgreSQL.

Aunque Citus es solo una extensión, conecta varias instancias de PostgreSQL. Cuando el servidor flexible de Azure Database for PostgreSQL se implementa con Citus, controla la administración y configuración de varias instancias de PostgreSQL como un único recurso. También configura automáticamente los nodos y los hace conocidos por la extensión Citus.

Los clústeres elásticos en un servidor flexible ofrecen dos modelos de particionamiento: un particionamiento basado en filas y otro basado en esquemas. Consulte la documentación de código abierto sobre modelos de particionamiento, si quiere obtener más información.

Arquitectura

Un clúster elástico consta de uno o varios nodos del servidor flexible de Azure Database for PostgreSQL. Estas instancias se conocen automáticamente entre sí y se interconectan para formar un clúster de Citus. Los nodos deben ser del mismo nivel de proceso y almacenamiento, y se pueden escalar uniformemente de manera vertical o reducir a niveles superiores o inferiores.

El clúster elástico usa servidores flexibles (denominados nodos) para coordinarse con otros en una arquitectura de "nada compartido". Los nodos de un clúster almacenan colectivamente más datos y usan más núcleos de CPU de lo que sería posible en un único servidor. Esta arquitectura también permite escalar la base de datos al agregar más nodos al clúster.

La conexión al clúster mediante el puerto 5432 le llega en el nodo de coordinación designado. Los clústeres elásticos también permiten equilibrar la carga de las conexiones en el clúster mediante un método hash de cinco tuplas, si se conecta mediante el puerto 7432. Con el 7432 todavía puede aterrizar en el nodo de coordinación designado actualmente. Para determinadas operaciones de todo el clúster, como la distribución de tablas, es posible que tenga que conectarse a través del puerto 5432. Se recomienda encarecidamente conectarse siempre por el puerto 5432, cuando planee realizar actualizaciones de esquema de aplicación y cambios similares.

A diferencia de Cosmos DB para PostgreSQL, las direcciones de nodo no se exponen externamente. Si examina las tablas de metadatos de Citus como pg_dist_node, es posible que observe que todos los nodos tienen la misma dirección IP que en el ejemplo 10.7.0.254, pero un número de puertos diferente.

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)

En la infraestructura de Azure, estos nodos residen en diferentes máquinas virtuales aunque parezcan diferentes puertos en la misma máquina.

Para más información sobre Citus, puede consultar la documentación oficial del proyecto de código abierto.

De forma predeterminada, las tablas y esquemas creados con Citus no se distribuyen automáticamente entre el clúster. Debe decidir sobre un modelo de particionamiento y decidir distribuir esquemas o decidir distribuir los datos de la tabla con particionamiento basado en filas.

Para cada consulta en tablas distribuidas, el nodo consultado lo enruta a un solo nodo o lo paraleliza en varios nodos. La decisión depende de si los datos necesarios residen en un solo nodo o en varios. Con particionamiento basado en esquemas, el coordinador enruta las consultas directamente al nodo que hospeda el esquema. Tanto en el particionamiento basado en esquemas como en el particionamiento basado en filas, el nodo decide qué hacer mediante la consulta de tablas de metadatos. Estas tablas realizan un seguimiento de la ubicación y el estado de los nodos y la distribución de datos entre nodos.

Una vez que los datos se distribuyen mediante uno de los modelos compartidos, puede conectarse a cualquiera de los nodos para realizar operaciones DML (Lenguaje de modificación de datos) (SELECT, UPDATE, INSERT, DELETE). Todos los nodos contienen los metadatos necesarios para localizar los datos necesarios para la consulta y pueden obtenerlos para responder a la consulta.

Actualmente, las operaciones de DDL (lenguaje de definición de datos) y las operaciones en todo el clúster están limitadas al nodo que contiene el rol de coordinador. Asegúrese de que las operaciones DDL y de todo el clúster se realizan mediante la conexión al puerto 5432 en lugar de usar el puerto 7432.

Puede escalar horizontalmente un clúster elástico agregando nuevos nodos y reequilibrando los datos en él. El reequilibrio es una operación en línea y no bloquea la ejecución de cargas de trabajo.

Particiones de base de datos

En la sección anterior, se describe la manera en que las tablas distribuidas se almacenan como particiones de base de datos en nodos de trabajo. En esta sección se describen detalles más técnicos sobre estas particiones.

La tabla de metadatos pg_dist_shard contiene una fila para cada partición de base de datos de cada tabla distribuida en el sistema. La fila asocia un identificador (shardid) de partición con un intervalo de enteros en un espacio de hash (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)

Si el nodo quiere determinar qué partición de base de datos contiene una fila de github_events, aplica un algoritmo hash al valor de la columna de distribución de la fila. A continuación, comprueba qué intervalo de la partición de base de datos contiene el valor con hash. Los intervalos se definen de modo que la imagen de la función hash sea su unión independiente.

Colocaciones de particiones

Supongamos que la partición de base de datos 102027 está asociada a la fila en cuestión. La fila se leerá o escribirá en una tabla denominada github_events_102027 de uno de los nodos de trabajo. Con la información almacenada en las tablas de metadatos, la extensión determina qué es ese trabajo específico. La asignación de la partición de base de datos a un nodo de trabajo se conoce como colocación de la partición.

El nodo vuelve a escribir consultas en fragmentos que hacen referencia a las tablas específicas como github_events_102027, y ejecuta esos fragmentos en los nodos de trabajo adecuados. Este es un ejemplo de una consulta que se ejecuta en segundo plano para buscar el nodo que contiene el identificador de partición de base de datos 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 │
└─────────┴───────────┴──────────┘

Contenido relacionado