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à.
# Monitoraggio degli aggiornamenti dello stato dei dispositivi in DynamoDB
In questo caso d'uso viene descritto l'utilizzo di DynamoDB per monitorare gli aggiornamenti dello stato del dispositivo (o le modifiche allo stato del dispositivo) in DynamoDB.
## Caso d’uso
Nei casi d'uso dell'IoT (ad esempio una fabbrica intelligente) molti dispositivi devono essere monitorati dagli operatori e inviano periodicamente il proprio stato o i log a un sistema di monitoraggio. Quando si verifica un problema con un dispositivo, lo stato del dispositivo cambia da *normale* ad *avviso*. Esistono diversi livelli o stati di log a seconda della gravità e del tipo di comportamento anomalo nel dispositivo. Il sistema incarica quindi un operatore di controllare il dispositivo e, se necessario, può segnalare il problema al proprio supervisore.
Alcuni modelli di accesso tipici per questo sistema includono:
+ Crea una voce di log per un dispositivo
+ Ottieni tutti i log per uno stato specifico del dispositivo, mostrando per primi i log più recenti
+ Ottieni tutti i log di un determinato operatore tra due date
+ Ottieni tutti i log inoltrati per un determinato supervisore
+ Ottieni tutti i log inoltrati con uno stato specifico del dispositivo per un determinato supervisore
+ Ottieni tutti i log inoltrati con uno stato specifico del dispositivo per un determinato supervisore e per una data specifica
## Diagramma delle relazioni tra entità
Questo è il diagramma di relazione delle entità (ERD) ch useremo per monitorare gli aggiornamenti dello stato dei dispositivi.
![\[ERD degli aggiornamenti sullo stato del dispositivo. Mostra le entità: Device e Operator.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-1-ERD.jpg)
## Modelli di accesso
Questi sono i modelli di accesso che prenderemo in considerazione per monitorare gli aggiornamenti dello stato dei dispositivi.
1. `createLogEntryForSpecificDevice`
1. `getLogsForSpecificDevice`
1. `getWarningLogsForSpecificDevice`
1. `getLogsForOperatorBetweenTwoDates`
1. `getEscalatedLogsForSupervisor`
1. `getEscalatedLogsWithSpecificStatusForSupervisor`
1. `getEscalatedLogsWithSpecificStatusForSupervisorForDate`
## Evoluzione della progettazione dello schema
**Fase 1: Gestire i modelli di accesso 1 (`createLogEntryForSpecificDevice`) e 2 (`getLogsForSpecificDevice`)**
L'unità di dimensionamento per un sistema di tracciamento dei dispositivi sarebbe costituita dai singoli dispositivi. In questo sistema, `deviceID` identifica in modo univoco un dispositivo. Questo rende `deviceID` un buon candidato per la chiave di partizione. Ogni dispositivo invia informazioni al sistema di tracciamento periodicamente (ad esempio ogni cinque minuti circa). Questo ordinamento rende la data un criterio di ordinamento logico e quindi la chiave di ordinamento. I dati di esempio in questo caso apparirebbero simili a:
![\[Tabella per archiviare lo stato di più dispositivi. DeviceID è la chiave primaria e State#Date è la chiave di ordinamento.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-2-Step1.png)
Per recuperare le voci di log per un dispositivo specifico, possiamo eseguire un’operazione di [query](Query.md) con la chiave di partizione `DeviceID="d#12345"`.
**Fase 2: Gestire il modello di accesso 3 (`getWarningLogsForSpecificDevice`)**
Poiché `State` è un attributo non chiave, affrontare il pattern di accesso 3 con lo schema corrente richiederebbe un’[espressione di filtro](Query.FilterExpression.md). In DynamoDB, le espressioni di filtro vengono applicate dopo la lettura dei dati utilizzando le espressioni delle condizioni chiave. Ad esempio, se si dovessero recuperare i registri dei log per `d#12345`, l’operazione di query con chiave di partizione `DeviceID="d#12345"` leggerà quattro elementi dalla tabella precedente e poi filtrerà l’unico elemento senza lo stato di *avviso*. Questo approccio non è efficiente su larga scala. Un'espressione di filtro può essere un buon modo per escludere gli elementi interrogati se il rapporto tra gli elementi esclusi è basso o la query viene eseguita di rado. Tuttavia, nei casi in cui molti elementi vengono recuperati da una tabella e la maggior parte degli elementi viene filtrata, possiamo continuare a sviluppare il design della tabella in modo che funzioni in modo più efficiente.
Cambiamo come gestire questo modello di accesso utilizzando [chiavi di ordinamento composte](data-modeling-blocks.md#data-modeling-blocks-composite). Puoi importare dati di esempio da [DeviceStateLog\$13.json in cui è stata](https://github.com/aws-samples/amazon-dynamodb-design-patterns/blob/master/examples/device-state-log/json/DeviceStateLog_3.json) modificata la chiave di ordinamento. `State#Date` Questa chiave di ordinamento è la composizione degli attributi `State`, `#` e `Date`. In questo caso, `#` viene usato come un delimitatore. L'aspetto dei dati è ora il seguente:
![\[Dati di aggiornamento dello stato per il dispositivo, d#12345, recuperati utilizzando la chiave di ordinamento composita State#Date.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-3-Step2.png)
Per recuperare solo i log degli avvisi per un dispositivo, la query diventa più mirata con questo schema. La condizione chiave per la query utilizza la chiave di partizione `DeviceID="d#12345"` e la chiave di ordinamento `State#Date begins_with “WARNING”`. Questa interrogazione leggerà solo i tre elementi pertinenti con lo stato di *avviso*.
**Fase 3: Gestire il modello di accesso 4 (`getLogsForOperatorBetweenTwoDates`)**
È possibile importare [DeviceStateLog\$14.json](https://github.com/aws-samples/amazon-dynamodb-design-patterns/blob/master/examples/device-state-log/json/DeviceStateLog_4.json) D dove l'`Operator`attributo è stato aggiunto alla tabella con dati di esempio. `DeviceStateLog`
![\[DeviceStateLog progettazione di tabelle con l'attributo Operator per ottenere i log di un operatore tra date specifiche.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-4-Step3.png)
Poiché `Operator` attualmente non è una chiave di partizione, non è possibile eseguire una ricerca diretta chiave-valore su questa tabella basata su `OperatorID`. Dovremo creare una nuova [collezione di articoli](WorkingWithItemCollections.md) con un indice secondario globale su `OperatorID`. Il modello di accesso richiede una ricerca basata sulle date, quindi Data è l'attributo chiave di ordinamento per [indice secondario globale (GSI)](GSI.md). Ecco come appare ora il GSI:
![\[Progettazione di GSI con OperatorID e Date come chiave di partizione e chiave di ordinamento per ottenere i log per un operatore specifico.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-5-Step3.png)
Per il modello di accesso 4 (`getLogsForOperatorBetweenTwoDates`), puoi interrogare questo GSI con la chiave di partizione `OperatorID=Liz` e la chiave di ordinamento `Date` fra `2020-04-11T05:58:00` e `2020-04-24T14:50:00`.
![\[Esecuzione di query su un GSI utilizzando OperatorID e Date per ottenere i log di un operatore tra due date.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-6-GSI1_1.png)
**Fase 4: Gestire i modelli di accesso 5 (`getEscalatedLogsForSupervisor`), 6 (`getEscalatedLogsWithSpecificStatusForSupervisor`) e 7 (`getEscalatedLogsWithSpecificStatusForSupervisorForDate`)**
Useremo un [indice sparso](data-modeling-blocks.md#data-modeling-blocks-sparse-index) per affrontare questi modelli di accesso.
Per impostazione predefinita, gli indici secondari globali sono sparsi, quindi solo gli elementi della tabella di base che contengono gli attributi della chiave primaria dell'indice verranno effettivamente visualizzati nell'indice. Questo è un altro modo per escludere gli elementi che non sono rilevanti per il modello di accesso da modellare.
Puoi importare [DeviceStateLog\$16.json](https://github.com/aws-samples/amazon-dynamodb-design-patterns/blob/master/examples/device-state-log/json/DeviceStateLog_6.json) dove l'`EscalatedTo`attributo è stato aggiunto alla `DeviceStateLog` tabella con dati di esempio. Come accennato in precedenza, non tutti i log vengono inoltrati a un supervisore.
![\[Progettazione GSI con l' EscalatedTo attributo per ottenere tutti i log escalation per un supervisore.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-7-Step4.png)
È ora possibile creare un nuovo GSI in cui `EscalatedTo` è la chiave di partizione e `State#Date` è la chiave di ordinamento. Nota che solo gli elementi che hanno entrambi gli attributi `EscalatedTo` e `State#Date` vengono visualizzati nell'indice.
![\[Progettazione GSI per ottenere tutti gli elementi con gli attributi e State #Date. EscalatedTo\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-8-Step4.png)
Gli altri modelli di accesso sono riassunti come segue:
Per il pattern di accesso 5 (getEscalatedLogsForSupervisor), è possibile eseguire una query sul GSI delle escalation con la chiave di partizione ="Sara» EscalatedTo Per il modello di accesso 6 (getEscalatedLogsWithSpecificStatusForSupervisor), è possibile eseguire una query sul GSI di escalation con la chiave di partizione ="Sara» e la chiave EscalatedTo di ordinamento State \$1Date begins\$1with «WARNING» Per il pattern di accesso 7 (getEscalatedLogsWithSpecificStatusForSupervisorForDate), è possibile eseguire un'interrogazione sul GSI di escalation con la chiave di partizione ="Sara» e la chiave di ordinamento State \$1Date begins\$1with «\$12020 -04-27» EscalatedTo WARNING4
Tutti i modelli di accesso e il modo in cui la progettazione dello schema li affronta sono riassunti nella tabella seguente:
| Modello di accesso | table/GSI/LSI Base | Operation | Valore della chiave di partizione | Valore della chiave di ordinamento | Altre condizioni/filtri |
| --- | --- | --- | --- | --- | --- |
| createLogEntryForSpecificDevice | Tabella di base | PutItem | DeviceID=deviceId | State\$1Date=state\$1date | |
| getLogsForSpecificDevice | Tabella di base | Query | DeviceID=deviceId | State\$1Date begins\$1with "state1\$1" | ScanIndexForward = Falso |
| getWarningLogsForSpecificDevice | Tabella di base | Query | DeviceID=deviceId | State\$1Date begins\$1with "WARNING" | |
| getLogsForOperatorBetweenTwoDates | GSI-1 | Query | Operator=operatorName | Data compresa tra data1 e data2 | |
| getEscalatedLogsForSupervisor | GSI-2 | Query | EscalatedTo= Nome del supervisore | | |
| getEscalatedLogsWithSpecificStatusForSupervisor | GSI-2 | Query | EscalatedTo= Nome del supervisore | State\$1Date begins\$1with "state1\$1" | |
| getEscalatedLogsWithSpecificStatusForSupervisorForDate | GSI-2 | Query | EscalatedTo= Nome del supervisore | State\$1Date begins\$1with "state1\$1date1" | |
## Schema finale
Di seguito sono riportate le progettazioni dello schema finale. Per scaricare questo schema come file JSON, consulta Esempi di [DynamoDB](https://github.com/aws-samples/aws-dynamodb-examples/tree/master/schema_design/SchemaExamples) su. GitHub
**Tabella di base**
![\[Progettazione di una tabella di base con metadati sullo stato del dispositivo, come DeviceID, State e Date.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-9-Table.png)
**GSI-1**
![\[Progettazione di GSI-1. Mostra la chiave primaria e gli attributi: DeviceID, State#Date e State.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-10-GSI1.png)
**GSI-2**
![\[Progettazione di GSI-2. Mostra la chiave primaria e gli attributi: DeviceID, Operator, Date e State.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-11-GSI2.png)
## Utilizzo di NoSQL Workbench con questa progettazione dello schema
Puoi importare questo schema finale in [NoSQL Workbench](workbench.md), uno strumento visivo che fornisce funzionalità di modellazione dei dati, visualizzazione dei dati e sviluppo di query per DynamoDB, per esplorare e modificare ulteriormente il tuo nuovo progetto. Per iniziare, segui queste fasi:
1. Scarica NoSQL Workbench. Per ulteriori informazioni, consulta [Download di NoSQL Workbench per DynamoDB](workbench.settingup.md).
1. Scarica il file dello schema JSON elencato in precedenza, che si trova già nel formato del modello NoSQL Workbench.
1. Importa il file dello schema JSON in NoSQL Workbench. Per ulteriori informazioni, consulta [Importazione di un modello di dati esistente](workbench.Modeler.ImportExisting.md).
1. Dopo che è stato importato in NOSQL Workbench, puoi modificare il modello di dati. Per ulteriori informazioni, consulta [Modifica di un modello di dati esistente](workbench.Modeler.Edit.md).