Modellazione incentrata sui dati in ThingWorx
Scelta degli elementi corretti del modello
PTC consiglia di acquisire familiarità con i concetti di modellazione di ThingWorx per seguire il resto della sezione. Per ulteriori informazioni, fare riferimento a Definizione del modello ThingWorx in Composer. Un modello in ThingWorx è una rappresentazione logica dell'ambiente fisico e delle soluzioni in uso. Questa rappresentazione logica viene realizzata con la creazione di istanze dei modelli di elementi del modello predefiniti, ad esempio oggetto, modello di oggetto, thing shape e data shape. La presente sezione fornisce consigli su come progettare l'aspetto di uno spazio di archiviazione dei dati della soluzione basata sul modello ThingWorx. In ThingWorx sono disponibili diverse opzioni per l'archiviazione dei dati. La comprensione di ciascuna opzione consente di determinare la soluzione migliore per l'archiviazione dei dati.
• Stream
 |
Utilizzare la Sizing Guide come metodo utile per stimare la quantità di elaborazione e di memoria che può essere necessaria a ThingWorx per soddisfare i requisiti.
|
Tipi di base e data shape
I tipi di base di ThingWorx forniscono un livello di astrazione che isola l'ambiente di sviluppo di applicazioni ThingWorx dai tipi di dati specifici di edge, nonché dall'archivio dati. In questo modo le applicazioni ThingWorx sono indipendenti dall'archivio dati ed è possibile cambiare i tipi di base in fase di esecuzione senza dover modificare lo schema del database sottostante.
Una data shape è un insieme denominato di definizioni di campi e metadati correlati, dove ogni campo è un tipo di base. Una data shape corrisponde vagamente al concetto di una tabella di database relazionale in cui i tipi di base assomigliano al tipo di dati di un campo.
Proprietà degli oggetti
Il metodo principale di inserimento dei dati nella piattaforma ThingWorx prevede l'utilizzo delle proprietà degli oggetti, dove un dispositivo connesso è modellato come oggetto all'interno di ThingWorx. Per una descrizione generale, fare riferimento a Proprietà degli oggetti.
Il caso di utilizzo che segue illustra le diverse opzioni di archiviazione dei dati disponibili per memorizzare le proprietà di un oggetto, dove un oggetto trattore dispone di una thing shape motore trattore con le seguenti proprietà: RPM max, Temperatura motore e Data ultimo cambio olio.
Le proprietà presentano tre opzioni di archiviazione dei dati: di sola lettura, persistente e registrato. In base all'esempio precedente si consigliano le impostazioni seguenti:
• RPM max - Utilizzare l'opzione di sola lettura poiché si tratta di un valore statico che non deve essere modificato in fase di esecuzione. Tuttavia, se il motore viene aggiornato, questo valore può essere modificato cambiando il valore di default.
• Data ultimo cambio olio - Utilizzare l'opzione persistente poiché questa proprietà può essere modificata in fase di esecuzione e si è interessati solo alla data più recente. L'utilizzo dell'opzione persistente rimarrà attivo anche dopo un riavvio del server ThingWorx.
• Temperatura motore - Utilizzare l'opzione registrato poiché si tratta di un valore che cambia in modo continuo. Si tratta essenzialmente di dati di serie temporali.
Stream
Uno stream è destinato a memorizzare un blob di dati di serie temporali. Ogni voce dello stream ha un campo per data e ora, origine, tipo di origine, valori campo, tag dati e posizione. L'elenco dei campi è definito in una data shape ed è associato allo stream. I valori di campo di questo elenco di campi vengono memorizzati in una singola colonna come blob JSON o di testo nello stream. Di conseguenza, quando si esegue un'interrogazione su un singolo valore di campo, vengono restituite la riga o le righe che contengono i valori di campo corrispondenti. In altre parole, il recupero dei dati è più veloce quando con un'interrogazione viene richiesto agli stream di restituire i valori di campo per una data origine per un breve periodo di tempo. L'esecuzione di un'interrogazione con un criterio condizionale per un valore di campo specifico comporta la necessità di filtrare i dati dei valori di campo a livello di applicazione.
Di seguito alcune best practice.
• Da utilizzare per dati di serie temporali arbitrari che non sono direttamente associati a un oggetto nel modello ThingWorx (rispetto agli stream di valori)
• Da utilizzare quando non è necessario interrogare i dati memorizzati con molti filtri basati sui valori di campo
• Da utilizzare quando le interrogazioni sono vincolate a periodi di tempo ridotti
• Evitare di eseguire l'interrogazione tra più origini per lunghi intervalli di tempo
Stream di valori
Uno stream di valori ha la funzione di memorizzare singole proprietà di un oggetto come dati di serie temporali. Una proprietà in un oggetto deve essere definita come registrata per essere considerata come dati di serie temporali e deve utilizzare uno stream di valori per l'archiviazione dei dati. Ogni voce dello stream di valori presenta un valore per data e ora, origine, tipo di proprietà, nome di proprietà e proprietà. Ciò è in contrasto con il modello di archiviazione degli stream perché, anziché memorizzare l'intero insieme di valori di campo in una colonna di valori di campo di una singola riga come blob JSON o di testo, gli stream di valori memorizzano ogni valore di proprietà in una riga separata con origine e data e ora associate. Quando si interrogano i dati delle proprietà di un oggetto in uno stream di valori, i valori vengono restituiti solo per tale proprietà.
Gli stream di valori sono utili per i modelli basati su oggetti. È consigliabile dividere gli oggetti tra diversi stream di valori per migliorare le prestazioni dell'indice. Sebbene non sia strettamente una best practice, in alcuni scenari di inserimento dati con volumi elevati (superiori alle velocità di inserimento riportate nella guida al dimensionamento) è inoltre possibile valutare la possibilità di creare più provider di persistenza puntati a istanze separate del database. Ciò garantisce che i dati vengano inseriti in tabelle diverse del database. Se vengono aggiunti più database, i provider di persistenza possono essere puntati a database specifici. Questo scenario richiede inoltre la migrazione dei dati.
Se si utilizza un sistema RDMS (PostgreSQL, MSSQL o H2), tutti i record vengono scritti nella stessa tabella del database, anche se provenienti da stream di valori diversi per oggetti diversi.
Se si utilizza PostgreSQL, nella tabella per ValueStream del database PostgreSQL, ogni riga contiene il record di una proprietà. Ciò significa che lo stream di valori tiene traccia della modifica del valore di ogni proprietà in modo indipendente e, dopo avere utilizzato il servizio QueryPropertyHistory, verificherà il flusso di dati di ciascuna proprietà nell'oggetto e raccoglierà tutti gli aggiornamenti più recenti (ciascuno con una data e ora di aggiornamento diverse) in un unico risultato nella infotable.
Tabelle dati
Una tabella dati è un'entità ThingWorx. Si tratta essenzialmente di un'astrazione di una tabella di database relazionale standard che è possibile utilizzare per semplificare e accelerare lo sviluppo di applicazioni ThingWorx. È tuttavia opportuno notare che l'implementazione di back-end di una tabella dati non è equivalente a una tabella di database relazionale e non avrà la massima flessibilità di una tabella di database relazionale. Le tabelle dati come entità superiore di ThingWorx consentono di elaborare in modo molto più semplice la funzionalità di accesso ai dati a livello di modello ThingWorx. Una data shape associata alla tabella dati definisce le colonne o i campi della tabella dati e la relativa chiave principale. Non ha tuttavia lo scopo di sostituire una tabella di database relazionale standard in termini di prestazioni e scalabilità.
Per ulteriori informazioni, vedere Best practice delle tabelle dati e Limiti di dimensione delle tabelle dati.