Datenverarbeitung
Zwischen der Aufnahme und der Visualisierung benötigt ThingWorx Platform auch genügend Systemressourcen, um die Geschäftslogik- und Datentransformationsanforderungen der Anwendung zu erfüllen.
In diesem Abschnitt werden die Konzepte für die aussagekräftigeren Bereiche erläutert, die sich auf die Datenverarbeitungsanforderungen auswirken können. Die Datenverarbeitung hängt stark von den spezifischen Geschäftsanwendungsfällen ab, wodurch eine standardisierte Berechnung weniger nützlich ist.
Sobald Ihre Aufnahme- und Visualisierungsschätzungen vorliegen, sind Anwendungslast- oder Stresstests ein wichtiger Schritt, bevor Sie live gehen. Diese könnten zur Auswahl eines Systems mit einer anderen Größe als der Baseline führen, wenn Ihre Anwendung weitere Ressourcen für komplexe Geschäftslogik oder Ereignis-/Warnungsverarbeitung benötigt.
Abonnements und Ereignisse
Abonnements für Zeitgeber und Eigenschaftsänderungsereignisse stellen häufig den größten Teil der Geschäftslogik in einer ThingWorx Anwendung dar. Diese Abonnements verwenden Arbeitsspeicher aus Untersystemen für die Ereignisverarbeitung, die während Aufnahme und Gerätekonnektivität nicht verwendet werden.
Sobald das System für eine stabile Aufnahme und Gerätekonnektivität dimensioniert ist, sind Lasttests mit Geschäftslogik ein wichtiger Schritt, um sicherzustellen, dass das System ordnungsgemäß dimensioniert wird, um die Verwendung in der Produktion zu unterstützen.
Dateiübertragung und -verwaltung
Das Übertragen von Dateien zu und von Edge-Geräten ist eine häufige Anforderung für ThingWorx Anwendungsfälle:
Bereitstellung von Software-Updates
Problembehandlung von oder Zugriff auf Protokolldateien
Erhalt von Bildern, PDFs oder anderen Dateien zur Prüfung von Funktionalität und Leistung
Wenn Sie viele gleichzeitige Dateiübertragungen und/oder die Übertragung großer Dateien erwarten, ist evtl. zusätzlicher Plattformarbeitsspeicher erforderlich, um diese Last zu verarbeiten.
Anforderungen hinsichtlich hoher Verfügbarkeit für ThingWorx
Bei der Bereitstellung in einer Hochverfügbarkeitskonfiguration (wie im Abschnitt Hochverfügbarkeit mit ThingWorx beschrieben) wird häufig eine relationale Datenbankkonfiguration mit hoher Verfügbarkeit verwendet.
Während diese Konfiguration Ausfallzeiten aufgrund eines Systemfehlers verhindern kann, führt sie evtl. auch zu einer geringfügigen Verschlechterung der Schreibleistung.
Um dies zu beheben, ziehen Sie die nächstgrößere Systemkonfiguration in Betracht, wenn die erwarteten WPS aus der Datenaufnahmeberechnung nahe am Schwellenwert für die gewünschte Konfiguration liegen.
Tunnel und Drittanbieter-Tools
Viele Geschäftsanwendungsfälle nutzen Tunneling-Sitzungen zu Edge-Geräten, für die WebSocket-Verbindungen während der Sitzungen offen sein und verwaltet werden müssen.
Ebenso können Tools von Drittanbietern (wie SCADA, ERP oder andere integrierte Back-Office-Anwendungen) ebenfalls WebSocket-Verbindungen zur Plattform verwenden.
Wenn diese Tools auf ThingWorx mit REST API-Aufrufen zugreifen, wird dadurch die Anzahl der zuvor für die Datenvisualisierung berechneten HTTP-Anforderungen pro Sekunde erhöht.
Jede WebSocket-Verbindung erfordert Arbeitsspeicher auf der Plattform. Daher sollten Sie die Gesamtarbeitsspeicherbelegung auf der Plattform erhöhen (oder die Größe/Klasse der ausgewählten VM), wenn viele gleichzeitige Tunneling-Sitzungen oder REST API-Anforderungen erwartet werden.
Datenbeibehaltung, -aggregation und -archivierung
Historische Daten werden häufig sowohl für die Datenverarbeitung (Wie weit zurück muss meine Geschäftslogik gehen?) als auch für die Datenvisualisierung (Wie weit zurück müssen Benutzer gehen?) benötigt.
Die Menge an historischen Daten, die auf der Plattform gespeichert werden sollen, hat Auswirkungen auf die Größe von Datenbank und Plattform. Für größere Datenquellen (Streams, Datentabellen und Wert-Streams) sind längere Transaktionen erforderlich, um die Datenbank abzufragen. Diese langen Transaktionen können auch dazu führen, dass die Stream- und Wert-Stream-Warteschlangen gesichert werden und zusätzlichen Arbeitsspeicher verwenden.
Das Aggregieren von Daten wird dringend empfohlen, sodass keine Datenquelle zu viele Einträge enthält. (Details finden Sie in diesem Handbuch zu optimalen Vorgehensweisen.) Wenn eine große Menge historischer Daten benötigt wird oder große Mengen an aufgenommenen Daten über einen längeren Zeitraum aufbewahrt werden müssen, sollten Sie eine robustere Datenbanklösung in Betracht ziehen. Unten finden Sie Details zu den Datenbankoptionen:
H2 – Kleine In-Memory-Datenbank, die ideal für die Entwicklung und kleinere Systeme geeignet ist; lässt sich nicht gut über kleine Implementierungen hinaus skalieren.
* 
H2 wird für ThingWorx Produktionssysteme nicht empfohlen.
Microsoft SQL Server – Robuste, ausgereifte relationale Datenbank, die verwendet werden kann, um ThingWorx Datenmodelle, Streams und Wert-Streams in Entwicklungs- oder Produktionssystemen zu verwalten. Sie kann für alle kleinen, mittelgroßen und großen Implementierungen skaliert werden.
PostgreSQL – PostgreSQL ist ähnlich wie SQL Server eine relationale Datenbank, die in Produktionsumgebungen jeder Größe verwendet werden kann. Die Wahl zwischen SQL Server und PostgreSQL wird häufig durch vorhandene IT-Erfahrung entschieden, entweder mit Datenbanken oder Betriebssystemen.
InfluxDB – Zeitreihen-Datenbank, die ideal für die umfassende Aufnahme von ThingWorx Streams und Wert-Streams in Entwicklungs- und Produktionssysteme geeignet ist, neben einer relationalen Datenbank (Microsoft SQL Server oder PostgreSQL) zur Verwaltung des ThingWorx Datenmodells.
* 
ThingWorx kann entweder mit der Single-Server-Version von InfluxDB (Open Source) oder einem InfluxDB Enterprise-Cluster für hohe Verfügbarkeit und mehr Leistung verwendet werden. Die Open-Source-Version wurde für die Tests in diesem Handbuch verwendet.
War dies hilfreich?