PTC recomienda familiarizarse con los conceptos de modelado de ThingWorx para seguir el resto de esta sección. Para obtener más información, consulte Definición del modelo de ThingWorx en Composer. Un modelo de ThingWorx es una representación lógica del entorno físico y de la solución. Esta representación lógica se realiza al crear instancias de las plantillas de elementos de modelo integrados, como una cosa, una plantilla de cosa, una definición de cosa y una definición de datos. En esta sección se proporcionan recomendaciones sobre cómo diseñar el aspecto de almacenamiento de datos de la solución basada en modelos de ThingWorx. En ThingWorx, existen varias opciones para almacenar los datos. Entender todas las opciones ayuda a determinar la mejor solución de almacenamiento para los datos:

Con los tipos base de ThingWorx se proporciona una capa de abstracción que permite aislar el entorno de desarrollo de aplicaciones de ThingWorx de los tipos de datos específicos del servidor Edge y del almacén de datos. De este modo, las aplicaciones de ThingWorx pueden ser independientes del almacén de datos y cambiar los tipos base en tiempo de ejecución sin tener que cambiar el esquema de bases de datos subyacente.

Una definición de datos es un conjunto de definiciones de campo con nombre y metadatos relacionados, en el que cada campo es un tipo base. Una definición de datos coincide con el concepto de tabla de base de datos relacional donde los tipos base son similares al tipo de datos de un campo.

El punto de entrada más destacado de la ingesta de datos en ThingWorx Platform es a través de las propiedades de cosa, donde un dispositivo conectado se modela como una cosa dentro de ThingWorx. Consulte Propiedades de cosa para obtener una descripción general.

En el siguiente caso de uso se muestran las distintas opciones de almacenamiento de datos disponibles para almacenar las propiedades de cosa. Donde una cosa de tractor tendría una definición de cosa de motor del tractor con las siguientes propiedades: RPM máx., Temperatura del motor y Fecha del último cambio de aceite.

Las propiedades tienen tres opciones de almacenamiento de datos: solo lectura, persistente y registrada. Dado el ejemplo anterior, se recomienda lo siguiente:

Un flujo está diseñado para almacenar un blob de datos de serie temporal. Cada entrada de flujo tiene fecha y hora, un origen, un tipo de origen, valores de campo, etiquetas de datos y un campo de ubicación. La lista de campos se define en una definición de datos y está asociada al flujo. Los valores de campo de esta lista de campos se almacenan en una sola columna como fichero JSON o blob de texto en el flujo. Como resultado, cuando se consulta un solo valor de campo, se devuelven todas las filas que incluyen valores de campo coincidentes. Es decir, la recuperación de datos es más rápida cuando los flujos se consultan para que devuelvan los valores de campo de un origen determinado durante un breve período de tiempo. Si se realiza una consulta con una condición para un valor de campo específico, se tendrán que filtrar los datos del valor del campo en el nivel de la aplicación.

Entre las prácticas recomendadas incluyen las siguientes:

Un flujo de valor está diseñado para almacenar propiedades individuales de una cosa como datos de la serie temporal. Una propiedad de una cosa se debe definir como registrada para que se considere datos de serie temporal y debe utilizar un flujo de valor para el almacenamiento de datos. Cada entrada de flujo de valor tiene fecha y hora, un origen, un tipo de propiedad, un nombre de propiedad y un valor de propiedad. Esto contrasta con el modelo de almacenamiento de los flujos porque, a diferencia de almacenar todo el conjunto de valores de campo en una columna de valores de campo de una sola fila como fichero JSON o blob de texto, los flujos de valor almacenan cada valor de propiedad en una fila independiente con el origen y la fecha y hora asociados. Al consultar los datos de una propiedad de cosa en un flujo de valor, solo se devuelven valores para esa propiedad.

Los flujos de valor son beneficiosos para los modelos gobernados por una cosa. Es una práctica recomendada dividir las cosas entre varios flujos de valor para mejorar el rendimiento del índice. Aunque no es estrictamente una práctica recomendada, determinados escenarios de ingesta de datos de gran volumen (por encima de las tasas de ingesta que se indican en el documento Sizing Guide) también pueden considerar la creación de varios proveedores de persistencia que señalan a instancias de bases de datos independientes. De este modo, se garantiza que los datos se van a incluir en diferentes tablas de la base de datos. Si se añaden varias bases de datos, los proveedores de persistencia pueden señalar a bases de datos específicas. En este escenario también se requeriría la migración de datos.

Si se utiliza RDMS (PostgreSQL, MSSQL, H2), todos los registros, incluso de flujos de valor diferentes para cosas diferentes, se escriben en la misma tabla de la base de datos.

Si se utiliza PostgreSQL, en la tabla de ValueStream de la base de datos PostgreSQL, en cada fila se incluye el registro para una propiedad. Esto significa que el flujo de valor realiza un seguimiento del cambio de valor de cada propiedad de manera independiente. Después de utilizar el servicio de QueryPropertyHistory, se verificará el flujo de datos de cada propiedad de la cosa y se recopilarán todas las actualizaciones más recientes (cada una de ellas tiene un tiempo de actualización diferente) en un resultado de infotable.

Una tabla de datos es una entidad de ThingWorx que consiste esencialmente en una abstracción de una tabla de base de datos relacional estándar que se puede utilizar para simplificar y acelerar el desarrollo de aplicaciones de ThingWorx. Sin embargo, se debe tener en cuenta que la implementación de back-end de una tabla de datos no es equivalente a una tabla de base de datos relacional y no tendrá la flexibilidad completa de esta. Las tablas de datos, como entidad de primera clase de ThingWorx, permiten procesar la funcionalidad de acceso a datos en el nivel del modelo de ThingWorx con mayor facilidad. Una definición de datos que se asociaría a la tabla de datos permite definir las columnas o los campos de la tabla de datos y su clave principal. Sin embargo, no está concebida para reemplazar una tabla de base de datos relacional estándar desde el punto de vista del rendimiento y la escalabilidad.

Consulte Prácticas recomendadas para tablas de datos y Límites de tamaño de tablas de datos para obtener más información.