Procesamiento de datos
Entre la ingesta y la visualización, ThingWorx Platform también necesita suficientes recursos del sistema para ejecutar cualquier necesidad de la aplicación de lógica empresarial y transformación de datos.
En esta sección se explicarán los conceptos para las áreas más significativas que pueden afectar a los requisitos de procesamiento de datos. El procesamiento de datos depende mucho de los casos de uso específicos del negocio, por lo que el cálculo estandarizado es menos útil.
Una vez realizados los cálculos de ingesta y visualización, la carga de la aplicación o la prueba de estrés será un paso importante antes de pasar a producción, y podría llevarle a seleccionar un sistema de tamaño diferente al de la instantánea si la aplicación requiere más recursos para el procesamiento de eventos/alertas o lógica empresarial compleja.
Suscripciones y eventos
Las suscripciones a temporizadores y a eventos de cambio de propiedades suelen constituir la mayoría de la lógica empresarial de una aplicación ThingWorx. Estas suscripciones utilizan memoria de los subsistemas de procesamiento de eventos, que son sistemas que no se utilizan durante la recopilación y la conectividad de los dispositivos.
Una vez que se haya ajustado el tamaño del sistema para una conectividad estable de ingesta y dispositivos, la prueba de carga con lógica empresarial en contexto es un paso importante para asegurarse de que el tamaño del sistema es compatible con el uso en producción.
Administración y transferencia de ficheros
La transferencia de ficheros a dispositivos periféricos y desde ellos es un requisito común de los casos de uso de la aplicación ThingWorx:
• Implementación de actualizaciones de software
• Resolución de problemas o acceso a los ficheros de registro
• Recepción de imágenes, ficheros PDF u otros ficheros para verificar la funcionalidad y el rendimiento
Si se esperan muchas transferencias de ficheros simultáneas o la transferencia de ficheros de gran tamaño, es posible que sea necesaria más memoria de la plataforma para gestionar esta carga.
Requisitos de alta disponibilidad para ThingWorx
Cuando se implementa en una configuración de alta disponibilidad (como se describe en la sección Alta disponibilidad de ThingWorx), a menudo se utiliza una configuración de base de datos relacional de alta disponibilidad.
Aunque esta configuración puede evitar el tiempo de inactividad debido a un error del sistema, también puede provocar una ligera reducción del rendimiento de la escritura.
Para solucionarlo, si el valor de WPS esperado del cálculo de la ingesta de datos se aproxima al umbral de la configuración deseada, considere la posibilidad de usar la configuración del sistema del siguiente tamaño.
Túneles y herramientas de terceros
En muchos casos de uso empresarial, se aprovechan las sesiones de tunelización de los dispositivos periféricos, que requieren que se abran y conserven conexiones WebSocket en todas las sesiones.
Del mismo modo, las herramientas de terceros (como SCADA, ERP u otras aplicaciones integradas de oficina administrativa) pueden utilizar también conexiones WebSocket para la plataforma.
Si estas herramientas acceden a ThingWorx mediante llamadas de API de REST, aumentará el número de solicitudes HTTP por segundo calculadas anteriormente para la visualización de datos.
Cada conexión WebSocket requiere memoria en la plataforma, por lo que se debe considerar la posibilidad de aumentar la asignación de memoria total para la plataforma (o el tamaño o la clase de VM que se selecciona), si se esperan muchas sesiones de tunelización simultáneas o solicitudes de API de REST.
Retención, adición y archivo de datos
A menudo, se necesitan datos históricos para el procesamiento de datos (¿cuánto tiempo atrás debe buscar la lógica empresarial?) y para la visualización de datos (¿cuánto tiempo atrás deben buscar los usuarios?).
La cantidad de datos históricos que se almacenarán en la plataforma afectará al tamaño del sistema de plataforma y base de datos. Los orígenes de datos más grandes (flujos, tablas de datos y flujos de valor) requerirán transacciones más largas al consultar desde la base de datos. Estas transacciones largas también pueden provocar que las colas de flujo y de flujo de valor realicen una copia de seguridad y utilicen memoria adicional.
Se recomienda la adición de datos de modo que ningún origen de datos contenga demasiadas entradas (consulte el manual Best Practice Guide para obtener más información). Si se necesita una gran cantidad de datos históricos o se deben mantener grandes volúmenes de datos ingeridos durante un período de tiempo prolongado, considere una solución de base de datos más sólida. Consulte los detalles de las opciones de base de datos a continuación:
• H2: base de datos pequeña y en memoria, idónea para el desarrollo y sistemas pequeños. No se escala bien más allá de implementaciones pequeñas.
 |
No se recomienda H2 para sistemas ThingWorx de producción.
|
• Microsoft SQL Server: una base de datos relacional sólida y madura que se puede utilizar para gestionar modelos de datos, flujos y flujos de valor de ThingWorx en sistemas de desarrollo o de producción. Se puede escalar para todas las implementaciones, ya sean pequeñas, medianas o grandes.
• PostgreSQL: similar a SQL Server, PostgreSQL es una base de datos relacional que se puede utilizar en entornos de producción de todos los tamaños. La elección entre SQL Server y PostgreSQL se suele tomar por la experiencia de TI existente, ya sea con bases de datos o sistemas operativos.
• InfluxDB: base de datos de serie temporal idónea para la ingesta a gran escala de flujos de ThingWorx y flujos de valor en sistemas de desarrollo y producción, junto con una base de datos relacional (Microsoft SQL Server o PostgreSQL) que gestiona el modelo de datos de ThingWorx.
|
|
ThingWorx se puede utilizar con la versión de código abierto de servidor único de InfluxDB o con un clúster de InfluxDB Enterprise para obtener una alta disponibilidad y un mayor rendimiento. En este manual, se utiliza la versión de código abierto para las pruebas.
|