Nodos y tablas en Azure Cosmos DB for PostgreSQL

  • Artículo

SE APLICA A: Azure Cosmos DB for PostgreSQL (con tecnología de la extensión de base de datos de Citus en PostgreSQL)

Nodos

Azure Cosmos DB for PostgreSQL permite a los servidores de PostgreSQL (llamados "nodos") coordinarse entre sí 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. La arquitectura también permite escalar la base de datos al agregar más nodos al clúster.

Coordinación y trabajos

Cada clúster un nodo de coordinación y varios trabajos. Las aplicaciones envían sus consultas al nodo de coordinación, que las retransmite a los trabajos pertinentes y acumula los resultados.

Azure Cosmos DB for PostgreSQL permite al administrador de bases de datos distribuir tablas y esquemas y almacenar distintas filas en nodos de trabajo diferentes. Las tablas y esquemas distribuidos son la clave para el rendimiento de Azure Cosmos DB for PostgreSQL. Si no se distribuyen las tablas y esquemas, las deja totalmente en el nodo de coordinación y no pueden aprovechar el paralelismo entre máquinas.

Para cada consulta sobre las tablas distribuidas, el coordinador la enruta a un único nodo de trabajo o la paraleliza en varias según si los datos necesarios se encuentren en un único nodo o en varios. Con particionamiento basado en esquemas, el coordinador enruta las consultas directamente al nodo que hospeda el esquema. En el particionamiento basado en esquemas y particionamiento basado en filas, el coordinador decide qué hacer mediante la consulta de tablas de metadatos. Estas tablas hacen un seguimiento de los nombres DNS y del estado de los nodos de trabajo, y de la distribución de datos entre nodos.

Tipos de tablas

Hay cinco tipos de tablas en un clúster, cada una se almacena de forma distinta y se usa con distintos fines.

Tipo 1: Tablas distribuidas

El primer tipo, y el más común, es la tabla distribuida. Aparece como una tabla normal para las instrucciones SQL, pero está particionada horizontalmente en nodos de trabajo. Esto significa que las filas de la tabla se almacenan en nodos diferentes, en tablas de fragmentos llamadas particiones de base de datos.

Azure Cosmos DB for PostgreSQL no solo ejecuta instrucciones SQL en un clúster, sino también DDL. El cambio del esquema de una tabla distribuida se propaga para actualizar todas las particiones de la tabla en los nodos de trabajo.

Columna de distribución

Azure Cosmos DB for PostgreSQL usa particionamiento algorítmico para asignar filas a particiones. La asignación se realiza de forma determinista en función del valor de una columna de la tabla denominada columna de distribución. El administrador de clústeres debe designar esta columna al distribuir una tabla. Realizar la elección correcta es importante para el rendimiento y la funcionalidad.

Tipo 2: tablas de referencia

Una tabla de referencia es un tipo de tabla distribuida en la que todo su contenido se concentra en una sola partición de base de datos. La partición se replica en todos los nodos de trabajo. Las consultas en cualquier nodo pueden acceder a la información de referencia localmente, sin la sobrecarga de red que supone solicitar filas de otro nodo. Las tablas de referencia no tienen columna de distribución porque no es necesario distinguir particiones de base de datos independientes por cada fila.

Las tablas de referencia suelen ser pequeñas y se usan para almacenar los datos que son pertinentes para las consultas que se ejecutan en cualquier nodo de trabajo. Por ejemplo, valores enumerados, como los estados de pedidos o las categorías de productos.

Tipo 3: tablas locales

Cuando se usa Azure Cosmos DB for PostgreSQL, el nodo de coordinación al que se conecta es una base de datos PostgreSQL normal. Puede crear tablas normales en el coordinador y elegir no particionarlas.

Un buen candidato para las tablas locales serían pequeñas tablas administrativas que no participan en las consultas de combinación. Por ejemplo, una tabla de users para el inicio de sesión en una aplicación y la autenticación.

Tipo 4: Tablas administradas locales

Azure Cosmos DB for PostgreSQL podría agregar automáticamente tablas locales a metadatos si existe una referencia de clave externa entre una tabla local y una tabla de referencia. Además, las tablas administradas localmente se pueden crear manualmente ejecutando la función create_reference_table citus_add_local_table_to_metadata en tablas locales normales. Las tablas presentes en los metadatos se consideran tablas administradas y se pueden consultar desde cualquier nodo, Citus sabe enrutar al coordinador para obtener datos de la tabla administrada local. Estas tablas se muestran como locales en la vista citus_tables.

Tipo 5: Tablas de esquema

Con particionamiento basado en esquemas introducido en Citus 12.0, los esquemas distribuidos se asocian automáticamente a grupos de coubicación individuales. Las tablas creadas en esos esquemas se convierten automáticamente en tablas distribuidas colocadas sin una clave de partición. Estas tablas se consideran tablas de esquema y se muestran como esquemas en la vista citus_tables.

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 tratan detalles más técnicos.

La tabla de metadatos pg_dist_shard del coordinador contiene una fila para cada partición de base de datos de cada tabla distribuida en el sistema. La fila asocia un identificador 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 de coordinación 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. ¿Qué trabajo? Esto lo determinan por completo las tablas de metadatos. 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 de coordinación 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 │
└─────────┴───────────┴──────────┘

Pasos siguientes