Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Überwachung von Gerätestatusaktualisierungen in DynamoDB
In diesem Anwendungsfall geht es um die Verwendung von DynamoDB zur Überwachung von Gerätestatusaktualisierungen (oder -änderungen) in DynamoDB.
## Anwendungsfall
Bei IoT-Anwendungsfällen (z. B. Smart Factory) müssen viele Geräte von den Betreibern überwacht werden und ihr Status oder ihre Protokolle werden regelmäßig an ein Überwachungssystem gesendet. Wenn bei einem Gerät ein Problem auftritt, ändert sich sein Status von *normal* in *warning*. Je nach Schweregrad und Art des abnormalen Verhaltens des Geräts gibt es unterschiedliche Protokollstufen oder Status. Das System fordert dann einen Betreiber auf, das Gerät zu überprüfen, und dieser leitet das Problem gegebenenfalls an einen Supervisor weiter.
Zu den typischen Zugriffsmustern für dieses System gehören:
+ Protokolleintrag für ein Gerät erstellen
+ Alle Protokolle für einen bestimmten Gerätestatus abrufen, wobei die neuesten Protokolle zuerst angezeigt werden
+ Alle Protokolle für einen bestimmten Betreiber und einen bestimmten Zeitraum abrufen
+ Alle eskalierten Protokolle für einen bestimmten Supervisor abrufen
+ Alle eskalierten Protokolle mit einem bestimmten Gerätestatus für einen bestimmten Supervisor abrufen
+ Alle eskalierten Protokolle mit einem bestimmten Gerätestatus für einen bestimmten Supervisor und ein bestimmtes Datum abrufen
## Diagramm der Entitätsbeziehungen
Wir nutzen dieses Diagramm der Entitätsbeziehungen zur Überwachung von Gerätestatusaktualisierungen.
![\[ERD mit Gerätestatusaktualisierungen. Es werden die Entitäten „Device“ und „Operator“ angezeigt.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-1-ERD.jpg)
## Zugriffsmuster
Diese Zugriffsmuster ziehen wir für die Überwachung von Gerätestatusaktualisierungen in Betracht.
1. `createLogEntryForSpecificDevice`
1. `getLogsForSpecificDevice`
1. `getWarningLogsForSpecificDevice`
1. `getLogsForOperatorBetweenTwoDates`
1. `getEscalatedLogsForSupervisor`
1. `getEscalatedLogsWithSpecificStatusForSupervisor`
1. `getEscalatedLogsWithSpecificStatusForSupervisorForDate`
## Entwicklung des Schemadesigns
**Schritt 1: Zugriffsmuster 1 (`createLogEntryForSpecificDevice`) und 2 (`getLogsForSpecificDevice`) angehen**
Die Skalierungseinheit für ein Nachverfolgungssystem für Geräte wären individuelle Geräte. In diesem System wird ein Gerät durch eine `deviceID` eindeutig identifiziert. Dadurch wäre die `deviceID` gut für den Partitionsschlüssel geeignet. Jedes Gerät sendet in regelmäßigen Abständen (etwa alle fünf Minuten) Informationen an das Nachverfolgungssystem. Diese Reihenfolge macht das Datum zu einem logischen Sortierkriterium und damit zum Sortierschlüssel. In diesem Fall sähen die Beispieldaten in etwa so aus:
![\[Tabelle zum Speichern des Status mehrerer Geräte. „DeviceID“ ist der Primärschlüssel und das Datum der Statusaktualisierung ist der Sortierschlüssel.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-2-Step1.png)
Um Protokolleinträge für ein bestimmtes Gerät abzurufen, können wir einen [Query](Query.md)-Vorgang mit dem Partitionsschlüssel `DeviceID="d#12345"` durchführen.
**Schritt 2: Zugriffsmuster 3 (`getWarningLogsForSpecificDevice`) angehen**
Da `State` kein Schlüsselattribut ist, wäre ein [Filterausdruck](Query.FilterExpression.md) erforderlich, um Zugriffsmuster 3 mit dem aktuellen Schema anzugehen. In DynamoDB werden Filterausdrücke angewendet, nachdem Daten mithilfe von Schlüsselbedingungsausdrücken gelesen wurden. Wenn wir beispielsweise Warnprotokolle für `d#12345` abrufen wollten, würde der Abfragevorgang mit dem Partitionsschlüssel `DeviceID="d#12345"` vier Elemente aus der obigen Tabelle lesen und dann das Element ohne den Status *warning* herausfiltern. Zur Anwendung im großen Maßstab ist dieser Ansatz nicht effizient. Ein Filterausdruck eignet sich, um abgefragte Elemente auszuschließen, wenn der Anteil der ausgeschlossenen Elemente gering ist oder die Abfrage selten ausgeführt wird. In Fällen, in denen viele Elemente aus einer Tabelle abgerufen und der Großteil der Elemente herausgefiltert werden, sollten wir jedoch unser Tabellendesign erweitern, damit es effizienter funktioniert.
Ändern wir nun unseren Ansatz für dieses Zugriffsmuster, indem wir [zusammengesetzte Sortierschlüssel](data-modeling-blocks.md#data-modeling-blocks-composite) nutzen. Sie können Beispieldaten aus [DeviceStateLog\$13.json](https://github.com/aws-samples/amazon-dynamodb-design-patterns/blob/master/examples/device-state-log/json/DeviceStateLog_3.json) importieren, wo der Sortierschlüssel geändert wird. `State#Date` Dieser Sortierschlüssel ist eine Zusammensetzung aus den Attributen `State`, `#` und `Date`. In diesem Beispiel dient `#` als Trennzeichen. Die Daten sehen jetzt in etwa so aus:
![\[Statusaktualisierungsdaten für das Gerät d#12345, abgerufen mit dem zusammengesetzten Sortierschlüssel „State#Date“.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-3-Step2.png)
Die Abfrage wird mit diesem Schema zielgerichteter und eignet sich besser, um nur Warnprotokolle für ein Gerät abzurufen. Die Schlüsselbedingung für die Abfrage verwendet den Partitionsschlüssel `DeviceID="d#12345"`und den Sortierschlüssel `State#Date begins_with “WARNING”`. Diese Abfrage liest nur die drei relevanten Elemente mit Status *warning*.
**Schritt 3: Zugriffsmuster 4 (`getLogsForOperatorBetweenTwoDates`) angehen**
Sie können [DeviceStateLog\$14.json](https://github.com/aws-samples/amazon-dynamodb-design-patterns/blob/master/examples/device-state-log/json/DeviceStateLog_4.json) D importieren, wo das `Operator` Attribut der `DeviceStateLog` Tabelle mit Beispieldaten hinzugefügt wurde.
![\[DeviceStateLog Tabellendesign mit dem Operator-Attribut, um die Logs eines Operators zwischen bestimmten Daten abzurufen.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-4-Step3.png)
Da `Operator` derzeit kein Partitionsschlüssel ist, gibt es keine Möglichkeit, in dieser Tabelle eine direkte Schlüssel-Wert-Suche auf der Grundlage von `OperatorID` durchzuführen. Wir müssen eine neue [Elementauflistung](WorkingWithItemCollections.md) mit einem globalen sekundären Index für `OperatorID` erstellen. Das Zugriffsmuster erfordert eine Suche auf der Grundlage von Daten, also ist Date (Datum) das Sortierschlüsselattribut für den [globalen sekundären Index (GSI)](GSI.md). So sieht der GSI jetzt aus:
![\[GSI-Design mit „OperatorID“ und „Date“ als Partitionsschlüssel und Sortierschlüssel zum Abrufen von Protokollen für einen bestimmten Operator.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-5-Step3.png)
Für Zugriffsmuster 4 (`getLogsForOperatorBetweenTwoDates`) können Sie diesen GSI mit dem Partitionsschlüssel `OperatorID=Liz` und Sortierschlüssel `Date` zwischen `2020-04-11T05:58:00` und `2020-04-24T14:50:00` abfragen.
![\[Abfragen von GSI mithilfe von „OperatorID“ und „Date“, um Protokolle für einen Operator zwischen zwei Daten abzurufen.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-6-GSI1_1.png)
**Schritt 4: Zugriffsmuster 5 (`getEscalatedLogsForSupervisor`), 6 (`getEscalatedLogsWithSpecificStatusForSupervisor`) und 7 (`getEscalatedLogsWithSpecificStatusForSupervisorForDate`) angehen**
Wir verwenden einen [spärlichen Index](data-modeling-blocks.md#data-modeling-blocks-sparse-index), um diese Zugriffsmuster anzugehen.
Globale sekundäre Indizes sind standardmäßig spärlich, sodass nur Elemente aus der Basistabelle, die Primärschlüsselattribute des Indexes enthalten, tatsächlich im Index erscheinen. Das ist eine weitere Möglichkeit, Elemente auszuschließen, die für das modellierte Zugriffsmuster nicht relevant sind.
Sie können [DeviceStateLog\$16.json](https://github.com/aws-samples/amazon-dynamodb-design-patterns/blob/master/examples/device-state-log/json/DeviceStateLog_6.json) importieren, wo das `EscalatedTo` Attribut der `DeviceStateLog` Tabelle mit Beispieldaten hinzugefügt wurde. Wie bereits erwähnt, werden nicht alle Protokolle an einen Supervisor eskaliert.
![\[GSI-Design mit dem EscalatedTo Attribut zum Abrufen aller eskalierten Protokolle für einen Supervisor.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-7-Step4.png)
Sie können jetzt einen neuen GSI erstellen, bei dem `EscalatedTo` der Partitionsschlüssel und `State#Date` der Sortierschlüssel ist. Beachten Sie, dass nur Elemente, die `EscalatedTo`- und `State#Date`-Attribute erhalten, im Index erscheinen.
![\[GSI-Design, um alle Elemente mit den Attributen EscalatedTo und State #Date abzurufen.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-8-Step4.png)
Die übrigen Zugriffsmuster sind wie folgt zusammengefasst:
Für das Zugriffsmuster 5 (getEscalatedLogsForSupervisor) können Sie mit dem Partitionsschlüssel ="Sara“ eine Abfrage an der GSI für Eskalationen durchführen EscalatedTo Für das Zugriffsmuster 6 (getEscalatedLogsWithSpecificStatusForSupervisor) können Sie mit dem Partitionsschlüssel EscalatedTo ="Sara“ und dem Sortierschlüssel State \$1Date begins\$1with „WARNING“ eine Abfrage an der GSI für Eskalationen durchführen Für das Zugriffsmuster 7 (getEscalatedLogsWithSpecificStatusForSupervisorForDate) können Sie mit dem Partitionsschlüssel EscalatedTo ="Sara“ und dem Sortierschlüssel State \$1Date begins\$1with „\$12020 -04-27“ eine Abfrage an der GSI für Eskalationen durchführen WARNING4
Alle Zugriffsmuster und wie das Schemadesign sie behandelt, sind in der folgenden Tabelle zusammengefasst:
| Zugriffsmuster | Basis-table/GSI/LSI | Operation | Partitionsschlüsselwert | Sortierschlüsselwert | Sonstige Bedingungen/Filter |
| --- | --- | --- | --- | --- | --- |
| createLogEntryForSpecificDevice | Basistabelle | PutItem | DeviceID=deviceId | State\$1Date=state\$1date | |
| getLogsForSpecificDevice | Basistabelle | Query | DeviceID=deviceId | State\$1Date begins\$1with "state1\$1" | ScanIndexForward = Falsch |
| getWarningLogsForSpecificDevice | Basistabelle | Query | DeviceID=deviceId | State\$1Date begins\$1with "WARNING" | |
| getLogsForOperatorBetweenTwoDates | GSI-1 | Query | Operator=operatorName | Datum zwischen Datum1 und Datum2 | |
| getEscalatedLogsForSupervisor | GSI-2 | Query | EscalatedTo=Name des Vorgesetzten | | |
| getEscalatedLogsWithSpecificStatusForSupervisor | GSI-2 | Query | EscalatedTo=Name des Vorgesetzten | State\$1Date begins\$1with "state1\$1" | |
| getEscalatedLogsWithSpecificStatusForSupervisorForDate | GSI-2 | Query | EscalatedTo=Name des Vorgesetzten | State\$1Date begins\$1with "state1\$1date1" | |
## Endgültiges Schema
Dies sind die endgültigen Schemadesigns. Informationen zum Herunterladen dieses Schemadesign als JSON-Datei finden Sie unter [DynamoDB-Beispiele](https://github.com/aws-samples/aws-dynamodb-examples/tree/master/schema_design/SchemaExamples) auf. GitHub
**Basistabelle**
![\[Basistabellendesign mit Metadaten zum Gerätestatus wie Geräte-ID, Status und Datum.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-9-Table.png)
**GSI-1**
![\[GSI-1-Design. Zeigt den Primärschlüssel und die Attribute „DeviceID“, „State#Date“ und „State“.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-10-GSI1.png)
**GSI-2**
![\[GSI-2-Design. Zeigt den Primärschlüssel und die Attribute „DeviceID“, „Operator“, „Date“ und „State“.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-11-GSI2.png)
## Verwendung von NoSQL Workbench mit diesem Schemadesign
Sie können dieses endgültige Schema in [NoSQL Workbench](workbench.md) importieren, um Ihr neues Projekt weiter zu untersuchen und zu bearbeiten. NoSQL Workbench ist ein visuelles Tool, das Features zur Datenmodellierung, Datenvisualisierung und Abfrageentwicklung für DynamoDB bereitstellt. Gehen Sie folgendermaßen vor, um zu beginnen:
1. Laden Sie NoSQL Workbench herunter. Weitere Informationen finden Sie unter [Herunterladen von NoSQL Workbench for DynamoDB](workbench.settingup.md).
1. Laden Sie die oben aufgeführte JSON-Schemadatei herunter, die bereits das NoSQL-Workbench-Modellformat aufweist.
1. Importieren Sie die JSON-Schemadatei in NoSQL Workbench. Weitere Informationen finden Sie unter [Importieren eines vorhandenen Datenmodells](workbench.Modeler.ImportExisting.md).
1. Nach dem Import in NOSQL Workbench können Sie das Datenmodell bearbeiten. Weitere Informationen finden Sie unter [Bearbeiten eines vorhandenen Datenmodells](workbench.Modeler.Edit.md).