DynamoDB Migrazioni senza tempi di inattività

Provenendo da SQL, una migrazione è un ALTER TABLE che blocca la tabella mentre riscrive ogni riga. DynamoDB non ha uno schema da modificare: gli elementi sono senza schema, quindi l'aggiunta di un attributo o di un nuovo tipo di entità è gratuita.

La parte difficile è il modello di accesso che i nuovi dati devono servire e la loro rimodellamento dati in tempo reale per servirlo senza una riscrittura improvvisa.

Come si esegue la migrazione di una tabella DynamoDB senza tempi di inattività?

DynamoDB non ha ALTER TABLE, quindi le migrazioni non bloccano mai la tabella. Aggiungi attributi, una nuova forma chiave o una nuovaGSIonline con "UpdateTable", quindi rimodellare i dati in tempo reale in modo incrementale: riempire pigramente i vecchi elementi in lettura o con una scansione limitata e scrivere due volte entrambi i formati durante la transizione. Non è prevista alcuna sospensione del giorno della bandiera.

• Non esiste "ALTER TABLE". Gli elementi sono senza schema. Una "migrazione" significa aggiungendo attributi, una nuova forma di chiave o un nuovo indice, senza mai riscrivere un file set di colonne fisse.
• Le nuove scritture sono facili; i vecchi elementi sono il problema. Le righe esistenti no portano i nuovi attributi, quindi qualsiasi nuovo indice o query li manca silenziosamente fino al riempimento.
• Aggiungi indici online, riempili pigramente. UpdateTable crea un GSI su un live tabella; riempi i vecchi elementi in lettura (pigro) o con una scansione controllata - mai a taglio del giorno della bandiera.
• Doppia scrittura durante la transizione. Mentre entrambe le forme coesistono, scrivi la vecchia e il nuovo formato insieme, quindi nessuno dei due percorsi di lettura diventa obsoleto.

Inquadralo come un modello di accesso, non come una colonna

Supponiamo che tu esegua un prodotto SaaS Workspace su una tabella. Gli elementi utilizzano PK = "WS#<id>" e "SK".sovraccaricoper entità:

Ora il prodotto richiede commenti sui documenti, oltre a una nuova lettura: "elenco ogni commento scritto da un membro nell'area di lavoro, prima il più recente." L'ultima clausola è la migrazione. Un nuovo tipo di entità da solo è banale; servire una query il le chiavi attuali non possono rispondere è il lavoro.

Aggiungi prima il nuovo tipo di entità

I commenti sono solo nuovi elementi nella stessa partizione: nessuna cerimonia di migrazione, no nuova tabella:

A Query su PK = "WS#a91" con SK begins_with "DOC#2026-04-01#x7#CMT#" elenca già i commenti di un documento. I documenti esistenti sono intatti. Questo metà navi il primo giorno: vedi raccolte di oggetti e chiavi sovraccariche per il motivo per cui la stessa partizione li contiene entrambi.

La nuova query richiede un GSI

"Tutti i commenti di un membro, prima i più recenti" non possono essere forniti dalla tabella di base — memberId non è né il prefisso PK né il prefisso SK. Questo è un nuovo indice e sceglierlo correttamente è una sua decisione: vedi GSI vs LSI (un LSI deve esistere alla creazione della tabella, quindi per una migrazione su una tabella live a GSI è la tua unica opzione).

Aggiungi un generico GSI1 e scrivi i nuovi attributi sui nuovi elementi dei commenti:

Query GSI1 WHERE GSI1PK = "MEMBER#u44" con ScanIndexForward = false dà commenti più recenti per membro.

Crea l'indice online

UpdateTable aggiunge un GSI a una tabella live senza tempi di inattività. DynamoDB riempimenti elementi esistenti nell'indice in background; riporta l'indice "CREAZIONE"/riempimento fino al completamento, quindi passa a "ATTIVO". (Gestione di GSIs).

Due trappole qui. Innanzitutto, AWS avverte che l'aggiunta di aGSIpuò regolare la tabella base scrive se la nuova chiave viene distribuita in modo non uniforme: aggiungila in una finestra a basso traffico e guarda CloudWatch. In secondo luogo, l'indice è eventualmente coerenteanche dopo diventa "ATTIVO"; una scritta potrebbe non essere visibile sul GSI per un momento. Vedi perché GSI alla fine sono coerenti.

Riempi i vecchi oggetti

Il GSI indicizza solo gli elementi che hanno GSI1PK/GSI1SK. La tua pre-migrazione i commenti, scritti prima che esistesse l'attributo, non compaiono mai, nemmeno dopo il riempimento viene completato. Il backfill online GSI copia gli elementi esistenti, ma non può farlo inventare attributi che non sono presenti su di essi. Devi aggiungere i valori.

Due strategie:

Per lo sweep, sfoglia con Scan e per ogni vecchio commento aggiungi l'indice attributi con un condizionale UpdateItem in modo da non ostacolare mai un concurrent scrivere.

La condizione protegge l'attributo non già esistente. Costruisci e copia il file esatto ConditionExpression e UpdateExpression con il file DynamoDB Expression Builder anziché digitando a mano attribute_not_exists(GSI1PK).

Doppia scrittura durante la transizione

Fino a quando ogni vecchio oggetto non avrà i nuovi attributi, due forme coesisteranno. La scrittura il percorso deve popolare il nuovo formato su ogni scrittura: nuovi commenti ed eventuali aggiornare a quello vecchio, quindi il divario si riduce solo.

Scegli una condizione di fine recupero che puoi verificare: lo sweep ha paginato l'intera tabella, oppure il percorso lento è durato abbastanza a lungo da rendere obsoleti gli elementi non convertiti in base alla progettazione. Solo allora rimuovi il vecchio percorso di lettura. Saltare questo è come avviene una migrazione "completa" mentre una frazione di query restituisce silenziosamente risultati brevi.

Insidie

• Aggiunta dell'attributo ≠ backfilled. Un nuovo GSI inizia vuoto per i vecchi elementi. Verificare la copertura prima di considerare attendibile la query.
• Cambiare una chiave sul posto è una riscrittura. Non puoi mutare PK/SK di un elemento; scrivi un nuovo elemento sotto la nuova chiave ed elimini quello vecchio. Pianificalo come copia-quindi elimina, doppia lettura nel mezzo.
• Nessun passaggio transazionale. Non c'è nessun momento in cui l'intero tabella si ribalta. Progetta ogni passaggio per essere sicuro mentre entrambe le forme sono attive.

Passaggi successivi

Controlla l'integrità delle nuove chiavi e delle raccolte sovraccariche progettazione a tabella singola e conferma che il riempimento è completare sfogliando la tabella live. Prova DynoTable per sfogliare il tuo tabella, individua gli elementi non riempiti ed esegui gli aggiornamenti condizionali sul tuo propri dati.