数据处理
在提取和可视化之间，ThingWorx Platform 还需要足以执行应用程序的任何业务逻辑和数据转换需求的系统资源。
本节将介绍可能影响数据处理需求的更重要领域的概念。数据处理与特定的业务用例息息相关，这使得标准化计算不太有用。
在完成提取和可视化预估后，必须在投入生产前执行应用程序负载或应力测试，如果您的应用程序需要将更多资源用于复杂的业务逻辑或事件/警报处理，则可能导致您选择大小与基线不同的系统。
订阅和事件
通常，计时器和属性更改事件订阅构成了 ThingWorx 应用程序中的大多数业务逻辑。这些订阅使用事件处理子系统中的内存，其中事件处理子系统是指在数据提取和设备连接期间未使用的系统。
针对稳定提取和设备连接设定系统大小后，需要使用业务逻辑执行负载测试，才能确保系统大小设定可以支持生产使用。
文件传输和管理
对于 ThingWorx 应用程序用例，通常要求与 Edge 设备进行文件传输：
• 部署软件更新
• 故障排除或访问日志文件
• 接收图像、PDF 或其他文件以检查功能和性能
如果预期要同时传输许多文件和/或传输大型文件，则可能需要额外的平台内存才能处理此负载。
ThingWorx 高可用性要求
在高可用性配置 (如 ThingWorx 高可用性一节所述) 中部署时，通常使用高可用性关系数据库配置。
此配置可预防系统故障导致的停机，但也可能稍稍降低写入性能。
当数据提取计算中的预期 WPS 接近所需配置的阈值时，要解决此情况，请考虑下一个大小的系统配置。
隧道和第三方工具
许多业务用例利用与 Edge 设备的隧道会话，这需要在整个会话中打开和维护 WebSocket 连接。
同样，第三方工具 (如 SCADA、ERP 或其他集成的后勤应用程序) 也可以利用与平台的 WebSocket 连接。
如果这些工具正在使用 REST API 调用访问 ThingWorx，则会增加之前为数据可视化计算的每秒 HTTP 请求数。
每个 WebSocket 连接都需要平台的内存，因此，如果预期使用多个并发隧道会话或 REST API 请求，请考虑增加分配给平台的总内存 (或当前选择的 VM 大小/类)。
数据保留、聚合和存档
历史数据通常需要进行数据处理 (业务逻辑需要查看过去哪个时间段内的数据？) 和数据可视化 (用户需要查看过去哪个时间段内的数据？)。
欲存储在平台上的历史数据量会影响数据库和平台系统大小设定。较大的数据源 (流、数据表和值流) 需要较长的事务才能从数据库中进行查询。这些长期事务也可能导致流和值流队列备份并使用额外内存。
强烈建议聚合数据，这样所有数据源都不会包含过多的条目 (有关详细信息，请参阅此最佳做法指南)。如果需要大量的历史数据，或者必须长期保留大量的提取数据，则考虑采用更可靠的数据库解决方案。有关数据库选项的详细信息，请参阅：
• H2 - 小内存数据库，非常适合开发系统和较小的系统；对于非小型实现，扩展性不佳。
 |
对于 ThingWorx 生产系统，建议不要使用 H2。
|
• Microsoft SQL Server - 可靠的成熟关系数据库，可用于在开发或生产系统中管理 ThingWorx 数据模型、流和值流。可针对所有小、中和大型实现进行扩展。
• PostgreSQL - 与 SQL Server 类似，PostgreSQL 也是关系数据库，适用于所有规模的生产环境。通常根据数据库或操作系统的现有 IT 体验决定是选择 SQL Server 还是 PostgreSQL。
• InfluxDB - 时间序列数据库，非常适合在开发和生产系统中大规模提取 ThingWorx 流和值流；也是关系数据库 (Microsoft SQL Server 或 PostgreSQL)，用于管理 ThingWorx 数据模型。
|
|
ThingWorx 可与开源、单一服务器版本的 InfluxDB 一起使用，或与 InfluxDB Enterprise 群集搭配使用，来实现高可用性和提高性能。在本指南中，开源版本用于测试。
|