Migrazione da PostgreSQL ad Aurora SQL

Utilizzatelo CREATE INDEX ASYNC al posto di quello CREATE INDEX per la creazione di indici non bloccanti.

Vantaggio: creazione di indici senza tempi di inattività su tabelle di grandi dimensioni.

Utilizzare DELETE FROM table_name al posto diTRUNCATE.

Alternativa: per una completa ricreazione a tavola, utilizzare DROP TABLE seguito daCREATE TABLE.

Aurora DSQL non supporta ALTER SYSTEM i comandi perché il sistema è completamente gestito. La configurazione viene gestita automaticamente in base ai modelli di carico di lavoro.

Vantaggio: non è necessario ottimizzare il database o gestire i parametri.

Usa le UUIDs nostre chiavi composite invece di sequenze ad incremento automatico. Le sequenze ad incremento automatico portano a un'elevata quantità di conflitti in un sistema distribuito poiché più autori cercano di aggiornare gli stessi dati. UUIDs forniscono la stessa funzione ma non richiedono alcun coordinamento.

Esempio: id UUID PRIMARY KEY DEFAULT gen_random_uuid()

Aurora DSQL supporta le relazioni e le JOIN operazioni tra tabelle ma non impone ancora vincoli di chiave esterna. Questa scelta progettuale si allinea ai moderni modelli di database distribuiti in cui la convalida a livello di applicazione offre maggiore flessibilità ed evita i colli di bottiglia delle prestazioni dovuti alle operazioni a cascata.

Modello: implementa i controlli di integrità referenziale a livello di applicazione utilizzando convenzioni di denominazione, logica di convalida e limiti di transazione coerenti. Molte applicazioni su larga scala preferiscono questo approccio per un migliore controllo sulla gestione degli errori e sulle prestazioni.

Utilizza CTEs sottoquery o tabelle normali con logica di pulizia anziché tabelle temporanee.

Alternativa: crea tabelle con nomi specifici della sessione e puliscile nell'applicazione.

Aurora DSQL fornisce un database integrato denominato postgres per cluster.

Suggerimento per la migrazione: se l'applicazione utilizza più database, create cluster Aurora DSQL separati per la separazione logica o utilizzate schemi all'interno di un singolo cluster.

Le tabelle temporanee non sono ancora supportate in Aurora DSQL. Le espressioni di tabella comuni (CTEs) e le sottoquery possono essere utilizzate come alternativa alle query complesse.

Alternativa: da utilizzare CTEs con WITH clausole per set di risultati temporanei o tabelle normali con denominazione univoca per dati specifici della sessione.

Aurora DSQL elimina i tablespace e la gestione manuale dello storage. Lo storage si ridimensiona e si ottimizza automaticamente in base ai modelli di dati.

Vantaggio: non è necessario monitorare lo spazio su disco, pianificare l'allocazione dello storage o gestire le configurazioni dei tablespace.

Aurora DSQL non supporta i trigger.

Strategia di migrazione: sposta la logica dei trigger nel codice dell'applicazione, usa architetture basate sugli eventi con AWS servizi come EventBridge o implementa gli audit trail utilizzando la registrazione delle applicazioni.

Aurora DSQL supporta funzioni basate su SQL ma non linguaggi procedurali come PL/pgSQL.

Alternativa: utilizza le funzioni SQL per le trasformazioni dei dati o sposta la logica complessa sul livello dell'applicazione o sulle funzioni AWS Lambda.

Aurora DSQL utilizza il controllo ottimistico della concorrenza (OCC), un approccio privo di blocchi che si differenzia dai tradizionali meccanismi di blocco del database. Invece di acquisire blocchi che bloccano altre transazioni, Aurora DSQL consente alle transazioni di procedere senza blocchi e rileva i conflitti al momento del commit. Ciò elimina le situazioni di stallo e impedisce che le transazioni lente blocchino altre operazioni.

Differenza fondamentale: quando si verificano conflitti, Aurora DSQL restituisce un errore di serializzazione anziché far attendere le transazioni per i blocchi. Ciò richiede che le applicazioni implementino una logica di ripetizione, simile alla gestione dei timeout di blocco nei database tradizionali, ma i conflitti vengono risolti immediatamente anziché causare attese di blocco.

Modello di progettazione: implementa una logica di transazione idempotente con meccanismi di ripetizione. Progetta schemi per ridurre al minimo i conflitti utilizzando chiavi primarie casuali e distribuendo gli aggiornamenti su tutta la gamma di chiavi. Per informazioni dettagliate, vedi Controllo della concorrenza in Aurora DSQL.

Aurora DSQL supporta le relazioni con chiavi esterne tra le tabelle, comprese le JOIN operazioni, ma i vincoli di chiave esterna non sono ancora supportati. Sebbene l'applicazione dell'integrità referenziale possa essere utile, le operazioni a cascata (come le eliminazioni a cascata) possono creare problemi di prestazioni imprevisti, ad esempio l'eliminazione di un ordine con 1.000 voci diventa una transazione di 1.001 righe. Per questo motivo, molti clienti evitano i vincoli relativi alle chiavi esterne.

Modello di progettazione: implementa i controlli di integrità referenziale a livello applicativo, utilizza eventuali modelli di coerenza o sfrutta AWS i servizi per la convalida dei dati.

Aurora SQL non richiede VACUUM comandiTRUNCATE. ALTER SYSTEM Il sistema gestisce automaticamente l'ottimizzazione dello storage, la raccolta di statistiche e l'ottimizzazione delle prestazioni.

Vantaggio: elimina la necessità di finestre di manutenzione del database, pianificazione a vuoto e ottimizzazione dei parametri di sistema.

Aurora DSQL partiziona e distribuisce automaticamente i dati in base ai modelli di accesso. Il partizionamento e le sequenze manuali non sono necessari.

Suggerimento per la migrazione: rimuovete la logica di partizionamento manuale e lasciate che Aurora DSQL gestisca la distribuzione dei dati. Usa UUIDs o generati dall'applicazione anziché sequenze IDs .