資料處理
在擷取與視覺化之間，ThingWorx Platform 也需要足夠的系統資源來執行應用程式的任何企業邏輯與資料轉換需求。
本節將說明可影響資料處理需求的更重要區域的概念。資料處理非常依賴於特定企業使用案例，使標準化計算不太有用。
當您的擷取與視覺化預估準備就緒時，應用程式負載或壓力測試是投入生產之前的一個重要步驟，如果您的應用程式需要更多資源來處理複雜的企業邏輯或事件/警示處理，則可能會導致您選取與基線不同的大小系統。
訂閱與事件
計時器與內容變更事件的訂閱通常會構成 ThingWorx 應用程式中的大多數企業邏輯。這些訂閱使用事件處理子系統中的記憶體，其中子系統是在擷取與裝置連接期間未使用的系統。
針對穩定擷取與裝置連線設定好系統大小之後，已準備好企業邏輯的負載測試是確保正確調整系統大小以支援生產使用的一個重要的步驟。
檔案傳輸與管理
在 Edge 之間傳輸檔案是 ThingWorx 應用程式使用案例的常見需求：
• 部署軟體更新
• 疑難排解或存取記錄檔
• 接收圖像、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 是可在所有大小的生產環境中使用的關聯式資料庫。SQL Server 與 PostgreSQL 之間的選擇通常是由資料庫或作業系統的現有 IT 經驗所決定。
• InfluxDB - 一種非常適合在開發與生產系統中用於對 ThingWorx 串流與值串流進行大規模擷取的時間序列資料庫，以及管理 ThingWorx 資料模型的關聯式資料庫 (Microsoft SQL Server 或 PostgreSQL)。
|
|
ThingWorx 可與開放原始碼、單一伺服器版本的 InfluxDB 或 InfluxDB Enterprise 叢集搭配使用，以獲得高可用性及提高效能。本指南中的測試使用了開放原始碼版本。
|