一個只提升 5 - 10 倍的硬體暴力美學正在擅動你的心

Albert 2012-08-29 07:22:00 ‧ 5376 瀏覽

分享至

一個只提升 5 - 10 倍的硬體暴力美學正在擅動你的心
一般 Oracle ERP 因為太多 [ View ] 拖累了速度...
一般 Oracle ERP 因為太多暫存性Update/Delete 拖累了速度...

Review Procedure 重構可以快 100 倍 , 但是太優雅了....
要改 code 要人工 .... 硬體有利潤空間 20% 人工有利潤空間 80%

台灣 I & BM O & racle ERP 執行績效調校服務有100倍的客戶驗證績效
我們在 AS & US 跟你一起實踐績效跳躍..........................

故事來自今天早上的 [心文] 啟發 :

在導入FAST Cache前報表作業需要2~3小時才能完成，現在僅花費20分鐘。

<太少了> 還要 20分鐘 ??

在車王驗證EMC FAST Cache方案確能突破儲存設備相容性限制後，整個建置過程十分迅速，只針對部分資訊系統的組態進行了一些調校，以使其能善用FAST Cache效能，便完全克服之前遭遇的可用度瓶頸，連擴充儲存系統的空間、電力、和成本都節省下來。

實際上線運作後，在導入FAST Cache前報表作業需要2~3小時才能完成，現在僅花費20分鐘。而在此架構下，車王使用的兩個不同容量儲存設備可同時作為線上和異地備援使用，彼此間並未發生效能干擾現象，充分運用既有投資。

DIGITIMES中文網原文網址: EMC Fast Cache助車王電子提升ERP效能 http://www.digitimes.com.tw/tw/dt/n/shwnws.asp?id=0000299949_J9Z8L04U5SCL6W80OYQBQ&ct=1#ixzz24swS25TZ

總裁 iT邦好手 1 級 ‧ 2012-08-29 11:19:07 檢舉

暴力美學---有這麼美嗎??

ted99tw iT邦高手 1 級 ‧ 2012-08-29 11:27:22 檢舉

嗯，嗯....隱約可看到蝴蝶展開的上翅.....

登入發表討論

直播研討會

{{ item.channelVendor }} {{ item.webinarstarted }} |

直播中

6 個回答

ted99tw

iT邦高手 1 級 ‧ 2012-08-29 09:26:25

前半段的第一個粉絲報到！

回應
分享
檢舉

登入發表回應

charmmih

iT邦研究生 5 級 ‧ 2012-08-29 10:12:14

albertachen提到：
硬體暴力美學

一般報表是指所謂月報, 其中又以進銷存月報跑的執行時間最長;
在分析報表執行的時間, 在資料庫動作中其實是撈取資料為最大宗;
以SQL Server撈一個月銷售資料約100萬筆要多久, 有的約10秒, 或有的要2小時;
上例以EMC FAST CACHE 3小時進步到20分鐘約9倍;

我遇到一個例子跑進銷存月報, 突然間跑錯執行計劃約需2小時,
之後開對索引, 跑對執行計劃不到20秒就出來了......

一般公司和SI公司較密切, 所以找的方案較偏向硬體提昇的普遍方案;
又資料庫調校是偏向個案, 有時甚至開發廠商也對資料庫調校沒有深入, 沒此解決方案......
所以一般公司解決方法, 通常是先硬體提昇, 而資料庫調校方面往往擺最後,
或是恰好遇到可供參考案例才會往這方面參考....

回應 2
分享
檢舉

Albert iT邦高手 1 級 ‧ 2012-08-29 10:19:25 檢舉

charmmih提到：
我遇到一個例子跑進銷存月報, 突然間跑錯執行計劃約需2小時,
之後開對索引, 跑對執行計劃不到20秒就出來了......

架構 [軟體] 優雅美學 , 展現 100 倍驚人魅力 !!

charmmih iT邦研究生 5 級 ‧ 2012-09-03 10:21:01 檢舉

charmmih提到：
以SQL Server撈一個月銷售資料約100萬筆要多久, 有的約10秒, 或有的要2小時;

這裏是指SQL Server 內部讀取100萬筆一個月資料的速度,
a. 有的資料庫會很精準讀取這100萬筆資料所在的資料區塊;
b. 有些資料庫設計不好, 資料散亂可能要讀到這300萬筆資料所在的資料區塊, 才能涵蓋這100萬筆資料;
c. 有些系統架構設計不好, 沒有使用索引要讀到所有的資料區塊, 才能涵蓋這100萬筆資料;
這是資料庫實際運作上所遇到的問題, 是被隱藏在系統設計下的KNOW-HOW.
用"撈"這字眼, 讓人感覺到前端讀取並顯示的資料, 確實要顯示時, 要考量資料使用者對資料的需求, 依其需求設計資料筆數, 而不是一股腦兒資料丟出來交代使用者.

登入發表回應

一級屠豬士

iT邦大師 1 級 ‧ 2012-08-29 10:13:48

前半段的第二個粉絲報到！

回應 2
分享
檢舉

charmmih iT邦研究生 5 級 ‧ 2012-08-29 10:17:41 檢舉

不好意思....插隊了....

Albert iT邦高手 1 級 ‧ 2012-08-29 10:21:20 檢舉

charmmih 說：不好意思....插隊了....

大師不用抱歉
大師大大有料英明無限

登入發表回應

pantc328

iT邦高手 1 級 ‧ 2012-08-29 10:20:33

軟實力要比硬實力重要
系統設計不好，換了硬體只是延長爆掉的時間

View,Update,索引..都是學問
100萬筆去撈..他馬的神經病
有人會去對100萬筆明細??
資料交易，資料採礦..
操作人員，決策人員
即時，歷史..
都有不同作法
要月報，就把交易資料拋轉至歷史資料庫
歷史資料庫在晚上慢慢的轉成報表就好了

回應 5
分享
檢舉

看更多先前的回應...收起先前的回應...

Albert iT邦高手 1 級 ‧ 2012-08-29 10:25:22 檢舉

大師的做法

與 SAP 比較接近的構思

大師軟實力身段大大優於硬體暴力美學

即時，歷史..
都有不同作法
要月報，就把交易資料拋轉至歷史資料庫
歷史資料庫在晚上慢慢的轉成報表就好了

pojen iT邦研究生 5 級 ‧ 2012-08-29 11:27:51 檢舉

不管黑貓白貓,只要會抓老鼠的就是好貓.

原始程式寫的再好, 如果能用硬體暴力加快處理速度, 有無不可. 與其慢慢的校調 OLTP 讓他跑報表, 到不如直接放到記憶體讓他跑. (如 O 家的 TimesTen) 或是 M 記的 Columnstore index, 或是乾脆直上 Exadata 在儲存池直接就把問題解決了.

如 pantc328 所說, 在資料庫的世界裡, 牽一髮則動全身, 多了一個 index 或許加快的某幾個 query, 但也可能同時搞砸另外的執行計畫. DBA 又有多少時間慢慢的建與管理 hint, baseline, profile. (喔.. 另外一個問題是要去哪裡找到有這種技術的人員? 而不是半桶水只會跟著 advistor 建 index ) 我對於新人的要求從 senior 到 mid-level 到 junior. 而現在我已經連大學剛畢業的都沒關係了... 還希望 albertachen 能夠多多分享在哪能找到這麼多的人才.