如何從源頭打造極速優化的MES系統

如何從源頭打造極速優化的MES系統

作者：黃睿

當企業上線MES系統之后，僅僅是萬里長征的開始，為什么要進行MES的優化？這是一個非常之現實以迫切的問題，眾所周知，MES系統所運行的必要基礎數據之外，MES系統每天還采集了大量的生產過程數據存放到數據庫之中，其數據量大小，取決于如下幾個方面：

A． 企業的生產規模。

B． MES管理的產品流程的數量

C． MES每流程上數據采集節點的站點數

D． 每站點數內部的數據采集內容

E．第站點上的數據采集的時間頻率

F．第三方系統存放到MES數據庫中的數據內容

隨著系統的上線，數據量日漸增大，由最初的幾個G，增加到100G甚至幾個TB, 系統的性能，也隨之而下降，同時還表現出如下的幾個方面的弊?。?/span>

G．系統掃描相應變慢

H．系統報表查詢變慢

I．看板等實時刷新程序無法正常執行

J．系統登陸時間過長

K．系統作業過程中停頓(卡，延時) 或死鎖, 需重啟服務器次數增多。

L．數據備份日漸困難。

以上問題不光是MES系統所特有的，所有的事務處理性(OLTP)性的數據庫應用系統，都將面臨以上的困擾。由于很多MES系統默認采用的是關系性數據庫（SQL Server /Oracle），除少量計算在前端完成以外，系統中95%的邏輯運算都在DB層中實現，非常依賴于數據庫服務器的性能， 所以，當MES系統表現不盡如人意之時，首先需要在數據庫后臺進行必要的數據優化，完成后基本上就能取得相應的性能提升，以下以中國市占率相當之高的深圳市華磊迅拓科技有限公司的OrBit-MES系統為例，來說明如何針對DB層進行深度的優化：

OrBit-MES后臺優化包含的內容如下：

1.合理的表以及邏輯關系的設計；

2.數據庫的日常維護工作；

3.數據庫大數據量表的數據壓縮；

4.數據庫大數據量表的分區表方法；

5.歷史數據的定期遷移；

6.合理的負載部署，服務器的分工；

7.服務器硬件性能的提升；

 以下以最常見的表結構與邏輯關系的設計的優化為例子加以重點說明：OrBit-MES系統表以及標準模型表，以及相關邏輯（存儲過程）是在系統平臺的設計階段已定決定，并且經過了相當多的實踐，其性能相對穩定可靠，靠此部份的優化以提升系統整體性能的收益不大，效果也不太明顯。

系統在實施周期時根據客戶所定制的表，以及存儲過程，特別是新上線的功能插件所對應的存儲過程，將有比較大的優化余地， 在這類業務表的設計時，應注意如下方面：

A.遵守業界通行的數據庫設計的標準范式（至少前3個范式盡可能遵守）

B.遵守OrBit-MES建議的主鍵定義方法，以及字段命名規則

C.合理的設計表的冗余以及關聯，區分事務處理表（大表），以及基礎數據表(小表)。

D.合理設計索引，特別是經常用于查詢的表的索引（產品表，工單表, Lot表等），對于大表只創建必要的索引。

E.對于第三方測試數據表，采用分庫或分服務器的設計方案，不要放到MES主數據庫中。

F.一切新表的設計，應以性能為首要考慮因素

業務邏輯（查詢或存儲過程）設計時時，應注意如下方面：

A. 所有的內部查詢應基于主鍵PK

B.避免在一個大的SQL中采用一次性連接多個表的查詢 (特別是大表對大表的關聯，是非常不明智的)，應拆分為基于PK的多步來執行查詢。

C. 避免使用大的事務包裹業務邏輯，事務應盡可能短小，否則容易占用服務器資源導致排隊甚至死鎖。

D. 少用游標，絕不要針對大表使用游標。

E.Select查詢時盡可能使用 With (no lock) 語句，避免占用鎖的開銷，在每一個存儲過程中加入： SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED ,以降低死鎖的可能性。

F.Insert最好以批量方式執行，一次性處理多條新記錄。

G.Update應基于PK為條件，避免使用復雜的Where表達式, 導致表鎖。

H.一切有利于減少死鎖，提升性能的邏輯設計為首要考慮因素。

事實證明，頻繁的死鎖往往出自于不合理的業務邏輯設計，故在進行OrBit-MES的客戶化功能的數據設計時，應仔細權衡，以性能為先導，才能取得相對較好的結果。

當數據庫服務層的優化進達到一個相當高的水準之后，企業的還需要考慮后續的一些優化過程，比如大數據的定期歸檔，提升網絡以及服務器本身的的IOPS性能等等，進行深度的負載均衡的設計，在這方面，不同的MES廠商水平參差不齊，所以選型MES時，請注意一定不能有“運維優化黑箱”，候選的MES系統所有的數據資產必須全方位向甲方開放，同時還需要提供專業的瓶頸定位工具以及優化工具，它必須是一個“可高度優化的MES”, 否則企業將會為此付出極為沉痛的代價。

只有從源頭加以及分析與優化，才能讓你的MES系統“健步如飛”。