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.

Tempo necessario per completare il modulo: 20 minuti


  • Fase 1: Sviluppa il tuo diagramma di entità e relazioni

    La prima fase di qualsiasi esercizio di creazione di modelli di dati consiste nello sviluppare un diagramma che mostri le entità dell'applicazione e le relazioni tra di loro.

    Nella nostra applicazione sono presenti le seguenti entità:
    • Utente
    • Partita
    • UserGameMapping

    Un'entità Utente rappresenta un utente nella nostra applicazione. Un utente può creare più entità Partita e il creatore di una partita determinerà qual è la mappa di gioco e quando inizia il gioco. Un utente può creare più entità Partita, in modo che sussista una relazione uno a molti tra gli Utenti e le Partite.

    Infine, una Partita contiene più Utenti e un Utente può giocare a diverse Partite nel tempo. Esiste una relazione molti a molti tra gli Utenti e le Partite. Possiamo rappresentare questa relazione con l'entità UserGameMapping.

    Con queste entità e relazioni in mente, il nostro diagramma di relazioni ed entità è mostrato qui sotto.

    Module2-step1

    (Fai clic per ingrandire)

    Module2-step1
  • Fase 2: Considera i modelli di accesso al profilo utente

     Gli utenti del nostro gioco hanno bisogno di creare profili utente. Questi profili includono dati quali nome utente, avatar, statistiche di gioco e altre informazioni su ogni utente. Il gioco visualizza questi profili utente quando un utente esegue l'accesso. Altri utenti possono visualizzare il profilo di un utente per esaminare le statistiche di gioco e altri dettagli.

    Quando un utente gioca, le statistiche di gioco vengono aggiornate per riflettere il numero di partite a cui l'utente ha giocato, il numero di partite vinte dall'utente e il numero di uccisioni da parte dell'utente.

    Sulla base di queste informazioni, abbiamo tre modelli di accesso:

    •  Crea profilo utente (Scrivi)
    •  Aggiorna profilo utente (Scrivi)
    • Ottieni profilo utente (Leggi)
  • Fase 3: Considera i modelli di accesso prepartita

    Il nostro gioco è della tipologia battle royale. I giocatori possono creare una partita con un una mappa specifica e altri giocatori si possono unire alla partita. Quando 50 giocatori si sono uniti alla partita, la partita inizia e non si possono aggiungere altri giocatori.

    Quando cercano partite a cui unirsi, i giocatori possono decidere di giocare a una mappa specifica. Altri giocatori possono non essere interessati alla mappa e possono decidere di cercare partite aperte tra tutte le mappe.

    Sulla base di queste informazioni, abbiamo i tre modelli di accesso seguenti:

    • Crea gioco (Scrivi)
    • Trova partite aperte (Leggi)
    • Trova partite aperte tramite la mappa (Leggi)
    • Visualizza partita(Leggi)
    • Visualizza utenti nella partita (Leggi)
    • Partecipa a una partita per un utente (Scrivi)
    • Avvia partita (Scrivi)
  • Fase 4: Modelli di accesso in partita e post partita

    Infine, consideriamo i modelli di accesso durante e dopo la partita.

    Durante la partita, i giocatori cercano di sconfiggere gli altri giocatori con l'obiettivo di essere gli ultimi a rimanere in gioco. La nostra applicazione monitora quante volte un utente viene ucciso durante una partita e il numero di volte che l'utente sopravvive in una partita. Se il giocatore è uno degli ultimi tre a sopravvivere in una partita, il giocatore riceve una medaglia d'oro, d'argento o di bronzo per la partita.

    In un secondo momento, i giocatori possono esaminare le partite a cui hanno giocato in passato o a cui hanno giocato altri giocatori.

    Sulla base di queste informazioni, abbiamo tre modelli di accesso:

    • Aggiorna partita per un utente (Scrivi)
    • Aggiorna partita (Scrivi)
    • Trova tutte le partite passate per un utente (Leggi)

    Abbiamo visto tutti i modelli di accesso per la partita. Nei moduli successivi, implementeremo questi modelli di accesso tramite DynamoDB.

    La fase di pianificazione potrebbe richiedere un po' di iterazioni. Parti da un'idea generale dei modelli di accesso di cui ha bisogno la tua applicazione. Esegui la mappatura della chiave principale, degli indici secondari e degli attributi nella tua tabella. Torna all'inizio e assicurati che tutti i modelli di accesso siano soddisfatti. Quando sei sicuro che la fase di pianificazione sia completata, procedi con l'implementazione.