# Monitoreo de las actualizaciones de estado de los dispositivos en DynamoDB
En este caso de uso se habla de utilizar DynamoDB para monitorear las actualizaciones del estado del dispositivo (o los cambios en el estado del dispositivo) en DynamoDB.
## Caso de uso
En los casos de uso de IoT (una fábrica inteligente, por ejemplo), los operadores deben monitorear muchos dispositivos y estos envían periódicamente su estado o sus registros a un sistema de monitoreo. Cuando hay un problema con un dispositivo, el estado del mismo cambia de *normal* a *advertencia*. Existen diferentes niveles o estados de registro en función de la gravedad y el tipo de comportamiento anómalo del dispositivo. A continuación, el sistema asigna a un operario para que compruebe el dispositivo y este puede escalar el problema a su supervisor si es necesario.
Algunos patrones de acceso típicos de este sistema son:
+ Crear una entrada de registro para un dispositivo
+ Obtener todos los registros para un estado de dispositivo específico mostrando primero los registros más recientes
+ Obtener todos los registros de un operador dado entre dos fechas
+ Obtener todos los registros escalados de un supervisor determinado
+ Obtener todos los registros escalados con un estado de dispositivo específico para un supervisor determinado
+ Obtener todos los registros escalados con un estado de dispositivo específico para un supervisor determinado en una fecha concreta
## Diagrama de relaciones entre entidades
Este es el diagrama de relaciones entre entidades (ERD) que utilizaremos para monitorear las actualizaciones del estado de los dispositivos.
![\[Actualizaciones del ERD de estado de los dispositivos. Muestra las entidades: Dispositivo y Operador.\]](http://docs.aws.amazon.com/es_es/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-1-ERD.jpg)
## Patrones de acceso
Estos son los patrones de acceso que tendremos en cuenta para monitorear las actualizaciones de estado de los dispositivos.
1. `createLogEntryForSpecificDevice`
1. `getLogsForSpecificDevice`
1. `getWarningLogsForSpecificDevice`
1. `getLogsForOperatorBetweenTwoDates`
1. `getEscalatedLogsForSupervisor`
1. `getEscalatedLogsWithSpecificStatusForSupervisor`
1. `getEscalatedLogsWithSpecificStatusForSupervisorForDate`
## Evolución del diseño de esquema
**Paso 1: Abordar patrones de acceso 1 (`createLogEntryForSpecificDevice`) y 2 (`getLogsForSpecificDevice`)**
La unidad de escala para un sistema de seguimiento de dispositivos serían los dispositivos individuales. En este sistema, un `deviceID` identifica de forma única a un dispositivo. Esto convierte a `deviceID` en un buen candidato para la clave de partición. Cada dispositivo envía información al sistema de seguimiento periódicamente ( por ejemplo, cada cinco minutos más o menos). Esta ordenación convierte a la fecha en un criterio lógico de clasificación y, por tanto, en la clave de clasificación. Los datos de muestra en este caso tendrían este aspecto:
![\[Tabla para almacenar el estado de varios dispositivos. DeviceID es la clave principal y la fecha de actualización de estado es la clave de clasificación.\]](http://docs.aws.amazon.com/es_es/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-2-Step1.png)
Para recuperar las entradas de registro de un dispositivo concreto, podemos realizar una operación de [consulta](Query.md) con clave de partición `DeviceID="d#12345"`.
**Paso 2: Abordar el patrón de acceso 3 (`getWarningLogsForSpecificDevice`)**
Dado que `State` es un atributo no clave, abordar el patrón de acceso 3 con el esquema actual requeriría una [expresión de filtro](Query.FilterExpression.md). En DynamoDB, las expresiones de filtro se aplican después de leer los datos mediante expresiones de condición clave. Por ejemplo, si quisiéramos obtener los registros de advertencias de `d#12345`, la operación de consulta con clave de partición `DeviceID="d#12345"` leerá cuatro elementos de la tabla anterior y, a continuación, filtrará el único elemento sin el estado de *advertencia*. Este enfoque no es eficiente a escala. Una expresión de filtro puede ser una buena forma de excluir elementos consultados si la proporción de elementos excluidos es baja o la consulta se realiza con poca frecuencia. No obstante, para los casos en los que se recuperan muchos elementos de una tabla y la mayoría de los elementos se filtran, podemos seguir evolucionando el diseño de nuestra tabla para que funcione de forma más eficiente.
Cambiemos la forma de gestionar este patrón de acceso mediante [claves de clasificación compuestas](data-modeling-blocks.md#data-modeling-blocks-composite). Puede importar datos de muestra de [DeviceStateLog\$13.json](https://github.com/aws-samples/amazon-dynamodb-design-patterns/blob/master/examples/device-state-log/json/DeviceStateLog_3.json), donde la clave de clasificación se cambia a `State#Date`. Esta clave de clasificación es la composición de los atributos `State`, `#` y `Date`. En este ejemplo, `#` se utiliza como delimitador. Los datos tienen ahora este aspecto:
![\[Los datos de actualización de estado del dispositivo, d#12345, se obtuvieron con la clave de clasificación compuesta State#Date.\]](http://docs.aws.amazon.com/es_es/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-3-Step2.png)
Para obtener solo los registros de advertencia de un dispositivo, la consulta se vuelve más específica con este esquema. La condición clave para la consulta utiliza la clave de partición `DeviceID="d#12345"` y la clave de clasificación `State#Date begins_with “WARNING”`. Esta consulta solo leerá los tres elementos relevantes con el estado de *advertencia*.
**Paso 3: Abordar el patrón de acceso 4 (`getLogsForOperatorBetweenTwoDates`)**
Puede importar [DeviceStateLog\$14.jsonD](https://github.com/aws-samples/amazon-dynamodb-design-patterns/blob/master/examples/device-state-log/json/DeviceStateLog_4.json), donde se agregó el atributo `Operator` a la tabla `DeviceStateLog` con datos de ejemplo.
![\[Diseño de tabla DeviceStateLog con el atributo Operador para obtener los registros de un operador entre fechas específicas.\]](http://docs.aws.amazon.com/es_es/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-4-Step3.png)
Dado que `Operator` no es actualmente una clave de partición, no hay forma de realizar una búsqueda directa de clave-valor en esta tabla basada en `OperatorID`. Tendremos que crear una nueva [colección de elementos](WorkingWithItemCollections.md) con un índice secundario global en `OperatorID`. El patrón de acceso requiere una búsqueda basada en fechas, por lo que Fecha es el atributo de clave de clasificación para el [índice secundario global (GSI)](GSI.md). Este es el aspecto actual del GSI:
![\[Diseño de GSI con OperatorID y Fecha como clave de partición y clave de clasificación para obtener los registros de un operador específico.\]](http://docs.aws.amazon.com/es_es/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-5-Step3.png)
Para el patrón de acceso 4 (`getLogsForOperatorBetweenTwoDates`), puede consultar este GSI con clave de partición `OperatorID=Liz` y clave de clasificación `Date` entre `2020-04-11T05:58:00` y `2020-04-24T14:50:00`.
![\[Consultas en GSI con OperatorID y Fecha para obtener los registros de un operador entre dos fechas.\]](http://docs.aws.amazon.com/es_es/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-6-GSI1_1.png)
**Paso 4: Abordar patrones de acceso 5 (`getEscalatedLogsForSupervisor`), 6 (`getEscalatedLogsWithSpecificStatusForSupervisor`) y 7 (`getEscalatedLogsWithSpecificStatusForSupervisorForDate`)**
Utilizaremos un [índice disperso](data-modeling-blocks.md#data-modeling-blocks-sparse-index) para abordar estos patrones de acceso.
Los índices secundarios globales son dispersos de forma predeterminada, por lo que solo aparecerán en el índice los elementos de la tabla base que contengan atributos de clave principal del índice. Esta es otra forma de excluir elementos que no son relevantes para el patrón de acceso que se está modelando.
Puede importar [DeviceStateLog\$16.json](https://github.com/aws-samples/amazon-dynamodb-design-patterns/blob/master/examples/device-state-log/json/DeviceStateLog_6.json), donde se agregó el atributo `EscalatedTo` a la tabla `DeviceStateLog` con datos de ejemplo. Como ya se ha mencionado, no todos los registros se escalan a un supervisor.
![\[Diseño de GSI con el atributo EscalatedTo para obtener todos los registros escalados de un supervisor.\]](http://docs.aws.amazon.com/es_es/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-7-Step4.png)
Ahora puede crear un nuevo GSI en el que `EscalatedTo` es la clave de partición y `State#Date` es la clave de clasificación. Observe que solo aparecen en el índice los elementos que tienen los atributos `EscalatedTo` y `State#Date`.
![\[Diseño de GSI para obtener todos los elementos con los atributos EscalatedTo y State#Date.\]](http://docs.aws.amazon.com/es_es/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-8-Step4.png)
El resto de los patrones de acceso se resumen como sigue:
Para el patrón de acceso 5 (getEscalatedLogsForSupervisor), puede realizar una consulta en el GSI de escalados con la clave de partición EscalatedTo=“Sara” Para el patrón de acceso 6 (getEscalatedLogsWithSpecificStatusForSupervisor), puede realizar una consulta en el GSI de escalados con clave de partición EscalatedTo=“Sara” y clave de clasificación State\$1Date begins\$1with “WARNING”. Para el patrón de acceso 7 (getEscalatedLogsWithSpecificStatusForSupervisorForDate), puede realizar una consulta en el GSI de escalados con clave de partición EscalatedTo=“Sara” y clave de clasificación State\$1Date begins\$1with “WARNING4\$12020-04-27”.
En la tabla siguiente se resumen todos los patrones de acceso y cómo los aborda el diseño del esquema:
| Patrón de acceso | Tabla base/GSI/LSI | Operación | Valor de clave de partición | Valor de la clave de clasificación | Otras condiciones/filtros |
| --- | --- | --- | --- | --- | --- |
| createLogEntryForSpecificDevice | Tabla de base | PutItem | DeviceID=deviceId | State\$1Date=state\$1date | |
| getLogsForSpecificDevice | Tabla de base | Consultar | DeviceID=deviceId | State\$1Date begins\$1with “state1\$1” | ScanIndexForward = False |
| getWarningLogsForSpecificDevice | Tabla de base | Consultar | DeviceID=deviceId | State\$1Date begins\$1with “WARNING” | |
| getLogsForOperatorBetweenTwoDates | GSI-1 | Consultar | Operator=operatorName | Date between date1 and date2 | |
| getEscalatedLogsForSupervisor | GSI-2 | Consultar | EscalatedTo=supervisorName | | |
| getEscalatedLogsWithSpecificStatusForSupervisor | GSI-2 | Consultar | EscalatedTo=supervisorName | State\$1Date begins\$1with “state1\$1” | |
| getEscalatedLogsWithSpecificStatusForSupervisorForDate | GSI-2 | Consultar | EscalatedTo=supervisorName | State\$1Date begins\$1with “state1\$1date1” | |
## Esquema final
Estos son los diseños finales del esquema. Para descargar este diseño de esquema como un archivo JSON, consulte los [ejemplos de DynamoDB](https://github.com/aws-samples/aws-dynamodb-examples/tree/master/schema_design/SchemaExamples) en GitHub.
**Tabla base**
![\[Diseño de tabla base con metadatos del estado del dispositivo, como el ID del dispositivo, el estado y la fecha.\]](http://docs.aws.amazon.com/es_es/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-9-Table.png)
**GSI-1**
![\[Diseño de GSI-1. Muestra la clave principal y los atributos: DeviceID, State#Date y Estado.\]](http://docs.aws.amazon.com/es_es/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-10-GSI1.png)
**GSI-2**
![\[Diseño de GSI-2. Muestra la clave principal y los atributos: DeviceID, Operador, Fecha y Estado.\]](http://docs.aws.amazon.com/es_es/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-11-GSI2.png)
## Uso de NoSQL Workbench con este diseño de esquema
Puede importar este esquema final en [NoSQL Workbench](workbench.md), una herramienta visual que proporciona características de modelado de datos, visualización de datos y desarrollo de consultas para DynamoDB, a fin de explorar y editar más a fondo el nuevo proyecto. Para comenzar, siga estos pasos:
1. Descargue NoSQL Workbench. Para obtener más información, consulte [Descargar NoSQL Workbench para DynamoDB](workbench.settingup.md).
1. Descargue el archivo de esquema JSON que se muestra anteriormente, que ya está en el formato de modelo NoSQL Workbench.
1. Importe el archivo de esquema JSON en NoSQL Workbench. Para obtener más información, consulte [Importación de un modelo de datos existente](workbench.Modeler.ImportExisting.md).
1. Una vez que haya importado en NOSQL Workbench, podrá editar el modelo de datos. Para obtener más información, consulte [Edición de un modelo de datos existente](workbench.Modeler.Edit.md).