Almacenamiento de datos en ThingWorx
ThingWorx proporciona entidades y métodos para almacenar datos. Se pueden almacenar datos en tablas de datos, propiedades de cosa, flujos, flujos de valor y tablas de configuración.
Al desarrollar la aplicació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.
|
|
Las tablas de datos no soportan la escritura de alta velocidad, ya que no tienen mecanismo de puesta en cola, como flujos y flujos de valor.
|
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 la plataforma de ThingWorx 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 aplicació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.
|
|
Se pueden consultar los datos de flujos directamente, utilizando sus propios servicios. El resultado de la consulta es toda la fila de datos.
|
No se pueden consultar datos de flujos de valor 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 aplicaciones personalizables que se puedan actualizar con seguridad en la plataforma de ThingWorx.
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.
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 de 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 aplicación, se debe decidir qué datos se utilizan con frecuencia. Estos datos se pueden almacenar en la base de datos de la aplicació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 aplicación.