Nodi e tabelle in Azure Cosmos DB for PostgreSQL

SI APPLICA A: Azure Cosmos DB for PostgreSQL (basato su estensione database Citus per PostgreSQL)

Nodi

Azure Cosmos DB for PostgreSQL consente ai server PostgreSQL (denominati nodi) di coordinarsi tra loro in un’architettura condivisa "senza condivisioni". I nodi in un cluster contengono collettivamente più dati e usano più core CPU di quanto sarebbe possibile in un singolo server. L'architettura inoltre consente al database di dimensionare aggiungendo altri nodi al cluster.

Coordinatore e ruoli di lavoro

Ogni cluster ha un nodo coordinatore e più ruoli di lavoro. Le applicazioni inviano le query al nodo coordinatore, che le inoltra ai ruoli di lavoro pertinenti e accumula i relativi risultati.

Azure Cosmos DB for PostgreSQL consente all'amministratore del database di distribuire tabelle e/o schemi, archiviando righe diverse in nodi di lavoro diversi. Le tabelle distribuite e/o gli schemi sono fondamentali per le prestazioni di Azure Cosmos DB for PostgreSQL. La mancata distribuzione di tabelle e/o schemi li lascia interamente sul nodo coordinatore e non può sfruttare il parallelismo tra computer.

Per ogni query su tabelle distribuite, il coordinatore le instrada a un singolo nodo di lavoro o le parallelizza in più nodi di lavoro, a seconda che i dati necessari si trovino in un singolo nodo o in più nodi. Con il partizionamento orizzontale basato su schema, il coordinatore instrada le query direttamente al nodo che ospita lo schema. Sia nel partizionamento orizzontale basato su schema che nel partizionamento orizzontale basato su righe, il coordinatore decide cosa fare consultando le tabelle dei metadati. Queste tabelle tengono traccia dei nomi DNS e dell'integrità dei nodi di lavoro e della distribuzione dei dati tra i nodi.

Tipi di tabella

Esistono cinque tipi di tabelle in un cluster, ognuna archiviata in modo diverso nei nodi e usata per scopi diversi.

Tipo 1: Tabelle distribuite

Tabelle distribuite è il primo tipo, e anche il più frequente. Sembrano essere tabelle normali per istruzioni SQL, ma sono partizionate orizzontalmente tra i nodi di lavoro. Questo significa che le righe della tabella vengono archiviate in nodi diversi, in tabelle di frammenti denominate partizioni.

Azure Cosmos DB for PostgreSQL esegue non solo SQL ma anche istruzioni DDL in un cluster. Modifica dello schema di una tabella distribuita a cascata per aggiornare tutte le partizioni della tabella tra i ruoli di lavoro.

Colonna di distribuzione

Azure Cosmos DB for PostgreSQL usa il partizionamento orizzontale algoritmico per assegnare righe alle partizioni. L'assegnazione viene eseguita in modo deterministico in base al valore di una colonna di tabella denominata colonna di distribuzione. L'amministratore del cluster deve designare questa colonna durante la distribuzione di una tabella. Fare la scelta giusta è importante ai fini delle prestazioni e della funzionalità.

Tipo 2: Tabelle di riferimento

Una tabella di riferimento è un tipo di tabella distribuita il cui intero contenuto viene concentrato in una singola partizione. La partizione viene replicata in ogni ruolo di lavoro. Le query su qualsiasi ruolo di lavoro possono accedere alle informazioni di riferimento in locale, senza il sovraccarico di rete della richiesta di righe da un altro nodo. Le tabelle di riferimento non hanno una colonna di distribuzione perché non è necessario distinguere le partizioni separate per riga.

In genere le tabelle di riferimento sono di piccole dimensioni e vengono usate per archiviare i dati rilevanti per le query in esecuzione nei nodi di lavoro. Un esempio è costituito da valori enumerati, ad esempio gli stati degli ordini o le categorie di prodotti.

Tipo 3: Tabelle locali

Quando si usa Azure Cosmos DB for PostgreSQL, il nodo coordinatore a cui ci si connette è un normale database PostgreSQL. È possibile creare tabelle comuni nel coordinatore e scegliere di non partizionarle.

Le tabelle amministrative di piccole dimensioni che non partecipano alle query di join rappresentano la scelta migliore per le tabelle locali. Un esempio è una tabella users per l'accesso e l'autenticazione dell'applicazione.

Tipo 4: Tabelle gestite locali

Azure Cosmos DB for PostgreSQL potrebbe aggiungere automaticamente tabelle locali ai metadati se esiste un riferimento di chiave esterna tra una tabella locale e una tabella di riferimento. Inoltre è possibile creare manualmente le tabelle gestite localmente eseguendo la funzionecreate_reference_table citus_add_local_table_to_metadata nelle normali tabelle locali. Le tabelle presenti nei metadati sono considerate tabelle gestite e possono essere sottoposte a query da qualsiasi nodo che Citus sa indirizzare al coordinatore per ottenere dati dalla tabella gestita locale. Tali tabelle vengono visualizzate come locali nella vista citus_tables.

Tipo 5: Tabelle dello schema

Con il partizionamento orizzontale basato su schema introdotto in Citus 12.0, gli schemi distribuiti vengono associati automaticamente ai singoli gruppi di coubicazione. Le tabelle create in tali schemi vengono convertite automaticamente in tabelle distribuite coubicate senza una chiave di partizione. Tali tabelle sono considerate tabelle dello schema e vengono visualizzate come schemi nella vista citus_tables.

Partizioni

Nella sezione precedente si è descritto in che modo le tabelle distribuite vengono archiviate come partizioni nei nodi di lavoro. Questa sezione descrive ulteriori dettagli tecnici.

La tabella dei metadati pg_dist_shard nel coordinatore contiene una riga per ciascuna partizione di ogni tabella distribuita nel sistema. La riga corrisponde a un ID partizione con un intervallo di interi in uno spazio 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)

Se il nodo coordinatore vuole determinare quale partizione contiene una riga di github_events, esegue il digest del valore della colonna di distribuzione nella riga. Il nodo controlla quindi quale intervallo di partizione contiene il valore hash. Gli intervalli vengono definiti in modo che l'immagine della funzione hash sia la loro unione disgiunta.

Posizionamenti partizioni

Si supponga che la partizione 102027 sia associata alla riga in questione. La riga viene letta o scritta in una tabella denominata github_events_102027 in uno dei ruoli di lavoro. Quale ruolo di lavoro? Questo è determinato interamente dalle tabelle di metadati. Il mapping della partizione per il ruolo di lavoro è noto come posizionamento della partizione.

Il nodo coordinatore riscrive le query in frammenti che fanno riferimento a tabelle specifiche quali github_events_102027, ed esegue tali frammenti nei ruoli di lavoro appropriati. Di seguito è riportato un esempio di esecuzione di query in background per trovare il nodo che contiene l'ID partizione 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 │
└─────────┴───────────┴──────────┘

Passaggi successivi

• Determinare il tipo di applicazione da preparare per la modellazione dei dati
• Esaminare partizioni e posizionamento con query di diagnostica utili.