PTC empfiehlt, sich zuerst mit ThingWorx Modellierungskonzepten vertraut zu machen, damit Sie dem Rest dieses Abschnitts besser folgen können. Weitere Informationen finden Sie unter ThingWorx Modelldefinition in Composer. Ein Modell in ThingWorx ist eine logische Darstellung Ihrer physischen Umgebung und Ihrer Lösungslandschaft. Diese logische Darstellung wird durch Erstellen von Instanzen der integrierten Modellelement-Vorlagen, z.B. Ding, Dingvorlage, Dingform und Data Shape, realisiert. Dieser Abschnitt enthält Empfehlungen zur Konstruktion des Datenspeicheraspekts der auf dem ThingWorx Modell basierenden Lösung. In ThingWorx gibt es mehrere Optionen zum Speichern von Daten. Diese Optionen zu verstehen hilft Ihnen dabei, die beste Speicherlösung für Ihre Daten zu finden:

ThingWorx Basistypen stellen eine Abstraktionsebene bereit, welche die ThingWorx Anwendungsentwicklungsumgebung von den spezifischen Edge-Datentypen sowie vom Datenspeicher isoliert. Dies ermöglicht es ThingWorx Anwendungen, unabhängig von Datenspeichern zu sein, und erlaubt das Ändern der Basistypen zur Laufzeit, ohne das zugrunde liegende Datenbankschema ändern zu müssen.

Ein Data Shape ist ein benannter Satz von Felddefinitionen und zugehörigen Metadaten, wobei jedes Feld ein Basistyp ist. Ein Data Shape entspricht in etwa dem Konzept einer relationalen Datenbanktabelle, in der die Basistypen dem Datentyp eines Felds ähneln.

Die Datenerfassung in ThingWorx Platform erfolgt hauptsächlich über Dingeigenschaften, bei denen ein verbundenes Gerät als Ding in ThingWorx modelliert wird. Eine allgemeine Beschreibung finden Sie unter Dingeigenschaften.

Der folgende Anwendungsfall veranschaulicht die verschiedenen Datenspeicheroptionen, die zum Speichern von Dingeigenschaften zur Verfügung stehen. Ein Traktor-Ding hat beispielweise die Traktormotor-Dingform mit den folgenden Eigenschaften: Maximale Drehzahl, Motortemperatur und Datum des letzten Ölwechsels.

Diese Eigenschaften haben drei Datenspeicheroptionen: schreibgeschützt, persistent und protokolliert. Im obigen Beispiel wird Folgendes empfohlen:

Ein Stream dient zum Speichern eines Blobs von Zeitreihendaten. Jeder Stream-Eintrag hat einen Zeitstempel, eine Quelle, einen Quelltyp, Feldwerte, Daten-Tags und einen Speicherort. Die Liste der Felder ist in einem Data Shape definiert und dem Stream zugeordnet. Die Feldwerte für diese Liste mit Feldern werden in einer einzelnen Spalte als JSON- oder als Text-Blob im Stream gespeichert. Wird ein einzelner Feldwert abgefragt, so werden alle Zeilen mit übereinstimmenden Feldwerten zurückgegeben. Das bedeutet, die Daten werden schneller abgerufen, wenn von den Streams nur Feldwerte für eine gegebene Quelle für einen kurzen Zeitraum zurückgegeben werden. Bei einer Abfrage mit einer Bedingung für einen bestimmten Feldwert müssen die Daten für den Feldwert auf Anwendungsebene gefiltert werden.

Optimale Vorgehensweisen:

Ein Wert-Stream dient zum Speichern einzelner Eigenschaften eines Dings als Zeitreihendaten. Eine Eigenschaft in einem Ding muss als protokolliert definiert werden, damit sie als Zeitreihendaten angesehen wird, und sie muss einen Wert-Stream für die Datenspeicherung verwenden. Jeder Wert-Stream-Eintrag hat einen Zeitstempel, eine Quelle, einen Eigenschaftstyp, einen Eigenschaftsnamen sowie einen Eigenschaftswert. Dies steht im Gegensatz zum Speichermodell der Streams, bei denen der gesamte Satz an Feldwerten in einer Feldwert-Spalte in einer einzelnen Zeile als JSON- oder als Text-Blob gespeichert wird. Wert-Streams hingegen speichern jeden Eigenschaftswert in einer separaten Zeile mit einer Quelle und einem Zeitstempel. Wenn Sie die Eigenschaftsdaten für ein Ding in einem Wert-Stream abfragen, werden nur Werte für diese Eigenschaft zurückgegeben.

Wert-Streams sind für dinggesteuerte Modelle von Vorteil. Es wird empfohlen, Dinge über mehrere Wert-Streams hinweg aufzuteilen, um die Indexleistung zu verbessern. Obwohl es sich hierbei streng genommen nicht um eine optimale Vorgehensweise handelt, sollte in bestimmten Datenerfassungsszenarien mit hohem Volumen (Daten übersteigen die Erfassungsraten im Dimensionierungshandbuch) in Erwägung gezogen werden, mehrere Persistenzanbieter zu erstellen, die auf separate Datenbankinstanzen verweisen. Dadurch wird sichergestellt, dass Daten in verschiedene Tabellen in der Datenbank eingefügt werden. Wenn mehrere Datenbanken hinzugefügt werden, können die Persistenzanbieter auf bestimmte Datenbanken verweisen. Dieses Szenario erfordert ebenfalls eine Datenmigration.

Wenn Sie ein RDMS (PostgreSQL, MSSQL, H2) verwenden, werden alle Datensätze, auch aus unterschiedlichen Wert-Streams für verschiedene Dinge, in dieselbe Tabelle in der Datenbank geschrieben.

Wenn Sie PostgreSQL verwenden, enthält jede Zeile in der Tabelle für ValueStream in der PostgreSQL-Datenbank einen Datensatz für eine Eigenschaft. Dies bedeutet, dass der Wert-Stream die Wertänderung für jede Eigenschaft verfolgt und nach der Verwendung des QueryPropertyHistory-Diensts den Datenfluss für jede Eigenschaft im Ding prüft und sämtliche neuesten Aktualisierungen (jede hat eine andere Aktualisierungszeit) in einem Infotable-Ergebnis sammelt.

Eine Datentabelle ist eine ThingWorx Entität, die im Grunde eine Abstraktion einer standardmäßigen relationalen Datenbanktabelle ist, welche verwendet werden kann, um die ThingWorx Anwendungsentwicklung zu vereinfachen und zu beschleunigen. Es ist jedoch zu beachten, dass die Backend-Implementierung einer Datentabelle nicht der einer relationalen Datenbanktabelle entspricht und sie nicht über die volle Flexibilität einer relationalen Datenbanktabelle verfügt. Datentabellen sind eine hochwertige ThingWorx Entität und ermöglichen eine wesentlich einfachere Verarbeitung der Datenzugriffsfunktionen auf ThingWorx Modellebene. Ein Data Shape, welcher der Datentabelle zugeordnet wird, definiert die Spalten oder Felder der Datentabelle und ihren primären Schlüssel. Er ersetzt jedoch keine standardmäßige relationale Datenbanktabelle in Bezug auf Leistung und Skalierbarkeit.

Weitere Informationen finden Sie unter Optimale Vorgehensweisen für Datentabellen und Dimensionierungsgrenzwerte von Datentabellen.