9月10號凌晨3點的時候，CERN的大型強子對撞機(LHC)投入了第一個質子束，一個月後就要進行第一次對撞。LHC一年能夠產生15PB(15,000,000GB)的資料量，如果以一張DVD9來算的話，那就是166萬張了。但要怎樣能夠將這些偵測器得到的原始資料進行龐大的運算？這個時候就要靠著分散式運算來得到結果。而其中一種分散式運算的技術，我們稱做格網計算。

我希望透過這篇文章，讓大家了解電腦的運算歷史，以及未來每個人手上的電腦，又會被放在世界的哪裡。

運算(Computing)的歷史

運算(Computing)，又被譯為計算。也因此用來計算的機器，當然就稱做為計算機了。但在台灣的譯名，放在手上輸入數字那種才叫計算機(大陸叫做計算器)，而Computer就是電腦了。計算的意義便是，有一群資料，透過一個流程將這些資料進行加減乘除，或是更複雜的數學運算，來得到想要的結果。

在討論計算的歷史的時候，同樣地也等於討論到計算機及電腦硬體的歷史。從算盤，到巴斯卡計算器，再到真空管電腦，直到現在的IC電腦，電腦計算的速度可以說是指數成長。而在IC電腦已經這樣普及的時候，人們也早就習慣研究數位化的計算方法(演算法)，並且將資料數位化後進行計算，在將這些計算後的數位資料，又轉回人可以理解的圖形或是文字資料。

這個時候CPU的設計也慢慢地開始從一台電腦只有一個CPU，到有多個CPU。在1970年代左右，計算的重心是放在超級電腦(Supercomputer)上。此時所發展出來的平行計算(Parallel Computing)的能力，足夠代表一個國家的科技水平甚至是戰爭科技。在當時也只有擁有超級電腦的國家，才有能力進行精確的彈道計算。換個角度不難可以想像，資訊科技及戰爭是相輔相成的方式互相成長。我們通常以FLOPS(FLoating point Operations Per Second)，也就是每秒能夠進行的浮點數運算數量，來代表電腦的運算能力。今年六月的時候，IBM的Roadrunner以1375.8TFLOPS創造驚人的數字，也就是說這個超級電腦每秒可以進行一千多兆次浮點運算，而其他的超級電腦也有5~600TFLOPS。讀者們還是可以想像，這些超級電腦從以前到現在，大多數都還是在美國。

而我們計算的資料，也與以往大有不同。早期透過人工可以輸入，計算並理解的資料，100KB就已經是龐然大數。然而現在的資料量動則就已經上GB或是TB，已經不可能在透過人工的方式輸入。而這個時候許多自動化的輸入輸出裝置也相當普及，許多公司如IBM早已生產上百萬台磁碟儲存系統，每台都可以儲存上百TB的資料。另一方面像LHC所使用的偵測器，也能夠在很短的時間累積大量的數位資料。

很快地我們就發現，這樣的上TFLOPS的計算能量也無法完全滿足我們想要計算的資料量。

所以從二次世界大戰帶來了網際網路之後，運算開始走向許多台電腦一起進行，而並非以前的單打獨鬥。也因此從平行計算逐漸開始有了不同的分支，一個是利用網路將多台電腦串在一起，我們稱做分散式計算(Distributed Computing)，另一個是原本的多CPU技術(SMP)，逐漸往多核心(Multicore)的技術發展。分散式計算，根據分散及構成方式不同，在分做網際網路運算(Internet Computing)，叢集運算(Cluster Computing)，格網運算(Grid Computing)，P2P運算(P2P Computing)，以下就讓我來介紹這些運算方式。

Internet運算和雲端運算

在我過去的文章曾經討論到，在還沒開始Web 2.0的時代之前，人們的在瀏覽器上的輸入，不管是填寫的表單也好，或者是搜尋的關鍵字也好，都已經是構成大量輸入的動作，但這些資料並沒有啥關連性。在Google還沒成名的時候，很多人就已經投入搜尋引擎的研發。後來Google卻將這個技術建構得非常紮實，讓這些資料有索引，也讓這些資料關連越來越密集。儘管2004的時候尚無網際網路運算這個名詞，卻可以視作現在雲端運算的前身。

由於網際網路實在過於龐大，無法以一般的方式進行測量，只能夠提及這個代表性的計畫，Seti@HOME。Seti@HOME計算的目的是收集宇宙的電波，並進行快速富立葉轉換的演算，來變成電腦可以分析的資料，藉此來發現有沒有外星人的存在。利用BOINC的分散式計算系統，透過全球33萬台電腦，在今年八月的時候達到了528TFLOPS，相當於上述的超級電腦。而LHC也有使用BOINC進行一部份的計算。

可以想像全世界的電腦一定多過於這個數字，就知道未來雲端計算能夠發揮的能量有多大。

而現在不管Yahoo還是微軟，都與Google一起爭奪這個龐大資源。因為雲端運算不僅牽扯到全世界的電腦，也包括全世界的使用者。如果能做出更好的平台，更好的服務，讓更多使用者涉入，那就有更多的商機。

儘管雲端運算看起來像是驚人的科技，但也有缺點。要將世界的電腦組合成有用的資源，除了像BOINC平台去進行特定計算或跑特殊的程式，以目前的科技還無法這樣隨心所欲。我們還無法做到讓使用者想執行的程式，想解決的問題，都變成拿地球上所有電腦去跑。也因此，不管現在這科技三巨頭怎樣做，都還是以自身的經費所建置的運算資源來達成。也因此從這些公司口中所說的「雲端」到底是否有真正運用到網際網路上的電腦，還是一個大問號。但不可否認的是，他們耗盡研發能量，經費構成的運算資源，都會讓全世界的人有機會「使用」，甚至是免費的，這樣就不是一般的中小企業做得到的。此外以一個企業的經費到底能夠產生多少運算能量，也一定有個上限。

儘管如此，雲端運算能夠讓眾人自由甚至免費使用，還是一個相當大的誘因。其使用能夠帶給企業更多的利潤，這也是企業所希望的。人類日常生活的資訊會因為他們手上所持有的裝置(手機，PDA)，或是電腦的規格慢慢提高，而能夠產生更多的輸入，企業能夠去整理分析這些資料，並且創造更好的服務回饋給人類，我想是會讓生活更好。

所以雲端運算，重點並不是在其運算能力，而是應用與服務。這個目的與原本的網際網路是相同的，也因此大家從以前到現在，都一直是在雲上。

當然換個角度，對於學術而言，就不見得是要求服務，而是真正的運算能力。現在的科技能發揮多大，就要讓他能夠多大，是一直以來資訊科學領域的人員都在努力的事。真正在進行運算的是誰？誰願意在雲下呢？

格網運算

格網運算的發展

比較起上面雲端運算，另一個分支就是著重高效能，串連各個CPU的運算能力，而非著重在服務上，我們稱做叢集運算。然而叢集運算也有部分技術，構成現在雲端運算的底層，像是負載平衡或是備援技術，都在我的文章中有說明過。而叢集技術，也已經成為現在超級電腦的核心技術，否則光靠一台電腦也無法達到上TFLOPS的水準。如何榨出CPU的每一分運算能力，如何擠出銅導線的每一分傳輸能力，都是在叢集或是高效能運算的主題中討論。

叢集運算雖然效能強勁，但成本也高昂，並不是一般的民生水平能負擔的起。因此以商用硬體(Commodity Hardware)所組裝的電腦，便慢慢變成另一個主流。這個情況在國內的大學也常見，教授不見得買得起一整組叢集，反而是逐次分批購買小電腦，再以軟體的方式合併在一起使用。而許多應用在叢集電腦上的函式庫或作業系統，也慢慢地改變並且移到這些商用電腦上執行。其中Unix作業系統，就是從大型工作站，慢慢演進成現在一般人都可以使用的最好例子。

另一個叢集運算的缺點，也在於需要完全同規格的硬體。不同的硬體，不同的環境，很難組合在一起運作。軟體上也有同樣問題，為了效能，可能針對作業系統的版本，使用的函式庫來限制，讓不同的站點(Site)之間必須開發許多的轉換程式才能整合。此外，跨網路區域，例如說大學與大學之間，連線與使用的時候都會遇到安全性的問題。為了解決這些問題，於是又衍生了另一個技術，稱做格網技術。

格網這個名詞，在英文中，比較多被用在電力格網(Power Grid)這樣的名詞中。也有人稱為網格。而在格網運算的始祖Ian Foster的論文中，便把格網計算的遠景，形容為就像電力或水力一樣，想要用的時候打開就有。然而格網運算，常會被拿來與叢集運算比較。從叢集運算起家的老教授們，也常常地難以理解既然沒那樣快，又為何需要格網技術。

在格網運算中常常會提到虛擬組織(VO, Virtual Organization)，與W3C的技術規格。其實格網運算就是利用現有的叢集運算以及Web觀念當作底層，也有人說格網技術是下一代的Web 3.0。但格網技術是完全不同的目的，最主要還是增加資源的利用性，而並非只是求一個效能。

也因此，資源的收集，控制，服務，就成了格網中介軟體(Middleware)要完成的事。我們可以試著將這樣的觀念想像為漏斗，漏斗的下方是資源，由中央的中介軟體進行收集，再由更上層的軟體去應用。而這樣的觀念也逐漸擴充到別的領域，包括資料格網(Data Grid)。中間所有的協定，都以W3C所制訂的規格為主，如HTTP，XML等。也因此這樣設計的中介軟體，可以用來管理上萬台甚至數十萬台電腦，並且將其納入運算或儲存資源裡。

不管是美洲，歐洲，東亞都有許多的格網計畫及組織。這些組織各自在物理，化學，生物上都有許多極佳的表現。其中一個就是由現在熱門的大型強子對撞機計畫所發展出的歐盟e化科學格網計畫(EGEE)，目前已經有250個站點，四萬多個CPU同時進行運算，其運算量已經超過一個國家所能夠產生的。台灣也有許多格網計畫，像是中研院的TWGrid，以及清華大學的Unigrid。而國家高速網路計算中心也推動了許多格網計畫，如醫療格網，氣喘格網，超級視訊格網…等。

但談到這邊，我們又不禁感到疑惑，

「這些格網計畫與我何干？」

「我並沒有聽過太多這些東西啊？」

「我的生活並沒有因為格網而變得比較美好。」

格網技術現在都還在研究階段，不管是業界，或是民生，要使用到格網技術帶來的便利，還要相當長的一陣子。

下一代的P2P運算

P2P的重要性

談到P2P大概會有許多人會想到驢子(eMule)與BT(BitTorrent)，而且許多人在用的Foxy，迅雷，甚至使用者也不知道這些是P2P的軟體。在使用上，使用者完全有個直接的想法就是「下載」，即便過多的查詢封包會縮短他們網路設備的壽命。我認為資訊科技能夠讓使用者有這樣大量的需求，並不是在於技術本身，而是使用者能夠透過這些技術獲得什麼。使用者會希望透過P2P技術下載，也不外乎是因為這些網路上有著最多免費或盜版的資源。許多電影，音樂等需要著作權才能生存的組織不斷地與許多反盜版組織合作，甚至利用伺服器散播假檔；但許多P2P技術，分享方式，論壇，鄉民人力不斷投入…雙方的大戰就這樣持續已久。

實際上，現在所有流行的P2P技術，都還是最簡單的Flooding(像洪水一樣擴散訊息)，並不包括任何控制訊息數量的方法。更別提是否使用到哪種很有效的P2P Overlay結構，可以讓關鍵字搜尋更聰明，或者是提高覆蓋度來讓搜尋更快。至今(2008)，許多P2P技術仍在論文的階段，即使有了些成果，也都還是不穩定的技術。

我們所面對的真實問題

舉個例子，如果今天每個人的電腦，都很夠很穩定地儲存自己寫的部落格(而且自家電腦又快，不用等某X小站龜速的回應)，只要你敢寫，永遠不會不見。那再加上如果有個地方，用很簡單的方法訂閱，讓大家可以「看見」自己寫了新的部落格文章，那有多好，是吧！

那對服務提供的業者呢？一來，業者不需要承擔資料消失的風險，因為「有種方法」可以讓資料永續存在，不因用戶重裝電腦而消失。二來，業者只要定期地去分析分類索引，做個首頁讓想要看的人可以快速地連到「某台電腦」並且讀取網頁就好了。這個某台電腦在哪裡，已經是一個大問號。而這個問號的背後，又遇到一個情況，那就是如果一個台灣人想要讀一個在美國的好友的部落格，因為相隔甚遠，勢必要遇到一些讀取緩慢甚至失敗的問題。

而最後的疑問還是，根本無人可以保證上一段話「」裡的那兩點。沒有方法可以保證資料的存在性，也沒有方法可以在提供資料的用戶關機後還能夠確保資料被讀取。

該怎樣解決？這個時候便讓我想起攻殼機動隊電影版第一集裡的一句話：「網路是無遠弗屆的」
我們接下來再來討論這個問題。

群聚性

我個人相信，未來的幾年，P2P技術一定會慢慢地與Web和Mobile技術結合在一起。人們會慢慢開始發現，他們每一個連結並散到網路上的訊息，都會讓他們在各個層面發現與自己類似的人。舉例說，當你在使用Last.FM的播放器，將你聽過的歌曲資訊傳到網路上，雖然只是一個小動作，但其實使用者在聽歌的時候，無非也只是想要認識能夠一起聽歌的人，不然就是希望可以找到更多免費且類似的歌曲。人們不管是使用哪種服務，總是希望可以螞蟻雄兵，藉群眾來獲得更大的效益。

而一間公司是否能有效率地使用用戶端資源，也就變成這間公司的一個最大的命脈。儘管他們有非常多的創意，當服務資訊瞬間累積的時候，他們也會發現根本毫無能力可以儲存，分析，計算。而那些能夠分析的公司，也通常是大企業，因為他們有雄厚的資本額可以建立這些分析的機制。當初Google也是藉著搜尋技術以及廣告而起家，才能有資本；而許多小公司，連技術都不見得可以拼得過，又能夠累積多少用戶來強調他們的廣告能見度，藉此吸引廠商？想要藉著新技術，或是以老鼠會的方式來招攬人頭客戶的方式根本行不通。

我想，真正能夠顧及使用者需求，並讓使用者享受功能的時候也付出，才是歷久不衰的道路。而如今，我認為P2P的網路結構正是符合這種意義，並且有效率的方法之一。在設計服務的同時，不妨也思考一下這些提供資訊的節點互相連結的方式。別用別單純地Flooding的方式，期待使用者的訊息慢慢地傳到分析用的伺服器，或許也可以思考怎樣構成一個有結構的網路(多維度，圓環狀，階層化…等)來加速同類型使用者的群聚性。從另一個角度說，就像是訊息傳遞的更快的社群。

中介資料

一方面讓網路產生群聚性，而另一方面，使用者就要積極地產生資料，來讓網路能夠分析並且群聚。

在我寫到Web2.0有關的幾篇文章裡有提到，Web 2.0便是有這樣的特性，讓使用者不斷地去輸入以便產生資料。這樣的資料我們稱做中介資料(Metadata)，也就是描述資料的資料。

舉例來說，你撰寫了一篇遊記，這篇文章裡有十個關鍵字，都是這篇遊記裡的重點地點，像是「台北」「新竹」。你上傳了一些照片，裡面有這些照片的座標。那麼這個時候，搜尋引擎就分析這些中介資料，來讓大家在搜尋台北和新竹的時候能找到你。而這不僅加速了搜尋引擎的效率，因為他不見得一定要掃瞄整篇文章才能做索引，同時也加速了這篇文章定位的準確性。

在舉個分享檔案的常見例子。假設我是一個喜歡電影的人，而我在我的興趣裡寫說「電影」。如果是以往，我要找到跟我有同樣興趣的人，並且互相交換電影，那就是先在交友網站認識後，剛好也發現對方也在開驢子或BT。但如果分享軟體本身就整合了Social的功能，使用者平常在編輯自己的相關資料的時候，也同樣地更能增加下載軟體的群聚性，增加下載速度。

如何整合

格網的優點是整合，而P2P的優點是搜尋，鬆散。比起以往使用某一種格網使用的傳輸協定，去包裝P2P的傳輸協定，未來整合的方式比較著重在將格網層的資源要求，轉換為P2P層的資源要求。舉例來說，如果有人對格網服務要求一個檔案，那這個服務便馬上要對下層的P2P網路進行搜尋，看誰有這個檔案。也因此P2P網路就比需採用更快的Structured Overlay，並且與上層的格網服務作緊密的整合。整合SuperPeer或許是一個加快網路查詢的方法，但也會給SuperPeer太大的負擔，因此這樣類型的節點，要能夠地轉移。

而檔案要如何保持存在網路上，也是一個問題。目前有相當多的研究都是著重在複寫(Replication)演算法上，許多複寫演算法要能夠探知整個網路的狀況，檔案的存在度，是非常繁瑣的作法。而我相信未來的電腦無論cpu，網路速度都會提昇，將網路的中介資料切割後再逐漸掃描，會是一個趨勢。

結論

在未來，每個人手上都會有一台以上的電腦。大家都會有手機，桌上型電腦，甚至數位相框，電冰箱…等家電也都是電腦。而這些電腦一旦串連起來，將會產生相當龐大的計算能力。你手上的電腦，將是維持世界運轉的一小小動力之一，當你使用一個方便服務的時候，也可以想想有些資料是從你的手機上貢獻出來的。

]]> http://kiwi.csie.chu.edu.tw/blog/archives/183/feed http://kiwi.csie.chu.edu.tw/blog/archives/184 http://kiwi.csie.chu.edu.tw/blog/archives/184#comments Fri, 12 Sep 2008 08:10:07 +0000 Kiwi http://kiwi.csie.chu.edu.tw/blog/?p=184 冷氣壞掉…拖了好一陣子

不過最近剛好也都處理的差不多了，也升級到WP新版了…

說真的這幾天實在是令人覺得驚奇

打從聽到Jeff發現我的作品也被選上，到公關公司打電話來
星期三過去看見73樓這些令我讚嘆的景色
直到記者會…直到星期六上台這10分鐘
總覺得好像在夢境中

不管怎樣，還是很給感謝Google給我這個機會展示
儘管還有許多功能還要加強，而且ok17go整合apps engine也已經是勢在必行了
我想接下來我有一些重要的任務就是，趕緊多帶一些學弟們一起開發
不然使用者們想要的功能就要等很久了

星期三基本上是去談一些初步的方向，例如說當天該怎樣簡報，也認識到了Caroline，Josie，Jessica，Andy等人。大家一下子就聊開了，其中Jessica一直讓我覺得很像我一個國中同學，大家都叫他奧莉薇XD。Caroline很招待我們，各塞給我們一個冰淇淋，還有一堆零食帶回家。文化是的確不同，但還是有點不好意思。

其實我心裡一直覺得能夠在73樓看風景，就已經不枉此行了吧。

星期五的時候就相當地混亂了，這是我人生第一場參與類似記者會的活動，實在是相當地緊張。儘管好像我們這組收到有關於簡報的內容有點誤解，其他都有DEMO，但我們是透過投影片，但也沒關係啦。雖然林大哥講的很生動，但我心裡想還是未來真的能夠有實質的應用比較重要。

記者進來前十分鐘的小插曲，Jessica走了過來，似乎很緊張的樣子。其實我也感受得到，被邀請的人，當地主的人，都很緊張XD
不過一回生，二回熟啦，我相信未來Google會舉辦更多活動的。

接著也還是去逛了逛，跟著記者排了一堆東西，我好像也是狗仔隊一樣啊XD～
不過其實我心裡真的感受到，他們跟我們公司滿像的。當然資源比起來是截然不同，可是我們也很有那種氣氛。其實在Google工作，並不是見得都是在玩吧，可能網路上有些blog報導地令人誤解。其實躲在會議室，座位上拼的要死的人大有人在。此外大家也是因為有客人，才想說也放鬆一點的。

那我就隨手拍了一下Jessica小姐(旁邊是記者小姐)XD

你知道嗎？我還是愛死這冰箱了XD
冰箱及零食真是工程師拼到半夜不可或缺的東西啊！

據說這次，本來只想要300人參加，沒想到來了1300人，原本預計有啥Party的大概也沒了吧。
星期六的時候，也是大混亂啊…
其實上場前10分鐘我都還在處理網路的問題…orz
Google Earth用虛擬機器跑，實在很不聽話，不過展示還是勉勉強強過去了…

這位是幸運地圖的作者，我還是覺得應用與技術的關連不能說是絕對的，他還是有著相當有趣的應用。我相信他如果遇到更好的技術人員一定能夠將這個有趣的想法發揚光大，台灣很多人都很喜歡算命啊～

MAC遙控器的簡報方式原本是我在學校常用的方式，但是發現在這種大小的場地顯得相當地不好用。我只好乖乖地回到NB前按鍵盤，大多都是拍到我向下看的畫面…orz

總之，獻醜了！

其實我還是覺得技術人員的心情，並不是每個都顧著想要展現技術。這次很可惜的是，我們錯估了到底有多少技術人員會來這裡。因此前一位上場，我就想說糟糕，大多數看起來都不是來聽技術的…orz。然而我毫無經驗，讓大家聽了可能有點乏味，但我想下次會更好的。

在這裡還是要感謝林大哥及許老師在我瀕死邊緣都還幫我很多大忙…謝謝你們！

這位是ericsk，他的揪團網也是很有趣的作品，其實我很喜歡他的網頁設計方式。然而聽他提過系統的部分他很「固力」，還找國外的rails主機。說真的，我很想幫幫他！未來希望有機會能夠一起做這些有趣的東西！也希望大家多給他鼓勵吧！

說真的星期五記者會他狀況很好，可能因為星期六場地很難掌握情況，他很緊張的樣子 ＠＠

再來是聊聊我聽了四場演講，其中兩場是Apps Engine初階，進階；另兩場是雲端運算及Android進階。

說到為啥我喜歡用google的產品，並不是因為他們大，而是他們真的從完整並且簡單的層面考慮到使用者的需求。或許Yahoo他們可以很明確地像大企業一樣在租CPU，可是其實能夠用的平民老百姓又有多少呢？但Apps Engine講個簡單的例子，像我們學校的學弟妹們，大二大三就可以開始學習，並且撰寫。但你要他們去用EC2？不太可能。

確實在進階的時候Bratt講的挺快的，不過卻很清楚。就像有人說他們其實都盡量用台灣人聽得懂的英文，所以儘管展示尚未了時間而很快，卻讓我瞭解到幾點：

1. 確實以BigTable的特性來說，不適合實做Relational的功能，畢竟資料是以Column-based Database的觀念為基礎，而非Row-based的。在這種情況下，要用MapReduce去scan，並且跑join，那可真是累啊。也因此DataStore的特性就變成純粹是以Distributed Object Storage的觀念來思考了，換句話說，就像DRb(Distribued Ruby)Object一樣，物件輕鬆讀取的時候很爽，同步的時候就頭大了。
2. 既然寫很累，那我們就要更加利用一次寫入的特性來加速。以往我們會依賴SQLServer幫我們管理自動遞增的序列資料，我們會經常使用這個來當作某表格的ID。可是，DataStore可不是表格啊，因此言下之意就是說我們得自己管理serial。當然Bratt也提出說，只要有unique特性一概可當ID，不一定要遞增。那麼，將你要當ID的那個Class(舉例StudentIndex與Student)組合成EntityGroup就可以了，因為組合在一起的時候，他們會一起在後端被序列化並且寫入。但如果沒組合在一起，應該就是分兩次寫入了。
3. 善用內建模組，但這也要他們趕快改好一些模組出來給我們用。並不是我直接把python函式庫放上去就可以的啊…
4. Pete跟我提到，他們一開始推廣DataStore的觀念也很頭痛，也因此才弄了GQL，不然大部分習慣SQL的工程師根本無法接受。但我心裡覺得GQL不是萬靈丹，還是掌握好物件的讀取寫入原則比較實在。

希望Batch Processing的功能快出現吧，ok17go得用到啊…

提到雲端運算，我個人認為有點媒體噱頭嫌疑。
此外並不是說葉博士講的不好，但我同事真的睡著了，還是覺得這次來的人多半是聽樂趣，聽應用，而非開發者。

為啥說有噱頭呢？因為實際上的內容，還是在介紹Google Infrastructure。那麼雲到底可以為使用者帶來什麼？難道真的只有在Web開發上嗎？從一個角度來看，我相信Google終究希望使用者盡量在Web上發揮的，這也是當初他們從Web反攻回視窗平台的理由吧。為了這個理由，把Internet當作天上的雲，而Google就在雲上，聽起來也確實滿有宣傳效果。

但我相信Internet的應用，儘管實在不能小看瀏覽器及普及應用帶來的威力，但也不完全是在Web上。我想能夠掌握基礎原理，並將其用在使用者所希望的功能上，才是重要的。舉例我到現在還是用Great News而並非Google Reader，那是因為視窗就是反應快嘛。而如果說看網頁…像Foxy那樣嵌IE在他們的程式裡，也是多此一舉了。那麼，對很多人從應用的角度來說，是不是在雲上(是否大量依賴Google或是Web技術)也不見得重要了。

而我們的校務平台也說明此事，就是對許多老師而言Google Docs根本不可能取代Microsoft Office。儘管XXXX的時代來臨，也還是有許多人在用他們覺得習慣的東西。但我必須承認，一開始遇到一個新名詞，新技術，許多工程師就會有非跟不可的衝動。我期許自己在未來更能審慎地辨識這些技術名詞的本質。

這場我很讚嘆啊，我並不是嵌入式系統領域的人，只能單純以計算機組織的的程式執行觀念來聽這場的演講。可以理解，為了節省記憶體，是用盡了各種手段。

我很好奇的是最後耗電量真的有減少嗎？吃空間，與CPU去Dereference哪個耗電呢？

我不知道其他家有沒有也做類似的事，但講實在究竟有哪一家敢大膽以Java當作主要開發的語言，而並非C。這不像以前的手機平台是J2ME，我想他們支援的Java語言完整性，與Android提供的函式庫，無法拿J2ME來比吧？然而他們給了會Java的人這個機會，也提升了Android發展的潛力。

那至於iPhone呢？資策會的記者大哥也有問我，覺得Android與iPhone未來哪個發展潛力大？我還是覺得以Android上的函式庫數量，是比較吃香的。至於他們所採用的是Java，讓開發產能也有競爭力。前一陣子儘管有聽過Sun想要找Dalvik VM的麻煩，不過現在看起來局勢已定，也很難去挑三撿四了。

因此未來ok17go確實是希望往Mobile的方向前進，旅遊整合行動是勢在必然的。

經過這次神奇的體驗，我想我大概是離不開Google了(大誤XD)
其實我發現我的開發任何地方都需要用到他，而且還用得不少。

那時候MMS簡訊上傳，本來是想靠另一家，但後來也還是用了GMail+IMAP。
還是那幾句老話，我是真的覺得他的API寫得很清楚啊，Tutorial也很多，但就是密技太多了XD。

現在我個人的情況就是，我得回到我的論文上，畢竟我還是做Grid Computing起來的，Web及Mobile是興趣，淵源一樣，用法不同啦。未來我會希望好好地去研究Google在他的Infrastructure上的技術貢獻，也會加緊研究Hadoop及HBase，我也希望中華能有機會加入第二次的Academy Program。我覺得Grid把事情講的太大太複雜，但如果能夠在應用面上與使用者透過這些技術連結在一起，那很多學校都能有機會投入並且創造屬於自己的計算平台。

外部連結

http://blog.ericsk.org/archives/999
http://www.lis186.com/?p=1820
http://blog.pixnet.net/nsysumis94/post/18722773
http://sullivan0201.blogspot.com/2008/06/google-developer-day-showcase.html

(本文圖片皆引用自PGCluster官方網站，http://pgcluster.projects.postgresql.org)

我在商業服務的Ruby on Rails HTTP Cluster觀念及測試中的第一張圖的前面那一段有提到說，DB的情況有點像是如此，不過實際上情況有點不同。因為有網友的疑問，如今我認為該是時候補完一下。

應用系統如果要能夠真正地服務大量的使用者，與常見裝個MySQL然後跑個PHP論壇程式，是完全的兩回事。因此一個良好的資料庫管理員，必須清楚地知道自己的應用程式與資料庫在單台機器上執行的時候，效能的瓶頸在哪裡。如果不清楚應用程式及資料庫各佔的資源比例，那在切割成叢集的時候，並不見得有 顯著的效能提升，因為負載平衡以及複寫管理的程式都會吃CPU。認為1+1就極有可能等於2，這個是一般的管理員錯誤的認知。

舉例來說，許多大型的論壇，擁有上萬使用者，每天流量破10G；這樣的論壇，有些時候一開始因為資金及管理人力的限制，會考慮只買一台效能相當好的伺服器(例如HP ProLiant 380 G5)，並且將Apache+PHP(應用程式)與MySQL(DBMS)擺在同一台主機上。管理員會想說反正這台效能高，一方面省下買另一台伺服器的錢，一方面PHP程式不用透過網路與MySQL連線，理論上應該效能很好。卻沒有考慮到，一般的論壇Web應用程式是以CPU及RAM需要量大的應用，而DBMS是一種I/O裝置(RAM+Disk)需要量大的應用。這是由於，大多數的管理員會誤以為DBMS僅吃CPU與RAM。負載低的時候看起來沒什麼，一旦人數增多，表示應用程式的部分記憶體就會越吃越多。系統用來快取的記憶體不足，很快地瓶頸就會出現在記憶體及硬碟之間，造成資料庫效能低落。這個代價比使用兩台機器跨網路線這樣的部署方式要來的大太多。

叢集化

在DBMS相關議題中，有幾個主題會在叢集化的時候一起討論。

複寫管理(Replication Management)

複寫可以理解為「複製」的意思，不過複寫這個詞更強調的是資料的一致性。在DBMS中進行的複寫，是針對Insert，Update，Delete三個指令，將指令在所有的節點上執行，並且必須檢查這些動作後資料是否一致。目前所有開放原碼的PostgreSQL專案中，比較有名的是PGCluster，PGPool及Slony-I。

PGCutser是一種多服務點(Multi Master)的複寫系統，意指資料會在節點之間全部同步，儘管會有些許時間延遲，但不至於有影響。與Master-Slave不同，並不需要寫入特定某個節點才能複寫至其他節點。PGPool也有相似的作法，也同時允許對多個節點進行複寫，但實做方式可能不同。

(註：儘管PGCluster與PGPool在技術上相似，但有些文章並不認同它們兩個是使用類似的技術)

Slony是一種Msater-Slave的複寫系統，資料只能夠從指定的節點寫入，而複寫至次要節點的時間也會稍微延遲。

複寫儘管能夠在資料庫叢集上發揮作用，也能夠做為備份使用。總之資料庫同步了，就看你要拿去做什麼用途。此外同步的複寫，與延遲的複寫，所影響的也只是被複寫的資料庫是否是要做線上使用。如果是延遲複寫，就要注意最好是當作備份，而非拿來做線上使用。

Statement Level 與 Row Level Replication

Statement Level與Row Level意義上就是，前者是複製SQL指令，後者是複製執行完SQL的一筆記錄。上述所有三套複寫管理的程式，都是採用Statement based。而像MySQL, Oracle等都有提供Row based replication。這兩種複寫的差異在於，一旦你的statement是Procedural Language，有可能在不同的節點上會造成不同的結果(non-deterministic)，那複寫便失敗了。而Row based的好處正是反過來，既然已經知道結果，便不會有任何差異的可能性。

查詢緩衝(Query Pooling)

對於許多應用程式而言，很有可能連續地進行同樣的查詢。例如你將應用程式的功能選項名稱列舉在表格裡，那為了讀取所有選項，都會進行同樣的查詢。這樣的查詢與結果，是不需要再傳回實體資料庫真正進行查詢的，因此就由緩衝區直接將結果傳回。以資料傳輸的角度來說，在Client使用的函式庫裡實做緩衝，就不用再進行網路傳輸，比在Server上實做有意義多。

不過PGPool就是這樣的一套軟體，他也採用了查詢緩衝機制，使得同樣的查詢不會重複地傳給後端的實體資料庫。

負載平衡(Load Balance)

如同字面意思，當有大量連線進入的時候，負載平衡程式要能夠得知所有連線中的資料庫，並且將查詢分散給這些資料庫查詢。當有任何資料庫中斷，負載平衡程式也不能夠傳給已斷線的實體資料庫，以免造成應用程式錯誤。PGCluster與PGPool都有負載平衡能力。

另一種獨特的負載平衡，是將一個資料表格切割，散佈在所有的實體資料庫內。這種不僅做到了負載平衡，更有可能實現平行查詢。PGPool擁有切割表格並且平行查詢的能力。

共享儲存系統(Shared Storage System)與磁碟鎖定管理員(Disk Lock Manager)

如果你的資料庫儲存系統效能相當地好，或許你可以考慮使用共享儲存系統來讓一份資料庫的資料檔，能被多個資料庫系統實體同時讀取。在這種情況之下，當然你就不需要複寫系統來讓資料庫同步了。不過這也延伸一個問題，畢竟多個城市實體要進行寫入的時候，那就可能造成衝突，也因此使用何種磁碟鎖定管理員就有很大的差別。Oracle附了自行開發的鎖定管理員，而其他的開放原碼資料庫就得尋找其他開放原碼的解決方案。

儘管有些檔案系統具有共享的特性(如NFS)，但卻並非相當適合當作資料庫存取的機制使用。另一個著名的檔案系統Global File System(GFS)已經被證實能與PostgreSQL一起運行，GFS本身也帶有DLM。

有網友詢問說資料庫能否建置在這樣的共享儲存系統上？在這裡要說明，即便你有高出力的儲存硬體，但你還是得想清楚，共享檔案系統就是靠網路進行I/O，資料庫是一種依賴I/O的應用程式。如果你只有100Mbps的區域網路，還是打消念頭吧！

SQLServer的部署

這裡要提到部署的作法，是適用在全部的DBMS上。使用不同的部署方法，會影響到建置及維護複雜度，效能，可擴充性。

單服務點(Single Master)

單服務點所要顧慮到的只是上述所說的，「除非真的窒礙難行，不然別輕易地把應用程式與DBMS擺在同一台主機上」。一般來說你的應用程式應該是能完全與單服務點的資料庫一起運作，對於你的應用程式而言，他與一個單機的資料庫沒有啥兩樣。所以，不管你用PGPool或是PGCluster，應該會預設設定為單服務點。如圖：

這樣建置的優點還是較為簡單，但這個作法的極限就在於一旦你發現你的負載平衡程式已經消耗過多的CPU，或是對應用程式的頻寬已經大到明顯拖慢速度，就是該換架構的時候了。

多服務點(Multi Master)

多服務點就相對地複雜，如果你會採用多服務點，一定是因為你的應用程式服務點也相當地多。例如說你的應用程式伺服器有上百個，但怎麼可能上百個都向同一個(單服務點的)負載平衡程式進行連線？不管你用多快的CPU，給多大的記憶體，都一樣會爆掉。

這個時候你也不可能考慮單一的儲存系統，所以你只剩下一個選擇就是進行複寫，並且實做多服務點架構。

參考

http://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling

http://www.openminds.co.uk/post_gre_sql_mirroring_and_recovery.aspx

http://www.postgresql.org/docs/8.3/interactive/high-availability.html

http://www.openminds.co.uk/post_gre_sql_mirroring_and_recovery.aspx

需要套件：

• SRB 3.4.x
• PostgreSQL 7.4/8.2
• unixODBC 2.2.11
• psqlodbc 07.03.0200/08.03.0100

安裝PostgreSQL：

http://www.postgresql.org/ftp/binary/

rpm --rebuild  postgresql-{version}-PGDG.f8.src.rpm

建置完將libs,client,server,contrib安裝
啟動資料庫，建立好新使用者srb，建立好unigrid mcat資料庫，並將擁有者指向srb
編輯pg_hba.conf
使得localhost使用密碼存取

安裝unixODBC：

yum install unixODBC-devel

根據相依性也會裝unixODBC

安裝psqlodbc：

http://www.postgresql.org/ftp/odbc/versions/src/

根據PostgreSQL版本下載

./configure --with-unixodbc
make  all install

ln /usr/local/lib/psqlodbc.so /usr/local/libpsqlodbc.so

要改成lib開頭的檔案ldconfig -v才會抓得到

編輯/etc/ld.so.conf
加入一行

/usr/local/lib

接著ldconfig -v |grep psql
看有沒有

將iodbc.h isqlext.h isql.h複製到/usr/include裡
這是編譯SRB時所需要的

設定ODBC：

unixODBC根據兩個檔案作為主要設定檔
如果不清楚設定檔的存放位置
odbcinst -j 就會顯示

編輯odbc.ini

[Unigrid]
Description = Unigrid
Driver = /usr/local/lib/psqlodbc.so
Database = unigrid
Servername = localhost
UserName = srb
Password = {password}
Port = 5432

存檔後，切換到srb帳號，執行isql -v unigrid就可以測試連接
不正常的話會有一些錯誤訊息，正常的話會出現connected!
並且可以測試select

isql 指令後面跟著的就是odbc source name，在這裡也就是設定檔第一行[ ]裡的”Unigrid”
ODBC是一種資料中介層，資料來源可以根據不同的驅動程式，來讓不同平台的應用程式可以連接
例如可以讓資料來源指定驅動為excel，如此就可以存取excel檔了

不正常的情況：

[IM002][unixODBC][Driver Manager]Data source name not found, and no default driver specified
輸入給isql的資料來源名稱錯誤，很有可能是設定檔裡的[ ]開頭的項目沒有這一項，或是那一項設定的Driver參數沒有指定

[28000][unixODBC]FATAL: ….
這一種類型的大概都是從資料庫回來的，那就要看postgresql傳回啥訊息了，可能會是帳號，密碼錯誤，無法連線，或是pg_hba.conf設定問題

編譯SRB：

MCAT

./configure --enable-psgmcat --enable-psghome=/usr/local/pgsql --enable-javagui --enable-jdkhome=$JAVA_HOME
make

without MCAT

./configure  --enable-javagui --enable-jdkhome=$JAVA_HOME
make

1. Virtualization - 虛擬化
   1. Full Virtualization - 全虛擬化
   2. Para Virtualization - 半虛擬化
2. 參考資料
3. 結論 - 虛擬化的應用

虛擬機器(Virtual Machine, VM)，用比較白話的方式講，就是「模擬器」。
利用現行的硬體，撰寫系統，模擬另一套系統的整體結構，包括硬體，甚至韌體，就是虛擬機器。

虛擬機器大致上可以分兩種，一種是模擬整個硬體系統，執行環境，我們稱做「虛擬系統」，如最有名的VMWare系列，便是一種用來虛擬IBM x86 PC架構電腦的虛擬機器。另一種稱做「虛擬行程」是利用軟體中介層的方式，模擬出一套執行環境，例如Java的執行環境Java Runtime，就是使用Java Virtual Machine (JVM)作為其執行環境。

本篇文章主要介紹虛擬化技術，及兩個最常見的虛擬化平台，VMWare及Xen。

Virtualization - 虛擬化

舉個例子，很多人可能會有這樣的經驗，Office出了2008新版了，想要裝來玩玩看，可是又發現一旦裝下去，自己的Windows可能會一片混亂；或者，就是刪掉舊版再裝，又相當地浪費時間。當忽然想要用舊版的時候，總不能夠經常刪刪裝裝吧？

另一個情景比較容易發生在軟體工程師身上，軟體工程師經常都需要一個與自己開發用的作業系統不同的乾淨環境來進行軟體測試。可是想要機器的時候，總是要不到。工作還是得做啊，怎麼辦？

為了解決類似的問題，早在很久以前就有人研究虛擬機器的可能性。不過相對以前的電腦硬體效能，想要使用程式模擬執行環境，是相當地不可能的。直到最近CPU的發展，已經邁向多核心的方向，不管是效能，或是應用性，已無法與以往的電腦硬體相比。

所以剛剛的情境，實際上就在你的電腦裡利用VMWare Workstation裝一台虛擬機器便可行了，而安裝上去的作業系統，我們便稱做「Guest OS」。Guest OS基本上可以是與你的作業系統完全不一樣的另一種作業系統。例如說你的實體機器是Linux，而你卻可以在上面灌一個虛擬的Windows。

Full Virtualization - 全虛擬化

在早期還沒有虛擬化技術的時候，本來有一種叫做「硬體虛擬化」技術，當時是藉由安裝額外的擴充卡(上面有鍵盤與滑鼠的介面)，來分享系統資源。當然這種不符合成本的作法很快就被淘汰。

而在歷史上，IBM也在1966年開發過自己的虛擬化技術，而當時的作法，就成為了現在商業化虛擬技術的先驅。VMWare大約在這五年搶下了全虛擬化的市場，其中對於個人用戶最方便的莫過於VMWare Workstation。而VMWare也在2004年被EMC這間全球最大的企業化儲存系統公司併購，搭配了VMWare Server系列產品，全面攻下高階伺服器管理的市場。

全虛擬化的技術，最主要就是完全依賴完全建構的虛擬硬體層，這個虛擬硬體層為了Windows及Linux系統提供了較佳的相容性。換句話說，上面的「Guest OS」所看見的硬體，比較少會是直接延伸自原來實體的電腦硬體，如下圖所示。除了CPU及記憶體，主機板，VMWare幾乎都虛擬化了，有虛擬的BIOS，也有虛擬的顯示卡，而且都必須安裝專屬的驅動程式。這樣的優點是，不管在怎樣的硬體環境中，Guest OS都能夠維持比較統一的相容性。但缺點是，因為有了這龐大複雜的虛擬硬體層，相對的實體機器就得維持比較大的負擔。

(本圖轉載自VMWare官網 )

Para Virtualization - 半虛擬化

半虛擬化是利用Linux/Unix系統核心原本有的 Monitoring Mode，將電腦硬體的使用變得可以讓多個記憶體位置的程式在不同的時間呼叫。這種作法儘管不像全虛擬化一樣，反而是變成你的電腦硬體是什麼，Guest OS就會看到同樣的硬體，也就是說真的好像把你的硬體拿去共享了。當然優點就是，不需要消耗額外的系統資源來模擬硬體層，因此就算是多個Guest OS同時執行，你也不見得會感受到效能下降。但缺點就是，Guest OS的作業系統，必須使用和實體機器的一樣。如同下圖：

(本圖轉載自http://it20.info/blogs/main/archive/2007/06/17/25.aspx )

最好的例子就是Xen。Xen是一個開放原始碼的虛擬系統軟體，相對於VMWare各個版本都需要花不少錢買(儘管有免費下載)，Xen已經被許多開放原始碼的作業系統如Fedora，CentOS，Ubuntu等內建於其中。儘管沒有像VMWare一樣有精美的操作介面，但Xen還是提供了Virtualization Manager，一個簡單的視窗程式來讓使用者快速建立虛擬機器。

但對於半虛擬化的最大限制：無法使用不同作業系統，還是有不少人覺得說比起VMWare來說實在是無法當作一個很好的虛擬平台使用。因此Intel開發出了支援虛擬化的新技術，Pentium 4包括後其的P4 6xx系列, PD系列，及現在最熱門的雙核心及四核心，全部都有支援。此外AMD也在同時開發出一樣的技術，包括後其的Athlon 64, Turion 64, Opteron, Phenom都有支援。這樣的技術，使得Xen可以執行不同的Guest OS，而對於全虛擬化的平台也能夠再加速。

參考資料

網路上都有很好的文章，關於介紹，或者是教學

http://it20.info/blogs/main/archive/2007/06/17/25.aspx

VMWare

http://tw.myblog.yahoo.com/handle1963/article?mid=13350&prev=13477&next=13205

Xen

http://linux.vbird.org/linux_enterprise/xen.php

結論 - 虛擬化的應用

儘管虛擬化技術為個人能夠帶來一些工作上的便利，但其實從企業的角度，虛擬化是不可或缺的。

台灣自從好幾年前，政府積極投入半導體產業以來，已經搖身一變成為名符其實的電腦王國。世界上有四分之三的主機板，都是在台灣生產。而台灣不僅是生產主機板，記憶體的主力，近年來筆記型電腦，網路產品，直到伺服器，也多在台灣生產製造。而這樣大量製造的情況下，伺服器的功能越來越好，價格越來越便宜，一般的中小企業，學校單位，都已經不需要花大錢購買五萬十萬的伺服器，也能夠用一般的PC做一些基本的服務。

但伺服器與PC之間也存在一種迷思，我不買伺服器的話，能夠獲得穩定性嗎？確實伺服器的許多硬體設計都是雙份，兩個CPU，兩個電源供應器…等，來增加穩定性，卻也造成運算效能的浪費。根據統計，拿全世界的伺服器計算能量，與實際產生出的資料量比較，推算這些伺服器的使用量都不到10%。也就是說大部分的時間，你的伺服器的CPU都是閒置的。比起這樣閒置的浪費，安裝虛擬機器，不僅能夠提升CPU的使用量，而在設備的管理上，也不需要如以前負擔龐大數量的購買成本及維修成本。

舉個例，以往公司內的MIS最頭痛也就是最主要的工作，就是有人報修電腦。個人使用的電腦沒辦法，因為會影響工作，還是得修。可是在一些軟體公司，許多員工可能都需要數台額外的機器來做不同的應用或開發，這個時候MIS通常都要準備許多舊電腦供其使用，如果這些電腦也報修，在管理上真的是一大負擔。有了虛擬機器，MIS只要使用管理介面新增一個虛擬機器，並且將磁碟映象檔複製一下，IP抓好，一個新的作業系統就可以使用了。而增加的動作，加上映象檔拷貝的時間，可能花不到10分鐘。尤其在Linux系統上，透過Xen使用虛擬機器的使用者，幾乎不會感受到他們是在使用虛擬機器。

這樣便利的科技，目前也運用在蘋果的Mac上，如Parallel Desktop或是VMWare Fusion，這些都是可以讓你在Mac上使用Windows的方便軟體。

由於多核心CPU的發展，虛擬化技術的應用也跟著成熟，未來我相信還會有許多更有趣的應用。

MapReduce是開技術倒車？實際上這像是當初SQL推出的時候，很多人也認為以語言來描述資料的處理是多餘的事情一樣。而ORM盛行的時候，也有人質疑SQL已經很直觀了，為啥又要轉成物件。

“Ronn Brashear said:
…
A good engineer understands the specific problem space, examines the potential solutions, and picks the right tool for the job. “

所以說，Vertica DB發表這一篇也只是商業競爭而已，其實他們並不如Google能夠理解Column-based DBMS的好處，並經其原理應用在BigTable上，其中一個回應也說的對，根據paper裡所說的結構，BigTable是有index(還有vertica做不到的timestamp based query)。這些教授對RDBMS很熟，可是卻完全不瞭解parallel data processing是怎樣回事，因此誤用，並拿來對照。

當然我在上次的書報討論中，也將這幾個paradigm拿來比，是不太對的。不過當然就是想說先讓同學們瞭解一下觀念。

不管怎樣，在此重新釐清一次觀念。

Google File System(GFS)是一種Global File System，目的是以出力(throughput)為主，並不具備任何的檔案分割能力。他與Redhat推出的GFS功能上相似，但實測的檔案大小及效能差異極為懸殊。GFS本身不具備任何的DLM(Distributed Lock Manager)機制，而是以另一套服務稱為Chubby來提供，這也是跟Redhat GFS不同。簡單地說，把他想像能夠高速傳輸上10TB大小檔案的NFS即可。

MapRedurce是一個parallel data processing framework，根據程式設計師撰寫的Mapper/Reducer Function，搭配合併於framework內的checkpoint技術，而進行平行化的資料分析及處理。首先利用GFS的特性，使得大容量(如上述的10TB)並且為單一檔案的資料，能夠分散在適當的節點群組裡。接著Framework的主程序就會自動地散佈開發好的程式，進行呼叫Map,Reduce兩個函式，最後將結果寫回GFS去。也就是說，就某種角度，他比較像Condor，而跟資料庫一點都扯不上關係。至於說他是不是能夠用在Computation上，paper的說法是「有機會」，但我認為除非你將問題切割成資料處理，不然是很難有機會的。

BigTable是一個利用上述Framework所撰寫成的巨大資料集儲存系統，這裡指的是「資料集」，而表示這些資料彼此之間可能不具有任何的「關連」。因此將關連式資料庫能夠有的功能如transcation，拿來比較是不合適的。換句話說，你應該不會經常拿許多份Excel，將其內容合併(join)後才取出資料(select)進行你的工作(真的已經這樣就會去用DB而不是excel了)，而你也不會將資料庫系統裡就建一個表格，然後把所有欄位都放在同一個資料表裡(坦白說我還是有看過人這樣做@@|||)。BigTable如其名，就是一個巨大的表格，就像Excel一樣，而並不是DBMS。儘管在paper裡也提過他擁有一些與DBMS相同的功能，不過這也不代表他是被定義為DBMS。更何況，在這樣大的系統內，要堅持使用特定的觀念去解決事情是一件很不合理的事。

看完了，大部分人可能也還是無法從定義去對應到腦袋裡可以想像的模樣，而不免心裡會有疑問，這些東西搭在一起又能幹嘛？就未來來說，我們有機會擁有下一代平行資料庫的雛形，也有可能就真的只是一輩子被用在Google的應用服務中了。但就現階段而言，請不要忘記這世界上已經有多少人無時無刻地在使用Google的軟體了。

我的九型人格分析？