iT邦幫忙

0

這些年來 BIG DATA 笑笑笑

這些年來 BIG DATA 笑笑笑
有人總計 65億萬筆資料
有笨到用 VIEW 來篩選存取
有笨到用 CURSOR 來篩選存取
因此 : 很慢很慢
答案 : 要改架構
但是一堆人推推推 BIG DATA
真是好好笑......

Albert iT邦高手 1 級 ‧ 2012-12-28 13:29:35 檢舉
感謝回應 回應真感謝
8
pantc328
iT邦研究生 1 級 ‧ 2012-12-28 08:49:41

看不懂寫什麼?
資料要看用途而定
資料要經過分類,分析,統計...變成資訊,然後運用
誰會去看65億萬筆資料??

Albert iT邦高手 1 級 ‧ 2012-12-28 13:28:50 檢舉

感謝回應 回應真感謝

8
ted99tw
iT邦高手 1 級 ‧ 2012-12-28 09:21:58

其實恆河所存沙的數量也是粉可怕滴,有可能超過65億萬粒,但與中國黃河比起來,那又差多了...

Albert iT邦高手 1 級 ‧ 2012-12-28 13:29:00 檢舉

感謝回應 回應真感謝

12
charmmih
iT邦研究生 5 級 ‧ 2012-12-28 10:08:12

albertachen提到:
這些年來 BIG DATA 笑笑笑
有人總計 65億萬筆資料
有笨到用 VIEW 來篩選存取
有笨到用 CURSOR 來篩選存取

Albert 大言簡意駭, 是高來高去的人....
勞駕你落入凡塵, 多說些大眾語言, 多多開示....

幸好你說的狀況, 多多少少經歷過,
得以接通腦海中的經驗, 還能領會你的高語.

先舉的例子來說明:

通常AP人員會這樣下SQL
where substring (SALE_DATE,1,6)='201212'
用欄位運算去符合一個值

有經驗的DBA會改寫成
where SALE_DATE like '201212%'
用資料運算去比對欄位, 使資料庫用到索引

其實用VIEW不是壞事,
壞在VIEW的條件一般下在外層,
導致資料庫無法一開始在主表格就精準取得資料後,
再去串接其他次要表格,
遇此現象, 寧可用TABLE Function 將條件下在內層,
一開始在主表格就精準取得資料.

其實用CURSOR不是壞事,
通常是AP人員寫程式的思維,
往往是一筆一筆處理,
壞在CURSOR每一筆均耗用些許資料庫資源,
在加上沒有開立到好的索引,
對一個長時間的交易而言,
累積起來對資料庫資源是很重的負擔;
遇到此現象, DBA會考量如何下批次的SQL指令.

albertachen提到:

因此 : 很慢很慢
答案 : 要改架構
但是一堆人推推推 BIG DATA
真是好好笑......

往往在DBA看來:
邏輯沒有錯, 就不需改寫架構;
效能差, 應是改寫SQL及建立合適的索引.

在我看來...
BIGDATA 應是用在海量的非結構性資料分析,
卻牛刀小試在解決報表效能問題....

charmmih iT邦研究生 5 級 ‧ 2012-12-28 12:20:56 檢舉

charmmih提到:
通常AP人員會這樣下SQL
where substring (SALE_DATE,1,6)='201212'
用欄位運算去符合一個值

有經驗的DBA會改寫成
where SALE_DATE like '201212%'
用資料運算去比對欄位, 使資料庫用到索引

這段話更精確描述是...

通常AP人員會這樣下SQL
where substring (SALE_DATE,1,6)='201212'
用每一筆資料之條件欄位的值運算去符合使用者條件的值,
表格欄位運算, 造成資料庫不能使用到此欄位的索引

有經驗的DBA會改寫成
where SALE_DATE like '201212%'
用使用者條件的值運算去比對欄位的值,
造成資料庫可以用到此欄位的索引

重點是....
要下好精準SQL, 要去瞭解資料庫引擎動作,
用資料庫引擎動作的思維去寫SQL

也就是...SARG
fn(field)=Variable (x)
field=fn(Variable)(O)

Albert iT邦高手 1 級 ‧ 2012-12-28 13:28:42 檢舉

感謝回應 回應真感謝

10
summertw
iT邦好手 1 級 ‧ 2012-12-28 10:50:29

Big Data...
有趣的用詞...
按樓主的用意,是否改一下...用【many data】或者【too many data】會較會用一點..
65億萬筆資料,確實是【很多】資料,而不是【大】資料..
...
SQL 最擅長為這種很多資料的資料庫建置高效率的索引,但首要條件,必須用對你要的讀取資料時所用的指令..
對於擁有65億萬筆資料的Table來說,每次的搜尋,條件必須是明確的,也就是操作資料的前端不可以不給條件或是給模糊的條件...

Cursor是有很明確的使用時機的,所以,設計者應不致弄到用Like這種語法才對..
Cursor的使用也必須視你要求的狀況來執行,如使用單向、或可回頭的捲覆式、屬區域或是全域都很重要..
再者,Cursor的使用,大多不會用在太龐大的資料,因為如此會耗掉太多的資源...除非有萬不得已的原因及理由..

註:
Cursor的使用,以上的說法不太合適於Unix/Linux裡所使用的Informix-4GL的概念。

65億萬筆資料,看似很多,但還得看它的資料結構是否很多欄位,如果只要十來個欄位或是幾個欄位,那這個數額應該還好,若結構屬於很多層的關聯(【含】三階以上的正規劃),那就有些可觀了...

其實用VIEW不是壞事..
VIEW的使用它本就是一種資料權限的移轉,它好像跟資料多寡不會有絕對的關係(但還是會有關係)..
比方說,同一個資料表,在設計之初,使用了40個欄位,但在使用一段時間後,因時空轉變,它必須分離,把其中15個欄位分離出來,分別弄給兩個不屬的單位去維護,這時你可能用View去作分割的工作,雖然是分割了,它的資料主從關係仍然緊緊的扣住,這是View一個很大的功用...
它的第二個使用時機則是Join主從資料表做出統計表或分類表,以簡化前端開發報表的工作。但單一資料表對自我作關聯再作出統計的作法,不能說沒有,但終是少見,而且這樣的作法應是規劃上出了問題的資料表...

一個規劃妥善的資料庫,不怕很多的資料,越多是越好才對,因為越能表現其實際的效率...

Albert iT邦高手 1 級 ‧ 2012-12-28 13:28:33 檢舉

感謝回應 回應真感謝

pantc328 iT邦研究生 1 級 ‧ 2012-12-28 13:40:20 檢舉

請問 albertachen 要怎麼處理?
65億萬筆,用超級電腦算也要一段時間

Albert iT邦高手 1 級 ‧ 2012-12-28 15:39:12 檢舉

pantc328 大大 技術超強

感謝 pantc328 大大 蒞臨指導

我要發表回答

立即登入回答