Überwachung von Gerätestatusaktualisierungen in DynamoDB

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.

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.

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:

Diagramm der Entitätsbeziehungen

Wir nutzen dieses Diagramm der Entitätsbeziehungen zur Überwachung von Gerätestatusaktualisierungen.

Zugriffsmuster

Diese Zugriffsmuster ziehen wir für die Überwachung von Gerätestatusaktualisierungen in Betracht.

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:

Um Protokolleinträge für ein bestimmtes Gerät abzurufen, können wir einen Query-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 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 Partitionsschlüssel DeviceID="d#12345" vier Elemente aus der obigen Tabelle lesen und dann das Element mit dem 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 nutzen. Sie können Beispieldaten aus 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:

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_4.json D importieren, wo das Operator Attribut der DeviceStateLog Tabelle mit Beispieldaten hinzugefügt wurde.

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 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). So sieht der GSI jetzt aus:

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.

Schritt 4: Zugriffsmuster 5 (getEscalatedLogsForSupervisor), 6 (getEscalatedLogsWithSpecificStatusForSupervisor) und 7 (getEscalatedLogsWithSpecificStatusForSupervisorForDate) angehen

Wir verwenden einen spärlichen 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_6.json importieren, wo das EscalatedTo Attribut der Tabelle mit Beispieldaten hinzugefügt wurde. DeviceStateLog Wie bereits erwähnt, werden nicht alle Protokolle an einen Supervisor eskaliert.

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.

Die übrigen Zugriffsmuster sind wie folgt zusammengefasst:

Alle Zugriffsmuster und wie das Schemadesign sie behandelt, sind in der folgenden Tabelle zusammengefasst:

Endgültiges Schema

Dies sind die endgültigen Schemadesigns. Informationen zum Herunterladen dieses Schemadesign als JSON-Datei finden Sie unter DynamoDB-Beispiele auf. GitHub

Basistabelle

GSI-1

GSI-2

Verwendung von NoSQL Workbench mit diesem Schemadesign

Sie können dieses endgültige Schema in NoSQL Workbench 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: