Modélisation orientée données dans ThingWorx
Choix des éléments de modèle appropriés
PTC vous recommande de vous familiariser avec les concepts de modélisation de ThingWorx pour suivre le reste de cette section. Consultez la rubrique
Définition du modèle ThingWorx dans Composer pour plus d'informations. Dans ThingWorx, un modèle est une représentation logique de l'environnement physique et des solutions utilisées. Cette représentation logique est obtenue en créant des instances des modèles d'élément de modèle intégrés, tels qu'un objet, un modèle d'objet, une forme d'objet et une forme de données. Cette section fournit des recommandations sur la conception d'un stockage de données de la solution ThingWorx basée sur des modèles. Dans ThingWorx, vous disposez de plusieurs options pour stocker vos données. Une maîtrise de chaque option vous aidera à déterminer la meilleure solution de stockage pour vos données :
 |
Utilisez le
Guide de dimensionnement (en anglais) pour estimer efficacement les capacités de traitement et la mémoire requises par ThingWorx pour répondre à vos besoins.
|
Que sont les types de base et les formes de données ?
Les types de base ThingWorx fournissent une couche d'abstraction qui isole le développement de l'application ThingWorx des types de données spécifiques de l'Edge, ainsi que du magasin de données. Cela permet aux applications ThingWorx d'être indépendantes du stockage de données et permet de modifier les types de base lors de l'exécution sans avoir à modifier le schéma de base de données sous-jacent.
Une forme de données est un ensemble nommé de définitions de champ et de métadonnées associées, où chaque champ est un type de base. Une forme de données correspond plus ou moins au concept d'une table de base de données relationnelle dans laquelle les types de base ressemblent au type de données d'un champ.
Propriétés d'objet
Dans ThingWorx Platform, les propriétés d'objet constituent le point d'entrée le plus important pour l'ingestion de données. C'est à ce niveau qu'un appareil connecté est modélisé en tant qu'objet dans ThingWorx. Consultez la rubrique
Propriétés d'objet pour obtenir une description générale.
Le cas d'utilisation suivant illustre les différentes options de stockage de données disponibles pour stocker les propriétés d'un objet. Imaginons que vous disposez d'un objet Tracteur présentant une forme d'objet Moteur de tracteur avec les propriétés suivantes : Tr/min max., Température du moteur et Date de la dernière vidange.
Les propriétés disposent de trois options de stockage de données : Lecture seule, Persistance et Journalisation. Pour l'exemple ci-dessus, la configuration suivante est recommandée :
• Tr/min max. : utilisez l'option de lecture seule, car il s'agit d'une valeur statique qui ne doit pas être modifiée lors de l'exécution. Toutefois, si le moteur est mis à niveau, vous pouvez modifier cette valeur en ajustant la valeur par défaut.
• Date de la dernière vidange : utilisez l'option de persistance, car cette propriété peut être modifiée lors de l'exécution et vous n'avez besoin que de la date la plus récente. Avec cette option, cette information devrait être conservée en cas de redémarrage du serveur ThingWorx.
• Température du moteur : utilisez l'option de journalisation, car il s'agit d'une valeur constamment mise à jour qui est essentiellement une donnée de série temporelle.
Flux
Un flux est destiné à stocker un objet BLOB de données de séries temporelles. Chaque entrée de flux possède un horodatage, une source, un type de source, des valeurs de champ, des tags de données et un champ d'emplacement. La liste des champs est définie dans une forme de données et associée au flux. Les valeurs de champ de cette liste de champs sont stockées dans une colonne unique sous la forme d'un objet JSON ou d'un objet BLOB textuel dans le flux. Par conséquent, lorsqu'une valeur de champ unique est interrogée, la ou les lignes contenant des valeurs de champ correspondantes sont renvoyées. En d'autres termes, la récupération des données est plus rapide lorsque les flux sont interrogés pour renvoyer les valeurs de champ d'une source donnée pour une courte période. Si vous interrogez un flux, à l'aide d'une expression conditionnelle, de façon à renvoyer une valeur de champ spécifique, vous devrez filtrer les données de valeur de champ au niveau de l'application.
Voici quelques bonnes pratiques :
• A utiliser pour les données de séries temporelles arbitraires qui ne sont pas directement associées à un objet dans le modèle ThingWorx (par rapport aux flux de valeurs)
• A utiliser lorsqu'il n'est pas nécessaire d'interroger les données stockées avec un filtrage approfondi basé sur les valeurs de champ
• A utiliser lorsque les requêtes sont restreintes par des périodes de courte durée
• Evitez d'interroger plusieurs sources pour un long intervalle de temps
Flux de valeurs
Un
flux de valeurs est destiné à stocker les propriétés individuelles d'un objet en tant que données de séries temporelles. Les propriétés d'un objet doivent être définies comme journalisées pour être considérées comme des données de séries temporelles et doivent utiliser un flux de valeurs pour le stockage des données. Chaque entrée de flux de valeurs possède un horodatage, une source, un type de propriété, un nom de propriété et une valeur de propriété. Cette approche contraste avec le modèle de stockage des flux. En effet, au lieu de stocker l'intégralité des valeurs de champ dans une colonne de valeurs de champ d'une seule ligne sous la forme d'un objet JSON/BLOB textuel, les flux de valeurs stockent chaque valeur de propriété sur une ligne distincte avec la source et l'horodatage associés. Lors de l'interrogation des données de propriété d'un objet dans un flux de valeurs, les valeurs ne sont renvoyées que pour cette propriété.
Les flux de valeurs sont utiles pour les modèles basés sur des objets. Il est recommandé de diviser les objets entre plusieurs flux de valeurs pour améliorer les performances d'index. Bien qu'il ne s'agisse pas à proprement parler d'une bonne pratique, vous pouvez également envisager de créer plusieurs fournisseurs de persistance qui se connectent à des instances de base de données distinctes pour certains cas d'ingestion de volumes élevés de données (supérieurs aux taux d'ingestion indiqués dans le guide de dimensionnement). Cela permet de s'assurer que les données sont placées dans différentes tables de la base de données. Si vous ajoutez plusieurs bases de données, les fournisseurs de persistance peuvent pointer vers des bases de données spécifiques. Ce scénario nécessite également une migration des données.
Si vous utilisez un système de gestion de base de données relationnelle (PostgreSQL, MSSQL, H2), tous les enregistrements sont écrits dans la même table de la base de données, même s'ils proviennent de flux de valeurs différents pour des objets différents.
Si vous utilisez PostgreSQL, chaque ligne contient l'enregistrement d'une seule propriété dans la table de ValueStream de la base de données PostgreSQL. Cela signifie que le flux de valeurs effectue un suivi du changement de valeur de chaque propriété, de façon indépendante. Après avoir utilisé le service QueryPropertyHistory, il vérifie le flux de données de chaque propriété de l'objet et collecte toutes les mises à jour les plus récentes (chacune avec une heure de mise à jour différente) dans un seul et même résultat de table d'informations.
Tables de données
Une table de données est une entité ThingWorx qui est essentiellement une abstraction d'une table de base de données relationnelle standard que vous pouvez utiliser pour simplifier et accélérer le développement d'applications ThingWorx. Toutefois, il convient de noter que l'implémentation back-end d'une table de données n'est pas équivalente à une table de base de données relationnelle et qu'elle ne dispose pas de la flexibilité complète d'une table de base de données relationnelle. En tant qu'entités ThingWorx de première classe, les tables de données facilitent le traitement de la fonctionnalité d'accès aux données au niveau du modèle ThingWorx. Une forme de données qui serait associée à la table de données définit les colonnes ou les champs de la table de données et sa clé primaire. Toutefois, elle n'est pas censée remplacer une table de base de données relationnelle standard en termes de performances et d'évolutivité.