Elaborazione dati
Tra l'inserimento e la visualizzazione, ThingWorx Platform necessita anche di risorse di sistema sufficienti per eseguire le attività dell'applicazione riguardanti la logica aziendale e la trasformazione dei dati.
In questa sezione vengono illustrati i concetti relativi alle aree più significative che possono influire sui requisiti di elaborazione dei dati. L'elaborazione dei dati dipende in larga misura dai casi di utilizzo aziendali specifici, pertanto rende meno utile qualsiasi calcolo standardizzato.
Una volta eseguite le stime di inserimento e visualizzazione, un passo importante da eseguire prima della produzione è costituito dal test di stress del carico dell'applicazione che può indurre a scegliere un sistema di dimensioni diverse da quelle della baseline, se l'applicazione richiede più risorse per l'elaborazione di eventi/avvisi o logica aziendale complessa.
Sottoscrizioni ed eventi
Le sottoscrizioni a timer ed eventi di modifica delle proprietà spesso costituiscono la maggior parte della logica aziendale in un'applicazione ThingWorx. Queste sottoscrizioni utilizzano la memoria dei sottosistemi Elaborazione eventi, che sono sistemi non utilizzati durante l'inserimento e la connettività del dispositivo.
Una volta che il sistema è dimensionato per la connettività dei dispositivi e l'inserimento stabili, è importante eseguire il test di carico con la logica aziendale per assicurarsi che il sistema sia dimensionato in modo appropriato per supportare la produzione.
Trasferimento e gestione dei file
Il trasferimento di file da e verso i dispositivi edge è un requisito comune dei casi di utilizzo delle applicazioni ThingWorx.
• Distribuzione degli aggiornamenti software
• Risoluzione dei problemi o accesso ai file di log
• Ricezione di immagini, PDF o altri file per la verifica di funzionalità e prestazioni
Se si prevede di trasferire file di grandi dimensioni o un numero elevato di file simultaneamente, potrebbe essere necessaria memoria aggiuntiva della piattaforma per gestire il carico.
Requisiti della disponibilità elevata per ThingWorx
Quando la distribuzione avviene in una configurazione a disponibilità elevata (come descritto nella sezione Panoramica del clustering a disponibilità elevata di ThingWorx), viene spesso utilizzata una configurazione del database relazionale a disponibilità elevata.
Se da un lato questa configurazione riesce a impedire periodi di inattività dovuti a errori di sistema, può d'altro canto causare una lieve riduzione delle prestazioni di scrittura.
Per risolvere questo problema, se il WPS previsto dal calcolo dell'inserimento dei dati è prossimo alla soglia per la configurazione desiderata, prendere in considerazione la configurazione di sistema di dimensioni immediatamente maggiori.
Tunnel e strumenti di terze parti
Molti casi di utilizzo aziendale sfruttano le sessioni di tunneling ai dispositivi edge, che richiedono connessioni WebSocket da mantenere per tutta la durata della sessione.
Analogamente, anche gli strumenti di terze parti (ad esempio SCADA, ERP o altre applicazioni integrate di back-office) possono utilizzare le connessioni WebSocket alla piattaforma.
Se tali strumenti accedono ThingWorx utilizzando le chiamate API REST, aumenta il numero di richieste HTTP al secondo calcolato in precedenza per la visualizzazione dei dati.
Ogni connessione WebSocket richiede memoria sulla piattaforma, pertanto è consigliabile aumentare l'allocazione della memoria totale alla piattaforma (o la dimensione/classe della macchina virtuale selezionata), se sono previste molte richieste API REST o sessioni di tunneling simultanee.
Conservazione, aggregazione e archiviazione dei dati
I dati cronologici sono spesso necessari sia per l'elaborazione dei dati (quanto indietro nel tempo deve risalire la logica aziendale?) sia per la visualizzazione dei dati (quanto indietro nel tempo devono risalire gli utenti?).
La quantità di dati cronologici da archiviare sulla piattaforma interferisce sul dimensionamento sia del sistema di database che della piattaforma. Le origini dati più grandi (stream, tabelle dati e stream di valori) richiedono transazioni più lunghe per eseguire un'interrogazione dal database. Le transazioni lunghe possono inoltre comportare il backup delle code stream e stream di valori e l'uso di memoria aggiuntiva.
È consigliabile aggregare i dati in modo che nessuna origine dati contenga troppe voci (consultare questa guida alle best practice per i dettagli). Se è richiesta una grande quantità di dati cronologici o è necessario conservare grandi quantità di dati inseriti per un periodo di tempo prolungato, considerare una soluzione di database più affidabile. Vedere i dettagli sulle opzioni del database di seguito.
• H2 - Un piccolo database in memoria perfetto per lo sviluppo e i sistemi più piccoli ma che non supporta le implementazioni più grandi.
 |
H2 non è consigliato per i sistemi di produzione ThingWorx.
|
• Microsoft SQL Server - Un database relazionale solido e maturo che può essere utilizzato per gestire modelli di dati, stream e stream di valori ThingWorx nei sistemi di sviluppo o di produzione. Può essere scalato per tutte le implementazioni di piccole, medie e grandi dimensioni.
• PostgreSQL - Simile a SQL Server, PostgreSQL è un database relazionale che può essere utilizzato in ambienti di produzione di tutte le dimensioni. La scelta tra SQL Server e PostgreSQL è spesso dettata dall'esperienza IT, sia con i database che con i sistemi operativi.
• InfluxDB - Un database di serie temporali perfetto per l'inserimento su vasta scala di stream e stream di valori ThingWorx nei sistemi di sviluppo e di produzione, accanto a un database relazionale (Microsoft SQL Server o PostgreSQL) che gestisce il modello di dati ThingWorx.
|
|
ThingWorx può essere utilizzato con la versione a server singolo open-source di InfluxDB o con un cluster InfluxDB Enterprise per prestazioni e disponibilità elevate. La versione open-source è stata utilizzata per i test in questa guida.
|