Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Progettazione dello schema del profilo di gioco in DynamoDB

Caso d'uso aziendale profilo di gioco

In questo caso d'uso viene descritto l'utilizzo di DynamoDB per archiviare i profili dei giocatori per un sistema di gioco. Gli utenti (in questo caso, i giocatori) devono creare profili prima di poter interagire con molti giochi moderni, in particolare quelli online. I profili di gioco includono in genere i seguenti:

Per soddisfare i requisiti granulari di accesso alle query di dati per questa applicazione, le chiavi primarie (chiave di partizione e chiave di ordinamento) utilizzeranno nomi generici (PK e SK) in modo da poter essere sovraccaricate con vari tipi di valori, come descritto di seguito.

I modelli di accesso per questa progettazione dello schema sono:

Le dimensioni del profilo di gioco possono variare in base ai giochi. La compressione di valori di attributi large permette la loro archiviazione nei limiti degli elementi in DynamoDB, riducendo così i costi. La strategia di gestione della velocità di trasmissione effettiva dipende da vari fattori quali: il numero di giocatori, il numero di partite giocate al secondo e la stagionalità del carico di lavoro. In genere, per un gioco appena lanciato, il numero di giocatori e il livello di popolarità sono sconosciuti, pertanto inizieremo con la modalità di velocità di trasmissione effettiva on demand.

Diagramma delle relazioni tra entità del profilo di gioco

Questo è il diagramma delle relazioni tra entità (ERD) che useremo per la progettazione dello schema del profilo di gioco.

Modelli di accesso del profilo di gioco

Questi sono i modelli di accesso che creeremo per la progettazione dello schema di social network.

Evoluzione della progettazione dello schema del profilo di gioco

Da quanto sopraERD, possiamo vedere che si tratta di un tipo di one-to-many relazione di modellazione dei dati. In DynamoDB one-to-many, i modelli di dati possono essere organizzati in raccolte di elementi, il che è diverso dai tradizionali database relazionali in cui vengono create più tabelle e collegate tramite chiavi esterne. Una raccolta di elementi è un gruppo di elementi che condividono lo stesso valore della chiave di partizione ma hanno valori di chiave di ordinamento differenti. All'interno di una raccolta di elementi, ogni elemento dispone di un valore di chiave di ordinamento univoco che lo distingue dagli altri elementi. Tenendo questo a mente, utilizziamo il modello seguente per i valori HASH e RANGE per ogni tipo di entità.

Per iniziare, utilizziamo nomi generici come PK e SK per archiviare diversi tipi di entità nella stessa tabella in modo da rendere il modello orientato al futuro. Per una migliore leggibilità, possiamo includere prefissi per indicare il tipo di dati o includere un attributo arbitrario chiamato Entity_type o Type. Nell'esempio corrente, utilizziamo una stringa che inizia con player per archiviare player_ID come PK; utilizziamo entity name# come il prefisso di SK e aggiungiamo un attributo Type per indicare il tipo di entità di questo dato. Questo ci consente di supportare l'archiviazione di più tipi di entità in futuro e di utilizzare tecnologie avanzate come GSI Overloading e Sparse GSI per soddisfare più modelli di accesso.

Iniziamo implementando i modelli di accesso. I modelli di accesso come l'aggiunta di giocatori e l'aggiunta di apparecchiature possono essere realizzati tramite l'operazione PutItem, pertanto possiamo ignorarli. In questo documento ci concentreremo sui modelli di accesso tipici elencati in precedenza.

Fase 1: Gestire il modello di accesso 1 (getPlayerFriends)

Gestiamo il modello di accesso 1 (getPlayerFriends) con questa fase. Nella progettazione attuale, l'amicizia è semplice e il numero di amici nel gioco è limitato. Per semplicità, utilizziamo un tipo di dati di elenco per archiviare gli elenchi di amici (modellazione 1:1). In questa progettazione, utilizziamo GetItem per soddisfare questo modello di accesso. Nell'operazione GetItem, forniamo esplicitamente il valore della chiave di partizione e della chiave di ordinamento per ottenere un elemento specifico.

Tuttavia, se un gioco ha un gran numero di amici e le relazioni tra loro sono complesse (ad esempio, le amicizie sono bidirezionali e prevedono sia la componente di invito che quella di accettazione), sarebbe necessario utilizzare una many-to-many relazione per memorizzare ogni amico singolarmente, in modo da ampliare la lista di amici fino a un numero illimitato di amici. E se il cambio di amicizia implica operare su più elementi contemporaneamente, le transazioni DynamoDB possono essere utilizzate per raggruppare più azioni e inviarle come un' all-or-nothingTransactWriteItemsunica operazione. TransactGetItems

Fase 2: Gestire i modelli di accesso 2 (getPlayerAllProfile), 3 (getPlayerAllItems) e 4 (getPlayerSpecificItem)

Usiamo questa fase per gestire i modelli di accesso 2 (getPlayerAllProfile), 3 (getPlayerAllItems) e 4 (getPlayerSpecificItem). Ciò che accomuna questi tre modelli di accesso è una query di intervallo che utilizza l'operazione Query. A seconda dell'ambito della query, vengono usate Condizione chiave ed Espressioni filtro, comunemente utilizzate nello sviluppo pratico.

Nell'operazione Query, forniamo un singolo valore per Partition Key e otteniamo tutti gli elementi con tale valore Partition Key. Il modello di accesso 2 (getPlayerAllProfile) è implementato in questo modo. Facoltativamente, possiamo aggiungere un'espressione di condizione della chiave di ordinamento, ovvero una stringa che determina gli elementi da leggere dalla tabella. Il modello di accesso 3 (getPlayerAllItems) viene implementato aggiungendo la chiave di condizione della chiave di ordinamento begins_with ITEMS#. Inoltre, al fine di semplificare lo sviluppo del lato applicativo, possiamo utilizzare le espressioni di filtro per implementare il modello di accesso 4 (getPlayerSpecificItem).

Di seguito è riportato un esempio di pseudocodice che utilizza un'espressione di filtro che filtra gli elementi della categoria Weapon:

filterExpression: "ItemType = :itemType" 
expressionAttributeValues: {":itemType": "Weapon"}

Se il modello di accesso consiste nell'eseguire query di un set di dati di grandi dimensioni e filtrare una grande quantità di dati per conservare solo un piccolo sottoinsieme di dati, l'approccio appropriato è progettare la Partition Key e la chiave di ordinamento DynamoDB in modo più efficace. Nell'esempio precedente, per ottenere un determinato ItemType, se sono presenti molti oggetti per ciascun giocatore e la richiesta di un determinato ItemType è un modello di accesso tipico, sarebbe più efficiente inserire ItemType in SK come una chiave composita. L'aspetto del modello di dati è simile a: ITEMS#ItemType#ItemId.

Fase 3: Gestire i modelli di accesso 5 (updateCharacterAttributes) e 6 (updateItemCount) 

Utilizziamo questa fase per gestire i modelli di accesso 5 (updateCharacterAttributes) e 6 (updateItemCount). Quando il giocatore deve modificare il personaggio, ad esempio riducendo la valuta o modificando la quantità di una determinata arma nei suoi elementi, utilizza UpdateItem per implementare questi modelli di accesso. Per aggiornare la valuta di un giocatore ma garantire che non scenda mai al di sotto di un importo minimo, possiamo aggiungere Esempio di espressione di condizione DynamoDB CLI per ridurre il saldo solo se è maggiore o uguale all'importo minimo. Di seguito è riportato un esempio di pseudocodice:

UpdateExpression: "SET currency = currency - :amount"
ConditionExpression: "currency >= :minAmount"

Durante lo sviluppo con DynamoDB e l'utilizzo di contatori atomici per diminuire l'inventario, possiamo garantire l'idempotenza utilizzando il blocco ottimistico. Di seguito è riportato un esempio di pseudocodice per contatori atomici:

UpdateExpression: "SET ItemCount = ItemCount - :incr" 
expression-attribute-values: '{":incr":{"N":"1"}}'

Inoltre, in uno scenario in cui il giocatore acquista un elemento con valuta, l'intero processo deve detrarre la valuta e aggiungere contemporaneamente un elemento. Possiamo utilizzare DynamoDB Transactions per raggruppare più azioni e inviarle come singola all-or-nothing TransactWriteItems operazione. TransactGetItems TransactWriteItemsè un'operazione di scrittura sincrona e idempotente che raggruppa fino a 100 azioni di scrittura in un'unica operazione. all-or-nothing Le operazioni vengono completate in modo atomico, in maniera tale che abbiano tutte esito positivo oppure abbiano tutte esito negativo. Le transazioni consentono di eliminare il rischio di duplicazione o di scomparsa della valuta. Per ulteriori informazioni sulle transazioni, consulta Esempio di transazioni di DynamoDB.

Tutti i modelli di accesso e il modo in cui la progettazione dello schema li affronta sono riassunti nella tabella seguente:

Schema finale del profilo di gioco

Di seguito è riportata la progettazione dello schema finale. Per scaricare questo schema come JSON file, consulta Esempi di DynamoDB su. GitHub

Tabella di base:

Utilizzo di No SQL Workbench con questo schema

Puoi importare questo schema finale in No SQL Workbench, uno strumento visivo che fornisce funzionalità di modellazione, visualizzazione dei dati e sviluppo di query per DynamoDB, per esplorare e modificare ulteriormente il tuo nuovo progetto. Per iniziare, segui queste fasi: