Esaminare le funzionalità non supportate

  • 2 minuti

È possibile usare l'estensione Citus open source per PostgreSQL per fornire la funzionalità distribuita in Azure Cosmos DB per PostgreSQL. Usa i costrutti SQL PostgreSQL standard, quindi la maggior parte delle query è supportata, anche quando combinano i dati in rete da più nodi di database. Questo supporto include la semantica transazionale tra i nodi. Attualmente, tutto SQL è supportato, ad eccezione di:

  • Sottoquery correlate
  • CTE ricorsive
  • Esempio di tabella
  • edizione Standard LECT ... FOR UPDATE
  • Set di raggruppamento

Inoltre, le query che accedono a un singolo nodo nel cluster dispongono del supporto SQL del 100%. Ad esempio, l'esecuzione di query sulla tabella di payment_events Woodgrove Bank per recuperare tutte le transazioni in cui user_id = 87 accede ai dati in una singola partizione che risiede in un singolo nodo. È possibile usare l'istruzione EXPLAIN per visualizzare il piano di query:

EXPLAIN SELECT * FROM payment_events WHERE user_id = 87;

L'output mostra un numero di attività pari a 1 su shardid 102235, la partizione in cui risiedono i dati per user_id 87.

Custom Scan (Citus Adaptive)  (cost=0.00..0.00 rows=0 width=0)
   Task Count: 1
   Tasks Shown: All
   ->  Task
         Node: host=private-w1.learn-cosmosdb-postgresql.postgres.database.azure.com port=5432 dbname=citus
         ->  Index Scan using payment_events_pkey_102235 on payment_events_102235 payment_events  (cost=0.28..65.23 rows=2 width=126)
               Index Cond: (user_id = 87)

Queste query sono comuni, ad esempio, nelle applicazioni multi-tenant in cui nodi diversi archiviano tenant diversi. Tuttavia, è fondamentale ricordare che, anche con un'ampia copertura SQL, la modellazione dei dati può influire significativamente sulle prestazioni delle query.

Limitazioni dei vincoli nelle tabelle distribuite

L'uso di Azure Cosmos DB per PostgreSQL consente di continuare a godere della sicurezza di un database relazionale, inclusi i vincoli di database. Tuttavia, esiste una limitazione. A causa della natura dei sistemi distribuiti, non è possibile creare vincoli di univocità tra riferimenti o integrità referenziale tra nodi di lavoro.

Ad esempio, Woodgrove Bank vuole aggiungere un UNIQUE vincolo tra eventi e commercianti per ogni transazione. Se si tenta di creare la combinazione dei event_id campi e merchant_id una chiave nella payment_events tabella, si riceverà un errore.

-- Will not work
ALTER TABLE payment_events ADD CONSTRAINT event_merchant UNIQUE (event_id, merchant_id);

ERROR:  cannot create constraint on "payment_events"
DETAIL:  Distributed relations cannot have UNIQUE, EXCLUDE, or PRIMARY KEY constraints that do not include the partition column (with an equality operator if EXCLUDE).

Tenere presente che la payment_events tabella viene distribuita nella user_id colonna . In una tabella distribuita, il meglio che è possibile fare è rendere univoca la colonna di distribuzione della colonna:

ALTER TABLE payment_events ADD CONSTRAINT event_merchant UNIQUE (user_id, event_id, merchant_id);

Il vincolo precedente rende merchant_id solo univoco per utente ed evento.