很多人對智能工廠的印象還停留在機(jī)械臂揮舞、AGV小車穿梭、大屏上跳動著的各種生產(chǎn)數(shù)據(jù)。但作為一個常年泡在車間信息化項目里的老運維我想說一句大實話那些炫酷的畫面背后真正支撐整條產(chǎn)線跑起來的往往是一排不起眼的Linux服務(wù)器和一群默默扛著千萬級數(shù)據(jù)讀寫的數(shù)據(jù)庫實例。高端制造能不能“加速”很多時候取決于Linux跑得穩(wěn)不穩(wěn)、數(shù)據(jù)庫扛不扛得住。這篇文章我想從一個親歷者的角度聊聊智能工廠背后這套“看不見的基座”為什么工業(yè)現(xiàn)場越來越依賴Linux數(shù)據(jù)庫在制造環(huán)節(jié)里到底承擔(dān)了多重的活以及我們在一線部署、運維、救火過程中踩過的坑和總結(jié)出來的經(jīng)驗。不管你是有意進(jìn)入智能制造領(lǐng)域的運維新人還是在工廠IT部門做系統(tǒng)支持的工程師這篇文章都值得花幾分鐘讀完。1. 智能工廠的控制中樞為什么偏偏是Linux在跑先說一個容易被忽視的事實工廠里的核心系統(tǒng)遠(yuǎn)比你想象中更依賴Linux。從數(shù)控機(jī)床的嵌入式系統(tǒng)、PLC的通信網(wǎng)關(guān)、機(jī)器人的控制柜到MES制造執(zhí)行系統(tǒng)應(yīng)用服務(wù)器、SCADA數(shù)據(jù)采集與監(jiān)控的歷史數(shù)據(jù)庫再到邊緣側(cè)的人工智能推理盒子Linux幾乎無處不在。有人會問Windows在老工業(yè)自動化里不也挺多的嗎確實有早期很多組態(tài)軟件、HMI人機(jī)界面跑在Windows上但最近五六年新改擴(kuò)建的產(chǎn)線項目里L(fēng)inux的占比肉眼可見地在提升。我參與過好幾個整車零部件工廠和3C電子產(chǎn)線的項目新上的邊緣網(wǎng)關(guān)、工業(yè)協(xié)議解析服務(wù)、數(shù)據(jù)中臺節(jié)點幾乎清一色是Linux環(huán)境。1.1 車間里那些你看不見的Linux很多讀者可能沒機(jī)會下車間我描述幾個真實場景你就明白Linux在工廠里無處不在。第一類是嵌入式工控機(jī)比如機(jī)器人控制柜里的主控單元。很多主流機(jī)器人品牌的控制器底層就是定制的Linux內(nèi)核甚至是實時擴(kuò)展后的Linux也就是帶PREEMPT_RT補(bǔ)丁的內(nèi)核。它要在一個控制周期內(nèi)完成運動學(xué)解算、插補(bǔ)運算和伺服指令下發(fā)對確定性要求極高。第二類是邊緣數(shù)據(jù)采集網(wǎng)關(guān)。產(chǎn)線上幾十臺PLC每臺每秒可能產(chǎn)生幾十乃至上百個點位數(shù)據(jù)網(wǎng)關(guān)要同時用Modbus TCP、OPC UA、S7comm等協(xié)議去采集再做一些清洗、緩存和轉(zhuǎn)發(fā)。這種活路Windows能干但穩(wěn)定性和資源占用都不如Linux來得省心。第三類是服務(wù)器集群包括數(shù)據(jù)庫服務(wù)器、應(yīng)用服務(wù)器、文件服務(wù)器。MES、WMS、QMS這些業(yè)務(wù)系統(tǒng)大概率部署在Linux上的容器環(huán)境或虛擬機(jī)里。原因也很直白穩(wěn)定、省內(nèi)存、好維護(hù)。所以當(dāng)你站在智能工廠的中控大屏前感慨?dāng)?shù)據(jù)多炫的時候請記住背后是無數(shù)個Linux進(jìn)程在默默干活。1.2 工控場景選Linux的三個硬理由很多非技術(shù)背景的管理者不理解為什么非要LinuxWindows Server不是也能用嗎我通常用三個理由來回答這三點是制造業(yè)客戶最關(guān)心的第一是穩(wěn)定性。整車廠往往是7×24小時不間斷生產(chǎn)設(shè)備窗口極其緊張。Windows更新機(jī)制偶爾會給你來個重啟這在產(chǎn)線環(huán)境里是不可接受的。而Linux服務(wù)器只要不打內(nèi)核升級跑上一兩年不重啟是家常便飯。第二是資源效率。同樣的4核8G配置裝Windows Server光系統(tǒng)就吃掉兩三個G內(nèi)存跑幾個服務(wù)就捉襟見肘。而換成精簡過的Linux同樣配置能跑起完整的數(shù)據(jù)庫加應(yīng)用集群。工廠的IT預(yù)算往往摳得很細(xì)能用同樣的硬件干更多活這事本身就很有說服力。第三是可裁剪性。工業(yè)環(huán)境五花八門有些場景需要極小系統(tǒng)比如一個只有幾十兆的嵌入式系統(tǒng)有些場景需要極強(qiáng)的實時性需要編譯帶實時補(bǔ)丁的內(nèi)核有些場景需要安全加固需要按等保要求裁剪不必要的服務(wù)和端口。這種靈活度Linux是唯一的選擇。1.3 從鏡像安裝到國產(chǎn)化Linux選型那些事這里順帶聊聊Linux的發(fā)行版選型因為很多剛?cè)胄械呐笥严矚g在這上面糾結(jié)。如果是云端或者純測試環(huán)境用Ubuntu Server或者Debian都挺舒服軟件源豐富遇到問題搜索引擎一抓一大把。如果是要長期運維的生產(chǎn)環(huán)境我更傾向于RHEL系的發(fā)行版比如Rocky Linux或AlmaLinux他們對內(nèi)核參數(shù)、SELinux、防火墻這些生產(chǎn)級特性的支持更成熟。至于網(wǎng)上常說的那些“Linux命令大全”說真的你不用死記硬背但下面幾個命令是生產(chǎn)環(huán)境高頻使用的# 查看系統(tǒng)負(fù)載和CPU核心數(shù)的關(guān)系 top # 查看內(nèi)存和Swap使用情況 free -h # 查看磁盤I/O是否成為瓶頸 iostat -x 1 # 查看網(wǎng)絡(luò)連接數(shù) ss -tunap # 查看特定進(jìn)程的線程數(shù) ps -eLf | grep java | wc -l鏡像安裝這塊現(xiàn)在主流做法是PXE網(wǎng)絡(luò)引導(dǎo)批量部署或者用云平臺的鏡像模板直接拉起來。工廠內(nèi)網(wǎng)環(huán)境一般沒有外網(wǎng)所以提前準(zhǔn)備好本地Yum源或Apt源是必須的不然裝個軟件包等半天極其影響效率。還有一點值得注意的是國產(chǎn)化趨勢。近幾年我們在政企和國企工廠項目里越來越多地接觸到麒麟、統(tǒng)信UOS這類國產(chǎn)Linux數(shù)據(jù)庫這塊也會要求適配人大金倉、達(dá)夢等國產(chǎn)數(shù)據(jù)庫。技術(shù)?？赡茏兞说讓舆壿嫑]變——它們依然是Linux內(nèi)核依然用SQL依然逃不開系統(tǒng)運維的基本功。與其焦慮學(xué)哪個不如把Linux的通用能力打扎實。2. 數(shù)據(jù)庫在智能工廠里到底“扛”什么講完Linux聊聊真正的重頭戲數(shù)據(jù)庫。如果說Linux是智能工廠的神經(jīng)系統(tǒng)那數(shù)據(jù)庫就是它的記憶中樞。設(shè)備數(shù)據(jù)、生產(chǎn)數(shù)據(jù)、質(zhì)量數(shù)據(jù)、物料數(shù)據(jù)、人員數(shù)據(jù)最終都要落到數(shù)據(jù)庫里變成可以被查詢、被分析、被追溯的資產(chǎn)。不少做業(yè)務(wù)系統(tǒng)開發(fā)的同學(xué)對數(shù)據(jù)庫的理解停留在“增刪改查”這個層面。但在工業(yè)現(xiàn)場數(shù)據(jù)庫的挑戰(zhàn)完全不是一回事。我常說普通互聯(lián)網(wǎng)應(yīng)用講究的是“高并發(fā)、大流量”而工業(yè)數(shù)據(jù)庫講究的是“高寫入、強(qiáng)時序、長歷史、可追溯”。這兩個方向的技術(shù)側(cè)重差異很大。2.1 工業(yè)數(shù)據(jù)從哪來裹著什么樣的體量先看數(shù)據(jù)源頭。一條典型的自動化產(chǎn)線傳感器包括溫度、壓力、振動、電流、位移、視覺檢測等等。這些信號經(jīng)過PLC采集后會通過OPC UA等服務(wù)送上邊緣網(wǎng)關(guān)再寫入車間級的實時數(shù)據(jù)庫或時序數(shù)據(jù)庫。舉個具體的例子一條發(fā)動機(jī)缸體機(jī)加工線大概有20多臺加工中心每臺機(jī)床配置幾十個關(guān)鍵監(jiān)控點位包括主軸負(fù)載、進(jìn)給倍率、刀具壽命、冷卻液溫度等。如果每臺設(shè)備每秒采集一個點位整條線每秒產(chǎn)生的數(shù)據(jù)量就是幾百到上千條。這還只是一條線一個工廠動輒十幾條線再加上能源計量、環(huán)境監(jiān)測、質(zhì)檢數(shù)據(jù)數(shù)據(jù)量很容易一天破億條。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫比如MySQL在這種寫入壓力下會非常吃力。不是說不能寫而是寫入大量索引后的隨機(jī)I/O會成為瓶頸同時歷史數(shù)據(jù)膨脹后查詢也越來越慢。所以工業(yè)場景里需要仔細(xì)地為不同類型的數(shù)據(jù)挑選不同的數(shù)據(jù)庫。2.2 關(guān)系型數(shù)據(jù)庫MES與ERP的“賬房先生”MySQL和PostgreSQL這類關(guān)系型數(shù)據(jù)庫在智能工廠中負(fù)責(zé)的是業(yè)務(wù)型數(shù)據(jù)也就是那些結(jié)構(gòu)化程度高、一致性要求強(qiáng)、需要復(fù)雜事務(wù)的數(shù)據(jù)。比如MES里的工單狀態(tài)流轉(zhuǎn)一個工單從“已創(chuàng)建”變成“生產(chǎn)中”再變成“已完成”中間涉及批次拆分、物料扣減、工序報工一步都不能錯。再比如ERP里的庫存賬、財務(wù)賬那更是分毫不差。這類數(shù)據(jù)用關(guān)系型數(shù)據(jù)庫的ACID特性來保證是最穩(wěn)妥的選擇。在部署上工廠內(nèi)部的MES數(shù)據(jù)庫通常不會開在公網(wǎng)而是在內(nèi)網(wǎng)用主從架構(gòu)保證高可用。我經(jīng)手的項目里MySQL主從加半同步復(fù)制或者PostgreSQL的流復(fù)制是比較常見的方案。這里要特別提醒一句工業(yè)環(huán)境經(jīng)常有突然斷電、網(wǎng)絡(luò)瞬斷的情況數(shù)據(jù)庫的binlog或WAL日志的可靠性一定要重點配置sync_binlog和innodb_flush_log_at_trx_commit這兩個參數(shù)在允許的情況下盡量調(diào)高。另外很多工廠IT手里都攢著一些老系統(tǒng)比如2008年的SQL Server或者早期的Oracle。這類老庫耦合深、遷移難短期內(nèi)只能繼續(xù)維護(hù)。但也別死扛做好備份策略在適當(dāng)?shù)臅r候向開源庫或國產(chǎn)庫演進(jìn)長期來看是趨勢。2.3 時序數(shù)據(jù)庫一秒一條數(shù)據(jù)時MySQL就不好使了大規(guī)模設(shè)備數(shù)據(jù)采集場景我強(qiáng)烈建議交給時序數(shù)據(jù)庫Time Series DatabaseTSDB。這類數(shù)據(jù)庫專門為時間戳數(shù)值點這種數(shù)據(jù)模型優(yōu)化寫入性能和處理海量歷史數(shù)據(jù)的能力遠(yuǎn)超傳統(tǒng)關(guān)系庫。目前工業(yè)圈里用得比較多的有TDengine、InfluxDB、TimescaleDB等特別是TDengine因為國產(chǎn)、開源、性能亮眼這幾年在制造企業(yè)的出鏡率相當(dāng)高。我自己的項目里就用它存儲機(jī)床主軸負(fù)載和振動數(shù)據(jù)。TDengine的超級表、子表設(shè)計很貼合工業(yè)場景——每臺設(shè)備建一張子表設(shè)備屬性放標(biāo)簽采集值放普通列查詢起來干凈利落。提到TDengine就不得不提它的C/C接口。邊緣采集程序大多用C或C開發(fā)通過taos_stmt_prepare來做參數(shù)綁定寫入可以顯著減少重復(fù)解析SQL的開銷。我最早接觸這個接口時還不太習(xí)慣用下來才發(fā)現(xiàn)針對高頻、固定模式的寫入需求這種預(yù)處理方式比逐條拼SQL性能好一個檔次。taos_stmt *stmt taos_stmt_init(taos); taos_stmt_prepare(stmt, INSERT INTO ? USING meters TAGS (?) VALUES (?, ?, ?), 0); TAOS_BIND tags[1] {0}; tags[0].buffer_type TSDB_DATA_TYPE_INT; int32_t deviceId 101; tags[0].buffer deviceId; taos_stmt_set_tbname_tags(stmt, deviceId, tags); TAOS_BIND params[3] {0}; // 綁定時間、數(shù)值等參數(shù)后執(zhí)行批量寫入 taos_stmt_bind_param(stmt, params); taos_stmt_execute(stmt);這里不展開講完整代碼但要記住一個原則高頻數(shù)據(jù)采集永遠(yuǎn)優(yōu)先考慮批量寫入和預(yù)編譯綁定別一條一條地insert。3. 一套典型智能工廠數(shù)據(jù)鏈路的落地過程理論扯了不少我把一套真實項目里反復(fù)驗證過的數(shù)據(jù)鏈路架構(gòu)畫個文字版給你看然后分環(huán)節(jié)講落地細(xì)節(jié)。整個鏈路大致是設(shè)備層PLC/傳感器→ 邊緣采集網(wǎng)關(guān) → 消息中間件或直連 → 數(shù)據(jù)清洗與規(guī)則引擎 → 分布式存儲時序庫關(guān)系庫→ 數(shù)據(jù)服務(wù)API → MES/可視化大屏/算法平臺。我在做項目時習(xí)慣先畫清楚這張數(shù)據(jù)流圖再決定每個環(huán)節(jié)用什么技術(shù)而不是一上來就裝數(shù)據(jù)庫。3.1 邊緣層數(shù)據(jù)采集網(wǎng)關(guān)怎么部署邊緣網(wǎng)關(guān)在Linux上的部署是整個鏈路里坑最多的地方。硬件上我們常用的是研華、戴爾或國產(chǎn)廠家的工控機(jī)系統(tǒng)安裝Rocky Linux或Ubuntu Server裁剪掉不必要的圖形組件。軟件上一般會用開源的Node-RED或自研的采集程序來跑協(xié)議解析。PLC協(xié)議接入只講一個容易踩的坑西門子S7協(xié)議走的是102端口很多安全人員默認(rèn)覺得非Web端口不危險就不加防護(hù)了。但在工業(yè)內(nèi)網(wǎng)這類端口恰恰是橫向移動的高發(fā)通道。建議用防火墻限制只能由白名單網(wǎng)關(guān)訪問PLC別把整個網(wǎng)段都放進(jìn)來。網(wǎng)關(guān)程序?qū)憯?shù)據(jù)到數(shù)據(jù)庫時最容易犯的錯是內(nèi)存暴漲。很多新手喜歡在程序里做一把梭等內(nèi)存爆了就找原因。正確做法是采集線程和寫入線程分離中間用有界隊列解耦。隊列長度超過閾值就丟棄老點位并記錄告警寧可丟采樣點也不能讓網(wǎng)關(guān)進(jìn)程崩潰。3.2 數(shù)據(jù)入庫建表、結(jié)構(gòu)變更與同步策略數(shù)據(jù)到了存儲層建表設(shè)計直接決定后續(xù)查詢爽不爽。我用MySQL存業(yè)務(wù)數(shù)據(jù)時遵循幾個原則主鍵用自增ID但配合業(yè)務(wù)唯一索引金額、重量等字段用DECIMAL避免浮點誤差文本字段長度要克制別一上來就是TEXT所有表都要有create_time和update_time后面排查問題會省很多事。MySQL修改表結(jié)構(gòu)這事看起來簡單但生產(chǎn)環(huán)境執(zhí)行起來要格外小心。千萬行級別的表直接ALTER TABLE加索引可能鎖表幾分鐘產(chǎn)線報工全部堵住。比較穩(wěn)妥的做法是借助工具如pt-online-schema-change或gh-ost來做在線變更最大限度降低鎖表時間。我在車間項目里用gh-ost改過一張幾千萬行的報工表業(yè)務(wù)幾乎無感知。至于數(shù)據(jù)庫同步很多工廠不止一套系統(tǒng)比如MES數(shù)據(jù)庫要跟ERP數(shù)據(jù)庫同步物料主數(shù)據(jù)或者從數(shù)據(jù)中心同步到分廠的報表庫。常用方案包括基于binlog的Canal訂閱同步、基于主從復(fù)制的直連同步或者用DataX等批同步工具。選型邏輯很簡單要實時就選Canal或主從復(fù)制能接受分鐘級延遲就選批同步。3.3 數(shù)據(jù)消費從SQL到API別讓業(yè)務(wù)裸奔數(shù)據(jù)存好了最終要給人用、給系統(tǒng)用、給AI用。最忌諱的做法是讓每個業(yè)務(wù)系統(tǒng)直連數(shù)據(jù)庫。我曾經(jīng)接手過一個項目可視化大屏的程序直接用賬號密碼連接生產(chǎn)庫寫了一個幾百行的SQL去查實時產(chǎn)量。開發(fā)一時爽運維火葬場。后來幾條報表SQL把生產(chǎn)庫的連接池打滿了MES直接連不上數(shù)據(jù)庫產(chǎn)線停產(chǎn)了十分鐘。正確的做法是數(shù)據(jù)服務(wù)化也就是在數(shù)據(jù)庫前面加一層API服務(wù)。業(yè)務(wù)系統(tǒng)、大屏、算法平臺都通過REST API或gRPC去取數(shù)由API層做鑒權(quán)、限流、緩存。這樣即使某個報表SQL寫得不怎么樣最多拖垮API服務(wù)也不會直接把生產(chǎn)庫拖死。對于常見的增刪改查需求可以通過API網(wǎng)關(guān)統(tǒng)一封裝對于分析類需求則把數(shù)據(jù)導(dǎo)出到分析型數(shù)據(jù)庫或數(shù)據(jù)倉庫里跑別在生產(chǎn)庫上執(zhí)行重型聚合。4. 數(shù)據(jù)庫扛不住時運維人怎么救場在智能工廠做運維最怕的就是半夜電話響。因為工廠一旦停線每一分鐘損失都是真金白銀。我總結(jié)過的數(shù)據(jù)庫故障案例幾乎都集中在幾個固定的坑里。這里把典型場景和排查思路分享出來方便兄弟們按圖索驥。4.1 典型故障一數(shù)據(jù)庫連接池被打滿癥狀非常直接業(yè)務(wù)系統(tǒng)報“無法獲取連接”或者連接數(shù)飆到上限。原因十有八九是某個應(yīng)用忘了釋放連接或者并發(fā)量突增導(dǎo)致的應(yīng)用側(cè)連接池配置不合理。排查步驟按順序來第一先看數(shù)據(jù)庫側(cè)當(dāng)前連接數(shù)show processlist;看有沒有大量Sleep狀態(tài)的連接。如果有基本就是應(yīng)用側(cè)沒釋放連接去查代碼、查連接池配置。第二看連接來自哪些應(yīng)用IP用防火墻或數(shù)據(jù)庫賬號權(quán)限按應(yīng)用隔離連接上限別讓一個應(yīng)用把數(shù)據(jù)庫拖死。第三調(diào)連接池參數(shù)初始連接數(shù)、最小空閑、最大連接、連接超時時間都要結(jié)合應(yīng)用的實際QPS來設(shè)置。補(bǔ)充一句MySQL默認(rèn)的max_connections是151在工廠里幾十個應(yīng)用一起接的話這個值通常要往上調(diào)。但是調(diào)高之前先算一下每個連接可能的排序緩沖、臨時表內(nèi)存不然連接數(shù)上去了內(nèi)存頂不住更加難看。4.2 典型故障二慢查詢拖垮一切另一個高頻故障是慢查詢。平時業(yè)務(wù)量小的時候一條爛SQL跑兩秒也不覺得有問題。一旦月底產(chǎn)量沖高數(shù)據(jù)量上來這條SQL突然變成50秒把CPU和I/O全部吃滿整個數(shù)據(jù)庫性能雪崩。所以數(shù)據(jù)庫維護(hù)有一條鐵律慢查詢?nèi)罩鹃L期開啟閾值設(shè)置到1秒甚至0.5秒然后每周定期分析這些慢SQL。-- 查看當(dāng)前慢查詢相關(guān)設(shè)置 SHOW VARIABLES LIKE slow_query_log%; SET GLOBAL slow_query_log ON; SET GLOBAL long_query_time 0.5;拿到了具體的慢SQL先別急著改代碼用EXPLAIN看執(zhí)行計劃。重點看三個東西是否走了索引、掃描行數(shù)是多少、有沒有文件排序或臨時表。工業(yè)軟件里最典型的問題是查設(shè)備點位的時候在歷史數(shù)據(jù)表上沒用上時間索引導(dǎo)致全表掃描。解決方法是建好聯(lián)合索引比如(device_id, ts)這類組合索引而不是只建單列索引。有一說一我見過太多所謂“數(shù)據(jù)庫性能優(yōu)化”最后就是給查詢加個索引了事。真正要治本還得從數(shù)據(jù)模型設(shè)計、讀寫分離、歷史數(shù)據(jù)歸檔幾個層面一起搞。4.3 高可用與容災(zāi)主從、同步和備份的平衡高端制造對數(shù)據(jù)連續(xù)性的要求特別高一臺數(shù)據(jù)庫掛了如果沒能及時切換產(chǎn)線上的數(shù)據(jù)就會斷檔。這塊我們常用的方案是主從復(fù)制加自動故障切換。MySQL半同步復(fù)制是主流。它的原理是主庫提交事務(wù)后至少要等一個從庫確認(rèn)收到binlog才返回成功這樣主從切換時數(shù)據(jù)丟失的概率極低。當(dāng)然半同步復(fù)制也有一個副作用如果從庫故障主庫的寫入會阻塞。所以還要配合監(jiān)控告警一旦半同步退化為異步立刻通知運維處理。備份策略也值得展開。很多工廠只做邏輯備份用mysqldump每天凌晨跑一次。對于小庫沒問題到大庫就是災(zāi)難——且不說導(dǎo)出和導(dǎo)入的時間光是備份期間對數(shù)據(jù)庫的性能影響就夠喝一壺的。更好的方案是物理備份用xtrabackup或者數(shù)據(jù)庫原生的物理備份工具速度比mysqldump快一個數(shù)量級而且能基于binlog做時間點恢復(fù)。我自己的備份習(xí)慣是“3-2-1”原則三份數(shù)據(jù)兩種介質(zhì)一份異地。工廠環(huán)境里異地可以是另一個車間機(jī)房也可以是云上的對象存儲總之不能和主庫待在同一個機(jī)柜里。4.4 國產(chǎn)數(shù)據(jù)庫與信創(chuàng)適配的一點叮囑既然熱搜里反復(fù)出現(xiàn)人大金倉、達(dá)夢這些詞我多說兩句國產(chǎn)數(shù)據(jù)庫適配的事。它們從功能上兼容主流SQL語法但深挖下去差異還是存在的。比如某些函數(shù)的行為、事務(wù)隔離級別的默認(rèn)值、分區(qū)表語法、主從同步的實現(xiàn)方式都跟MySQL或Oracle有微妙的不同。做信創(chuàng)項目時我會建議團(tuán)隊提前準(zhǔn)備一個“語法兼容性清單”把項目里常用的SQL語句拉出來在目標(biāo)數(shù)據(jù)庫上逐個跑一遍。不要等系統(tǒng)上線了才發(fā)現(xiàn)某個復(fù)雜報表語法不支持。還有性能問題國產(chǎn)庫在簡單增刪改查上和MySQL差距不大但復(fù)雜分析查詢可能性能差異明顯該優(yōu)化的還是要優(yōu)化。另外工業(yè)場景里向量數(shù)據(jù)庫也開始露臉。隨著AI質(zhì)檢、知識庫問答在工廠里落地像文本、圖像特征向量這類非結(jié)構(gòu)化數(shù)據(jù)越來越多地存儲到向量數(shù)據(jù)庫里做語義檢索。未來智能工廠的數(shù)據(jù)底座大概率是“關(guān)系庫時序庫向量庫”多引擎并存運維人員的技術(shù)面也得跟著拓寬。5. 寫在最后給智能工廠IT人的幾句心里話這個行業(yè)這些年變化太快從數(shù)字化車間到智能工廠從自動化到智能化概念一個接一個。但我始終覺得無論上層業(yè)務(wù)怎么變底層技術(shù)基座的邏輯沒有變過——穩(wěn)定的操作系統(tǒng)可靠的數(shù)據(jù)存儲清晰的數(shù)據(jù)流。說句實在話做工廠IT和做互聯(lián)網(wǎng)運維的最大區(qū)別在于互聯(lián)網(wǎng)掛了用戶頂多罵兩句工廠系統(tǒng)掛了那是實實在在的產(chǎn)線停擺、訂單延誤、設(shè)備空轉(zhuǎn)。這種壓力逼著我們必須把系統(tǒng)和數(shù)據(jù)庫的功課做得更細(xì)。如果你正在入行或者已經(jīng)在路上建議從三件事入手積累第一把Linux常用命令和系統(tǒng)排查方法論練扎實這是所有上層技術(shù)的底座第二吃透至少一種數(shù)據(jù)庫的運行原理包括事務(wù)、索引、鎖、復(fù)制而不是只停留在寫SQL第三多下車間、多看產(chǎn)線理解業(yè)務(wù)比理解技術(shù)更重要。踩過幾次數(shù)據(jù)庫連接池被打滿的坑之后我現(xiàn)在寫任何代碼都會自動帶上一句連接必須釋放查詢必須帶LIMIT關(guān)鍵SQL必須過一遍EXPLAIN。這些習(xí)慣都是工廠的產(chǎn)線替我們養(yǎng)成的。