Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
I cluster elastici nel servizio Database di Azure per PostgreSQL sono un'offerta gestita dell'estensione Citus open source per PostgreSQL che consente il partizionamento orizzontale di PostgreSQL.
Sebbene Citus sia solo un'estensione, connette più istanze di PostgreSQL. Quando un'istanza del server flessibile di Database di Azure per PostgreSQL viene distribuita con Citus, gestisce la gestione e la configurazione di più istanze di PostgreSQL come singola risorsa. Configura automaticamente anche i nodi e li rende noti all'estensione Citus.
I cluster elastici nel servizio offrono due modelli di partizionamento orizzontale: partizionamento orizzontale basato su righe e partizionamento orizzontale basato su schema. Per altre informazioni, vedere la documentazione open source sui modelli di partizionamento orizzontale.
Architettura
Un cluster elastico è costituito da uno o più nodi delle istanze del server flessibile di Database di Azure per PostgreSQL. Queste istanze vengono rese automaticamente note e connesse tra loro per formare un cluster Citus. I nodi devono appartenere allo stesso livello di calcolo e archiviazione e possono essere scalati uniformemente verso l’alto o verso il basso a livelli superiori o inferiori.
I cluster elastici usano istanze di server flessibili (denominati nodi) per coordinarsi tra loro in un'architettura "nulla condiviso". L'architettura inoltre consente al database di dimensionare aggiungendo altri nodi al cluster.
La connessione al cluster tramite la porta 5432 raggiunge il nodo coordinatore designato. I cluster elastici consentono anche di bilanciare il carico delle connessioni nel cluster usando un metodo hash a cinque tuple, se ci si connette usando la porta 7432. Usando 7432 è comunque possibile atterrare nel nodo attualmente designato come coordinatore. Per determinate operazioni a livello di cluster, ad esempio la distribuzione di tabelle, potrebbe essere necessario connettersi sulla porta 5432. È consigliabile connettersi sempre alla porta 5432, quando si prevede di eseguire aggiornamenti dello schema dell'applicazione e modifiche simili. Se si abilita PgBouncer nei cluster elastici, è possibile usare la porta 8432 per bilanciare il carico delle connessioni tra le istanze di PgBouncer in ogni nodo (o usare la porta 6432 per il coordinatore designato).
A differenza di Cosmos DB per PostgreSQL, gli indirizzi dei nodi non vengono esposti esternamente. Se si esaminano tabelle di metadati Citus come pg_dist_node, è possibile notare che tutti i nodi hanno lo stesso indirizzo IP dell'esempio 10.7.0.254 ma numeri di porta diversi.
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)
Nell'infrastruttura di Azure, questi nodi si trovano in macchine virtuali diverse, sebbene possano sembrare porte diverse nello stesso computer.
Per altre informazioni su Citus, è possibile fare riferimento alla documentazione ufficiale del progetto open source.
Per impostazione predefinita, le tabelle e gli schemi creati con Citus non vengono distribuiti automaticamente tra il cluster. È necessario scegliere un modello di partizionamento orizzontale e decidere di distribuire gli schemi o i dati della tabella con il partizionamento orizzontale basato su righe.
Per ogni query su tabelle distribuite, il nodo sottoposto a query lo instrada a un singolo nodo o lo parallelizza tra più nodi. La decisione dipende dal fatto che i dati necessari si trovino su un singolo nodo o su 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 nodo decide cosa fare consultando le tabelle dei metadati. Queste tabelle tengono traccia della posizione e dell'integrità dei nodi e della distribuzione dei dati tra i nodi.
Una volta distribuiti i dati usando uno dei modelli di partizionamento orizzontale, è possibile connettersi a uno dei nodi per eseguire operazioni DML (Data Modification Language) (SELECT, UPDATE, INSERT, DELETE). Tutti i nodi contengono i metadati per individuare i dati necessari per la query e possono ottenerli per rispondere alla query.
Le operazioni DDL (Data Definition Language) e le operazioni a livello di cluster sono attualmente limitate al nodo che ha il ruolo di coordinatore. Assicurarsi di eseguire operazioni DDL e a livello di cluster connettendosi alla porta 5432, invece di usare la porta 7432.
È possibile scalare un cluster elastico aggiungendo nuovi nodi e ribilanciare i dati al suo interno. Il ribilanciamento è un'operazione online e non blocca l'esecuzione dei carichi di lavoro.
Partizioni
Nella sezione precedente si è descritto in che modo le tabelle distribuite vengono archiviate come partizioni nei nodi di lavoro. In questa sezione vengono illustrati più dettagli tecnici su queste partizioni.
La tabella di metadati pg_dist_shard contiene una riga per ogni partizione di ogni tabella distribuita nel sistema. La riga corrisponde a un identificatore di partizione (shardid) con un intervallo di numeri 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 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. Con le informazioni archiviate nelle tabelle di metadati, l'estensione determina il ruolo di lavoro specifico. Il mapping della partizione per il ruolo di lavoro è noto come posizionamento della partizione.
Il nodo riscrive le query in frammenti che fanno riferimento a tabelle specifiche come github_events_102027 ed esegue tali frammenti nei ruoli di lavoro appropriati. Di seguito è riportato un esempio di esecuzione di una query in background volta a trovare il nodo che contiene la partizione con identificatore 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 │
└─────────┴───────────┴──────────┘