Creare modelli per i dati dei giocatori con Amazon DynamoDB

La creazione di modelli di dati è il processo di progettazione di come un'applicazione archivia i dati in un database specifico. Con un database NoSQL come DynamoDB, la creazione di modelli è diversa rispetto alla creazione di modelli con un database relazionale. Un database relazionale è pensato per essere flessibile e può essere la scelta ideale per le applicazioni di analisi. Nella creazione di modelli di dati relazionali, parti dalle tue entità. Quando hai un modello relazionale normalizzato, puoi soddisfare qualsiasi schema di query di cui hai bisogno all'interno della tua applicazione.

I database NoSQL (non relazionali) sono progettati per la velocità e la scalabilità, non per la flessibilità. Mentre le prestazioni del tuo database relazionale potrebbero diminuire con la scalabilità verticale, i database a scalabilità orizzontale, come DynamoDB, offrono prestazioni costanti su qualsiasi scala. Alcuni utenti DynamoDB hanno tabelle più grandi di 100 TB e le prestazioni di lettura e di scrittura delle loro tabelle sono le stesse di quelle di tabelle più piccole di 1 GB.

Il raggiungimento di risultati migliori con un database NoSQL come DynamoDB richiede un cambio di mentalità rispetto al tipico database relazionale. Utilizza le best practice seguenti per la creazione di modelli di dati con DynamoDB.

1. Concentrati sui modelli di accesso
Per la creazione di modelli di dati di qualsiasi tipo, partirai da un diagramma di relazioni ed entità che descrive i diversi oggetti (o entità) della tua applicazione e il modo in cui sono connessi (o le relazioni tra le tue entità).

Nei database relazionali, metterai le entità direttamente nelle tabelle e specificherai la relazione usando le chiavi esterne. Dopo aver definito le tue tabelle di dati, un database relazionale fornisce un linguaggio di query flessibile per restituire i dati nella forma di cui hai bisogno.

In DynamoDB, devi pensare ai modelli di accesso prima di creare il modello per la tua tabella. I database NoSQL sono incentrati sulla velocità, non sulla flessibilità. Per prima cosa, devi considerare in che modo accederai ai dati e, in seguito, devi creare i modelli di dati nella forma in cui eseguirai l'accesso.

Prima di progettare la tua tabella DynamoDB, documenta ogni necessità di lettura e scrittura di dati nella tua applicazione. Devi essere accurato e pensare a tutti i flussi della tua applicazione, perché stai eseguendo l'ottimizzazione della tua tabella per i modelli di accesso.

2. Ottimizza il numero di richieste di DynamoDB
Dopo aver documentato le tue necessità relative ai modelli di accesso dell'applicazione, sei pronto a progettare la tua tabella. Devi progettare la tua tabella in modo da ridurre al minimo il numero di richieste al database DynamoDB per ogni modello di accesso. Idealmente, ogni modello di accesso dovrebbe effettuare una singola richiesta al database DynamoDB perché le richieste di rete sono lente e questo limita il numero di richieste di rete che effettuerai nella tua applicazione.

Per ottimizzare il numero di richieste effettuate al database DynamoDB, devi comprendere alcuni concetti principali:

● Chiave principali
● Indici secondari
● Transazioni

3. Non simulare un modello relazionale
Le persone nuove ai database DynamoDB spesso provano a implementare un modello relazionale su database DynamoDB non relazionali. Questo, comporta la perdita della maggior parte dei vantaggi di un database DynamoDB.

Gli anti-modelli più comuni (risposte non efficaci a problemi ricorrenti) che le persone provano con DynamoDB sono:

•  Normalizzazione: in un database relazionale, normalizzi i tuoi dati per ridurre la ridondanza dei dati e lo spazio di archiviazione e, quindi, usi i join per combinare più tabelle diverse. Tuttavia, i join su scala sono lenti e costosi. DynamoDB non permette l'utilizzo dei join perché diventano più lenti man mano che la tabella cresce.
• Un tipo di dati per tabella: la tua tabella DynamoDB spesso include tipi diversi di dati in una singola tabella. Nel nostro esempio abbiamo entità Utente, Partita e UserGameMapping in una singola tabella. In un database relazionale, il modello dell'esempio precedente verrebbe creato come tre tabelle diverse.
• Troppi indice secondari: spesso le persone provano a creare un indice secondario per ogni modello di accesso aggiuntivo di cui hanno bisogno. DynamoDB è privo di schema e questo si applica anche ai tuoi indici. Usa la flessibilità dei tuoi attributi per riutilizzare un singolo indice secondario per più tipi di dati nella tua tabella. Questo si chiama sovraccarico di indici.

Nelle fasi qui sotto, svilupperemo il nostro diagramma di entità e relazioni e definiremo i nostri modelli di accesso iniziali. Questi dovrebbero sempre essere i primi passaggi per l'utilizzo di DynamoDB. Nel modulo successivo, implementeremo questi modelli di accesso nella progettazione della tabella.