PostgreSQL als Persistenzanbieter verwenden
PostgreSQL ist ein objektrelationales Open Source-Datenbanksystem. Der Persistenzanbieter PostgreSQL unterstützt Modell- und Datenanbieter.
 |
Die ersten Schritte mit PostgreSQL umfassen Registrierung, Installation und Konfiguration. Der Großteil dieses Prozesses wird unabhängig von ThingWorx durchgeführt und ist unter ThingWorx installieren dokumentiert.
|
PostgreSQL HA
Sie können PostgreSQL High Availability (HA) als Teil der Datenlösung verwenden. HA ermöglicht es Ihnen, separate Server einzurichten, um Lese- und Schreibvorgänge für Daten zu erfassen, wenn diese auf dem primären Server fehlschlagen. Wenn HA Teil der PostgreSQL-Implementierung ist, referenzieren Sie die entsprechenden Abschnitte im Handbuch für empfohlene Installations- und Bereitstellungsdetails.
Allgemeiner Prozess für die PostgreSQL-Implementierung
1. Bestimmen Sie, ob PostgreSQL die richtige Lösung für Ihre Daten ist. Referenzieren Sie die Dimensionierungs- und Planungsabschnitte für zusätzliche Informationen.
2. Laden Sie PostgreSQL herunter, und installieren Sie es. Dieser Prozess wird unabhängig von ThingWorx durchgeführt. Ein Bereitstellungsbeispiel ist im Handbuch vorhanden.
|
|
Die PostgreSQL-Standardimplementierung umfasst einen Persistenzanbieter, der nicht in ThingWorx bearbeitet werden kann. Sie können ihn jedoch über die Datei "platform-settings.json" oder Dienste bearbeiten.
|
3. Wenn Sie zusätzliche Persistenzanbieter-Instanzen in ThingWorx erstellen möchten, die mit dem PostgreSQL-Datenspeicher verbunden sind, gehen Sie zu > , und klicken Sie auf das grüne Pluszeichen (+).
4. Geben Sie im Bildschirm Allgemeine Informationen einen Namen für den Persistenzanbieter ein.
5. Verwenden Sie im Feld Persistenzanbieter-Paket den Zauberstab, um das PostgreSQL-Persistenzanbieter-Paket auszuwählen.
6. Klicken Sie auf Konfiguration, und konfigurieren Sie folgende Einstellungen:
Sie können die folgenden Stream- und Wert-Stream-Warteschlangeneinstellungen bearbeiten, die für alle Streams und Wert-Streams gelten. Sie können diese Einstellungen für einen bestimmten Stream oder Wert-Stream nicht ändern.
|
Stream-Prozessoreinstellungen
|
Basistyp
|
Standard
|
Hinweise
|
|---|---|---|---|
|
Maximale Warteschlangengröße
|
Number
|
250000
|
Maximale Anzahl der Stream-Einträge in der Warteschlange.Sobald der angegebene Wert erreicht ist, werden die folgenden Einträge zurückgewiesen.
|
|
Maximale Wartezeit vor der Leerung des Stream-Puffers (Millisek.)
|
Number
|
2000
|
Anzahl der Millisekunden, die das System wartet, bevor der Stream-Puffer geleert wird
|
|
Anzahl der Verarbeitungs-Threads
|
Number
|
5
|
Anzahl der Verarbeitungs-Threads, die dem Stream zugeordnet sind
|
|
Maximale Anzahl der Elemente vor der Leerung des Stream-Puffers
|
Number
|
500
|
Maximale Anzahl von Elementen, die erfasst werden, bevor der Stream-Puffer geleert wird
|
|
Maximale Anzahl der Stream-Schreibvorgänge im Verarbeitungsblock
|
Number
|
2500
|
Maximale Anzahl der Stream-Schreibvorgänge zum Verarbeiten in einem Block
|
|
Pufferstatus-Scanrate (Millisek.)
|
Number
|
5
|
Der Pufferstatus wird in der angegebenen Rate in Millisekunden geprüft.
|
|
Abfrage-Timeout
|
Number
|
600000
|
Dauer (in Millisekunden), die eine Abfrage auf den Abschluss wartet, bevor sie abgebrochen wird.
|
|
Netzwerk-Timeout
|
Number
|
900000
|
Dauer (in Millisekunden), die ein Thread auf Antwort von der Datenbank wartet.
Wenn keine Antwort innerhalb dieser konfigurierten Dauer empfangen wird, schließt die Plattform die zugrunde liegende Verbindung und gibt den auf Antwort wartenden Thread frei.
|
|
Producer-Timeout
|
Number
|
3000
|
Diese Einstellung gilt für die Stream-Eintragsprozessoren und ist aktuell nur für den persistenten Eigenschaftsprozessor wirksam.
Wenn eine Warteschlange voll ist und keinen Platz für einen neuen Eintrag hat, ist dies die maximale Dauer (Millisekunden), die ein Producer wartet, dass der Eintrag in die Warteschlange gestellt wird. Wenn die Wartezeit vorüber, die Warteschlange weiterhin voll und immer noch kein Platz ist, wird der Eintrag nicht zur Warteschlange hinzugefügt.
|
|
Wert-Stream-Prozessoreinstellungen
|
Basistyp
|
Standard
|
Hinweise
|
|---|---|---|---|
|
Maximale Warteschlangengröße
|
Number
|
250000
|
Maximale Anzahl der Wert-Stream-Einträge in der Warteschlange.Sobald der angegebene Wert erreicht ist, werden die folgenden Einträge zurückgewiesen.
|
|
Maximale Wartezeit vor der Leerung des Wert-Stream-Puffers (Millisek.)
|
Number
|
2000
|
Anzahl der Millisekunden, die das System wartet, bevor der Wert-Stream-Puffer geleert wird
|
|
Anzahl der Verarbeitungs-Threads
|
Number
|
5
|
Anzahl der Verarbeitungs-Threads, die dem Wert-Stream zugeordnet sind
|
|
Maximale Anzahl der Elemente vor der Leerung des Wert-Puffers
|
Number
|
500
|
Maximale Anzahl von Elementen, die erfasst werden, bevor der Wert-Stream-Puffer geleert wird
|
|
Maximale Anzahl der Wert-Stream-Schreibvorgänge im Verarbeitungsblock
|
Number
|
2500
|
Maximale Anzahl der Wert-Stream-Schreibvorgänge zum Verarbeiten in einem Block
|
|
Pufferstatus-Scanrate (Millisek.)
|
Number
|
5
|
Der Pufferstatus wird in der angegebenen Rate in Millisekunden geprüft.
|
|
Producer-Timeout
|
Number
|
3000
|
Diese Einstellung gilt für die Stream-Eintragsprozessoren und ist aktuell nur für den persistenten Eigenschaftsprozessor wirksam.
Wenn eine Warteschlange voll ist und keinen Platz für einen neuen Eintrag hat, ist dies die maximale Dauer (Millisekunden), die ein Producer wartet, dass der Eintrag in die Warteschlange gestellt wird. Wenn die Wartezeit vorüber, die Warteschlange weiterhin voll und immer noch kein Platz ist, wird der Eintrag nicht zur Warteschlange hinzugefügt.
|
|
Stapelüberwachungs-Einstellungen für die Datenbankverbindung
|
Standard
|
Hinweise
|
|---|---|---|
|
Schwellenwert für die Datenbankverbindung der Pool-Sättigung zum Auslösen von Stapelüberwachungen (in Prozent)
|
90
|
Schwellwert für Datenbankverbindungspool zum Erreichen der Sättigung und Auslösen von Stapelüberwachungen.
|
|
Anzahl der Sätze von Stapelüberwachungen, die nach dem Auslösen protokolliert werden
|
5
|
Anzahl der Sätze von Stapelüberwachungen, die nach dem Auslösen von Überwachungseinstellungen protokolliert werden
|
|
Intervall, für das die Stapelüberwachungen protokolliert werden (in Sekunden)
|
10
|
Zeitintervall, für das die Stapelüberwachungen protokolliert werden.
|
|
Minimal verstrichene Zeit, bevor die Stapelüberwachungs-Protokollierung erneut ausgelöst wird (in Minuten)
|
60
|
Minimal verstrichene Zeit, bevor die Stapelüberwachungs-Protokollierung erneut ausgelöst wird.
|
|
Dauer des Haltens der Verbindung zum Protokollieren von Stapelüberwachungen (in Millisekunden)
|
1000
|
Dauer des Haltens der Verbindung zum Protokollieren von Stapelüberwachungen.
|
|
Name
|
Standardwert
|
Hinweise
|
|---|---|---|
|
JDBC-URL
|
jdbc:postgresql://localhost:5432/thingworx
|
JDBC-URL der Datenbank, von der Verbindungen abgerufen werden sollen. Sie können mehrere Schemas in dieser URL angeben.
|
|
Benutzername
|
thingworx
|
Benutzername zum Abrufen einer Datenbankverbindung
|
|
Passwort
|
N/A
|
Passwort zum Abrufen einer Datenbankverbindung
|
|
Verbindungspool-Anfangsgröße
|
5
|
Anzahl von Verbindungen, die ein Pool versucht, beim Start abzurufen
|
|
Inkrement beim Abrufen der Verbindung
|
5
|
Bestimmt, wie viele Verbindungen abgerufen werden, wenn der Pool ausgeschöpft ist
|
|
Maximale Verbindungspoolgröße
|
100
|
Maximale Anzahl von Verbindungen, die ein Pool zu einem beliebigen Zeitpunkt aufrechterhält
|
|
Mindest-Verbindungspoolgröße
|
5
|
Minimale Anzahl von Verbindungen, die ein Pool zu einem beliebigen Zeitpunkt aufrechterhält
|
|
Maximale zwischengespeicherte Anweisungen
|
100
|
Größe des globalen PreparedStatement-Cache
|
|
Treiberklasse
|
org.postgresql.Driver
|
Datenbank-JDBC-Treiberklasse
|
|
Wiederholungsversuche abrufen
|
3
|
Definiert, wie viele Male der Verbindungspool versucht, eine neue Verbindung abzurufen
|
|
Wiederholungsverzögerung erfassen
|
10000
|
Zeit in Millisekunden, die der Verbindungspool zwischen Erfassungsversuchen wartet
|
|
Timeout beim Wiederholen eines Checkouts
|
1000000
|
Anzahl von Millisekunden, die ein Client, der getConnection aufruft, auf das Einchecken oder Erfassen einer Verbindung wartet, wenn der Pool ausgeschöpft ist
|
|
Maximale Leerlaufzeit
|
0
|
Sekunden, die eine Verbindung im Pool, aber nicht verwendet bleiben kann, bevor sie verworfen wird. 0 bedeutet Leerlaufverbindungen laufen nie ab.
|
|
Maximales Verbindungsalter
|
0
|
Verbindungen älter als dieses Alter in Sekunden werden getrennt und aus dem Pool gelöscht. 0 bedeutet, dass kein maximales Alter erzwungen wird.
|
|
Anzahl der Helper-Threads
|
8
|
Langsame JDBC-Operationen werden im Allgemeinen von Helper-Threads durchgeführt, die keine Konfliktsperren aufweisen. Die Verteilung dieser Operationen auf mehrere Threads kann die Leistung deutlich verbessern, da mehrere Operationen gleichzeitig durchgeführt werden können.
|
|
Nicht zurückgegebener Verbindungs-Timeout
|
0
|
Wenn die Anwendung eine Verbindung abruft, sie aber nicht innerhalb des angegebenen Zeitraums schließen kann, löscht der Pool die Verbindung. 0 bedeutet "kein Timeout". Es wird erwartet, dass die Anwendungen ihre eigenen Verbindungen schließen.
|
|
Maximale Leerlaufzeit für Verbindungen über der Mindest-Poolgröße
|
300
|
Anzahl von Sekunden, die Verbindungen über minPoolSize im Leerlauf im Pool bleiben dürfen, bevor sie gelöscht werden. 0 bedeutet Folgendes: "kein Erzwingen", und entsprechende Verbindungen werden nicht gelöscht.
|
7. Migrieren Sie Entitäten und Daten ggf.
8. Überwachen und verwalten Sie Ihre PostgreSQL-Implementierung. Die optimalen Vorgehensweisen für die Erstellung eines erfolgreichen Wartungsplans werden im Handbuch beschrieben.