Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Los clústeres elásticos del servicio Azure Database for PostgreSQL son una oferta administrada de la extensión Citus de código abierto a PostgreSQL que habilita el particionamiento horizontal de PostgreSQL.
Aunque Citus es solo una extensión, conecta varias instancias de PostgreSQL. Al implementar un servidor flexible Azure Database for PostgreSQL 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 del servicio ofrecen dos modelos de particionamiento: particionamiento basado en filas y particionamiento basado en esquemas. Para más información, consulte la documentación de código abierto sobre los modelos de particionamiento.
Architecture
Un clúster elástico consta de uno o varios nodos de Azure Database for PostgreSQL servidores flexibles. Estas instancias se detectan automáticamente e interconectan para formar un clúster de Citus. Los nodos deben ser el mismo nivel de proceso y almacenamiento, y puede escalarlos de forma uniforme a niveles superiores o inferiores.
Los clústeres elásticos usan instancias de servidores flexibles (denominados nodos) para coordinarse entre sí en una arquitectura de "nada compartido". Esta arquitectura también permite escalar la base de datos al agregar más nodos al clúster.
Los clústeres elásticos usan servidores flexibles (denominados nodos) para coordinarse entre sí en una arquitectura de nada compartido . La arquitectura también permite escalar la base de datos al agregar más nodos al clúster.
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, consulte 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 el fragmento 102027 está asociado 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. Utilizando la información almacenada en las tablas de metadatos, la extensión determina qué proceso de trabajo específico utilizar. 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 │
└─────────┴───────────┴──────────┘