Almacenamiento de datos en ThingWorx
ThingWorx proporciona entidades y métodos para almacenar datos. Los datos se pueden almacenar en tablas de datos, propiedades de cosa, flujos, flujos de valor y tablas de configuración.
Al desarrollar la solución, se debe tener en cuenta cómo ThingWorx gestiona el almacenamiento de datos. La elección del almacenamiento de datos correcto es muy importante, ya que afecta al resultado del proyecto, a su escalabilidad y fiabilidad, y a la experiencia del usuario.
En la siguiente sección se describen las opciones de almacenamiento del modelo de ThingWorx:
Tabla de datos
◦ Se utiliza para menos de 100.000 filas de datos.
◦ Se utiliza para conjuntos de datos estáticos y tablas de búsqueda estáticas. Para conjuntos de datos altamente dinámicos y de tamaño grande, utilice una base de datos relacional conectada a través de una plantilla de cosa de Database.
 |
Utilice una base de datos relacional para las uniones y consultas complejas.
|
◦ Se utiliza para consultas y almacenamiento basados en claves, así como para permitir de forma fácil las actualizaciones y eliminaciones basadas en la clave principal.
Por ejemplo: se puede almacenar información sobre el inventario de una máquina expendedora inteligente conectada, donde cada posición del inventario sea una clave principal. También se pueden utilizar tablas de datos con el fin de almacenar información acerca de los programas de riego disponibles para un dispositivo de gestión de cultivos, donde cada programa de riego sea una fila con una clave principal.
◦ Para manipular o consultar los datos fila a fila, utilice tablas de datos.
◦ Utilice índices al trabajar con tablas de datos.
Propiedad de cosa
Utilice las propiedades de cosa para almacenar datos sobre una cosa en ThingWorx. Las propiedades tienen las siguientes opciones de almacenamiento de datos:
◦ Solo lectura: la opción de solo lectura se utiliza para valores estáticos que no deben cambiarse en tiempo de ejecución. Sin embargo, si se desea, se puede cambiar el valor por defecto.
◦ Persistente: la opción persistente se utiliza si se desea que el valor de la propiedad se guarde incluso después de un reinicio del servidor ThingWorx y si el valor de la propiedad se puede cambiar en tiempo de ejecución.
◦ Registrada: la opción registrada se utiliza para las propiedades cuyos valores se actualizan continuamente. Se trata de datos de serie temporal que se pueden almacenar en flujos de valor.
|
|
No se deben utilizar propiedades explícitas para almacenar datos históricos. En su lugar, se utilizan flujos o flujos de valor.
|
Flujo
Se utiliza para registrar los eventos de proceso gobernados por el tiempo o las actividades de los dispositivos.
Por ejemplo, se puede crear un flujo para registrar las incidencias sobre las actividades del dispositivo o para registrar cuándo el dispositivo se desconecta de ThingWorx Platform y se vuelve a conectar. Los flujos están optimizados para la escritura de alta velocidad y tienen un sistema de caché configurable.
Flujo de valor
Se utiliza para almacenar datos de serie temporal que se obtienen de las propiedades de una cosa.
Con los flujos, se crean tablas de datos. Cuando se utilizan flujos de valor, se elimina la creación de tablas de datos rellenas de forma dispersa.
El acceso centrado en cosa de los datos de un flujo de valor proporciona soporte integrado para varios clientes.
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 sola propiedad. Esto significa que el flujo de valor efectúa un seguimiento del cambio de valor de cada propiedad de forma independiente. Después de utilizar el servicio QueryPropertyHistory, verifica cada propiedad del flujo de datos de la cosa y recopila todas las actualizaciones más recientes (cada una tiene un tiempo de actualización diferente) en un resultado de infotable.
En la siguiente tabla, se proporciona información sobre las diferencias clave entre los flujos y los flujos de valor. Utilice esta información para decidir el tipo de entidad que se utilizará para almacenar los datos de serie temporal en la solución:
|
Flujos
|
Flujos de valor
|
|---|---|
|
Los flujos pueden almacenar cualquier tipo de datos de serie temporal.
|
Los flujos de valor pueden almacenar datos de serie temporal de la propiedad de una cosa.
Los flujos de valor están enlazados a las propiedades de una cosa.
|
|
Los datos de flujos se pueden consultar directamente, utilizando sus propios servicios. El resultado de la consulta es toda la fila de datos.
|
Los datos de flujos de valor no se pueden consultar directamente. En su lugar, se utilizan los servicios definidos en la cosa para consultar datos del flujo de valor. Por ejemplo:QueryPropertyHistory
|
|
Para añadir una fila de datos a un flujo, utilice el servicio WritePropertiesToStream.
|
Para añadir datos a un flujo de valor, seleccione la casilla Registrado para una propiedad.
|
|
Los flujos pueden almacenar datos contextuales. Por ejemplo, cuando se active un evento específico, se pueden añadir los valores de las demás propiedades. Esto ayuda en el análisis de datos.
|
Los flujos de valor no pueden almacenar datos contextuales.
|
¿Cuándo se deben utilizar flujos o flujos de valor?
◦ Utilice flujos de valor y flujos para almacenar y recuperar datos de serie temporal. En función de la cantidad de datos que se necesite almacenar, elija la opción de almacenamiento de datos correcta.
◦ Utilice flujos cuando desee consultar datos solo dentro de períodos de tiempo pequeños.
◦ Divida las cosas entre varios flujos de valor para mejorar el rendimiento del índice.
Tabla de configuración
Se utiliza para crear soluciones personalizables que se puedan actualizar con seguridad en ThingWorx Platform.
Se puede añadir una tabla de configuración en una entidad de mashup basada en una definición de datos predefinida. Esto simplifica el proceso de creación de mashups de extensión que se pueden personalizar, a la vez que también soporta actualizaciones locales, puesto que los valores de la tabla de configuración se transfieren durante las actualizaciones de extensiones.
Recuperación de una interrupción de la base de datos para proveedores de datos
En el caso de que se produzca un reinicio o una interrupción de la base de datos, si los datos ingeridos no se almacenan correctamente en los proveedores de datos, se puede configurar el sistema para que se vuelvan a intentar las operaciones y así evitar la pérdida de datos. Para ello, se deben definir las siguientes propiedades configurables para el proveedor de persistencia necesario en platform-settings.json:
• acquireRetryAttempts: permite definir cuántas veces ThingWorx intentará adquirir una nueva conexión de la base de datos antes de abandonar.
• acquireRetryDelay: el tiempo (en milisegundos) que ThingWorx esperará entre los intentos de adquisición.
Según corresponda, ThingWorx se volverá a intentar hasta acquireRetryAttempts veces, con un retraso de acquireRetryDelay entre cada intento, según las opciones configuradas. (Por ejemplo, si ThingWorx debe esperar 5 segundos para que la base de datos vuelva a estar en línea, defina acquireRetryAttempts= 5 y acquireRetryDelay= 1000).
Si fallan todos los intentos de reintento, se registrará el siguiente mensaje de error en Registro de aplicación, que indica que las entradas no se han podido guardar: Failed to connect to persistence provider after retrying 5 times in 10 seconds.
|
|
No se recomienda definir acquireRetryAttempts en un valor menor o igual que cero, ya que la aplicación reintentará indefinidamente almacenar las entradas y puede hacer que la plataforma se bloquee en caso de una interrupción prolongada de la base de datos.
|
Al utilizar InfluxDB como proveedor de persistencia opcional, se debe configurar DatabaseWriteRetryAttempts para reintentar las operaciones de la base de datos con el número de veces configurado.
|
|
Para cambiar con frecuencia las propiedades persistentes y registradas, se producirá una inevitable pérdida de datos debido al procesamiento basado en lotes. En estos escenarios, se registrarán los siguientes mensajes en Registros de aplicación:
Para la propiedad persistente: BatchUpdateException error occurred executing batch update of persistent properties.
Para propiedades registradas o ingesta de ValueStream: Error executing batch.
|
|
|
Los tamaños de cola se deben configurar correctamente para contener los datos según la velocidad de ingesta.
|
Para obtener más información acerca del rendimiento, consulte Informe de rendimiento.
Prácticas recomendadas para la gestión del modelado centrado en datos
Utilice las siguientes prácticas recomendadas generales para gestionar el modelado centrado en datos en ThingWorx:
• Si hay datos que no cambiarán o que se sobrescribirán la próxima vez que se cambien/carguen y están asociados a una cosa, cree una propiedad infotable para esa cosa y asígnele la definición de datos adecuada. De esta manera, se puede acceder a los datos a través de la cosa. También se pueden utilizar tablas de configuración o, para cantidades mayores de datos, utilizar una tabla de datos.
• Utilice el almacenamiento en caché de datos tanto como sea posible.
Por ejemplo, en lugar de consultar la base de datos en cada evento DataChange, implemente una caché como infotable que se renueve a intervalos definidos.
• Archive los datos que ya no se necesiten.
Al diseñar la solución, se debe decidir qué datos se utilizan con frecuencia. Estos datos se pueden almacenar en la base de datos de la solución. Mueva los datos antiguos lo antes posible a un servidor externo, como una instancia federada de ThingWorx o un servidor de base de datos.
• Proporcione parámetros de fecha de inicio y de fin a los métodos de consulta para limitar la cantidad de datos que la consulta vaya a recuperar. De esta manera, se reduce el tiempo de procesamiento y se mejora el rendimiento.
• Para los escenarios de gran volumen de ingesta de datos (sobre y por encima de los índices de ingesta que se describen en el manual ThingWorx Platform Sizing Guide), considere la posibilidad de crear varios proveedores de persistencia que se conecten a instancias de base de datos independientes. De este modo, se garantiza que los datos se van a incluir en tablas diferentes de la base de datos. Si se añaden varias bases de datos, los proveedores de persistencia pueden apuntar a bases de datos específicas. En este caso, se necesita la migración de datos.
• Asegúrese de que las tablas de datos tengan menos de 100.000 filas.
• La consulta de datos de tablas de datos y flujos solo debería tardar unos pocos segundos. Si estas tablas de datos y flujos tienen más de 100.000 filas, las consultas tendrán un rendimiento lento.
• Asegúrese de planificar cómo se van a depurar los datos antiguos. La depuración de datos es importante, ya que ayuda a mejorar el rendimiento de una solución.