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 implementato 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:

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 che le persone provano con DynamoDB are sono:

  • Normalizzazione: in un database relazionale, normalizzi i tuoi dati per ridurre la ridondanza 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. Nell'esempio, sono presenti le entità Utente, Amico, Foto e Reazione in un'unica tabella. In un database relazionale, il modello dell'esempio precedente verrebbe creato come quattro 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
    • Foto
    • Reazione
    • Amicizia

    Un utente può aver molte foto e una foto può presentare molte reazioni. Infine, l' entità Amicizia rappresenta una relazione a molti-a-molti tra utenti, in quanto un Utente può seguire più utenti e a sua volta essere seguito da altri utenti.

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

    Module_2_Step_1

    (Fai clic per ingrandire)

    Module_2_Step_1
  • Fase 2: Considera i modelli di accesso al profilo utente

    Ora che abbiamo il nostro diagramma di entità e relazioni, consideriamo i modelli di accesso che riguardano le entità. Iniziamo con gli utenti.

    Gli utenti della nostra applicazione mobile dovranno creare profili utenti. Tali profili conterranno informazioni quali il nome utente, l'immagine del profilo, la posizione, lo stato corrente e gli interessi di un dato utente.

    Gli utenti potranno esplorare il profilo di altri utenti. Un utente potrebbe voler esplorare il profilo di un altro utente per vedere se questo è interessante da seguire o semplicemente per ottenere informazioni su di lui o su un amico esistente.

    Nel tempo, un utente vorrà aggiornare il proprio profilo per mostrare un nuovo stato o per aggiornare i propri interessi man mano che questi cambiano.

    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

    Adesso, diamo un'occhiata ai modelli di accesso che riguardano le foto.

    La nostra applicazione mobile consente agli utenti di caricare e condividere foto con gli amici, in modo analogo a Instagram o Snapchat. Quando gli utenti caricano una foto, dovrai archiviare informazioni come l'ora di caricamento della foto o la posizione del file sulla tua rete per la distribuzione di contenuti (CDN).

    Quando gli utenti non caricano foto, vorranno esplorare quelle dei loro amici. Se visitano il profilo di un amico, dovrebbero vedere le foto di tale utente a partire dalla più recente. Per mostrare il loro apprezzamento a una foto, possono inviare una delle quattro reazioni predefinite: un cuore, una faccina sorridente, un pollice rivolto verso l'alto o un paio di occhiali da sole. Quando visualizzi una foto dovrebbero comparire le attuali reazioni a essa associate.

    In questa sezione, abbiamo i seguenti modelli di accesso:

    • Carica foto per l'utente (Scrivi)
    • Visualizza foto recenti dell'utente (Leggi)
    • Metti una reazione a una foto (Scrivi)
    • Visualizza foto e reazioni (Leggi)
       
  • Fase 4: Modelli di accesso in partita e post partita

    Infine, consideriamo i modelli di accesso che riguardano l'amicizia.

    Molte applicazioni mobili comuni presentano un aspetto da social network. Puoi seguire gli amici, visualizzare gli aggiornamenti delle loro attività e ricevere suggerimenti su altri amici che potresti voler seguire.

    Nella tua applicazione, un'amicizia è una relazione monodirezionale, come Twitter. Un utente può scegliere di seguirne un altro e quest'ultimo può scegliere di seguirlo a sua volta. Per la nostra applicazione, chiameremo gli utenti che seguono un utente "follower" e quelli seguiti da un utente "seguiti".

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

    • Segui utente (Scrivi)
    • Visualizza follower per utente (Leggi)
    • Visualizza seguiti per utente (Leggi)

    Abbiamo visto tutti i modelli di accesso per la nostra applicazione mobile. 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.