# Monitoramento das atualizações de status do dispositivo no DynamoDB
Esse caso de uso aborda o uso do DynamoDB para monitorar atualizações de status de dispositivos (ou alterações no estado dos dispositivos) no DynamoDB.
## Caso de uso
Em casos de uso de IoT (uma fábrica inteligente, por exemplo), muitos dispositivos precisam ser monitorados pelos operadores e eles enviam periodicamente seus status ou logs para um sistema de monitoramento. Quando há um problema com um dispositivo, o status dele muda de *normal* para *aviso*. Existem diferentes níveis ou status de log, dependendo da gravidade e do tipo de comportamento anormal no dispositivo. O sistema então designa um operador para verificar o dispositivo e ele pode encaminhar o problema ao supervisor, se necessário.
Alguns padrões de acesso típicos desse sistema incluem:
+ Criar entrada de log para um dispositivo
+ Obter todos os logs de um estado específico do dispositivo, mostrando primeiro os logs mais recentes
+ Obter todos os logs de determinado operador entre duas datas
+ Obter todos os logs encaminhados a determinado supervisor
+ Obter todos os logs encaminhados com um estado de dispositivo específico para determinado supervisor
+ Obter todos os logs encaminhados com um estado de dispositivo específico para determinado supervisor em uma data específica
## Diagrama de relacionamento de entidades
Este é o diagrama de relacionamento de entidades (ERD) que usaremos para monitorar atualizações de status de dispositivos.
![\[ERD de atualizações de status de dispositivos. Mostra as entidades: Device e Operator.\]](http://docs.aws.amazon.com/pt_br/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-1-ERD.jpg)
## Padrões de acesso
Esses são os padrões de acesso que vamos considerar para monitorar atualizações de status de dispositivos.
1. `createLogEntryForSpecificDevice`
1. `getLogsForSpecificDevice`
1. `getWarningLogsForSpecificDevice`
1. `getLogsForOperatorBetweenTwoDates`
1. `getEscalatedLogsForSupervisor`
1. `getEscalatedLogsWithSpecificStatusForSupervisor`
1. `getEscalatedLogsWithSpecificStatusForSupervisorForDate`
## Evolução do design do esquema
**Etapa 1: abordar os padrões de acesso 1 (`createLogEntryForSpecificDevice`) e 2 (`getLogsForSpecificDevice`)**
A unidade de escala de um sistema de rastreamento de dispositivos seriam dispositivos individuais. Nesse sistema, um `deviceID` identifica de forma exclusiva um dispositivo. Isso tornar `deviceID` um bom candidato para a chave de partição. Cada dispositivo envia informações ao sistema de rastreamento periodicamente (digamos, a cada cinco minutos, mais ou menos). Essa ordem torna a data um critério lógico de classificação e, portanto, a chave de classificação. Os dados de amostra, nesse caso, ficariam mais ou menos assim:
![\[Tabela para armazenar o status de vários dispositivos. DeviceID é a chave primária e a data de atualização de status é a chave de classificação.\]](http://docs.aws.amazon.com/pt_br/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-2-Step1.png)
Para buscar entradas de log para um dispositivo específico, podemos realizar uma operação de [consulta](Query.md) com a chave de partição `DeviceID="d#12345"`.
**Etapa 2: abordar o padrão de acesso 3 (`getWarningLogsForSpecificDevice`)**
Como `State` é um atributo não chave, abordar o padrão de acesso 3 com o esquema atual exigiria uma [expressão de filtro](Query.FilterExpression.md). No DynamoDB, as expressões de filtro são aplicadas depois que os dados são lidos usando expressões de condição de chave. Por exemplo, se fôssemos obter os logs de aviso para `d#12345`, a operação de consulta com a chave de partição `DeviceID="d#12345"` leria quatro itens da tabela acima e, depois, filtraria o único item sem o status *aviso*. Essa abordagem não é eficiente em grande escala. Uma expressão de filtro pode ser uma boa maneira de excluir itens que são consultados se a proporção de itens excluídos for baixa ou se a consulta for realizada com pouca frequência. No entanto, nos casos em que muitos itens são recuperados de uma tabela e a maioria dos itens é excluída após a filtragem, podemos continuar desenvolvendo nosso design de tabela para que funcione com maior eficiência.
Vamos mudar a forma de lidar com esse padrão de acesso usando [chaves de classificação compostas](data-modeling-blocks.md#data-modeling-blocks-composite). É possível importar dados de amostra do [DeviceStateLog\$13.json](https://github.com/aws-samples/amazon-dynamodb-design-patterns/blob/master/examples/device-state-log/json/DeviceStateLog_3.json), onde a chave de classificação é alterada para `State#Date`. Essa chave de classificação é a composição dos atributos `State`, `#` e `Date`. Nesse exemplo, `#` é usado como um delimitador. Os dados agora ficam mais ou menos assim:
![\[Dados de atualização de status do dispositivo, d #12345, recebidos com a chave de classificação composta State#Date.\]](http://docs.aws.amazon.com/pt_br/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-3-Step2.png)
Para obter somente logs de aviso de um dispositivo, a consulta se torna mais direcionada com esse esquema. A condição de chave para a consulta usa a chave de partição `DeviceID="d#12345"` e a chave de classificação `State#Date begins_with “WARNING”`. Essa consulta lerá somente os três itens relevantes com o estado *aviso*.
**Etapa 3: abordar o padrão de acesso 4 (`getLogsForOperatorBetweenTwoDates`)**
É possível importar [DeviceStateLog\$14.json](https://github.com/aws-samples/amazon-dynamodb-design-patterns/blob/master/examples/device-state-log/json/DeviceStateLog_4.json), onde o atributo `Operator` foi adicionado à tabela `DeviceStateLog` com dados de exemplo.
![\[Design de tabela DeviceStateLog com o atributo Operator para receber os logs de um operador entre datas específicas.\]](http://docs.aws.amazon.com/pt_br/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-4-Step3.png)
Como no momento `Operator` não é uma chave de partição, não há como realizar uma pesquisa direta de chave-valor nessa tabela com base em `OperatorID`. Precisaremos criar uma [coleção de itens](WorkingWithItemCollections.md) com um índice secundário global em `OperatorID`. O padrão de acesso requer uma pesquisa com base em datas, então Data é o atributo da chave de classificação do [índice secundário global (GSI)](GSI.md). É assim que o GSI se parece agora:
![\[Design de GSI com OperatorID e Date como chave de partição e chave de classificação para receber logs de um operador específico.\]](http://docs.aws.amazon.com/pt_br/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-5-Step3.png)
Para o padrão de acesso 4 (`getLogsForOperatorBetweenTwoDates`), é possível consultar esse GSI com a chave de partição `OperatorID=Liz` e a chave de classificação `Date` entre `2020-04-11T05:58:00` e `2020-04-24T14:50:00`.
![\[Consultar no GSI usando OperatorID e Date para receber logs de um operador entre duas datas.\]](http://docs.aws.amazon.com/pt_br/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-6-GSI1_1.png)
**Etapa 4: abordar os padrões de acesso 5 (`getEscalatedLogsForSupervisor`), 6 (`getEscalatedLogsWithSpecificStatusForSupervisor`) e 7 (`getEscalatedLogsWithSpecificStatusForSupervisorForDate`)**
Usaremos um [índice esparso](data-modeling-blocks.md#data-modeling-blocks-sparse-index) para abordar esses padrões de acesso.
Os índices secundários globais são esparsos por padrão; portanto, somente os itens na tabela base que contêm atributos de chave primária do índice realmente aparecerão no índice. Essa é outra forma de excluir itens que não são relevantes para o padrão de acesso que está sendo modelado.
É possível importar [DeviceStateLog\$16.json](https://github.com/aws-samples/amazon-dynamodb-design-patterns/blob/master/examples/device-state-log/json/DeviceStateLog_6.json), onde o atributo `EscalatedTo` foi adicionado à tabela `DeviceStateLog` com dados de exemplo. Conforme mencionado anteriormente, nem todos os logs são encaminhados para um supervisor.
![\[Design de GSI com o atributo EscalatedTo para receber todos os logs encaminhados a um supervisor.\]](http://docs.aws.amazon.com/pt_br/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-7-Step4.png)
Agora você pode criar um novo GSI em que `EscalatedTo` é a chave de partição e `State#Date` é a chave de classificação. Observe que somente itens que têm ambos os atributos `EscalatedTo` e `State#Date` aparecem no índice.
![\[Design de GSI para receber todos os itens com os atributos EscalatedTo e State#Date.\]](http://docs.aws.amazon.com/pt_br/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-8-Step4.png)
O restante dos padrões de acesso está resumido da seguinte forma:
Para o padrão de acesso 5 (getEscalatedLogsForSupervisor), você pode realizar uma consulta no GSI de encaminhamentos com a chave de partição EscalatedTo=“Sara” Para o padrão de acesso 6 (getEscalatedLogsWithSpecificStatusForSupervisor), você pode realizar uma consulta no GSI de encaminhamentos com a chave de partição EscalatedTo=“Sara” e a chave de classificação State\$1Date begins\$1with “WARNING” Para o padrão de acesso 7 (getEscalatedLogsWithSpecificStatusForSupervisorForDate), você pode realizar uma consulta no GSI de encaminhamentos com a chave de partição EscalatedTo=“Sara” e a chave de classificação State\$1Date begins\$1with “WARNING4\$12020-04-27”
Todos os padrões de acesso e a forma como o design do esquema os aborda estão resumidos na tabela abaixo:
| Padrão de acesso | Tabela base/GSI/LSI | Operation | Valor da chave de partição | Valores de chave de classificação | Outras condições/filtros |
| --- | --- | --- | --- | --- | --- |
| createLogEntryForSpecificDevice | Tabela base | PutItem | DeviceID=deviceId | State\$1Date=state\$1date | |
| getLogsForSpecificDevice | Tabela base | Consulta | DeviceID=deviceId | State\$1Date begins\$1with "state1\$1" | ScanIndexForward = False |
| getWarningLogsForSpecificDevice | Tabela base | Consulta | DeviceID=deviceId | State\$1Date begins\$1with "WARNING" | |
| getLogsForOperatorBetweenTwoDates | GSI-1 | Consulta | Operator=operatorName | Data entre date1 e date2 | |
| getEscalatedLogsForSupervisor | GSI-2 | Consulta | EscalatedTo=supervisorName | | |
| getEscalatedLogsWithSpecificStatusForSupervisor | GSI-2 | Consulta | EscalatedTo=supervisorName | State\$1Date begins\$1with "state1\$1" | |
| getEscalatedLogsWithSpecificStatusForSupervisorForDate | GSI-2 | Consulta | EscalatedTo=supervisorName | State\$1Date begins\$1with "state1\$1date1" | |
## Esquema final
Veja aqui os designs do esquema final. Para baixar esse design de esquema como arquivo JSON, consulte [DynamoDB Examples](https://github.com/aws-samples/aws-dynamodb-examples/tree/master/schema_design/SchemaExamples) no GitHub.
**Tabela base**
![\[Design de tabela base com metadados de status do dispositivo, como ID do dispositivo, Estado e Data.\]](http://docs.aws.amazon.com/pt_br/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-9-Table.png)
**GSI-1**
![\[Design de GSI-1. Ele mostra a chave primária e os atributos: DeviceID, State#Date e State.\]](http://docs.aws.amazon.com/pt_br/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-10-GSI1.png)
**GSI-2**
![\[Design de GSI-2. Ele mostra a chave primária e os atributos: DeviceID, Operator, Date e State.\]](http://docs.aws.amazon.com/pt_br/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-11-GSI2.png)
## Como usar o NoSQL Workbench com esse design de esquema
Você pode importar esse esquema final para o [NoSQL Workbench](workbench.md), uma ferramenta visual que fornece atributos de modelagem de dados, visualização de dados e desenvolvimento de consultas para o DynamoDB, se quiser explorar e editar ainda mais seu novo projeto. Para começar, siga estas etapas:
1. Baixe o NoSQL Workbench. Para obter mais informações, consulte [Baixar o NoSQL Workbench para DynamoDB](workbench.settingup.md).
1. Baixe o arquivo do esquema JSON listado acima, que já está no formato do modelo NoSQL Workbench.
1. Importe o arquivo do esquema JSON para o NoSQL Workbench. Para obter mais informações, consulte [Importar um modelo de dados existente](workbench.Modeler.ImportExisting.md).
1. Depois de importar para o NOSQL Workbench, você pode editar o modelo de dados. Para obter mais informações, consulte [Editar um modelo de dados existente](workbench.Modeler.Edit.md).